@_avichawla：DeepSeek 又做到了！他们刚刚开源了 DeepInfer，这是其缓存命中时能返回首个 to… 的推理技术栈

DeepSeek 又做到了！ 他们刚刚开源了 DeepInfer，这套推理技术栈能让缓存命中时的首个 token 返回速度最高提升至 26 倍。 当请求重复使用一段较长的前缀，比如系统提示词或之前的聊天轮次时，服务器可以复用已经计算好的 KV 缓存，而不必重新执行预填充。 理想情况下，你会认为这些缓存应该放在 GPU 显存里，毕竟磁盘通常被认为太慢，无法用于请求处理链路。 但实际上，DeepSeek 把它们放在 SSD 上。 DeepSeek 推出这项功能时，一个包含 128K token 的提示词在命中缓存后，只需 500 毫秒就能返回首个 token，而原先需要 13 秒。 而在去年的某一天生产流量中，所有输入 token 里有 56% 直接由磁盘提供。 所以，只要存储的数据足够小，存储系统的并行带宽足够大，磁盘在这里就不是瓶颈。 让我们来了解一下它是如何工作的。 1) 为什么要复用 KV 缓存： 在生成任何内容之前，LLM 会读取整个提示词，并为每一层中的每个 token 计算一个键和一个值。这就是预填充，对于长提示词来说，这是最耗时的部分。 很多请求的开头都一样。 例如，聊天应用会重新发送之前的每一轮对话，或者智能体会在每次调用时重新发送相同的系统提示词和工具定义。 如果保存了这些 KV，下一个具有相同前缀的请求就可以加载它们，只计算新增的 token。 2) 为什么主要使用 GPU 显存： 每个 token 都要在每一层存储 KV，因此在常规模型中，长提示词的 KV 缓存会达到数 GB 甚至更多。 从磁盘读取这么多数据，可能比在 GPU 上重新计算还要慢。 所以，推理引擎会将它们保存在 GPU 显存中。但 GPU 显存容量有限，旧前缀很快就会被淘汰，许多重复请求也就无法命中缓存。 3) DeepSeek 缩小了 KV 缓存： DeepSeek-V2 引入了多头潜在注意力机制（Multi-head Latent Attention，MLA）。 MLA 不再为每个注意力头分别存储 KV，而是在每一层为每个 token 存储一个小型压缩向量，并在进行注意力计算时从中重建键和值。 根据 V2 论文，与 DeepSeek 此前的 67B 模型相比，这使 KV 缓存减少了 93.3%。 MLA 将 KV 缓存缩小到了可以存储在低成本磁盘上的程度。 每个缓存 token 占用的字节数更少，意味着每次命中时需要读取的数据也更少，从而使从 SSD 加载比重新计算更快。 4) 3FS 同时从多块 SSD 读取缓存： 单块 SSD 仍然太慢，因此缓存存储在 DeepSeek 自研的分布式文件系统 3FS 上。 3FS 将文件切分成数据块，分散存储在多个存储节点的数千块 SSD 上。一次读取会并行从多块硬盘获取数据块，从而汇聚它们的带宽。 请求到达时，系统会将其前缀与缓存块进行匹配，从 3FS 将这些块取到主机内存中，并在模型已经开始运行的同时，逐层将它们复制到 GPU。 而且，由于每台预填充机器都能访问所有已缓存的前缀，请求无需再回到上次为它提供服务的那台机器。 磁盘也很便宜，因此缓存可以保留数天。根据 DeepInfer 文档，智能体流量的前缀缓存保留 3 天，聊天流量的前缀缓存保留 7 天。 当 KV 缓存足够小、存储系统的并行带宽足够大时，磁盘缓存就能发挥作用。DeepSeek 通过注意力机制设计实现了前者，通过 3FS 实现了后者。 价格也体现了这一点。目前在 deepseek-flash 上，缓存命中的费用仅为未命中的 1/50。 如果你使用 API，请把提示词中固定不变的部分（系统提示词、工具、文档）放在最前面，因为只有从第一个 token 开始完全匹配，才算缓存命中。 下图展示了我们讨论的内容。 不过，前缀缓存只是 LLM 推理服务中使用的缓存之一。我最近写了一篇文章，介绍了全部四种缓存，并为每种都提供了代码。 请在下方阅读。