# 把记忆交给CPU，大模型会变快 - Sohu

*Источник: Sohu*
*Дата: 2026-09-16*
*Язык: zh*

**Кратко:** 把记忆交给CPU，大模型会变快
金磊 发自 凹非寺
量子位 | 公众号 QbitAI
拿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，大模型会变快
金磊 发自 凹非寺
量子位 | 公众号 QbitAI
拿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，是希望它多干点新活儿。已经算过、又能复用的内容，就尽量别再付一次计算的账。

[Оригинал](https://m.sohu.com/a/1076680305_610300?scm=10001.325_13-325_13.0.0-0-0-0-0.5_1334)