用了一段时间接口，某天去对账，发现扣的钱比「调用次数 × 单次价格」算出来的多了一截。这时候最容易冒出两个念头：是不是被多扣了，是不是接口在偷偷计费。但绝大多数情况下，账本身没错，错的是我们对计费口径的想象——有三件事只要没对齐，自己算出来的数字就必然和账单差一截。
先分清：是按次收费，还是按量收费
同样一趟调用，计费方式可能完全不同。图像、视频、语音这类产出物固定的模型，通常按「次」或按「秒」计——你发一次请求，就是一次的量，和你提示词写多长基本无关。而对话、补全、嵌入这类文本模型，是按输入输出的 token 量算的：同一个问题问两遍，只要上下文不同、回答长短不同，费用就不一样。
所以对账的第一步不是算钱，而是确认这个模型属于哪一类。按次的用「请求条数 × 单次价格」核对；按 token 的要用「输入 token × 输入价 + 输出 token × 输出价」核对。拿按 token 的模型去乘单次价格，或者反过来，算出来的数一定不对，但这跟账单是否准确是两回事。
口径错位造成的「对不上」，占了这类问题的绝大多数。先确认口径，再谈金额。
第二件事：倍率和折扣会乘在单价上
接口站通常不是「一个价卖到底」，而是按分组给出不同倍率：默认分组、高速分组、低价分组各有各的系数，同一个模型在不同分组里价格能差出一倍。你的 Key 绑定在哪个分组，调用就按哪个分组结算——很多人换了 Key 却没意识到分组也换了，于是同一套代码跑出来的费用对不上。
还有一层是输出长度。文本模型里，输出 token 的单价普遍比输入贵几倍，因为生成比读取更耗算力。一条「问一句话」的请求看着很短，但如果让它写一篇长文，输出量可能是输入的几十倍，费用自然也会高出许多。看到账单里输出占了大头，先别怀疑计算，先翻一翻模型的输入输出价格比。
第三件事：单位别读错，量级差得离谱
报价单上的价格常以「每百万 token」标注，而账单结算往往以更小的单位累计。中间如果看错了量级，算出来的差额会是十倍甚至百倍，看着像严重错误，其实只是少除了一个数。建议把换算写成一行固定的公式贴在自己的核对表里，每次都套同一个公式，而不是每次心算。
视频、语音这类按秒计费的任务还有个小坑：接口返回的用量字段不一定叫「秒」，有时藏在看起来像 token 数量的位置里。遇到这类模型，去查调用记录里的时长参数，比盯着那个数字猜要靠谱。
一套可复用的对账流程
第一步，导出调用明细，按时间窗口截取你要核对的那一段，别把不同分组的记录混在一起。第二步，按模型分类汇总，把按次和按 token 的分开。第三步，对每一类套用对应的公式，算出理论金额。第四步，和账单逐项比对，只盯差异最大的那几条，不必全量重算。
如果差异集中在某几条记录上，就去翻那几条的请求内容：是不是带了很长的上下文、是不是触发了重试导致一次意图两次扣费、是不是流式输出中断后重发。一次对话被重试三遍，账单上就是三份钱，这属于程序设计问题，不是计费错误。把重试逻辑改成「只在明确的失败状态码下重试」，这类冤枉钱立刻就能止住。
常见问题
请求失败了，会扣费吗？
取决于失败发生在哪一步。如果是网络没通、鉴权被拒、参数校验不通过，请求根本没进到模型这一层，通常不计费。但如果模型已经开始生成、只是中途超时断开，上游已经消耗了算力，就可能产生费用。核对时重点看那些「开始得很正常、最后报错」的记录。
同一个问题问两次，为什么价格不一样？
因为输出的长度不一样。生成模型每次写出来的字数都不同，而输出是按量计价的。如果你需要费用稳定可预期，可以在请求里限制最大输出长度，或者把任务拆细，让每次产出的大小相对可控。
账单比自己算的低，还要管吗？
值得花两分钟查一下口径。常见原因是自己按原价算、实际走了折扣分组，也可能是部分请求被缓存命中而没有全额计费。搞清楚原因，你才能知道下次估算成本时该按哪个数报给团队——估高了会吓退项目，估低了会超预算。