KV Cache还能这么玩？这波操作惊艳到我了！

大家好，我是小林。

你调用大模型 API 的时候，有没有留意过「缓存命中」这个指标？

再翻一下价格表，你可能会发现，同一个模型，输入 token 还分两种价格，缓存命中和缓存未命中。命中的那部分，价格能便宜不少。

同样是把内容发给模型，怎么命中缓存就便宜了？背后到底省了什么？

你可以想一个场景。用 Agent 写代码时，每轮请求里往往都带着相同的系统提示词、工具说明，还有前面的对话记录。虽然这次问的问题变了，输入前面的一大段内容，可能和上次一模一样。

这些内容模型已经处理过了，下一次还要从头再算一遍吗？

这就轮到 KV Cache 出场了。

KV Cache 会保留模型处理历史内容时产生的一部分计算结果。你可以把它理解成一份「计算底稿」。下一轮请求的输入前缀匹配、也满足其他复用条件时，大模型服务就有机会直接用上这份底稿，省掉一部分重复计算。

图 1，重复输入命中缓存

所以，命中缓存后，模型仍然会继续计算、生成回答，只是处理输入时，有些活不用再干一次了。

不过，省下计算，也得付出另一份成本。模型在 GPU 上推理时，这份「底稿」需要占用显存，而显存的容量是有限的。

那这些缓存该往哪里存，又该留多久？对数据中心运营方来说，历史内容越长、请求越多，需要管理的缓存就越大。全留着，容量和成本吃不消。清掉吧，下次又可能得让 GPU 重算。

带着这个问题，我翻了些相关资料，发现 Intel 的 KV Cache 方案有个挺有意思的思路，让 CPU、内存和存储一起帮忙，把值得复用的结果留住，减少 GPU 的重复计算。

那这份「计算底稿」里到底存了什么，为什么 Agent 越忙，它就越大？我们先把这件事弄明白。

────01 ｜Agent 越忙，KV Cache 为什么越大？────

模型每生成一个新 token，都需要参考前面的内容。你想想，历史内容没变，相关计算每一步都从头做，岂不是白忙活？

那模型怎么参考前面的内容？在注意力计算中，模型会为 token 算出几组数字，分别叫 Q、K、V。简单理解，Q 表示当前要找什么，K 帮助匹配相关内容，V 提供对应的信息。

在常见的因果注意力模型中，历史 token 不会看到后来才出现的内容，所以已经算好的 K、V 不必每一步重算，可以留下来继续用。随着新 token 加入，再把新的 K、V 追加进去。

这些保存在模型各层的 K、V，就是 KV Cache。读取历史缓存、计算注意力和生成新 token，仍然需要计算。

图 2，KV 缓存追加

刚才说的是一次回答里怎么复用。那换到下一轮请求呢？如果输入前缀一致，模型和缓存状态也满足复用条件，这段 KV 就有机会接着用。这也就接上了开头说的 API 缓存命中。

这省下的是一部分重复 Prefill，也就是处理输入上下文的计算。模型服务提供方就有机会把省下的算力用于新请求，而用户也可能更早看到第一个 token，这段等待时间叫 TTFT。

图 3，前缀复用与首字等待

但别被「缓存」两个字骗了，它可不小。

Agent 每读入一段工具结果、多生成一段内容，上下文里就多了一批 token。这些 token 又会在模型的多层计算中留下各自的 K、V。模型结构和缓存精度固定时，要保留的上下文越长，缓存通常就越大。再叠加同时运行的会话，显存压力就上来了。

图 4，上下文增长与显存占用

有多大？按 Qwen3-8B 的结构，KV 使用 FP16 或 BF16 时，每个 token 对应约 147KB 的未压缩缓存。一万 token，光 KV 就约 1.47GB，还没算模型权重。

假设一款 AI 应用有 300 万日活，每人每天 10 次请求，每次按一万 token 计算。把每次请求对应的完整 KV 体积加起来，一天累计约 44PB。

图 5，单次请求到应用规模

先别急着买硬盘。这里把重复前缀也重复计入了，累计体积不等于每天新增、更不等于同时要存下的容量。 实际要留多少，还得看并发、共享、保留时间和淘汰策略。

问题也就在这里。算过的结果有复用价值，全部留着又不划算，KV 开始成为需要单独管理的基础设施资源。

────02 ｜显存装不下，缓存该怎么管？────

做过后端的同学应该不陌生，访问最频繁的数据放在最快的地方，暂时不用的往下放。这就是分层存储。

KV Cache 也一样。当前生成急着用的数据留在 GPU HBM 显存。暂时闲置、可能很快再用的放到 CPU DDR 内存。更久不用的，再考虑本地 SSD 或远端存储。

图 6，四层 KV Cache 存储架构

你想，一个 Agent 正在等工具返回，这份缓存暂时用不上，为什么要一直占着昂贵的显存？按调度策略先挪出去，就能给其他请求腾位置。

不过，搬出去容易，需要时能不能及时拿回来？ 如果读取、传输和恢复的时间比重算还长，这次复用就未必划算。缓存放哪层、留多久，都得结合访问频率和重算成本判断。

谁来记住它们的位置，安排什么时候搬、什么时候取？这就是运行在 CPU 侧的缓存管理软件的工作。数据中心运营方要管理的不只是 GPU 的分配，还包括 GPU 算出的结果怎样在各层资源之间流转。

缓存挪出去以后，还可以压缩保存，让同样的空间多放一些缓存。不过，搬运、压缩和解压本身也会消耗资源。Intel 在至强服务器平台上提供了专用加速能力，QAT 负责压缩和解压，DSA 可以分担数据搬运，让这些任务少占用 CPU 核心。

图 7，GPU、CPU、QAT 与 DSA 分工

GPU 管理决定算力分给谁，KV 管理则影响哪些计算可以少做一次。 两者一起考虑，才有机会在相同资源下支撑更多工作。接下来，我们先看 KV Shrink 怎样把缓存卸载和压缩结合起来。

────03 ｜Intel KV Shrink 怎样把这笔账算得更划算？────

先看一次缓存的去向。一批用户会话暂时闲置，KV Shrink 可以按调度策略把相关 KV 从显存卸载到主机侧，压缩后存进 DDR 缓存池。如果很久没用、DDR 又快满了，还可以继续往 SSD 或远端存储放。

下一轮请求到来，系统找到匹配的缓存，再读取、解压、回载，让模型接着处理新增内容。没有命中的部分，照常计算。

图 8，缓存卸载与恢复

第一次处理内容的计算还是得做，后面则有机会用一次读取换掉一次重算。这就是「以存代算」。哪些值得保留、留多久，可以通过冷热调度 API 结合业务策略控制。

到这里，你可能想问，缓存已经挪出显存了，为什么还要压缩？

因为 DDR 和 SSD 也有容量和成本。同样的空间能多留一些缓存，原本不得不淘汰的结果就有机会留下，后续请求也就多了一些命中的可能。压缩后的缓存往下层存储传输时，数据量也可以更小。

这里要分清，卸载释放的是显存，压缩主要节省主机内存和下层存储空间。 正在 GPU 上参与计算的 KV，不会因为下面那份压小了，就自动跟着缩小。

那一堆 K、V 数字怎么压，会不会丢信息？

数字在底层也是字节。KV Shrink 先做数据格式重排，让布局更适合压缩，再利用其中的冗余进行无损压缩。你可以把它理解成整理行李，东西没少，换个摆法让它更容易装下。解压还原后，仍是原始 KV 数据，与降低数值精度的量化不同。

图 9，KV 无损压缩与还原

按英特尔提供的测试资料，空间节省约为 20%—30%，具体取决于数据。换成直观的说法，原本 100GB 的缓存，按这个比例压缩后约为 70—80GB。规模越大，这部分容量就越值得关注。

不过，压得小就够了吗？假如 GPU 已经等着用下一批 KV，解压却还没完成，省下了存储空间，推理还是可能被拖慢。压缩和解压的吞吐，也得跟上 GPU 所需的缓存处理速度。

按英特尔对这套方案的补充说明，在其面向的高并发、长上下文场景中，单靠 CPU 核心做软件压缩解压，吞吐难以跟上需求，还会挤占其他任务的计算资源。KV Shrink 因而把这部分工作交给至强服务器平台上的 QAT 专用引擎，用硬件加速来匹配 GPU 推理所需的 KV 处理吞吐，同时减少 CPU 核心占用。

这也是 QAT 的优势所在。对于缺少同类专用压缩加速能力的友商硬件平台，仅靠 CPU 核心跑软件压缩，很难兼顾这样的吞吐需求和较低的核心占用。

图 10，QAT 分担 CPU 压缩任务

资料中的测试显示，在相同分层卸载机制下，开启 QAT 压缩，相对不开压缩的 TTFT 额外开销控制在 10% 以内。这个比较回答的是「卸载时增加压缩的代价」，不能理解成远端缓存和直接访问显存一样快。

容量省了多少，压缩花了多久，传输是否更轻，得放在一起看。这套方案可接入 vLLM，并提供容器与 Python 安装包，具体仍要核对模型、框架版本和 QAT 硬件支持。

────04 ｜除了压缩，KV 管理还能优化什么？────

缓存存得下，还得用得上。Intel 套件里的其他技术，分别从不同问题入手。

比如 RAG 上次找回文档 A、B，这次换成 B、C。B 明明算过，为什么不能直接复用？因为普通前缀缓存要求前缀匹配，B 前面的内容变了，对应的 KV 就未必还能直接用。

KV Fuse 通过独立 KV Cache 的融合与部分重计算，争取复用这些结果。缓存之间的关系需要处理，不能简单拼接了事。

图 11，KV Fuse 独立缓存复用

再想想，检索回来很多文档，主模型有必要把每一段都完整读一遍吗？KV Cascade 让辅助小模型并行提炼分块内容，再交给主模型综合回答，减少主模型需要处理的原始上下文。

进入主模型的 token 少了，主模型需要生成和保存的 KV 也有机会减少。

企业 RAG 白皮书里，它还与 KV Shrink 配合，保存、压缩和恢复相关缓存。小模型传给主模型的是提炼后的内容，两者的 KV 张量不能直接混用。提炼有没有漏掉信息，也要评估。

图 12，KV Cascade 与 KV Shrink 的 RAG 协作架构

还有些 Agent 持续生成，等不到会话闲置就已经遇到显存压力。能不能用到哪部分，再把哪部分加载进来？

KV Infinity 面向这个方向，通过按需加载与预测预取，减少全量缓存常驻 HBM 的需求。它扩展的是缓存管理方式，模型本身的上下文长度限制依然存在。

图 13，KV Infinity 按需加载与预取

这些能力分别处理复用、上下文提炼和加载问题，运营方可以根据业务场景选用，不是每个请求都必须依次走过的步骤。

────05 ｜放到数据中心，收益要怎么看？────

对运营方来说，存得更多、恢复得更快，最终都要回到同一业务量和服务要求下的资源成本。我们先看一个具体的时延结果。

前面看的是增加压缩会多花多少时间。这里换一个比较，看看整套 KV Shrink 方案与 LMCache 的表现。

英特尔与道客的 Coding Agent 联合测试中，在 80% 缓存命中率下，相比 LMCache，KV Shrink 的单路 TTFT 从 129.81 毫秒降到 114.13 毫秒，下降约 12.1%。八路并发下，从 765.66 毫秒降到 730.47 毫秒，下降约 4.6%。

图 14，Coding Agent 场景下 KV Shrink 与 LMCache 的 TTFT 对比

你留意一下，并发量变了，降幅也会变。这组测试使用双路至强金牌 6554S、8 张 H800、Qwen3-32B-fp8 和 vLLM v0.13，不能直接套到另一套部署上，更不能拿 TTFT 降幅当作总成本降幅。

真正部署时，还要观察缓存命中率、显存占用、请求吞吐和高峰期的等待时间。否则，单次请求快了一点，却让 CPU 或网络更拥堵，这套推理系统未必能处理更多请求。这里要评估的是整套系统。

除了处理得快不快，还得看容量够不够、扩容要花多少成本。如果值得保留的缓存连本机都装不下呢？英特尔与忆联的 JBOF 实践提供了一条扩容路径，把 NVMe SSD 组织成可通过网络访问的全闪存储资源，配合 DDR 缓存池、RDMA 和 SPDK，让温冷 KV 在远端也有地方存。

图 15，推理服务器通过 RDMA 访问远端 NVMe 存储

扩容之后，还要把存储、网络、功耗和维护成本一并算进去。减少的重复计算，能否覆盖保存与恢复的代价？这才决定整套系统有没有机会改善 TCO，也就是总体拥有成本。

────最后────

做后端时，我们会认真设计数据库、索引和缓存，讨论数据怎么存、什么时候过期。现在，模型算出的 KV 也有生成成本、复用价值和生命周期，这套资源管理的思路，正在延伸到 AI 基础设施里。

图 16，Intel KV Cache 智能加速套件全景图

Intel 的系统级创新，就体现在围绕至强服务器平台，把缓存软件、QAT、DSA、内存和存储组织起来，让保存、搬运与复用协同工作，争取用更低的 TCO 支撑业务。

这也意味着，基础设施的竞争会更看重资源之间的配合。对 Agent 开发者来说，除了看推理系统配了多少 GPU，也值得多问一句，这些算力里，有多少在完成新工作，又有多少在重做已经做过的事？

最后，如果你也对这些基础设施问题感兴趣，想把讨论从文章延伸到线下，也可以报名参加 Intel Connection 大会。感兴趣的同学，记得留意下面的报名截止时间和现场安排。