DualPath论文解读_打破 Agentic LLM 推理中的存储带宽瓶颈
DualPath: 打破 Agentic LLM 推理中的存储带宽瓶颈
📚 论文来源：arXiv:2602.21548v2
👨💻 作者团队：北京大学、清华大学、DeepSeek-AI
前言
DeepSeek 模型许久未更新，我便去挖了挖他们的最新论文。还真发现了一篇大模型基建领域的重磅工作——DualPath。
这篇论文解决了一个核心问题：多轮对话型 AI 的性能瓶颈。简单来说，当 AI 助手处理多轮对话时，系统效率被一个"存储带宽"问题严重制约。DeepSeek 的解决方案非常巧妙——通过双路径 KV-Cache 加载，可以让推理吞吐量提升近 2 倍。
接下来，我用最清晰明了的方式，读懂这篇论文的核心思想。
一、什么是 Agentic LLM？
先说说最近很火的一个概念——Agentic LLM。
传统 LLM vs Agentic LLM
| 传统 LLM | Agentic LLM |
|---|---|
| 单轮问答 | 多轮交互 |
| 独立请求 | 长期会话 |
| 上下文固定 | 上下文累积 |
| 简单任务 | 复杂任务规划 |
Agentic LLM 可以理解为"AI 助手"，它能够自主规划任务步骤、调用外部工具（搜索、API、计算器），通过多轮对话解决复杂问题。上下文可以累积到 10 万 tokens。
Agentic 工作负载的特点
论文给出的典型数据是这样的：
- 平均轮数：157 轮
- 平均上下文长度：32,721 tokens
- 每轮新增内容：429 tokens
- KV-Cache 命中率：98.7%
重点来了：每轮对话中，98.7% 的内容都已经在缓存中，只有 1.3% 需要重新计算。
二、核心问题：存储带宽瓶颈
2.1 先搞清楚 KV-Cache 是什么
KV-Cache = Key-Value Cache（键值缓存）。简单理解就是 LLM 处理时产生的"中间计算结果"，保存下来可以避免重复计算。
2.2 PD 分离架构
现代 LLM 推理采用 Prefill-Decode 分离架构：
┌─────────────────────────────────────────────────────────┐
│ PD 分离架构 │
├─────────────────────┬───────────────────────────────────┤
│ Prefill 引擎 (PE) │ Decode 引擎 (DE) │
│ 负责：处理输入提示 │ 负责：生成输出 tokens │
│ 计算密集型 │ 内存密集型 │
└─────────────────────┴───────────────────────────────────┘
- Prefill 引擎（PE）：处理输入提示，计算密集型
- Decode 引擎（DE）：生成输出 tokens，内存密集型
2.3 问题在哪
传统架构下，KV-Cache 加载路径是这样的：
┌──────────┐ 所有流量挤在这里 ┌──────────┐
│ 存储 │ ──────────────────────→ │ Prefill │
│ 系统 │ │ 引擎 │
└──────────┘ └──────────┘
↑ │
│ ↓
Decode 引擎完全闲置 计算后发送到 Decode 引擎
(存储带宽浪费) (参与生成)
问题本质：
- 所有 KV-Cache 都要从存储加载到 Prefill 引擎
- Decode 引擎的存储带宽完全浪费
- 导致 Prefill 端带宽饱和，成为系统瓶颈
2.4 为什么这个问题很严重
论文给出了几个关键原因：
- 缓存命中率极高：98.7% 的 tokens 需要从存储加载
- 硬件发展趋势不利：从 Ampere 到 Blackwell，I/O-计算比下降了 14.4 倍
- 负载严重失衡：一边饱和，一边闲置
三、解决方案：DualPath 双路径加载
3.1 核心思想
DualPath 的核心创新是双路径 KV-Cache 加载：
DualPath 双路径架构：
路径1 (传统)：存储 → Prefill 引擎（保留）
路径2 (创新)：存储 → Decode 引擎 → Prefill 引擎（新增）
↑ ↑
利用闲置的 通过高速网络
存储带宽 传输过来
3.2 打个比方
传统方式：
你住在 A 小区，需要去远处的仓库取货。路上非常堵。
DualPath 方式：
先让货车把货送到 B 小区的便利店（Decode 引擎），然后你从 B 小区取货。B 小区离你更近，而且货车走的是另一条路，完全不堵。
3.3 系统架构
┌─────────────────────────────────────────────────────────────────┐
│ DualPath 系统架构 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ 请求调度器 │ │ 流量管理器 │ │
│ │ (Scheduler) │ │ (Traffic) │ │
│ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │
│ └────────┬───────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────┐ │
│ │ 推理引擎池 │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Prefill 引擎 │ │ Decode 引擎 │ │ │
│ │ │ (PEs) │ │ (DEs) │ │ │
│ │ └──────┬──────┘ └──────┬──────┘ │ │
│ │ │ │ │ │
│ │ └────────┬──────────┘ │ │
│ │ ↓ │ │
│ │ RDMA 高速网络 │ │
│ └───────────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────┐ │
│ │ 分布式存储 (3FS) │ │
│ └───────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
系统主要包含三个组件：
- 推理引擎池：管理 GPU，分为 Prefill 引擎和 Decode 引擎
- 流量管理器：负责 H2D/D2H 复制、引擎间 KV-Cache 传输、存储读写
- 请求调度器：接收请求并动态分配到不同引擎和路径
3.4 关键技术细节
3.4.1 流量隔离
DualPath 使用 InfiniBand 虚拟通道实现流量隔离：
| 虚拟通道 | 带宽占比 | 用途 |
|---|---|---|
| 高优先级 VL | 99% | 模型推理通信 |
| 低优先级 VL | 1%+ | KV-Cache 传输 |
这样 KV-Cache 传输不会影响延迟敏感的推理通信。
3.4.2 CNIC 辅助的数据复制
传统方式（cudaMemcpyAsync）：5-7 微秒
DualPath 方式（RDMA Write）：~1 微秒
快了 5-7 倍。
为什么能这么快？因为 RDMA Write 只需要几个 mmio 写入操作，而 cudaMemcpyAsync 有额外的开销。
3.4.3 自适应请求调度
调度器会智能决定两件事：
- 每个请求走哪条路径（PE 路径还是 DE 路径）
- 如何平衡 Prefill 和 Decode 引擎的负载
核心思路是：优先选择负载低的引擎，同时保证存储 NIC 不会被压垮。
四、实验结果
4.1 实验设置
| 项目 | 配置 |
|---|---|
| GPU | NVIDIA Hopper × 8 |
| 计算网络 | 8× 400Gbps RDMA NIC |
| 存储网络 | 1× 400Gbps NIC (连接 3FS) |
| 测试模型 | DeepSeek-V3.2 (660B)、DeepSeek-27B、Qwen2.5-32B |
4.2 离线批处理推理
| 模型 | 吞吐量提升 | 相比 Oracle |
|---|---|---|
| DeepSeek-V3.2 (660B) | 1.87× | 1.05× |
| DeepSeek-27B | 1.78× | 1.09-1.85× |
| Qwen2.5-32B | 1.73× | - |
简单说，大模型提升更明显。DS 660B 能达到 Oracle（理论上限）的 95% 性能，说明 KV-Cache I/O 开销基本被消除了。
4.3 在线服务
| 模型 | 服务容量提升 | SLO 达标 |
|---|---|---|
| DeepSeek-27B | 1.67× | ✅ |
| DeepSeek-V3.2 (660B) | 2.25× | ✅ |
服务容量提升 2.25 倍，这意味着同等硬件下能服务更多用户。
4.4 各组件贡献（消融实验）
JCT (作业完成时间) 减少贡献：
调度算法贡献 ████████████████████ 45.62%
双路径加载贡献 ████████████████ 38.19%
分层预填充贡献 ███████ 17.21%
调度算法的贡献最大，说明好的资源调度对系统性能至关重要。
4.5 大规模扩展性
| 配置 | 吞吐量提升 |
|---|---|
| 2P4D → 48P96D | 22 倍 |
近乎完美的线性扩展。大规模部署时，调度器 CPU 使用率始终低于 10 核，不会成为瓶颈。
五、核心洞察
KV-Cache 加载不必以 Prefill 为中心；利用 Decode 引擎的带宽可以解决 Prefill 端的瓶颈。
这个观点简单但深刻：换个思路，把闲置资源用起来，问题就解决了。
对工程实践的启示
- 资源分离不等于资源浪费：PD 分离架构中，Decode 端的带宽不应该被忽视
- 网络隔离很重要：计算网络和存储网络分离避免互相干扰
- 调度算法是关键：好的调度可以减少 45% 的完成时间
适用场景
DualPath 特别适合：
- 多轮对话应用（AI 助手、客服机器人）
- Agent 应用（工具调用、任务规划）
- 长上下文场景
- 高并发在线服务
六、总结
论文贡献
- 问题识别：首次系统性地指出 Agentic LLM 工作负载的 I/O 瓶颈问题
- 解决方案：提出双路径 KV-Cache 加载架构
- 工程实现：完整的流量隔离、CNIC 辅助复制、自适应调度
- 效果验证：1.87× 离线吞吐量提升，1.96× 在线服务容量提升
关键技术点
| 技术 | 作用 |
|---|---|
| 双路径加载 | 利用 Decode 端闲置带宽 |
| 流量隔离 | 避免 KV-Cache 传输干扰推理 |
| CNIC 辅助复制 | 减少数据复制开销 |
| 自适应调度 | 动态平衡系统负载 |
参考资料
- 论文原文：DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference
- DeepSeek 官方博客
- NVIDIA InfiniBand QoS 文档
如果读完有任何想法，欢迎在评论区交流！
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
11
0- 0
已为社区贡献2条内容
所有评论(0)