大模型 API 为什么这样定价？从 batch、KV cache 到长上下文成本

最近看了 Dwarkesh Patel 对 Reiner Pope 的访谈：

Reiner Pope – The math behind how LLMs are trained and served

Reiner Pope 是 MatX CEO，长期研究大模型训练、推理和底层硬件系统。这期节目很长，主题正好对应两个关键词：trained 和 served。

• 大模型是怎么被训练出来的；
• 大模型又是怎么被服务出来的。

这两个问题如果放在一篇里讲，会非常重。所以我准备拆成两篇来写。

第一篇，先讲 served：大模型 API 为什么这样定价？
第二篇，再讲 trained：大模型训练为什么这么贵？

这篇先讲第一部分：大模型是怎么被 served 出来的。说白了，就是一张推理账本。

API 价格表看起来是在给 token 定价，但背后其实藏着 batch、KV cache、prefill、decode、长上下文和缓存命中的成本结构。

【图表 1：API 定价背后的推理账本】

价格项	背后的系统成本
input token	prefill、上下文处理、KV cache 建立
output token	decode、逐 token 生成、持续占用推理资源
长上下文	更大的 KV cache、更高显存和带宽压力
batch	GPU 利用率、吞吐、延迟之间的平衡
cache read/write	避免重复 prefill，但需要缓存存储和管理

一、Token：API 计费的最小颗粒

Token 不是成本本身，但它是 API 计费里最容易被统计、也最容易被理解的颗粒。

严格说，token 不是算力单位。

同样 100 万 token，在不同模型大小、上下文长度、batch size、缓存命中率、硬件利用率下，成本可能完全不同。

但 API 服务必须找到一个能被用户理解、也能被系统统计的计费颗粒。Token 正好承担了这个角色。

对用户来说，token 对应输入和输出内容。

对服务商来说，token 背后对应 GPU 时间、显存占用、memory bandwidth、KV cache、调度、并发和稳定性。

所以 API 按 token 收费，不是简单“按字数收费”，而是把复杂的推理资源消耗，折算成一个可计量的业务单位。

但 token 只是计费入口，不是完整成本。继续往下看，还得先分清一件事：训练和推理不是同一本账。

二、先分清两本账：训练账本和推理账本

训练关注如何把模型造出来，推理关注如何把请求稳定服务出来。

训练阶段更像大型工程项目。它关心 batch size、GPU 利用率、分布式通信、checkpoint、故障恢复、训练失败后的重跑成本，以及大规模集群协同。

推理阶段更像长期在线服务。它关心请求分布、上下文长度、output token 数量、continuous batching、延迟、吞吐、KV cache 管理、高峰期排队和 SLA。

训练贵在一次性投入巨大。

推理贵在持续发生，而且每一次请求都会消耗资源。

一个模型训练完成，只是获得了能力。真正把能力变成服务，还要依赖后面的 serving stack。

【图表 2：训练 vs 推理账本对比】

对比项	训练	推理
目标	造模型	服务请求
成本结构	GPU 集群、数据、训练时间	GPU 时间、显存、带宽、并发、缓存
关键指标	GPU 利用率、训练吞吐、失败重跑	延迟、吞吐、每百万 token 成本
常见瓶颈	通信、checkpoint、调度	KV cache、batch、长上下文、并发

这篇文章聚焦的是 served，也就是推理账本。而推理账本里，第一个绕不开的变量，就是 batch。

三、Batch：单位 token 成本是怎么被摊薄的

Batch 可以摊薄部分计算和权重读取成本，提高 GPU 利用率，但它会和延迟发生冲突。

Reiner Pope 在访谈里反复提到 batch size。

在推理服务里，batch 不是简单把请求“排队堆起来”，而是把多个正在生成的序列组织到一起，让一次 forward pass 服务更多 token。

如果 batch 太小，GPU 很容易吃不饱，单位 token 成本就高。

如果 batch 做得好，同一段 GPU 时间里可以服务更多 token，吞吐提升，单位成本下降。

但 batch 不是越大越好。

batch 太大，等待时间会上升；请求长度差异太大，调度会变复杂；如果用户对延迟敏感，系统也不能只追求吞吐。

成熟的推理服务不是单纯“把 batch 拉大”，而是在吞吐、延迟和成本之间找平衡。

这也是为什么同样一张 GPU，不同平台跑出来的单位 token 成本可能差很多。差别不只在硬件，也在调度和 serving stack。

【图表 3：batch 与成本/延迟关系示意】

Batch 解决的是 GPU 利用率问题。但当上下文变长，另一个更棘手的成本会冒出来：KV cache。

四、KV Cache：长上下文真正贵在哪里

长上下文会扩大 KV cache，占用更多显存和 memory bandwidth，并降低并发能力。

很多人理解长上下文时，会把它看成“多输入一点文字”。

但在推理系统里，长上下文不是免费能力。

模型生成每一个新 token 时，都要参考历史上下文。这些历史上下文的中间状态，会形成 KV cache。

上下文越长，KV cache 越大。

KV cache 越大，就会带来几类成本：

• 显存占用上升
• memory bandwidth 压力上升
• 单卡可服务的并发请求下降
• 长文档、RAG、多轮对话成本上升

Reiner 在访谈里强调，长上下文的限制很多时候不只是 compute，而是 memory bandwidth 和 memory capacity。

这句话很关键。它解释了为什么一些模型“理论上支持很长上下文”，但真正在线服务时，长上下文依然会更贵、更慢、更难并发。

所以，长上下文不是“多看几页纸”。

它是在推理系统里占用显存和带宽。

【图表 4：KV cache 示意图】

KV cache 解释了长上下文为什么贵，也顺手解释了另一个常见现象：为什么 input token 和 output token 往往不是一个价。

五、Prefill 和 Decode：input/output 不同价的底层原因

Prefill 和 decode 是两类 workload，成本结构不同。

输入阶段通常叫 prefill。

模型一次性处理 prompt、系统提示词、历史对话、文档上下文，并建立对应的 KV cache。

输出阶段叫 decode。

模型一个 token 一个 token 生成答案。每生成一个新 token，都要读取模型权重和已有上下文状态，再推进到下一个 token。

Prefill 更容易并行化，计算密度通常更高。

Decode 是逐 token 推进，对延迟更敏感，也更容易受 memory bandwidth 和 batch 调度影响。

所以很多 API 会把 input（输入） token 和 output（输出） token 分开计价。在不少价格表里，output token 往往比 input token 更贵。

这不是因为“生成文字更高级”，而是因为 decode 阶段更像持续占用推理产线。

当然，这不是所有平台都必须遵守的定律。具体价格还会受模型、硬件、商业策略和竞争环境影响。但从系统角度看，input/output 分开计价是合理的。

【图表 5：prefill vs decode】

阶段	处理内容	成本特点
Prefill	输入 prompt、上下文、历史对话	可并行处理，建立 KV cache
Decode	逐 token 生成输出	持续占用推理资源，对带宽和延迟敏感

理解了 prefill 和 decode，再回头看 API 价格表里的长上下文分档，就没那么神秘了。

六、长上下文分档：价格表里的系统瓶颈

价格分档通常反映了长上下文带来的资源压力，但不能简单等同于厂商真实成本表。

一些 API 价格表会在上下文长度超过某个阈值后进入更高档位。

这背后的工程逻辑比较清楚：

• 上下文越长，KV cache 越大；
• KV cache 越大，显存和带宽压力越高；
• 同一张卡能服务的并发就越少；
• 服务商需要把这部分成本反映到价格里。

但这里要注意，API 价格不是纯工程账本。

价格里还包含商业策略、SLA、竞争、补贴、客户分层和毛利设计。

所以我们不能说“价格分档精确等于某个硬件成本”。

更稳的说法是：

价格分档说明长上下文会真实改变推理系统的资源账本。

当一个模型宣传支持超长上下文时，真正要问的不是“最长支持多少”，而是：

• 多长之后会变慢？
• 多长之后会变贵？
• 高并发下还能不能稳定？
• cache 能不能命中？

这些问题，比单纯看 context window 数字更重要。

不过，长上下文也不是完全没有优化空间。缓存，就是服务商常用的一种降本方式。

七、Prompt Cache：缓存命中为什么能省钱

Cache hit 避免了重复 prefill 或 KV 重算，但缓存本身也有写入、读取和保留成本。

现在很多 API 都支持 prompt cache 或 prefix cache。

它的核心逻辑是：如果多个请求共享同一段系统提示词、文档前缀、历史上下文或固定 prompt，系统可以把已经计算过的部分缓存起来。

后续请求命中缓存，就不需要完整重算。

所以 cache read 通常会比重新输入便宜。

但缓存不是免费魔法。

它有 cache write 成本，也有 cache read 成本；缓存保留时间越长，占用资源越久；如果 cache miss，仍然要重新计算。

Anthropic 的 prompt caching 文档里，就把 cache write、cache read 和缓存保留时间分开说明。

这说明一个很现实的问题：

缓存便宜，不是平台“让利”，而是系统少做了一部分重复计算。

对于长文档、多轮对话、固定系统提示词、Agent 工作流来说，cache hit rate 会直接影响最终账单。

【图表 6：cache write / cache read】

动作	含义
Cache write	第一次写入缓存，需要计算并保存
Cache read	后续读取缓存，避免重复计算
Cache miss	没命中缓存，需要重新计算
Cache duration	缓存保留时间，越久越占资源

到这里再看 API 价格表，它就不再只是一张报价单，而更像一张 serving stack 的能力清单。

八、API 价格表：不只是模型报价，而是 serving stack 报价

价格表不只是模型报价，它也在反映 serving stack 的能力。

一个 API 价格背后，不只是模型本身。

它还包括 GPU 类型、batch 调度能力、KV cache 管理、长上下文支持、prompt cache / prefix cache、并发能力、SLA、失败重试、路由和限流。

所以同一个模型，在不同平台上价格、延迟和稳定性可能完全不同。

因为你买到的不是一个“模型名字”。

你买到的是模型加上一整套推理系统。

如果只看每百万 token 单价，很容易忽略真实业务里的隐性成本。

更值得看的，是这套服务在你的场景下能不能稳定、可控、可预测地跑起来。

所以真正读 API 价格表时，不要只盯着“每百万 token 多少钱”，还要看下面这些问题。

九、最后，看价格表别只看单价

不要只看单价，要看这套价格是否覆盖你的真实使用场景。

要看什么	为什么重要
input/output 是否分开计价	两者成本结构不同
长上下文是否分档	影响显存、带宽和并发
是否支持 prompt cache	影响重复上下文成本
cache read/write 怎么算	决定缓存是否真省钱
是否限速/限并发	影响生产可用性
是否有 batch API	影响大批量任务成本
是否承诺延迟和吞吐	影响线上体验

真正重要的不是“单价看起来便宜”。

而是这套推理服务放到你的业务里，最终账本是否可控。

写在最后

回到最开始的问题：大模型 API 为什么按 token 收费？

因为 token 是最适合被计量的推理资源入口。

但 token 背后，不只是文字。

它背后有 batch，有 KV cache，有 prefill 和 decode，有 prompt cache，也有长上下文带来的显存和带宽压力。

所以，大模型 API 的价格表，看起来是在给 token 定价。

实际上，它是在给一整套推理系统定价。

下次再看到一张 API 价格表，不妨别急着只看单价。

先问一句：

这背后的 batch、KV cache、长上下文和缓存账本，是怎么算的？