突破Agentic LLM推理的存储带宽瓶颈：DualPath系统设计
1. 项目概述：突破Agentic LLM推理的存储带宽瓶颈
在当今AI领域，大型语言模型（LLM）正从单轮对话系统快速演进为具备多轮交互能力的智能体（Agentic）系统。这类系统能够自主规划、调用工具并通过数十甚至上百轮的交互解决复杂任务。然而，这种演进带来了一个关键的技术挑战：随着交互轮次的增加，上下文长度呈指数级增长，导致KV-Cache（键值缓存）的存储I/O性能成为系统瓶颈。
传统解耦架构（Prefill-Decode Disaggregation）中，KV-Cache从外部存储加载到预填充引擎时，预填充侧的存储网络带宽往往成为系统吞吐量的限制因素。令人惊讶的是，在这种架构下，解码引擎的存储带宽却长期处于闲置状态。这种资源利用的不平衡直接制约了整体系统性能，在代码助手、自主任务代理等需要长上下文交互的场景中尤为明显。
2. 核心问题解析：KV-Cache加载的瓶颈本质
2.1 Agentic工作负载的I/O特性
多轮Agentic工作负载展现出三个显著特征：
- 高KV-Cache命中率（通常≥95%）：每轮交互仅需处理少量新增token，绝大多数上下文token可复用之前轮次的KV-Cache
- 短追加长上下文模式：平均追加长度仅429token，而上下文长度可达32.7k token
- 层间强局部性：预填充计算具有明显的层间局部性，每层只需处理本层的KV-Cache
这些特性使得系统性能从计算密集型转变为I/O密集型。以DeepSeek-V3.2 660B模型为例，其cache-compute ratio达到22GB/PFLOP，意味着每完成1PFLOP的计算就需要加载22GB的KV-Cache数据。
2.2 硬件发展趋势的错配
现代GPU的计算能力增长速度远超I/O子系统：
- 从NVIDIA Ampere到Blackwell架构，I/O-compute比率下降14.4倍
- 存储网络带宽增长滞后于GPU FLOPS提升
- HBM容量限制导致批处理规模受限
这种错配使得KV-Cache加载速度无法匹配GPU的计算能力，导致GPU利用率低下（通常仅40%左右）。
2.3 传统架构的带宽利用失衡
现有PD解耦架构存在严重的存储网络利用不均衡：
- 预填充引擎的存储NIC（SNIC）带宽持续饱和
- 解码引擎的SNIC带宽大量闲置
- 计算网络（CNIC）带宽呈现间歇性使用模式
这种不对称性使得系统无法充分利用已有的硬件资源，造成整体性能受限。
3. DualPath系统设计：双路径KV-Cache加载
3.1 核心创新：双路径加载机制
DualPath系统突破性地引入双路径KV-Cache加载架构：
- 传统路径：存储→预填充引擎（Storage-to-Prefill）
- 创新路径：存储→解码引擎→预填充引擎（Storage-to-Decode-to-Prefill）
这种设计通过RDMA over Compute Network将解码引擎的闲置SNIC带宽转化为预填充加速资源，实现了存储带宽的全局负载均衡。
3.2 系统架构组件
DualPath包含三个关键组件：
推理引擎集群：
- 预填充引擎（PE）：专注处理prompt预填充
- 解码引擎（DE）：负责自回归解码
- 每引擎管理一个GPU，配备专用CNIC和SNIC
流量管理器：
- 采用CNIC-centric设计，确保KV-Cache传输不影响模型推理通信
- 支持三种数据传输模式：
- Host-Device内存拷贝（H2D/D2H）
- PE与DE间的KV-Cache传输
- 通过SNIC的存储读写
请求调度器：
- 动态分配请求到(PE, DE)对
- 智能选择KV-Cache加载路径
- 实时平衡计算与网络资源
3.3 双路径数据流详解
预填充PE读取路径（图4a）：
- KV-Cache从持久化存储读入PE缓冲区
- 在注意力层计算前，该层KV-Cache传输到PE HBM
- 计算新增token的KV-Cache
- 完整KV-Cache传输到DE缓冲区
- 重复n_layer次后开始解码
预填充DE读取路径（图4b）：
- KV-Cache直接读入DE缓冲区
- 预填充时按层从DE缓冲区读取KV-Cache
- 仅新增token的KV-Cache回传DE缓冲区
- 同样重复n_layer次
解码阶段：
- DE分配HBM并执行H2D传输
- 立即持久化完整token块（如64token）
- 采用两种块布局：
- Full Block：包含所有层
- Layer Block：单层专用
4. 关键技术实现与优化
4.1 CNIC中心化流量管理
现代LLM推理系统面临的关键挑战是如何在KV-Cache传输与模型推理通信间实现隔离。DualPath采用创新性的CNIC-centric设计：
流量隔离机制
- 利用InfiniBand虚拟通道（VL）实现QoS：
- 高优先级VL（99%带宽）：模型推理通信
- 低优先级VL（1%带宽）：KV-Cache传输
- 类似机制可扩展到RoCE（通过TC/DSCP）和Ultra Ethernet
CNIC辅助的KV-Cache拷贝
相比传统GPUDirect Storage和CUDA拷贝引擎，DualPath采用：
- KV-Cache先读入主机DRAM
- 通过RDMA Write请求提交到配对CNIC
- CNIC执行本地H2D拷贝
- 写回过程对称进行
实测表明，该方案：
- 单次RDMA Write延迟仅1μs（cudaMemcpyAsync需5-7μs）
- 支持门铃批处理进一步降低开销
- 完美隔离高低优先级流量
4.2 自适应请求调度算法
DualPath的调度器需同时平衡两个维度：
- NIC流量分布
- GPU利用率均衡
引擎间调度
- 将引擎分组，仅Leader Engine与调度器交互
- 每个引擎e报告三个关键指标：
- seq_e：未完成请求数
- tok_e：对应token总数
- read_qn(e)：节点磁盘读取队列长度
- 使用token计数作为负载代理指标
动态路径选择策略
调度器根据实时负载情况动态选择：
- PE路径：当DE集群负载较高时
- DE路径：当PE SNIC带宽饱和时
- 混合路径：根据各节点SNIC利用率弹性分配
5. 性能评估与生产实践
5.1 实验设置
- 硬件环境：NVIDIA DGX SuperPOD集群
- 每节点8个Hopper GPU
- 400Gbps CNIC（计算网络）
- 400Gbps SNIC（存储网络）
- 工作负载：真实Agentic轨迹（平均157轮，32.7k上下文）
- 对比基线：传统PD解耦架构
5.2 关键性能指标
| 指标 | 传统架构 | DualPath | 提升幅度 |
|---|---|---|---|
| 离线推理吞吐量 | 1x | 1.87x | 87% |
| 在线服务吞吐量 | 1x | 1.96x | 96% |
| 首token延迟 | 基准值 | -12% | 显著改善 |
| GPU利用率 | 40% | 80% | 2倍提升 |
5.3 生产部署经验
在实际部署中，我们总结了以下最佳实践：
配置优化
- PCIe拓扑确保GPU-NIC位于同一交换机下
- 存储读取带宽完全利用
- 计算网络无拥塞
- 根据公式(9)合理设置P/D比例
避坑指南
DRAM缓冲区大小：
- PE/DE缓冲区过小会导致频繁换入换出
- 建议占总DRAM 15-20%
层间传输优化：
- 采用异步流水线重叠计算与传输
- 批量处理小数据块（≥64KB）
RDMA参数调优：
# 最佳实践配置 ibv_rc_pingpong -d mlx5_0 -g 0 -i 1 -s 4096 -n 1000监控指标：
- 各SNIC利用率差异应<15%
- CNIC高优先级VL利用率应>95%
- 各GPU计算利用率波动应<10%
6. 应用场景与未来展望
6.1 典型应用场景
DualPath特别适合以下Agentic应用：
- 代码助手：如GitHub Copilot等长会话场景
- 自主任务代理：需多轮工具调用的复杂任务
- RL训练rollout阶段：DRAM受限的大规模轨迹生成
6.2 扩展方向
基于当前架构，我们正在探索：
分层存储集成：
- 热KV-Cache存于DRAM
- 温数据存于NVMe
- 冷数据存于SSD集群
自适应块大小：
def adaptive_block_size(context_len): if context_len < 16_384: return 64 elif context_len < 65_536: return 128 else: return 256预测性预加载：
- 基于会话模式预测下一轮可能需要的KV-Cache
- 在解码阶段后台预加载
在实际部署中，我们发现当上下文长度超过100k token时，KV-Cache的压缩效率会显著影响系统性能。通过引入稀疏注意力与量化技术（如FP8），可将KV-Cache体积减少50%以上，进一步释放带宽压力。