DeepSeek新论文“双通道”，让AI服务器的闲置带宽重新活过来了

今年春节期间，国内AI大厂轮流发布新模型。意外的是，去年春节的主角DeepSeek缺席了。不过前几天，DeepSeek联合北大清华发表一篇关于AI推理的新论文，或许DeepSeek的新模型发布也近在咫尺了。

这篇论文解决的是什么问题呢？假如你开了一家爆火的餐厅，菜品只现炒，不预制。厨房里有两条生产线：一条负责备菜（相当于AI里的"预填充"阶段），另一条负责出餐（相当于AI里的"解码"阶段）。问题来了，备菜那条线的传菜通道彻底堵死了，菜根本送不进来，厨师只好干等着。而出餐那条线的传菜通道却闲得发慌，几乎没有什么东西经过。整个餐厅的产能被这个奇怪的不平衡给拖垮了。

这，就是当今最先进的AI推理系统正在面对的真实困境。而这篇论文提出的系统，叫做DualPath，干的事情说白了就是：把那条闲置的传菜通道也利用起来，让整个餐厅重新转起来。

AI变"话痨"之后，麻烦来了

要理解DualPath解决的问题，得先搞清楚AI这几年发生了什么变化。

过去我们和AI聊天，通常是一问一答，问完就完了，就像发短信一样。但现在的AI越来越像一个能自主干活的"员工"，它会自己上网查资料、执行代码、调用工具、根据执行结果再做下一步决策，来回折腾几十甚至上百个回合，这就是所谓的"智能体（Agentic）"模式。

一个典型的智能体任务是这样运转的：AI收到一个任务，比如"帮我修复这段代码里的bug"。它先看一眼代码，然后在命令行里执行了一条命令，看到报错信息后又修改了一处，再执行，再看结果……如此循环。每一轮，AI都需要把之前所有的对话历史都"记在心里"，才能接着干下去。随着轮数增加，这段历史越来越长，轻轻松松就能达到三四万个词，有时候甚至超过一百万个词。

研究团队从他们自己的生产任务里收集了真实数据，发现平均每次任务要经历157轮对话，平均的上下文长度达到了32,700个词，而每一轮新增的内容只有区区429个词。这意味着，每一轮AI在开始思考之前，需要从头重新"读"的内容里，有98.7%都是上一轮已经读过的东西。

这里就出现了一个聪明的优化手段：把已经读过的内容存起来（这叫KV缓存，Key-Value Cache，你可以把它理解为AI的"工作记忆草稿"），下次直接从仓库里取出来用，不用重新计算。这样做可以节省大量的计算资源。现实中，智能体任务的KV缓存命中率通常在95%以上，也就是说，每次AI开工，超过95%的"草稿"都是直接从仓库里拿来的现成货。

听起来很好，对吧？但问题恰恰出在"从仓库里拿"这件事上。

堵车，就堵在备菜通道上

现代大型AI推理系统通常采用"分离式架构"，就是把两个阶段的工作分给两种不同的服务器来做：专门负责"读取上下文、准备好记忆草稿"的叫预填充引擎（Prefill Engine，简称PE），专门负责"一个词一个词往外生成答案"的叫解码引擎（Decode Engine，简称DE）。这两种引擎各司其职，通过高速网络互相传递数据。

两种服务器各自都有两种网卡：一种连接外部存储系统（用来读取那些存好的KV缓存草稿），叫存储网卡（SNIC）；另一种连接同类型服务器之间的高速计算网络（用来在服务器之间传递中间结果），叫计算网卡（CNIC）。

现在问题来了。按照传统的工作方式，每次AI开始处理一个请求，读取KV缓存这件事完全由预填充引擎来做，它需要把几万词的"历史草稿"从外部存储里全部搬过来，然后才能开始干活。这意味着预填充引擎的存储网卡一直在满负荷运转，就像一条永远堵死的高速公路入口。

而另一边，解码引擎的存储网卡却几乎没什么事干，大部分时间都在摸鱼。

研究团队测量了实际情况，发现在典型的智能体推理场景下，预填充引擎的GPU利用率只有40%，存储网卡却满载运行；解码引擎的GPU利用率达到了80%，存储网卡却几乎空转。整套系统被预填充侧的存储带宽牢牢卡住了脖子。

更要命的是，这个问题随着时间推移只会越来越严重。研究团队梳理了NVIDIA从Ampere到Blackwell几代GPU的硬件数据，发现从2020年到2024年，GPU的计算能力提升了28.8倍，内存容量只增长了2.4倍，而网络带宽的提升更是远远落在后面。GPU越来越能算，但搬数据的管道没跟上，这就好比餐厅的厨师变得越来越快，但送菜的电梯还是几十年前的老货。

一个看似简单却颇有门道的想法

DualPath的核心思路，用一句话说就是：既然解码引擎的存储网卡闲着，为什么不让它也来帮忙搬KV缓存呢？

具体来说，DualPath在原有的"存储→预填充引擎"这条路之外，新开了一条路："存储→解码引擎→通过计算网络RDMA传给预填充引擎"。这两条路可以同时使用，系统根据实时情况动态分配任务：哪边通道空，就往哪边派。

你可以把这个过程想象成同一个仓库，现在有两个出口可以往外拿货，一个直接通到备菜区，另一个先通到出餐区，再用内部高速传送带送到备菜区。虽然后者多了一段路，但如果前面那条路已经堵死，走后门反而更快。

这里有一个关键的技术细节值得解释一下。为什么走"存储→解码引擎"这条路，然后再通过计算网络转发给预填充引擎，不会把计算网络堵死呢？

原因在于，计算网络的带宽远比存储网络大得多。在典型的NVIDIA数据中心配置里，每个节点有8张GPU，每张GPU配一个400Gbps的计算网卡，加起来是8×400Gbps=3200Gbps；而存储网卡一般只有一个，400Gbps。计算网络的总容量是存储网络的8倍。而且，计算网络的流量本身具有"爆发性"特点，AI在做矩阵运算的时候，大家需要互相通信，但这种通信是以毫秒以下的短暂脉冲形式出现的，脉冲与脉冲之间存在大量空闲时间。利用这些空闲时间来传输KV缓存，就像利用高速公路的低峰期来运货，完全不影响正常交通。

研究团队还做了严格的数学推导，证明了在绝大多数实际的预填充/解码比例配置下（论文给出的范围是1/7到7/2），DualPath可以同时让所有存储网卡都跑满，而不会在计算网卡或内存带宽上造成新的瓶颈。这不是凭感觉说"应该够用"，而是用不等式推出来的有理论保证的结论。

把想法变成现实的三道关卡

把这个思路真正做成一个能用的系统，面临三个具体的工程难题，DualPath各有针对性的解法。

第一道关卡是如何在保证效率的前提下搬运大量细碎的数据块。AI在做推理时，会采用一种叫"按层预填充"的技术，把整个模型分成一层一层来处理，好处是每次只需要把当前层的KV缓存放进GPU内存，避免内存不够用。但这样一来，原本一整块的KV缓存被切成了很多小块，搬运这些小块产生了大量的细碎I/O操作。DualPath设计了两种数据块格式：一种叫"完整块"，装的是一个请求所有层的KV缓存，方便存储；另一种叫"层块"，只装一层的KV缓存，方便在GPU计算时随取随用。通过在合适的时候使用合适的格式，避免了频繁的格式转换，同时让数据搬运和GPU计算能够尽量重叠进行。

第二道关卡是流量隔离。这是一个非常务实的工程问题：在计算网络上传输KV缓存数据，如果和AI模型计算时必须的通信（比如多卡之间的专家并行通信）混在一起，后者是对延迟极度敏感的，一旦被"插队"或者挤占带宽，整个AI计算的速度就会受影响。DualPath的解决方案是把所有GPU进出的数据流量，包括本地的内存复制操作，统一经过计算网卡来走，然后用InfiniBand网络的"虚拟通道"（Virtual Lane）机制给不同类型的流量打上优先级标签。模型计算通信走高优先级通道，得到约99%的带宽保障；KV缓存传输走低优先级通道，利用剩余的带宽，但保证不会饿死。这就像高速公路上的ETC快速通道和普通通道，各走各的，互不干扰。

顺带一提，这种方案还带来了一个意外的好处：原本用CUDA API做内存复制，每次调用有大约5到7微秒的固定开销；换成通过网卡的RDMA方式来做同样的事情，只需要约1微秒，而且可以批量提交，进一步摊薄开销。

第三道关卡是智能调度。DualPath有两条路可以选，究竟怎么分配任务才能让两边都不闲置、也不过载？这不是一个简单的轮询问题，因为每个请求的大小不同，每台服务器当前的负载也不同，存储队列的排队长度也在动态变化。

DualPath的调度器把这些因素都纳入考虑。对于预填充引擎，调度器把每台机器分成三类：第一类是"过载"，暂时不分新任务；第二类是"存储队列短且负载轻"，优先分配，因为不给它任务它的存储网卡就要闲着了；第三类是"存储队列有点长但计算没过载"，作为备选。对于解码引擎，调度器在全局层面先按照各组的总token数来平衡，然后在组内层面根据剩余HBM显存来决定能承载多少请求。最后，选定了预填充/解码引擎对之后，再比较两边的存储队列谁更短，决定这次读取走哪条路。

此外，DualPath还解决了一个多卡之间的负载均衡问题：在某些AI模型的并行计算方式下，不同GPU处理不同的请求，但完成一层的计算后必须互相等待才能进入下一层。如果某张GPU的任务明显比其他GPU重，大家就要一起等它，产生"气泡"浪费。DualPath通过预先估算每个请求的注意力层计算时间，把任务分配控制得更均匀，实测可以把各GPU之间的最大/平均时间比值控制在1.06左右，大大减少了等待气泡。

实验室里跑出来的数字

口说无凭，研究团队在真实的GPU集群上做了详细的测试。测试环境是每台服务器配8张NVIDIA Hopper GPU、8个400Gbps计算网卡、1个400Gbps存储网卡，存储后端是DeepSeek开源的3FS分布式文件系统，无内部DRAM缓存，能完全跑满存储网卡的带宽。

测试使用的模型包括三个：DeepSeek V3.2（660亿参数的大模型）、一个27亿参数的内部实验模型，以及Qwen2.5-32B（320亿参数的开源模型）。任务数据集来自真实的智能体RL训练任务，包含500条轨迹，上下文长度分布在32K到64K词之间，真实反映了生产环境的特征。

在离线批量推理场景下（模拟RL训练的rollout阶段，同时启动大量智能体），DualPath对比未改动的基础系统，在DeepSeek V3.2上最高实现了1.87倍的吞吐量提升，在27B小模型上最高1.78倍。而DualPath的性能与"理想上限"（假设所有存储I/O时间为零的理论最快速度）已经非常接近，说明存储I/O瓶颈基本被消除了。

研究团队还测试了改变预填充/解码节点比例对结果的影响，发现一个有趣的规律：使用DualPath的1P1D配置（1个预填充节点配1个解码节点）和不使用DualPath的2P1D配置（2个预填充节点配1个解码节点），性能表现相当。换句话说，DualPath让你用更少的预填充硬件资源达到同样的效果，或者说让原有硬件的价值翻了一番。

在线服务场景下，DualPath在27B模型上能支持的请求到达速率是基础系统的1.67倍，在660B大模型上更达到了2.25倍，同时完全满足首字延迟不超过4秒、每个词生成时间不超过50毫秒的服务质量约束。

研究团队还做了一个消融实验，把DualPath的三个组成部分，按层预填充、双路加载、以及调度算法，逐步叠加，看看各自的贡献。按层预填充单独贡献了17.21%的提升，双路加载在此基础上又贡献了38.19%，调度算法再加上去又多贡献了部分，三者合计比基础系统提升了45.62%。

最后，研究团队还测试了大规模场景，把系统扩展到了最多1152张GPU（48个预填充节点、96个解码节点）。从小规模的2P4D扩展到48P96D，任务完成时间从3167秒变为3201秒，几乎实现了线性扩展，而整个调度器的CPU占用始终不超过10个核，说明调度本身不是瓶颈。

还有什么值得关注的细节

DualPath是一篇来自工程实践的论文，里面有不少细节值得关注。

首先，关于为什么不用DRAM来缓存KV缓存。确实，已经有系统（比如Mooncake）用分布式内存来存KV缓存，命中率高、延迟低。但问题是，在RL训练的rollout阶段，GPU上的数据会被卸载到主机内存里，内存已经被占用了；而且对于在线服务这样有巨大工作集的场景，内存的成本比SSD高很多。DualPath直接面向SSD后端，不依赖DRAM缓存，在内存受限的场景下更有实用价值。DualPath和DRAM缓存可以叠加使用，但研究团队发现叠加后的额外收益有限。

其次，DualPath目前有一个已知的待改进点：对于同一个请求，调度器只能选择"完全走预填充侧读"或者"完全走解码侧读"，还没有实现把一个请求拆成两半、同时从两侧并行读取。研究团队提到这是未来工作的方向之一。

另外，研究团队还观察到一个有趣的现象：在RL训练任务中，整个任务的前半段预填充压力远大于后半段。这是因为前半段大量请求同时处于上下文较短的早期轮次，后半段很多请求已经到了上下文很长、每轮append较短的阶段。这种动态变化意味着未来需要更自适应的预填充/解码节点比例调整机制，而不是在任务开始前固定好配置。

归根结底，DualPath做的事情其实很朴实：它没有发明新的硬件，没有改变AI模型的结构，只是重新安排了一下数据搬运的路线，把原本闲置的带宽资源利用了起来。但就是这么一个看似简单的重新安排，让同样的硬件能跑出将近两倍的吞吐量。

在AI算力成本居高不下、算力资源极度稀缺的当下，这种"不花一分钱硬件，靠软件调度把性能翻倍"的思路，比任何炫技的新硬件方案都要务实，也都要有吸引力。毕竟，最好的优化往往不是"造更宽的管道"，而是"把现有的管道都用满"。

END本文来自至顶AI实验室，一个专注于探索生成式AI前沿技术及其应用的实验室。致力于推动生成式AI在各个领域的创新与突破，挖掘其潜在的应用场景，为企业和个人提供切实可行的解决方案。

Q&A

Q1：DualPath是什么，和普通的AI推理系统有什么区别？

A：DualPath是由北京大学、清华大学和DeepSeek-AI联合研发的AI推理系统，它的核心创新是把原本只有预填充引擎才能用的存储带宽，扩展到让解码引擎也能参与KV缓存的读取工作，相当于从"单车道"升级成了"双车道"，让两种服务器的网络资源都能被充分利用。

Q2：KV缓存是什么，为什么它这么重要？

A：KV缓存可以理解为AI在进行多轮对话时存下来的"工作记忆草稿"，有了它就不用每次都从头重新计算之前的所有内容。在智能体任务里，每轮对话有超过95%的内容都是之前见过的，所以KV缓存的读取速度直接决定了整个系统的快慢，是最核心的性能瓶颈。

Q3：DualPath会不会让AI的响应速度变慢，因为数据要绕路传？

A：实验结果显示DualPath不会让响应变慢，反而更快。虽然通过解码引擎中转多走了一段路，但因为计算网络的总带宽是存储网络的8倍以上，而且传输发生在GPU计算的空闲间隙，并不抢占关键通信资源，整体来看解决了存储侧的瓶颈，系统吞吐量最高提升了1.87倍。