芯耀
与非AI
272
大家好，我是小林。
你调用大模型 API 的时候，有没有留意过「缓存命中」这个指标？
再翻一下价格表，你可能会发现，同一个模型，输入 token 还分两种价格，缓存命中和缓存未命中。命中的那部分，价格能便宜不少。
同样是把内容发给模型，怎么命中缓存就便宜了？背后到底省了什么？
你可以想一个场景。用 Agent 写代码时，每轮请求里往往都带着相同的系统提示词、工具说明，还有前面的对话记录。虽然这次问的问题变了，输入前面的一大段内容，可能和上次一模一样。
这些内容模型已经处理过了，下一次还要从头再算一遍吗？
这就轮到 KV Cache 出场了。
KV Cache 会保留模型处理历史内容时产生的一部分计算结果。你可以把它理解成一份「计算底稿」。下一轮请求的输入前缀匹配、也满足其他复用条件时，大模型服务就有机会直接用上这份底稿，省掉一部分重复计算。
所以，命中缓存后，模型仍然会继续计算、生成回答，只是处理输入时，有些活不用再干一次了。
不过，省下计算，也得付出另一份成本。模型在 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，仍然需要计算。
刚才说的是一次回答里怎么复用。那换到下一轮请求呢？如果输入前缀一致，模型和缓存状态也满足复用条件，这段 KV 就有机会接着用。这也就接上了开头说的 API 缓存命中。
这省下的是一部分重复 Prefill，也就是处理输入上下文的计算。模型服务提供方就有机会把省下的算力用于新请求，而用户也可能更早看到第一个 token，这段等待时间叫 TTFT。
但别被「缓存」两个字骗了，它可不小。
Agent 每读入一段工具结果、多生成一段内容，上下文里就多了一批 token。这些 token 又会在模型的多层计算中留下各自的 K、V。模型结构和缓存精度固定时，要保留的上下文越长，缓存通常就越大。再叠加同时运行的会话，显存压力就上来了。
有多大？按 Qwen3-8B 的结构，KV 使用 FP16 或 BF16 时，每个 token 对应约 147KB 的未压缩缓存。一万 token，光 KV 就约 1.47GB，还没算模型权重。1
假设一款 AI 应用有 300 万日活，每人每天 10 次请求，每次按一万 token 计算。把每次请求对应的完整 KV 体积加起来，一天累计约 44PB。
先别急着买硬盘。这里把重复前缀也重复计入了，累计体积不等于每天新增、更不等于同时要存下的容量。 实际要留多少，还得看并发、共享、保留时间和淘汰策略。
问题也就在这里。算过的结果有复用价值，全部留着又不划算，KV 开始成为需要单独管理的基础设施资源。
────02 ｜显存装不下，缓存该怎么管？────
做过后端的同学应该不陌生，访问最频繁的数据放在最快的地方，暂时不用的往下放。这就是分层存储。
KV Cache 也一样。当前生成急着用的数据留在 GPU HBM 显存。暂时闲置、可能很快再用的放到 CPU DDR 内存。更久不用的，再考虑本地 SSD 或远端存储。
你想，一个 Agent 正在等工具返回，这份缓存暂时用不上，为什么要一直占着昂贵的显存？按调度策略先挪出去，就能给其他请求腾位置。
不过，搬出去容易，需要时能不能及时拿回来？ 如果读取、传输和恢复的时间比重算还长，这次复用就未必划算。缓存放哪层、留多久，都得结合访问频率和重算成本判断。
谁来记住它们的位置，安排什么时候搬、什么时候取？这就是运行在 CPU 侧的缓存管理软件的工作。数据中心运营方要管理的不只是 GPU 的分配，还包括 GPU 算出的结果怎样在各层资源之间流转。
缓存挪出去以后，还可以压缩保存，让同样的空间多放一些缓存。不过，搬运、压缩和解压本身也会消耗资源。Intel 在至强服务器平台上提供了专用加速能力，QAT 负责压缩和解压，DSA 可以分担数据搬运，让这些任务少占用 CPU 核心。
GPU 管理决定算力分给谁，KV 管理则影响哪些计算可以少做一次。 两者一起考虑，才有机会在相同资源下支撑更多工作。接下来，我们先看 KV Shrink 怎样把缓存卸载和压缩结合起来。
────03 ｜Intel KV Shrink 怎样把这笔账算得更划算？────
先看一次缓存的去向。一批用户会话暂时闲置，KV Shrink 可以按调度策略把相关 KV 从显存卸载到主机侧，压缩后存进 DDR 缓存池。如果很久没用、DDR 又快满了，还可以继续往 SSD 或远端存储放。
下一轮请求到来，系统找到匹配的缓存，再读取、解压、回载，让模型接着处理新增内容。没有命中的部分，照常计算。
第一次处理内容的计算还是得做，后面则有机会用一次读取换掉一次重算。这就是「以存代算」。哪些值得保留、留多久，可以通过冷热调度 API 结合业务策略控制。
到这里，你可能想问，缓存已经挪出显存了，为什么还要压缩？
因为 DDR 和 SSD 也有容量和成本。同样的空间能多留一些缓存，原本不得不淘汰的结果就有机会留下，后续请求也就多了一些命中的可能。压缩后的缓存往下层存储传输时，数据量也可以更小。
这里要分清，卸载释放的是显存，压缩主要节省主机内存和下层存储空间。 正在 GPU 上参与计算的 KV，不会因为下面那份压小了，就自动跟着缩小。
那一堆 K、V 数字怎么压，会不会丢信息？
数字在底层也是字节。KV Shrink 先做数据格式重排，让布局更适合压缩，再利用其中的冗余进行无损压缩。你可以把它理解成整理行李，东西没少，换个摆法让它更容易装下。解压还原后，仍是原始 KV 数据，与降低数值精度的量化不同。
按英特尔提供的测试资料，空间节省约为 20%—30%，具体取决于数据。换成直观的说法，原本 100GB 的缓存，按这个比例压缩后约为 70—80GB。规模越大，这部分容量就越值得关注。
不过，压得小就够了吗？假如 GPU 已经等着用下一批 KV，解压却还没完成，省下了存储空间，推理还是可能被拖慢。压缩和解压的吞吐，也得跟上 GPU 所需的缓存处理速度。
按英特尔对这套方案的补充说明，在其面向的高并发、长上下文场景中，单靠 CPU 核心做软件压缩解压，吞吐难以跟上需求，还会挤占其他任务的计算资源。KV Shrink 因而把这部分工作交给至强服务器平台上的 QAT 专用引擎，用硬件加速来匹配 GPU 推理所需的 KV 处理吞吐，同时减少 CPU 核心占用。
这也是 QAT 的优势所在。对于缺少同类专用压缩加速能力的友商硬件平台，仅靠 CPU 核心跑软件压缩，很难兼顾这样的吞吐需求和较低的核心占用。
资料中的测试显示，在相同分层卸载机制下，开启 QAT 压缩，相对不开压缩的 TTFT 额外开销控制在 10% 以内。这个比较回答的是「卸载时增加压缩的代价」，不能理解成远端缓存和直接访问显存一样快。2
容量省了多少，压缩花了多久，传输是否更轻，得放在一起看。这套方案可接入 vLLM，并提供容器与 Python 安装包，具体仍要核对模型、框架版本和 QAT 硬件支持。
────04 ｜除了压缩，KV 管理还能优化什么？────
缓存存得下，还得用得上。Intel 套件里的其他技术，分别从不同问题入手。
比如 RAG 上次找回文档 A、B，这次换成 B、C。B 明明算过，为什么不能直接复用？因为普通前缀缓存要求前缀匹配，B 前面的内容变了，对应的 KV 就未必还能直接用。
KV Fuse 通过独立 KV Cache 的融合与部分重计算，争取复用这些结果。缓存之间的关系需要处理，不能简单拼接了事。
再想想，检索回来很多文档，主模型有必要把每一段都完整读一遍吗？KV Cascade 让辅助小模型并行提炼分块内容，再交给主模型综合回答，减少主模型需要处理的原始上下文。
进入主模型的 token 少了，主模型需要生成和保存的 KV 也有机会减少。
企业 RAG 白皮书里，它还与 KV Shrink 配合，保存、压缩和恢复相关缓存。小模型传给主模型的是提炼后的内容，两者的 KV 张量不能直接混用。提炼有没有漏掉信息，也要评估。
还有些 Agent 持续生成，等不到会话闲置就已经遇到显存压力。能不能用到哪部分，再把哪部分加载进来？
KV Infinity 面向这个方向，通过按需加载与预测预取，减少全量缓存常驻 HBM 的需求。它扩展的是缓存管理方式，模型本身的上下文长度限制依然存在。
这些能力分别处理复用、上下文提炼和加载问题，运营方可以根据业务场景选用，不是每个请求都必须依次走过的步骤。
────05 ｜放到数据中心，收益要怎么看？────
对运营方来说，存得更多、恢复得更快，最终都要回到同一业务量和服务要求下的资源成本。我们先看一个具体的时延结果。
前面看的是增加压缩会多花多少时间。这里换一个比较，看看整套 KV Shrink 方案与 LMCache 的表现。
英特尔与道客的 Coding Agent 联合测试中，在 80% 缓存命中率下，相比 LMCache，KV Shrink 的单路 TTFT 从 129.81 毫秒降到 114.13 毫秒，下降约 12.1%。八路并发下，从 765.66 毫秒降到 730.47 毫秒，下降约 4.6%。
你留意一下，并发量变了，降幅也会变。这组测试使用双路至强金牌 6554S、8 张 H800、Qwen3-32B-fp8 和 vLLM v0.13，不能直接套到另一套部署上，更不能拿 TTFT 降幅当作总成本降幅。
真正部署时，还要观察缓存命中率、显存占用、请求吞吐和高峰期的等待时间。否则，单次请求快了一点，却让 CPU 或网络更拥堵，这套推理系统未必能处理更多请求。这里要评估的是整套系统。
除了处理得快不快，还得看容量够不够、扩容要花多少成本。如果值得保留的缓存连本机都装不下呢？英特尔与忆联的 JBOF 实践提供了一条扩容路径，把 NVMe SSD 组织成可通过网络访问的全闪存储资源，配合 DDR 缓存池、RDMA 和 SPDK，让温冷 KV 在远端也有地方存。
扩容之后，还要把存储、网络、功耗和维护成本一并算进去。减少的重复计算，能否覆盖保存与恢复的代价？这才决定整套系统有没有机会改善 TCO，也就是总体拥有成本。
────最后────
做后端时，我们会认真设计数据库、索引和缓存，讨论数据怎么存、什么时候过期。现在，模型算出的 KV 也有生成成本、复用价值和生命周期，这套资源管理的思路，正在延伸到 AI 基础设施里。
Intel 的系统级创新，就体现在围绕至强服务器平台，把缓存软件、QAT、DSA、内存和存储组织起来，让保存、搬运与复用协同工作，争取用更低的 TCO 支撑业务。
这也意味着，基础设施的竞争会更看重资源之间的配合。对 Agent 开发者来说，除了看推理系统配了多少 GPU，也值得多问一句，这些算力里，有多少在完成新工作，又有多少在重做已经做过的事？
最后，如果你也对这些基础设施问题感兴趣，想把讨论从文章延伸到线下，也可以报名参加 Intel Connection 大会。感兴趣的同学，记得留意下面的报名截止时间和现场安排。
