token 成本核算（token cost） 产品与架构

它是什么

token 成本核算（token cost）指把模型调用的 token 用量 × 单价折算成金钱。与「算 token 数」不同，它乘以的单价是非均匀的：输入与输出不同价（输出通常贵好几倍，因为生成比读贵）、命中 prompt-cache 的输入部分按折扣价计费。供应商按「每百万 token」报价，第 20 章的单价模型默认是输入 $3、输出 $15、缓存命中输入 $0.3——输出贵 5 倍、缓存只有输入价的一折。

计费公式与派生指标

单次调用成本拆成三段：

const cached = Math.min(usage.cachedTokens ?? 0, input);
return (input - cached) * prices.inputPerMillion / 1_000_000
     + cached * prices.cachedInputPerMillion / 1_000_000
     + output * prices.outputPerMillion / 1_000_000;

派生的还有 cacheSavings（命中 token × 输入价与缓存价之差，即「cache 经济学」直接省下的钱）与 sessionBill（一次会话所有调用逐行列出、累计成 totals）。GET /costs/<sessionId> 就返回这个账单。

一个诚实的坑：协议可见用量只是下界

第 15 章的协议只在 done 上带 usage，且只带最后一轮 LLM 调用的用量——中间轮次的 token 在协议里根本没出现过。按 trace 核算的成本是「协议可见用量」的下界，不是精确账单。要精确，三条路：a) 在 provider 层按调用记账（响应里本来就有 usage）；b) 流式响应用 stream_options.include_usage；c) 扩展协议给每次 LLM 调用一个事件。记账的精度取决于协议能带出多少数据——这是设计事件协议时就要想好的事。

小结

成本核算让「贵不贵」从感觉变成数字，但它只是可观测性的派生指标：数据源是 trace 里累计的 usage，单价是配置（换模型改配置即可，不硬编码），生产里真正的成本控制还要靠预算熔断（TOKEN_BUDGET）与缓存优化。