欢迎光临

DeepSeek API 费用对不上?usage、缓存命中、重试与流式中断对账实战

开发者在双屏工位核对 API 请求日志与费用表格,AI 生成写实配图
AI 生成写实配图,展示本文讨论的工作场景。

应用统计了 100 次聊天,平台记录却更多。常见原因是一次用户操作触发了多次请求,或者本地丢失了 usage。建立对账记录时,先明确一行代表一次实际发出的 API 尝试,再聚合到用户任务。

本文用虚构价格和模拟 usage 演示估算,不调用付费 API。实际单价、币种及模型规则从调用当期官方价格页取得,并保留生效时间和来源。

一、为用户任务和 API 尝试分别编号

business_request_id 关联一次用户任务,每次实际发出的请求另有 attempt_id。重试沿用业务编号,使用新的尝试编号。响应 JSON 的 id、供应商请求标识、模型名、起止时间、HTTP 状态和流结束状态也要单独记录。响应到达前就先写入 attempt_id,才能保留超时记录。

字段 用途
business_request_id / attempt_id 区分一次业务操作及其多次尝试
requested_model / returned_model 追踪别名和实际响应中的模型标识
usage / usage_state 保存原始用量,标记 received、missing 或 invalid
price_version / currency 关联当时使用的单价快照
status / finish_reason 区别正常结束、HTTP 失败、连接中断和本地取消

二、输入缓存命中和未命中分别计算

DeepSeek 文档提供 prompt_cache_hit_tokens 和 prompt_cache_miss_tokens。对返回这两项的响应,先核对它们之和与 prompt_tokens 是否一致,再按当期模型的计费规则计算。缓存命中数量已经属于输入 Token,计算时不要再将 prompt_tokens 全量加一遍。

参考资料 · DeepSeek 上下文缓存与 usage 字段

from decimal import Decimal
from usage_ledger import estimate

# 演示价格,单位为虚构货币 / 百万 Token
rates = {"hit": Decimal("0.1"),
         "miss": Decimal("1"),
         "output": Decimal("2")}
usage = {"prompt_tokens": 1000,
         "prompt_cache_hit_tokens": 800,
         "prompt_cache_miss_tokens": 200,
         "completion_tokens": 100}
print(estimate(usage, rates))  # 0.00048

上例由 800 个缓存命中输入、200 个未命中输入和 100 个输出 Token 组成。配套函数使用 Decimal,拒绝负值、字段缺失及输入计数不一致。价格适配层应匹配实际响应结构,不能把未知字段直接推成零。若模型提供推理 Token 明细,先核对其与 completion_tokens 的包含关系,避免重复收费估算。

参考资料 · DeepSeek 当前价格及计费口径

三、流式中断后,将用量保留为未知

按本次核对的 DeepSeek Chat Completions 文档,正常流的末尾内容 chunk 携带总 usage。include_usage 会影响此前 chunk 中该字段的出现方式。不同兼容接口对末尾事件安排可能不同,因此采集器应读取任何非空 usage,并验证流的完成状态。

参考资料 · DeepSeek 流式响应和 stream_options

在末尾到达前断开连接,本地可能没有完整 usage。此时保存 usage_state=missing、原始错误和已接收字节数,估算费用留空。界面显示出的文本长度只是一项观测,无法准确还原供应商计费。取消请求后的费用也应按平台记录核对。

四、重试和日志去重采用不同规则

同一条响应日志被消费两次,应依据 attempt_id 做幂等落库。请求实际重发两次,则保留两个尝试。超时发生时服务器可能已经处理请求,仅凭客户端错误不能判断该尝试是否产生费用。把“是否重试”“是否收到响应”“是否收到 usage”分开存储,后续才有依据核对。

五、按平台口径聚合,保留差额原因

  1. 统一时间范围、时区、币种、账户和 API Key 所属项目。
  2. 按模型和价格版本聚合已收到的 usage,单列缺失用量尝试数。
  3. 核对优惠、赠送额度、价格调整、舍入与入账延迟。
  4. 对无法解释的差额,携带请求标识向平台核查。

不要将带完整提示词的原始日志当作默认对账材料。常规费用记录保存必要标识与计数即可,敏感内容按另外的访问和保留策略管理。

验证范围:usage_ledger.py 已用虚构价格验证正常估算、缺失 usage 和缓存计数不一致。尚未使用真实 DeepSeek 账单逐笔核对。关于额度入口,可继续阅读站内已有的 DeepSeek API 免费额度文章。

配套文件与同系列文章

下载本文 Python 示例 ZIP。技术文档核对日期为 2026 年 11 月 10 日。

【本站文章皆为原创,未经允许不得转载】:汤不热吧 » DeepSeek API 费用对不上?usage、缓存命中、重试与流式中断对账实战
分享到: 更多 (0)