DualPath：破解Agentic LLM推理中的存储带宽瓶颈

副标题：一种通过双路径KV-Cache加载技术提升多轮对话AI系统性能的新架构

引言：当AI代理成为主流，推理架构面临新挑战

大型语言模型（LLMs）正在从简单的单轮聊天机器人进化为能够自主规划、调用工具、通过多轮交互解决实际任务的智能代理系统。无论是代码助手还是自动化任务代理，这些应用都依赖于多轮LLM推理——一个长会话过程，其中上下文随时间不断累积。

这种转变带来了一个根本性的技术挑战：Agentic工作负载变得极度I/O密集。想象一下，一个AI代理在与外部环境（如浏览器、Python解释器）交互时，可能经历数十甚至数百轮对话。虽然每轮的工具调用或反馈很短（通常只有几百个token），但上下文长度可以增长到极端程度——甚至达到百万token级别。

更关键的是，由于大多数上下文（通常超过95%的token）在轮次间被重用，KV-Cache的命中率极高。这意味着KV-Cache加载效率，而非纯计算能力，成为主导系统性能的关键因素。

本文将深入介绍DualPath——一种突破性的推理系统架构，它通过创新的双路径KV-Cache加载机制，解决了现代AI数据中心中的存储带宽瓶颈问题。

核心问题：为什么现有的PD分离架构会遇到瓶颈？

什么是PD分离架构？

在现代LLM推理系统中，Prefill-Decode（PD）分离已成为事实标准架构。这种设计将推理过程分为两个阶段：

阶段	名称	特点	负责引擎
第一阶段	Prefill（预填充）	计算密集型、可批处理	Prefill引擎（PE）
第二阶段	Decode（解码）	内存受限、延迟敏感	Decode引擎（DE）

Prefill阶段：处理输入prompt，计算并生成KV-Cache。这个阶段需要大量计算，但可以高效批处理。

Decode阶段：基于KV-Cache自回归地生成token。这个阶段对延迟极其敏感，因为用户需要实时看到生成的内容。

PD分离的优势在于减少两阶段间的干扰，允许各自采用针对性的优化策略和硬件配置。

瓶颈在哪里？

在标准的PD分离架构中，存在一个根本性的效率问题：

┌─────────────────────────────────────────┐
│  传统架构的带宽利用情况                  │
├─────────────────────────────────────────┤
│  Prefill引擎（PE）                       │
│  ├─ 计算NIC：40%利用率                   │
│  ├─ 存储NIC：100%利用率 ← 瓶颈！         │
│  └─ GPU：部分空闲，等待数据              │
├─────────────────────────────────────────┤
│  Decode引擎（DE）                        │
│  ├─ 计算NIC：低利用率                    │
│  ├─ 存储NIC：几乎空闲 ← 浪费！           │
│  └─ GPU：活跃，但存储带宽未利用          │
└─────────────────────────────────────────┘

问题的本质：Prefill引擎必须从远程存储加载大量KV-Cache，导致其存储网络带宽（SNIC）持续饱和；而Decode引擎的存储NIC却基本闲置。这种不对称的带宽利用严重制约了整个系统的吞吐量。

为什么不能简单地给Prefill引擎增加更多带宽？在通用集群中，这不仅成本高昂，而且往往不现实。因此，更优的方案是利用所有引擎的可用I/O带宽，而不是让Prefill引擎独自承担所有负载。

DualPath的核心创新：双路径KV-Cache加载

什么是双路径加载？

DualPath的核心洞察是：KV-Cache加载不必以Prefill为中心。传统系统总是直接将KV-Cache从存储加载到Prefill引擎，这无法利用Decode引擎的远程存储带宽。

DualPath引入了第二条路径——除了传统的存储→Prefill路径外，还允许KV-Cache先加载到Decode引擎，然后通过高性能RDMA网络（计算网络）传输到Prefill引擎。

┌─────────────────────────────────────────┐
│  DualPath架构的带宽利用情况              │
├─────────────────────────────────────────┤
│  Prefill引擎（PE）                       │
│  ├─ 计算NIC：80%利用率（RDMA传输）       │
│  ├─ 存储NIC：100%利用率                  │
│  └─ GPU：更高利用率，更少等待            │
├─────────────────────────────────────────┤
│  Decode引擎（DE）                        │
│  ├─ 计算NIC：活跃（RDMA传输）            │
│  ├─ 存储NIC：100%利用率 ← 充分利用！     │
│  └─ GPU：正常解码工作                    │
└─────────────────────────────────────────┘

通过动态选择这两条路径，DualPath重新分配了网络负载，缓解了Prefill侧的带宽饱和问题。

两条路径的数据流详解

DualPath为每个引擎分配了少量DRAM作为缓冲区（PE Buffer和DE Buffer），支持两种读取路径：

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

存储→PE Buffer：KV-Cache从持久存储读入Prefill引擎的缓冲区
PE Buffer→PE HBM：在注意力层计算前，将该层KV-Cache传入GPU高带宽内存
PE HBM→DE Buffer：计算完成后，KV-Cache传入Decode引擎缓冲区
重复：上述过程重复n_layer次，与计算重叠进行

路径二：DE读取路径（创新方式）

存储→DE Buffer：KV-Cache首先读入Decode引擎的缓冲区
DE Buffer→PE HBM：Prefill过程中，通过RDMA从DE Buffer读取对应层的KV-Cache
PE HBM→DE Buffer：层计算完成后，仅将miss token的KV-Cache传回DE Buffer与hit token合并
重复：同样重复n_layer次

为什么这种设计不会引入新的瓶颈？

你可能会担心：增加了一条数据路径，会不会导致计算网络拥塞？或者DRAM带宽成为新瓶颈？

DualPath的理论分析表明，在合理的P/D（Prefill/Decode）比例下，系统可以实现无瓶颈运行。关键条件包括：

计算NIC带宽：通过精细的流量管理，确保KV-Cache传输不会干扰延迟敏感的模型执行通信
DRAM压力：通过分层块（Layer Block）和全块（Full Block）的混合布局，优化内存访问模式
PCIe带宽：采用CNIC中心化的数据传输方式，统一管理所有GPU PCIe流量

对于典型的8 GPU节点配置（g=8，存储带宽比例s=1），无瓶颈的P/D比例范围是1/7到7/2，覆盖了绝大多数实际部署场景。

技术实现：三大核心组件

1. CNIC中心化流量管理器

现代LLM推理使用多种先进数据传输技术，如GPUDirect Storage和CUDA拷贝引擎。然而，这些技术存在一个共同问题：它们无法将KV-Cache流量与延迟敏感的集合通信隔离。

为什么这很重要？在模型执行过程中，集合通信（如专家并行中的AllToAll、张量并行中的ReduceScatter/AllGather）以亚毫秒级的突发方式发生。如果KV-Cache传输干扰了这些关键通信，会严重降低推理延迟。

DualPath的解决方案：采用**CNIC中心化（Compute NIC-Centric）**的数据传输方式。所有进出GPU的数据，包括本地H2D/D2H拷贝，都必须通过GPU配对的计算NIC，使用GPUDirect RDMA数据路径。

具体实现：

对于InfiniBand网络：利用虚拟通道（Virtual Lanes, VL）进行流量隔离
- 高优先级VL：专门用于模型推理通信（保留99%带宽）
- 低优先级VL：用于KV-Cache传输（防止饥饿）
对于RoCE网络：使用DSCP标记和流量类（TC）实现类似隔离

意外收获：CNIC辅助的H2D/D2H在处理大量小数据块时，性能优于CUDA拷贝引擎。单次RDMA写操作仅需约1微秒，而cudaMemcpyAsync有5-7微秒的开销。

2. 自适应请求调度器

DualPath需要实时决定：每个请求应该使用哪条路径？这涉及两个层面的调度：

引擎间调度（Inter-Engine Scheduling）

引擎被组织成组，只有每组的Leader Engine与中央调度器交互。调度时考虑三个关键指标：

seq_e：分配给引擎但未完成的请求数
tok_e：这些请求的总token数
read_q_n(e)：引擎所在节点的磁盘读取队列长度

Prefill引擎调度策略：

过载引擎（tok_e > β）：不分配新请求
短队列引擎（read_q_n(e) ≤ α且tok_e ≤ β）：优先分配，防止存储NIC欠载
长队列引擎（read_q_n(e) > α且tok_e ≤ β）：次优先分配

Decode引擎调度策略：

第一阶段：跨组平衡，将请求分配给总tok_e最小的组
第二阶段：组内平衡，考虑HBM容量和token数量，避免碎片化

KV-Cache读取任务调度：在选定PE和DE后，选择读取队列更短的一侧执行存储读取。未来工作考虑将请求拆分，从两侧并行读取。

引擎内调度（Intra-Engine Scheduling）

仅Prefill引擎需要引擎内调度。由于数据并行（DP）配置中每个GPU服务不同请求集，工作负载可能不平衡，导致GPU在同步点产生空闲气泡。

解决方案：基于计算配额的批处理选择

使用FIFO顺序打包请求
每个请求描述为(cached, bsz)对：已缓存token数、本轮需计算token数
预测注意力层执行时间，确保不超过预设的计算配额（如300ms）
如添加请求会超配额，对该请求执行分块预填充（Chunked Prefill）

3. 分层KV-Cache块布局

Layer-wise预填充将KV-Cache块大小减少到原来的1/layer，块数量增加到layer倍。这对传输和存储性能构成挑战。

DualPath的双块设计：

块类型	形状	用途
Layer Block	`[1, tokens, bytes]`	存储单层KV-Cache，用于层间流传输
Full Block	`[layer, tokens, bytes]`	存储完整层KV-Cache，用于存储交互

优势：

与存储的所有交互使用Full Block，优化存储性能
层间流传输使用Layer Block，减少内存占用
无需手动内存布局转换，简单拼接Layer Block即可得到Full Block

KV-Cache在分布式存储中使用Trie结构组织，每个树节点对应一个Full Block。

性能评估：真实场景下的显著提升

实验设置

测试平台：

GPU集群：NVIDIA Hopper GPU，InfiniBand互联
节点配置：每节点8 GPU，8×400Gbps计算NIC + 1×400Gbps存储NIC
存储后端：3FS（无内部DRAM缓存，可饱和存储NIC带宽）

评估模型：

DeepSeek-V3.2 660B（MoE，稀疏注意力）
DeepSeek 27B（内部实验模型，660B的缩小版）
Qwen2.5-32B（Dense模型，GQA）

数据集：从生产级Agentic RL训练工作负载收集的三个轨迹数据集

数据集	最大长度	平均轮次	平均追加长度	平均生成长度	平均总长度	平均上下文长度
32K	32K	60	608	148	28,639	17,183
48K	48K	106	474	172	42,607	25,120
64K	64K	157	429	176	55,958	32,721

对比基线：

Basic：未修改的内部推理框架
SGL(MC)：SGLang + Mooncake + 3FS（部分配置因不支持而N/A）
Oracle：理论上限，绕过所有磁盘读取和传输

离线批处理推理结果

在RL训练的回滚（rollout）阶段场景中，所有代理同时开始推理，测量作业完成时间（JCT）。

关键发现：

DeepSeek 660B：DualPath相比Basic提升最高1.87倍，性能接近Oracle，表明KV-Cache I/O瓶颈被基本消除
DeepSeek 27B：提升最高1.78倍，但由于1P1D配置存储带宽有限，仍比Oracle慢1.09-1.85倍
Qwen 32B：趋势与DeepSeek模型一致
规模效应：DualPath在更大batch size和更长上下文长度下收益更明显

P/D比例影响：

在1P1D、2P1D、1P2D配置下，DualPath平均提速1.64倍（最高2.46倍）
有趣的现象：Basic 1P1D ≈ Basic 1P2D，DualPath 1P1D ≈ Basic 2P1D，DualPath 2P1D ≈ DualPath 1P2D
这证实了存储带宽是Agentic推理的主导瓶颈，而非计算能力

追加长度和生成长度的影响：

追加长度增加时，Basic性能逐渐接近DualPath（计算压力增大，I/O压力相对减小）
生成长度增加时，由于更大的Prefill间隔时间，KV-Cache加载压力降低
在典型Agentic场景（短追加、短生成）下，DualPath保持1.82-1.99倍优势

在线服务结果

在在线服务场景中，代理按泊松过程到达，测量延迟指标：

TTFT（Time To First Token）：首token延迟
TTST（Time To Second Token）：次token延迟
TPOT（Time Per Output Token）：每输出token时间

服务水平目标（SLO）：TTFT ≤ 4秒，TPOT ≤ 50毫秒

关键发现：

吞吐量提升：DualPath的代理每秒处理能力（APS）相比Basic提升1.67倍（27B）到2.25倍（660B）
延迟特性：TTST与Basic相当，TPOT未增加，证明DualPath未引入额外解码开销
TTFT稳定性：DualPath在不同到达率下保持稳定的TTFT组件，而Basic的队列时间因存储带宽不足而急剧增长

消融研究

逐步添加技术组件，量化各自贡献（64K上下文，1024/2048代理）：

配置	相比Basic的JCT降低
Basic + Layerwise Prefill	17.21%
+ Dual-path Loading	额外38.19%（累计55.4%）
+ Scheduling Algorithm	额外45.62%（累计最优）

负载均衡效果：

存储NIC流量均衡：从1.53（轮询调度）改善到1.18（Max/Avg比率，1.0为完美均衡）
注意力层执行时间均衡：任务前5%阶段保持Max/Avg比率低至1.06，显著减少GPU空闲气泡

大规模扩展性

在多达1,152 GPU的大规模集群上验证：

场景	配置	结果
离线推理	2P4D (2K代理) → 48P96D (48K代理)	JCT从3,167s到3,201s，接近线性扩展
在线服务	44P88D	吞吐量22倍提升（0.4→8.8 APS），延迟保持稳定

调度器CPU使用率始终低于10核，证明其不会成为瓶颈。

深入理解：为什么DualPath有效？

硬件趋势与Workload的错配

从NVIDIA Ampere到Blackwell架构，I/O计算比例下降了14.4倍。这意味着：

GPU计算能力（FLOPS）快速增长
网络带宽和HBM容量增长相对滞后
在Agentic工作负载下，我们更早遇到内存墙和通信墙

小HBM容量限制了token批处理大小，无法充分利用Tensor Core等计算单元。低NIC带宽限制了KV-Cache加载速度，导致GPU空闲等待。

Cache-Compute Ratio的重要性

定义：KV-Cache加载量与所需计算量的比值（GB/PFLOP）

模型	Cache-Compute Ratio (16K-64K上下文)
Qwen2.5-32B (FP16)	117-267
GPT-OSS-120B	47-95
Qwen3-235B-A22B	39-60
DeepSeek-V3.2 660B	13-36
DeepSeek-V3 660B	4.8-5.8

即使是经过MLA优化的DeepSeek-V3.2，在32K上下文、429 token追加长度场景下，cache-compute ratio仍达约22GB/PFLOP，对存储带宽构成显著压力。对于KV-Cache更大的模型，情况更为严峻。

现代AI数据中心架构的约束

标准NVIDIA DGX SuperPOD的设计原则：

计算网络（东-西向）：高速NVLink + 400Gbps计算NIC，用于GPU间通信
存储网络（南-北向）：独立400Gbps存储NIC，用于数据集、检查点、KV-Cache访问
关键隔离：计算网络和存储网络物理隔离，防止相互干扰

DualPath的创新在于：在不破坏这种隔离的前提下，通过计算网络传输KV-Cache，从而聚合所有节点的存储带宽。

实际部署考虑

适用场景

DualPath特别适合以下场景：

Agentic RL训练：回滚阶段需要处理大量多步代理轨迹，DRAM被训练状态占用，必须依赖外部存储
长上下文在线服务：多轮对话应用，上下文累积到极端长度
高KV-Cache命中率工作负载：短追加、多轮次交互模式

配置建议

P/D比例选择：

根据理论分析，确保P/D比例在合理范围内（如g=8,s=1时为1/7到7/2）
实际部署建议通过小规模实验确定最优比例

DRAM分配：

DeepSeek模型：每节点80GB
Qwen等较大KV-Cache模型：每节点320GB
相比纯DRAM缓存方案（如Mooncake需要1.5TB/节点），大幅降低内存成本

流量隔离配置（InfiniBand示例）：

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

局限性与未来工作

动态适应性：当前工作负载高度动态（如RL训练前半段Prefill压力显著高于后半段），需要更灵活的并行策略和P/D比例在线调整机制
调度优化：大规模部署下，仍有空间降低TTFT的尾部延迟
拆分读取：当前实现选择单侧读取，未来可探索将请求拆分到两侧并行读取
工作集管理：在线场景下，随着到达率和JCT增加，KV-Cache工作集可能超出内存，需要更智能的缓存策略

常见问题解答（FAQ）

Q1: DualPath与Mooncake等分布式内存缓存方案有什么区别？

A: Mooncake构建分布式DRAM池缓存KV-Cache，通过亲和性感知调度最大化命中率。这在内存充足场景下效果很好，但有两个局限：

内存受限场景（如RL训练回滚阶段，DRAM被训练状态占用）无法使用
超大工作集场景（在线服务）成本高昂，因为DRAM比SSD贵得多

DualPath直接针对存储后端，平衡所有存储NIC的流量，大幅减少DRAM使用而不损害性能。两者可以结合使用，但增益有限。

Q2: 为什么不用GPUDirect Storage直接读取KV-Cache到GPU？

A: GPUDirect Storage确实可以直接从存储读取到GPU HBM，但它无法隔离KV-Cache流量与延迟敏感的模型执行通信。在Agentic推理中，集合通信（如AllToAll）的延迟至关重要。CNIC中心化的方式虽然看似绕路，但是目前唯一实用的方法确保KV-Cache加载不降低关键模型执行性能。

Q3: DualPath会增加解码阶段的延迟吗？

A: 不会。实验数据显示，DualPath的TPOT（每输出token时间）与Baseline相当，TTST（次token时间）也无显著差异。这是因为：

计算网络的QoS机制确保KV-Cache传输使用空闲带宽
DE Buffer设计优化了数据传输路径
解码阶段的计算和通信模式未受干扰

Q4: 如何决定使用PE读取路径还是DE读取路径？

A: 调度器基于实时负载信息动态决定：

比较Prefill引擎和Decode引擎所在节点的存储读取队列长度
选择队列更短的一侧执行存储读取
同时考虑GPU负载、token数量、HBM容量等多维度因素

Q5: Layer-wise预填充是否必须？对性能有何影响？

A: Layer-wise预填充是DualPath的重要基础，它解决了长上下文预填充的HBM容量瓶颈。通过每层只加载当前层所需的KV-Cache，有效批处理大小（以token计）可提升约layer倍。消融研究显示，仅添加layer-wise预填充就可降低17.21%的JCT。

Q6: DualPath支持哪些网络类型？

A: 虽然实验在InfiniBand上进行，但设计原则适用于：

InfiniBand：使用Virtual Lanes（VL）进行QoS隔离
RoCE：使用DSCP和Traffic Class（TC）标记
新兴技术：UnifiedBus、Ultra Ethernet等融合QoS机制的技术

Q7: 对于小模型（如27B），DualPath是否同样有效？

A: 有效，但提升幅度受存储带宽限制。在小模型1P1D配置下，由于总存储带宽有限，DualPath仍比Oracle慢1.09-1.85倍。建议通过增加节点数或优化P/D比例来释放更大潜力。

总结

DualPath通过重新思考PD分离架构中的KV-Cache加载方式，解决了Agentic LLM推理中的核心瓶颈。其关键创新包括：

双路径加载架构：打破Prefill-centric的局限，充分利用Decode引擎的闲置存储带宽
CNIC中心化流量管理：在确保延迟敏感通信不受影响的前提下， opportunistically利用计算网络空闲带宽
自适应调度算法：动态平衡计算和网络资源，实现全局最优

在真实Agentic工作负载下，DualPath实现了最高1.87倍的离线推理吞吐量提升和平均1.96倍的在线服务吞吐量提升，同时保持延迟指标稳定。这一架构为下一代长上下文、多轮交互AI应用的高效部署提供了坚实基础。

参考信息

本文基于以下研究论文：

DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference
作者：Yongtong Wu, Shaoyuan Chen, Yinmin Zhong 等（北京大学、清华大学、DeepSeek-AI）
发表：arXiv:2602.21548v2 [cs.DC], 2026年2月

相关技术：

PD分离架构：Splitwise, DistServe
Layer-wise预填充：LayerKV, PrefillOnly
分布式KV-Cache：Mooncake, TokenLake
高效注意力内核：FlashMLA, FlashInfer
专家并行通信：DeepEP

DualPath技术揭秘：如何破解AI多轮对话的存储带宽死局，让大模型推理提速187%？