{"id":83485,"topic":"ai","source":"新浪财经","title":"把记忆交给CPU，大模型会变快 - 新浪财经","url":"https://finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html?vt=4&cid=76993&node_id=76993","url_hash":"0d99ece7e297866cef7d9340dcc57e375e7a6835","author":"","summary":"<a href=\"https://news.google.com/rss/articles/CBMipwFBVV95cUxNY3lPSHVydUtwQzFselAxLUllcG1PLWd1aFUyUUJDU2lQa0Y4UldfT0RxdkNxTmtrWldBYXBSVW1RYVRpbDkxZkM2cTZReFZYV0FCTlgwQmVBNHVMZ3poaVh0aEltVkx3ek1fRkN5Qm5FZkpUYmdiVkZhSHJJVWFjS1ZYWEVpZlNaaWwyU0hIT3l5T0VBd29GWFYwbWZkazV6SFVvUnFHRQ?oc=5\" target=\"_blank\">把记忆交给CPU，大模型会变快</a>&nbsp;&nbsp;<font color=\"#6f6f6f\">新浪财经</font>","content":"把记忆交给CPU，大模型会变快\n（来源：量子位）\n拿Agent做Coding，想必大家都已经很熟悉了。\n不过，如果我们把目光从聊天窗口移到背后的数据中心，事情就没那么简单了。\n一个Coding Agent改跨十几个文件的bug，需要反复读代码、查资料、跑测试。前几轮交互可能还很顺畅，但任务继续跑下去，系统要处理的历史信息也会越积越多。\n当成千上万个Agent同时这样干活，运营方就可能遇到一个头疼的问题：服务器还在跑，能接住的并发却越来越吃紧，有些请求连吐出第一个Token都要等上好一会儿。\n难道只能继续加GPU？\n非也非也。\n模型还是那个模型，服务器也还是那个服务器，问题的根儿啊，其实是出在了记忆。\n因为大模型每生成一个新的Token，都还要继续用到前文的信息。为了不用每次从头计算，系统会把前面已经算好的中间结果保存起来；会话越聊越长，这份记忆自然也就越堆越厚。\n一旦显存装不下，部分缓存被清走，等Agent下一轮又需要这些历史信息时，就可能重新做一遍Prefill。前面明明已经算过的东西，又得花GPU时间再算一次。\n尤其是到了Agent时代，AI很少干一问一答的事儿，更多是那种反复需要思考、规划和行动的任务，期间会不断积累会话历史、检索证据、工具结果和中间状态等等。\n于是乎，一个过去藏在大模型推理内部、普通用户几乎感知不到的东西，就这样被推到了台面儿上——KV Cache。\n它的特点，说起来就一个字：大。但运营方又不能为了省空间，任由已经算过的内容反复占用GPU重算。所以，长上下文推理要算的这笔账，也就从算力延伸到了存储、搬运和复用。\n而这件事的破局之道，并不是你以为的GPU，而是——CPU。\n我们先把KV Cache这件事说清楚。\n对于采用因果自注意力的Transformer模型来说，前面处理过的Token，会在注意力层中留下对应的Key和Value。模型生成后续Token时，还能继续使用这些结果。推理系统把它们缓存起来，就有了KV Cache。\n你可以把它理解成模型读书时做的笔记。后面再遇到需要联系上文的地方，模型可以调用笔记，省去对已有Token的重复计算。\n所以，我们这里说的记忆，指的是推理过程中留下的中间状态，模型的权重并没有因此发生变化。\n这份笔记确实能省计算，但它也是实实在在要占地方的。而且，Agent读的东西越多，服务器要替它保存的笔记往往就越厚。\n那么这个增长到底有多明显呢？\n我们拿Qwen3-8B算一笔账。按照它的公开模型配置，在KV Cache采用BF16或FP16、每个数值占2字节的条件下，每个Token对应的KV数据是147456字节，也就是约147KB。这还没有计入缓存管理等额外开销。\n为什么一个Token会带出这么大一份缓存？因为系统保存的并不是这个Token的文字本身，而是它在多层注意力计算中对应的Key和Value。按这个模型的结构，计算式就是：2份K/V × 36层 × 8个KV头 × 每头128维 × 2字节。\n接下来，我们只借用这个每Token开销，做一次百万上下文的容量推演：如果需要缓存100万个Token，对应的KV数据就约为147GB。注意，这里的1M是测算假设，不代表Qwen3-8B实际支持百万上下文；它的官方说明是原生32768 Token，采用YaRN可扩展到131072 Token。\n单个请求已经如此，如果把请求规模也放大呢？假设一个服务有300万日活用户，每人每天发出10个请求，而且每个请求都按前面的1M上下文计算，一天就是3000万个请求。\n先不考虑压缩和共享复用，按每个请求约147GB全量累加，对应的日累计KV数据规模就是：300万 × 10 × 147GB ≈ 4410PB。如果日活再增加到3亿，相同假设下，这个数字还会放大100倍，达到约441000PB，也就是441EB。\n不过，这里得分清两件事：一天的请求累计涉及多少KV数据，和数据中心同时需要存下多少KV数据，不是一回事。上面是每次请求都独立、全量计数的规模推演，不能直接当作存储采购清单。\n实际要配多大的缓存池，运营方还得看高峰时有多少请求同时运行、缓存要留多久、哪些前缀能够共享，以及压缩和淘汰策略。已经复用的同一份缓存，也不该因为被请求多次就重复占一份容量。\n当然，不同模型的“笔记本”也不一样。模型层数、KV头数量、缓存精度等都会影响大小，不能只看参数量。上面的数字不是某个服务的真实用量，却能说明运营方为什么要格外关注这份“记忆”：上下文长度和请求规模，会一起把缓存的账越算越大。\n而GPU的显存，还要放模型权重和运行时的其他数据。大家共用这么多空间，KV Cache占得越多，系统留给其他请求的余地就可能越小。\n这时候，推理系统就得做取舍了：减少同时处理的请求，把部分缓存卸载到其他存储层，或者清理暂时不用的缓存。\n再拿前面的Coding Agent来说。它可能正在等工具跑测试，系统趁这个空当，把它的一部分历史缓存清掉了。等测试结果返回，Agent准备接着干活，却发现需要用的缓存已经不在了。\n如果其他存储层也没保存这份数据，模型就得重新处理相应的历史输入、重建缓存。这个处理输入的阶段叫Prefill，输入越长，通常就越费时。用户等待首个Token的时间，也就是TTFT，便可能跟着增加。\n算过一遍的内容，过一会儿又得再算。对运营方来说，消耗掉的不只是电和时间，还有这批GPU原本可以用来处理新任务、生成新Token的机会。\n这也解释了，为什么KV Cache再大，运营方仍然要认真考虑怎么把它用好。\n从成本角度看，GPU应该尽量把资源花在必要的新输入处理和新Token生成上，少为已经处理过、又可以复用的历史内容重复做Prefill。KV Cache保留下来的，正是这部分已有计算的成果。\n当然，这不意味着所有缓存都得永久保存。真正要算的是：保留和取回一份缓存，能不能比下次重算更划算？谁能把这笔账算好，谁就更有机会用同一套设备服务更多请求。\n聊到这里，你可能已经想到了，显存放不下，难道不能先存到别处，等要用的时候再拿回来？\n可以，这也正是“以存代算”的思路。\n在服务器里，GPU显存之外还有CPU侧的DDR内存、本地SSD，以及远端存储。它们的容量、速度和成本各不相同，正好可以用来存放不同活跃程度的缓存。\n例如眼下正在生成回答，需要频繁访问的数据，就留在GPU的高带宽显存HBM里；短时间内可能继续用到的缓存，可以先放进CPU侧的DDR内存；至于更久没有访问、但还值得保留的历史缓存，则可以继续下沉到SSD或远端存储。\n再聚焦到Coding Agent的任务里，就是它写代码时，相关缓存尽量留在GPU侧；任务暂停后，系统可以把缓存转存到内存；如果这段会话很久没继续，再考虑把数据移到更下一层。用户回来后，系统根据缓存命中情况，把需要的部分取回来。\n对运营方来说，这样安排的直接好处是：显存不用一直替所有历史会话占着位置，腾出的空间可以交给正在运行的请求。\n不过，把东西搬出去只是第一步。哪些数据可以搬、应该放在哪里、什么时候得提前取回来，总得有个地方统一管理。\nCPU就在这里发挥作用。\n推理服务运行在主机侧的管理逻辑，需要跟踪会话状态、剩余容量和缓存访问情况。CPU连接的大容量内存和存储，也为显存之外的缓存池提供了基础。系统可以结合这些信息，决定一份KV Cache接下来该留在哪一层。\n这类机制其实已经出现在一些推理框架里了。例如，vLLM的KV Offloading支持将缓存块卸载到CPU内存，还可以配置次级存储层。在它描述的多层方案里，次级存储与GPU之间的数据传输，会经过CPU侧的缓存层。\n但这里还有个问题，那就是数据是存下来了，搬回来会不会更慢？\n毕竟，DDR、SSD和远端存储的访问条件各不相同。假如取回缓存比重新计算还费时，用户还是得等，甚至可能等得更久。所以，系统需要根据访问频率和传输开销安排缓存，不能一股脑地把数据全塞到硬盘里。\n要减少搬运量，另一个办法就是压缩。数据变小了，同样的空间能存得更多，传输时要搬的字节也更少。\n可压缩也不是白来的，压缩和解压都要花时间，如果全让通用CPU核心来干，又可能挤占请求调度等工作需要的资源。\n更麻烦的是，KV Cache本身就是大体量数据，压缩和解压的速度如果跟不上GPU侧的数据吞吐，压缩环节反而会成为新的瓶颈。单纯依靠通用CPU核心做软件压缩，很难同时兼顾高吞吐和CPU资源占用。\n这也是QAT的意义所在。它把压缩、解压交给专用硬件处理，在提升吞吐的同时释放通用CPU核心。相比只依赖CPU Core的软件方案，这种内置专用压缩加速能力，也构成了英特尔在KV Cache分层卸载上的一个差异化优势。\n于是问题就不只是能不能压，还变成了能不能压得足够快。\n对此，CPU老巨头英特尔给出了一套面向数据中心的KV Cache优化思路。\n围绕KV Cache，英特尔布局了KV Shrink、KV Fuse、KV Cascade和KV Infinity四个技术方向。\n名字虽然看着多，但我们用一张表格，根据它们各自要解决的问题来分类，就一目了然了：\n其中，KV Shrink已经有较具体的实现和测试披露，我们先来重点看看它。\nKV Shrink可以把前面讲的分层管理与硬件压缩结合起来，并提供冷热调度API，让业务系统按自己的策略决定缓存什么时候下沉、什么时候回载。内存吃紧时，系统还可以把较冷的数据继续转存到SSD等下一层介质。\n而负责分担压缩工作的，是英特尔的QAT（QuickAssist Technology）。\n它能够把压缩、解压等任务交给专用加速单元，减少对通用CPU核心的占用。英特尔从第四代至强可扩展处理器的相关型号开始集成QAT硬件。\n这么一来，CPU侧的管理逻辑继续负责调度，专用硬件接过压缩任务，系统便有机会在控制额外开销的同时，缩小缓存体积。\n英特尔还做了一个更细的调整：重新排列KV Cache的存储格式，让压缩算法更容易压缩这些数据。\n重排后，压缩所节省的空间从原先的10%以上增加到20%以上，空间降幅约为20%至30%。这条路径采用无损压缩，解压后能够恢复原始KV数据，不会因压缩而丢失数据。\n虽然20%-30%这个数字乍一看似乎没那么夸张，但把缓存池的规模放大，差别就出来了。\n例如，一个数据中心需要保留500TB的KV Cache，如果能压缩掉30%，对应的就是约150TB空间。这里算的是实际缓存池的容量，和前面按请求累加的日累计数据量不同。至于运营方最终能省下多少费用，还得结合存储介质、保留时间和业务负载来算，不能直接给总成本也打个七折。\n空间这块算是有收益了，那速度又怎么样呢？\n在英特尔给出的一组测试中，使用双路至强金牌6554S处理器、两张英伟达L20 GPU和Qwen3-32B模型，在80%缓存命中率下，相较未开启分层卸载的原生vLLM基线，KV Shrink在测试覆盖的输入长度和并发组合中，TTFT最高获得约5倍加速。\n除此之外，QAT硬件压缩方案的整体性能约为CPU软件压缩方案的两倍。在相同分层卸载机制下，相较不启用压缩，开启QAT压缩带来的额外TTFT开销低于10%。\n从这两项对照测试来看，压缩确实会多一道工序，但在这组测试里，专用硬件把额外开销控制在了较小范围内，让系统能够用一定的时间代价换取存储空间。\n再来看一组面向Coding Agent服务的测试。\n英特尔与道客联合实验室采用另一套配置进行测试：双路至强金牌6554S、八张H800和Qwen3-32B FP8模型，缓存命中率同样为80%。相较测试中的LMCache方案，KV Shrink在单路负载下的平均TTFT由129.81毫秒降至114.13毫秒，降幅约12.1%；八路并发时，降幅约为4.6%。\n你会发现，换一套设备、换一个比较对象，加速幅度也变了。所以数据中心运营方真正部署时，还是要把自己的上下文长度、并发量和缓存命中率带进去测试。业务里重复访问历史内容的机会越少，缓存复用能帮上的忙通常也越有限。\n除了把一段会话存好，运营方承载的企业服务还可能遇到另一类需求：几份文档以前都处理过，现在想把它们组合起来用，能不能少算一点？\n这就是KV Fuse关注的问题。但模型处理文档时会受到前文和位置等因素影响，几份独立生成的KV Cache通常不能直接拼接。KV Fuse尝试通过缓存融合和部分重计算，保留其中能够复用的工作。\n如果问题出在“给模型看的东西太多”，KV Cascade则尝试先请辅助模型做筛选或处理，把相关内容交给主模型。例如，一大堆文档里只有部分信息和当前问题有关，就可以先缩小主模型需要处理的范围。\n而KV Infinity面向持续增长的长任务，通过按需加载和预取，尝试缓解缓存必须全部常驻HBM的压力，让系统能够利用显存之外的资源。具体能扩展到什么程度，仍然要看访问方式和传输效率。\n这些方向背后，英特尔想要做的事就已经比较清楚了：\n让CPU协助管理推理中产生的大量计算结果，再通过内存、存储和专用加速单元，把保存和使用这些结果的成本降下来。\n对于具备相应QAT硬件的至强服务器，这提供了一条利用已有平台能力的优化路径。当然，实际接入还要检查内存、存储和软件等条件。\n最后，再回到数据中心的那笔账。单个用户看到的，也许只是Coding Agent有没有及时回答；运营方要考虑的，则是成千上万个请求涌进来之后，系统还能不能以可接受的成本持续提供服务。\nKV Cache越大，全部留在显存里就越难；可如果把还有复用价值的缓存一清了之，GPU又得为同一段历史反复开工。运营方需要在保存、搬运和重算之间找到合适的平衡。\n英特尔押注KV Cache，争取的正是这个位置：通过CPU侧的管理、分层存储和硬件压缩，让已有计算结果能以更低的代价被保留和再次使用。\nGPU仍然负责模型计算，CPU和存储系统则协助减少那些本可以避免的重复工作。至于方案值不值得部署，最终还得看真实负载下的响应时间、吞吐量，以及把服务器、内存、存储和能耗都算进去的总成本。\n毕竟，运营方买下昂贵的GPU，是希望它多干点新活儿。已经算过、又能复用的内容，就尽量别再付一次计算的账。\n最后，若是小伙伴们想要了解更多关于英特尔CPU的最新进展，欢迎锁定9月22日-9月23日的英特尔技术创新与产业生态大会（关注【英特尔商用】报名参加）！","image_url":"https://n.sinaimg.cn/spider20260916/232/w660h372/20260916/9316-05677b6f6ee16212fe173876d9ae53ae.jpg","lang":"zh","published_at":"2026-09-16T03:44:29+00:00","fetched_at":"2026-09-16T04:15:07+00:00","status":"read","starred":0,"extract_state":"ok","summary_auto":"把记忆交给CPU，大模型会变快\n（来源：量子位）\n拿Agent做Coding，想必大家都已经很熟悉了。\n不过，如果我们把目光从聊天窗口移到背后的数据中心，事情就没那么简单了。\n一个Coding Agent改跨十几个文件的bug，需要反复读代码、查资料、跑测试。前几轮交互可能还很顺畅，但任务继续跑下去，系统要处理的历史信息也会越积越多。\n当成千上万个Agent同时这样干活，运营方就可能遇到一个头疼的问题：服务器还在跑，能接住的并发却越来越吃紧，有些请求连吐出第一个Token都要等上好一会儿。\n难道只能继续加GPU？\n非也非也。\n模型还是那个模型，服务器也还是那个服务器，问题的根儿啊，其实是出在了记忆。\n因为大模型每生成一个新的Token，都还要继续用到前文的信息。为了不用每次从头计算，系统会把前面已经算好的中间结果保存起来；会话越聊越长，这份记忆自然也就越堆越厚。\n一旦显存装不下，部分缓存被清走，等Agent下一轮又需要这些历史信息时，就可能重新做一遍Prefill。前面明明已经算过的东西，又得花GPU时间再算一次。\n尤其是到了Agent时代，AI很少干一问一答的事儿，更多是那种反复需要思考、规划和行动的任务，期间会不断积累会话历史、检索证据、工具结果和中间状态等等。\n于是乎，一个过去藏在大模型推理内部、普通用户几乎感知不到的东西，就这样被推到了台面儿上——KV Cache。\n它的特点，说起来就一个字：大。但运营方又不能为了省空间，任由已经算过的内容反复占用GPU重算。所以，长上下文推理要算的这笔账，也就从算力延伸到了存储、搬运和复用。\n而这件事的破局之道，并不是你以为的GPU，而是——CPU。\n我们先把KV Cache这件事说清楚。\n对于采用因果自注意力的Transformer模型来说，前面处理过的Token，会在注意力层中留下对应的Key和Value。模型生成后续Token时，还能继续使用这些结果。推理系统把它们缓存起来，就有了KV Cache。\n你可以把它理解成模型读书时做的笔记。后面再遇到需要联系上文的地方，模型可以调用笔记，省去对已有Token的重复计算。\n所以，我们这里说的记忆，指的是推理过程中留下的中间状态，模型的权重并没有因此发生变化。\n这份笔记确实能省计算，但它也是实实在在要占地方的。而且，Agent读的东西越多，服务器要替它保存的笔记往往就越厚。\n那么这个增长到底有多明显呢？\n我们拿Qwen3-8B算一笔账。按照它的公开模型配置，在KV Cache采用BF16或FP16、每个数值占2字节的条件下，每个Token对应的KV数据是147456字节，也就是约147KB。这还没有计入缓存管理等额外开销。\n为什么一个Token会带出这么大一份缓存？因为系统保存的并不是这个Token的文字本身，而是它在多层注意力计算中对应的Key和Value。按这个模型的结构，计算式就是：2份K/V × 36层 × 8个KV头 × 每头128维 × 2字节。\n接下来，我们只借用这个每Token开销，做一次百万上下文的容量推演：如果需要缓存100万个Token，对应的KV数据就约为147GB。注意，这里的1M是测算假设，不代表Qwen3-8B实际支持百万上下文；它的官方说明是原生32768 Token，采用YaRN可扩展到131072 Token。\n单个请求已经如此，如果把请求规模也放大呢？假设一个服务有300万日活用户，每人每天发出10个请求，而且每个请求都按前面的1M上下文计算，一天就是3000万个请求。\n先不考虑压缩和共享复用，按每个请求约147GB全量累加，对应的日累计KV数据规模就是：300万 × 10 × 147GB ≈ 4410PB。如果日活再增加到3亿，相同假设下，这个数字还会放大100倍，达到约441000PB，也就是441EB。\n不过，这里得分清两件事：一天的请求累计涉及多少KV数据，和数据中心同时需要存下多少KV数据，不是一回事。上面是每次请求都独立、全量计数的规模推演，不能直接当作存储采购清单。\n实际要配多大的缓存池，运营方还得看高峰时有多少请求同时运行、缓存要留多久、哪些前缀能够共享，以及压缩和淘汰策略。已经复用的同一份缓存，也不该因为被请求多次就重复占一份容量。\n当然，不同模型的“笔记本”也不一样。模型层数、KV头数量、缓存精度等都会影响大小，不能只看参数量。上面的数字不是某个服务的真实用量，却能说明运营方为什么要格外关注这份“记忆”：上下文长度和请求规模，会一起把缓存的账越算越大。\n而GPU的显存，还要放模型权重和运行时的其他数据。大家共用这么多空间，KV Cache占得越多，系统留给其他请求的余地就可能越小。\n这时候，推理系统就得做取舍了：减少同时处理的请求，把部分缓存卸载到其他存储层，或者清理暂时不用的缓存。\n再拿前面的Coding Agent来说。它可能正在等工具跑测试，系统趁这个空当，把它的一部分历史缓存清掉了。等测试结果返回，Agent准备接着干活，却发现需要用的缓存已经不在了。\n如果其他存储层也没保存这份数据，模型就得重新处理相应的历史输入、重建缓存。这个处理输入的阶段叫Prefill，输入越长，通常就越费时。用户等待首个Token的时间，也就是TTFT，便可能跟着增加。\n算过一遍的内容，过一会儿又得再算。对运营方来说，消耗掉的不只是电和时间，还有这批GPU原本可以用来处理新任务、生成新Token的机会。\n这也解释了，为什么KV Cache再大，运营方仍然要认真考虑怎么把它用好。\n从成本角度看，GPU应该尽量把资源花在必要的新输入处理和新Token生成上，少为已经处理过、又可以复用的历史内容重复做Prefill。KV Cache保留下来的，正是这部分已有计算的成果。\n当然，这不意味着所有缓存都得永久保存。真正要算的是：保留和取回一份缓存，能不能比下次重算更划算？谁能把这笔账算好，谁就更有机会用同一套设备服务更多请求。\n聊到这里，你可能已经想到了，显存放不下，难道不能先存到别处，等要用的时候再拿回来？\n可以，这也正是“以存代算”的思路。\n在服务器里，GPU显存之外还有CPU侧的DDR内存、本地SSD，以及远端存储。它们的容量、速度和成本各不相同，正好可以用来存放不同活跃程度的缓存。\n例如眼下正在生成回答，需要频繁访问的数据，就留在GPU的高带宽显存HBM里；短时间内可能继续用到的缓存，可以先放进CPU侧的DDR内存；至于更久没有访问、但还值得保留的历史缓存，则可以继续下沉到SSD或远端存储。\n再聚焦到Coding Agent的任务里，就是它写代码时，相关缓存尽量留在GPU侧；任务暂停后，系统可以把缓存转存到内存；如果这段会话很久没继续，再考虑把数据移到更下一层。用户回来后，系统根据缓存命中情况，把需要的部分取回来。\n对运营方来说，这样安排的直接好处是：显存不用一直替所有历史会话占着位置，腾出的空间可以交给正在运行的请求。\n不过，把东西搬出去只是第一步。哪些数据可以搬、应该放在哪里、什么时候得提前取回来，总得有个地方统一管理。\nCPU就在这里发挥作用。\n推理服务运行在主机侧的管理逻辑，需要跟踪会话状态、剩余容量和缓存访问情况。CPU连接的大容量内存和存储，也为显存之外的缓存池提供了基础。系统可以结合这些信息，决定一份KV Cache接下来该留在哪一层。\n这类机制其实已经出现在一些推理框架里了。例如，vLLM的KV Offloading支持将缓存块卸载到CPU内存，还可以配置次级存储层。在它描述的多层方案里，次级存储与GPU之间的数据传输，会经过CPU侧的缓存层。\n但这里还有个问题，那就是数据是存下来了，搬回来会不会更慢？\n毕竟，DDR、SSD和远端存储的访问条件各不相同。假如取回缓存比重新计算还费时，用户还是得等，甚至可能等得更久。所以，系统需要根据访问频率和传输开销安排缓存，不能一股脑地把数据全塞到硬盘里。\n要减少搬运量，另一个办法就是压缩。数据变小了，同样的空间能存得更多，传输时要搬的字节也更少。\n可压缩也不是白来的，压缩和解压都要花时间，如果全让通用CPU核心来干，又可能挤占请求调度等工作需要的资源。\n更麻烦的是，KV Cache本身就是大体量数据，压缩和解压的速度如果跟不上GPU侧的数据吞吐，压缩环节反而会成为新的瓶颈。单纯依靠通用CPU核心做软件压缩，很难同时兼顾高吞吐和CPU资源占用。\n这也是QAT的意义所在。它把压缩、解压交给专用硬件处理，在提升吞吐的同时释放通用CPU核心。相比只依赖CPU Core的软件方案，这种内置专用压缩加速能力，也构成了英特尔在KV Cache分层卸载上的一个差异化优势。\n于是问题就不只是能不能压，还变成了能不能压得足够快。\n对此，CPU老巨头英特尔给出了一套面向数据中心的KV Cache优化思路。\n围绕KV Cache，英特尔布局了KV Shrink、KV Fuse、KV Cascade和KV Infinity四个技术方向。\n名字虽然看着多，但我们用一张表格，根据它们各自要解决的问题来分类，就一目了然了：\n其中，KV Shrink已经有较具体的实现和测试披露，我们先来重点看看它。\nKV Shrink可以把前面讲的分层管理与硬件压缩结合起来，并提供冷热调度API，让业务系统按自己的策略决定缓存什么时候下沉、什么时候回载。内存吃紧时，系统还可以把较冷的数据继续转存到SSD等下一层介质。\n而负责分担压缩工作的，是英特尔的QAT（QuickAssist Technology）。\n它能够把压缩、解压等任务交给专用加速单元，减少对通用CPU核心的占用。英特尔从第四代至强可扩展处理器的相关型号开始集成QAT硬件。\n这么一来，CPU侧的管理逻辑继续负责调度，专用硬件接过压缩任务，系统便有机会在控制额外开销的同时，缩小缓存体积。\n英特尔还做了一个更细的调整：重新排列KV Cache的存储格式，让压缩算法更容易压缩这些数据。\n重排后，压缩所节省的空间从原先的10%以上增加到20%以上，空间降幅约为20%至30%。这条路径采用无损压缩，解压后能够恢复原始KV数据，不会因压缩而丢失数据。\n虽然20%-30%这个数字乍一看似乎没那么夸张，但把缓存池的规模放大，差别就出来了。\n例如，一个数据中心需要保留500TB的KV Cache，如果能压缩掉30%，对应的就是约150TB空间。这里算的是实际缓存池的容量，和前面按请求累加的日累计数据量不同。至于运营方最终能省下多少费用，还得结合存储介质、保留时间和业务负载来算，不能直接给总成本也打个七折。\n空间这块算是有收益了，那速度又怎么样呢？\n在英特尔给出的一组测试中，使用双路至强金牌6554S处理器、两张英伟达L20 GPU和Qwen3-32B模型，在80%缓存命中率下，相较未开启分层卸载的原生vLLM基线，KV Shrink在测试覆盖的输入长度和并发组合中，TTFT最高获得约5倍加速。\n除此之外，QAT硬件压缩方案的整体性能约为CPU软件压缩方案的两倍。在相同分层卸载机制下，相较不启用压缩，开启QAT压缩带来的额外TTFT开销低于10%。\n从这两项对照测试来看，压缩确实会多一道工序，但在这组测试里，专用硬件把额外开销控制在了较小范围内，让系统能够用一定的时间代价换取存储空间。\n再来看一组面向Coding Agent服务的测试。\n英特尔与道客联合实验室采用另一套配置进行测试：双路至强金牌6554S、八张H800和Qwen3-32B FP8模型，缓存命中率同样为80%。相较测试中的LMCache方案，KV Shrink在单路负载下的平均TTFT由129.81毫秒降至114.13毫秒，降幅约12.1%；八路并发时，降幅约为4.6%。\n你会发现，换一套设备、换一个比较对象，加速幅度也变了。所以数据中心运营方真正部署时，还是要把自己的上下文长度、并发量和缓存命中率带进去测试。业务里重复访问历史内容的机会越少，缓存复用能帮上的忙通常也越有限。\n除了把一段会话存好，运营方承载的企业服务还可能遇到另一类需求：几份文档以前都处理过，现在想把它们组合起来用，能不能少算一点？\n这就是KV Fuse关注的问题。但模型处理文档时会受到前文和位置等因素影响，几份独立生成的KV Cache通常不能直接拼接。KV Fuse尝试通过缓存融合和部分重计算，保留其中能够复用的工作。\n如果问题出在“给模型看的东西太多”，KV Cascade则尝试先请辅助模型做筛选或处理，把相关内容交给主模型。例如，一大堆文档里只有部分信息和当前问题有关，就可以先缩小主模型需要处理的范围。\n而KV Infinity面向持续增长的长任务，通过按需加载和预取，尝试缓解缓存必须全部常驻HBM的压力，让系统能够利用显存之外的资源。具体能扩展到什么程度，仍然要看访问方式和传输效率。\n这些方向背后，英特尔想要做的事就已经比较清楚了：\n让CPU协助管理推理中产生的大量计算结果，再通过内存、存储和专用加速单元，把保存和使用这些结果的成本降下来。\n对于具备相应QAT硬件的至强服务器，这提供了一条利用已有平台能力的优化路径。当然，实际接入还要检查内存、存储和软件等条件。\n最后，再回到数据中心的那笔账。单个用户看到的，也许只是Coding Agent有没有及时回答；运营方要考虑的，则是成千上万个请求涌进来之后，系统还能不能以可接受的成本持续提供服务。\nKV Cache越大，全部留在显存里就越难；可如果把还有复用价值的缓存一清了之，GPU又得为同一段历史反复开工。运营方需要在保存、搬运和重算之间找到合适的平衡。\n英特尔押注KV Cache，争取的正是这个位置：通过CPU侧的管理、分层存储和硬件压缩，让已有计算结果能以更低的代价被保留和再次使用。\nGPU仍然负责模型计算，CPU和存储系统则协助减少那些本可以避免的重复工作。至于方案值不值得部署，最终还得看真实负载下的响应时间、吞吐量，以及把服务器、内存、存储和能耗都算进去的总成本。\n毕竟，运营方买下昂贵的GPU，是希望它多干点新活儿。已经算过、又能复用的内容，就尽量别再付一次计算的账。\n最后，若是小伙伴们想要了解更多关于英特尔CPU的最新进展，欢迎锁定9月22日-9月23日的英特尔技术创新与产业生态大会（关注【英特尔商用】报名参加）！","cluster_id":null,"extract_retries":0,"extract_error":null,"contract_version":"news_item.v1","format_contract_version":"news_item_formats.v1","dedup_url":"https://finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html?vt=4&cid=76993&node_id=76993","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 5905 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":5905,"summary_length":5905,"usable_text_length":5905,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":5905,"summary_length":5905}},"news_item":{"id":83485,"canonical_url":"https://finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html?vt=4&cid=76993&node_id=76993","source_url":"https://finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html?vt=4&cid=76993&node_id=76993","title":"把记忆交给CPU，大模型会变快 - 新浪财经","source_name":"新浪财经","author":null,"published_at":"2026-09-16T03:44:29+00:00","locale":"zh","topic":"ai","tags":[],"rss_summary":"<a href=\"https://news.google.com/rss/articles/CBMipwFBVV95cUxNY3lPSHVydUtwQzFselAxLUllcG1PLWd1aFUyUUJDU2lQa0Y4UldfT0RxdkNxTmtrWldBYXBSVW1RYVRpbDkxZkM2cTZReFZYV0FCTlgwQmVBNHVMZ3poaVh0aEltVkx3ek1fRkN5Qm5FZkpUYmdiVkZhSHJJVWFjS1ZYWEVpZlNaaWwyU0hIT3l5T0VBd29GWFYwbWZkazV6SFVvUnFHRQ?oc=5\" target=\"_blank\">把记忆交给CPU，大模型会变快</a>&nbsp;&nbsp;<font color=\"#6f6f6f\">新浪财经</font>","full_text":"把记忆交给CPU，大模型会变快\n（来源：量子位）\n拿Agent做Coding，想必大家都已经很熟悉了。\n不过，如果我们把目光从聊天窗口移到背后的数据中心，事情就没那么简单了。\n一个Coding Agent改跨十几个文件的bug，需要反复读代码、查资料、跑测试。前几轮交互可能还很顺畅，但任务继续跑下去，系统要处理的历史信息也会越积越多。\n当成千上万个Agent同时这样干活，运营方就可能遇到一个头疼的问题：服务器还在跑，能接住的并发却越来越吃紧，有些请求连吐出第一个Token都要等上好一会儿。\n难道只能继续加GPU？\n非也非也。\n模型还是那个模型，服务器也还是那个服务器，问题的根儿啊，其实是出在了记忆。\n因为大模型每生成一个新的Token，都还要继续用到前文的信息。为了不用每次从头计算，系统会把前面已经算好的中间结果保存起来；会话越聊越长，这份记忆自然也就越堆越厚。\n一旦显存装不下，部分缓存被清走，等Agent下一轮又需要这些历史信息时，就可能重新做一遍Prefill。前面明明已经算过的东西，又得花GPU时间再算一次。\n尤其是到了Agent时代，AI很少干一问一答的事儿，更多是那种反复需要思考、规划和行动的任务，期间会不断积累会话历史、检索证据、工具结果和中间状态等等。\n于是乎，一个过去藏在大模型推理内部、普通用户几乎感知不到的东西，就这样被推到了台面儿上——KV Cache。\n它的特点，说起来就一个字：大。但运营方又不能为了省空间，任由已经算过的内容反复占用GPU重算。所以，长上下文推理要算的这笔账，也就从算力延伸到了存储、搬运和复用。\n而这件事的破局之道，并不是你以为的GPU，而是——CPU。\n我们先把KV Cache这件事说清楚。\n对于采用因果自注意力的Transformer模型来说，前面处理过的Token，会在注意力层中留下对应的Key和Value。模型生成后续Token时，还能继续使用这些结果。推理系统把它们缓存起来，就有了KV Cache。\n你可以把它理解成模型读书时做的笔记。后面再遇到需要联系上文的地方，模型可以调用笔记，省去对已有Token的重复计算。\n所以，我们这里说的记忆，指的是推理过程中留下的中间状态，模型的权重并没有因此发生变化。\n这份笔记确实能省计算，但它也是实实在在要占地方的。而且，Agent读的东西越多，服务器要替它保存的笔记往往就越厚。\n那么这个增长到底有多明显呢？\n我们拿Qwen3-8B算一笔账。按照它的公开模型配置，在KV Cache采用BF16或FP16、每个数值占2字节的条件下，每个Token对应的KV数据是147456字节，也就是约147KB。这还没有计入缓存管理等额外开销。\n为什么一个Token会带出这么大一份缓存？因为系统保存的并不是这个Token的文字本身，而是它在多层注意力计算中对应的Key和Value。按这个模型的结构，计算式就是：2份K/V × 36层 × 8个KV头 × 每头128维 × 2字节。\n接下来，我们只借用这个每Token开销，做一次百万上下文的容量推演：如果需要缓存100万个Token，对应的KV数据就约为147GB。注意，这里的1M是测算假设，不代表Qwen3-8B实际支持百万上下文；它的官方说明是原生32768 Token，采用YaRN可扩展到131072 Token。\n单个请求已经如此，如果把请求规模也放大呢？假设一个服务有300万日活用户，每人每天发出10个请求，而且每个请求都按前面的1M上下文计算，一天就是3000万个请求。\n先不考虑压缩和共享复用，按每个请求约147GB全量累加，对应的日累计KV数据规模就是：300万 × 10 × 147GB ≈ 4410PB。如果日活再增加到3亿，相同假设下，这个数字还会放大100倍，达到约441000PB，也就是441EB。\n不过，这里得分清两件事：一天的请求累计涉及多少KV数据，和数据中心同时需要存下多少KV数据，不是一回事。上面是每次请求都独立、全量计数的规模推演，不能直接当作存储采购清单。\n实际要配多大的缓存池，运营方还得看高峰时有多少请求同时运行、缓存要留多久、哪些前缀能够共享，以及压缩和淘汰策略。已经复用的同一份缓存，也不该因为被请求多次就重复占一份容量。\n当然，不同模型的“笔记本”也不一样。模型层数、KV头数量、缓存精度等都会影响大小，不能只看参数量。上面的数字不是某个服务的真实用量，却能说明运营方为什么要格外关注这份“记忆”：上下文长度和请求规模，会一起把缓存的账越算越大。\n而GPU的显存，还要放模型权重和运行时的其他数据。大家共用这么多空间，KV Cache占得越多，系统留给其他请求的余地就可能越小。\n这时候，推理系统就得做取舍了：减少同时处理的请求，把部分缓存卸载到其他存储层，或者清理暂时不用的缓存。\n再拿前面的Coding Agent来说。它可能正在等工具跑测试，系统趁这个空当，把它的一部分历史缓存清掉了。等测试结果返回，Agent准备接着干活，却发现需要用的缓存已经不在了。\n如果其他存储层也没保存这份数据，模型就得重新处理相应的历史输入、重建缓存。这个处理输入的阶段叫Prefill，输入越长，通常就越费时。用户等待首个Token的时间，也就是TTFT，便可能跟着增加。\n算过一遍的内容，过一会儿又得再算。对运营方来说，消耗掉的不只是电和时间，还有这批GPU原本可以用来处理新任务、生成新Token的机会。\n这也解释了，为什么KV Cache再大，运营方仍然要认真考虑怎么把它用好。\n从成本角度看，GPU应该尽量把资源花在必要的新输入处理和新Token生成上，少为已经处理过、又可以复用的历史内容重复做Prefill。KV Cache保留下来的，正是这部分已有计算的成果。\n当然，这不意味着所有缓存都得永久保存。真正要算的是：保留和取回一份缓存，能不能比下次重算更划算？谁能把这笔账算好，谁就更有机会用同一套设备服务更多请求。\n聊到这里，你可能已经想到了，显存放不下，难道不能先存到别处，等要用的时候再拿回来？\n可以，这也正是“以存代算”的思路。\n在服务器里，GPU显存之外还有CPU侧的DDR内存、本地SSD，以及远端存储。它们的容量、速度和成本各不相同，正好可以用来存放不同活跃程度的缓存。\n例如眼下正在生成回答，需要频繁访问的数据，就留在GPU的高带宽显存HBM里；短时间内可能继续用到的缓存，可以先放进CPU侧的DDR内存；至于更久没有访问、但还值得保留的历史缓存，则可以继续下沉到SSD或远端存储。\n再聚焦到Coding Agent的任务里，就是它写代码时，相关缓存尽量留在GPU侧；任务暂停后，系统可以把缓存转存到内存；如果这段会话很久没继续，再考虑把数据移到更下一层。用户回来后，系统根据缓存命中情况，把需要的部分取回来。\n对运营方来说，这样安排的直接好处是：显存不用一直替所有历史会话占着位置，腾出的空间可以交给正在运行的请求。\n不过，把东西搬出去只是第一步。哪些数据可以搬、应该放在哪里、什么时候得提前取回来，总得有个地方统一管理。\nCPU就在这里发挥作用。\n推理服务运行在主机侧的管理逻辑，需要跟踪会话状态、剩余容量和缓存访问情况。CPU连接的大容量内存和存储，也为显存之外的缓存池提供了基础。系统可以结合这些信息，决定一份KV Cache接下来该留在哪一层。\n这类机制其实已经出现在一些推理框架里了。例如，vLLM的KV Offloading支持将缓存块卸载到CPU内存，还可以配置次级存储层。在它描述的多层方案里，次级存储与GPU之间的数据传输，会经过CPU侧的缓存层。\n但这里还有个问题，那就是数据是存下来了，搬回来会不会更慢？\n毕竟，DDR、SSD和远端存储的访问条件各不相同。假如取回缓存比重新计算还费时，用户还是得等，甚至可能等得更久。所以，系统需要根据访问频率和传输开销安排缓存，不能一股脑地把数据全塞到硬盘里。\n要减少搬运量，另一个办法就是压缩。数据变小了，同样的空间能存得更多，传输时要搬的字节也更少。\n可压缩也不是白来的，压缩和解压都要花时间，如果全让通用CPU核心来干，又可能挤占请求调度等工作需要的资源。\n更麻烦的是，KV Cache本身就是大体量数据，压缩和解压的速度如果跟不上GPU侧的数据吞吐，压缩环节反而会成为新的瓶颈。单纯依靠通用CPU核心做软件压缩，很难同时兼顾高吞吐和CPU资源占用。\n这也是QAT的意义所在。它把压缩、解压交给专用硬件处理，在提升吞吐的同时释放通用CPU核心。相比只依赖CPU Core的软件方案，这种内置专用压缩加速能力，也构成了英特尔在KV Cache分层卸载上的一个差异化优势。\n于是问题就不只是能不能压，还变成了能不能压得足够快。\n对此，CPU老巨头英特尔给出了一套面向数据中心的KV Cache优化思路。\n围绕KV Cache，英特尔布局了KV Shrink、KV Fuse、KV Cascade和KV Infinity四个技术方向。\n名字虽然看着多，但我们用一张表格，根据它们各自要解决的问题来分类，就一目了然了：\n其中，KV Shrink已经有较具体的实现和测试披露，我们先来重点看看它。\nKV Shrink可以把前面讲的分层管理与硬件压缩结合起来，并提供冷热调度API，让业务系统按自己的策略决定缓存什么时候下沉、什么时候回载。内存吃紧时，系统还可以把较冷的数据继续转存到SSD等下一层介质。\n而负责分担压缩工作的，是英特尔的QAT（QuickAssist Technology）。\n它能够把压缩、解压等任务交给专用加速单元，减少对通用CPU核心的占用。英特尔从第四代至强可扩展处理器的相关型号开始集成QAT硬件。\n这么一来，CPU侧的管理逻辑继续负责调度，专用硬件接过压缩任务，系统便有机会在控制额外开销的同时，缩小缓存体积。\n英特尔还做了一个更细的调整：重新排列KV Cache的存储格式，让压缩算法更容易压缩这些数据。\n重排后，压缩所节省的空间从原先的10%以上增加到20%以上，空间降幅约为20%至30%。这条路径采用无损压缩，解压后能够恢复原始KV数据，不会因压缩而丢失数据。\n虽然20%-30%这个数字乍一看似乎没那么夸张，但把缓存池的规模放大，差别就出来了。\n例如，一个数据中心需要保留500TB的KV Cache，如果能压缩掉30%，对应的就是约150TB空间。这里算的是实际缓存池的容量，和前面按请求累加的日累计数据量不同。至于运营方最终能省下多少费用，还得结合存储介质、保留时间和业务负载来算，不能直接给总成本也打个七折。\n空间这块算是有收益了，那速度又怎么样呢？\n在英特尔给出的一组测试中，使用双路至强金牌6554S处理器、两张英伟达L20 GPU和Qwen3-32B模型，在80%缓存命中率下，相较未开启分层卸载的原生vLLM基线，KV Shrink在测试覆盖的输入长度和并发组合中，TTFT最高获得约5倍加速。\n除此之外，QAT硬件压缩方案的整体性能约为CPU软件压缩方案的两倍。在相同分层卸载机制下，相较不启用压缩，开启QAT压缩带来的额外TTFT开销低于10%。\n从这两项对照测试来看，压缩确实会多一道工序，但在这组测试里，专用硬件把额外开销控制在了较小范围内，让系统能够用一定的时间代价换取存储空间。\n再来看一组面向Coding Agent服务的测试。\n英特尔与道客联合实验室采用另一套配置进行测试：双路至强金牌6554S、八张H800和Qwen3-32B FP8模型，缓存命中率同样为80%。相较测试中的LMCache方案，KV Shrink在单路负载下的平均TTFT由129.81毫秒降至114.13毫秒，降幅约12.1%；八路并发时，降幅约为4.6%。\n你会发现，换一套设备、换一个比较对象，加速幅度也变了。所以数据中心运营方真正部署时，还是要把自己的上下文长度、并发量和缓存命中率带进去测试。业务里重复访问历史内容的机会越少，缓存复用能帮上的忙通常也越有限。\n除了把一段会话存好，运营方承载的企业服务还可能遇到另一类需求：几份文档以前都处理过，现在想把它们组合起来用，能不能少算一点？\n这就是KV Fuse关注的问题。但模型处理文档时会受到前文和位置等因素影响，几份独立生成的KV Cache通常不能直接拼接。KV Fuse尝试通过缓存融合和部分重计算，保留其中能够复用的工作。\n如果问题出在“给模型看的东西太多”，KV Cascade则尝试先请辅助模型做筛选或处理，把相关内容交给主模型。例如，一大堆文档里只有部分信息和当前问题有关，就可以先缩小主模型需要处理的范围。\n而KV Infinity面向持续增长的长任务，通过按需加载和预取，尝试缓解缓存必须全部常驻HBM的压力，让系统能够利用显存之外的资源。具体能扩展到什么程度，仍然要看访问方式和传输效率。\n这些方向背后，英特尔想要做的事就已经比较清楚了：\n让CPU协助管理推理中产生的大量计算结果，再通过内存、存储和专用加速单元，把保存和使用这些结果的成本降下来。\n对于具备相应QAT硬件的至强服务器，这提供了一条利用已有平台能力的优化路径。当然，实际接入还要检查内存、存储和软件等条件。\n最后，再回到数据中心的那笔账。单个用户看到的，也许只是Coding Agent有没有及时回答；运营方要考虑的，则是成千上万个请求涌进来之后，系统还能不能以可接受的成本持续提供服务。\nKV Cache越大，全部留在显存里就越难；可如果把还有复用价值的缓存一清了之，GPU又得为同一段历史反复开工。运营方需要在保存、搬运和重算之间找到合适的平衡。\n英特尔押注KV Cache，争取的正是这个位置：通过CPU侧的管理、分层存储和硬件压缩，让已有计算结果能以更低的代价被保留和再次使用。\nGPU仍然负责模型计算，CPU和存储系统则协助减少那些本可以避免的重复工作。至于方案值不值得部署，最终还得看真实负载下的响应时间、吞吐量，以及把服务器、内存、存储和能耗都算进去的总成本。\n毕竟，运营方买下昂贵的GPU，是希望它多干点新活儿。已经算过、又能复用的内容，就尽量别再付一次计算的账。\n最后，若是小伙伴们想要了解更多关于英特尔CPU的最新进展，欢迎锁定9月22日-9月23日的英特尔技术创新与产业生态大会（关注【英特尔商用】报名参加）！","excerpt":"把记忆交给CPU，大模型会变快\n（来源：量子位）\n拿Agent做Coding，想必大家都已经很熟悉了。\n不过，如果我们把目光从聊天窗口移到背后的数据中心，事情就没那么简单了。\n一个Coding Agent改跨十几个文件的bug，需要反复读代码、查资料、跑测试。前几轮交互可能还很顺畅，但任务继续跑下去，系统要处理的历史信息也会越积越多。\n当成千上万个Agent同时这样干活，运营方就可能遇到一个头疼的问题：服务器还在跑，能接住的并发却越来越吃紧，有些请求连吐出第一个Token都要等上好一会儿。\n难道只能继续加GPU？\n非也非也。\n模型还是那个模型，服务器也还是那个服务器，问题的根儿啊，其实是出在了记忆。\n因为大模型每生成一个新的Token，都还要继续用到前文的信息。为了不用每次从头计算，系统会把前面已经算好的中间结果保存起来；会话越聊越长，这份记忆自然也就越堆越厚。\n一旦显存装不下，部分缓存被清走，等Agent下一轮又需要这些历史信息时，就可能重新做一遍Prefill。前面明明已经算过的东西，又得花GPU时间再算一次。\n尤其是到了Agent时代，AI很少干一问一答的事儿，更多是那种反复需要思考、规划和行动的任务，期间会不断积累会话历史、检索证据、工具结果和中间状态等等。\n于是乎，一个过去藏在大模型推理内部、普通用户几乎感知不到的东西，就这样被推到了台面儿上——KV Cache。\n它的特点，说起来就一个字：大。但运营方又不能为了省空间，任由已经算过的内容反复占用GPU重算。所以，长上下文推理要算的这笔账，也就从算力延伸到了存储、搬运和复用。\n而这件事的破局之道，并不是你以为的GPU，而是——CPU。\n我们先把KV Cache这件事说清楚。\n对于采用因果自注意力的Transformer模型来说，前面处理过的Token，会在注意力层中留下对应的Key和Value。模型生成后续Token时，还能继续使用这些结果。推理系统把它们缓存起来，就有了KV Cache。\n你可以把它理解成模型读书时做的笔记。后面再遇到需要联系上文的地方，模型可以调用笔记，省去对已有Token的重复计算。\n所以，我们这里说的记忆，指的是推理过程中留下的中间状态，模型的权重并没有因此发生变化。\n这份笔记确实能省计算，但它也是实实在在要占地方的。而且，Agent读的东西越多，服务器要替它保存的笔记往往就越厚。\n那么这个增长到底有多明显呢？\n我们拿Qwen3-8B算一笔账。按照它的公开模型配置，在KV Cache采用BF16或FP16、每个数值占2字节的条件下，每个Token对应的KV数据是147456字节，也就是约147KB。这还没有计入缓存管理等额外开销。\n为什么一个Token会带出这么大一份缓存？因为系统保存的并不是这个Token的文字本身，而是它在多层注意力计算中对应的Key和Value。按这个模型的结构，计算式就是：2份K/V × 36层 × 8个KV头 × 每头128维 × 2字节。\n接下来，我们只借用这个每Token开销，做一次百万上下文的容量推演：如果需要缓存100万个Token，对应的KV数据就约为147GB。注意，这里的1M是测算假设，不代表Qwen3-8B实际支持百万上下文；它的官方说明是原生32768 Token，采用YaRN可扩展到131072 Token。\n单个请求已经如此，如果把请求规模也放大呢？假设一个服务有300万日活用户，每人每天发出10个请求，而且每个请求都按前面的1M上下文计算，一天就是3000万个请求。\n先不考虑压缩和共享复用，按每个请求约147GB全量累加，对应的日累计KV数据规模就是：300万 × 10 × 147GB ≈ 4410PB。如果日活再增加到3亿，相同假设下，这个数字还会放大100倍，达到约441000PB，也就是441EB。\n不过，这里得分清两件事：一天的请求累计涉及多少KV数据，和数据中心同时需要存下多少KV数据，不是一回事。上面是每次请求都独立、全量计数的规模推演，不能直接当作存储采购清单。\n实际要配多大的缓存池，运营方还得看高峰时有多少请求同时运行、缓存要留多久、哪些前缀能够共享，以及压缩和淘汰策略。已经复用的同一份缓存，也不该因为被请求多次就重复占一份容量。\n当然，不同模型的“笔记本”也不一样。模型层数、KV头数量、缓存精度等都会影响大小，不能只看参数量。上面的数字不是某个服务的真实用量，却能说明运营方为什么要格外关注这份“记忆”：上下文长度和请求规模，会一起把缓存的账越算越大。\n而GPU的显存，还要放模型权重和运行时的其他数据。大家共用这么多空间，KV Cache占得越多，系统留给其他请求的余地就可能越小。\n这时候，推理系统就得做取舍了：减少同时处理的请求，把部分缓存卸载到其他存储层，或者清理暂时不用的缓存。\n再拿前面的Coding Agent来说。它可能正在等工具跑测试，系统趁这个空当，把它的一部分历史缓存清掉了。等测试结果返回，Agent准备接着干活，却发现需要用的缓存已经不在了。\n如果其他存储层也没保存这份数据，模型就得重新处理相应的历史输入、重建缓存。这个处理输入的阶段叫Prefill，输入越长，通常就越费时。用户等待首个Token的时间，也就是TTFT，便可能跟着增加。\n算过一遍的内容，过一会儿又得再算。对运营方来说，消耗掉的不只是电和时间，还有这批GPU原本可以用来处理新任务、生成新Token的机会。\n这也解释了，为什么KV Cache再大，运营方仍然要认真考虑怎么把它用好。\n从成本角度看，GPU应该尽量把资源花在必要的新输入处理和新Token生成上，少为已经处理过、又可以复用的历史内容重复做Prefill。KV Cache保留下来的，正是这部分已有计算的成果。\n当然，这不意味着所有缓存都得永久保存。真正要算的是：保留和取回一份缓存，能不能比下次重算更划算？谁能把这笔账算好，谁就更有机会用同一套设备服务更多请求。\n聊到这里，你可能已经想到了，显存放不下，难道不能先存到别处，等要用的时候再拿回来？\n可以，这也正是“以存代算”的思路。\n在服务器里，GPU显存之外还有CPU侧的DDR内存、本地SSD，以及远端存储。它们的容量、速度和成本各不相同，正好可以用来存放不同活跃程度的缓存。\n例如眼下正在生成回答，需要频繁访问的数据，就留在GPU的高带宽显存HBM里；短时间内可能继续用到的缓存，可以先放进CPU侧的DDR内存；至于更久没有访问、但还值得保留的历史缓存，则可以继续下沉到SSD或远端存储。\n再聚焦到Coding Agent的任务里，就是它写代码时，相关缓存尽量留在GPU侧；任务暂停后，系统可以把缓存转存到内存；如果这段会话很久没继续，再考虑把数据移到更下一层。用户回来后，系统根据缓存命中情况，把需要的部分取回来。\n对运营方来说，这样安排的直接好处是：显存不用一直替所有历史会话占着位置，腾出的空间可以交给正在运行的请求。\n不过，把东西搬出去只是第一步。哪些数据可以搬、应该放在哪里、什么时候得提前取回来，总得有个地方统一管理。\nCPU就在这里发挥作用。\n推理服务运行在主机侧的管理逻辑，需要跟踪会话状态、剩余容量和缓存访问情况。CPU连接的大容量内存和存储，也为显存之外的缓存池提供了基础。系统可以结合这些信息，决定一份KV Cache接下来该留在哪一层。\n这类机制其实已经出现在一些推理框架里了。例如，vLLM的KV Offloading支持将缓存块卸载到CPU内存，还可以配置次级存储层。在它描述的多层方案里，次级存储与GPU之间的数据传输，会经过CPU侧的缓存层。\n但这里还有个问题，那就是数据是存下来了，搬回来会不会更慢？\n毕竟，DDR、SSD和远端存储的访问条件各不相同。假如取回缓存比重新计算还费时，用户还是得等，甚至可能等得更久。所以，系统需要根据访问频率和传输开销安排缓存，不能一股脑地把数据全塞到硬盘里。\n要减少搬运量，另一个办法就是压缩。数据变小了，同样的空间能存得更多，传输时要搬的字节也更少。\n可压缩也不是白来的，压缩和解压都要花时间，如果全让通用CPU核心来干，又可能挤占请求调度等工作需要的资源。\n更麻烦的是，KV Cache本身就是大体量数据，压缩和解压的速度如果跟不上GPU侧的数据吞吐，压缩环节反而会成为新的瓶颈。单纯依靠通用CPU核心做软件压缩，很难同时兼顾高吞吐和CPU资源占用。\n这也是QAT的意义所在。它把压缩、解压交给专用硬件处理，在提升吞吐的同时释放通用CPU核心。相比只依赖CPU Core的软件方案，这种内置专用压缩加速能力，也构成了英特尔在KV Cache分层卸载上的一个差异化优势。\n于是问题就不只是能不能压，还变成了能不能压得足够快。\n对此，CPU老巨头英特尔给出了一套面向数据中心的KV Cache优化思路。\n围绕KV Cache，英特尔布局了KV Shrink、KV Fuse、KV Cascade和KV Infinity四个技术方向。\n名字虽然看着多，但我们用一张表格，根据它们各自要解决的问题来分类，就一目了然了：\n其中，KV Shrink已经有较具体的实现和测试披露，我们先来重点看看它。\nKV Shrink可以把前面讲的分层管理与硬件压缩结合起来，并提供冷热调度API，让业务系统按自己的策略决定缓存什么时候下沉、什么时候回载。内存吃紧时，系统还可以把较冷的数据继续转存到SSD等下一层介质。\n而负责分担压缩工作的，是英特尔的QAT（QuickAssist Technology）。\n它能够把压缩、解压等任务交给专用加速单元，减少对通用CPU核心的占用。英特尔从第四代至强可扩展处理器的相关型号开始集成QAT硬件。\n这么一来，CPU侧的管理逻辑继续负责调度，专用硬件接过压缩任务，系统便有机会在控制额外开销的同时，缩小缓存体积。\n英特尔还做了一个更细的调整：重新排列KV Cache的存储格式，让压缩算法更容易压缩这些数据。\n重排后，压缩所节省的空间从原先的10%以上增加到20%以上，空间降幅约为20%至30%。这条路径采用无损压缩，解压后能够恢复原始KV数据，不会因压缩而丢失数据。\n虽然20%-30%这个数字乍一看似乎没那么夸张，但把缓存池的规模放大，差别就出来了。\n例如，一个数据中心需要保留500TB的KV Cache，如果能压缩掉30%，对应的就是约150TB空间。这里算的是实际缓存池的容量，和前面按请求累加的日累计数据量不同。至于运营方最终能省下多少费用，还得结合存储介质、保留时间和业务负载来算，不能直接给总成本也打个七折。\n空间这块算是有收益了，那速度又怎么样呢？\n在英特尔给出的一组测试中，使用双路至强金牌6554S处理器、两张英伟达L20 GPU和Qwen3-32B模型，在80%缓存命中率下，相较未开启分层卸载的原生vLLM基线，KV Shrink在测试覆盖的输入长度和并发组合中，TTFT最高获得约5倍加速。\n除此之外，QAT硬件压缩方案的整体性能约为CPU软件压缩方案的两倍。在相同分层卸载机制下，相较不启用压缩，开启QAT压缩带来的额外TTFT开销低于10%。\n从这两项对照测试来看，压缩确实会多一道工序，但在这组测试里，专用硬件把额外开销控制在了较小范围内，让系统能够用一定的时间代价换取存储空间。\n再来看一组面向Coding Agent服务的测试。\n英特尔与道客联合实验室采用另一套配置进行测试：双路至强金牌6554S、八张H800和Qwen3-32B FP8模型，缓存命中率同样为80%。相较测试中的LMCache方案，KV Shrink在单路负载下的平均TTFT由129.81毫秒降至114.13毫秒，降幅约12.1%；八路并发时，降幅约为4.6%。\n你会发现，换一套设备、换一个比较对象，加速幅度也变了。所以数据中心运营方真正部署时，还是要把自己的上下文长度、并发量和缓存命中率带进去测试。业务里重复访问历史内容的机会越少，缓存复用能帮上的忙通常也越有限。\n除了把一段会话存好，运营方承载的企业服务还可能遇到另一类需求：几份文档以前都处理过，现在想把它们组合起来用，能不能少算一点？\n这就是KV Fuse关注的问题。但模型处理文档时会受到前文和位置等因素影响，几份独立生成的KV Cache通常不能直接拼接。KV Fuse尝试通过缓存融合和部分重计算，保留其中能够复用的工作。\n如果问题出在“给模型看的东西太多”，KV Cascade则尝试先请辅助模型做筛选或处理，把相关内容交给主模型。例如，一大堆文档里只有部分信息和当前问题有关，就可以先缩小主模型需要处理的范围。\n而KV Infinity面向持续增长的长任务，通过按需加载和预取，尝试缓解缓存必须全部常驻HBM的压力，让系统能够利用显存之外的资源。具体能扩展到什么程度，仍然要看访问方式和传输效率。\n这些方向背后，英特尔想要做的事就已经比较清楚了：\n让CPU协助管理推理中产生的大量计算结果，再通过内存、存储和专用加速单元，把保存和使用这些结果的成本降下来。\n对于具备相应QAT硬件的至强服务器，这提供了一条利用已有平台能力的优化路径。当然，实际接入还要检查内存、存储和软件等条件。\n最后，再回到数据中心的那笔账。单个用户看到的，也许只是Coding Agent有没有及时回答；运营方要考虑的，则是成千上万个请求涌进来之后，系统还能不能以可接受的成本持续提供服务。\nKV Cache越大，全部留在显存里就越难；可如果把还有复用价值的缓存一清了之，GPU又得为同一段历史反复开工。运营方需要在保存、搬运和重算之间找到合适的平衡。\n英特尔押注KV Cache，争取的正是这个位置：通过CPU侧的管理、分层存储和硬件压缩，让已有计算结果能以更低的代价被保留和再次使用。\nGPU仍然负责模型计算，CPU和存储系统则协助减少那些本可以避免的重复工作。至于方案值不值得部署，最终还得看真实负载下的响应时间、吞吐量，以及把服务器、内存、存储和能耗都算进去的总成本。\n毕竟，运营方买下昂贵的GPU，是希望它多干点新活儿。已经算过、又能复用的内容，就尽量别再付一次计算的账。\n最后，若是小伙伴们想要了解更多关于英特尔CPU的最新进展，欢迎锁定9月22日-9月23日的英特尔技术创新与产业生态大会（关注【英特尔商用】报名参加）！","extraction":{"state":"ok","confidence":0.9,"error":null,"explanation":"High confidence: full text extraction produced 5905 characters.","diagnostics_url":"/api/diagnose?url=https%3A//finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html%3Fvt%3D4%26cid%3D76993%26node_id%3D76993","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 5905 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":5905,"summary_length":5905,"usable_text_length":5905,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":5905,"summary_length":5905}}},"display_formats":["compact","card","full","digest_section","json"]},"daily_stack_record":{"title":"把记忆交给CPU，大模型会变快 - 新浪财经","url":"https://finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html?vt=4&cid=76993&node_id=76993","summary":"把记忆交给CPU，大模型会变快\n（来源：量子位）\n拿Agent做Coding，想必大家都已经很熟悉了。\n不过，如果我们把目光从聊天窗口移到背后的数据中心，事情就没那么简单了。\n一个Coding Agent改跨十几个文件的bug，需要反复读代码、查资料、跑测试。前几轮交互可能还很顺畅，但任务继续跑下去，系统要处理的历史信息也会越积越多。\n当成千上万个Agent同时这样干活，运营方就可能遇到一个头疼的问题：服务器还在跑，能接住的并发却越来越吃紧，有些请求连吐出第一个Token都要等上好一会儿。\n难道只能继续加GPU？\n非也非也。\n模型还是那个模型，服务器也还是那个服务器，问题的根儿啊，其实是出在了记忆。\n因为大模型每生成一个新的Token，都还要继续用到前文的信息。为了不用每次从头计算，系统会把前面已经算好的中间结果保存起来；会话越聊越长，这份记忆自然也就越堆越厚。\n一旦显存装不下，部分缓存被清走，等Agent下一轮又需要这些历史信息时，就可能重新做一遍Prefill。前面明明已经算过的东西，又得花GPU时间再算一次。\n尤其是到了Agent时代，AI很少干一问一答的事儿，更多是那种反复需要思考、规划和行动的任务，期间会不断积累会话历史、检索证据、工具结果和中间状态等等。\n于是乎，一个过去藏在大模型推理内部、普通用户几乎感知不到的东西，就这样被推到了台面儿上——KV Cache。\n它的特点，说起来就一个字：大。但运营方又不能为了省空间，任由已经算过的内容反复占用GPU重算。所以，长上下文推理要算的这笔账，也就从算力延伸到了存储、搬运和复用。\n而这件事的破局之道，并不是你以为的GPU，而是——CPU。\n我们先把KV Cache这件事说清楚。\n对于采用因果自注意力的Transformer模型来说，前面处理过的Token，会在注意力层中留下对应的Key和Value。模型生成后续Token时，还能继续使用这些结果。推理系统把它们缓存起来，就有了KV Cache。\n你可以把它理解成模型读书时做的笔记。后面再遇到需要联系上文的地方，模型可以调用笔记，省去对已有Token的重复计算。\n所以，我们这里说的记忆，指的是推理过程中留下的中间状态，模型的权重并没有因此发生变化。\n这份笔记确实能省计算，但它也是实实在在要占地方的。而且，Agent读的东西越多，服务器要替它保存的笔记往往就越厚。\n那么这个增长到底有多明显呢？\n我们拿Qwen3-8B算一笔账。按照它的公开模型配置，在KV Cache采用BF16或FP16、每个数值占2字节的条件下，每个Token对应的KV数据是147456字节，也就是约147KB。这还没有计入缓存管理等额外开销。\n为什么一个Token会带出这么大一份缓存？因为系统保存的并不是这个Token的文字本身，而是它在多层注意力计算中对应的Key和Value。按这个模型的结构，计算式就是：2份K/V × 36层 × 8个KV头 × 每头128维 × 2字节。\n接下来，我们只借用这个每Token开销，做一次百万上下文的容量推演：如果需要缓存100万个Token，对应的KV数据就约为147GB。注意，这里的1M是测算假设，不代表Qwen3-8B实际支持百万上下文；它的官方说明是原生32768 Token，采用YaRN可扩展到131072 Token。\n单个请求已经如此，如果把请求规模也放大呢？假设一个服务有300万日活用户，每人每天发出10个请求，而且每个请求都按前面的1M上下文计算，一天就是3000万个请求。\n先不考虑压缩和共享复用，按每个请求约147GB全量累加，对应的日累计KV数据规模就是：300万 × 10 × 147GB ≈ 4410PB。如果日活再增加到3亿，相同假设下，这个数字还会放大100倍，达到约441000PB，也就是441EB。\n不过，这里得分清两件事：一天的请求累计涉及多少KV数据，和数据中心同时需要存下多少KV数据，不是一回事。上面是每次请求都独立、全量计数的规模推演，不能直接当作存储采购清单。\n实际要配多大的缓存池，运营方还得看高峰时有多少请求同时运行、缓存要留多久、哪些前缀能够共享，以及压缩和淘汰策略。已经复用的同一份缓存，也不该因为被请求多次就重复占一份容量。\n当然，不同模型的“笔记本”也不一样。模型层数、KV头数量、缓存精度等都会影响大小，不能只看参数量。上面的数字不是某个服务的真实用量，却能说明运营方为什么要格外关注这份“记忆”：上下文长度和请求规模，会一起把缓存的账越算越大。\n而GPU的显存，还要放模型权重和运行时的其他数据。大家共用这么多空间，KV Cache占得越多，系统留给其他请求的余地就可能越小。\n这时候，推理系统就得做取舍了：减少同时处理的请求，把部分缓存卸载到其他存储层，或者清理暂时不用的缓存。\n再拿前面的Coding Agent来说。它可能正在等工具跑测试，系统趁这个空当，把它的一部分历史缓存清掉了。等测试结果返回，Agent准备接着干活，却发现需要用的缓存已经不在了。\n如果其他存储层也没保存这份数据，模型就得重新处理相应的历史输入、重建缓存。这个处理输入的阶段叫Prefill，输入越长，通常就越费时。用户等待首个Token的时间，也就是TTFT，便可能跟着增加。\n算过一遍的内容，过一会儿又得再算。对运营方来说，消耗掉的不只是电和时间，还有这批GPU原本可以用来处理新任务、生成新Token的机会。\n这也解释了，为什么KV Cache再大，运营方仍然要认真考虑怎么把它用好。\n从成本角度看，GPU应该尽量把资源花在必要的新输入处理和新Token生成上，少为已经处理过、又可以复用的历史内容重复做Prefill。KV Cache保留下来的，正是这部分已有计算的成果。\n当然，这不意味着所有缓存都得永久保存。真正要算的是：保留和取回一份缓存，能不能比下次重算更划算？谁能把这笔账算好，谁就更有机会用同一套设备服务更多请求。\n聊到这里，你可能已经想到了，显存放不下，难道不能先存到别处，等要用的时候再拿回来？\n可以，这也正是“以存代算”的思路。\n在服务器里，GPU显存之外还有CPU侧的DDR内存、本地SSD，以及远端存储。它们的容量、速度和成本各不相同，正好可以用来存放不同活跃程度的缓存。\n例如眼下正在生成回答，需要频繁访问的数据，就留在GPU的高带宽显存HBM里；短时间内可能继续用到的缓存，可以先放进CPU侧的DDR内存；至于更久没有访问、但还值得保留的历史缓存，则可以继续下沉到SSD或远端存储。\n再聚焦到Coding Agent的任务里，就是它写代码时，相关缓存尽量留在GPU侧；任务暂停后，系统可以把缓存转存到内存；如果这段会话很久没继续，再考虑把数据移到更下一层。用户回来后，系统根据缓存命中情况，把需要的部分取回来。\n对运营方来说，这样安排的直接好处是：显存不用一直替所有历史会话占着位置，腾出的空间可以交给正在运行的请求。\n不过，把东西搬出去只是第一步。哪些数据可以搬、应该放在哪里、什么时候得提前取回来，总得有个地方统一管理。\nCPU就在这里发挥作用。\n推理服务运行在主机侧的管理逻辑，需要跟踪会话状态、剩余容量和缓存访问情况。CPU连接的大容量内存和存储，也为显存之外的缓存池提供了基础。系统可以结合这些信息，决定一份KV Cache接下来该留在哪一层。\n这类机制其实已经出现在一些推理框架里了。例如，vLLM的KV Offloading支持将缓存块卸载到CPU内存，还可以配置次级存储层。在它描述的多层方案里，次级存储与GPU之间的数据传输，会经过CPU侧的缓存层。\n但这里还有个问题，那就是数据是存下来了，搬回来会不会更慢？\n毕竟，DDR、SSD和远端存储的访问条件各不相同。假如取回缓存比重新计算还费时，用户还是得等，甚至可能等得更久。所以，系统需要根据访问频率和传输开销安排缓存，不能一股脑地把数据全塞到硬盘里。\n要减少搬运量，另一个办法就是压缩。数据变小了，同样的空间能存得更多，传输时要搬的字节也更少。\n可压缩也不是白来的，压缩和解压都要花时间，如果全让通用CPU核心来干，又可能挤占请求调度等工作需要的资源。\n更麻烦的是，KV Cache本身就是大体量数据，压缩和解压的速度如果跟不上GPU侧的数据吞吐，压缩环节反而会成为新的瓶颈。单纯依靠通用CPU核心做软件压缩，很难同时兼顾高吞吐和CPU资源占用。\n这也是QAT的意义所在。它把压缩、解压交给专用硬件处理，在提升吞吐的同时释放通用CPU核心。相比只依赖CPU Core的软件方案，这种内置专用压缩加速能力，也构成了英特尔在KV Cache分层卸载上的一个差异化优势。\n于是问题就不只是能不能压，还变成了能不能压得足够快。\n对此，CPU老巨头英特尔给出了一套面向数据中心的KV Cache优化思路。\n围绕KV Cache，英特尔布局了KV Shrink、KV Fuse、KV Cascade和KV Infinity四个技术方向。\n名字虽然看着多，但我们用一张表格，根据它们各自要解决的问题来分类，就一目了然了：\n其中，KV Shrink已经有较具体的实现和测试披露，我们先来重点看看它。\nKV Shrink可以把前面讲的分层管理与硬件压缩结合起来，并提供冷热调度API，让业务系统按自己的策略决定缓存什么时候下沉、什么时候回载。内存吃紧时，系统还可以把较冷的数据继续转存到SSD等下一层介质。\n而负责分担压缩工作的，是英特尔的QAT（QuickAssist Technology）。\n它能够把压缩、解压等任务交给专用加速单元，减少对通用CPU核心的占用。英特尔从第四代至强可扩展处理器的相关型号开始集成QAT硬件。\n这么一来，CPU侧的管理逻辑继续负责调度，专用硬件接过压缩任务，系统便有机会在控制额外开销的同时，缩小缓存体积。\n英特尔还做了一个更细的调整：重新排列KV Cache的存储格式，让压缩算法更容易压缩这些数据。\n重排后，压缩所节省的空间从原先的10%以上增加到20%以上，空间降幅约为20%至30%。这条路径采用无损压缩，解压后能够恢复原始KV数据，不会因压缩而丢失数据。\n虽然20%-30%这个数字乍一看似乎没那么夸张，但把缓存池的规模放大，差别就出来了。\n例如，一个数据中心需要保留500TB的KV Cache，如果能压缩掉30%，对应的就是约150TB空间。这里算的是实际缓存池的容量，和前面按请求累加的日累计数据量不同。至于运营方最终能省下多少费用，还得结合存储介质、保留时间和业务负载来算，不能直接给总成本也打个七折。\n空间这块算是有收益了，那速度又怎么样呢？\n在英特尔给出的一组测试中，使用双路至强金牌6554S处理器、两张英伟达L20 GPU和Qwen3-32B模型，在80%缓存命中率下，相较未开启分层卸载的原生vLLM基线，KV Shrink在测试覆盖的输入长度和并发组合中，TTFT最高获得约5倍加速。\n除此之外，QAT硬件压缩方案的整体性能约为CPU软件压缩方案的两倍。在相同分层卸载机制下，相较不启用压缩，开启QAT压缩带来的额外TTFT开销低于10%。\n从这两项对照测试来看，压缩确实会多一道工序，但在这组测试里，专用硬件把额外开销控制在了较小范围内，让系统能够用一定的时间代价换取存储空间。\n再来看一组面向Coding Agent服务的测试。\n英特尔与道客联合实验室采用另一套配置进行测试：双路至强金牌6554S、八张H800和Qwen3-32B FP8模型，缓存命中率同样为80%。相较测试中的LMCache方案，KV Shrink在单路负载下的平均TTFT由129.81毫秒降至114.13毫秒，降幅约12.1%；八路并发时，降幅约为4.6%。\n你会发现，换一套设备、换一个比较对象，加速幅度也变了。所以数据中心运营方真正部署时，还是要把自己的上下文长度、并发量和缓存命中率带进去测试。业务里重复访问历史内容的机会越少，缓存复用能帮上的忙通常也越有限。\n除了把一段会话存好，运营方承载的企业服务还可能遇到另一类需求：几份文档以前都处理过，现在想把它们组合起来用，能不能少算一点？\n这就是KV Fuse关注的问题。但模型处理文档时会受到前文和位置等因素影响，几份独立生成的KV Cache通常不能直接拼接。KV Fuse尝试通过缓存融合和部分重计算，保留其中能够复用的工作。\n如果问题出在“给模型看的东西太多”，KV Cascade则尝试先请辅助模型做筛选或处理，把相关内容交给主模型。例如，一大堆文档里只有部分信息和当前问题有关，就可以先缩小主模型需要处理的范围。\n而KV Infinity面向持续增长的长任务，通过按需加载和预取，尝试缓解缓存必须全部常驻HBM的压力，让系统能够利用显存之外的资源。具体能扩展到什么程度，仍然要看访问方式和传输效率。\n这些方向背后，英特尔想要做的事就已经比较清楚了：\n让CPU协助管理推理中产生的大量计算结果，再通过内存、存储和专用加速单元，把保存和使用这些结果的成本降下来。\n对于具备相应QAT硬件的至强服务器，这提供了一条利用已有平台能力的优化路径。当然，实际接入还要检查内存、存储和软件等条件。\n最后，再回到数据中心的那笔账。单个用户看到的，也许只是Coding Agent有没有及时回答；运营方要考虑的，则是成千上万个请求涌进来之后，系统还能不能以可接受的成本持续提供服务。\nKV Cache越大，全部留在显存里就越难；可如果把还有复用价值的缓存一清了之，GPU又得为同一段历史反复开工。运营方需要在保存、搬运和重算之间找到合适的平衡。\n英特尔押注KV Cache，争取的正是这个位置：通过CPU侧的管理、分层存储和硬件压缩，让已有计算结果能以更低的代价被保留和再次使用。\nGPU仍然负责模型计算，CPU和存储系统则协助减少那些本可以避免的重复工作。至于方案值不值得部署，最终还得看真实负载下的响应时间、吞吐量，以及把服务器、内存、存储和能耗都算进去的总成本。\n毕竟，运营方买下昂贵的GPU，是希望它多干点新活儿。已经算过、又能复用的内容，就尽量别再付一次计算的账。\n最后，若是小伙伴们想要了解更多关于英特尔CPU的最新进展，欢迎锁定9月22日-9月23日的英特尔技术创新与产业生态大会（关注【英特尔商用】报名参加）！","source":"新浪财经","date":"2026-09-16T03:44:29+00:00","content":"把记忆交给CPU，大模型会变快\n（来源：量子位）\n拿Agent做Coding，想必大家都已经很熟悉了。\n不过，如果我们把目光从聊天窗口移到背后的数据中心，事情就没那么简单了。\n一个Coding Agent改跨十几个文件的bug，需要反复读代码、查资料、跑测试。前几轮交互可能还很顺畅，但任务继续跑下去，系统要处理的历史信息也会越积越多。\n当成千上万个Agent同时这样干活，运营方就可能遇到一个头疼的问题：服务器还在跑，能接住的并发却越来越吃紧，有些请求连吐出第一个Token都要等上好一会儿。\n难道只能继续加GPU？\n非也非也。\n模型还是那个模型，服务器也还是那个服务器，问题的根儿啊，其实是出在了记忆。\n因为大模型每生成一个新的Token，都还要继续用到前文的信息。为了不用每次从头计算，系统会把前面已经算好的中间结果保存起来；会话越聊越长，这份记忆自然也就越堆越厚。\n一旦显存装不下，部分缓存被清走，等Agent下一轮又需要这些历史信息时，就可能重新做一遍Prefill。前面明明已经算过的东西，又得花GPU时间再算一次。\n尤其是到了Agent时代，AI很少干一问一答的事儿，更多是那种反复需要思考、规划和行动的任务，期间会不断积累会话历史、检索证据、工具结果和中间状态等等。\n于是乎，一个过去藏在大模型推理内部、普通用户几乎感知不到的东西，就这样被推到了台面儿上——KV Cache。\n它的特点，说起来就一个字：大。但运营方又不能为了省空间，任由已经算过的内容反复占用GPU重算。所以，长上下文推理要算的这笔账，也就从算力延伸到了存储、搬运和复用。\n而这件事的破局之道，并不是你以为的GPU，而是——CPU。\n我们先把KV Cache这件事说清楚。\n对于采用因果自注意力的Transformer模型来说，前面处理过的Token，会在注意力层中留下对应的Key和Value。模型生成后续Token时，还能继续使用这些结果。推理系统把它们缓存起来，就有了KV Cache。\n你可以把它理解成模型读书时做的笔记。后面再遇到需要联系上文的地方，模型可以调用笔记，省去对已有Token的重复计算。\n所以，我们这里说的记忆，指的是推理过程中留下的中间状态，模型的权重并没有因此发生变化。\n这份笔记确实能省计算，但它也是实实在在要占地方的。而且，Agent读的东西越多，服务器要替它保存的笔记往往就越厚。\n那么这个增长到底有多明显呢？\n我们拿Qwen3-8B算一笔账。按照它的公开模型配置，在KV Cache采用BF16或FP16、每个数值占2字节的条件下，每个Token对应的KV数据是147456字节，也就是约147KB。这还没有计入缓存管理等额外开销。\n为什么一个Token会带出这么大一份缓存？因为系统保存的并不是这个Token的文字本身，而是它在多层注意力计算中对应的Key和Value。按这个模型的结构，计算式就是：2份K/V × 36层 × 8个KV头 × 每头128维 × 2字节。\n接下来，我们只借用这个每Token开销，做一次百万上下文的容量推演：如果需要缓存100万个Token，对应的KV数据就约为147GB。注意，这里的1M是测算假设，不代表Qwen3-8B实际支持百万上下文；它的官方说明是原生32768 Token，采用YaRN可扩展到131072 Token。\n单个请求已经如此，如果把请求规模也放大呢？假设一个服务有300万日活用户，每人每天发出10个请求，而且每个请求都按前面的1M上下文计算，一天就是3000万个请求。\n先不考虑压缩和共享复用，按每个请求约147GB全量累加，对应的日累计KV数据规模就是：300万 × 10 × 147GB ≈ 4410PB。如果日活再增加到3亿，相同假设下，这个数字还会放大100倍，达到约441000PB，也就是441EB。\n不过，这里得分清两件事：一天的请求累计涉及多少KV数据，和数据中心同时需要存下多少KV数据，不是一回事。上面是每次请求都独立、全量计数的规模推演，不能直接当作存储采购清单。\n实际要配多大的缓存池，运营方还得看高峰时有多少请求同时运行、缓存要留多久、哪些前缀能够共享，以及压缩和淘汰策略。已经复用的同一份缓存，也不该因为被请求多次就重复占一份容量。\n当然，不同模型的“笔记本”也不一样。模型层数、KV头数量、缓存精度等都会影响大小，不能只看参数量。上面的数字不是某个服务的真实用量，却能说明运营方为什么要格外关注这份“记忆”：上下文长度和请求规模，会一起把缓存的账越算越大。\n而GPU的显存，还要放模型权重和运行时的其他数据。大家共用这么多空间，KV Cache占得越多，系统留给其他请求的余地就可能越小。\n这时候，推理系统就得做取舍了：减少同时处理的请求，把部分缓存卸载到其他存储层，或者清理暂时不用的缓存。\n再拿前面的Coding Agent来说。它可能正在等工具跑测试，系统趁这个空当，把它的一部分历史缓存清掉了。等测试结果返回，Agent准备接着干活，却发现需要用的缓存已经不在了。\n如果其他存储层也没保存这份数据，模型就得重新处理相应的历史输入、重建缓存。这个处理输入的阶段叫Prefill，输入越长，通常就越费时。用户等待首个Token的时间，也就是TTFT，便可能跟着增加。\n算过一遍的内容，过一会儿又得再算。对运营方来说，消耗掉的不只是电和时间，还有这批GPU原本可以用来处理新任务、生成新Token的机会。\n这也解释了，为什么KV Cache再大，运营方仍然要认真考虑怎么把它用好。\n从成本角度看，GPU应该尽量把资源花在必要的新输入处理和新Token生成上，少为已经处理过、又可以复用的历史内容重复做Prefill。KV Cache保留下来的，正是这部分已有计算的成果。\n当然，这不意味着所有缓存都得永久保存。真正要算的是：保留和取回一份缓存，能不能比下次重算更划算？谁能把这笔账算好，谁就更有机会用同一套设备服务更多请求。\n聊到这里，你可能已经想到了，显存放不下，难道不能先存到别处，等要用的时候再拿回来？\n可以，这也正是“以存代算”的思路。\n在服务器里，GPU显存之外还有CPU侧的DDR内存、本地SSD，以及远端存储。它们的容量、速度和成本各不相同，正好可以用来存放不同活跃程度的缓存。\n例如眼下正在生成回答，需要频繁访问的数据，就留在GPU的高带宽显存HBM里；短时间内可能继续用到的缓存，可以先放进CPU侧的DDR内存；至于更久没有访问、但还值得保留的历史缓存，则可以继续下沉到SSD或远端存储。\n再聚焦到Coding Agent的任务里，就是它写代码时，相关缓存尽量留在GPU侧；任务暂停后，系统可以把缓存转存到内存；如果这段会话很久没继续，再考虑把数据移到更下一层。用户回来后，系统根据缓存命中情况，把需要的部分取回来。\n对运营方来说，这样安排的直接好处是：显存不用一直替所有历史会话占着位置，腾出的空间可以交给正在运行的请求。\n不过，把东西搬出去只是第一步。哪些数据可以搬、应该放在哪里、什么时候得提前取回来，总得有个地方统一管理。\nCPU就在这里发挥作用。\n推理服务运行在主机侧的管理逻辑，需要跟踪会话状态、剩余容量和缓存访问情况。CPU连接的大容量内存和存储，也为显存之外的缓存池提供了基础。系统可以结合这些信息，决定一份KV Cache接下来该留在哪一层。\n这类机制其实已经出现在一些推理框架里了。例如，vLLM的KV Offloading支持将缓存块卸载到CPU内存，还可以配置次级存储层。在它描述的多层方案里，次级存储与GPU之间的数据传输，会经过CPU侧的缓存层。\n但这里还有个问题，那就是数据是存下来了，搬回来会不会更慢？\n毕竟，DDR、SSD和远端存储的访问条件各不相同。假如取回缓存比重新计算还费时，用户还是得等，甚至可能等得更久。所以，系统需要根据访问频率和传输开销安排缓存，不能一股脑地把数据全塞到硬盘里。\n要减少搬运量，另一个办法就是压缩。数据变小了，同样的空间能存得更多，传输时要搬的字节也更少。\n可压缩也不是白来的，压缩和解压都要花时间，如果全让通用CPU核心来干，又可能挤占请求调度等工作需要的资源。\n更麻烦的是，KV Cache本身就是大体量数据，压缩和解压的速度如果跟不上GPU侧的数据吞吐，压缩环节反而会成为新的瓶颈。单纯依靠通用CPU核心做软件压缩，很难同时兼顾高吞吐和CPU资源占用。\n这也是QAT的意义所在。它把压缩、解压交给专用硬件处理，在提升吞吐的同时释放通用CPU核心。相比只依赖CPU Core的软件方案，这种内置专用压缩加速能力，也构成了英特尔在KV Cache分层卸载上的一个差异化优势。\n于是问题就不只是能不能压，还变成了能不能压得足够快。\n对此，CPU老巨头英特尔给出了一套面向数据中心的KV Cache优化思路。\n围绕KV Cache，英特尔布局了KV Shrink、KV Fuse、KV Cascade和KV Infinity四个技术方向。\n名字虽然看着多，但我们用一张表格，根据它们各自要解决的问题来分类，就一目了然了：\n其中，KV Shrink已经有较具体的实现和测试披露，我们先来重点看看它。\nKV Shrink可以把前面讲的分层管理与硬件压缩结合起来，并提供冷热调度API，让业务系统按自己的策略决定缓存什么时候下沉、什么时候回载。内存吃紧时，系统还可以把较冷的数据继续转存到SSD等下一层介质。\n而负责分担压缩工作的，是英特尔的QAT（QuickAssist Technology）。\n它能够把压缩、解压等任务交给专用加速单元，减少对通用CPU核心的占用。英特尔从第四代至强可扩展处理器的相关型号开始集成QAT硬件。\n这么一来，CPU侧的管理逻辑继续负责调度，专用硬件接过压缩任务，系统便有机会在控制额外开销的同时，缩小缓存体积。\n英特尔还做了一个更细的调整：重新排列KV Cache的存储格式，让压缩算法更容易压缩这些数据。\n重排后，压缩所节省的空间从原先的10%以上增加到20%以上，空间降幅约为20%至30%。这条路径采用无损压缩，解压后能够恢复原始KV数据，不会因压缩而丢失数据。\n虽然20%-30%这个数字乍一看似乎没那么夸张，但把缓存池的规模放大，差别就出来了。\n例如，一个数据中心需要保留500TB的KV Cache，如果能压缩掉30%，对应的就是约150TB空间。这里算的是实际缓存池的容量，和前面按请求累加的日累计数据量不同。至于运营方最终能省下多少费用，还得结合存储介质、保留时间和业务负载来算，不能直接给总成本也打个七折。\n空间这块算是有收益了，那速度又怎么样呢？\n在英特尔给出的一组测试中，使用双路至强金牌6554S处理器、两张英伟达L20 GPU和Qwen3-32B模型，在80%缓存命中率下，相较未开启分层卸载的原生vLLM基线，KV Shrink在测试覆盖的输入长度和并发组合中，TTFT最高获得约5倍加速。\n除此之外，QAT硬件压缩方案的整体性能约为CPU软件压缩方案的两倍。在相同分层卸载机制下，相较不启用压缩，开启QAT压缩带来的额外TTFT开销低于10%。\n从这两项对照测试来看，压缩确实会多一道工序，但在这组测试里，专用硬件把额外开销控制在了较小范围内，让系统能够用一定的时间代价换取存储空间。\n再来看一组面向Coding Agent服务的测试。\n英特尔与道客联合实验室采用另一套配置进行测试：双路至强金牌6554S、八张H800和Qwen3-32B FP8模型，缓存命中率同样为80%。相较测试中的LMCache方案，KV Shrink在单路负载下的平均TTFT由129.81毫秒降至114.13毫秒，降幅约12.1%；八路并发时，降幅约为4.6%。\n你会发现，换一套设备、换一个比较对象，加速幅度也变了。所以数据中心运营方真正部署时，还是要把自己的上下文长度、并发量和缓存命中率带进去测试。业务里重复访问历史内容的机会越少，缓存复用能帮上的忙通常也越有限。\n除了把一段会话存好，运营方承载的企业服务还可能遇到另一类需求：几份文档以前都处理过，现在想把它们组合起来用，能不能少算一点？\n这就是KV Fuse关注的问题。但模型处理文档时会受到前文和位置等因素影响，几份独立生成的KV Cache通常不能直接拼接。KV Fuse尝试通过缓存融合和部分重计算，保留其中能够复用的工作。\n如果问题出在“给模型看的东西太多”，KV Cascade则尝试先请辅助模型做筛选或处理，把相关内容交给主模型。例如，一大堆文档里只有部分信息和当前问题有关，就可以先缩小主模型需要处理的范围。\n而KV Infinity面向持续增长的长任务，通过按需加载和预取，尝试缓解缓存必须全部常驻HBM的压力，让系统能够利用显存之外的资源。具体能扩展到什么程度，仍然要看访问方式和传输效率。\n这些方向背后，英特尔想要做的事就已经比较清楚了：\n让CPU协助管理推理中产生的大量计算结果，再通过内存、存储和专用加速单元，把保存和使用这些结果的成本降下来。\n对于具备相应QAT硬件的至强服务器，这提供了一条利用已有平台能力的优化路径。当然，实际接入还要检查内存、存储和软件等条件。\n最后，再回到数据中心的那笔账。单个用户看到的，也许只是Coding Agent有没有及时回答；运营方要考虑的，则是成千上万个请求涌进来之后，系统还能不能以可接受的成本持续提供服务。\nKV Cache越大，全部留在显存里就越难；可如果把还有复用价值的缓存一清了之，GPU又得为同一段历史反复开工。运营方需要在保存、搬运和重算之间找到合适的平衡。\n英特尔押注KV Cache，争取的正是这个位置：通过CPU侧的管理、分层存储和硬件压缩，让已有计算结果能以更低的代价被保留和再次使用。\nGPU仍然负责模型计算，CPU和存储系统则协助减少那些本可以避免的重复工作。至于方案值不值得部署，最终还得看真实负载下的响应时间、吞吐量，以及把服务器、内存、存储和能耗都算进去的总成本。\n毕竟，运营方买下昂贵的GPU，是希望它多干点新活儿。已经算过、又能复用的内容，就尽量别再付一次计算的账。\n最后，若是小伙伴们想要了解更多关于英特尔CPU的最新进展，欢迎锁定9月22日-9月23日的英特尔技术创新与产业生态大会（关注【英特尔商用】报名参加）！","confidence":0.9,"diagnostics_url":"/api/diagnose?url=https%3A//finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html%3Fvt%3D4%26cid%3D76993%26node_id%3D76993","quality_bucket":"high","failure_kind":"none","retryable":false,"quality_reason":"High confidence: full text extraction produced 5905 characters.","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 5905 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":5905,"summary_length":5905,"usable_text_length":5905,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":5905,"summary_length":5905}},"tags":[]},"fallback_formats":["markdown","json","html"],"actions":{"read":"/item/83485","export_markdown":"/api/items/83485/export?format=markdown","export_json":"/api/items/83485/export?format=json","diagnose":"/api/diagnose?url=https%3A//finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html%3Fvt%3D4%26cid%3D76993%26node_id%3D76993"},"formats":{"full":{"id":83485,"title":"把记忆交给CPU，大模型会变快 - 新浪财经","url":"https://finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html?vt=4&cid=76993&node_id=76993","source":"新浪财经","author":null,"published_at":"2026-09-16T03:44:29+00:00","locale":"zh","topic":"ai","tags":[],"excerpt":"把记忆交给CPU，大模型会变快\n（来源：量子位）\n拿Agent做Coding，想必大家都已经很熟悉了。\n不过，如果我们把目光从聊天窗口移到背后的数据中心，事情就没那么简单了。\n一个Coding Agent改跨十几个文件的bug，需要反复读代码、查资料、跑测试。前几轮交互可能还很顺畅，但任务继续跑下去，系统要处理的历史信息也会越积越多。\n当成千上万个Agent同时这样干活，运营方就可能遇到一个头疼的问题：服务器还在跑，能接住的并发却越来越吃紧，有些请求连吐出第一个Token都要等上好一会儿。\n难道只能继续加GPU？\n非也非也。\n模型还是那个模型，服务器也还是那个服务器，问题的根儿啊，其实是出在了记忆。\n因为大模型每生成一个新的Token，都还要继续用到前文的信息。为了不用每次从头计算，系统会把前面已经算好的中间结果保存起来；会话越聊越长，这份记忆自然也就越堆越厚。\n一旦显存装不下，部分缓存被清走，等Agent下一轮又需要这些历史信息时，就可能重新做一遍Prefill。前面明明已经算过的东西，又得花GPU时间再算一次。\n尤其是到了Agent时代，AI很少干一问一答的事儿，更多是那种反复需要思考、规划和行动的任务，期间会不断积累会话历史、检索证据、工具结果和中间状态等等。\n于是乎，一个过去藏在大模型推理内部、普通用户几乎感知不到的东西，就这样被推到了台面儿上——KV Cache。\n它的特点，说起来就一个字：大。但运营方又不能为了省空间，任由已经算过的内容反复占用GPU重算。所以，长上下文推理要算的这笔账，也就从算力延伸到了存储、搬运和复用。\n而这件事的破局之道，并不是你以为的GPU，而是——CPU。\n我们先把KV Cache这件事说清楚。\n对于采用因果自注意力的Transformer模型来说，前面处理过的Token，会在注意力层中留下对应的Key和Value。模型生成后续Token时，还能继续使用这些结果。推理系统把它们缓存起来，就有了KV Cache。\n你可以把它理解成模型读书时做的笔记。后面再遇到需要联系上文的地方，模型可以调用笔记，省去对已有Token的重复计算。\n所以，我们这里说的记忆，指的是推理过程中留下的中间状态，模型的权重并没有因此发生变化。\n这份笔记确实能省计算，但它也是实实在在要占地方的。而且，Agent读的东西越多，服务器要替它保存的笔记往往就越厚。\n那么这个增长到底有多明显呢？\n我们拿Qwen3-8B算一笔账。按照它的公开模型配置，在KV Cache采用BF16或FP16、每个数值占2字节的条件下，每个Token对应的KV数据是147456字节，也就是约147KB。这还没有计入缓存管理等额外开销。\n为什么一个Token会带出这么大一份缓存？因为系统保存的并不是这个Token的文字本身，而是它在多层注意力计算中对应的Key和Value。按这个模型的结构，计算式就是：2份K/V × 36层 × 8个KV头 × 每头128维 × 2字节。\n接下来，我们只借用这个每Token开销，做一次百万上下文的容量推演：如果需要缓存100万个Token，对应的KV数据就约为147GB。注意，这里的1M是测算假设，不代表Qwen3-8B实际支持百万上下文；它的官方说明是原生32768 Token，采用YaRN可扩展到131072 Token。\n单个请求已经如此，如果把请求规模也放大呢？假设一个服务有300万日活用户，每人每天发出10个请求，而且每个请求都按前面的1M上下文计算，一天就是3000万个请求。\n先不考虑压缩和共享复用，按每个请求约147GB全量累加，对应的日累计KV数据规模就是：300万 × 10 × 147GB ≈ 4410PB。如果日活再增加到3亿，相同假设下，这个数字还会放大100倍，达到约441000PB，也就是441EB。\n不过，这里得分清两件事：一天的请求累计涉及多少KV数据，和数据中心同时需要存下多少KV数据，不是一回事。上面是每次请求都独立、全量计数的规模推演，不能直接当作存储采购清单。\n实际要配多大的缓存池，运营方还得看高峰时有多少请求同时运行、缓存要留多久、哪些前缀能够共享，以及压缩和淘汰策略。已经复用的同一份缓存，也不该因为被请求多次就重复占一份容量。\n当然，不同模型的“笔记本”也不一样。模型层数、KV头数量、缓存精度等都会影响大小，不能只看参数量。上面的数字不是某个服务的真实用量，却能说明运营方为什么要格外关注这份“记忆”：上下文长度和请求规模，会一起把缓存的账越算越大。\n而GPU的显存，还要放模型权重和运行时的其他数据。大家共用这么多空间，KV Cache占得越多，系统留给其他请求的余地就可能越小。\n这时候，推理系统就得做取舍了：减少同时处理的请求，把部分缓存卸载到其他存储层，或者清理暂时不用的缓存。\n再拿前面的Coding Agent来说。它可能正在等工具跑测试，系统趁这个空当，把它的一部分历史缓存清掉了。等测试结果返回，Agent准备接着干活，却发现需要用的缓存已经不在了。\n如果其他存储层也没保存这份数据，模型就得重新处理相应的历史输入、重建缓存。这个处理输入的阶段叫Prefill，输入越长，通常就越费时。用户等待首个Token的时间，也就是TTFT，便可能跟着增加。\n算过一遍的内容，过一会儿又得再算。对运营方来说，消耗掉的不只是电和时间，还有这批GPU原本可以用来处理新任务、生成新Token的机会。\n这也解释了，为什么KV Cache再大，运营方仍然要认真考虑怎么把它用好。\n从成本角度看，GPU应该尽量把资源花在必要的新输入处理和新Token生成上，少为已经处理过、又可以复用的历史内容重复做Prefill。KV Cache保留下来的，正是这部分已有计算的成果。\n当然，这不意味着所有缓存都得永久保存。真正要算的是：保留和取回一份缓存，能不能比下次重算更划算？谁能把这笔账算好，谁就更有机会用同一套设备服务更多请求。\n聊到这里，你可能已经想到了，显存放不下，难道不能先存到别处，等要用的时候再拿回来？\n可以，这也正是“以存代算”的思路。\n在服务器里，GPU显存之外还有CPU侧的DDR内存、本地SSD，以及远端存储。它们的容量、速度和成本各不相同，正好可以用来存放不同活跃程度的缓存。\n例如眼下正在生成回答，需要频繁访问的数据，就留在GPU的高带宽显存HBM里；短时间内可能继续用到的缓存，可以先放进CPU侧的DDR内存；至于更久没有访问、但还值得保留的历史缓存，则可以继续下沉到SSD或远端存储。\n再聚焦到Coding Agent的任务里，就是它写代码时，相关缓存尽量留在GPU侧；任务暂停后，系统可以把缓存转存到内存；如果这段会话很久没继续，再考虑把数据移到更下一层。用户回来后，系统根据缓存命中情况，把需要的部分取回来。\n对运营方来说，这样安排的直接好处是：显存不用一直替所有历史会话占着位置，腾出的空间可以交给正在运行的请求。\n不过，把东西搬出去只是第一步。哪些数据可以搬、应该放在哪里、什么时候得提前取回来，总得有个地方统一管理。\nCPU就在这里发挥作用。\n推理服务运行在主机侧的管理逻辑，需要跟踪会话状态、剩余容量和缓存访问情况。CPU连接的大容量内存和存储，也为显存之外的缓存池提供了基础。系统可以结合这些信息，决定一份KV Cache接下来该留在哪一层。\n这类机制其实已经出现在一些推理框架里了。例如，vLLM的KV Offloading支持将缓存块卸载到CPU内存，还可以配置次级存储层。在它描述的多层方案里，次级存储与GPU之间的数据传输，会经过CPU侧的缓存层。\n但这里还有个问题，那就是数据是存下来了，搬回来会不会更慢？\n毕竟，DDR、SSD和远端存储的访问条件各不相同。假如取回缓存比重新计算还费时，用户还是得等，甚至可能等得更久。所以，系统需要根据访问频率和传输开销安排缓存，不能一股脑地把数据全塞到硬盘里。\n要减少搬运量，另一个办法就是压缩。数据变小了，同样的空间能存得更多，传输时要搬的字节也更少。\n可压缩也不是白来的，压缩和解压都要花时间，如果全让通用CPU核心来干，又可能挤占请求调度等工作需要的资源。\n更麻烦的是，KV Cache本身就是大体量数据，压缩和解压的速度如果跟不上GPU侧的数据吞吐，压缩环节反而会成为新的瓶颈。单纯依靠通用CPU核心做软件压缩，很难同时兼顾高吞吐和CPU资源占用。\n这也是QAT的意义所在。它把压缩、解压交给专用硬件处理，在提升吞吐的同时释放通用CPU核心。相比只依赖CPU Core的软件方案，这种内置专用压缩加速能力，也构成了英特尔在KV Cache分层卸载上的一个差异化优势。\n于是问题就不只是能不能压，还变成了能不能压得足够快。\n对此，CPU老巨头英特尔给出了一套面向数据中心的KV Cache优化思路。\n围绕KV Cache，英特尔布局了KV Shrink、KV Fuse、KV Cascade和KV Infinity四个技术方向。\n名字虽然看着多，但我们用一张表格，根据它们各自要解决的问题来分类，就一目了然了：\n其中，KV Shrink已经有较具体的实现和测试披露，我们先来重点看看它。\nKV Shrink可以把前面讲的分层管理与硬件压缩结合起来，并提供冷热调度API，让业务系统按自己的策略决定缓存什么时候下沉、什么时候回载。内存吃紧时，系统还可以把较冷的数据继续转存到SSD等下一层介质。\n而负责分担压缩工作的，是英特尔的QAT（QuickAssist Technology）。\n它能够把压缩、解压等任务交给专用加速单元，减少对通用CPU核心的占用。英特尔从第四代至强可扩展处理器的相关型号开始集成QAT硬件。\n这么一来，CPU侧的管理逻辑继续负责调度，专用硬件接过压缩任务，系统便有机会在控制额外开销的同时，缩小缓存体积。\n英特尔还做了一个更细的调整：重新排列KV Cache的存储格式，让压缩算法更容易压缩这些数据。\n重排后，压缩所节省的空间从原先的10%以上增加到20%以上，空间降幅约为20%至30%。这条路径采用无损压缩，解压后能够恢复原始KV数据，不会因压缩而丢失数据。\n虽然20%-30%这个数字乍一看似乎没那么夸张，但把缓存池的规模放大，差别就出来了。\n例如，一个数据中心需要保留500TB的KV Cache，如果能压缩掉30%，对应的就是约150TB空间。这里算的是实际缓存池的容量，和前面按请求累加的日累计数据量不同。至于运营方最终能省下多少费用，还得结合存储介质、保留时间和业务负载来算，不能直接给总成本也打个七折。\n空间这块算是有收益了，那速度又怎么样呢？\n在英特尔给出的一组测试中，使用双路至强金牌6554S处理器、两张英伟达L20 GPU和Qwen3-32B模型，在80%缓存命中率下，相较未开启分层卸载的原生vLLM基线，KV Shrink在测试覆盖的输入长度和并发组合中，TTFT最高获得约5倍加速。\n除此之外，QAT硬件压缩方案的整体性能约为CPU软件压缩方案的两倍。在相同分层卸载机制下，相较不启用压缩，开启QAT压缩带来的额外TTFT开销低于10%。\n从这两项对照测试来看，压缩确实会多一道工序，但在这组测试里，专用硬件把额外开销控制在了较小范围内，让系统能够用一定的时间代价换取存储空间。\n再来看一组面向Coding Agent服务的测试。\n英特尔与道客联合实验室采用另一套配置进行测试：双路至强金牌6554S、八张H800和Qwen3-32B FP8模型，缓存命中率同样为80%。相较测试中的LMCache方案，KV Shrink在单路负载下的平均TTFT由129.81毫秒降至114.13毫秒，降幅约12.1%；八路并发时，降幅约为4.6%。\n你会发现，换一套设备、换一个比较对象，加速幅度也变了。所以数据中心运营方真正部署时，还是要把自己的上下文长度、并发量和缓存命中率带进去测试。业务里重复访问历史内容的机会越少，缓存复用能帮上的忙通常也越有限。\n除了把一段会话存好，运营方承载的企业服务还可能遇到另一类需求：几份文档以前都处理过，现在想把它们组合起来用，能不能少算一点？\n这就是KV Fuse关注的问题。但模型处理文档时会受到前文和位置等因素影响，几份独立生成的KV Cache通常不能直接拼接。KV Fuse尝试通过缓存融合和部分重计算，保留其中能够复用的工作。\n如果问题出在“给模型看的东西太多”，KV Cascade则尝试先请辅助模型做筛选或处理，把相关内容交给主模型。例如，一大堆文档里只有部分信息和当前问题有关，就可以先缩小主模型需要处理的范围。\n而KV Infinity面向持续增长的长任务，通过按需加载和预取，尝试缓解缓存必须全部常驻HBM的压力，让系统能够利用显存之外的资源。具体能扩展到什么程度，仍然要看访问方式和传输效率。\n这些方向背后，英特尔想要做的事就已经比较清楚了：\n让CPU协助管理推理中产生的大量计算结果，再通过内存、存储和专用加速单元，把保存和使用这些结果的成本降下来。\n对于具备相应QAT硬件的至强服务器，这提供了一条利用已有平台能力的优化路径。当然，实际接入还要检查内存、存储和软件等条件。\n最后，再回到数据中心的那笔账。单个用户看到的，也许只是Coding Agent有没有及时回答；运营方要考虑的，则是成千上万个请求涌进来之后，系统还能不能以可接受的成本持续提供服务。\nKV Cache越大，全部留在显存里就越难；可如果把还有复用价值的缓存一清了之，GPU又得为同一段历史反复开工。运营方需要在保存、搬运和重算之间找到合适的平衡。\n英特尔押注KV Cache，争取的正是这个位置：通过CPU侧的管理、分层存储和硬件压缩，让已有计算结果能以更低的代价被保留和再次使用。\nGPU仍然负责模型计算，CPU和存储系统则协助减少那些本可以避免的重复工作。至于方案值不值得部署，最终还得看真实负载下的响应时间、吞吐量，以及把服务器、内存、存储和能耗都算进去的总成本。\n毕竟，运营方买下昂贵的GPU，是希望它多干点新活儿。已经算过、又能复用的内容，就尽量别再付一次计算的账。\n最后，若是小伙伴们想要了解更多关于英特尔CPU的最新进展，欢迎锁定9月22日-9月23日的英特尔技术创新与产业生态大会（关注【英特尔商用】报名参加）！","full_text":"把记忆交给CPU，大模型会变快\n（来源：量子位）\n拿Agent做Coding，想必大家都已经很熟悉了。\n不过，如果我们把目光从聊天窗口移到背后的数据中心，事情就没那么简单了。\n一个Coding Agent改跨十几个文件的bug，需要反复读代码、查资料、跑测试。前几轮交互可能还很顺畅，但任务继续跑下去，系统要处理的历史信息也会越积越多。\n当成千上万个Agent同时这样干活，运营方就可能遇到一个头疼的问题：服务器还在跑，能接住的并发却越来越吃紧，有些请求连吐出第一个Token都要等上好一会儿。\n难道只能继续加GPU？\n非也非也。\n模型还是那个模型，服务器也还是那个服务器，问题的根儿啊，其实是出在了记忆。\n因为大模型每生成一个新的Token，都还要继续用到前文的信息。为了不用每次从头计算，系统会把前面已经算好的中间结果保存起来；会话越聊越长，这份记忆自然也就越堆越厚。\n一旦显存装不下，部分缓存被清走，等Agent下一轮又需要这些历史信息时，就可能重新做一遍Prefill。前面明明已经算过的东西，又得花GPU时间再算一次。\n尤其是到了Agent时代，AI很少干一问一答的事儿，更多是那种反复需要思考、规划和行动的任务，期间会不断积累会话历史、检索证据、工具结果和中间状态等等。\n于是乎，一个过去藏在大模型推理内部、普通用户几乎感知不到的东西，就这样被推到了台面儿上——KV Cache。\n它的特点，说起来就一个字：大。但运营方又不能为了省空间，任由已经算过的内容反复占用GPU重算。所以，长上下文推理要算的这笔账，也就从算力延伸到了存储、搬运和复用。\n而这件事的破局之道，并不是你以为的GPU，而是——CPU。\n我们先把KV Cache这件事说清楚。\n对于采用因果自注意力的Transformer模型来说，前面处理过的Token，会在注意力层中留下对应的Key和Value。模型生成后续Token时，还能继续使用这些结果。推理系统把它们缓存起来，就有了KV Cache。\n你可以把它理解成模型读书时做的笔记。后面再遇到需要联系上文的地方，模型可以调用笔记，省去对已有Token的重复计算。\n所以，我们这里说的记忆，指的是推理过程中留下的中间状态，模型的权重并没有因此发生变化。\n这份笔记确实能省计算，但它也是实实在在要占地方的。而且，Agent读的东西越多，服务器要替它保存的笔记往往就越厚。\n那么这个增长到底有多明显呢？\n我们拿Qwen3-8B算一笔账。按照它的公开模型配置，在KV Cache采用BF16或FP16、每个数值占2字节的条件下，每个Token对应的KV数据是147456字节，也就是约147KB。这还没有计入缓存管理等额外开销。\n为什么一个Token会带出这么大一份缓存？因为系统保存的并不是这个Token的文字本身，而是它在多层注意力计算中对应的Key和Value。按这个模型的结构，计算式就是：2份K/V × 36层 × 8个KV头 × 每头128维 × 2字节。\n接下来，我们只借用这个每Token开销，做一次百万上下文的容量推演：如果需要缓存100万个Token，对应的KV数据就约为147GB。注意，这里的1M是测算假设，不代表Qwen3-8B实际支持百万上下文；它的官方说明是原生32768 Token，采用YaRN可扩展到131072 Token。\n单个请求已经如此，如果把请求规模也放大呢？假设一个服务有300万日活用户，每人每天发出10个请求，而且每个请求都按前面的1M上下文计算，一天就是3000万个请求。\n先不考虑压缩和共享复用，按每个请求约147GB全量累加，对应的日累计KV数据规模就是：300万 × 10 × 147GB ≈ 4410PB。如果日活再增加到3亿，相同假设下，这个数字还会放大100倍，达到约441000PB，也就是441EB。\n不过，这里得分清两件事：一天的请求累计涉及多少KV数据，和数据中心同时需要存下多少KV数据，不是一回事。上面是每次请求都独立、全量计数的规模推演，不能直接当作存储采购清单。\n实际要配多大的缓存池，运营方还得看高峰时有多少请求同时运行、缓存要留多久、哪些前缀能够共享，以及压缩和淘汰策略。已经复用的同一份缓存，也不该因为被请求多次就重复占一份容量。\n当然，不同模型的“笔记本”也不一样。模型层数、KV头数量、缓存精度等都会影响大小，不能只看参数量。上面的数字不是某个服务的真实用量，却能说明运营方为什么要格外关注这份“记忆”：上下文长度和请求规模，会一起把缓存的账越算越大。\n而GPU的显存，还要放模型权重和运行时的其他数据。大家共用这么多空间，KV Cache占得越多，系统留给其他请求的余地就可能越小。\n这时候，推理系统就得做取舍了：减少同时处理的请求，把部分缓存卸载到其他存储层，或者清理暂时不用的缓存。\n再拿前面的Coding Agent来说。它可能正在等工具跑测试，系统趁这个空当，把它的一部分历史缓存清掉了。等测试结果返回，Agent准备接着干活，却发现需要用的缓存已经不在了。\n如果其他存储层也没保存这份数据，模型就得重新处理相应的历史输入、重建缓存。这个处理输入的阶段叫Prefill，输入越长，通常就越费时。用户等待首个Token的时间，也就是TTFT，便可能跟着增加。\n算过一遍的内容，过一会儿又得再算。对运营方来说，消耗掉的不只是电和时间，还有这批GPU原本可以用来处理新任务、生成新Token的机会。\n这也解释了，为什么KV Cache再大，运营方仍然要认真考虑怎么把它用好。\n从成本角度看，GPU应该尽量把资源花在必要的新输入处理和新Token生成上，少为已经处理过、又可以复用的历史内容重复做Prefill。KV Cache保留下来的，正是这部分已有计算的成果。\n当然，这不意味着所有缓存都得永久保存。真正要算的是：保留和取回一份缓存，能不能比下次重算更划算？谁能把这笔账算好，谁就更有机会用同一套设备服务更多请求。\n聊到这里，你可能已经想到了，显存放不下，难道不能先存到别处，等要用的时候再拿回来？\n可以，这也正是“以存代算”的思路。\n在服务器里，GPU显存之外还有CPU侧的DDR内存、本地SSD，以及远端存储。它们的容量、速度和成本各不相同，正好可以用来存放不同活跃程度的缓存。\n例如眼下正在生成回答，需要频繁访问的数据，就留在GPU的高带宽显存HBM里；短时间内可能继续用到的缓存，可以先放进CPU侧的DDR内存；至于更久没有访问、但还值得保留的历史缓存，则可以继续下沉到SSD或远端存储。\n再聚焦到Coding Agent的任务里，就是它写代码时，相关缓存尽量留在GPU侧；任务暂停后，系统可以把缓存转存到内存；如果这段会话很久没继续，再考虑把数据移到更下一层。用户回来后，系统根据缓存命中情况，把需要的部分取回来。\n对运营方来说，这样安排的直接好处是：显存不用一直替所有历史会话占着位置，腾出的空间可以交给正在运行的请求。\n不过，把东西搬出去只是第一步。哪些数据可以搬、应该放在哪里、什么时候得提前取回来，总得有个地方统一管理。\nCPU就在这里发挥作用。\n推理服务运行在主机侧的管理逻辑，需要跟踪会话状态、剩余容量和缓存访问情况。CPU连接的大容量内存和存储，也为显存之外的缓存池提供了基础。系统可以结合这些信息，决定一份KV Cache接下来该留在哪一层。\n这类机制其实已经出现在一些推理框架里了。例如，vLLM的KV Offloading支持将缓存块卸载到CPU内存，还可以配置次级存储层。在它描述的多层方案里，次级存储与GPU之间的数据传输，会经过CPU侧的缓存层。\n但这里还有个问题，那就是数据是存下来了，搬回来会不会更慢？\n毕竟，DDR、SSD和远端存储的访问条件各不相同。假如取回缓存比重新计算还费时，用户还是得等，甚至可能等得更久。所以，系统需要根据访问频率和传输开销安排缓存，不能一股脑地把数据全塞到硬盘里。\n要减少搬运量，另一个办法就是压缩。数据变小了，同样的空间能存得更多，传输时要搬的字节也更少。\n可压缩也不是白来的，压缩和解压都要花时间，如果全让通用CPU核心来干，又可能挤占请求调度等工作需要的资源。\n更麻烦的是，KV Cache本身就是大体量数据，压缩和解压的速度如果跟不上GPU侧的数据吞吐，压缩环节反而会成为新的瓶颈。单纯依靠通用CPU核心做软件压缩，很难同时兼顾高吞吐和CPU资源占用。\n这也是QAT的意义所在。它把压缩、解压交给专用硬件处理，在提升吞吐的同时释放通用CPU核心。相比只依赖CPU Core的软件方案，这种内置专用压缩加速能力，也构成了英特尔在KV Cache分层卸载上的一个差异化优势。\n于是问题就不只是能不能压，还变成了能不能压得足够快。\n对此，CPU老巨头英特尔给出了一套面向数据中心的KV Cache优化思路。\n围绕KV Cache，英特尔布局了KV Shrink、KV Fuse、KV Cascade和KV Infinity四个技术方向。\n名字虽然看着多，但我们用一张表格，根据它们各自要解决的问题来分类，就一目了然了：\n其中，KV Shrink已经有较具体的实现和测试披露，我们先来重点看看它。\nKV Shrink可以把前面讲的分层管理与硬件压缩结合起来，并提供冷热调度API，让业务系统按自己的策略决定缓存什么时候下沉、什么时候回载。内存吃紧时，系统还可以把较冷的数据继续转存到SSD等下一层介质。\n而负责分担压缩工作的，是英特尔的QAT（QuickAssist Technology）。\n它能够把压缩、解压等任务交给专用加速单元，减少对通用CPU核心的占用。英特尔从第四代至强可扩展处理器的相关型号开始集成QAT硬件。\n这么一来，CPU侧的管理逻辑继续负责调度，专用硬件接过压缩任务，系统便有机会在控制额外开销的同时，缩小缓存体积。\n英特尔还做了一个更细的调整：重新排列KV Cache的存储格式，让压缩算法更容易压缩这些数据。\n重排后，压缩所节省的空间从原先的10%以上增加到20%以上，空间降幅约为20%至30%。这条路径采用无损压缩，解压后能够恢复原始KV数据，不会因压缩而丢失数据。\n虽然20%-30%这个数字乍一看似乎没那么夸张，但把缓存池的规模放大，差别就出来了。\n例如，一个数据中心需要保留500TB的KV Cache，如果能压缩掉30%，对应的就是约150TB空间。这里算的是实际缓存池的容量，和前面按请求累加的日累计数据量不同。至于运营方最终能省下多少费用，还得结合存储介质、保留时间和业务负载来算，不能直接给总成本也打个七折。\n空间这块算是有收益了，那速度又怎么样呢？\n在英特尔给出的一组测试中，使用双路至强金牌6554S处理器、两张英伟达L20 GPU和Qwen3-32B模型，在80%缓存命中率下，相较未开启分层卸载的原生vLLM基线，KV Shrink在测试覆盖的输入长度和并发组合中，TTFT最高获得约5倍加速。\n除此之外，QAT硬件压缩方案的整体性能约为CPU软件压缩方案的两倍。在相同分层卸载机制下，相较不启用压缩，开启QAT压缩带来的额外TTFT开销低于10%。\n从这两项对照测试来看，压缩确实会多一道工序，但在这组测试里，专用硬件把额外开销控制在了较小范围内，让系统能够用一定的时间代价换取存储空间。\n再来看一组面向Coding Agent服务的测试。\n英特尔与道客联合实验室采用另一套配置进行测试：双路至强金牌6554S、八张H800和Qwen3-32B FP8模型，缓存命中率同样为80%。相较测试中的LMCache方案，KV Shrink在单路负载下的平均TTFT由129.81毫秒降至114.13毫秒，降幅约12.1%；八路并发时，降幅约为4.6%。\n你会发现，换一套设备、换一个比较对象，加速幅度也变了。所以数据中心运营方真正部署时，还是要把自己的上下文长度、并发量和缓存命中率带进去测试。业务里重复访问历史内容的机会越少，缓存复用能帮上的忙通常也越有限。\n除了把一段会话存好，运营方承载的企业服务还可能遇到另一类需求：几份文档以前都处理过，现在想把它们组合起来用，能不能少算一点？\n这就是KV Fuse关注的问题。但模型处理文档时会受到前文和位置等因素影响，几份独立生成的KV Cache通常不能直接拼接。KV Fuse尝试通过缓存融合和部分重计算，保留其中能够复用的工作。\n如果问题出在“给模型看的东西太多”，KV Cascade则尝试先请辅助模型做筛选或处理，把相关内容交给主模型。例如，一大堆文档里只有部分信息和当前问题有关，就可以先缩小主模型需要处理的范围。\n而KV Infinity面向持续增长的长任务，通过按需加载和预取，尝试缓解缓存必须全部常驻HBM的压力，让系统能够利用显存之外的资源。具体能扩展到什么程度，仍然要看访问方式和传输效率。\n这些方向背后，英特尔想要做的事就已经比较清楚了：\n让CPU协助管理推理中产生的大量计算结果，再通过内存、存储和专用加速单元，把保存和使用这些结果的成本降下来。\n对于具备相应QAT硬件的至强服务器，这提供了一条利用已有平台能力的优化路径。当然，实际接入还要检查内存、存储和软件等条件。\n最后，再回到数据中心的那笔账。单个用户看到的，也许只是Coding Agent有没有及时回答；运营方要考虑的，则是成千上万个请求涌进来之后，系统还能不能以可接受的成本持续提供服务。\nKV Cache越大，全部留在显存里就越难；可如果把还有复用价值的缓存一清了之，GPU又得为同一段历史反复开工。运营方需要在保存、搬运和重算之间找到合适的平衡。\n英特尔押注KV Cache，争取的正是这个位置：通过CPU侧的管理、分层存储和硬件压缩，让已有计算结果能以更低的代价被保留和再次使用。\nGPU仍然负责模型计算，CPU和存储系统则协助减少那些本可以避免的重复工作。至于方案值不值得部署，最终还得看真实负载下的响应时间、吞吐量，以及把服务器、内存、存储和能耗都算进去的总成本。\n毕竟，运营方买下昂贵的GPU，是希望它多干点新活儿。已经算过、又能复用的内容，就尽量别再付一次计算的账。\n最后，若是小伙伴们想要了解更多关于英特尔CPU的最新进展，欢迎锁定9月22日-9月23日的英特尔技术创新与产业生态大会（关注【英特尔商用】报名参加）！","reading_time_min":1,"extraction":{"state":"ok","confidence":0.9,"error":null,"explanation":"High confidence: full text extraction produced 5905 characters.","diagnostics_url":"/api/diagnose?url=https%3A//finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html%3Fvt%3D4%26cid%3D76993%26node_id%3D76993","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 5905 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":5905,"summary_length":5905,"usable_text_length":5905,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":5905,"summary_length":5905}}},"quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 5905 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":5905,"summary_length":5905,"usable_text_length":5905,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":5905,"summary_length":5905}},"actions":{"read":"/item/83485","export_markdown":"/api/items/83485/export?format=markdown","export_json":"/api/items/83485/export?format=json","diagnose":"/api/diagnose?url=https%3A//finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html%3Fvt%3D4%26cid%3D76993%26node_id%3D76993"}},"digest":{"id":83485,"title":"把记忆交给CPU，大模型会变快 - 新浪财经","url":"https://finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html?vt=4&cid=76993&node_id=76993","source":"新浪财经","topic":"ai","published_at":"2026-09-16T03:44:29+00:00","excerpt":"把记忆交给CPU，大模型会变快 （来源：量子位） 拿Agent做Coding，想必大家都已经很熟悉了。 不过，如果我们把目光从聊天窗口移到背后的数据中心，事情就没那么简单了。 一个Coding Agent改跨十几个文件的bug，需要反复读代码、查资料、跑测试。前几轮交互可能还很顺畅，但任务继续跑下去，系统要处理的历史信息也会越积越多。 当成千上万个Agent同时这样干活，运营方就可能遇到一个头疼的问题：服务器还在跑，能接住的并发却越来越吃紧，有些请求连吐出第一个Token都要等上好一会儿。 难道只能继续加GPU？ 非也非也。…","quality_bucket":"high","quality_reason":"High confidence: full text extraction produced 5905 characters.","reading_time_min":1,"cluster_id":null},"card":{"display_title":"把记忆交给CPU，大模型会变快 - 新浪财经","subtitle":"新浪财经 · 2026-09-16","summary":"把记忆交给CPU，大模型会变快 （来源：量子位） 拿Agent做Coding，想必大家都已经很熟悉了。 不过，如果我们把目光从聊天窗口移到背后的数据中心，事情就没那么简单了。 一个Coding Agent改跨十几个文件的bug，需要反复读代码、查资料、跑测试。前几轮交互可能还很顺畅，但任务继续跑下去，系统要处理的历史信息也会越积越多。…","badges":["quality:high"],"links":{"read":"/item/83485","original":"https://finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html?vt=4&cid=76993&node_id=76993","diagnose":"/api/diagnose?url=https%3A//finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html%3Fvt%3D4%26cid%3D76993%26node_id%3D76993"},"quality_warning":null},"export":{"title":"把记忆交给CPU，大模型会变快 - 新浪财经","url":"https://finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html?vt=4&cid=76993&node_id=76993","summary":"把记忆交给CPU，大模型会变快\n（来源：量子位）\n拿Agent做Coding，想必大家都已经很熟悉了。\n不过，如果我们把目光从聊天窗口移到背后的数据中心，事情就没那么简单了。\n一个Coding Agent改跨十几个文件的bug，需要反复读代码、查资料、跑测试。前几轮交互可能还很顺畅，但任务继续跑下去，系统要处理的历史信息也会越积越多。\n当成千上万个Agent同时这样干活，运营方就可能遇到一个头疼的问题：服务器还在跑，能接住的并发却越来越吃紧，有些请求连吐出第一个Token都要等上好一会儿。\n难道只能继续加GPU？\n非也非也。\n模型还是那个模型，服务器也还是那个服务器，问题的根儿啊，其实是出在了记忆。\n因为大模型每生成一个新的Token，都还要继续用到前文的信息。为了不用每次从头计算，系统会把前面已经算好的中间结果保存起来；会话越聊越长，这份记忆自然也就越堆越厚。\n一旦显存装不下，部分缓存被清走，等Agent下一轮又需要这些历史信息时，就可能重新做一遍Prefill。前面明明已经算过的东西，又得花GPU时间再算一次。\n尤其是到了Agent时代，AI很少干一问一答的事儿，更多是那种反复需要思考、规划和行动的任务，期间会不断积累会话历史、检索证据、工具结果和中间状态等等。\n于是乎，一个过去藏在大模型推理内部、普通用户几乎感知不到的东西，就这样被推到了台面儿上——KV Cache。\n它的特点，说起来就一个字：大。但运营方又不能为了省空间，任由已经算过的内容反复占用GPU重算。所以，长上下文推理要算的这笔账，也就从算力延伸到了存储、搬运和复用。\n而这件事的破局之道，并不是你以为的GPU，而是——CPU。\n我们先把KV Cache这件事说清楚。\n对于采用因果自注意力的Transformer模型来说，前面处理过的Token，会在注意力层中留下对应的Key和Value。模型生成后续Token时，还能继续使用这些结果。推理系统把它们缓存起来，就有了KV Cache。\n你可以把它理解成模型读书时做的笔记。后面再遇到需要联系上文的地方，模型可以调用笔记，省去对已有Token的重复计算。\n所以，我们这里说的记忆，指的是推理过程中留下的中间状态，模型的权重并没有因此发生变化。\n这份笔记确实能省计算，但它也是实实在在要占地方的。而且，Agent读的东西越多，服务器要替它保存的笔记往往就越厚。\n那么这个增长到底有多明显呢？\n我们拿Qwen3-8B算一笔账。按照它的公开模型配置，在KV Cache采用BF16或FP16、每个数值占2字节的条件下，每个Token对应的KV数据是147456字节，也就是约147KB。这还没有计入缓存管理等额外开销。\n为什么一个Token会带出这么大一份缓存？因为系统保存的并不是这个Token的文字本身，而是它在多层注意力计算中对应的Key和Value。按这个模型的结构，计算式就是：2份K/V × 36层 × 8个KV头 × 每头128维 × 2字节。\n接下来，我们只借用这个每Token开销，做一次百万上下文的容量推演：如果需要缓存100万个Token，对应的KV数据就约为147GB。注意，这里的1M是测算假设，不代表Qwen3-8B实际支持百万上下文；它的官方说明是原生32768 Token，采用YaRN可扩展到131072 Token。\n单个请求已经如此，如果把请求规模也放大呢？假设一个服务有300万日活用户，每人每天发出10个请求，而且每个请求都按前面的1M上下文计算，一天就是3000万个请求。\n先不考虑压缩和共享复用，按每个请求约147GB全量累加，对应的日累计KV数据规模就是：300万 × 10 × 147GB ≈ 4410PB。如果日活再增加到3亿，相同假设下，这个数字还会放大100倍，达到约441000PB，也就是441EB。\n不过，这里得分清两件事：一天的请求累计涉及多少KV数据，和数据中心同时需要存下多少KV数据，不是一回事。上面是每次请求都独立、全量计数的规模推演，不能直接当作存储采购清单。\n实际要配多大的缓存池，运营方还得看高峰时有多少请求同时运行、缓存要留多久、哪些前缀能够共享，以及压缩和淘汰策略。已经复用的同一份缓存，也不该因为被请求多次就重复占一份容量。\n当然，不同模型的“笔记本”也不一样。模型层数、KV头数量、缓存精度等都会影响大小，不能只看参数量。上面的数字不是某个服务的真实用量，却能说明运营方为什么要格外关注这份“记忆”：上下文长度和请求规模，会一起把缓存的账越算越大。\n而GPU的显存，还要放模型权重和运行时的其他数据。大家共用这么多空间，KV Cache占得越多，系统留给其他请求的余地就可能越小。\n这时候，推理系统就得做取舍了：减少同时处理的请求，把部分缓存卸载到其他存储层，或者清理暂时不用的缓存。\n再拿前面的Coding Agent来说。它可能正在等工具跑测试，系统趁这个空当，把它的一部分历史缓存清掉了。等测试结果返回，Agent准备接着干活，却发现需要用的缓存已经不在了。\n如果其他存储层也没保存这份数据，模型就得重新处理相应的历史输入、重建缓存。这个处理输入的阶段叫Prefill，输入越长，通常就越费时。用户等待首个Token的时间，也就是TTFT，便可能跟着增加。\n算过一遍的内容，过一会儿又得再算。对运营方来说，消耗掉的不只是电和时间，还有这批GPU原本可以用来处理新任务、生成新Token的机会。\n这也解释了，为什么KV Cache再大，运营方仍然要认真考虑怎么把它用好。\n从成本角度看，GPU应该尽量把资源花在必要的新输入处理和新Token生成上，少为已经处理过、又可以复用的历史内容重复做Prefill。KV Cache保留下来的，正是这部分已有计算的成果。\n当然，这不意味着所有缓存都得永久保存。真正要算的是：保留和取回一份缓存，能不能比下次重算更划算？谁能把这笔账算好，谁就更有机会用同一套设备服务更多请求。\n聊到这里，你可能已经想到了，显存放不下，难道不能先存到别处，等要用的时候再拿回来？\n可以，这也正是“以存代算”的思路。\n在服务器里，GPU显存之外还有CPU侧的DDR内存、本地SSD，以及远端存储。它们的容量、速度和成本各不相同，正好可以用来存放不同活跃程度的缓存。\n例如眼下正在生成回答，需要频繁访问的数据，就留在GPU的高带宽显存HBM里；短时间内可能继续用到的缓存，可以先放进CPU侧的DDR内存；至于更久没有访问、但还值得保留的历史缓存，则可以继续下沉到SSD或远端存储。\n再聚焦到Coding Agent的任务里，就是它写代码时，相关缓存尽量留在GPU侧；任务暂停后，系统可以把缓存转存到内存；如果这段会话很久没继续，再考虑把数据移到更下一层。用户回来后，系统根据缓存命中情况，把需要的部分取回来。\n对运营方来说，这样安排的直接好处是：显存不用一直替所有历史会话占着位置，腾出的空间可以交给正在运行的请求。\n不过，把东西搬出去只是第一步。哪些数据可以搬、应该放在哪里、什么时候得提前取回来，总得有个地方统一管理。\nCPU就在这里发挥作用。\n推理服务运行在主机侧的管理逻辑，需要跟踪会话状态、剩余容量和缓存访问情况。CPU连接的大容量内存和存储，也为显存之外的缓存池提供了基础。系统可以结合这些信息，决定一份KV Cache接下来该留在哪一层。\n这类机制其实已经出现在一些推理框架里了。例如，vLLM的KV Offloading支持将缓存块卸载到CPU内存，还可以配置次级存储层。在它描述的多层方案里，次级存储与GPU之间的数据传输，会经过CPU侧的缓存层。\n但这里还有个问题，那就是数据是存下来了，搬回来会不会更慢？\n毕竟，DDR、SSD和远端存储的访问条件各不相同。假如取回缓存比重新计算还费时，用户还是得等，甚至可能等得更久。所以，系统需要根据访问频率和传输开销安排缓存，不能一股脑地把数据全塞到硬盘里。\n要减少搬运量，另一个办法就是压缩。数据变小了，同样的空间能存得更多，传输时要搬的字节也更少。\n可压缩也不是白来的，压缩和解压都要花时间，如果全让通用CPU核心来干，又可能挤占请求调度等工作需要的资源。\n更麻烦的是，KV Cache本身就是大体量数据，压缩和解压的速度如果跟不上GPU侧的数据吞吐，压缩环节反而会成为新的瓶颈。单纯依靠通用CPU核心做软件压缩，很难同时兼顾高吞吐和CPU资源占用。\n这也是QAT的意义所在。它把压缩、解压交给专用硬件处理，在提升吞吐的同时释放通用CPU核心。相比只依赖CPU Core的软件方案，这种内置专用压缩加速能力，也构成了英特尔在KV Cache分层卸载上的一个差异化优势。\n于是问题就不只是能不能压，还变成了能不能压得足够快。\n对此，CPU老巨头英特尔给出了一套面向数据中心的KV Cache优化思路。\n围绕KV Cache，英特尔布局了KV Shrink、KV Fuse、KV Cascade和KV Infinity四个技术方向。\n名字虽然看着多，但我们用一张表格，根据它们各自要解决的问题来分类，就一目了然了：\n其中，KV Shrink已经有较具体的实现和测试披露，我们先来重点看看它。\nKV Shrink可以把前面讲的分层管理与硬件压缩结合起来，并提供冷热调度API，让业务系统按自己的策略决定缓存什么时候下沉、什么时候回载。内存吃紧时，系统还可以把较冷的数据继续转存到SSD等下一层介质。\n而负责分担压缩工作的，是英特尔的QAT（QuickAssist Technology）。\n它能够把压缩、解压等任务交给专用加速单元，减少对通用CPU核心的占用。英特尔从第四代至强可扩展处理器的相关型号开始集成QAT硬件。\n这么一来，CPU侧的管理逻辑继续负责调度，专用硬件接过压缩任务，系统便有机会在控制额外开销的同时，缩小缓存体积。\n英特尔还做了一个更细的调整：重新排列KV Cache的存储格式，让压缩算法更容易压缩这些数据。\n重排后，压缩所节省的空间从原先的10%以上增加到20%以上，空间降幅约为20%至30%。这条路径采用无损压缩，解压后能够恢复原始KV数据，不会因压缩而丢失数据。\n虽然20%-30%这个数字乍一看似乎没那么夸张，但把缓存池的规模放大，差别就出来了。\n例如，一个数据中心需要保留500TB的KV Cache，如果能压缩掉30%，对应的就是约150TB空间。这里算的是实际缓存池的容量，和前面按请求累加的日累计数据量不同。至于运营方最终能省下多少费用，还得结合存储介质、保留时间和业务负载来算，不能直接给总成本也打个七折。\n空间这块算是有收益了，那速度又怎么样呢？\n在英特尔给出的一组测试中，使用双路至强金牌6554S处理器、两张英伟达L20 GPU和Qwen3-32B模型，在80%缓存命中率下，相较未开启分层卸载的原生vLLM基线，KV Shrink在测试覆盖的输入长度和并发组合中，TTFT最高获得约5倍加速。\n除此之外，QAT硬件压缩方案的整体性能约为CPU软件压缩方案的两倍。在相同分层卸载机制下，相较不启用压缩，开启QAT压缩带来的额外TTFT开销低于10%。\n从这两项对照测试来看，压缩确实会多一道工序，但在这组测试里，专用硬件把额外开销控制在了较小范围内，让系统能够用一定的时间代价换取存储空间。\n再来看一组面向Coding Agent服务的测试。\n英特尔与道客联合实验室采用另一套配置进行测试：双路至强金牌6554S、八张H800和Qwen3-32B FP8模型，缓存命中率同样为80%。相较测试中的LMCache方案，KV Shrink在单路负载下的平均TTFT由129.81毫秒降至114.13毫秒，降幅约12.1%；八路并发时，降幅约为4.6%。\n你会发现，换一套设备、换一个比较对象，加速幅度也变了。所以数据中心运营方真正部署时，还是要把自己的上下文长度、并发量和缓存命中率带进去测试。业务里重复访问历史内容的机会越少，缓存复用能帮上的忙通常也越有限。\n除了把一段会话存好，运营方承载的企业服务还可能遇到另一类需求：几份文档以前都处理过，现在想把它们组合起来用，能不能少算一点？\n这就是KV Fuse关注的问题。但模型处理文档时会受到前文和位置等因素影响，几份独立生成的KV Cache通常不能直接拼接。KV Fuse尝试通过缓存融合和部分重计算，保留其中能够复用的工作。\n如果问题出在“给模型看的东西太多”，KV Cascade则尝试先请辅助模型做筛选或处理，把相关内容交给主模型。例如，一大堆文档里只有部分信息和当前问题有关，就可以先缩小主模型需要处理的范围。\n而KV Infinity面向持续增长的长任务，通过按需加载和预取，尝试缓解缓存必须全部常驻HBM的压力，让系统能够利用显存之外的资源。具体能扩展到什么程度，仍然要看访问方式和传输效率。\n这些方向背后，英特尔想要做的事就已经比较清楚了：\n让CPU协助管理推理中产生的大量计算结果，再通过内存、存储和专用加速单元，把保存和使用这些结果的成本降下来。\n对于具备相应QAT硬件的至强服务器，这提供了一条利用已有平台能力的优化路径。当然，实际接入还要检查内存、存储和软件等条件。\n最后，再回到数据中心的那笔账。单个用户看到的，也许只是Coding Agent有没有及时回答；运营方要考虑的，则是成千上万个请求涌进来之后，系统还能不能以可接受的成本持续提供服务。\nKV Cache越大，全部留在显存里就越难；可如果把还有复用价值的缓存一清了之，GPU又得为同一段历史反复开工。运营方需要在保存、搬运和重算之间找到合适的平衡。\n英特尔押注KV Cache，争取的正是这个位置：通过CPU侧的管理、分层存储和硬件压缩，让已有计算结果能以更低的代价被保留和再次使用。\nGPU仍然负责模型计算，CPU和存储系统则协助减少那些本可以避免的重复工作。至于方案值不值得部署，最终还得看真实负载下的响应时间、吞吐量，以及把服务器、内存、存储和能耗都算进去的总成本。\n毕竟，运营方买下昂贵的GPU，是希望它多干点新活儿。已经算过、又能复用的内容，就尽量别再付一次计算的账。\n最后，若是小伙伴们想要了解更多关于英特尔CPU的最新进展，欢迎锁定9月22日-9月23日的英特尔技术创新与产业生态大会（关注【英特尔商用】报名参加）！","source":"新浪财经","date":"2026-09-16T03:44:29+00:00","content":"把记忆交给CPU，大模型会变快\n（来源：量子位）\n拿Agent做Coding，想必大家都已经很熟悉了。\n不过，如果我们把目光从聊天窗口移到背后的数据中心，事情就没那么简单了。\n一个Coding Agent改跨十几个文件的bug，需要反复读代码、查资料、跑测试。前几轮交互可能还很顺畅，但任务继续跑下去，系统要处理的历史信息也会越积越多。\n当成千上万个Agent同时这样干活，运营方就可能遇到一个头疼的问题：服务器还在跑，能接住的并发却越来越吃紧，有些请求连吐出第一个Token都要等上好一会儿。\n难道只能继续加GPU？\n非也非也。\n模型还是那个模型，服务器也还是那个服务器，问题的根儿啊，其实是出在了记忆。\n因为大模型每生成一个新的Token，都还要继续用到前文的信息。为了不用每次从头计算，系统会把前面已经算好的中间结果保存起来；会话越聊越长，这份记忆自然也就越堆越厚。\n一旦显存装不下，部分缓存被清走，等Agent下一轮又需要这些历史信息时，就可能重新做一遍Prefill。前面明明已经算过的东西，又得花GPU时间再算一次。\n尤其是到了Agent时代，AI很少干一问一答的事儿，更多是那种反复需要思考、规划和行动的任务，期间会不断积累会话历史、检索证据、工具结果和中间状态等等。\n于是乎，一个过去藏在大模型推理内部、普通用户几乎感知不到的东西，就这样被推到了台面儿上——KV Cache。\n它的特点，说起来就一个字：大。但运营方又不能为了省空间，任由已经算过的内容反复占用GPU重算。所以，长上下文推理要算的这笔账，也就从算力延伸到了存储、搬运和复用。\n而这件事的破局之道，并不是你以为的GPU，而是——CPU。\n我们先把KV Cache这件事说清楚。\n对于采用因果自注意力的Transformer模型来说，前面处理过的Token，会在注意力层中留下对应的Key和Value。模型生成后续Token时，还能继续使用这些结果。推理系统把它们缓存起来，就有了KV Cache。\n你可以把它理解成模型读书时做的笔记。后面再遇到需要联系上文的地方，模型可以调用笔记，省去对已有Token的重复计算。\n所以，我们这里说的记忆，指的是推理过程中留下的中间状态，模型的权重并没有因此发生变化。\n这份笔记确实能省计算，但它也是实实在在要占地方的。而且，Agent读的东西越多，服务器要替它保存的笔记往往就越厚。\n那么这个增长到底有多明显呢？\n我们拿Qwen3-8B算一笔账。按照它的公开模型配置，在KV Cache采用BF16或FP16、每个数值占2字节的条件下，每个Token对应的KV数据是147456字节，也就是约147KB。这还没有计入缓存管理等额外开销。\n为什么一个Token会带出这么大一份缓存？因为系统保存的并不是这个Token的文字本身，而是它在多层注意力计算中对应的Key和Value。按这个模型的结构，计算式就是：2份K/V × 36层 × 8个KV头 × 每头128维 × 2字节。\n接下来，我们只借用这个每Token开销，做一次百万上下文的容量推演：如果需要缓存100万个Token，对应的KV数据就约为147GB。注意，这里的1M是测算假设，不代表Qwen3-8B实际支持百万上下文；它的官方说明是原生32768 Token，采用YaRN可扩展到131072 Token。\n单个请求已经如此，如果把请求规模也放大呢？假设一个服务有300万日活用户，每人每天发出10个请求，而且每个请求都按前面的1M上下文计算，一天就是3000万个请求。\n先不考虑压缩和共享复用，按每个请求约147GB全量累加，对应的日累计KV数据规模就是：300万 × 10 × 147GB ≈ 4410PB。如果日活再增加到3亿，相同假设下，这个数字还会放大100倍，达到约441000PB，也就是441EB。\n不过，这里得分清两件事：一天的请求累计涉及多少KV数据，和数据中心同时需要存下多少KV数据，不是一回事。上面是每次请求都独立、全量计数的规模推演，不能直接当作存储采购清单。\n实际要配多大的缓存池，运营方还得看高峰时有多少请求同时运行、缓存要留多久、哪些前缀能够共享，以及压缩和淘汰策略。已经复用的同一份缓存，也不该因为被请求多次就重复占一份容量。\n当然，不同模型的“笔记本”也不一样。模型层数、KV头数量、缓存精度等都会影响大小，不能只看参数量。上面的数字不是某个服务的真实用量，却能说明运营方为什么要格外关注这份“记忆”：上下文长度和请求规模，会一起把缓存的账越算越大。\n而GPU的显存，还要放模型权重和运行时的其他数据。大家共用这么多空间，KV Cache占得越多，系统留给其他请求的余地就可能越小。\n这时候，推理系统就得做取舍了：减少同时处理的请求，把部分缓存卸载到其他存储层，或者清理暂时不用的缓存。\n再拿前面的Coding Agent来说。它可能正在等工具跑测试，系统趁这个空当，把它的一部分历史缓存清掉了。等测试结果返回，Agent准备接着干活，却发现需要用的缓存已经不在了。\n如果其他存储层也没保存这份数据，模型就得重新处理相应的历史输入、重建缓存。这个处理输入的阶段叫Prefill，输入越长，通常就越费时。用户等待首个Token的时间，也就是TTFT，便可能跟着增加。\n算过一遍的内容，过一会儿又得再算。对运营方来说，消耗掉的不只是电和时间，还有这批GPU原本可以用来处理新任务、生成新Token的机会。\n这也解释了，为什么KV Cache再大，运营方仍然要认真考虑怎么把它用好。\n从成本角度看，GPU应该尽量把资源花在必要的新输入处理和新Token生成上，少为已经处理过、又可以复用的历史内容重复做Prefill。KV Cache保留下来的，正是这部分已有计算的成果。\n当然，这不意味着所有缓存都得永久保存。真正要算的是：保留和取回一份缓存，能不能比下次重算更划算？谁能把这笔账算好，谁就更有机会用同一套设备服务更多请求。\n聊到这里，你可能已经想到了，显存放不下，难道不能先存到别处，等要用的时候再拿回来？\n可以，这也正是“以存代算”的思路。\n在服务器里，GPU显存之外还有CPU侧的DDR内存、本地SSD，以及远端存储。它们的容量、速度和成本各不相同，正好可以用来存放不同活跃程度的缓存。\n例如眼下正在生成回答，需要频繁访问的数据，就留在GPU的高带宽显存HBM里；短时间内可能继续用到的缓存，可以先放进CPU侧的DDR内存；至于更久没有访问、但还值得保留的历史缓存，则可以继续下沉到SSD或远端存储。\n再聚焦到Coding Agent的任务里，就是它写代码时，相关缓存尽量留在GPU侧；任务暂停后，系统可以把缓存转存到内存；如果这段会话很久没继续，再考虑把数据移到更下一层。用户回来后，系统根据缓存命中情况，把需要的部分取回来。\n对运营方来说，这样安排的直接好处是：显存不用一直替所有历史会话占着位置，腾出的空间可以交给正在运行的请求。\n不过，把东西搬出去只是第一步。哪些数据可以搬、应该放在哪里、什么时候得提前取回来，总得有个地方统一管理。\nCPU就在这里发挥作用。\n推理服务运行在主机侧的管理逻辑，需要跟踪会话状态、剩余容量和缓存访问情况。CPU连接的大容量内存和存储，也为显存之外的缓存池提供了基础。系统可以结合这些信息，决定一份KV Cache接下来该留在哪一层。\n这类机制其实已经出现在一些推理框架里了。例如，vLLM的KV Offloading支持将缓存块卸载到CPU内存，还可以配置次级存储层。在它描述的多层方案里，次级存储与GPU之间的数据传输，会经过CPU侧的缓存层。\n但这里还有个问题，那就是数据是存下来了，搬回来会不会更慢？\n毕竟，DDR、SSD和远端存储的访问条件各不相同。假如取回缓存比重新计算还费时，用户还是得等，甚至可能等得更久。所以，系统需要根据访问频率和传输开销安排缓存，不能一股脑地把数据全塞到硬盘里。\n要减少搬运量，另一个办法就是压缩。数据变小了，同样的空间能存得更多，传输时要搬的字节也更少。\n可压缩也不是白来的，压缩和解压都要花时间，如果全让通用CPU核心来干，又可能挤占请求调度等工作需要的资源。\n更麻烦的是，KV Cache本身就是大体量数据，压缩和解压的速度如果跟不上GPU侧的数据吞吐，压缩环节反而会成为新的瓶颈。单纯依靠通用CPU核心做软件压缩，很难同时兼顾高吞吐和CPU资源占用。\n这也是QAT的意义所在。它把压缩、解压交给专用硬件处理，在提升吞吐的同时释放通用CPU核心。相比只依赖CPU Core的软件方案，这种内置专用压缩加速能力，也构成了英特尔在KV Cache分层卸载上的一个差异化优势。\n于是问题就不只是能不能压，还变成了能不能压得足够快。\n对此，CPU老巨头英特尔给出了一套面向数据中心的KV Cache优化思路。\n围绕KV Cache，英特尔布局了KV Shrink、KV Fuse、KV Cascade和KV Infinity四个技术方向。\n名字虽然看着多，但我们用一张表格，根据它们各自要解决的问题来分类，就一目了然了：\n其中，KV Shrink已经有较具体的实现和测试披露，我们先来重点看看它。\nKV Shrink可以把前面讲的分层管理与硬件压缩结合起来，并提供冷热调度API，让业务系统按自己的策略决定缓存什么时候下沉、什么时候回载。内存吃紧时，系统还可以把较冷的数据继续转存到SSD等下一层介质。\n而负责分担压缩工作的，是英特尔的QAT（QuickAssist Technology）。\n它能够把压缩、解压等任务交给专用加速单元，减少对通用CPU核心的占用。英特尔从第四代至强可扩展处理器的相关型号开始集成QAT硬件。\n这么一来，CPU侧的管理逻辑继续负责调度，专用硬件接过压缩任务，系统便有机会在控制额外开销的同时，缩小缓存体积。\n英特尔还做了一个更细的调整：重新排列KV Cache的存储格式，让压缩算法更容易压缩这些数据。\n重排后，压缩所节省的空间从原先的10%以上增加到20%以上，空间降幅约为20%至30%。这条路径采用无损压缩，解压后能够恢复原始KV数据，不会因压缩而丢失数据。\n虽然20%-30%这个数字乍一看似乎没那么夸张，但把缓存池的规模放大，差别就出来了。\n例如，一个数据中心需要保留500TB的KV Cache，如果能压缩掉30%，对应的就是约150TB空间。这里算的是实际缓存池的容量，和前面按请求累加的日累计数据量不同。至于运营方最终能省下多少费用，还得结合存储介质、保留时间和业务负载来算，不能直接给总成本也打个七折。\n空间这块算是有收益了，那速度又怎么样呢？\n在英特尔给出的一组测试中，使用双路至强金牌6554S处理器、两张英伟达L20 GPU和Qwen3-32B模型，在80%缓存命中率下，相较未开启分层卸载的原生vLLM基线，KV Shrink在测试覆盖的输入长度和并发组合中，TTFT最高获得约5倍加速。\n除此之外，QAT硬件压缩方案的整体性能约为CPU软件压缩方案的两倍。在相同分层卸载机制下，相较不启用压缩，开启QAT压缩带来的额外TTFT开销低于10%。\n从这两项对照测试来看，压缩确实会多一道工序，但在这组测试里，专用硬件把额外开销控制在了较小范围内，让系统能够用一定的时间代价换取存储空间。\n再来看一组面向Coding Agent服务的测试。\n英特尔与道客联合实验室采用另一套配置进行测试：双路至强金牌6554S、八张H800和Qwen3-32B FP8模型，缓存命中率同样为80%。相较测试中的LMCache方案，KV Shrink在单路负载下的平均TTFT由129.81毫秒降至114.13毫秒，降幅约12.1%；八路并发时，降幅约为4.6%。\n你会发现，换一套设备、换一个比较对象，加速幅度也变了。所以数据中心运营方真正部署时，还是要把自己的上下文长度、并发量和缓存命中率带进去测试。业务里重复访问历史内容的机会越少，缓存复用能帮上的忙通常也越有限。\n除了把一段会话存好，运营方承载的企业服务还可能遇到另一类需求：几份文档以前都处理过，现在想把它们组合起来用，能不能少算一点？\n这就是KV Fuse关注的问题。但模型处理文档时会受到前文和位置等因素影响，几份独立生成的KV Cache通常不能直接拼接。KV Fuse尝试通过缓存融合和部分重计算，保留其中能够复用的工作。\n如果问题出在“给模型看的东西太多”，KV Cascade则尝试先请辅助模型做筛选或处理，把相关内容交给主模型。例如，一大堆文档里只有部分信息和当前问题有关，就可以先缩小主模型需要处理的范围。\n而KV Infinity面向持续增长的长任务，通过按需加载和预取，尝试缓解缓存必须全部常驻HBM的压力，让系统能够利用显存之外的资源。具体能扩展到什么程度，仍然要看访问方式和传输效率。\n这些方向背后，英特尔想要做的事就已经比较清楚了：\n让CPU协助管理推理中产生的大量计算结果，再通过内存、存储和专用加速单元，把保存和使用这些结果的成本降下来。\n对于具备相应QAT硬件的至强服务器，这提供了一条利用已有平台能力的优化路径。当然，实际接入还要检查内存、存储和软件等条件。\n最后，再回到数据中心的那笔账。单个用户看到的，也许只是Coding Agent有没有及时回答；运营方要考虑的，则是成千上万个请求涌进来之后，系统还能不能以可接受的成本持续提供服务。\nKV Cache越大，全部留在显存里就越难；可如果把还有复用价值的缓存一清了之，GPU又得为同一段历史反复开工。运营方需要在保存、搬运和重算之间找到合适的平衡。\n英特尔押注KV Cache，争取的正是这个位置：通过CPU侧的管理、分层存储和硬件压缩，让已有计算结果能以更低的代价被保留和再次使用。\nGPU仍然负责模型计算，CPU和存储系统则协助减少那些本可以避免的重复工作。至于方案值不值得部署，最终还得看真实负载下的响应时间、吞吐量，以及把服务器、内存、存储和能耗都算进去的总成本。\n毕竟，运营方买下昂贵的GPU，是希望它多干点新活儿。已经算过、又能复用的内容，就尽量别再付一次计算的账。\n最后，若是小伙伴们想要了解更多关于英特尔CPU的最新进展，欢迎锁定9月22日-9月23日的英特尔技术创新与产业生态大会（关注【英特尔商用】报名参加）！","confidence":0.9,"diagnostics_url":"/api/diagnose?url=https%3A//finance.sina.cn/stock/jdts/2026-09-16/detail-iniryvce3039198.d.html%3Fvt%3D4%26cid%3D76993%26node_id%3D76993","quality_bucket":"high","failure_kind":"none","retryable":false,"quality_reason":"High confidence: full text extraction produced 5905 characters.","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 5905 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":5905,"summary_length":5905,"usable_text_length":5905,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":5905,"summary_length":5905}},"tags":[],"format_contract_version":"news_item_formats.v1"}}}