DualPath

Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference

DeepSeek 与北京大学、清华大学联合提出的 LLM 推理系统,解决了智能体场景下 KV-Cache 存储 I/O 瓶颈这一关键问题。 DualPath 引入了双路径 KV-Cache 加载机制——除传统的"存储→Prefill"路径外, 新增"存储→Decode→Prefill"路径,通过高速 RDMA 计算网络将 KV-Cache 从 Decode 引擎传输到 Prefill 引擎。 其设计哲学不是简单地"加资源",而是"重新分配已有资源", 通过全局带宽池化、精细流量隔离和智能调度,实现了接近理论上限的推理吞吐。

1.87×
离线推理吞吐提升
1.96×
在线服务吞吐提升
98.7%
KV-Cache 命中率
1152
GPU 近线性扩展

🔍 背景:智能体推理的 I/O 瓶颈

从 compute-bound 到 I/O-bound 的范式转变

智能体轨迹示例
Figure 2. 智能体轨迹示例:每轮交互中上下文不断累积,绝大部分 Token 可复用 KV-Cache
从单轮对话到多轮智能体
LLM 正从单轮对话演变为自主式智能体系统,通过多轮交互与外部环境持续互动。 典型的智能体运行包含数十甚至数百轮交互,上下文可增长至百万 Token 级别。

每轮交互中,绝大部分上下文(通常 ≥95%)来自前轮复用,仅有少量新增 Token 需要计算。 这使得推理性能的决定因素从计算转变为 KV-Cache 的 I/O 加载效率
三重因素加剧瓶颈
因素一:智能体工作负载的高 Cache 命中率
指标 数值
平均交互轮数 157
平均上下文长度 32.7K Token
平均新增长度 429 Token
KV-Cache 命中率 98.7%
在 DeepSeek-V3.2 上,Cache-Compute 比值约为 22 GB/PFLOP,对存储带宽构成巨大压力。

因素二:硬件演进趋势不利
从 NVIDIA Ampere 到 Blackwell,I/O-Compute 比下降了 14.4×。 网络带宽和 HBM 容量的增速远落后于 GPU 算力增长。

因素三:存储网络利用率严重失衡
在 PD 分离架构中,KV-Cache 仅由 Prefill 引擎从远程存储加载,所有 I/O 压力集中于 Prefill 侧网卡(SNIC), 而 Decode 侧网卡几乎完全闲置
各模型的 Cache-Compute 比
模型 GB/PFLOP (16K–64K)
Qwen2.5-32B (FP16) 117–267
GPT-OSS-120B 47–95
Qwen3-235B-A22B 39–60
DeepSeek-V3.2 660B 13–36
DeepSeek-V3 660B 4.8–5.8
KV-Cache 越大的模型,I/O 瓶颈越严重。DeepSeek MLA 模型 KV-Cache 已高度优化,但仍面临显著压力。

🚀 核心创新:双路径 KV-Cache 加载

不是增加资源,而是重新分配已有资源

现有瓶颈与 DualPath 对比
Figure 1. 现有瓶颈(左)与 DualPath(右):Prefill 侧 SNIC 饱和 vs. 全局带宽池化
核心设计哲学
DualPath 的核心洞察:KV-Cache 加载不必以 Prefill 为中心。 现有系统总是将 KV-Cache 从存储直接加载到 Prefill 引擎,无法利用 Decode 引擎的远程存储带宽。 DualPath 打破了这一限制,将存储 I/O 从单一瓶颈资源转变为全局可调度的带宽池

类比:就像高速公路——一条车道(Prefill SNIC)严重拥堵,另一条车道(Decode SNIC)空空如也。 DualPath 不是拓宽拥堵车道,而是打通一条绕行路线,让车辆先走空闲车道再通过立交桥(RDMA)合流。
双路径加载示意图
Figure 4. 双路径加载示意图:调度器动态分配两条路径的数据流量
P
PE 读取路径(存储→Prefill)
传统路径的优化版本
数据流:
1. KV-Cache 从持久存储读入 PE Buffer(DRAM)
2. 在每层注意力计算前,将该层 KV-Cache 传入 PE HBM
3. 计算 Cache-miss Token 的 KV-Cache
4. 所有 KV-Cache(命中 + 未命中)传输到 DE Buffer
5. 上述过程重复 n_layer 次,传输与计算重叠执行
D
DE 读取路径(存储→Decode→Prefill)
DualPath 的核心创新路径
数据流:
1. KV-Cache 先读入 DE Buffer(DRAM)
2. 在 PE Prefill 期间,对应层的 KV-Cache 从 DE Buffer 读取,通过高速 RDMA 计算网络传输到 PE
3. 层计算完成后,仅将 miss Token 的 KV-Cache 传回 DE Buffer 与已有命中缓存合并

关键设计:DE Buffer 的引入虽然增加了一次 H2D 拷贝, 但由于智能体场景中生成长度短、TTFT 占端到端时间比例大,减少 GPU 内存使用的收益更为显著。
无瓶颈分析
数学证明覆盖绝大多数实际部署场景
在合理的 P/D 比例下,DualPath 可以完全饱和所有存储网卡而不引入计算网卡或 DRAM 瓶颈。

无瓶颈条件:s/(g-s) ≤ P/D ≤ min{(g-2s)/s, (g-s)/(2s), (M/(Bs)-3)/2} 典型配置 (g=8, s=1, M≈500 GB/s, Bs≈50 GB/s): → 无瓶颈范围:1/7 ≤ P/D ≤ 7/2
其中 P/D 为 Prefill/Decode 节点比,g 为每节点 GPU 数,s 为存储 NIC 与计算 NIC 的带宽比, B 为计算 NIC 带宽,M 为内存带宽。 该范围覆盖绝大多数实际部署场景

🛡️ CNIC 中心化流量管理

看似绕路,实则是唯一能确保不干扰推理通信的方案

为何需要流量隔离?
双路径架构在计算网络和 PCIe 链路上引入了额外的 KV-Cache 传输流量。

关键挑战:这些流量可能干扰模型推理中时延敏感的集合通信操作 (如专家并行的 AllToAll、张量并行的 ReduceScatter/AllGather)。 这些通信以亚毫秒级脉冲式发生,软件流量整形难以介入。

如果不隔离:KV-Cache 传输与推理通信竞争 PCIe 和网络带宽 → 推理性能严重退化。
CNIC 中心化:为何选择"绕路"方案?
方案 优点 缺点
GPUDirect Storage 路径最短:存储→GPU HBM 无法与推理通信隔离
CUDA Copy Engine 从 Host DRAM 直接拷贝 GPU PCIe 无 QoS
CNIC 中心化 利用计算网络原生 QoS 看似绕路

核心原则:所有进出 GPU 的数据流量(包括本地 H2D/D2H 拷贝) 都必须通过 GPU 配对的计算网卡(CNIC),使用 GPUDirect RDMA 数据路径。

流量隔离实现:
• 利用 InfiniBand 的虚拟通道(Virtual Lanes)进行隔离
• 模型推理通信 → 高优先级 VL(~99% 带宽预留
• KV-Cache 传输 → 低优先级 VL(~1% 带宽防饥饿)
• KV-Cache 流量可机会性利用计算网络空闲带宽
CNIC 辅助拷贝的额外优势
当处理大量小数据块时,CNIC 辅助 H2D/D2H 性能优于 CUDA copy engine:

cudaMemcpyAsync
单次拷贝延迟:5-7 μs
CUDA 驱动闭源,无法进一步优化
RDMA Write
单次提交延迟:~1 μs
可通过 doorbell batching 进一步摊薄

⚙️ 自适应请求调度器

同时平衡 NIC 流量与 GPU 利用率的两级调度

引擎间 PE 调度示意图
Figure 5. 引擎间 PE 调度示意图:8 个 GPU 在同一 PE 引擎组中,调度器选择最优目标
1
引擎间调度:PE 调度
带宽利用率第一的优先级反转策略
每个引擎报告三个指标——未完成请求数 seq_e、Token 总量 tok_e、所在节点磁盘读取队列长度 read_q。

类别 条件 调度优先级
过载引擎 tok_e > β 不分配新请求
短磁盘队列引擎 read_q ≤ α 且 tok_e ≤ β 最高优先
长磁盘队列引擎 read_q > α 且 tok_e ≤ β 次高

设计精髓:短磁盘队列的引擎优先(而非低 Token 量引擎)。 磁盘队列短意味着存储 NIC 即将空闲,若不及时补充请求,带宽会白白浪费。
2
引擎间调度:DE 调度(两级)
跨组 + 组内的负载均衡
跨组调度:将全局队列中的请求分配给 tok_e 总量最小的 DE 组。

组内调度:
• 设定高 Token 阈值 Z = 1.05 × 平均值
• 优先选择非高负载 DE(类别 2),在同类中选 seq_e 最小的
• 若所有 DE 都高负载,选 tok_e 最小的以减少 HBM 耗尽和抢占风险

KV-Cache 读取路径选择:选定 PE 和 DE 后,选择读取队列较短的一侧
3
引擎内调度:Compute Quota
最小化 GPU 间等待气泡
引擎内调度示意图
核心问题:数据并行配置下,不同 GPU 服务不同请求集合。 注意力层执行时间不均会导致同步等待气泡。

Compute Quota 方案:
• 每个请求描述为 (cached, bsz) 对,估算注意力层执行时间
• 按 FIFO 顺序添加请求,直到预测执行时间达到上限(300ms
• 若添加某请求会超限,通过二分搜索找到更小的 bsz',执行分块预填充

效果:Max/Avg 比率低至 1.06,GPU 间等待气泡最小化。

📊 评估结果:全面提升

实验设置
硬件:NVIDIA Hopper GPU 集群 · InfiniBand 互连 · 每节点 8 GPU + 8×400Gbps RDMA NIC + 1 存储 NIC · 3FS 分布式存储
模型:DeepSeek V3.2 660B (MoE) · DS 27B (缩小版) · Qwen2.5-32B (Dense + GQA)
数据集:3 个来自生产智能体 RL 训练的轨迹数据集(32K/48K/64K 最大长度,500 轨迹/集)
智能体轨迹数据集统计
最大长度 平均轮数 平均新增 Token 平均生成 Token 平均总 Token 平均上下文
32K 60 608 148 28,639 17,183
48K 106 474 172 42,607 25,120
64K 157 429 176 55,958 32,721
离线推理性能
Figure 7. 不同 Agent 数量和最大上下文长度下的离线推理性能(上:DS 27B,中:DS 660B,下:Qwen 32B)
离线批量推理:核心结果
吞吐提升:
• DS 660B:DualPath 相比 Basic 提升高达 1.87×,性能接近 Oracle(零 I/O 开销理论上限)
• DS 27B:提升高达 1.78×
• Qwen 32B:趋势与 DS 27B 类似

DualPath 在以下场景收益更大:
• 更大的 Agent 批量大小
• 更长的最大上下文长度
• 更短的 Append 和 Generation Token(I/O 占比更高)
P/D 比例影响
Figure 8. Prefill-Decode 比例对离线推理性能的影响(DS 27B)
P/D 比例实验验证了存储带宽是主导瓶颈
在 DS 27B 上测试 1P1D、2P1D、1P2D 三种配置:
• DualPath 在所有配置下平均加速 1.64×(最高 2.46×
• Basic 1P1D ≈ Basic 1P2D(增加 Decode 节点不帮忙,因 Basic 用不到其存储带宽)
• DualPath 1P1D ≈ Basic 2P1D(DualPath 1 个节点 = Basic 2 个节点的存储带宽)

关键结论:每对系统恰好具有等量可用存储带宽,证实存储带宽是智能体场景的主导瓶颈。
在线服务延迟指标
Figure 10. TTFT、TTST、TPOT 随 Agent 到达速率 (APS) 的变化(上:DS 27B,下:DS 660B)
在线服务:延迟与吞吐
SLO 约束:TTFT ≤ 4s,TPOT ≤ 50ms

关键结果:
• DS 27B:DualPath APS 容量为 Basic 的 1.67×
• DS 660B:DualPath APS 容量为 Basic 的 2.25×
• TTST 和 TPOT 无额外开销
• DualPath 保持稳定的 TTFT 组成,而 Basic 的排队时间随 APS 增长急剧上升
消融研究:各技术组件贡献
三项技术的逐步叠加效果(DS 660B, 64K):

技术 平均 JCT 降低 单项贡献
+Layerwise Prefill 17.21% 缓解 PE HBM 瓶颈,隐藏传输开销
+Dual-Path Loading 38.19% 主要性能增益,全局存储带宽利用
+Scheduling Algorithm 45.62% 负载均衡的精细化调度

负载均衡效果:
• 存储 NIC 流量 Max/Avg:1.53(轮询)→ 1.18(DualPath)
• 注意力执行时间 Max/Avg:低至 1.06
大规模可扩展性:1152 GPU 近线性扩展
配置 JCT TTFT TTST TPOT
离线 2P4D (2K agents) 3,167s
离线 48P96D (48K agents) 3,201s
在线 2P4D (0.4 APS) 1.739s 0.228s 0.039s
在线 44P88D (8.8 APS) 1.847s 0.194s 0.036s

从 2P4D 扩展到 48P96D(1152 GPU),JCT 仅从 3167s 增至 3201s(近线性扩展)。 在线服务从 0.4 APS 扩展到 8.8 APS(22×),延迟基本不变。 调度器 CPU 使用量始终低于 10 核。

💡 技术亮点深度解读

1
为何存储带宽成为瓶颈而非计算?
智能体场景的范式颠覆
传统认知:LLM 推理是计算密集型任务,GPU 算力是瓶颈。

智能体场景的颠覆:
• 98.7% 的 Token 命中 KV-Cache → 几乎不需要计算
• 仅 1.3% 的 Token 需要真正 Prefill → GPU 大部分时间在等 I/O
• 每个 PFLOP 计算需加载 22GB KV-Cache → I/O 远比计算慢

根本原因:智能体的"长上下文、短新增、多轮次"模式, 将工作负载从 compute-bound 彻底转变为 I/O-bound。
传统优化焦点:更快的 GPU 更大的批量 更高的吞吐
智能体时代:更高的存储带宽 更快的 KV-Cache 加载 更高的吞吐
2
双路径设计的精妙之处
资源重分配而非资源增加
为何不简单增加 Prefill 侧带宽?
• 通用集群中成本高且不切实际
• Decode 侧的存储带宽已经存在但被浪费
• 增加一侧带宽无法解决架构层面的不对称性

DualPath 不是增加资源,而是重新分配已有资源
• Decode 引擎的 SNIC 闲置 → 让它加载 KV-Cache
• 计算网络(CNIC)有大量空闲带宽(通信呈脉冲式) → 让它搬运 KV-Cache
• 两条路径动态切换 → 存储带宽全局池化
3
Working Set 分析的深层意义
解释了为何 DRAM 缓存方案不够用
论文给出了一个简洁的 Working Set 估算公式:
Working Set ≈ λ × T̄ × total_len_avg / 2 DS 660B 在线服务:69 GB (APS=0.1) → 681 GB (APS=0.45)
深层意义:
• 生产环境中实际 Working Set 远大于实验值(工具调用延迟和到达间隔会使 JCT 增加 r 倍)
• Working Set 以 r² 增长,所需存储以 r² 扩展,实验成本以 r³ 扩展
• 这解释了为何 DRAM 缓存方案不够用:Working Set 可轻易超过可用内存,必须依赖 SSD 级外部存储
4
现代 AI 数据中心的网络分离
DualPath 在两个隔离网络间架起桥梁
DualPath 深度利用了现代 AI 数据中心的双网络架构

计算网络(CNIC)
每 GPU 配一个 400Gbps NIC
用于 GPU 间通信(AllToAll 等)
聚合带宽远大于存储网络
流量呈间歇性脉冲模式
存储网络(SNIC)
每节点一个 400Gbps NIC
用于访问数据集、检查点、KV-Cache
与计算网络物理隔离
Prefill 侧持续饱和

DualPath 巧妙地在这两个隔离网络之间架起桥梁: 让存储数据可以"绕道"计算网络,打破了物理隔离带来的带宽利用不均。

🔄 与相关工作的差异化定位

方案对比:为何 DualPath 独特?
方案 思路 局限
Mooncake DRAM 池分布式缓存 内存受限场景不适用
HCache 减少 KV-Cache 数据量 不解决带宽不对称
Strata GPU 辅助 I/O + 分层存储 仍是单路径
KVPR/TailorKV 重计算重叠 / 层级量化 优化单路径效率
DualPath 双路径加载 + 全局带宽池化 从架构层面消除不对称

DualPath 的独特贡献:不是在单条路径上做优化,而是开辟第二条路径, 从根本上重塑数据流动方式。
块布局设计:Layer Block 与 Full Block
Layerwise Prefill 将 KV-Cache 块大小缩小为 1/layer,块数量增加 layer 倍,对传输和存储性能构成挑战。

Layer Block [1, tokens, bytes]
单层 KV-Cache
用于 PE/DE 间的层级流式传输
Full Block [layer, tokens, bytes]
全层 KV-Cache
用于与存储交互

n 个 Layer Block 可直接拼接为一个 Full Block,无需手动内存布局转换

🌟 对大规模推理系统的启示

1. I/O 将成为智能体推理的核心瓶颈
随着智能体工作负载成为主流,传统以 GPU 算力为中心的推理优化思路需要根本性转变。

启示:推理系统的核心指标应从"FLOPS 利用率"转向"存储带宽利用率"。
2. 系统级全局优化优于局部优化
DualPath 不是在某个组件上做极致优化,而是重新审视整个数据流动, 发现并利用了全局资源的不对称性。

• 单一组件优化(如更快的存储、更大的缓存)收益有限
• 全局视角下发现"闲置资源"并加以利用,往往事半功倍
• 系统设计应追求资源利用率的全局均衡
3. 网络 QoS 是混合流量系统的基石
DualPath 成功的关键前提是流量隔离。没有可靠的 QoS 机制,引入额外数据路径只会带来干扰而非收益。

• 未来推理系统将承载越来越多异构流量
• 硬件级 QoS 支持(VL、DSCP、TC)是必要基础设施
PCIe QoS 的缺失是当前的重要瓶颈
4. 智能体 RL 训练需要专门的推理基础设施
智能体 RL 训练的 rollout 阶段本质上是大规模多轮推理,且 DRAM 被训练状态占用, 进一步加剧了存储带宽压力。

• RL 训练中的 rollout 推理 ≠ 普通推理,需要专门优化
• 训练和推理的基础设施正在融合
DualPath 式的全局带宽池化对 RL 训练场景尤为重要
5. 动态调度是充分发挥硬件潜力的关键
即使双路径硬件架构就位,没有好的调度策略也无法充分发挥其优势。

• Layerwise Prefill 贡献 17.21% 提升
• Dual-Path Loading 额外贡献 20.98% 提升
• Scheduling 额外贡献 7.43% 提升

调度算法将存储 NIC 负载不均衡从 1.53 降至 1.18, 看似简单的百分比改进,在大规模部署中转化为显著的吞吐收益
局限性与未来方向
当前局限:
• KV-Cache 读取路径未分割:一个请求只能选择 PE 或 DE 一侧读取
• 小模型场景下 P-D 传输开销不可忽略(DS 27B 的 TPOT 显著高于 Oracle)
• 大规模部署的 P/D 比例调优受限于实验预算
• 工作负载高度动态:前半段 Prefill 压力远高于后半段,静态配置难以最优应对

未来研究方向:
• 自适应 P/D 比例和并行配置(模拟器或在线调整机制)
• 更细粒度的读取路径调度(单个请求拆分到双路径同时加载)
• 大规模部署下的尾延迟优化
• 与 DRAM 缓存层的协同(当前边际收益有限)
• 跨代硬件适配(Ultra Ethernet 等新互连技术)
总结
DualPath 敏锐地捕捉到了智能体推理从 compute-bound 向 I/O-bound 转变的关键趋势, 并以一种优雅的架构创新——双路径 KV-Cache 加载——从根本上打破了 PD 分离架构中存储带宽的不对称瓶颈。

其设计哲学不是简单地"加资源",而是"重新分配已有资源", 通过全局带宽池化、精细流量隔离和智能调度,实现了接近理论上限的推理吞吐。

核心启示 当工作负载模式发生根本性转变时,系统架构也必须相应重构,而非在旧架构上修修补补。
论文信息
标题:DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference
作者:Yongtong Wu, Shaoyuan Chen, Yinmin Zhong, Rilin Huang, Yixuan Tan, Wentao Zhang, Liyue Zhang, Shangyan Zhou, Yuxuan Liu, Shunfeng Zhou, Mingxing Zhang, Xin Jin, Panpan Huang
机构:北京大学 · 清华大学 · DeepSeek-AI
发表时间:2026 年 2 月

评估模型:
• DeepSeek V3.2 660B(MoE,DeepSeek Sparse Attention)
• DS 27B(内部实验模型,660B 缩小版)
• Qwen2.5-32B(Dense,GQA)

核心技术:
双路径 KV-Cache 加载 · CNIC 中心化流量管理与 VL 隔离 · Layerwise Prefill · 自适应请求调度器 · Compute Quota 机制

基于 DeepSeek-AI 发布的 DualPath 论文 | 论文原文 | 3FS | FlashMLA | DeepGEMM | DeepEP

Kcores LLM Arena Logo