DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference
DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference #
Yongtong Wu et al. (PKU, Tsinghua, DeepSeek-AI) | 2026-02 | https://arxiv.org/abs/2602.21548 Category: framework | Tags: serving, KV-cache, disaggregated-inference, agentic-workloads, RDMA, scheduling, traffic-isolation, storage-io
§1 TL;DR #
DualPath 在 PD 分离推理架构中增加 storage→decode engine→RDMA→prefill engine 的第二条 KV-Cache 加载路径，聚合所有 engine 的 storage NIC 带宽，配合 CNIC-centric 流量隔离和自适应调度，在 agentic workload 下实现最高 1.87× 离线吞吐和 1.96× 在线服务提升，1152 GPU 近线性扩展。
§2 核心三问 #
Q1 痛点：PD 分离架构下 agentic 推理的存储带宽单点瓶颈 #
Paper's Figure 1 (caption: "Existing bottleneck (left) and DualPath (right)"). 左图：现有架构中 PE 的 SNIC 饱和而 DE 的 SNIC 空闲；右图：DualPath 新增 DE read path 聚合所有 SNIC 带宽。
Agentic LLM 推理（多轮、短追加、长上下文）导致 KV-Cache 命中率极高——DeepSeek 生产 coding agent trace 显示平均 157 轮、429 token/轮 append、上下文 32.7K tokens，命中率 98.7%。Prefill 阶段从计算密集退化为 I/O 密集：DeepSeek-V3.2 的 cache-compute ratio 达 22 GB/PFLOP。在 PD 分离架构中，所有 KV-Cache 存储读取集中在 prefill engine 的 storage NIC（SNIC）上，该 NIC 持续饱和；而 decode engine 的 SNIC 几乎完全空闲。硬件趋势加剧了这一矛盾——Ampere 到 Blackwell 的 I/O-compute ratio 下降了 14.4×。
Paper's Figure 3 (caption: "Hardware trends from Ampere to Blackwell"). Ampere→Blackwell I/O-compute ratio 下降 14.4×，存储带宽瓶颈逐代恶化。
Mooncake 用分布式 DRAM pool 缓解，但 DRAM 在 RL training rollout 时被 optimizer state offload 占用，且成本难以支撑超大 working set（论文估算真实场景下 working set 随 tool call latency 以 $r^2$ 扩展，总成本以 $r^3$ 扩展）。其他方案（HCache、TARDIS、Phoenix）从减少数据量或优化检索入手，但不解决带宽分配不均的根本问题。
Q2 方法：双路径 KV-Cache 加载 + CNIC-centric 流量隔离 + 自适应调度 #
核心洞察：KV-Cache 加载不必是 prefill-centric 的。Decode engine 的 SNIC 空闲，计算网络（CNIC）带宽远大于存储网络且模型推理通信是脉冲式的——可以让 KV-Cache 先走 DE 的 SNIC 加载到 DE DRAM，再通过 CNIC RDMA 转发到 PE，利用计算网络的空闲窗口。
三个关键设计：
- Dual-path data path：PE read path（传统：storage→PE buffer→PE HBM）和 DE read path（新增：storage→DE buffer→RDMA→PE HBM），两条路径均采用 layerwise streaming 与 prefill 计算重叠
- CNIC-centric traffic management：所有 GPU 数据传输（包括本地 H2D/D2H）统一走 CNIC + RDMA Write，利用 InfiniBand Virtual Lane 的 WRR 策略将 ~99% 带宽保留给模型推理通信，KV-Cache 流量走低优先级通道
- Adaptive request scheduler：PE 调度基于三级分类（overloaded/short-queue/long-queue）+ token count proxy；DE 调度两阶段（组间全局平衡 + 组内 HBM 感知）；读取路径选择基于 disk reading queue 长度
- Stage coverage：prefill + decode 均覆盖；prefill 端做 layerwise streaming（逐层加载/释放 KV-Cache，有效 batch size 扩大约 $n_{\text{layer}}$ 倍），decode 端所有请求进 forward batch
- Serving or training：兼顾在线推理服务（SLO-aware：TTFT≤4s, TPOT≤50ms）和离线批量推理（RL training rollout 阶段）
- Parallelism：PE 端采用 EP（Expert Parallel）+ DP（Data Parallel for attention）；DE 端采用 EP + DP。SGLang baseline 使用 TP=8（不支持 DP attention for Qwen）。论文不涉及 PP 或 SP
- Deployment mode：多节点 PD 分离（disaggregated prefill-decode）。评估规模从 2 节点（1P1D）到 144 节点（48P96D, 1152 GPU）。计算网络和存储网络物理隔离
- 存储层：3FS 分布式存储，无内部 DRAM cache，可饱和 400Gbps SNIC。KV-Cache 以 trie 结构组织，每个节点对应一个 Full Block $[\text{layer}, \text{tokens}, \text{bytes}]$
- Buffer 层：PE buffer + DE buffer 在 DRAM 预分配（DS models: 80GB/node, Qwen 32B: 320GB/node）。Layer Block $[1, \text{tokens}, \text{bytes}]$ 是逐层传输的基本单位，$n$ 个 Layer Block 可零拷贝拼接为 Full Block
- HBM 层：layerwise prefill 下 PE HBM 仅持有当前层 KV-Cache；DE HBM 持有完整 prompt KV-Cache（decode 开始前一次性加载）
- 硬件：NVIDIA Hopper GPU 集群，每节点 8 GPU，八张 400Gbps RDMA NIC（InfiniBand 计算网络），一张 400Gbps SNIC（3FS 存储网络），双处理器。计算网络和存储网络物理隔离
- 存储：3FS（无 DRAM cache，可饱和 400Gbps SNIC）
- 模型：DS 660B（MoE + MLA + Sparse Attention）、DS 27B（V3.2 缩小版，内部实验模型）、Qwen 32B（dense, GQA）
- 数据：DeepSeek 生产 RL training coding agent trace，三个 MaxLen 档位（32K/48K/64K），各 500 trajectories
- 默认配置：DS 660B 2P4D, Qwen 32B 1P2D, DS 27B 1P1D。DualPath DRAM 80GB/node（DS models），320GB/node（Qwen 32B）。SGL(MC) DRAM 1.5TB/node
- PE 端：compute-quota-based FIFO packing。逐个添加请求直到预估 attention 执行时间达上限（300ms）。溢出请求做 chunked prefill（binary search 找最大可塞入 bsz'）。每请求描述为 $(cached, bsz)$，通过 profiling 拟合理论计算量→wall-clock 时间映射
- DE 端：所有请求进 forward batch，不做 intra-engine 调度
- PE/DE buffer 在 DRAM 预分配。DualPath 每节点仅 80GB（DS models），vs SGL(MC) 的 1.5TB/node——DRAM 效率高 18.75×
- HBM 采用 paged 管理，DE 调度考虑 remaining HBM 容量决定能否接纳新请求
- KV-Cache 持久化：decode 阶段每累积 64 token 立即写入 3FS
- Layerwise prefill 消除 HBM capacity 对 batch size 的限制
- Compute quota 对齐 EP group 内各 GPU 的 attention 执行时间（Max/Avg ≤ 1.06），减少同步 bubble
- Dual-path loading 让 KV-Cache 读取与 prefill 计算重叠
- Basic → Ours：公平（same implementation base，增量 ~5K 行修改）
- SGL(MC)：论文自认不公平（"Comparing DualPath and SGL(MC) is unfair due to implementation differences"）。实质差异：(1) SGL(MC) 用 TP=8 而 DualPath 用 DP attention——attention 层效率不同；(2) SGL(MC) 用 1.5TB DRAM/node（Mooncake Store）而 DualPath 仅 80GB——未报告 Mooncake DRAM cache 命中率；(3) SGL(MC) 多个配置标记 N/A（运行出错）但未解释原因。仅报告 Basic→Ours 改善比，不报告绝对性能
- Oracle：公平（基于 DualPath 实现，bypass all I/O）
- 3FS (DeepSeek-AI, 2025a)：分布式存储，io_uring-like kernel bypass 接口
- FlashMLA (Li & Liu, 2025)：MLA attention kernel
- DeepGEMM (DeepSeek-AI, 2025b)：矩阵乘 kernel
- DeepEP (Zhao et al., 2025b)：Expert Parallelism 通信库
- SGLang (Zheng et al., 2024) / vLLM (Kwon et al., 2023)：baseline 对比框架
- 深入理解 InfiniBand VL arbiter 配置（高优先级 vs 低优先级 WRR 权重）
- 掌握 RDMA verbs API 的 work request submit 路径（mmio write to NIC registers, ~1μs）
- 验证 CNIC loopback RDMA Write 在 PCIe topology 下的实际行为
- 确保 doorbell batching 在高吞吐场景下的稳定性
- DE buffer 而非 GPUDirect RDMA 直写 DE HBM：论文选择先将 KV-Cache 存入 DE DRAM buffer 再 H2D，而非直接 GPUDirect RDMA 写入 DE HBM。原因是 agentic workload 的 generation length 短，TTFT 占端到端时间的不可忽略比例，DE buffer 减少了 HBM 占用从而允许更大 decode batch。这个权衡在长 generation 场景下可能翻转（GPUDirect RDMA 直写更优）。
- KV-Cache 路径选择的简单性：选择 PE read 还是 DE read 仅看"哪侧 disk reading queue 更短"——没有 split-read（将一个请求拆分到两条路径分别读取），论文自己承认这是 future work。在高度不均匀的工作负载下，这个简单策略可能导致一条路径过载。
- 对外接口：未公开。In-house system，无公开 API 规范
- 模型兼容：支持 DeepSeek MLA 系列和 HuggingFace 标准模型（Qwen2.5-32B 验证）
- 配置复杂度：高。需要调整 P/D ratio、InfiniBand VL QoS 参数（A.1 附录）、scheduler 参数（$\alpha$ = 3 秒可读 token 数, $\beta$ = 5 秒可处理 token 数, compute quota = 300ms）、DRAM buffer size、block size。参数需按硬件和工作负载 profiling 调优
- 迁移成本：从 vLLM/SGLang 迁移需要重写数据搬运层（CNIC-centric H2D/D2H）、scheduler 模块、集成 3FS 存储后端。工程量巨大，但核心思想（dual-path + VL isolation）可以在现有框架上实现
- 开源状态：否。DualPath 是 DeepSeek 内部 inference framework 的一部分
- 生产部署：是。论文明确声明 CNIC-centric approach "widely adopted in our production deployment"，实验数据来自 "production agentic RL training workloads"
- 上游合并：未合并到任何开源框架。核心组件 3FS、FlashMLA、DeepGEMM、DeepEP 均已单独开源
- 下游要求：需要 InfiniBand/RoCE 双网物理隔离的数据中心、3FS 分布式存储系统、NVIDIA Hopper+ GPU + 400Gbps RDMA NIC
- 与 DeepSeek-V3 基础设施的关系：DualPath 团队与 DeepSeek-V3 infra 高度重合，所有底层组件为 DeepSeek 自研。DualPath 本质上是 DeepSeek inference stack 在 agentic workload 兴起后的架构演进
- Serving stage：prefill + decode 全覆盖，核心优化在 prefill 端的 KV-Cache 加载
- Concurrency regime：中高并发（评估 1024-48K agents offline, 0.1-8.8 APS online）。低并发（<8 agents）时存储带宽未饱和，DualPath 优势有限
- Hardware affinity：NVIDIA Hopper（评估平台），需要 400Gbps RDMA NIC + InfiniBand VL QoS 或等效 RoCE TC。对 Blackwell 等更高算力 GPU，I/O-compute ratio 进一步恶化（Figure 3），DualPath 的收益更大
- Ecosystem integration：DeepSeek 内部 framework，5K 行修改。外部框架（vLLM/SGLang/TRT-LLM）需要：(a) 重写 H2D/D2H data path 为 CNIC RDMA Write，(b) 实现 dual-path KV-Cache loading 逻辑，(c) 扩展 scheduler 支持路径选择和三级分类，(d) 集成 3FS 或等效存储后端
- Migration path：对于已有 InfiniBand 双网集群的团队，最小改动路径是在现有 PD 分离框架上增加 DE read path 和 VL QoS 配置。但 CNIC-centric H2D/D2H 要求改写底层 memory copy 调用（从 cudaMemcpyAsync 到 RDMA verbs），这是侵入性改动
- PCIe QoS lanes：如果 GPU 的 PCIe 控制器原生支持多优先级队列（类似 NVMe 的 weighted round-robin arbitration），就可以直接在 PCIe 层面隔离集合通信和 KV-Cache 传输，无需 CNIC 绕路
- NIC-integrated memory controller：将 RDMA 和 local H2D/D2H 统一到 NIC 的 DMA engine 中（而非 GPU 的 CUDA copy engine），从硬件层面保证 QoS 一致性
- Storage-NIC 扩展：每节点从 1 SNIC 扩展到多 SNIC（$s > 1$），或 SNIC 带宽追上 CNIC（>400Gbps），可以直接缓解 storage I/O 瓶颈而无需 dual-path。但 Eq.9 表明 $s$ 增大会收窄 bottleneck-free P/D 区间
- CXL 内存池：CXL-attached memory 可以提供比 SSD 更高的带宽和比 DRAM 更大的容量，为 KV-Cache 存储提供中间层，降低对 storage NIC 带宽的依赖
核心技术壁垒：CNIC-centric data path 设计——将所有 GPU 数据搬运"绕路"走 CNIC 而非直接 CUDA copy engine 或 GPUDirect Storage，是目前唯一能在 PCIe 层面实现流量隔离的方案（现有 GPU 不支持 PCIe QoS）。这个"看似绕路实则唯一可行"的判断需要对 InfiniBand VL 机制、RDMA verbs API、PCIe 拓扑、CUDA copy engine 行为有深入的生产经验，是外部团队最难复现的部分。实测 RDMA Write work submission ~1μs vs cudaMemcpyAsync ~5-7μs，绕路反而更快。
Q3 结果 #
| 场景 | 指标 | 提升 | 条件 |
|---|---|---|---|
| 离线推理 | JCT | 最高 1.87× | DS 660B, 64K, 2048 agents |
| 在线服务 | APS 容量 | 平均 1.96× | DS 660B: 2.25×, DS 27B: 1.67× |
| 大规模扩展 | JCT | 3167s→3201s（24× 规模仅 +1.07%） | 2P4D→48P96D, 1152 GPU |
| Ablation | JCT 贡献 | layerwise -17.21%, +DPL -38.19%, +sched -45.62% | DS 660B, 64K |
| 负载均衡 | NIC balance | 1.53→1.18 (Max/Avg) | vs round-robin |
| 负载均衡 | Attention balance | 1.06 (Max/Avg) | EP group 内前 5% 任务阶段 |
DS 660B 上 DualPath 性能逼近 Oracle（零 I/O 上界），说明存储 I/O 瓶颈被有效消除。DS 27B 上 DualPath 仍比 Oracle 慢 1.09-1.85×，因为 1P1D 配置下存储带宽受限；小模型 TPOT 显著高于 Oracle，P-D transfer overhead 在小模型上不可忽略。
§3 架构与方法 #
3.1 System Scope #
3.2 数据通路 #
Paper's Figure 4a: PE read path — 传统路径，KV-Cache 从 3FS 经 PE SNIC 加载到 PE buffer，逐层 H2D 后计算，再 RDMA 传至 DE。
Paper's Figure 4b: DE read path — 新增路径，KV-Cache 从 3FS 经 DE SNIC 加载到 DE buffer，通过 CNIC RDMA Write 逐层转发到 PE HBM 参与计算。两条路径均采用 layerwise streaming 实现传输-计算重叠。
3.3 请求生命周期 #
3.3 核心组件 #
Central Scheduler：全局中心化调度器。接收客户端请求，通过 Leader Engine（每组 rank 0）获取 engine 状态报告 $(seq_e, tok_e, read\_q_{n(e)})$。调度分两级：inter-engine（请求→(PE,DE) pair + 路径选择）和 intra-engine（forward batch 构建）。CPU 开销 <10 核，不是扩展瓶颈。
Traffic Manager：每个 engine 内部模块。核心职责是将所有 GPU 数据传输统一走 CNIC——H2D/D2H 通过 CNIC loopback RDMA Write 实现（非 cudaMemcpyAsync），PE↔DE transfer 走 CNIC RDMA，storage I/O 走 SNIC。InfiniBand VL arbiter 以 WRR 策略分配带宽：高优先级 VL（模型推理通信）~99%，低优先级 VL（KV-Cache 传输）~1%+剩余。配置参数：qos_max_vls=4, qos_high_limit=240, qos_vlarb_high=0:192,1:192,2:0,3:192, qos_vlarb_low=0:192,1:192,2:64,3:192。
KV-Cache / Memory Manager：
Cross-node communication：计算网络 InfiniBand，每 GPU 一张 400Gbps CNIC。存储网络独立，每节点一张 400Gbps SNIC 连接 3FS。两网物理隔离。所有 PE↔DE KV-Cache 传输走计算网络 RDMA，通过 VL QoS 与模型推理的 AllToAll/ReduceScatter/AllGather 隔离。
3.4 Block Layout #
两种布局服务不同传输粒度：
| 布局 | Shape | 用途 |
|---|---|---|
| Full Block | $[\text{layer}, \text{tokens}, \text{bytes}]$ | 与 3FS 交互（读写存储） |
| Layer Block | $[1, \text{tokens}, \text{bytes}]$ | layerwise streaming（PE↔DE 逐层传输、PE buffer→HBM 逐层加载） |
Layerwise prefill 将 block 大小缩小为 $1/n_{\text{layer}}$、数量扩大 $n_{\text{layer}}$ 倍，对传输和存储性能提出挑战。CNIC-assisted copy（RDMA Write）的 ~1μs submit latency 相比 cudaMemcpyAsync 的 5-7μs 在细粒度传输场景下优势显著，且可通过 doorbell batching 进一步摊薄。
§4 作者证明 #
4.1 Notation Table #
| 符号 | 含义 | 典型值 |
|---|---|---|
| $P$ | Prefill 节点数 | 2 (DS 660B default) |
| $D$ | Decode 节点数 | 4 (DS 660B default) |
| $g$ | 每节点 GPU 数 | 8 |
| $B$ | 单 CNIC 带宽 | 400 Gbps ≈ 50 GB/s |
| $s$ | 每节点 SNIC 数 | 1 |
| $M$ | 每节点 DRAM 带宽 | ~500 GB/s |
| $T_p$ | PE read path 下单 PE-DE pair 流量 | $Bs/(Dg^2)$ |
| $T_c$ | DE read path 下单 PE-DE pair 流量 | $Bs/(Pg^2)$ |
4.2 方程推导与物理意义 #
PE CNIC Read (Eq. 1)：
$$2 \times T_p \times Dg = \frac{2Bs}{g} \leq B$$
物理意义：PE 的 CNIC read 方向承受两部分流量——(a) PE buffer→PE HBM 的逐层加载和 (b) PE HBM→DE buffer 的 KV-Cache 传输（PE read path 下两个方向的 loopback traffic 均计入 read）。因子 2 来自 PE read path 中 step 3（load to HBM）和 step 5（transfer to DE）各一次读取。成立条件：$s \leq g/2$，在 $g=8, s=1$ 下显然满足。
PE CNIC Write (Eq. 2-3)：
$$(T_p + T_c) \times Dg = \frac{Bs}{g} \times \left(1 + \frac{D}{P}\right) \leq B$$
$$\Rightarrow \frac{P}{D} \geq \frac{s}{g-s} \tag{3}$$
物理意义：PE 的 CNIC write 方向同时承受 PE read path（step 4: HBM→DE buffer write）和 DE read path（step 5: miss KV→DE buffer write）。当 D/P 过大时 DE read path 带来的写流量占主导。$g=8, s=1$ 时下界 $P/D \geq 1/7$。
DE CNIC Read (Eq. 4-5)：
$$(T_p + 2T_c) \times Pg = \frac{s}{g} \times \left(\frac{P}{D} + 2\right) \times B \leq B$$
$$\Rightarrow \frac{P}{D} \leq \frac{g-2s}{s} \tag{5}$$
物理意义：DE 的 CNIC read 方向承受三部分——PE read path 的 step 8（DE buffer→DE HBM），DE read path 的 step 3（DE buffer→PE HBM）和 step 6（DE buffer→DE HBM）。因子 2 在 $T_c$ 前因为 DE read path 有两次 DE-side read。$g=8, s=1$ 时上界 $P/D \leq 6$。
DE CNIC Write (Eq. 6-7)：
$$(2T_p + T_c) \times Pg \leq B$$
$$\Rightarrow \frac{P}{D} \leq \frac{g-s}{2s} \tag{7}$$
物理意义：DE 的 CNIC write 方向承受 PE read path 的 step 7/9 写入和 DE read path 的 step 7 写入。$g=8, s=1$ 时上界 $P/D \leq 3.5$。
DE DRAM (Eq. 8)：
$$\frac{P}{D} \leq \frac{M/(Bs) - 3}{2} \tag{8}$$
物理意义：DRAM 半双工，DE 端 read+write 总压力为 $(3+2P/D) \times Bs$。$M \approx 500$ GB/s, $Bs \approx 50$ GB/s 时上界 $P/D \leq 3.5$。
综合约束 (Eq. 9)：
$$\frac{s}{g-s} \leq \frac{P}{D} \leq \min\left\{\frac{g-2s}{s},\; \frac{g-s}{2s},\; \frac{M/(Bs)-3}{2}\right\} \tag{9}$$
$g=8, s=1$: bottleneck-free 范围 $\frac{1}{7} \leq P/D \leq \frac{7}{2}$，覆盖几乎所有生产配置。
4.3 六项核查 #
| # | 检查项 | 结论 |
|---|---|---|
| 1 | 假设合理性 | 关键假设"well-configured PCIe topology（每 GPU-NIC pair 在同一 PCIe switch 下）"在 DGX 系列中成立；"load-balanced task scheduling"由 §6 的调度器保证；"无计算网络拥塞"由 VL QoS 保证。假设集合合理但排除了 PCIe 拓扑非对称的非标准集群 |
| 2 | 方程推导正确性 | 手动代入 $g=8, s=1, P=2, D=4$：Eq.1 → $2 \times 50/(4 \times 64) \times 32 = 50 \leq 50$ GB/s（恰好满足）；Eq.3 → $P/D = 0.5 \geq 1/7$ ✓；Eq.5 → $P/D = 0.5 \leq 6$ ✓；Eq.7 → $0.5 \leq 3.5$ ✓；Eq.8 → $0.5 \leq 3.5$ ✓ |
| 3 | 单调性/凸性 | Eq.9 定义了 P/D 的可行区间。上界 $\min\{6, 3.5, 3.5\} = 3.5$，约束最紧处为 DE CNIC Write 和 DE DRAM（两者并列）。增加 $s$ 会缩窄可行区间（分子减、分母增），说明多 SNIC 需要更严格的 P/D 配比 |
| 4 | 数值验证 | 论文宣称 g=8, s=1 时范围 $[1/7, 7/2]$：下界 $s/(g-s)=1/7$ ✓；上界 $\min\{6, 3.5, 3.5\}=3.5=7/2$ ✓。数值与论文一致 |
| 5 | 边界条件 | $P/D = 1/7$（最少 PE）：PE CNIC write 恰好饱和。$P/D = 7/2$（最多 PE）：DE CNIC write 和 DE DRAM 同时恰好饱和。边界处任一路径增加流量都会导致瓶颈 |
| 6 | 模型局限性 | 分析假设所有 storage NIC 全速利用、负载完美均衡、无计算网络拥塞——这是理论上界。实际中 scheduler 不完美（NIC balance 1.18 而非 1.0）、VL QoS 仍有 ~1% 带宽损耗、PCIe topology 可能不完全对称。论文通过实验验证理论可行区间在实践中成立 |
4.4 Working Set Model (§8.2) #
$$\text{Working Set} = \lambda \bar{T} \times \frac{\text{total\_len}_{avg}}{2}$$
Little's law 应用于 KV-Cache 存储：并发 trajectory 数 = $\lambda\bar{T}$，每个 trajectory 平均 KV-Cache 占用为总长度的一半（trajectory 生命周期内均匀增长）。DS 660B 在线服务场景：APS 0.1 时 69 GB，APS 0.45 时 681 GB。
关键推论：真实场景中 tool call latency 使 JCT 增长 $r$ 倍 → APS 容量增长 $r$ 倍 → working set 增长 $r^2$ 倍 → 总成本增长 $r^3$。这从根本上限制了纯 DRAM pool 方案在大规模 agentic 部署中的可行性。
§5 实验与数据 #
5.1 实验环境 #
5.2 关键实验结果 #
Paper's Figure 7 (caption: "End-to-end JCT comparison for offline agentic inference"). 三个模型在不同 agent 数量和 MaxLen 下的 JCT 对比。
Figure 7 — 离线推理主实验：DualPath 在 DS 660B 上几乎逼近 Oracle（零 I/O 上界），证明 I/O 瓶颈被有效消除。更大 batch 和更长上下文时优势更大——这恰好是 agentic workload 的典型特征。SGL(MC) 在多个大配置标记 N/A（运行出错）。
Figure 8 — P/D ratio 消融（DS 27B）：DualPath 1P1D ≈ Basic 2P1D，DualPath 2P1D ≈ DualPath 1P2D。每对系统具有等量的可用存储带宽（Basic 只用 PE 节点 SNIC，DualPath 用所有节点），这直接证实存储带宽是主导瓶颈。
Figure 9 — Append/Generation 长度敏感性（DS 660B, 64K, 1024 agents）：短 append 时 DualPath 优势最大（1.82-1.99× vs Basic）。随 append 增长，Basic 性能逐渐追上 DualPath 和 Oracle（瓶颈从 I/O 转为 compute）。Generation 长度趋势类似。
Paper's Figure 10 (caption: "Online serving: TTFT and TPOT under increasing APS"). DualPath APS 容量远超 Basic，TPOT 不增加。
Figure 10 — 在线服务延迟指标：DualPath APS 容量远超 Basic（DS 660B 2.25×, DS 27B 1.67×）。TPOT 不增加（证明 DE 端无额外开销）。TTFT 在高负载下保持稳定，而 Basic 的 TTFT 因排队急剧上升。
Paper's Figure 12 (caption: "TTFT breakdown (left) and ablation study (right)"). 左图 TTFT 各组件分解，右图三项技术的增量贡献。
Figure 12 — TTFT 分解 + Ablation：左图 TTFT 分解直接证明 Basic 瓶颈在 "Reading KV-Cache" 组件——随 APS 增长膨胀，DualPath 有效压缩。右图 ablation 量化三个技术独立贡献：layerwise prefill -17.21%（缓解 HBM 瓶颈），+dual-path loading -38.19%（核心贡献：聚合 SNIC 带宽），+scheduling -45.62%（均衡利用）。
5.3 Before-After 对比表 #
| 优化 | 指标 | Baseline | After | 改善 | 条件 |
|---|---|---|---|---|---|
| Layerwise prefill | JCT | Basic | +Layerwise | -17.21% avg | DS 660B, 64K |
| +Dual-path loading | JCT | Basic | +LW+DPL | -38.19% avg | DS 660B, 64K |
| +Scheduling | JCT | Basic | Full DualPath | -45.62% avg | DS 660B, 64K |
| Full DualPath | JCT (offline) | Basic | Ours | 1.87× | DS 660B, 64K, 2048 agents |
| Full DualPath | APS (online) | Basic | Ours | 2.25× | DS 660B |
| Full DualPath | APS (online) | Basic | Ours | 1.67× | DS 27B |
| Full DualPath | NIC balance | Round-robin 1.53 | Scheduler 1.18 | -23% | 3 nodes |
| 2P4D→48P96D | JCT | 3167s (2K agents) | 3201s (48K agents) | ~线性扩展 | DS 660B offline |
| 2P4D→44P88D | APS | 0.4 APS | 8.8 APS | 22× throughput | DS 660B online |
5.4 瓶颈转移分析 #
Basic: Storage I/O bound (PE SNIC 饱和, GPU 空等)
→ +Layerwise prefill: Storage I/O bound (HBM 不再限制 batch, 但 SNIC 仍饱和)
→ +Dual-path loading: 逼近 compute bound (DE SNIC 参与, 总 SNIC BW 翻倍)
→ +Scheduling: Compute bound (SNIC 均衡利用, Ours ≈ Oracle)
残余瓶颈:
- DS 660B: GPU compute (Ours ≈ Oracle)
- DS 27B: P-D KV-Cache transfer overhead (TPOT >> Oracle, 小模型 transfer time 占比高)
- 大规模: scheduler queuing (TTFT percentile 有优化空间)
5.5 Scheduling & Resource Management #
Batch formation：
Memory management：
GPU utilization optimization：
Preemption/admission：PE 调度中 $tok_e > \beta$（5 秒处理量上限）的 engine 归入 $C_1$（overloaded），不接受新请求——隐式 admission control。DE 调度中 HBM 不足时终止 fetch。无显式 preemption 机制。
5.6 Workload Characterization #
| Workload 区间 | DualPath | Basic | 原因 |
|---|---|---|---|
| 短 append、高并发、长上下文（agentic 典型） | 显著优于 (1.87×) | 存储 I/O 瓶颈 | cache-compute ratio 极高，SNIC 饱和，DualPath 聚合全部 SNIC 带宽 |
| 长 append（>数千 token/turn） | 优势缩小 | 逐渐追上 | 瓶颈从 I/O 转为 compute，DualPath 的带宽优势被稀释 |
| 长 generation（decode-heavy） | 优势缩小 | 接近 | KV-Cache loading 压力降低 |
| 低并发（<8 agents） | 有限优势 | 尚可 | 存储带宽未饱和，DualPath 无需双路径 |
| 单轮/少轮对话 | 无优势 | 等价 | 无 KV-Cache reuse，不存在 I/O 瓶颈 |
| DRAM 充足（非 RL 训练） | Mooncake 可能更优 | — | DRAM pool 命中率高时无需走 SSD |
论文在 append/generation 长度敏感性实验（Figure 9）中展示了前三行的趋势，但未显式测试后三行的 worst-case 场景。
5.7 Baselines 公平性分析 #
§6 论证链 #
| Step | 论点 | 证据 | 依赖 |
|---|---|---|---|
| 1 | Agentic workload 导致 KV-Cache 命中率极高（≥95%） | 生产 trace：157 轮，429 token append，98.7% 命中率（Table 2） | — |
| 2 | 高命中率使 prefill 从 compute-intensive 退化为 I/O-intensive | Cache-compute ratio 达 22 GB/PFLOP（DS V3.2, Table 1） | Step 1 |
| 3 | GPU 算力增长远超网络带宽，I/O 瓶颈逐代恶化 | Ampere→Blackwell I/O-compute ratio 下降 14.4×（Figure 3） | Step 2 |
| 4 | PD 分离架构中 PE SNIC 持续饱和而 DE SNIC 几乎空闲 | 架构分析 + Figure 1 左图 | Step 2 + §2.1 |
| 5 | 计算网络（CNIC）带宽远大于存储网络且推理通信为脉冲式，可复用空闲窗口 | 每 GPU 400Gbps CNIC vs 每节点共享 400Gbps SNIC；集合通信 sub-ms 级别 | Step 4 + §2.3 |
| 6 | Dual-path 设计在典型 P/D 比下不引入新的 CNIC 或 DRAM 瓶颈 | Closed-form 分析 Eq. 1-9：$g=8, s=1$ → $P/D \in [1/7, 7/2]$ | Step 5 |
| 7 | InfiniBand VL QoS 可有效隔离 KV-Cache 流量与模型推理通信 | VL arbiter WRR 配置 ~99% 带宽给高优先级；CNIC-centric data path 使 PCIe 层面也受 NIC QoS 管控 | Step 5 |
| 8 | 三级分类 + token count proxy 调度有效平衡 NIC 和 GPU 负载 | NIC balance 1.53→1.18（Figure 13），attention balance 1.06（Figure 14） | Step 6 + 7 |
| 9 | 完整系统在离线/在线场景均显著提升，且近线性扩展 | 1.87× offline, 1.96× online, 1152 GPU 扩展 JCT 仅 +1.07%（Figure 7, 10, Table 3） | Step 6 + 7 + 8 |
§7 实现与工程细节 #
7.1 代码 Cross-Reference #
[实现未公开] — DualPath 实现于 DeepSeek 内部 inference framework，约 5K 行修改，代码未开源。
依赖的开源组件：
7.2 核心技术壁垒 #
CNIC-centric data path 是全文最难复现的工程决策。表面上"所有 H2D/D2H 都绕路走 NIC"违反直觉——为什么不用 CUDA copy engine 直连？根本原因是当前 GPU 不支持 PCIe QoS：cudaMemcpyAsync 和 GPUDirect Storage 产生的 PCIe 流量与模型推理的集合通信（EP AllToAll、TP ReduceScatter/AllGather）共享 PCIe 带宽，且无法区分优先级。在 sub-ms 级别的集合通信 burst 之间插入低优先级 I/O 是不可能通过软件 traffic shaper 实现的。
唯一的解法是将所有数据搬运统一到 NIC 的 QoS 域——通过 CNIC 的 RDMA Write 完成 H2D/D2H（包括本机 loopback），然后用 InfiniBand VL（或 RoCE TC/DSCP）实现硬件级优先级隔离。这需要：
这不是算法创新而是大规模部署中"唯一可行路径"的工程判断，需要在生产级集群上反复验证。
7.3 关键实现细节 #
7.4 API & Usability #
7.5 Adoption & Ecosystem #
7.6 Deployment Context #
7.7 Software → Hardware Reverse Implication #
DualPath 的 CNIC-centric 设计本质上是软件层面对硬件缺陷的 workaround——当前 GPU 不支持 PCIe QoS，无法在 PCIe 层面区分推理通信和数据搬运的优先级。
这个 workaround 的复杂度（所有 H2D/D2H 绕路走 NIC、InfiniBand VL 配置、RDMA verbs API 替代 CUDA copy engine）暗示了未来硬件可以简化的方向：