拿 Agent 做 Coding，想必大家都已经很熟悉了。

不过，如果我们把目光从聊天窗口移到背后的数据中心，事情就没那么简单了。

一个 Coding Agent 改跨十几个文件的 bug，需要反复读代码、查资料、跑测试。前几轮交互可能还很顺畅，但任务继续跑下去，系统要处理的历史信息也会越积越多。

当成千上万个 Agent 同时这样干活，运营方就可能遇到一个头疼的问题：服务器还在跑，能接住的并发却越来越吃紧，有些请求连吐出第一个 Token 都要等上好一会儿。

难道只能继续加 GPU？

非也非也。

模型还是那个模型，服务器也还是那个服务器，问题的根儿啊，其实是出在了记忆。

因为大模型每生成一个新的 Token，都还要继续用到前文的信息。为了不用每次从头计算，系统会把前面已经算好的中间结果保存起来；会话越聊越长，这份记忆自然也就越堆越厚。

一旦显存装不下，部分缓存被清走，等 Agent 下一轮又需要这些历史信息时，就可能重新做一遍 Prefill。前面明明已经算过的东西，又得花 GPU 时间再算一次。

尤其是到了 Agent 时代，AI 很少干一问一答的事儿，更多是那种反复需要思考、规划和行动的任务，期间会不断积累会话历史、检索证据、工具结果和中间状态等等。

于是乎，一个过去藏在大模型推理内部、普通用户几乎感知不到的东西，就这样被推到了台面儿上——KV Cache。

它的特点，说起来就一个字：大。但运营方又不能为了省空间，任由已经算过的内容反复占用 GPU 重算。所以，长上下文推理要算的这笔账，也就从算力延伸到了存储、搬运和复用。

而这件事的破局之道，并不是你以为的 GPU，而是——CPU。

AI 的记忆怎么就越来越贵了？

我们先把 KV Cache 这件事说清楚。

对于采用因果自注意力的 Transformer 模型来说，前面处理过的 Token，会在注意力层中留下对应的 Key 和 Value。模型生成后续 Token 时，还能继续使用这些结果。推理系统把它们缓存起来，就有了 KV Cache。

你可以把它理解成模型读书时做的笔记。后面再遇到需要联系上文的地方，模型可以调用笔记，省去对已有 Token 的重复计算。

所以，我们这里说的记忆，指的是推理过程中留下的中间状态，模型的权重并没有因此发生变化。

这份笔记确实能省计算，但它也是实实在在要占地方的。而且，Agent 读的东西越多，服务器要替它保存的笔记往往就越厚。

那么这个增长到底有多明显呢？

我们拿 Qwen3-8B 算一笔账。按照它的公开模型配置，在 KV Cache 采用 BF16 或 FP16、每个数值占 2 字节的条件下，每个 Token 对应的 KV 数据是 147456 字节，也就是约147KB。这还没有计入缓存管理等额外开销。

为什么一个 Token 会带出这么大一份缓存？因为系统保存的并不是这个 Token 的文字本身，而是它在多层注意力计算中对应的 Key 和 Value。按这个模型的结构，计算式就是：2 份 K/V × 36 层 × 8 个 KV 头 × 每头 128 维 × 2 字节。

接下来，我们只借用这个每 Token 开销，做一次百万上下文的容量推演：如果需要缓存 100 万个 Token，对应的 KV 数据就约为 147GB。注意，这里的 1M 是测算假设，不代表 Qwen3-8B 实际支持百万上下文；它的官方说明是原生 32768 Token，采用 YaRN 可扩展到 131072 Token。

单个请求已经如此，如果把请求规模也放大呢？假设一个服务有 300 万日活用户，每人每天发出 10 个请求，而且每个请求都按前面的 1M 上下文计算，一天就是 3000 万个请求。

先不考虑压缩和共享复用，按每个请求约 147GB 全量累加，对应的日累计 KV 数据规模就是：300 万 × 10 × 147GB ≈ 4410PB。如果日活再增加到 3 亿，相同假设下，这个数字还会放大 100 倍，达到约441000PB，也就是 441EB。

不过，这里得分清两件事：一天的请求累计涉及多少 KV 数据，和数据中心同时需要存下多少 KV 数据，不是一回事。上面是每次请求都独立、全量计数的规模推演，不能直接当作存储采购清单。

实际要配多大的缓存池，运营方还得看高峰时有多少请求同时运行、缓存要留多久、哪些前缀能够共享，以及压缩和淘汰策略。已经复用的同一份缓存，也不该因为被请求多次就重复占一份容量。

当然，不同模型的 " 笔记本 " 也不一样。模型层数、KV 头数量、缓存精度等都会影响大小，不能只看参数量。上面的数字不是某个服务的真实用量，却能说明运营方为什么要格外关注这份 " 记忆 "：上下文长度和请求规模，会一起把缓存的账越算越大。

而 GPU 的显存，还要放模型权重和运行时的其他数据。大家共用这么多空间，KV Cache 占得越多，系统留给其他请求的余地就可能越小。

这时候，推理系统就得做取舍了：减少同时处理的请求，把部分缓存卸载到其他存储层，或者清理暂时不用的缓存。

再拿前面的 Coding Agent 来说。它可能正在等工具跑测试，系统趁这个空当，把它的一部分历史缓存清掉了。等测试结果返回，Agent 准备接着干活，却发现需要用的缓存已经不在了。

如果其他存储层也没保存这份数据，模型就得重新处理相应的历史输入、重建缓存。这个处理输入的阶段叫Prefill，输入越长，通常就越费时。用户等待首个 Token 的时间，也就是TTFT，便可能跟着增加。

算过一遍的内容，过一会儿又得再算。对运营方来说，消耗掉的不只是电和时间，还有这批 GPU 原本可以用来处理新任务、生成新 Token 的机会。

这也解释了，为什么 KV Cache 再大，运营方仍然要认真考虑怎么把它用好。

从成本角度看，GPU 应该尽量把资源花在必要的新输入处理和新 Token 生成上，少为已经处理过、又可以复用的历史内容重复做 Prefill。KV Cache 保留下来的，正是这部分已有计算的成果。

当然，这不意味着所有缓存都得永久保存。真正要算的是：保留和取回一份缓存，能不能比下次重算更划算？谁能把这笔账算好，谁就更有机会用同一套设备服务更多请求。

GPU 生成 Token，CPU 开始接管记忆

聊到这里，你可能已经想到了，显存放不下，难道不能先存到别处，等要用的时候再拿回来？

可以，这也正是" 以存代算 "的思路。

在服务器里，GPU 显存之外还有 CPU 侧的 DDR 内存、本地 SSD，以及远端存储。它们的容量、速度和成本各不相同，正好可以用来存放不同活跃程度的缓存。

例如眼下正在生成回答，需要频繁访问的数据，就留在 GPU 的高带宽显存 HBM 里；短时间内可能继续用到的缓存，可以先放进 CPU 侧的 DDR 内存；至于更久没有访问、但还值得保留的历史缓存，则可以继续下沉到 SSD 或远端存储。

再聚焦到 Coding Agent 的任务里，就是它写代码时，相关缓存尽量留在 GPU 侧；任务暂停后，系统可以把缓存转存到内存；如果这段会话很久没继续，再考虑把数据移到更下一层。用户回来后，系统根据缓存命中情况，把需要的部分取回来。

对运营方来说，这样安排的直接好处是：显存不用一直替所有历史会话占着位置，腾出的空间可以交给正在运行的请求。

不过，把东西搬出去只是第一步。哪些数据可以搬、应该放在哪里、什么时候得提前取回来，总得有个地方统一管理。

CPU 就在这里发挥作用。

推理服务运行在主机侧的管理逻辑，需要跟踪会话状态、剩余容量和缓存访问情况。CPU 连接的大容量内存和存储，也为显存之外的缓存池提供了基础。系统可以结合这些信息，决定一份 KV Cache 接下来该留在哪一层。

这类机制其实已经出现在一些推理框架里了。例如，vLLM 的 KV Offloading 支持将缓存块卸载到 CPU 内存，还可以配置次级存储层。在它描述的多层方案里，次级存储与 GPU 之间的数据传输，会经过 CPU 侧的缓存层。

但这里还有个问题，那就是数据是存下来了，搬回来会不会更慢？

毕竟，DDR、SSD 和远端存储的访问条件各不相同。假如取回缓存比重新计算还费时，用户还是得等，甚至可能等得更久。所以，系统需要根据访问频率和传输开销安排缓存，不能一股脑地把数据全塞到硬盘里。

要减少搬运量，另一个办法就是压缩。数据变小了，同样的空间能存得更多，传输时要搬的字节也更少。

可压缩也不是白来的，压缩和解压都要花时间，如果全让通用 CPU 核心来干，又可能挤占请求调度等工作需要的资源。

更麻烦的是，KV Cache 本身就是大体量数据，压缩和解压的速度如果跟不上 GPU 侧的数据吞吐，压缩环节反而会成为新的瓶颈。单纯依靠通用 CPU 核心做软件压缩，很难同时兼顾高吞吐和 CPU 资源占用。

这也是 QAT 的意义所在。它把压缩、解压交给专用硬件处理，在提升吞吐的同时释放通用 CPU 核心。相比只依赖 CPU Core 的软件方案，这种内置专用压缩加速能力，也构成了英特尔在 KV Cache 分层卸载上的一个差异化优势。

于是问题就不只是能不能压，还变成了能不能压得足够快。

对此，CPU 老巨头英特尔给出了一套面向数据中心的 KV Cache 优化思路。

记忆存得下，还要用得上

围绕 KV Cache，英特尔布局了 KV Shrink、KV Fuse、KV Cascade 和 KV Infinity 四个技术方向。

名字虽然看着多，但我们用一张表格，根据它们各自要解决的问题来分类，就一目了然了：

其中，KV Shrink已经有较具体的实现和测试披露，我们先来重点看看它。

KV Shrink 可以把前面讲的分层管理与硬件压缩结合起来，并提供冷热调度 API，让业务系统按自己的策略决定缓存什么时候下沉、什么时候回载。内存吃紧时，系统还可以把较冷的数据继续转存到 SSD 等下一层介质。

而负责分担压缩工作的，是英特尔的QAT（QuickAssist Technology）。

它能够把压缩、解压等任务交给专用加速单元，减少对通用 CPU 核心的占用。英特尔从第四代至强可扩展处理器的相关型号开始集成 QAT 硬件。

这么一来，CPU 侧的管理逻辑继续负责调度，专用硬件接过压缩任务，系统便有机会在控制额外开销的同时，缩小缓存体积。

英特尔还做了一个更细的调整：重新排列 KV Cache 的存储格式，让压缩算法更容易压缩这些数据。

重排后，压缩所节省的空间从原先的 10% 以上增加到 20% 以上，空间降幅约为 20% 至 30%。这条路径采用无损压缩，解压后能够恢复原始 KV 数据，不会因压缩而丢失数据。

虽然 20%-30% 这个数字乍一看似乎没那么夸张，但把缓存池的规模放大，差别就出来了。

例如，一个数据中心需要保留 500TB 的 KV Cache，如果能压缩掉 30%，对应的就是约 150TB 空间。这里算的是实际缓存池的容量，和前面按请求累加的日累计数据量不同。至于运营方最终能省下多少费用，还得结合存储介质、保留时间和业务负载来算，不能直接给总成本也打个七折。

空间这块算是有收益了，那速度又怎么样呢？

在英特尔给出的一组测试中，使用双路至强金牌 6554S 处理器、两张英伟达 L20 GPU 和 Qwen3-32B 模型，在 80% 缓存命中率下，相较未开启分层卸载的原生 vLLM 基线，KV Shrink 在测试覆盖的输入长度和并发组合中，TTFT 最高获得约 5 倍加速。

除此之外，QAT 硬件压缩方案的整体性能约为 CPU 软件压缩方案的两倍。在相同分层卸载机制下，相较不启用压缩，开启 QAT 压缩带来的额外 TTFT 开销低于 10%。

从这两项对照测试来看，压缩确实会多一道工序，但在这组测试里，专用硬件把额外开销控制在了较小范围内，让系统能够用一定的时间代价换取存储空间。

再来看一组面向 Coding Agent 服务的测试。

英特尔与道客联合实验室采用另一套配置进行测试：双路至强金牌 6554S、八张 H800 和 Qwen3-32B FP8 模型，缓存命中率同样为 80%。相较测试中的 LMCache 方案，KV Shrink 在单路负载下的平均 TTFT 由 129.81 毫秒降至 114.13 毫秒，降幅约 12.1%；八路并发时，降幅约为 4.6%。

你会发现，换一套设备、换一个比较对象，加速幅度也变了。所以数据中心运营方真正部署时，还是要把自己的上下文长度、并发量和缓存命中率带进去测试。业务里重复访问历史内容的机会越少，缓存复用能帮上的忙通常也越有限。

除了把一段会话存好，运营方承载的企业服务还可能遇到另一类需求：几份文档以前都处理过，现在想把它们组合起来用，能不能少算一点？

这就是KV Fuse关注的问题。但模型处理文档时会受到前文和位置等因素影响，几份独立生成的 KV Cache 通常不能直接拼接。KV Fuse 尝试通过缓存融合和部分重计算，保留其中能够复用的工作。

如果问题出在 " 给模型看的东西太多 "，KV Cascade则尝试先请辅助模型做筛选或处理，把相关内容交给主模型。例如，一大堆文档里只有部分信息和当前问题有关，就可以先缩小主模型需要处理的范围。

而 KV Infinity 面向持续增长的长任务，通过按需加载和预取，尝试缓解缓存必须全部常驻 HBM 的压力，让系统能够利用显存之外的资源。具体能扩展到什么程度，仍然要看访问方式和传输效率。

这些方向背后，英特尔想要做的事就已经比较清楚了：

让 CPU 协助管理推理中产生的大量计算结果，再通过内存、存储和专用加速单元，把保存和使用这些结果的成本降下来。

对于具备相应 QAT 硬件的至强服务器，这提供了一条利用已有平台能力的优化路径。当然，实际接入还要检查内存、存储和软件等条件。

最后，再回到数据中心的那笔账。单个用户看到的，也许只是 Coding Agent 有没有及时回答；运营方要考虑的，则是成千上万个请求涌进来之后，系统还能不能以可接受的成本持续提供服务。

KV Cache 越大，全部留在显存里就越难；可如果把还有复用价值的缓存一清了之，GPU 又得为同一段历史反复开工。运营方需要在保存、搬运和重算之间找到合适的平衡。

英特尔押注 KV Cache，争取的正是这个位置：通过 CPU 侧的管理、分层存储和硬件压缩，让已有计算结果能以更低的代价被保留和再次使用。

GPU 仍然负责模型计算，CPU 和存储系统则协助减少那些本可以避免的重复工作。至于方案值不值得部署，最终还得看真实负载下的响应时间、吞吐量，以及把服务器、内存、存储和能耗都算进去的总成本。

毕竟，运营方买下昂贵的 GPU，是希望它多干点新活儿。已经算过、又能复用的内容，就尽量别再付一次计算的账。

最后，若是小伙伴们想要了解更多关于英特尔 CPU 的最新进展，欢迎锁定 9 月 22 日 -9 月 23 日的英特尔技术创新与产业生态大会（关注【英特尔商用】报名参加）！

一键三连「点赞」「转发」「小心心」

欢迎在评论区留下你的想法！

—  完  —

点亮星标

科技前沿进展每日见