计量与结算

给你计费的那个数字，是上游厂商自己报的用量。下面所有机制的存在，都是为了保证进入结算的确实是那个数字。

三个数据来源

估算是启发式的——按字符类加权，不是厂商的 tokenizer。它只用来抓数量级上的荒谬值，所以容忍度给得很宽。

交叉核对

上报值与估算值在输入侧和输出侧分别比对。偏差超过 25% 会记到卖家的信誉上，但不改金额。

缓存读取算在输入侧，所以一次高缓存命中的会话不会被误判成偏差。

硬性封顶

这些是会改金额的：

• 输出按授权预算封顶。 每次派单都带一个签名过的预算，卖家不可能按超过授权的输出量计费。
• prompt 按网关自身估算的三倍封顶（或估算值 + 1,000 token，取较大者）。超出后四类计数按比例整体缩小，各类 token 之间的比例保持不变。

一个小请求被报成九百万 token，最终按封顶值计费，并在卖家记录上留下一条风控事件。

结算

每个请求一个数据库事务：

1. 捕获冻结

   捕获预先冻结的金额，差额退回你的可用余额。

2. 按实有资金封顶

   扣款永远不会超过「冻结 + 可用」，余额不可能变成负数。

3. 划账

   从你这边扣款；卖家的待结算加上成交价减 8% 手续费；手续费进平台账户。

4. 记账

   三条复式记账分录，合计必须为零。

5. 关单

   token 数、金额、手续费和延迟写入该请求；一条带唯一键的结算记录让重复扣款成为不可能。

事务失败会按退避策略重试——而且绝不会盲目重跑，因为那个唯一键让重复执行变成空操作，而不是第二次扣款。

自己对账

买卖两侧都保存本地流水，也都能拿去和服务端比。token 数应当一致。若不一致，以服务端的数字为准——本地流水是给你自己审计用的，不参与计费。

客户端和网站上的 记录 是同一批数据。