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 仍然建立在两项已有技术之上：

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

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)，其在所有配对上的总流量为：