DualPath架构突破LLM推理KV-Cache存储瓶颈

1. 项目背景与核心挑战

在大型语言模型（LLM）的多轮Agent推理场景中，KV-Cache的存储带宽瓶颈已成为制约系统性能的关键因素。DeepSeek团队最新提出的DualPath架构，通过创新的双路径加载机制，成功突破了这一技术瓶颈。根据实测数据，在DeepSeek-V3 660B模型上，该系统实现了离线推理吞吐量提升1.87倍，在线服务容量提升2.25倍的显著效果。

当前Agent推理面临三大核心挑战：

1. 硬件发展不匹配：从NVIDIA Ampere到Blackwell架构，I/O计算比下降了14.4倍，网络带宽和HBM容量增长远落后于GPU算力提升
2. 存储网络利用率失衡：在主流PD解耦架构中，KV-Cache加载压力集中在prefill端的存储网卡(SNIC)，而decode端的SNIC长期处于闲置状态
3. 细粒度数据传输开销：层式执行范式将KV-Cache分割为大量细粒度块，传统传输方式难以实现计算与传输的高效重叠

关键指标对比：在典型配置(g=8,s=1)下，DualPath的存储带宽利用率从单节点的400Gbps提升到全集群的3.2Tbps，实现了真正的线性扩展能力。

2. DualPath架构设计原理

2.1 系统整体架构

DualPath系统由三个核心组件构成：

1. 推理引擎集群：

   • Prefill引擎(PE)：专用于prompt处理
   • Decode引擎(DE)：专用于token生成
   • 每个GPU对应一个独立引擎实例

2. 流量管理器：

   • 采用CNIC中心化设计
   • 统一管理三类数据传输：
     • 主机-设备内存拷贝(H2D/D2H)
     • PE与DE间的KV-Cache传输
     • 通过存储网卡的持久化存储读写

3. 动态请求调度器：

   • 中央调度器接收客户端请求
   • 实时监控各节点负载状态
   • 动态选择最优数据路径(PE路径/DE路径)

2.2 双路径加载机制

创新性地引入两种KV-Cache加载路径：

PE读取路径（传统方式）：

1. KV-Cache直接从持久存储读入PE缓冲区
2. 计算前传输到PE HBM
3. 计算结果传回DE缓冲区形成完整prompt KV-Cache

DE读取路径（创新点）：

1. KV-Cache先读入DE缓冲区
2. PE计算时从DE缓冲区读取对应层的KV-Cache
3. 仅将新生成token的KV-Cache传回DE缓冲区

两种路径的关键差异在于：

• PE路径：直接加载→计算→传输
• DE路径：间接加载→传输→计算

通过动态负载均衡算法，系统可将存储I/O压力均匀分布到所有节点的SNIC上，实现全局带宽池化。

3. 关键技术实现细节

3.1 CNIC中心化流量管理

为解决KV-Cache传输与模型推理通信的带宽竞争问题，DualPath采用创新性的CNIC中心化方案：

1. 流量隔离机制：

   • 为InfiniBand网络配置两个虚拟通道(VL)
   • 模型推理通信：高优先级VL（占用99%带宽）
   • KV-Cache传输：低优先级VL（占用1%带宽）

2. CNIC辅助拷贝：

   • 放弃传统CUDA拷贝引擎
   • 改用RDMA Write请求执行本地H2D拷贝
   • 实测单次操作延迟从5-7μs降至1μs

3. 门铃批处理优化：

   • 批量提交RDMA工作请求
   • 通过mmio写操作直接操作NIC寄存器
   • 显著降低小数据块传输开销

3.2 自适应请求调度算法

3.2.1 引擎间调度

采用两级分组调度策略：

PE调度阶段：

1. 根据节点磁盘队列长度和未完成token数，将PE分为三类：

   • 过载引擎（tok_e > β）
   • 轻载节点（read_q ≤ α 且 tok_e ≤ β）
   • 正常节点（read_q > α 且 tok_e ≤ β）

2. 优先选择轻载节点中的最小tok_e引擎

3. 次选正常节点中的最小tok_e引擎

DE调度阶段：

1. 全局队列→组私有队列两级分发
2. 组间调度：选择总tok_e最小的组
3. 组内调度：
   • 计算剩余HBM总量
   • 设置高token阈值Z=1.05×平均负载
   • 优先选择非高负载且seq_e最小的DE

3.2.2 引擎内调度

针对PE特有的计算负载均衡问题：

1. 层时间预估：

   • 基于(cached, bsz)二元组预测计算量
   • 通过预定义的性能模型转换为时延估计

2. 计算配额策略：

   • FIFO顺序打包请求
   • 当预测时延超过配额上限时：
     • 对bsz进行二分搜索
     • 找到满足剩余配额的最大bsz'
     • 执行分块prefill处理

4. 性能评估与生产部署

4.1 离线推理性能

在DeepSeek 660B模型上的测试结果显示：

关键发现：

1. 上下文长度越长，性能优势越明显
2. 短append/生成长度场景下优势更突出
3. 不同P/D比例下均保持稳定加速

4.2 在线服务能力

在线服务SLO指标：

• TTFT ≤ 4秒
• TPOT ≤ 50ms

实测结果对比：

4.3 大规模生产部署

在1152 GPU集群上的表现：

1. 离线推理：

   • 48P96D配置处理48K agents
   • 完成时间3201s（相比2P4D配置仅增加1%）
   • 实现近线性扩展

2. 在线服务：

   • 44P88D配置支持8.8 APS
   • 平均TTFT 1.847s
   • 调度器CPU占用<10核

5. 实践经验与优化建议

5.1 部署配置建议

1. 硬件选型：

   • 每个节点配置8 GPU+8 CNIC+1 SNIC
   • 存储网络与计算网络物理隔离
   • 推荐PCIe拓扑：GPU-NIC直连同一交换机

2. 参数调优：

   python复制# 典型调优参数范围
   config = {
       'alpha': 300-500,  # 短队列阈值(tokens)
       'beta': 800-1200,  # 负载均衡阈值(tokens)
       'compute_quota': '15-25ms',  # 计算配额
       'vl_ratio': [99, 1]  # 虚拟通道带宽比
   }
   

3. 监控指标：

   • 存储SNIC利用率差异(<15%)
   • 注意力层执行时间方差(<6%)
   • KV-Cache传输队列深度

5.2 常见问题排查

1. 性能不达预期：

   • 检查PCIe拓扑是否合规
   • 验证VL/DSCP配置是否正确
   • 监控CNIC带宽利用率

2. OOM异常：

   • 调整DE缓冲区大小
   • 检查HBM碎片化情况
   • 优化调度器的token计数逻辑

3. 延迟波动：

   • 检查计算配额设置
   • 分析RDMA门铃批处理效率
   • 验证负载均衡算法执行情况

6. 技术演进方向

1. 自适应P/D比例：

   • 在线调整prefill/decode资源配比
   • 基于工作负载特征动态伸缩

2. 混合缓存策略：

   • 结合DRAM缓存池设计
   • 智能预取热点KV-Cache

3. 量化传输优化：

   • 层粒度混合精度量化
   • 无损压缩传输协议

在实际生产环境中，我们发现当工作集超过681GB时，系统的内存命中率会显著下降。这提示我们需要在更大规模集群上验证系统的极限能力，这也是团队下一步的重点研究方向。