api 充值 预扣 和 结算 差在哪

很多人充完值发现余额掉得比预期快，过一阵又好像退回来一点；也有人月末对账单，发现账单金额和余额变化对不上。多半不是平台算错，而是你把预扣和结算当成了同一笔。这篇把两者的区别、常见差异来源和排查顺序讲清楚，方便你下次对账时按步骤走。

很多人充完值发现余额掉得比预期快，过一阵又好像退回来一点；也有人月末对账单，发现账单金额和余额变化对不上。这种时候先别急着怀疑平台算错，大概率是你把预扣和结算当成了同一笔账。它们一个发生在请求发出前，一个发生在响应结束后，中间隔着一段冻结期，余额在这段时间里是会变的。

这篇不聊计费公式，只讲怎么把这两次记账分开看，以及钱对不上时按什么顺序排查。看完你至少能判断：某个差额是正常的估算误差，还是真该提工单。具体费率数字别在这猜，去站内对应页面看当时的数。

预扣和结算分别记的是什么账

预扣是请求发出那一刻，平台先按你能消耗的上限冻结一笔额度。它的目的很单纯：防止你超额调用之后收不回钱。结算则是响应彻底结束后，按这次请求真实产生的用量，把冻结的那笔改成实扣。两次记账的金额来源不一样，一个是估，一个是算。

预扣

按请求参数里的上限估算并冻结，不代表最终花费

结算

按响应实际用量实扣，最终以它为准

冻结期

预扣到结算之间，余额被占住但还没真正划走

估算口径通常是看你设的 max tokens 或输入长度，流式响应和带工具调用的请求会让预扣更保守，因为平台没法提前知道你会生成多少。所以预扣偏大是常态，结算偏小也正常。但有一条要注意：不是所有计费方式都走预扣。

• 按次计费的接口，一般直接记一次调用，不冻结额度
• 订阅额度或包月套餐内的调用，扣的是额度表不是现金余额
• 后付费账户可能压根不冻结，账单出来时才记一笔
• 以上几种情况余额不动，但用量照样会记进日志

为什么预扣数和结算数对不上

最常见的差异来源是估算口径和真实用量的天然落差。预扣看的是你填的上限，真实用量看的是实际生成了多少 token。模型提前停、命中缓存、被限速截断，任何一种都会让结算小于预扣，于是你看到余额先掉一截再回一点。

另一个容易忽略的点是：倍率、缓存价、输入输出分开计价这些规则，通常不在预扣里体现，只在结算时按当时规则算。想知道某家厂商具体怎么分价、怎么算倍率，到站内 /official-api 页面核对当时的说明，别拿旧记忆套。

对账按这个顺序走

对账最怕一上来就逐笔核对，几十上百条记录对到眼花还找不出问题。正确做法是从粗到细：先确认口径，再对总差额，最后才定位异常单笔。下面这个顺序照着走就行。

1. 拉齐用量日志字段把请求 ID、输入输出 token、缓存命中、时间戳这几列凑齐。字段不全就先到站内 /usage 对照真实用量榜的口径，弄明白哪些维度是平台认的。
2. 三份数据放一起对总额同一时间段的充值记录、余额变动流水、账单三份并排，只对总差额。总差很小就收工，别为几分钱较劲。
3. 总差持续放大再往下查如果差值不是随机波动而是稳步增长，按站内 /providers 找到对应厂商页面，核对计费规则和账户类型，再决定是提工单还是改调用方式。
4. 定位到单笔时看解冻某笔大额异常别急着下结论，先看它是不是卡在预扣没解冻。失败请求是否退出预扣，各平台处理不一致，这是最常见的误会。

哪些情况你会看不到预扣

如果你的账户压根看不到预扣动作，不代表平台没记账，可能只是你的计费模式不经过这个环节。先搞清自己属于哪种，再谈对账。

• 后付费或月结账户：账单出的时候才记一笔，余额没有参考价值
• 订阅制或套餐内调用：扣的是套餐额度，要看额度消耗表而不是现金余额
• 企业协议或定制结算：规则跟公开页面不一样，以合同为准
• 免费额度或试用额度：消耗走的是额度池，不影响充值余额

判断标准很简单：如果你连续几次调用余额纹丝不动，但用量日志在涨，那基本就是走了非预扣路径。这种情况下对账的对象应该换成额度表或账单，而不是充值余额。分清对象，能省掉大半困惑。