AI API Token 用量怎么统计？7 天日志模板与月成本换算

成本计算器只能算你填进去的数字。真正决定结果是否可信的，是这组数字来自“拍脑袋预设”，还是来自一段可以核对的调用日志。

这份模板只做一件事：连续记录 7 天 API 调用，把输入、输出、缓存、失败和重试分开，再换算成月用量。你不需要保存用户原文，也不需要把 API Key 交给任何第三方。

演示任务与可复现输入

假设你在后端调用 DeepSeek OpenAI 格式的 Chat Completions 接口，为文章生成摘要。连续 7 天记录每次调用，但只保留下列计费和可靠性字段：

DeepSeek 官方 Chat Completion 响应把输入记为 prompt_tokens，输出记为 completion_tokens。流式调用时，需要启用 stream_options.include_usage；接口会在 [DONE] 前额外返回一个带完整 usage 的数据块，其他数据块的 usage 为 null。

可复制 CSV 模板

先复制这一行作为表头：

timestamp,request_id_hash,scenario,model,prompt_tokens,completion_tokens,prompt_cache_hit_tokens,prompt_cache_miss_tokens,status_code,latency_ms,retry_count

下面三行演示成功、限流和重试后的成功结果：

2026-07-25T09:12:03+08:00,7f2ac418,article_summary,deepseek-v4-flash,4620,812,1280,3340,200,1840,0
2026-07-25T09:13:17+08:00,05bd778e,article_summary,deepseek-v4-flash,null,null,null,null,429,216,0
2026-07-25T09:13:19+08:00,05bd778e,article_summary,deepseek-v4-flash,4388,756,960,3428,200,2094,1

失败响应没有返回 usage 时，缺失值填 null，不要填 0。0 代表已经确认没有消耗，null 代表不知道；两者混用会让汇总结果看起来比真实情况更精确。

如果 429 开始连续出现，不要直接增加重试次数。先按 DeepSeek API 429 排障清单 同时记录账号在途并发、请求速率和退避结果。

操作过程：连续记录 7 天

1. 先固定业务标签

   用 article_summary、support_reply 这类稳定标签区分任务。不要把用户邮箱、手机号或原始问题塞进标签。

2. 成功和失败都写一行

   成功请求记录官方返回的 usage；失败请求保留状态码和耗时。没有 usage 就写 null，不猜 Token。

3. 重试沿用同一请求哈希

   同一业务请求再次调用时保留相同 request_id_hash，并增加 retry_count，这样才能区分真实任务量和额外调用量。

4. 第 8 天再做汇总

   汇总 7 个完整自然日，排除压测和开发调试，再分别计算输入、输出、缓存、失败率和重试率。

结果样例与验收记录

假设 7 天汇总结果如下，数字仍是演示数据：

先做三个一致性检查：

1. 缓存命中输入 + 缓存未命中输入 = 输入 Token，本例为 94.5 万 + 220.5 万 = 315 万。
2. 同一个 request_id_hash 出现多行时，能够解释是重试还是重复写日志。
3. 所有失败行都保留状态码；没有 usage 的失败行没有被错误地填成 0。

从 7 天换算到月成本

为了与本站成本计算器一致，先按保守方法把全部输入视为缓存未命中：

• 月输入：315 万 ÷ 7 × 30 = 1350 万 Token
• 月输出：63 万 ÷ 7 × 30 = 270 万 Token
• 在计算器中填写：输入 13.5，输出 2.7

如果要做缓存感知的账单估计，再分别使用缓存命中与未命中价格计算。不要把缓存命中率当成长期常数；提示词、上下文和访问分布变化后，它可能立即下降。

上线前检查清单

官方资料与字段来源

• DeepSeek Create Chat Completion：官方响应结构包含 usage、prompt_tokens、completion_tokens、缓存命中与未命中字段。
• DeepSeek 中文错误码：区分 400、401、402、422、429、500 和 503，避免把所有失败都写成同一种错误。
• DeepSeek 中文模型与价格：将日志中的输入、输出和缓存字段映射到当前官方价格。

失败边界与不适合条件

• 7 天只是一段观察窗口。节假日、营销活动或批处理任务明显波动时，不能直接乘以 30 当作年度预算。
• API 返回的 Token 用量不能证明输出质量。还需要固定样本、人工验收和失败原因记录。
• latency_ms 是调用方测得的端到端时间，不等于供应商纯推理时间。
• 没有 usage 的失败请求成本未知；把它记为 null 能保留不确定性，但不能证明没有消耗。
• 这份模板适合低敏感度的成本分析。医疗、金融、客户隐私或受监管数据需要单独的数据治理方案。
• 如果业务必须保存原文用于审计，应先确定权限、加密、脱敏和删除周期，不要直接扩大这份最小日志。

FAQ

为什么不用用户 ID 统计？

成本估算只需要请求和场景维度。若业务必须区分用户，应使用不含个人信息的不透明内部标识，并遵守供应商和自身隐私规则。

失败请求为什么也要写日志？

失败率会影响重试、体验和最终成本。只记录成功调用，会看不到 429、服务错误和被重试放大的流量。

7 天数据可以直接作为下个月预算吗？

可以作为第一版基准，但还要同时计算流量翻倍、输出变长和重试上升的情况，并在第二个周期复核。

日志需要永久保存吗？

不需要。先定义分析目的和保留周期，产出聚合报告后删除不再需要的逐请求明细，通常比无限期留存更安全。