DeepSeek新论文来了！联手清华、北大，优化智能体大模型推理！

「DeepSeek V4 来了！」这样的消息是不是已经听烦了？

我们也是。

不过 DeepSeek V4 虽然迟迟未发，但今天我们等来了其与清华、北大合作撰写的一篇新论文。

总结来说，这篇新论文介绍了一个名为「DualPath」的创新推理系统，专门针对智能体工作负载下的大语言模型（LLM）推理性能进行优化。具体来讲，通过引入「双路径 KV-Cache 加载」机制，解决了在预填充 - 解码（PD）分离架构下，KV-Cache 读取负载不平衡的问题。

该推理系统带来了显著效果：在离线推理场景中实现了 1.87 倍的吞吐量提升，在线服务场景下实现了 1.96 倍的服务吞吐量提升。

• 论文标题：DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference

• arXiv 地址：https://arxiv.org/pdf/2602.21548

我们知道，如今智能体已经成为主流 AI 开发范式。但是，智能体范式下出现了全新的瓶颈，即存储带宽。

在多轮互动的智能体场景中，上下文信息会随轮次迅速累积，导致其呈现出 「长上下文、短追加」 的特征。研究指出，这类负载的 KV-Cache 命中率通常高于 95%。这意味着系统性能的决定性因素已不再是纯粹的计算能力，而是从存储中加载 KV-Cache 的效率。

在现有的预填充 - 解码分离（PD-disaggregated）架构中，所有的存储 I/O 压力都集中在预填充引擎（PE）的存储网卡上，而解码引擎（DE）的存储带宽则被闲置。这种带宽利用的极度不平衡，成为了限制系统吞吐量的核心障碍。

针对这一痛点，DualPath 重新设计了数据加载路径，核心创新在于引入了存储到解码（Storage-to-Decode）路径，包括以下两个特征：

一方面是双路并行。KV-Cache 不仅可以直接读入预填充引擎，还可以先加载到解码引擎，随后通过高带宽 RDMA 计算网络高效传输至预填充引擎。

另一方面是带宽资源池化：通过动态分配两条路径的负载，DualPath 成功将集群中所有引擎的存储网卡聚合为一个 全局容量池，彻底打破了单节点 I/O 的限制。

另外，为了确保大规模数据传输不干扰延迟极其敏感型的模型推理任务，DualPath 还采用了以下两项关键技术：

一是以计算网卡（CNIC）为中心的流量管理：系统将所有 GPU 相关的流量（包括本地内存拷贝）统一通过计算网卡进行管理，同时利用网络的服务质量（QoS）机制，将推理通信设为高优先级，确保加载 KV-Cache 的流量仅利用闲置带宽，不影响延迟 SLO。

二是自适应请求调度：调度器实时监控各引擎的磁盘读取队列长度和计算负载，动态决定每个请求的最优路径。同时，通过计算配额机制优化引擎内调度，最大限度减少 GPU 执行过程中的气泡。

研究团队在包含 1152 个 GPU 的大规模生产集群上对 DualPath 进行了评估，并验证了离线与在线服务场景下吞吐量的显著提升。

接下来解析 DualPath 系统细节。

DualPath 系统概览

为了打破 Prefill 侧存储 I/O 的瓶颈，DeepSeek 提出了一种双路径加载架构，重新设计了在 Prefill–Decode 解耦（PD-disaggregated）推理架构中 KV-Cache 的读取方式。传统做法是所有 KV-Cache 都从存储直接读入 Prefill 侧 GPU，导致 Prefill 侧存储网卡成为单点瓶颈。DualPath 则在此基础上增加了一条新的加载路径，从而缓解这一不平衡问题。

DualPath 仍然建立在两项已有技术之上：

（1）P/D 解耦（PD Disaggregation），将 prompt 处理与 decode 处理分离，以提高整体效率；

（2）Layerwise Prefill，通过按层加载 KV-Cache，避免了 LayerKV 和 PrefillOnly 指出的 Prefill 引擎上的 HBM 显存瓶颈问题，从而提升 GPU 利用率。

DualPath 整个系统由三部分组成：

• 推理引擎（Inference Engines）。每个引擎管理一张 GPU。引擎分为两类：用于执行 prefill 的 Prefill Engine（PE），以及用于执行 decode 的 Decode Engine（DE）。

• 流量管理器（Traffic Manager）。每个引擎内部都包含一个流量管理器，负责：（1）主机与设备之间的内存拷贝（H2D 与 D2H）；（2）PE 与 DE 之间的 KV-Cache 传输；（3）通过存储网卡进行 KV-Cache 的读写操作。DeepSeek 采用以 CNIC 为中心的流量管理方案，以防止 KV-Cache 相关流量干扰模型推理过程中的通信。

• 请求调度器（Request Scheduler）。一个中心化调度器，负责接收客户端请求并将其分配到不同引擎。同时，它还负责在两条加载路径之间动态分配数据流量（如图 4 所示）。

双路径加载（Dual-Path Loading）

传统系统中，KV-Cache 只能从存储直接读入 Prefill 引擎，因此所有存储带宽压力都集中在 Prefill 侧，形成单点瓶颈。DualPath 在此基础上增加了一条新的加载路径：KV-Cache 可以先从存储读入 Decode 引擎，再通过高速 RDMA 计算网络传回 Prefill 引擎。这样，系统就可以同时利用 Prefill 和 Decode 两侧的存储网卡带宽，而不是只依赖 Prefill 一侧，从而消除带宽不均衡问题。

为了实现双路径加载，DualPath 在每个 Prefill Engine（PE）和 Decode Engine（DE）上分配少量 DRAM 作为缓冲区，分别称为 PE buffer 和 DE buffer。

Prefill 侧读取路径。首先，将命中 token 的 KV-Cache 从持久化存储中读取到 PE buffer（如图 4a 中标注 1 和 2）。在某一注意力层开始计算之前，该层对应的 KV-Cache 会从 PE buffer 传输到 PE 的 HBM（3 和 4），用于计算未命中（cache-miss）的 prompt token 的 KV-Cache。随后，命中和未命中 token 的所有 KV-Cache 都会被传输到 DE buffer，以组成完整的 prompt KV-Cache（ 5–7）。步骤 3–7 的流程会重复 n_layer 次。在 prefill 前向计算过程中，数据传输与计算是重叠执行的。

预填充 DE 读取路径。首先，命中 token 的 KV-Caches 会被读取到 DE 缓冲区中（如图 4b 中的标签 1 和 2 ）。在 PE 预填充期间，相应层的 KV-Cache 会从 DE 缓冲区中读取，这同样与计算过程相重叠（ 3-5）。此过程会重复 n_layer 次。当每一层的计算完成后，只有缺失 token 的 KV-Caches 会被传输到 DE 缓冲区，并与现有的命中 token KV-Cache 进行合并。

解码阶段。在 DE 缓冲区接收到完整的提示 KV-Cache（包括通过 PE 读取路径加载的 KV-Cache 以及新追加 token 的 KV-Cache）后，解码阶段正式开始。DE 首先分配 HBM 并执行主机到设备（H2D）传输（如图 4a 中的标签 8 和 9；图 4b 中的标签 6 和 7 ），随后在开始解码前释放 CPU 内存。

DE 缓冲区的设计虽然给 DRAM 和 CNIC 带来了额外的带宽压力（因为增加了一次额外的 H2D 拷贝），这本可以通过 GPU Direct RDMA 直接绕过来避免。然而，由于在此类智能体场景下生成的长度通常较短，首 token 延迟在整个端到端请求时间中占据了不可忽视的比例。引入 DE 缓冲区有助于减少 GPU 内存占用。在解码过程中，每当累积一个完整的 token 块（例如 64 个 token）时，系统会立即将其持久化到磁盘中。

不同的数据块布局。DualPath 采用了两种不同的数据块布局：完整块和层级块，它们分别包含所有层的信息和单个层的信息。对于所有与存储系统的交互，均采用完整块。在 PE 读取的情况下，KV-Cache 加载到 PE HBM 以及传输到 DE 缓冲区的过程是以层级流式方式进行的，两者都使用层级块。同样地，对于 DE 读取路径，从 DE 缓冲区到 PE HBM 的传输也使用层级块。

无瓶颈（Bottleneck-Free）分析

比例（预填充 / 解码比例）下证明了，该系统可以完全打满所有存储网卡（NIC）的带宽，且不会引入计算网卡或 DRAM 的瓶颈。

假设 PCIe 拓扑配置良好（即每一对 GPU - NIC 都位于同一个 PCIe 交换机下）、任务调度负载均衡、计算网络无拥塞，且存储读取带宽得到了充分利用。

首先是 PE CNIC 带宽分析。对于 PE CNIC，由于存在回环流量（即不经过交换机的 H2D 和 D2H 拷贝），因此无论读或写操作，PCIe 侧的总流量始终大于或等于交换机方向的流量。因此，只需要计算 PCIe 侧的压力。读取操作包括 PE 路径 (3) 和 (5)，其在所有配对上的总流量为：

其次是 DRAM 压力分析。DRAM 是半双工的，因此将读取和写入压力相加。对于 PE 内存，其压力为 2sB，这通常不会超过内存带宽。对于 DE 内存，遵循上述类似的分析，可以得出其压力为 (3 + 2P / D) Bs。要求 DE 内存压力小于或等于 M，得到如下：

更多公式请参考原论文。

实际挑战

双路径架构从根本上重新定向了数据移动方式：KV-Cache 既可以直接从存储加载到预填充引擎，也可以通过解码引擎间接加载 。通过这种方式，系统聚合了所有引擎的存储带宽，从而打破了预填充侧的 I/O 瓶颈 。然而，在实际系统中实现这一高层设计引入了三个相互关联的挑战 。

一是细粒度数据传输。层级执行范式虽然对于克服 HBM 容量限制至关重要，但它会将 KV-Cache 碎片化为海量的细粒度数据块。为了实现吞吐量增益，在存储、主机 DRAM 和 GPU HBM 之间传输这些海量的细粒度数据块时，必须确保产生极低的开销，并与计算任务无缝重叠。

二是流量隔离。DualPath 中复杂的数据路径在计算网络和 PCIe 链路上都引入了额外的 KV-Cache 传输流量。一个主要的顾虑是，这些流量可能会干扰模型执行中至关重要的、对延迟敏感的现有集合通信操作 —— 例如专家并行中的 AllToAll，以及张量 / 上下文并行中的 ReduceScatter 和 AllGather。由于这些集合通信直接决定了端到端的推理延迟，因此在不降低模型推理性能的前提下利用空闲 I/O 带宽是一个关键挑战。

三是动态负载均衡。由于采用了两种不同的 KV-Cache 加载路径，系统必须及时决定每个请求使用哪条路径。过于简单的策略可能会导致某条路径过载，从而重新产生原始瓶颈。流量调度器必须实时平衡多个因素：存储网卡队列长度、GPU 上的计算负载以及请求的工作负载特性。

评估结果

在评估部分，论文核心任务只有一个：证明 DualPath 在真实 agent 工作负载下，确实能解决存储带宽瓶颈，并带来稳定、可扩展的性能提升。

论文在自研推理框架上实现 DualPath，核心改动约 5000 行代码。底层使用 FlashMLA、DeepGEMM、DeepEP 等高性能算子，存储后端采用 3FS 分布式存储。

评测模型包括：DS 660B（MoE + 稀疏注意力）、DS 27B（缩小版实验模型），Qwen 32B（稠密模型）。

离线批量推理

这一部分模拟 RL rollout 场景：n 个 agent 同时启动，测整体完成时间（JCT）。

不同 Agent 批量规模与最大 Agent 长度（MAL）的影响。 随着批量规模增大以及 MAL 变长，DualPath 的优势更加明显。图 7 展示了在不同 batch size 与 MAL 组合下的 JCT 表现。SGL (MC) 出现错误，未能完成部分大规模配置（图中 token 为 N/A）。在 DS 660B 模型上，DualPath 相比 Basic 最高实现了 1.87× 的加速，并展现出接近 Oracle 的性能，这表明 KV-cache 的 I/O 开销基本被消除。在 DS 27B 上，DualPath 相比 Basic 最高提升 1.78×，但由于 1P1D 架构下存储带宽受限，其性能仍比 Oracle 慢 1.09–1.85×（见图 8）。对于 Qwen 32B，趋势与 DS 27B 类似。

不同追加长度（Append Length）与生成长度（Generation Length）的影响。如图 9 所示，随着追加长度增加，Basic 的性能逐渐接近 DualPath 和 Oracle，而 DualPath 与 Oracle 的性能变化较小，这表明系统瓶颈始终主要来自 GPU 计算压力。与 Basic 相比，DualPath 在不同追加规模下实现了 1.82–1.99× 的加速。生成长度扩展时的趋势类似。

Online Serving（在线推理服务）

在线服务实验部分则模拟真实生产环境下 agent 按泊松分布持续到达的场景，设置 TTFT ≤ 4 秒、TPOT ≤ 50 毫秒为服务等级目标。结果表明，DualPath 显著提高系统可承载的到达率上限：在 DS 27B 上提升 1.67 倍，在 DS 660B 上提升 2.25 倍。

与此同时，DualPath 的 TTST 与 Basic 基本持平，TPOT 也未引入额外解码开销，说明其优化集中在 KV-Cache 读取与排队阶段，而不会影响解码阶段效率。更重要的是，在负载升高时，DualPath 能保持 TTFT 结构稳定，而 Basic 的排队时间会因存储带宽不足迅速上升，成为延迟恶化的主要来源。

最后，论文还做了大量消融实验，感兴趣的读者，可以参考原论文，查看更多内容。

转载自：机器之心。