DeepSeek把KV缓存放上SSD，首token快26倍，前提是提示词一个字都别动

DeepSeek又开源了一个推理栈，DeepInfer。它解决的是大模型服务里最容易被忽略的一段等待：请求重复了很长的前缀，比如系统提示、工具定义、前几轮对话，服务器能不能直接复用已经算过的KV缓存，不再跑一遍prefill。

官方给出的数字很直接。128K token的提示词命中缓存后，首token从13秒降到500ms。去年某一天的生产流量里，56%的输入token直接从磁盘读出来。

硬盘在请求路径上通常是被嫌弃的角色。GPU显存不够快、不够大，才会考虑把KV缓存放到别处。DeepSeek偏把缓存放上SSD，还让它在主流程里工作。

为什么通常不敢放磁盘

LLM生成前要先读完整段提示词，给每一层、每个token算key和value。这就是prefill。长提示词下，prefill是最慢的部分。

很多请求开头完全一样。聊天会把历史一轮轮重发，agent每次调用都带着同一套系统提示和工具说明。如果这些KV存下来，下一次只算新增token就行。

问题是KV缓存很大。标准模型上，长提示词的KV能到几十GB。从磁盘读这么多数据，可能比在GPU上重算还慢。所以推理引擎一般把KV放显存，显存又小，旧前缀很快被挤掉，重复请求经常落空。

DeepSeek把缓存压小，再把读取摊宽

DeepSeek-V2引入MLA，Multi-head Latent Attention。它不再给每个注意力头存独立KV，而是每个token每层存一个压缩后的潜向量，注意力计算时再重建key和value。V2论文里，这一步把KV缓存相对早前67B模型减少了93.3%。

缓存小了，才有资格放磁盘。每个命中token要读的字节少了，从SSD加载就可能比重新算更快。

单块SSD还是不够。缓存放在DeepSeek自研的分布式文件系统3FS上。3FS把文件切块，分散到多台存储节点的上千块SSD。读取时并行拉取，带宽叠加。请求进来后，系统用前缀匹配缓存块，从3FS读到主机内存，再逐层拷到GPU，同时模型已经开始跑。每台prefill机器都能访问所有缓存前缀，请求不必回到上次服务它的那台机器。

Avi Chawla在推文里提到，缓存前缀对agent流量保留3天，对聊天保留7天。deepseek-flash上缓存命中的价格比未命中低50倍。有网友问SSD缓存能否跨重启保留，Avi回复说会，KV块放在独立的3FS存储集群，和GPU机器分开，引擎重启或重新部署不会动它。

命中条件比想象中苛刻

这套机制只认从第一个token开始的精确匹配。系统提示、工具定义、文档这些稳定内容要放在最前面，时间戳、请求ID、用户名这些变量放最后。有人只是在系统提示里加了一个时间戳，后面所有块都失效。工具schema顺序变了，也会让整个缓存作废。

另一个容易踩的点是历史总结。总结会重写前缀，下一次调用按冷token全价算。截断工具输出、保持前缀字节一致，缓存才能活着。要确认两个提示词到底从哪里开始分叉，比较token ID比看日志文本可靠。BOS token、末尾换行、重新序列化的工具schema，都可能在肉眼看不见的地方改变匹配。

Avi Chawla的长文把LLM服务里的缓存拆成四层，容易混在一起：

KV缓存：单个请求内保存注意力张量，请求结束就释放。
前缀缓存：请求结束后把KV块留在服务器，按token ID的哈希链索引，后来的请求可以查。
提示词缓存：云厂商把前缀复用做成计费项，写入收溢价，读取打折。
语义缓存：把请求转成embedding，做相似度搜索，命中后直接返回存好的回答。

前三种是精确匹配，输出不变，只省计算。语义缓存是模糊匹配，命中可能给你一个错误答案，还带着200状态码返回。有网友在回复里说，语义缓存最容易出问题的是时效性。同一个问题隔四小时问，正确答案已经变了，embedding看不出区别。还有人说，带状态查询的工具调用没法用语义缓存。Artem Tarasov的回复更直接：前三种透明，语义缓存是唯一可能给出不同答案的，把它们混在一起谈，容易上线时才发现没有评测。

这套方案能不能搬到普通模型

有网友问，这套东西能不能移植到普通MHA模型，还是只因为MLA先把缓存压小了才成立。关键在两个条件：KV缓存足够小，存储足够宽。MLA解决前者，3FS解决后者。普通模型如果KV缓存仍然很大，单次命中要读的字节太多，磁盘延迟就会重新变成瓶颈。

DeepSeek这次开源DeepInfer，把推理栈里的缓存路径摊开给人看。它没有改变模型能力，只是把重复计算的钱和时间省下来。对agent和长系统提示场景，这种节省很实际。对提示词天天改开头的人，26倍加速基本停留在论文和推文里。

参考来源：Avi Chawla的推文和长文 https://x.com/_avichawla/status/2115400590960599112 ，以及LMCache项目 https://github.com/LMCache/LMCache 。