同样的 token，一行按 1 元计费，一行按 2 分钱计费。断层线的两边，一边是重新算一遍，一边是直接复用
同一个 token，两种价格。中间隔着一个技术名词。
DeepSeek 的 API 有个不太起眼的设计：每次响应的 usage 段里，输入 token 被拆成两行。一行叫 prompt_cache_hit_tokens，一行叫 prompt_cache_miss_tokens。
不信可以现在就试。打开终端，随便发起一次多轮对话，翻到响应末尾。第一轮请求，第二行是满的，第一行是零。第二轮请求，第一行突然跳到几万——上一轮发过的输入，这次全部变成了"命中"。
这两行字对应两个价格。按 2026 年 9 月 10 日生效的 V4.1 Flash 定价，闲时的缓存命中输入是 0.02 元/百万 token，未命中输入是 1 元/百万 token。同样一个 token，两种命运，价差 50 倍。
50 倍不是促销。它是大模型推理成本结构里一道真实的断层线，断层两边，一边是"重新算一遍"，一边是"直接复用"。
分界线就是这篇文章的主角：KV Cache。讲三件事：它是什么，它怎么决定你的账单，以及 DeepSeek 凭什么把命中率做那么高——高到敢把命中价打到 2 分钱。
答案是一本账。这本账叫 KV Cache。
从一次对话的内部说起。模型生成文字的方式叫自回归：一次只吐一个 token，吐完这个，再决定下一个。你看到模型"流式输出"的背后，是几十次、几百次这样的循环。
每个新 token 诞生前，都要做一次注意力计算：回头看清前面所有的历史 token，再决定说什么。"看清"这个动作，需要用到历史 token 身上的两个向量——键（Key）和值（Value）。
麻烦在于，K 和 V 不是现成的。每一轮生成时，每个 token 的 K、V 都要从原始表示算出来。如果每个新 token 都把全部历史重算一遍，生成第 1000 个字就要付 1000 倍历史的计算量，上下文一长，推理慢到没法用。
解法朴素得像记账：算过的就存起来。第一次算完每个 token 的 K 和 V，写进账本。之后每个新 token 只算自己的 K、V、Q，历史部分直接翻账本。
为什么账本里只有 K 和 V，没有 Q？查询向量（Query）的意思是"我现在想找什么"，只属于正在生成的这个 token，用完就扔。而 K 和 V 的意思是"我能提供什么"，后面每一个新 token 都要来查。一个像当天的报纸，一个像档案柜。
这本账换来了速度：生成一个字的成本，从"重算全部历史"降到"只算增量"。没有它，就没有能用的对话产品。
但天下没有免费的午餐。账本本身要占地方，而且每个 token 都要记、每一层都要记。这本账有多能吃，下一章算给你看。
三条路径：占显存、重计算、吃带宽。
先算一笔账，用早期标准多头注意力（MHA）模型的公开配置。
一个 7B 级别的模型，典型是 32 层、32 个注意力头、128 维。每个 token 在每层要存 K、V 各 32×128 个数，乘上层数，全模型算下来，一个 token 约 26 万个元素，半精度下是 512KB。
512KB 一个 token，听着不多。把上下文拉到 10 万 token——长文档分析、Agent 任务现在动辄这个量级——单个请求的账本就是 50GB。这个 7B 模型自己的权重才 14GB 左右。账本比脑子还重 3 倍多。
所以后来有了 GQA：让多个注意力头共享同一套 K/V，账本压薄几倍。但方向没变——账本必须驻留在显存里，显存就那么大。
这就是 KV Cache 影响成本的第一条路径：占显存。推理服务器真正贵的是 HBM 显存，账本占得越多，能同时装下的请求越少，batch 上不去，每个 token 摊到的成本就下不来。
第二条路径更隐蔽：重复计算。多轮对话的规矩，是每一轮都把完整历史重发一遍。第二轮的输入等于 system prompt 加第一轮全部内容再加新问题。其中一大块，上一轮刚算完，K 和 V 还躺在显存里，这一轮却要再算一遍。这个"读题"阶段业内叫预填充（prefill），会话越长，重复浪费越大。
第三条路径藏在解码阶段。每生成一个 token，都要把整本账从头翻到尾。上下文 10 万，生成 1000 个字，就是 1000 次"翻 10 万页"。账越厚，翻页的带宽开销越大，生成速度越慢。
三条路径叠在一起，长上下文推理自然就贵。
于是有人问了个朴素的问题：模型权重训练完就不变了，同样的前缀算出来的 K/V 永远一样——为什么要算第二遍？
把算好的缓存留在磁盘上，下次直接复用。这就是上下文缓存（Context Caching）。对用户是五折再五折的折扣，对厂商是实打实省下的算力。问题只剩一个：什么样的请求算"命中"？
规则只有一条：前缀精确匹配。
规则比很多人想的严格。DeepSeek 的缓存以 64 个 token 为最小存储单元，新请求进来，系统拿它的开头和过往请求的缓存逐段比对：相同的前缀部分算命中，按缓存价计费；从第一个不同的 token 起，全部按全价。中间有重复段落没用——必须从头连续一致。
看一个具体场景。客服 Agent 的 system prompt 里写着公司制度、退换货规则、产品参数，共 3 万 token。第一轮用户问"怎么退款"：输入全是新内容，零命中。第二轮用户追问"运费谁出"：输入变成 system prompt 加第一轮完整对话加新问题，前面 3 万多 token 和上一轮一字不差——命中。真正按全价计费的，只有新问题那几十个 token。
为什么命中可以便宜 50 倍？因为厂商的边际成本变了。未命中的 token 要跑完整的预填充：GPU 逐层算注意力、算 FFN，卡时和电都是钱。命中的 token 只需要把磁盘上的缓存搬回显存。搬运比计算便宜两个数量级，定价就敢差一个数量级再拐个弯。
厂商在拼命把命中价往下打，逻辑也在这里：省下的是自己的算力，让出去的是用户留存的理由。今年 4 月 26 日，DeepSeek 把全系 API 的缓存命中价格直接砍到原价的十分之一；9 月 10 日的 Flash 新价，闲时命中 0.02 元、未命中 1 元。两次调价说的是同一句话：命中越多，越便宜。
| V4.1 Flash 计费项 | 旧价·闲时 | 新价·闲时 | 新价·高峰 |
|---|---|---|---|
| 输入（缓存命中） | 0.05 | 0.02 | 0.04 |
| 输入（缓存未命中） | 1.5 | 1 | 2 |
| 输出 | 4.5 | 4 | 8 |
单位：元/百万 token。高峰时段为工作日 9:00-12:00、14:00-18:00，其余为闲时，闲时价格是高峰的一半。无论峰谷，命中与未命中的价差都是 50 倍。
什么场景天然高命中：多轮对话、固定的 system prompt、RAG 里反复引用同一批文档、Agent 带着滚动历史跑长任务、few-shot 的固定示例。
什么操作会毁掉命中率：把动态内容放进前缀。设想一个场景——运维同学为了"让模型知道日期"，往 system prompt 开头加了一行"今天是 2026 年 9 月 19 日"。就这一行，每个请求的前缀从第一个字符就不同，3 万 token 的固定指令全部按全价。删掉这行，把日期挪到末尾或者交给工具注入，命中率当天回来。
一个立刻能用的原则：静态内容放前面，动态内容放后面。文档在前、问题在后；人设在前、请求在后。让不变的部分尽可能长地充当前缀。
三层答案：存得起、留得住、送得到。
从 V2 开始，DeepSeek 用 MLA（多头潜在注意力）替代标准注意力。思路：不存完整的 K 和 V，存一个低秩压缩的潜在向量，注意力计算时再投影还原。落到 V3 的公开配置，每 token 每层只存 512 加 64 共 576 个元素——对照上一章 MHA 的 8192，薄了一个数量级。
| 注意力机制 | 每 token 每层缓存（元素） | 说明 |
|---|---|---|
| MHA | 8192 | 32 头 × 128 维 × K/V，7B 级典型 |
| GQA | 2048 | 8 组共享 KV，70B 级典型 |
| MLA | 576 | 512 潜在向量 + 64 rope 分量 |
一个 671B 参数的模型，每个 token 的账本反而比 7B 的 MHA 模型还小 7 倍。到 V4.1 Flash，官方给的数字是：相对初代模型，KV Cache 缩小 437 倍，对 HBM 显存的需求降到四分之一，对 SSD 的需求降到八分之一。
账本薄带来什么？同样一块磁盘，能多存几百倍的上下文。库存越大，下一个请求匹配上的概率越高。命中率的第一因，是容量。
多数推理服务的 KV Cache 只活在显存里，请求一结束就清，显存一紧张就清。DeepSeek 把缓存放到了分布式 SSD 集群上。在 Hacker News 上，有人专门翻出他们开源的 3FS 文件系统：KVCache 就写在 README 的使用场景里，KVCache 客户端的单节点读取吞吐峰值能到 40 GiB/s 以上。磁盘池子比显存大几个数量级，也便宜几个数量级。
留得住意味着什么？用户下午聊到一半的会话，晚上接着聊，前缀还在缓存里。多轮对话越聊越长，命中率越聊越高。缓存和会话是共生关系。
缓存散落在几百台机器的磁盘上，新请求来了派给谁？DeepSeek 的调度会把前缀相同的请求，尽量派到已经持有这段缓存的节点上，而不是随机分配再跨机器拉取。命中率不只是存储问题，还是调度问题。
三层叠起来，就是敢把命中价打到 0.02 元的底气：MLA 让缓存小到存得起，SSD 集群让缓存大到留得住，调度让缓存近到送得到。厂商的边际成本逼近"搬数据的电费"，定价才有空间。
这也是为什么 Agent 时代各家都在卷缓存。Agent 一次任务几十轮调用，每一轮都带着完整历史，命中的费用占比极高。谁的缓存便宜，谁的 Agent 就跑得起。
架构决定下限，工程决定上限。
回头看那 50 倍价差，它不是营销话术，是三次设计的叠加：注意力架构决定缓存的体积，存储架构决定缓存的寿命，调度架构决定缓存的距离。架构决定成本下限，工程决定命中率上限。
对开发者，三件事今晚就能做。把 system prompt 里的动态内容挪到末尾；翻出 usage 里那两行字段，算一下自己的真实命中率，别靠感觉；长文档分析之前，考虑先花几分钱把缓存"焐热"。
账单上那两行字，从此不再是黑话。它是一道选择题：同样的 token，让它重新算一遍，还是复用已经算好的答案。
至于 0.02 元之后还能降到多少——往下看，剩下的就只有电费了。