大模型APi 的输入输出缓存 Token 为什么价格不一样？

我之前一直很好奇，就是为什么各家大模型api 的定价都有这几个东西：输入费用、输出费用、以及缓存创建/读取。

这几个东西价格都不一样，之前一直好奇，但是没有深究过，今天就来深入了解一下。

输入和输出

你可以把大模型想成一个很奇怪的流水线。读一整段话的时候，它可以把很多 token 一起过一遍，像一批指令一起进流水线，铺开算。这一段叫 prefill。虽然输入很长，但它有个好处：能并行。

并行这两个字很值钱。GPU 最喜欢这种活。你一次给它 1000 个 token，它就把 1000 个 token 尽量同时处理，机器很忙，但忙得很整齐，吞吐也高。所以 input token 便宜，原因并不神秘：它们适合批量干。

但 output 不一样。

模型生成回答，不是把整段话一下写完。它是先猜下一个 token，再把这个 token 接到后面，再猜下一个。像一个人边写边看自己刚写下来的字。第 37 个字没出来，第 38 个字根本无从谈起。

这一下，并行性塌了。

输入像批处理，输出像单步调试。前者能把 GPU 塞满，后者必须一步一步来。每生成一个新 token，整套推理链路都得再走一遍，只是这次只为这一个 token 服务。串行，几乎总是比并行贵。

所以 output 贵，不是因为它更高级，而是因为它更别扭。机器得一直等上一步的结果，像工厂里最慢的那台机床拖住整条线。

如果每吐一个字，都要把前面整段上下文重新看一遍，那成本应该更离谱才对。现实里模型虽然贵，还没有贵到完全不能用。这里面一定有个地方被优化掉了。

这个地方就是 KV Cache。

缓存

KV Cache 这个词听起来很学术，其实骨子里特别朴素：前面已经算过的东西，别再算第二遍。

Transformer 里，每个 token 进去后，都会变成几份中间结果。里面最值得存下来的，是 Key 和 Value。你可以先不用管公式，粗暴一点理解：Key 像索引，Value 像正文。

后面新来的 token 要决定该关注谁，本质上就是拿着自己的 Query，去旧的 Key 里查，再把对应的 Value 拉出来参考。

关键在这儿：旧 token 没变，它们对应的 Key 和 Value 也就没变。

那你为什么还要重算呢？这不是浪费资源吗··

所以第一次算完，就把它们留在显存里。下一个 token 来的时候，只算它自己的那一份，再去读取前面缓存好的 K 和 V。这样一来，模型不需要每次从头回放整段历史，只要在旧缓存上继续往后长。

这很像聊天窗口上面那一大段历史，并不是每次回复都重新理解成一篇全新的文章。更像是进程已经把页表建好了，后面每次访存，直接查已有映射。

这就是为什么你会感觉到一种很具体的体验：第一个字慢，后面的字快。

第一个字出来之前，模型得先把你发来的整段输入完整跑一遍，把 KV Cache 热起来。这是最花时间的一下。等缓存建好，后面继续生成，就进入比较顺滑的 decode 阶段了。

所以首字延迟高，不一定是网卡，不一定是服务抖，更常见是：你的 prompt 太长，prefill 还没做完。

到这儿，定价的第二件事也顺了：为什么 cache hit 那么便宜？

因为 cache hit 有时候便宜得近乎离谱。它不是“少算一点”，而是“有一大段干脆不算”。

如果一段 system prompt、背景资料、长文档前缀已经缓存过，下一次请求又复用了它，服务端就不用重新做 prefill。直接把那段现成的 KV 拿出来接着用就行。

这不是优化语气词，这是优化电费。

普通 input token，厂商至少还得老老实实帮你算一遍。缓存命中的 token，很多计算被跳过，成本自然更低。它更像直接读出一段现成状态，而不是再跑一遍。

当然，缓存也不是白拿的。

KV Cache 最大的代价不是算力，是显存。你可以把它理解成大模型推理时最贵的工作内存。上下文越长，用户越多，要留着的 K 和 V 就越多。这个东西会吃掉大量显存，而且几乎是线性涨。你想支持更长上下文，或者更高并发，最后常常不是算不过来，而是放不下。

所以这件事特别有意思：KV Cache 一边让输出更快，一边又让系统更贵。它像缓存系统里最典型的交易：用空间换时间。只不过这里换掉的不是几毫秒，是一整套推理成本结构。

碎碎念，这也是为什么养龙虾🦞的时候，会觉得很废 Token 了，由于 OpenClaw 原生提示词的缺陷。龙虾的缓存命中率极低，这就导致输入token 费用很高hhh