用脚本追踪DeepSeek API费用：周末定价变更后的真实成本

那张账单引起了我的好奇

我平时每周查看一次 API 账单就够了。但上周日那天实在无聊看了一眼，数字比我按实际使用量估算的要低。

查了一下才发现，DeepSeek 悄悄改了高峰/非高峰的计费结构。根据他们的定价文档，高峰时段现在是严格限于周一至周五的 01:00–04:00 和 06:00–10:00（UTC 时间）。其余时间——包括整个周六和周日——均按非高峰费率计费，约为高峰费率的一半（无论输入还是输出 token）。

我大部分测试都安排在周末（工作日要上班），所以理论上这次调整对我的影响应该很大。但"理论上"不够——毕竟账单是我自己付的。我需要的是我自己的实际使用数据算出来的真实数字，而不是猜测。

于是我写了一个小脚本。

没什么花哨的——它读取我的 API 调用日志（时间戳 + 输入/输出 token 数量），按照新的高峰/非高峰规则计算我的实际支出，并按工作日 vs 周末分开统计。

import csv
from datetime import datetime, timezone

# Pricing per 1M tokens (cache miss), off-peak / peak
PRICING = {
    "deepseek-v4-flash": {
        "input_offpeak": 0.22, "input_peak": 0.44,
        "output_offpeak": 0.66, "output_peak": 1.32,
    },
    "deepseek-v4-pro": {
        "input_offpeak": 0.66, "input_peak": 1.32,
        "output_offpeak": 1.98, "output_peak": 3.96,
    },
}

def is_peak(dt_utc):
    # Peak: Mon-Fri, 01:00-04:00 and 06:00-10:00 UTC
    if dt_utc.weekday() >= 5:  # Sat=5, Sun=6
        return False
    hour = dt_utc.hour
    return (1 <= hour < 4) or (6 <= hour < 10)

def calc_cost(model, input_tokens, output_tokens, dt_utc):
    rates = PRICING[model]
    peak = is_peak(dt_utc)
    in_rate = rates["input_peak"] if peak else rates["input_offpeak"]
    out_rate = rates["output_peak"] if peak else rates["output_offpeak"]
    cost = (input_tokens / 1_000_000) * in_rate + (output_tokens / 1_000_000) * out_rate
    return cost, peak

def analyze_log(csv_path):
    weekday_cost, weekend_cost = 0.0, 0.0
    weekday_calls, weekend_calls = 0, 0

    with open(csv_path) as f:
        reader = csv.DictReader(f)
        for row in reader:
            dt = datetime.fromisoformat(row["timestamp"]).astimezone(timezone.utc)
            cost, peak = calc_cost(
                row["model"],
                int(row["input_tokens"]),
                int(row["output_tokens"]),
                dt,
            )
            if dt.weekday() >= 5:
                weekend_cost += cost
                weekend_calls += 1
            else:
                weekday_cost += cost
                weekday_calls += 1

    print(f"Weekday: {weekday_calls} calls, ${weekday_cost:.4f}")
    print(f"Weekend: {weekend_calls} calls, ${weekend_cost:.4f}")

if __name__ == "__main__":
    analyze_log("api_usage_log.csv")

timestamp,model,input_tokens,output_tokens
2026-08-22T14:32:00+00:00,deepseek-v4-flash,1200,340
2026-08-23T09:15:00+00:00,deepseek-v4-flash,980,410

你需要导出自己的使用日志——DeepSeek 的管理后台支持下载调用历史，或者你也可以在请求时自行记录（如果你还没这么做的活）。

实际发现

用约六周的日志跑了一下：即便在这次调价之前，我的周末调用单 token 成本就一直比工作日低（因为部分周末时段恰好落在了旧的非高峰窗口之外）。调价之后，差距进一步拉大了——周六和周日现在无条件按非高峰计费，无论几点都是，所以我的单次调用成本又下降了一截。

对于在周末跑少量批处理任务的人来说，这是实打实的（虽然不多）节省。具体能省多少，完全取决于你实际的工作负载运行时间——如果你大部分用量集中在工作日下午，这次调价对你毫无影响。

这个脚本回答不了的问题

拿到这组数据之后，下一个顺理成章的问题就是：同样的工作负载，换成别的模型要花多少钱？上面的脚本之所以能跑，是因为我已经知道 DeepSeek 的定价结构。想用 Qwen 或 GLM 回答同样的问题，就得写一整套新的定价表，更麻烦的是还得做一整套新的 API 集成，才能生成可比的 token 日志。

这部分我没有用脚本解决——我把项目改成了通过 RouteAI（一个 OpenAI 兼容的 API 网关）来调用模型，主要是为了能把同一套请求格式指向不同的模型，而不用每次都重建客户端代码。这没有改变上面的计费逻辑，但意味着我可以真正去收集其他模型的数据，而不只是空想。值得一说的是，这只帮我省了集成的工作量——实际 per-token 定价仍然是各家模型厂商各自设定的。

如果你想自己跑

• 用 UTC 时间（而不是本地时间）导出或记录你的使用日志和时间戳（这点在第一次跑的时候坑了我）
• 为你使用的模型添加定价层级；我这里只包含了 flash 和 pro 两个型号
• 如果你在其他 provider 上，先确认他们是否有分时段计费，再来套用这个脚本

一句话总结：DeepSeek 的新定价把周末完全纳入了非高峰（此前只有特定时段才是）。我写了一个 Python 脚本，从调用日志中计算工作日/周末的实际成本拆分——脚本上文已附，MIT 协议，随你怎么用。

如果这跟你的技术栈相关，值得一试：www.fastrouteai.com