服务端怎么记录 token 用量？账单的来源

DeepSeek 等开放平台的用量页面上，每一行明细都对应真实消耗，服务端记录 token 用量的这套机制是一切结算的源头，调用方看懂它，花出去的每一份量都有来处。

可以把它想成水电表：表在墙外，用多少记多少，月底按表结算。这个类比的失效之处在于，水电表只记总量，token 计量要分输入输出、分缓存命中与否，精细得多。带走一个判断：用量记录在请求结束那一刻就已成型，账单只是它的滞后汇总。

从一次请求到一条用量记录

请求结束时，服务端会汇总几项数据：输入 token、输出 token、缓存读取量、缓存写入量，各记各的。

这份即时数据先落成一条用量记录，带上时间、应用标识和请求编号；记录进入汇总管道，按小时、按日滚动聚合；对账环节再核对记录总数与实际资源消耗是否一致；结算账单就是从这条管道末梢出来的。每一步进来什么、发生什么、出去什么都有据可查。

输入和输出的 token 各怎么数

输入按你发过去的全部内容计：系统提示词、历史对话、资料引用都算，这也是为什么长提示词更耗量；输出按模型生成的全部内容计，包括被你中途停止的部分。两阶段的计算方式不同，成本结构也不同，分工见预填充和解码差在哪？两阶段的分工。命中缓存的输入按折扣口径计，未命中才按全价计，前缀稳定时这一项能省下可观份额。

两个容易踩的坑值得单独说。一是「隐形输入」：系统自动拼进请求的内容——检索到的资料片段、历史对话摘要、工具调用的结果——都计入输入量，你在自己的提示词里看不到它们，明细里却实实在在。二是「滚动历史」：多轮对话里每轮都把之前的全部历史重发一遍，输入量随轮次增长，缓存未命中时这个增长尤其明显。看懂这两点，明细里「我没发这么多字」的疑惑多半就有了答案。

汇总、对账和账单的生成

记录汇总后要做两件事：一是出统计报表，供平时查看；二是在结算周期末生成账单，金额就是各口径单价与对应量的乘积之和。被拦截的请求多数平台不计输出量，只记极少量或零，口径见敏感词拦截在哪个环节？从原理到落地；撞上限未完成的请求是否计数，规则见请求的限流计数是怎么清零的？每一步都讲透。文心一言等平台的帮助中心都会公开计价口径，先读再调是习惯。

自己怎么核对用量记录

三步对账法：先取请求编号，在明细里找到对应行；再核对输入输出 token 与自己的估算是否在同一量级，可用字数乘系数粗算；最后看缓存读取占比是否合理，过低的占比提示前缀不稳定。速度表现与量的关系也值得留意，见首字时间和吞吐有什么区别？选型不再纠结。长期对不上的记录，交给平台反馈渠道处理，服务侧波动可先看健康状态，见推理服务的健康检查是怎么做的？。

用量对账三查：

• 请求编号与明细行是否一一对应
• 输入输出 token 是否在同一量级
• 缓存读取占比是否符合前缀稳定度

三查过关，每一份消耗都有来处。

换个问法再问 token 用量三句

• 中途中断的回答怎么计？：已生成的部分照常计入输出量，停止指令本身也占少量 token。
• 系统提示词每次都重复计吗？：命中缓存时按折扣口径计，未命中才按全价计。
• 用量和账单为什么会差几天？：账单要等结算周期结束并完成对账，滞后几天属正常。

看懂计量，用得起也用得明，这是调用方该有的基本功。