一、引言
没等来 DeepSeek V4，却先等来了 DualPath。虽然它在算法层面并没有带来特别显著的创新，但从工程实践的角度看，依然是一项非常值得关注的工作。业内已经有不少关于 DualPath 的介绍，不过按照笔者的一贯习惯，对于这类具有较强启发性的技术方案，还是希望进行一次较为系统的解读。
对应的论文：[2602.21548] DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference
DeepSeek 的相关文章可以参考：
其他相关文章可以参考：
二、摘要
多轮、Agentic LLM Inference 的性能越来越受 KV-Cache 存储 I/O 主导，而非算力主导。在主流 PD 分离架构中，从外部 Storage 加载海量 KV-Cache 会产生根本性失衡：Prefill Engine 的 Storage NIC 带宽饱和，而 Decoding Engine 的 Storage NIC 却处于闲置状态。这种不对称性严重制约了系统整体吞吐量。
为此，DeepSeek 提出 DualPath Inference 系统，通过引入双路径 KV-Cache 加载机制突破上述瓶颈。在传统 Storage-to-Prefill 路径之外，额外实现了 Storage-to-Decoding 路径，将 KV-Cache 加载到 Decoding Engine 后，通过后端计算网络的 RDMA 技术高效传输到 Prefill Engine。该系统融合了两大创新：
优化数据路径：该路径天然可以规避网络拥塞，且不对延迟敏感的模型 Forward 通信产生干扰。
全局调度器：动态平衡 Prefill Engine 和 Decoding Engine 的负载分配。
基于三种模型在真实 Agentic 工作负载下的评估表明，DualPath 在自研的推理系统中将 Offline Batch Inference 吞吐提升 1.87x；在满足 SLO 的前提下，Online Serving 吞吐平均提升高达 1.96x。
三、背景
3.1 标准 DGX Superpod 集群
3.1.1 DGX H100 System
如下图所示为一个 DGX H100 System（具体可以参考 Introduction to the NVIDIA DGX H100 System [2]），其包含：
8 个 H100 GPU，每个 GPU 900 GB/s NVLink 带宽。
总共 900*8=7.2TB/s NVSwitch 带宽，80*8=640GB HBM3 显存。
8 个 400 Gbps 的 ConnectX-7计算网卡，提供 8*400 Gbps 带宽（4 x OSFP ports）。
2 个 400 Gbps 的 ConnectX-7存储网卡，提供 2*400 Gbps 带宽（Slot 1 和 2）。
1 个 100 Gbps Ethernet NIC（前端网络，Slot 3）。
3.1.2 SuperPod SU
如下图 Figure 2 所示为构建 DGX-SuperPod-H100 的基本单元，称作 SuperPod SU（Scalable Unit）：
每个 SU 中包含 8 个 Compute Rack，每个 Rack 40 KW。
每个 Compute Rack 包含 4 个 DGX H100 System，以及 3 个 PDU（Power Distribute Unit），也就是每个 Compute Rack 32 个 H100 GPU，则一个 SU 有 256 个 H100 GPU。
3.1.3 Management Rack
在 H100 对应的 DGX SuperPod 中，NVIDIA 提供了 Management Rack。如下图 Figure 3 所示为一个示例（针对不同的规模相应的配置会有所改变），其包含：
后端计算网络：
32 个 LeafCompute Switch，使用 QM9700，每个可以提供 64 个 400Gbps 的 Port。理论上有 32*(64/2)=1024 个 400Gbps Port 可以连接节点上的 ConnectX-7 网卡，剩下的 1024 个 Port 正好连接 16 个 Spine Compute Switch，实现 1024 GPU 的无阻塞（Non-Blocking）网络。
16 个 Spine Compute Switch，同样使用 QM9700。正好连接 32 个 Leaf Compute Switch 的一半 Port。
High-Performance 存储网络：
8 个 Leaf Storage Switch，同样使用 QM9700，连接存储网络的网卡和 Spine Switch。
4 个 Spine Storage Switch，同样使用 QM9700，连接存储网络的 Leaf Switch。
前端网络：
6 个 SN4600c In-Band Leaf Switch。
2 个 SN4600c In-Band Spine Switch。
管理网络：
8 个 SN2201 Out-of-Band Leaf Switch。
3.1.4 DGX SuperPod 127-node
如下图 Figure 5 所示为一个 127 节点的 DGX SuperPod 对应的计算网络，对应 4 个 SU，以及一个上述的 Management Rack。理论上上述的 Management Rack 正好可以连接 4 个 SU 的 128 个 Noe，但是 Leaf Switch 有一部分连接了 UFM（Unified Fabric Manager），所以实际上只有 127 个节点（NVIDIA 在最新的交换机中优化了这个部分，不会再出现少一个节点的情况）。
如下图 Figure 6 所示为其对应的 High-Performance 存储网络，也可以看出，计算网络和存储网络是独立的网络平面，互不联通。
如下图 Figure 8 所示为前端网络，也是独立的网络平面：
3.2 DeepSeek H800 集群
DeepSeek 在 [2505.09343] Insights into DeepSeek-V3: Scaling Challenges and Reflections on Hardware for AI Architectures [3] 中也介绍过其 H800 集群的网络拓扑，如下图 Figure 2 所示，其与标准 DGX H100 有所不同，其不是 2 个 High-Performance 存储网卡，每个节点只有一个 400 Gbps 的存储网卡。（PS：其并没有介绍是否还有独立的前端网卡，还是 Storage NIC 就是东西向网络，而计算网卡是南北向网络。）
3.3 当前系统的问题
当前 Agentic 应用场景快速发展，输入序列长度急剧增加，KV-Cache 的加载成为主要瓶颈。
如下图 Figure 1 左侧所示，Prefill 节点使用 Storage NIC 加载 KV-Cache 的利用率达到 100%，而 GPU 的利用率只有 40%。与此同时，Decode 节点的 Storage NIC 利用率极低。
如下图 Figure 1 右图所示，通过利用 Decoding 节点的 Storage NIC + 后端计算网络 NIC 作为 KV-Cache 加载的第二路径，可以更加充分的提升 Prefill 节点的利用率。
四、方案
4.1 方案概览
DualPath 依赖两种广泛认可的技术：
PD 分离：Prefill 和 Decoding 分开部署，以获得更高的效率。
Layerwise Prefill：按层加载 KV Cache，可以和计算 Overlap，提升 GPU 利用率。
DualPath 系统包含以下几个关键组件：
Inference Engine：每个 Engine 管理一个 GPU，其中 Prefill Engine 简称 PE，Decoding Engine 简称 DE。
Traffic Manager：采用以计算网卡为中心（CNIC-centric）的流量管理方案，以防止 KV-Cache 的后端流量干扰模型 Inference 的正常通信。每个 Engine 包含一个 Traffic Manager，用于：
CPU DRAM 和 GPU HBM 之间的数据拷贝（H2D 和 D2H）。
PE 和 DE 之间的 KV-Cache 传输。
经由 Storage NIC 读写 Storage 中的 KV-Cache。
Request Scheduler：中心调度器，负责：
接收 Client 端 Request 并将其分发给各个 Engine。
在两条数据加载路径之间进行动态的流量分配。
4.1.1 DualPath 加载
DualPath 的核心创新是在 “Storage-to-Prefill” 的路径外，额外引入一条 “Storage-to-Decoding” 的路径。允许 KV-Cache 先加载到 DE 中，然后通过高带宽的计算网络（经 RDMA）传输给 PE。通过在两条路径之间动态分配负载，能够聚合所有 Engine（包括原本闲置的 DE 侧的 Storage NIC）的存储带宽资源，进而将 Storage I/O 从单一资源瓶颈转变为一个全局池化且可调度的资源。具体数据流程如下所示，为了实现 DualPath 加载，会在每个 PE 和 DE 预留少量的 DRAM 作为缓冲区，称为 PE Buffer 和 DE Buffer：
Prefill PE 读路径（Figure 4a）：
命中的 KV-Cache 从持久化 Storage 中经存储网卡（SNIC）读取到 PE Buffer 中（1 和 2）。
该过程会逐层进行并充分的 Overlap。
以 Layerwise 的方式将 KV-Cache 逐层加载到 GPU HBM 中（3 和 4）。
逐层加载后的 KV-Cache 可以立即启动计算。
计算后的命中 KV-Cache 和未命中 KV-Cache 会经计算网卡（CNIC）传输到 DE Buffer 中（5、6 和 7）。
Prefill DE 读路径（Figure 4b）：
命中的 KV-Cache 从持久化 Storage 中经存储网卡（SNIC）读取到DE Buffer 中（1 和 2）。
该过程会逐层进行并充分的 Overlap。
PE 以 Layerwise 方式经计算网卡（CNIC）从对端 DE Buffer 中拉取命中的 KV-Cache（3、4 和 5）。
逐层加载后的 KV-Cache 可以立即启动计算。
某一层计算完之后只需将未命中的 KV-Cache 传输给 DE Buffer，然后与 DE Buffer 中命中的 KV-Cache 合并。
Decoding 阶段：
在 DE Buffer 中拼凑齐完整的 Prompt KV-Cache后（包括网络传输来的和新生产的），Decoding 阶段便正式开始。
DE 首先在自己的 HBM 中分配所需显存，执行 H2D 传输，并在开始模型 Decoding 之前主动释放 CPU DRAM，避免浪费。（PS：增加 DE Buffer 会额外引入一次 H2D 操作，实际上可以使用 RDMA 直接写入 HBM，但是考虑到 Agentic 场景中 TTFT 耗时占比很大，DE Buffer 能够有效缩短 KV-Cache 在 HBM 中的占用周期）
在 Decoding 阶段，每当积攒够一个完整的 Block（通常 64 个 Token），系统立即将它们持久化写入 Storage。
不同的数据块布局：系统采用两种不同的内存布局类型：
Full Block：存储全部层的数据，对于所有的 Storage 存储操作，均使用 Full Block 以提升吞吐。
Layer Block：存储单层的数据，当 PE/DE 数据在 HBM 和 CPU DRAM 中逐层流式搬运时，均使用 Layer Block。
4.1.2 Bottleneck-Free 分析
作者通过数学形式论证，在绝大多数合理的 P/D 比例配置下，该系统可以跑满 SNIC 的带宽，而不会引入任何 CNIC 或 DRAM 方面的新瓶颈。
假设：各节点的 PCIe 拓扑结构优良，调度实现负载均衡，计算网络不拥塞，且整个系统的存储读带宽被 100% 使用。
参数定义：
设 P 和 D 为 Prefill 节点和 Decoding 节点的数量。
每个节点包含 g 张 GPU（并配有带宽为 B 的 CNIC），节点 CNIC 总带宽为 B x g。
每个节点 SNIC 总带宽为 B x s，这里 s 可以理解为折算系数（1 个 200Gbps SNIC，则 s=0.5，2 个 400 Gbps SNIC，则 s=2），由节点内所有 Engine 共享。
M 为单个节点的 DRAM 带宽。
每个 PE-DE 对流量：
PE 读路径：流量为 Tp = Bs/(Dg2)。
共有 Pxg 个 PE，Dxg 个 DE；也就是有 Pxg 个发送端，Dxg 个接收端。
全集群可能的 “PE-DE Pair” 为 (Pxg) x (Dxg) = PDg2。
Prefill 节点全集群拉取 KV-Cache 的带宽为 PxBxs。
在极端均衡的情况下，可以得出每个 PE-DE 对的流量为：Tp = PxBxs / (PDg2) = Bs/(Dg2)。
DE 读路径：流量为 Tc = Bs/(Pg2)。
Decoding 节点全集群拉取 KV-Cache 的带宽为 DxBxs。
在极端均衡的情况下，可以得出每个 PE-DE 对的流量为：Tp = DxBxs / (PDg2) = Bs/(Pg2)。
PE 侧的 CNIC 带宽分析：由于存在不会跨交换机的回环流量 (Loopback traffic，即 H2D/D2H)，PCIe 侧的总流量始终大于等于交换机侧的流量。因此只需要计算 PCIe 的压力即可。
读操作包括 PE 路径中的 (3 和 5)，如下图 Figure 4 中绿框，所有对的总流量为：2 x Tp x Dg = 2Bs/g <= B。实际中 2s < g 通常都成立，因此读方向没有瓶颈。
写操作包含 PE 路径中的 (4) 和 DE 路径中的 (5)，如下图 Figure 4 中蓝框，所有对的总流量为：(Tp + Tc) x Dg = Bs/g x (1 + D/P) <= B。因此可以得出 P/D >= s/(g-s)。
DE 侧的 CNIC 带宽分析：
读操作包括 PE 路径中的 (8) 和 DE 路径中的 (3 和 6)，如下图 Figure 4 中绿框，所有对的总流量为：(Tp + 2 x Tc) x Pg = s/g x (P/D + 2) x B <= B。因此可以得出 P/D <= (g-2s)/s。
写操作包括 PE 路径中的 (7 和 9) 和 DE 路径中的 (7)，如下图 Figure 4 中蓝框，所有对的总流量为：(2 x Tp + Tc) x Pg <= B。因此可以得出 P/D <= (g-s)/2s。
DRAM 压力分析：DRAM 是半双工的，读写相加，PE 侧压力极低；对于 DE 侧，要求压力不超过 M，得出条件：P/D <= (M/(Bs) - 3)/2。
总的来说，合并并简化上述不等式，可以得出系统安全的配比为：
s/(g-s) <= P/D <= min{(g-2s)/s, (g–s)/2s, (M/(Bs) - 3)/2}
例如：
DeepSeek H800 系统：g=8，s=1，M≈500GB/s，B≈50GB/s，得出 1/7 <= P/D <= 7/2。
NVIDIA DGX H100 系统：g=8，s=2，M≈500GB/s，B≈50GB/s，得出 1/3 <= P/D <= 1。
4.1.3 实践挑战
DualPath 在理论上可以利用 Decoding 节点闲置的 I/O 来缓解 Prefill 节点的压力，但想要实现会面临 3 个工程挑战：
细粒度数据传输：Layerwise 方式可以克服 HBM 容量瓶颈，但会将 Full Block 的 KV-Cache 拆分成很多 Layer Block 的细粒度 KV-Cache。这些碎片化的 KV-Cache 在 Storage、DRAM、HBM 之间高频传输，要求系统不能有明显的调度开销，并且能无缝的与计算 Overlap。
流量隔离：DualPath 生成了远比单机 Inference 复杂的内部 KV-Cache 传输网络流。非常容易干扰模型并行 Inference 中极度看重时延的集合通信操作（如 All2All 和 AllReduce）。如果因为传输 KV-Cache 导致通道拥塞，整个 Forward 的卡顿将是致命的。挑战在于“在压榨出所有空闲 I/O 带宽的同时，不允许对模型的正常通信性能造成任何负面影响”。
动态负载均衡：系统中存在两条 KV-Cache 的读路径，系统必须对每个新到来的请求在线决策“该走哪条路”。Traffic Manager 必须在极短的时间窗内，实时综合多个瞬态因子来权衡：包括 SNIC 的队列深度、GPU 上的计算负载，以及 Request 负载特征等。
4.2 以 CNIC 为中心的 Traffic Manager
LLM Inference 系统中广泛采用先进的数据传输技术（比如使用 GPU 上的 Copy Engine 和 GPUDirect Storage）实现 Storage、DRAM 和 HBM 之间的高效搬运。然而这些机制存在一个严重的缺陷，严重干扰模型 Forward 期间对时延敏感的集合通信操作（如 All2All 和 AllReduce），主要有 2 个原因：
这些数据传输技术往往运行在独立的数据路径上，这些路径与计算网络没有共享同一套 QoS 控制机制。
现有的 GPU 不支持 PCIe 层级的 QoS，导致很难保护 Model Forward 通信不受其他 PCIe 流量的干扰。
此外，集合通信往往以亚毫秒级的极快突发形式出现，试图依靠纯软件维度的流量整形器去在这些高优且转瞬即逝的通信窗口之间，精确穿插低优先级的 I/O 读写操作，在工程上是不切实际。
为了解决这一问题，作者提出：以 CNIC 为中心的数据传输方案——所有进出 GPU 的数据流向，包括 GPU 与通节点的 H2D/D2H，都必须强制经由这块 GPU 绑定的 CNIC，并依靠 GPUDirect RDMA 数据链路完成。通过将所有异构流量强行收拢并暴露在计算网络上，可以充分利用计算网络底层的原生 QoS 硬件能力，来实施绝对严格的流量隔离与分级管制。
4.2.1 流量隔离
对于基于 IB 的网络，可以利用虚拟信道（Virtual Lanes, VL）技术实现流量类别间的硬隔离。（PS：DeepSeek 在 3FS 中也提到，利用 IB 的 Service Level（SL）技术，在节点之间建立连接时为其分配不同的 SL 值，并将 SL 映射到 IB 物理队列 VL，使用 VL 可以确保不同通道中的流量不会相互干扰。）
所有与模型 Inference 相关的 Forward 通信流量都被全部调度到专有的 High-Priority VL 中。
所有其他流量，包括 DualPath 的跨节点 KV-Cache 传输，全部被映射到一条隔离的 Low-Priority VL。
为基于该通信框架内的 Switch 和 NIC 的 VL 仲裁器配置极端的加权轮询参数策略，为 High-Priority VL 预留大约 99% 的带宽，仅把剩余的带宽留给 Low-Priority VL，以防止 KV-Cache 传输彻底饿死断连。这种配置可以保证模型 Forward 的通信流量免受 KV-Cache 传输的干扰，同时又给 KV-Cache 传输利用计算网络中的闲置带宽提供机会。
尽管上述方案基于 IB 网络，但该隔离设计原则上能够平滑的迁移到其他网络互联技术中。例如，在 RoCE 中，DualPath 可以基于 Traffic Class 控制器并结合 DSCP 组合实现。
4.2.2 CNIC 辅助的 KV-Cache 拷贝
目前常见的两种 GPU 数据传输流派包括：从底层 Storage 直接传输到 HBM 的 GPUDirect Storage，以及传统基于 CUDA Copy Engine 的方式。这两种方式无法实现 KV-Cache 传输的 I/O 操作与模型 Forward 中的集合通信操作互相隔离，会导致模型 Forward 性能退化。
为了解决这一痛点，实现了 CNIC 辅助的 H2D/D2H 数据路径。
对于 KV-Cache 加载：
首先从 Storage 后端中读取 KV-Cache 到 DRAM。
然后向目标 GPU 对应的 CNIC 下达 RDMA 写请求，以便进行本地的 H2D 拷贝。
对于新生成的 KV-Cache 的存储：
首先交由对应的 CNIC 写入 DRAM 中缓存。
然后通过 SNIC 写入 Storage 后端。
这种设计可以将 CNIC 作为所有 GPU PCIe 流量的中心 QoS 调度器，使其 VL 仲裁器能够优先处理 Inference 通信流量，并利用空闲的 PCIe 带宽执行 KV-Cache 传输。
作者观察到，在处理大量小数据 Block 时，CNIC 辅助的 H2D 和 D2H 传输性能优于 CUDA Copy Engine。测试数据表明，通过 cudaMemcpyAsync 提交的单次复制操作会产生约 5-7 μs 的延迟开销，由于 CUDA Driver 是闭源的，无法进一步分析该开销的构成。相比之下，提交单个 RDMA 写入请求仅需在用户空间对 NIC Register 执行少量的 mmio 写入操作，耗时仅 1μs。此外，通过 doorbell batching 技术，可以显著分担 RDMA 工作提交开销。
4.3 自适应请求调度器
理论分析证实 DualPath 读取不会产生绝对瓶颈，但在实际运行中，负载不均仍会大幅降低硬件利用率。在这种情况下，需要同时兼顾 NIC 流量和 GPU 利用率之间的平衡。为此，将调度分为两个层次：
跨 Engine 调度：负责将 Request 精确分配给一对目标节点（PE，DE），并为每个 Request 判定具体的 KV-Cache 读取路径（PE 或 DE）。
Engine 内调度：负责 Engine 内 Request 如何处理。
4.3.1 跨 Engine 调度
为了减轻调度器的压力，将 Engine 分为不同的组，只有组内编号 Rank 0 的 Engine（也称为 Leader Engine）与调度器交互。一个组内所有 Engine 要么都是 PE，要么都是 DE，且确保同一个节点上的所有 Engine 都属于同一个组。
组内的所有 Engine 会定期、同步主动拉取任务。在拉取新的 Request 时，每个 Engine 同时上报 3 个关键状态指标：
seqe：已分配给该 Engine 但还未完成的 Request 数量。
toke：上述 seqe 个 Request 包含的总 Token 数量。
read_qn(e)：Engine e 所在节点 n(e) 当前磁盘读取队列长度。
因为 GPU 负载、磁盘读负载以及网络负载压力与 Token 数量密切相关，因此使用 Token 数量（toke）作为平衡所有 Engine 的代理指标。
PE 调度：所有抵达调度器的 Request 都首先进入全局等待队列，并严格按照 FIFO（先进先出）原则调度。当一个 PE 组发起一个拉取请求时，启动调度算法。如下图 Figure 5 所示，定义两个阈值：短读取队列 α，未完成 Token 上限 β。所有 Engine 被分为 3 类（如下图 Algorithm 1 中红框）：
第一类（过载 Engine）：toke > β，排队处理的 Token 超标。
第二类（理想 Engine）：未超标，且 read_qn(e) <= α，toke <= β。
第三类（磁盘受压 Engine）：节点的磁盘读取队列较长，read_qn(e) > α，toke <= β。
系统绝对不会将新的 Request 发送给过载 Engine，此外让第二类的调度优先级高于第三类——因为第二类节点 SNIC 此刻没有磁盘排队任务，如果不安排新的 Request，将导致 SNIC 处于低利用率。当选中类别后，会将 Request 调度到类别中 toke 最小的 PE，然后会更新当前 PE 的 toke（如下图 Algorithm 1 蓝框）；接着处理下一个 Request。直到队列为空或者第二、三类别都满为止（如下图 Algorithm 1 绿框）。
DE 调度 - 阶段 1：跨组全局调度：与 PE 强制全局 FIFO 不同，DE 的调度分为两级，且不保证绝对的全局 FIFO。存在一个全局等待池，以及每个 DE 组的私有队列池。新 Request 先落到全局池。当一个 DE 组来拉取任务时，会针对性清空全局等待池，并将任务直接发给当下总 toke 最小的 DE 组。
DE 调度 - 阶段 2：组内处理：
首先计算本组所有 DE Engine 的 HBM 余量，随后从私有队列池头部开始遍历，以计算假设不存在 HBM 碎片时可调度的 Request 数量。这些 Request 构成集合 R，作为可以调度的上界。然后计算一个“危险界线”——高 Token 阈值 Z：
然后从私有队列池的头部开始调度 Request，将其调度到剩余 HBM 满足该 Request 需求的 DE Engine。具体来说，将 DE 分为两种类型，并优先将 Request 调度到（2）中 seqe 最小的 DE，从而平衡 Request 数量；只有（2）为空，才会在（1）中挑选 toke 最小的 DE，以避免 HBM 用满触发抢占风险。
（1）：高 Token DE，如果接收该 Request，则 toke + len(r) > Z。
（2）：剩余 DE，即使接收 Request，依然满足 toke + len(r) <= Z。
KV-Cache 读任务调度：为一个 Request 选好 PE 和 DE 后，调度器最后只需选择较短读队列长度的路径读取 KV-Cache 即可。理论上，将 Request 拆分成两部分，从 PE 和 DE 两个路径同时读取会更好，不过本文中并没有实现，当做未来的工作。
4.3.2 Engine 内调度
Engine 内的细粒度调度只发生在 PE 节点，因为 DE 总是把所有 Request 放入一个 Forward Batch，不需要过度调度。如下图 Figure 6 展示了 Engine 内调度方式，常见模型在 Attention 层都会采用 DP 方式，尤其是 MLA 模型：
Dense 模型或粗粒度 MoE 模型可能会采用 Attention TP + FFN TP 方式。
细粒度 MoE 模型（MHA/GQA）可以考虑 Attention TP + FFN EP 或 Attention DP + FFN EP。
细粒度 MoE 模型（MLA）模型一般采用 Attention DP + FFN EP，MLA 不适合 TP，甚至可以考虑 CP。
在这种情况下，每个 GPU 处理不同的 Request，可能导致 GPU 之间出现工作负载不均，而又必须在 Attention 阶段后同步并进入 FFN 阶段，从而导致 GPU 互相等待产生的 Bubble。因此，需要确保各 GPU 具有相似的 Attention 执行时间，以最大程度减少等待 Bubble。
层时间预估：采用 FIFO 打包策略确定 Forward 中包含的 Request 数量。Forward Batch 中的每个 Request 都有一对（cached, bsz）参数描述，其中：
cached 表示已经具备 KV-Cache 的 Token 数量。
bsz 表示当前 Batch 中需要计算 KV-Cache 的 Token 数量。
基于这些参数对，计算 Attention 层的理论总计算量并估算其执行时间。理论计算量和实际计算时间的关系取决于硬件和并行配置，可通过预先的性能分析进行拟合。
算法：只要预测的 Attention 层执行时间不超过预设上限（称作计算配额），就持续按照 FIFO 顺序添加 Request。如果某个 Request 超过此限制，则对 bsz 进行二分搜索以找到更小的 bsz’，使其适配剩余的计算配额，并对该 Request 执行 Chunked-Prefill 处理。
五、评估
5.1 实现 & 配置
代码实现：DualPath 的实现结合了 DeepSeek 之前开源的 FlashMLA、DeepGEMM、DeepEP 以及 3FS，大概涉及 5K 行代码修改。
硬件配置：前面介绍的 DeepSeek H800 集群，SNIC 连接 3FS。
模型：
MoE 模型：DeepSeek V3.2 660B，表示为 DS 660B；缩小版的 DS 27B；
Dense 模型：Qwen2.5 32B。
数据集：3 个 Agent Trace 数据集，每个包含 500 个轨迹，统计信息如下图 Table 2 所示。
基线：实验对比了 3 个基线。
SGL（MC）：SGLang + HiCache、Mooncake、3FS。
Basic：未修改的内部 Inference 框架。
Oracle：基于 DualPath，绕过所有的磁盘读取, H2D/D2H 传输, 以及 PD 间的 KV-Cache 传输。相当于 I/O 开销为 0 的理想情况。
PD 比例和并行度：DS 660B 采用 2P4D；Qwen 32B 采用 1P2D；DS 27B 采用 1P1D。DS 模型采用 Attention DP + FFN EP；Qwen 模型仅在 DualPath 中采用 DP，SGL(MC) 中采用 TP=8。
Metric：对于 Offline Batch Inference 场景, 测量整个任务的作业完成时间 (JCT)。对于 Online Serving 场景，测量首个 Token 时延（TTFT），第二个 Token 时间（TTST），以及每输出 Token 时间（TPOT）。
5.2 Offline Inference 场景
可变 Agent Batch Size & 最大 Agent 长度（MAL）：DualPath 在更大的 Batch Size，更长的 MAL 是可以获得更大的收益。如下图所示，在 DS 660B 上，DualPath 相较于 Basic 可以实现高达 1.87x 的提升，并且性能接近理论上限 Oracle，表面 KV-Cache 的传输几乎可以被隐藏。
可变的 Append 长度& 生成长度：DualPath 在可变的 Append 长度以及生成长度下都有明显优势，并且 DualPath 和 Oracle 很接近。如下图 Figure 9 所示，随着 Append 长度增加，Basic 方案逐渐趋近于 DualPath，表面系统瓶颈在 GPU 计算。相比 Basic 方案，DualPath 在不同的 Append 比例下实现了 1.82x-1.99x 的加速。
可变的 P/D 比例：在所有比例下, DualPath 都比 Basic 表现出显著的性能收益。如下图 Figure 8 所示，DualPath 在所有配置中平均实现 1.64x 加速（最高 2.46x）。Basic 版本的 1P1D 和 1P2D 性能接近；DualPath 的 1P1D 和 2P1D 性能接近；DualPath 2P1D 和 DualPath 1P2D 也类似。主要是各组系统具有等效的可用存储带宽，从而证实在 Agent 场景中存储带宽是主导系统性能的关键瓶颈。
5.3 Online Serving 场景
方法论：评估系统在不同 Agent 每秒到达率（APS）的时延特性。Agent 根据泊松过程以指定速率到达，每个 Agent 在到达时从第 0 轮开始重放直至其最后一轮。实验中，SLO 目标为 TTFT <= 4s，TPOT <= 50ms。实验终止条件为满足以下任何一种情况：TTFT > 4s 或系统到达稳态（150s 滑动窗口内的 TTFT 波动相较于 30min 前低于 5%）。
如下图 Figure 10 所示，DualPath 比 Basic 方案获得更高的 APS 容量（DS 27B 提升 1.67x，DS 660B 提升 2.25x）。DualPath 的 TTST 指标与 Basic 相当，而 TPOT 数据表面 DualPath 相较于 Basic 方案未引入额外的 Decoding 开销。SGL(MC) 出现异常偏低的 TTST，可能源于实现问题，导致前两个 Token 几乎同时到达客户端。对于 DS 27B，呈现出与 DS 660B 相似的趋势。但 Basic 与 DualPath 方案的 TPOT 均显著高于 Oracle，表明在小规模模型场景中 P-D 传输机制的开销相当大，不容忽略。
两种模型的平均 JCT 如下图 Figure 11 所示。如下图 Figure 12（左）所示，在不同 APS 配置下 DualPath 能保持稳定的 TTFT 耗时，而 Basic 方案因存储带宽不足导致队列等待时间急剧增长。
5.4 消融实验
5.4.1 负载均衡
DualPath 的调度算法改善了 SNIC 和 Attention 层计算时间的负载均衡。
对于 SNIC：如下图 Figure 13 所示，调度算法将负载均衡程度（Max/Avg 比例）从 1.53 改善到 1.18。
对于 Attention 层计算：如下图 Figure 14 所示，DualPath 在任务的前 5% 期间将 Max/Avg 比例维持在低于 1.06，减少了 GPU Bubble。
5.4.2 大规模可扩展性
使用 1152 GPU 进行 Offline 和 Online 实验以展示大规模可扩展性。如下图 Table 3 和 Figure 15 所示：
Offline 采用 2P4D（2K Agent），扩展后 48P96D（48K Agent），JCT 相当。
Online 也是 2P4D，扩展后 44P88D，实现了 22x 的吞吐量（0.4 APS vs 0.8 APS），同时保持相似的时延。
六、参考链接
https://arxiv.org/abs/2602.21548
https://docs.nvidia.com/dgx/dgxh100-user-guide/introduction-to-dgxh100.html
https://arxiv.org/abs/2505.09343