5 计量链路

5.1 两条链路

市场常把 token 说成 AI 时代的电量，这个类比只对了一半。电表后的千瓦时在相同规格下高度可比，而一个 token 的计算成本、语义价值和用户体验，会随模型、分词器、上下文、输入输出比例、缓存、批处理与服务等级变化。token 能成为计量接口，却不是天然同质的商品，这是全书商业分析的出发点。

一个 token 同时走两条链。技术链从原始文本开始，经过编码、模型计算、token 生成和流式返回；计量链从鉴权后的请求开始，记录模型、输入 token、缓存命中、输出 token、错误和完成原因，最后形成账单。两条链在使用记录处会合。这一步很关键：模型已经生成过的 token 不一定都可计费，连接中断、内容过滤、服务器错误、客户取消和重试都可能改变最终口径；反过来，客户没在屏幕上看到的部分，也可能已经消耗了输入、缓存写入或工具调用。合同如果只写按 token 计费，仍然没有定义账单。

当前公开价格已经体现这种差异：Google、Anthropic、AWS Bedrock 与 OpenAI 的官方价格页分别对输入、输出、缓存、批处理设置不同费率，而不是给一个跨模型统一的 token 单价。核比较供应商价格前，必须用目标模型的计数规则重算，不能拿字符数或另一个模型的账单代替。

5.2 四层条件

一个可售 token 至少依赖四层条件，缺一层，卖的就不是完整产品。

5.3 计量反馈

计价规则会反过来改变客户行为。缓存输入更便宜，客户会尝试复用前缀；批处理有折扣，非实时任务会被迁移到批量接口；输出 token 更贵，应用会限制最大输出。这是价格的直接效果。间接效果发生在系统端：负载迁移后，缓存命中、到达节奏和长短请求分布改变，原来用来定价的容量模型也跟着变。供应商如果只看总 token 增长，可能误以为需求变强，实际却是重试、冗长输出或路由回退在增加。计量必须能区分有价值的业务增长和系统浪费，这个要求会在第 28 章落成合同条款。

5.4 三个分母

厂商喜欢把 token 吞吐当成产出规模来讲，但 token 数量不等于质量、客户价值或利润。同样数量的 token，可能来自高价值企业任务，也可能来自测试、失败重试或低价批处理。专业的算法是同时保留三个分母：生成的 token、满足服务目标的可计费 token、已经回款的 token 收入。只有三者能够对账，token 才能成为产品单位。这三个分母会贯穿第 26 章的单位经济和第 40 章的主张核验。

5.5 账务实现

计量口径写在合同里，实现落在三条日志上。对不上账的项目，问题几乎都出在这三条日志不同源。

幂等是第一件要做的事。重试、超时重发和网络抖动会让同一次调用产生多条事件。每个计费事件要带请求级唯一键，账单系统按键去重，不按时间窗口去重。按时间窗口去重的系统，在高并发和跨可用区场景下必然重复计费。

漏记比多记更难发现。多记会被客户投诉出来，漏记只有自己对账才看得见。要同时准备当期补记和跨期冲正两条路径，并规定冲正只新增反向记录，不修改历史行。历史行一旦可改，账单就失去了审计价值。

对账分两个频率。日对账查数量差，发现的多半是系统问题：事件丢失、去重失效、时钟漂移。月对账查金额差，发现的多半是配置问题：价格表版本、阶梯折扣、承诺量抵扣。两个频率查的不是同一类故障，缺一个就会长期带病运行。

客户要能自己复核。账单至少支持按请求 ID 抽样回溯到用量事件，并能导出指定周期的明细。做不到这一点，任何计量争议最后都会按客户的数字结算，因为我方拿不出可核的另一份。