新增: DeepSeek 全部 33 篇官方论文(原文 PDF 走 Git LFS + 中文精读笔记与索引)
This commit is contained in:
ylhan
@@ -0,0 +1,94 @@
|
||||
# DualPath：打破智能体式 LLM 推理中的存储带宽瓶颈
|
||||
|
||||
> **原文标题**：DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference
|
||||
> **arXiv**：[2602.21548](https://arxiv.org/abs/2602.21548) ｜ **发布**：25 Feb 2026（v1），26 Feb 2026（v2）
|
||||
> **作者/机构**：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）
|
||||
> **原文 PDF**：[03-DualPath-2602.21548.pdf](./03-DualPath-2602.21548.pdf)
|
||||
|
||||
## 一、摘要（全文翻译）
|
||||
|
||||
多轮、智能体式（agentic）LLM 推理的性能，正日益由 KV-Cache 的存储 I/O 而非计算所主导。在普遍采用的分离式（disaggregated）架构中，从外部存储加载海量 KV-Cache 造成了一种根本性的失衡：预填充引擎（prefill engine）上的存储网卡带宽被完全打满，而解码引擎上的存储网卡却处于空闲状态。这种不对称严重制约了系统整体吞吐。
|
||||
|
||||
我们提出 DualPath，一个通过引入双路径 KV-Cache 加载来打破该瓶颈的推理系统。在传统的「存储到预填充」路径之外，DualPath 还启用了一条新颖的「存储到解码」路径：KV-Cache 先被加载进解码引擎，随后通过计算网络上的 RDMA 高效传输到预填充引擎。DualPath 将这条经过优化的数据路径——它本身就能避免网络拥塞，并避免干扰对延迟至关重要的模型执行通信——与一个在预填充与解码引擎之间动态均衡负载的全局调度器结合在一起。
|
||||
|
||||
我们在三个模型上、使用真实的智能体式工作负载所做的评测表明，DualPath 在我们自研的推理系统上把离线推理吞吐最高提升 1.87×。它还能在不违反 SLO 的前提下，把在线服务吞吐平均提升 1.96×。
|
||||
|
||||
## 二、核心贡献
|
||||
|
||||
1. **指出智能体式负载的本质是 I/O 受限**：论文通过生产环境 trace 量化了「多轮 + 短追加 + 长上下文」带来的 98.7% KV-Cache 命中率与约 22 GB/PFLOP 的缓存-计算比，证明 KV-Cache 加载而非计算才是当代 PD 分离架构下的主导性能因素。
|
||||
2. **提出双路径 KV-Cache 加载（dual-path loading）**：在传统「存储→预填充（PE）」路径之外新增「存储→解码（DE）→RDMA→PE」路径，把全机群存储网卡带宽池化，解决既有系统只能用预填充侧网卡、造成预填充侧存储带宽长期饱和而解码侧闲置的根本性浪费。
|
||||
3. **给出无瓶颈可行性分析**：在合理的 PCIe 拓扑与负载均衡假设下推导出双路径不引入 CNIC 或 DRAM 新瓶颈的 P/D 比值区间 $\frac{s}{g-s}\le P/D\le\min\{\frac{g-2s}{s},\frac{g-s}{2s},\frac{M/Bs-3}{2}\}$，在 $g=8,s=1$ 的实际配置下覆盖 $1/7\le P/D\le 7/2$ 的绝大多数部署。
|
||||
4. **以 CNIC 为中心的流量管理与隔离**：让所有 GPU 进出的流量（含本地 H2D/D2H）统一走 GPU 配对的 CNIC 与 GPUDirect RDMA 路径，从而借用计算网络原生的 QoS（InfiniBand VL / RoCE TC+DSCP）把 KV-Cache 流量压到低优先级虚拟通道，避免干扰 EP AllToAll 等亚毫秒级集合通信。
|
||||
5. **面向负载的双层自适应调度器**：跨引擎调度同时均衡存储网卡队列、token 计数与 HBM 余量并动态选择读取路径；引擎内调度用计算配额与 chunked prefill 拉平注意力层执行时间，消除 GPU 空泡。
|
||||
6. **实测收益**：离线推理吞吐最高 1.87×（DS 660B，对未改造的自研基线 Basic），在线服务在 TTFT≤4s、TPOT≤50ms 的 SLO 下吞吐平均 1.96×，TTST 与 TPOT 基本无回退，并验证到 1152 张 GPU 的近线性扩展。
|
||||
|
||||
## 三、方法与技术要点
|
||||
|
||||
### 3.1 瓶颈诊断与动机
|
||||
|
||||
论文从三个决定性因素论证瓶颈：其一，智能体负载天然高命中率——生产代码类任务 trace 显示平均 157 轮、平均上下文 32.7k、平均追加长度仅 429，命中率 98.7%，每轮都要从持久化存储读回全上下文 KV-Cache，缓存-计算比高达约 22 GB/PFLOP（DeepSeek-V3.2），而 KV-Cache 更大、未做 MLA 优化的模型（如 FP16 下的 Qwen2.5-32B 达 117–267 GB/PFLOP）情况更差；其二，硬件趋势不利，从 NVIDIA Ampere 到 Blackwell 的 I/O-计算比下降了 14.4×，网卡带宽与 HBM 容量落后于 GPU FLOPS 增长；其三，PD 分离架构下命中 KV-Cache 完全由预填充引擎从远端存储读取，把全部存储 I/O 压力集中在预填充侧 SNIC 上。论文同时观察到计算网络流量呈「亚毫秒突发、间歇」形态，存在大量闲置窗口，于是产生核心机会：用解码节点的 SNIC 读数据，再借更快的计算网络带宽送回预填充节点。
|
||||
|
||||
### 3.2 双路径加载的数据流
|
||||
|
||||
系统为每个 PE 与 DE 分配少量 DRAM 作为缓冲（PE Buffer / DE Buffer）。在 **PE 读路径**中，命中 token 的 KV-Cache 先从持久化存储读入 PE Buffer，在每层注意力计算前按层搬入 PE HBM 以计算未命中（miss）prompt token 的 KV-Cache，随后命中与未命中的 KV-Cache 一起传回 DE Buffer 组成完整 prompt KV-Cache；这一过程重复 $n_{layer}$ 次，且传输与计算重叠。在 **DE 读路径**中，命中 KV-Cache 先读入 DE Buffer，预填充期间逐层从 DE Buffer 取用（同样与计算重叠），某层算完后只把 miss token 的 KV-Cache 传到 DE Buffer 与已有命中部分合并。解码阶段开始前，DE 分配 HBM 并做 H2D 搬移，然后释放 CPU 内存；解码过程中每累积满一个 token 块（如 64 个 token）即落盘。选择 DE Buffer 中转而非直接 GPU Direct RDMA 绕开，是为了降低 GPU 显存占用、加快首 token 时延（TTFT 在本场景占端到端时间不可忽略），代价是额外的 DRAM 与一次 H2D 的 CNIC 压力。
|
||||
|
||||
### 3.3 块布局与无瓶颈分析
|
||||
|
||||
层式预填充把 KV-Cache 块大小降到原 $1/layer$、块数放大 $layer$ 倍，为此论文设计两种块：**Layer Block** 形状 $[1,tokens,bytes]$（单层）与 **Full Block** 形状 $[layer,tokens,bytes]$（全层）。与存储的交互一律用 Full Block，而 PE HBM 加载、PE↔DE Buffer 的层式流式传输用 Layer Block。无瓶颈分析取每个 PE-DE 对的流量 $T_p=Bs/(Dg^2)$（PE 读路径）与 $T_c=Bs/(Pg^2)$（DE 读路径），逐一约束 PE CNIC 的读/写方向与 DE CNIC 的读/写方向，并叠加 DRAM 半双工压力（PE MEM 为 $2sB$，DE MEM 为 $(3+2P/D)Bs$），最终得到 3.1 中给出的 P/D 合法区间；当 $g=8,s=1$、$M\approx500$ GB/s、$Bs\approx50$ GB/s 时区间为 $1/7 \le P/D \le 7/2$。
|
||||
|
||||
### 3.4 以 CNIC 为中心的流量管理器
|
||||
|
||||
CUDA copy engine 与 GPUDirect Storage 等既有手段的问题在于：它们走与计算网络不同的通道、不受同一套 QoS 管控，且现有 GPU 不支持 PCIe QoS，无法保护模型执行通信；而集合通信是亚毫秒级突发，软件流量整形器也无法把低优先级 I/O 塞进空隙。因此论文把所有 GPU 进出流量统一收敛到 CNIC 的 GPUDirect RDMA 路径：先用存储网把 KV-Cache 读入 host DRAM，再向配对的 CNIC 提交 RDMA Write 完成本地 H2D，写回对称处理，使 CNIC 成为全部 GPU PCIe 流量的集中 QoS 调度点。隔离上基于 InfiniBand 虚拟通道（VL），把模型通信放高优先级 VL、其余（含 KV-Cache）放低优先级 VL，配置加权轮询仲裁把约 99% 带宽留给高优先级 VL、余量给低优先级防饿死（附录给出 `qos_max_vls 4`、`qos_high_limit 240` 等参数；RoCE 可用 DSCP+TC 与 PFC 等价实现）。额外收益是：单次 `cudaMemcpyAsync` 提交开销约 5–7 μs，一次 RDMA Write 只需约 1 μs 且可用 doorbell batching 摊薄，故大量小块数据下 CNIC 辅助 H2D/D2H 反而优于 CUDA copy engine。
|
||||
|
||||
### 3.5 自适应请求调度
|
||||
|
||||
调度分两层。**跨引擎调度**把引擎分组，仅 rank 0（Leader Engine）与调度器交互，同节点引擎保证同组；引擎上报未完成请求数 $seq_e$、其 token 总量 $tok_e$ 与所属节点的磁盘读队列长度 $read\_q_{n(e)}$，并以 token 数作为 GPU、磁盘与网络负载的统一代理。PE 侧按 FIFO 取任务，把引擎分为过载（$tok_e>\beta$）、所在节点读队列短（$read\_q\le\alpha$）、读队列长三类：不给过载引擎派活，优先第二类（避免存储网卡闲置），在其中选 $tok_e$ 最小者，其次第三类；两类皆空则终止本次取任务。DE 侧为两级且不保全局 FIFO：组间把请求分给 token 总量最小的组；组内按剩余 HBM 估算可调度上界集合 $R$，取高 token 阈值 $Z=1.05\times(\sum_{r\in R}len_r+\sum_{e\in E}tok_e)/|E|$，优先选择不会越过 $Z$ 且 $seq_e$ 最小的 DE，否则退回高 token 组中 $tok_e$ 最小者以降低 HBM 耗尽与抢占风险。路径选择上挑读队列更短的一侧读取（把请求一分为二从两侧并行读留作未来工作）。**引擎内调度**只作用于 PE（DE 总是把全部请求入批）：以 (cached, bsz) 描述请求并预估注意力层执行时间（计算量与墙钟时间的关系通过离线 profiling 拟合），按 FIFO 持续加入请求直到逼近预设计算配额；超限时对 $bsz$ 做二分查找得到可塞入余量的 $bsz'$ 并执行 chunked prefill。
|
||||
|
||||
## 四、主要实验结果
|
||||
|
||||
实验平台为 8×NVIDIA Hopper GPU、双路 CPU、8 张 400 Gbps RDMA 网卡加 1 张连 3FS 的存储网卡、计算网与存储网物理隔离的机群；模型为 DS 660B（MoE + DeepSeek Sparse Attention）、DS 27B（内缩版本）与 Qwen2.5-32B（dense + GQA）；数据集为三个生产级智能体 RL 轨迹集（各 500 条轨迹）。
|
||||
|
||||
| 基准 / 任务 | 本模型 | 对比对象 | 说明 |
|
||||
|---|---|---|---|
|
||||
| 离线批量推理 JCT（DS 660B） | 最高 **1.87×** | Basic（未改造自研框架） | 性能接近 Oracle（零 I/O 开销理论上界），说明 KV-Cache I/O 基本被消除 |
|
||||
| 离线批量推理 JCT（DS 27B） | 最高 **1.78×** | Basic | 仍比 Oracle 慢 1.09–1.85×，受 1P1D 存储带宽限制 |
|
||||
| 离线 JCT（追加长度变化，DS 660B/64K/1024 agents） | **1.82–1.99×** | Basic | 追加变长时 Basic 逐步逼近 DualPath 与 Oracle，瓶颈转回 GPU 计算压力 |
|
||||
| 离线 JCT（P/D 比值 1P1D、2P1D、1P2D，DS 27B） | 平均 **1.64×**（最高 2.46×） | Basic（对应配置） | Basic 1P1D≈Basic 1P2D、DualPath 1P1D≈Basic 2P1D，佐证存储带宽是主导瓶颈 |
|
||||
| 在线服务吞吐（DS 660B） | 最高 **2.25×** | Basic | 到达率上限由 APS 提升衡量 |
|
||||
| 在线服务吞吐（DS 27B） | 最高 **1.67×** | Basic | 与 DS 660B 趋势相似，两者 TPOT 均显著高于 Oracle（小模型基础 P-D 传输开销可观） |
|
||||
| 消融：层式预填充 | JCT 降低 **17.21%** | Basic | 缓解 PE HBM 瓶颈并掩盖传输开销 |
|
||||
| 消融：层式预填充 + 双路径加载 | JCT 降低 **38.19%** | Basic | 双路径贡献主要收益，请求可从 PE 或 DE 两侧读 KV-Cache |
|
||||
| 消融：再加调度算法 | JCT 降低 **45.62%** | Basic | 最好的组合，验证均衡调度对存储网卡的有效性 |
|
||||
| 负载均衡（存储网卡） | Max/Avg 由 **1.53 降至 1.18** | 轮询（round robin） | 注意力层执行时间 Max/Avg 在任务前 5% 低至 1.06，减少 GPU 空泡 |
|
||||
| 大规模离线（DS 660B） | 48P96D/4.8万 agents：**JCT 3,201s** | 2P4D/2千 agents：3,167s | 近线性加速，调度器 CPU 占用始终低于 10 核 |
|
||||
| 大规模在线（DS 660B） | 44P88D：**8.8 APS**（TTFT 1.847s / TTST 0.194s / TPOT 0.036s） | 2P4D：0.4 APS（1.739s / 0.228s / 0.039s） | 吞吐提升 22× 而时延基本不变 |
|
||||
|
||||
离线场景下 DualPath 在更大批量和更长最大智能体长度（MAL）时受益更多；在线场景下 DualPath 的 TTST 与 Basic 相当、TPOT 不引入额外解码开销，并且 TTFT 的各分量在不同 APS 下保持稳定，而 Basic 的排队时间因存储带宽不足急剧增长。仍有差距之处在于：DS 27B 等小模型上基础 P-D 传输开销显著（TPOT 明显高于 Oracle），且 SGL(MC) 在部分大配置下报错未能完成（记为 N/A），与 SGL(MC) 的对比因实现差异被论文明确判定为不公平、只报告 Basic→Ours 的提升。
|
||||
|
||||
## 五、结论、局限与影响
|
||||
|
||||
- **结论**：DualPath 通过双路径 KV-Cache 加载重新分配存储网络负载，解决 PD 分离架构下 KV-Cache 读取不均衡问题，离线推理吞吐最高提升 1.87×，在线服务平均每秒智能体运行数提升 1.96×；理论上在常见 P/D 比下不引入新瓶颈，工程上通过 CNIC 集中 QoS 与双层调度把额外流量对推理通信的干扰降到可忽略。
|
||||
- **局限性**：作者自述的局限包括——大规模实验因缺少充分调优的并行度与 P/D 比值（需要大量实验预算），未展现出相比等价成本的多组小规模单元之外的额外 JCT 或服务容量收益；调度算法仍有改进空间，期望在大规模部署下取得更低的 TTFT 分位数；由于真实场景存在到达间隔与工具调用延迟，工作集将随 $r^2$ 放大，而验证这一点需要 $r$ 倍机器小时与 $r^2$ 倍存储（成本按 $r^3$ 增长），受资源限制无法承担；把小请求拆成两半从 PE/DE 两侧并行读取以及小模型上 P-D 传输开销的优化均留作未来工作；离线负载高度动态，需要更自适应的并行度与 P/D 比配置（如模拟器或在线调整机制）。
|
||||
- **影响**：该工作把「KV-Cache 必须由预填充引擎读取」这一隐含假设拆掉，将全机群存储网卡带宽变成可池化、可调度的全局资源，为智能体式（RL rollout、长会话编码助手）这类高缓存命中、I/O 受限负载提供了新的扩容维度；其「所有 GPU 流量统一走 CNIC 以借用计算网络原生 QoS」的做法与 RoCE/UnifiedBus/Ultra Ethernet 的 QoS 演进方向一致，具备向更广泛互连技术迁移的潜力。
|
||||
|
||||
## 六、关键术语对照表
|
||||
|
||||
| English | 中文 |
|
||||
|---|---|
|
||||
| Agentic LLM Inference | 智能体式 LLM 推理 |
|
||||
| KV-Cache | 键值缓存 |
|
||||
| Prefill-Decode (PD) Disaggregation | 预填充-解码分离 |
|
||||
| Prefill Engine (PE) / Decode Engine (DE) | 预填充引擎 / 解码引擎 |
|
||||
| Dual-Path Loading | 双路径加载 |
|
||||
| Layerwise Prefill | 层式预填充 |
|
||||
| Storage NIC (SNIC) / Compute NIC (CNIC) | 存储网卡 / 计算网卡 |
|
||||
| GPUDirect RDMA / GPUDirect Storage | GPU 直通 RDMA / GPU 直通存储 |
|
||||
| Virtual Lane (VL) / Weighted Round Robin (WRR) | 虚拟通道 / 加权轮询 |
|
||||
| Quality of Service (QoS) | 服务质量 |
|
||||
| Cache-Compute Ratio | 缓存-计算比 |
|
||||
| Time to First Token (TTFT) / Time to Second Token (TTST) / Time per Output Token (TPOT) | 首 token 时延 / 第二 token 时延 / 每输出 token 时延 |
|
||||
| Service Level Objective (SLO) | 服务等级目标 |
|
||||
| Job Completion Time (JCT) | 作业完成时间 |
|
||||
| Expert Parallelism (EP) / Data Parallelism (DP) | 专家并行 / 数据并行 |
|
||||
| Chunked Prefill / Compute Quota | 分块预填充 / 计算配额 |
|
||||
| Working Set | 工作集 |
|
||||
Reference in New Issue
Block a user