← 返回 PaperDaily
大模型与智能体
告别显存墙！DualDecoder用预测预取颠覆LLM推理
长上下文LLM推理中，KV缓存的内存占用一直是瓶颈，现有稀疏KV方法引入的GPU辅助状态反而成了新“内存墙”。这篇来自复旦大学与蚂蚁集团的论文找到了一个很巧妙的突破口：相邻解码步骤的KV索引具有强可预测性，从而可以用预测性预取彻底替换掉GPU驻留的辅助状态。方法设计的双token解码流水线、层感知传输调度和乒乓缓冲区都很实在，在128K上下文下吞吐量提升最高
龙哥读论文
发布于 2026-09-05 00:31:11
阅读 5
查看原文
原论文信息如下：
大家有没有想过，当你在使用那些“无所不知”的大模型，让它帮你分析一本厚厚的财报，或者梳理整个项目的代码库时，它背后其实在经历一场怎样的“内存战争”？尤其是在处理超长上下文（比如128K甚至1M个token）时，大模型会显得有点“吃力”。这背后的罪魁祸首，往往就是那个大名鼎鼎的“KV Cache”——也就是模型推理过程中缓存下来的键值对。
为了解决这个内存墙，聪明的同学们想出了“稀疏化”的妙招：既然每一次推理只用得到一小部分历史KV，那干嘛不把大部分KV数据放到内存更大的CPU（内存）里，只把当前步骤需要的少数KV拉到显存（GPU HBM）里呢？这听起来很完美，对吧？
错！坑就在这里。现有系统为了能从CPU内存快速捞回来这些稀疏的KV，被迫在GPU显存里养了一大堆“辅助状态”（Auxiliary States）——比如低秩的Key表示、量化后的KV指引等等。结果呢？这些原本是为了“省流”而生的辅助数据，自己却成了显存的新的“吞金兽”，有时候甚至占据了超过60%的显存！
龙哥推荐理由：
原论文信息如下：
要理解今天这篇论文有多么“点睛”，我们得先看看大模型跑长上下文推理时到底有多痛苦。
大模型在生成每一个新token时，都需要“回顾”之前所有历史token的信息。为了避免重复计算，系统会把之前每一层计算的Key（K）和Value（V）张量缓存下来，这就是所谓的KV Cache。这个KV Cache的大小直接正比于序列长度、批量大小（Batch Size）和模型层数。当我们在处理百万级token的长文档时，KV Cache的尺寸会膨胀到几十甚至上百GB。
现在最贵的H100 GPU也就是80GB显存，宝贵的显存既要装模型权重，又要装激活值，剩下的空间根本塞不下这么大的KV Cache。因此，大佬们想出了一个好办法——动态稀疏KV Cache。
其核心思想是：把95%以上的KV Cache数据都存放在更便宜的CPU内存（Host Memory）里，然后每解码一个token，只根据当前的Query动态地从CPU内存“捞”回一小部分至关重要的稀疏KV到GPU显存中进行注意力计算。这一波操作的代表作有ShadowKV和SpeCache。
但是，正如论文中指出的，这些系统虽然减少了KV Entries本身的显存占用，却带来了新的开销。因为从CPU捞数据的速度（比如PCIe 5.0只有64GB/s）远远低于HBM（大约4.8TB/s），为了掩盖这个延迟，系统不得不在GPU显存中保留各种“辅助状态”来加速数据的挑选与重建。
图4：一个典型推理过程的显存占用随时间的变化。可以看到，K Landmarks 和 Low-rank K等辅助状态（图中Residency部分）占据了高达64%的GPU显存，远比稀疏KV本身要大得多，而且在整个解码过程中常驻显存。
如图4所示，这些“辅助状态”（图中称为KV-cache-auxiliary residency）就像一对隐形的大手，牢牢压住了显存占用。作者通过实验发现，在图5中，即使使用了ShadowKV这样的先进系统，其辅助状态的显存占用依然占据了至少30%的HBM，在8B模型上更是高达惊人的74.7%。这也直接导致了最大并发请求数（Batch Size）被死死卡住，系统难以发挥硬件的全部算力。
图5：不同模型大小下辅助状态（KV-cache-auxiliary residency）占GPU HBM的百分比。ShadowKV和SpeCache的辅助状态占用都在30%以上，甚至远高于理想状态（Ideal）下模型权重及其他元数据之外的剩余空间。
所以，现在的问题变成了：难道我们为了省掉KV Entry本身的存储空间，就必须牺牲大量显存去养这些辅助状态吗？有没有办法摆脱这种“请神容易送神难”的局面？
预测性KV检索：打破辅助状态瓶颈
这篇论文最吸引人的地方就在于它那犀利的洞察。作者发现，在动态稀疏KV Cache系统中，下一个解码步骤需要提取哪一部分KV，其实是可以被“猜”出来的。
在现有的系统里，假设第i步解码出来的token是Ti，那么为了生成第i+1个token，系统需要根据当前token Ti和静态的K Landmarks（一种预计算的稀疏摘要）来计算一个“检索索引”（Retrieval Index），这个索引告诉系统应该去CPU内存里取哪些KV chunk过来。
关键来了：如果我们在第i-1步的时候，就能“猜到”第i步会生成什么token，那我们是不是就可以在真正需要之前，提前把KV给取回来？这就像看《名侦探柯南》，虽然不能百分之百猜到下一集凶手是谁，但根据前面的线索，你完全可以把最有可能的几本“犯人笔记”提前借出来！
图6：通过推测Token进行KV检索预测。图中展示了在Step 2中，模型除了生成真正的输出Token Token3外，还可以生成一个推测Token Token3'。基于Token3'和K Landmark，系统可以预测下一个KV索引，从而提前预取KV。
图6展示了这个过程。在每个解码步骤中，模型不仅生成真实的输出Token（如Token3），还会额外地生成一个“推测Token”（Speculative Token）（如Token3'）。这个推测Token是紧跟在当前token之后的“假想未来token”，拥有非常相似的上下文信息。虽然它未必是真正的下一个token，但它足以帮助我们生成一个非常准确的检索索引。
图7(a)：KV预测与Token预测准确率对比。橙色线（KV Prediction）的准确率稳定在88%以上，而蓝色线（Token Prediction）则波动巨大甚至很低，说明即使Token预测不准，KV预测依然很准。
正如论文中图7(a)所示，虽然推测Token本身的预测准确率可能很低（蓝色线），但基于这个推测Token计算出来的KV检索索引的准确率（橙色线）却非常高，平均达到了88%！这意味着，我们在绝大多数情况下都能提前准确地找到下一个解码步骤所需的数据。
既然KV检索是可以预测的，那么一个天大的机会就摆在了面前。我们不再需要那些昂贵且占地方的“辅助状态”（比如低秩K等）去辅助快速检索，而是可以直接把预取操作（Prefetch）与模型的计算（Model Computation）重叠起来。
想象一下，当前解码步骤在GPU上进行矩阵乘法等计算时（这通常需要几毫秒），系统可以充分利用这段时间，通过PCIe通道将CPU内存中预测出来的KV数据传送到GPU显存。这样一来，当计算结束，真正需要执行注意力（Attention）操作时，KV数据已经“到了”！之前那种眼巴巴等着CPU传数据的卡顿感就消失了。
这个“预测-预取”的范式改变，直接就可以把GPU显存里那些占地几十GB的辅助状态给清退出去，还显寸于民（给更大的批量大小用），从而从根本上提升系统的吞吐量。
当然，光有洞察还不够，把这个想法落地成一个高效的推理系统，还需要解决三个“拦路虎”：
1. 如何不花大代价生成那个“推测Token”？如果为了预测而让每次解码的计算量翻倍，那就得不偿失了。
2. 预取时机如何把控？预取早了，数据待在显存里占用空间；预取晚了，重叠失效，解码还是会卡住。
3. 预取的KV怎么存？如果预取数据的管理很粗糙，又会制造出新的内存压力。
接下来，我们就来看看DualDecoder是如何见招拆招的。
双Token解码流水线设计 让模型在一次前向传播中，同时生成真正的输出Token和推测Token 。
具体的做法是：在解码步骤Si中，DualDecoder会把当前真实的输入Token Ti和之前预测出的推测Token Ti+1'拼接在一起，作为两个不同的输入序列，喂给模型的同一层。
但是，直接拼接会出问题！因为Ti+1'是在Ti之后生成的，它必须能看到Ti的信息，否则就没有“预测”的意义了；而Ti作为一个“前辈”，又不能看到未来的Ti+1'，否则就破坏了因果关系。DualDecoder的处理方式是：把这两个token在序列维度上拼接，然后通过一个临时掩码（Temp Mask）来控制注意力。这个掩码会让Ti看不到Ti+1'，但Ti+1'却能看到包括Ti在内的所有之前的令牌。这样，在最终输出时，Ti的最终层输出正常，而Ti+1'的输出则变成了一个可以进行KV预测的“候选者”。
整个过程不需要启动两次模型推理，只需要一次，额外增加的显存带宽消耗微乎其微，GPU利用率很高。这简直是大模型时代的“时间管理大师”，同一个时钟周期里完成了两项任务。
万事开头难。第一个推测Token从哪来？如果用一个随机token初始化，后续的预测会像多米诺骨牌一样崩掉。DualDecoder的方法很朴实：在正式进入双token流水线之前，先做一次轻量级的预解码（Pre-Deconding），基于第一个真实的输入token生成第二个真实的输出token。然后，就用这个真实的T2作为第一个推测Token Ti+1'。
图7(b)：首推测Token选择的影响。使用真实输出Token（金线）作为初始推测Token，KV预测准确率能稳定在80%以上，而使用随机Token（红线）则准确率会大幅下滑。
如图7(b)所示，这个“正确”的起步至关重要。使用真实的T2作为初始推测Token，KV预测准确率稳定在80%以上；如果用一个随机的token开局，准确率会立刻崩溃到60%以下。这好比赛车比赛中的起步，DualDecoder用一个完美的弹射，确保了整个预测过程的稳定性。
层感知传输调度与优先级恢复
大模型的计算是按层（Layer）进行的。DualDecoder利用了一个常见的推理特性：当GPU在计算当前层（比如第l层）时，第l+1层的数据还没被用到。因此，DualDecoder会启动两个异步的CUDA流：
- 预取流（Prefetch Stream） 主计算流（Computation Stream）
虽然KV预测有88%的准确率，但总会有猜错的时候。对于那12%的“漏网之鱼”，DualDecoder的处理方式也很巧妙。它会在主计算流上设置一个“紧急流”（Urgent Stream）。
当发现预取的数据中缺少了某个关键的KV chunk时，系统会立刻通过紧急流高优先级地补传缺失的部分。因为缺失的数据量通常很少（被预测中的数据覆盖了大部分），所以补传的延迟极小，几乎不会导致解码卡顿。这就像一个交通系统，虽然有部分车辆走错了路，但实时导航立刻会为他们开出绿色的“优先通道”。
为了管理预取的数据，DualDecoder还设计了一个层作用域的KV内存管理器（Layer-Scoped KV Memory Manager），核心就是一个两层的“乒乓缓冲区”（Ping-Pong Buffer）。当Buffer A被当前注意力计算读取时，Buffer B正在接收预取流写入的新数据。这两块缓冲区的角色随着GPU计算层的推进而不断交换，从而将预取缓存的空间开销降到最低。
实验结果：吞吐量提升2.62倍
所有花里胡哨的设计，最终都要在benchmark上见真章。DualDecoder在多种模型配置和负载下进行了测试，结果相当亮眼。
表1：系统吞吐量对比（tokens/s）。DualDecoder在所有模型大小和批次大小下都取得了最高吞吐量，相比SOTA系统，最高提升了2.62倍。
从表1可以看到，在面对8B规模的模型、128K上下文时，DualDecoder（DualDec下）的吞吐量达到了187 tokens/s，而最先进的稀疏KV系统ShadowKV只有70 tokens/s，提升幅度达到了2.62倍！即使是面对更重的32B模型负载，DualDecoder也稳定地保持着约2倍的性能优势。这个结果非常硬核，说明DualDecoder确实把从辅助状态那里“抠”出来的显存，无缝转化成了实实在在的计算吞吐量。
为了证明每个模块的不可或缺，作者还做了漂亮的消融实验。实验表明，如果去掉双token解码（变成随机推测），KV预测精度和最终吞吐量都会大幅下滑；如果去掉层感知调度，预取与计算的延迟无法重叠，吞吐量也会受影响。
表4：RULER Benchmark上的模型质量对比。DualDecoder在多个长上下文任务上的分数与全量KV Cache（VLLM）持平甚至更高，说明其稀疏方法没有损失模型精度。
更重要的是，DualDecoder并没有像某些激进的方法那样为了速度牺牲质量。表4显示，在流行的长上下文Benchmark（如RULER）上，DualDecoder的精度不仅没有下降，反而在某些任务上略高于全量KV Cache的VLLM。这证明了其稀疏策略的精妙——它准确找到了那些真正重要的token，而摒弃了噪音。
总结与展望
DualDecoder凭借着“KV检索可预测”这个核心洞察，用一套极简而精巧的设计，巧妙地解决了大模型长上下文推理中一个深层的显存利用问题。它没有引入复杂的模型改动，而是通过对推理调度系统的优化，将“辅助状态”这种显存的“坏账”彻底清出，实现了吞吐量的飞跃。
当然，DualDecoder也并非没有局限。它的预测机制高度依赖于“推测Token”能准确捕捉上下文的注意力模式。在面对一些特殊场景（比如推理代码中的复杂模式识别）时，预测准确率是否会下降，目前还缺少更详尽的鲁棒性测试。另外，论文中假设了K Landmark是静态的，未来如果能设计出能自适应更新的Lankmark，有望进一步提升预测的泛化能力。
DualDecoder给我们的启发是，在解决算力瓶颈时，不要只盯着模型本身（加算子、改结构），很多工程系统层面的“内耗”一旦被清除，带来的效益可能比增加硬件还要可观。这不只是AI，这是系统工程智慧的胜利。
图8：DualDecoder系统概览图。展示了核心的双Token解码流水线（Dual-Token Pipe）、推测KV传输调度（Speculative KV Transfer）、以及层作用域的KV内存管理（Layer Buffer）三个核心模块的协同工作流程。
龙迷三问 这篇论文解决什么问题？
"推测Token"是怎么产生的？会不会很慢？
KV预测准确性达不到100%，那12%的缺失数据怎么办？
如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~
龙哥点评 论文创新性分数： ★★★★✰
从系统与算法融合的角度来看，创新性很强。它不是简单调参，而是发现了KV检索的可预测性这个根本规律，并用简洁优雅的方法（双Token解码）加以利用。不过，在模型层面并没有提出新的注意力机制，因此称不上“颠覆性”。实验合理度： ★★★★★
实验设计非常扎实，对比基线包括了VLLM和ShadowKV等当前最先进的系统，涵盖了小到8B大到32B的模型，以及128K到1M的上下文长度。消融实验和模型质量验证一应俱全，结论有说服力。学术研究价值： ★★★★✰
论文提出的“Predictive Retrieval”范式为后续研究提供了很好的启发。它打破了“要快就必须在显存里放更多辅助状态”的固有思维，可能会衍生出更多关于动态Prefetching策略的研究。稳定性： ★★★★✰
该系统基于成熟的工程架构构建，乒乓缓冲区和紧急流机制都考虑了边界情况。唯一的不确定性在于面对极其生僻或Out of Distribution的上下文时，预测准确率是否保持稳定。目前看88%的平均准确率很稳健。适应性以及泛化能力： ★★★★✰
论文在Llama和Qwen系列模型上都做了测试，表现稳定。但它假设了系统具备PCIe 5.0的高带宽，对于更老的硬件（如PCIe 4.0或NVLink互通）场景，延迟重叠效果可能需要重新评估。硬件需求及成本： ★★★★✰
该系统在推理阶段通过卸载辅助状态，可以显著降低单次推理的显存需求，让用户能用更少的GPU处理更大的Batch Size，性价比极高。不过，它需要CPU与GPU之间具备异步数据传输能力，这是现代服务器的基本配置。复现难度： ★★✰✰✰
作为一篇系统论文，复现的门槛相对较高，需要深入了解CUDA流、内存管理和现有的推理框架（如VLLM），代码目前未见开源，可能难以严格复现。产品化成熟度： ★★★★✰
实验数据表明其性能和稳定性都很好，概念经过了充分验证。距离直接作为商品化部署模型，主要还差一个开箱即用的代码库和更详尽的运维最佳实践文档。方向非常好，有潜质。可能的问题： 论文中的“紧急流”对于预测失败的处理只用了补传，在极端高并发下，多次补传是否会加剧PCIe带宽竞争，导致整体性能雪崩？这一点在论文中讨论不够充分。此外，论文并未讨论模型微调或持续学习场景下的适应性。
主要参考文献
[1] Zuning Liang et al., “DualDecoder: Accelerate Long Context LLM Inference by Predictive Prefetch”, arXiv:2607.26475, July 2026. [2] ShadowKV: KV Cache in Shadows for High-Throughput Long-Context LLM Inference. [3] SpeCache: Sparse KV Cache with Memory-asymmetry and Predictive Prefetching. *本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～ 想了解更多原文细节的小伙伴，可以点击 "阅读原文"， 查看更多原论文细节哦！
长上下文推理优化是当前AI部署的热点！DualDecoder的预测性预取思路为LLM服务提供了新范式。想了解更多系统级优化技巧？加入龙哥读论文粉丝群，与同行交流LLM推理、KV缓存管理、稀疏注意力等前沿技术。
扫描下方二维码或者添加龙哥助手微信号加群 ：kangjinlonghelper。
一定要备注：研究方向+地点+学校/公司+昵称（如 LLM推理+上海+复旦+龙哥） ，根据格式备注，可更快被通过且邀请进群。
