第 14 章 — Token 经济学与 API 定价

发布于: 2026-05-06 最后更新于: 2026-07-08 版本: 1
第 14 章 — Token 经济学与 API 定价

第 14 章 — Token 经济学与 API 定价

LLM Primer VI: Scaling AI Systems》章节走读的第十四篇。这一章把第 1 章的物理学连到账单上的分项 —— 并解释为什么第一个月的账单往往和团队一开始设想的对不上。


这一章为什么存在

前面几章把推理成本当作物理事实来处理 —— HBM 上搬多少字节、matmul 花多少 FLOPs、GPU 秒被一个请求消耗多少。对拥有硅片的团队,这份框架是对的。而对更庞大的"从 API 买推理"的团队群体,成本表面被供应商计费的那个单位重塑成了 —— token。第 14 章讲的是为什么 token 被这样定价、为什么同一次调用的输入和输出侧价格差得那么远,以及一段 chat 对话历史和一个 reasoning 模型看不见的"思考"是怎么悄悄爬上账单的。

一句话:Token 被定价,是因为它几乎线性对应供应商花的算力,但输入 token 和输出 token 是两个不同的成本对象,把它们当成一个的团队会踩坑。

14.1 输出比输入贵 4–8 倍,因为 decoding 是那个带宽受限阶段

一个输入 token 走 prefill 那条路 —— 稠密、compute-bound、对 prompt 所有位置并行,正好是 GPU 被设计来处理的工作负载。70B 模型上 H100 每秒能吃几万个输入 token,因为运算是一次算术强度高的宽 matmul。一个输出 token 走 decode 那条路 —— 顺序、memory-bandwidth-bound、每次前向传播一个 token、每一步都从 HBM 读整个 KV cache。同一块 H100 每请求每秒产出 50–100 个输出 token。两种吞吐率之间的比值,就是价格表反映的比值。2025 年前沿模型收每百万输入 token 两到五美元、每百万输出 token 十到三十美元 —— 4:1 到 8:1 的不对称,不是利润率选择,而是底层算力不对称的直接传导。缓存过的输入更便宜,因为 prefill 的钱供应商在上一次请求就付过了。批量 API 半价,因为供应商能把工作调度进空闲容量窗口。Reasoning token 之所以按输出计费,因为它在 engine 里就是输出。

14.2 优化杠杆看输入/输出的形状

常见错误是用一个心智数字来建模成本 —— "token 每个 X 美元" —— 而不是把输入和输出分开分解。一个检索重的客服分诊系统,发 8,500 输入 token、收 600 输出 token,在前沿定价下由输入成本主导(每天 1 万请求大约 $255 输入、$90 输出)。同样量下的长稿撰写系统 —— 2,200 输入 token 进、3,000 输出 token 出 —— 由输出主导($66 输入、$450 输出)。两个例子的优化建议是相反的:第一个缩 prompt,第二个缩回答,并把请求路由到定价画像在主导轴上更友好的模型。第二种值得跑的分解是按租户或工作负载。多租户系统几乎总能看到幂律分布 —— 前 10% 租户占开销的一半或更多 —— 针对这些租户做的成本优化,回报比在长尾里均匀投入高好几倍。

14.3 上下文累积和看不见的 reasoning token 放大账单

最贵的 token 是团队忘了自己在发的那个。API 是无状态的;每一次请求都把完整对话历史当输入寄一遍。N 轮对话累计的输入成本随 N 二次方增长,再减去前缀缓存那份抵扣。一支在单轮基线上定的价的团队,六个月后会发现自己平均对话是八轮,单场对话输入成本按平方倍数增长了。第二个隐形放大器是 reasoning token。o1/o3、Anthropic 的 extended thinking、DeepSeek R1、Google 的 reasoning 变体这类模型,在可见回答之前会产生大量内部思考 —— 一段 500 token 的可见回答背后往往有 4,000–8,000 token 的思考。这些 token 走同一条输出 decode 循环,按输出计费;除非代码要求,不然它们不返回给调用者。补救办法是把 API 响应的 usage 对象好好埋点 —— prompt_tokenscached_prompt_tokenscompletion_tokensreasoning_tokens、以及供应商特定的类别 —— 遇到没见过的类别报错,而不是悄悄丢掉。供应商每加一个计费维度,团队的 usage schema 都得跟上,否则下一张账单就是意外。

值得记住:只写"输入 token""输出 token"的 usage 埋点 schema,是那种会默默吸收供应商每一个新计费类别的 schema。每一个披露出来的维度分开记、没见过的报错、每一个季度重新分解一次成本。

第 14 章为下面铺了什么

团队一旦能按"输入对输出、按租户、按类别"三个维度读自己的账单,财务下一个会问的自然问题是:是不是就该按 token 付钱?第 15 章走替代方案:把推理搬进来、租或买 GPU、按 GPU 小时付。盈亏平衡算术很干净。真正不那么干净、也是大多数团队低估的,是自建这一侧账本上不出现在 GPU 账单里的一切:平台工程、安全补丁、模型升级编排、一个节点从 fleet 里掉出来时接电话的 on-call 轮值。


下一章 — 第 15 章:Serverless API 对比自建基础设施盈亏平衡的公式、那个隐藏的分项,以及"两者都要"才是对的答案的那些混合姿态。

想看完整的全貌?书里这一章包括能跑的 TokenPricingUsageRecord dataclass、把二次方量化的累计对话成本函数、"agent 长大了"的日成本例子,以及关于"输出为什么更贵"和"计价表在没人看时怎么跑"的两份 In Plain English 边栏。在 Amazon 上查看 LLM Primer VI →

下田 昌平
下田 昌平
作为株式会社Receipt Roller的CEO兼CTO,目前负责开发电子收据服务以及自动将对话分类并生成行动任务的系统「ACTIONBRIDGE」。从小便接触编程,1996年参与开发测量仪器的相关程序,始终保持着对技术的深刻探索与热情。 在此前的职业生涯中,曾担任日本最大呼叫中心行业企业的子公司——一家研究开发公司的CEO/CTO,领导了多个技术开发项目。目前,我依然活跃在编程的最前沿,持续书写代码。