DualPath ---DeepSeek V4 推理框架创新论文学习笔记DeepSeek 推理架构创新 ● 设计并实现

时间：2026-2-25

原文链接：arxiv.org/abs/2602.21…

研究背景

超长上下文的频繁复用： 现在的 LLM 应用正从单轮对话转向复杂的 Agent 任务（比如自主写代码、多轮工具调用）。这意味着上下文在多轮交互中会疯狂累加，达到几十万甚至上百万 tokens，并且具有极高的 KV-Cache 复用率（命中率高达 98.7%）。
计算不再是主要矛盾，I/O 成了短板： 当新请求到来时，因为大部分前置上下文的特征都已经计算过并存入了外部硬盘或分布式存储中，模型不再需要做大量的“从头计算”，而是需要频繁且大量地将历史 KV-Cache 重新读进显存。
传统 PD 分离架构下的“忙的忙死，闲的闲死”： 按照传统的单路径架构（Storage-to-Prefill），所有的 KV-Cache 读取压力全部压在了 Prefill 节点 上。这导致 Prefill 节点的存储网卡（SNIC）带宽瞬间被打满（网络拥塞），系统卡在数据加载上；而与此同时，负责逐字生成的 Decode 节点 的存储网卡却大量闲置
I/O上的短板就导致了GPU利用率不足

动机：观察发现，总带宽远大于存储网络（SNIC，400Gbps）的计算网络（CNIC，8*400Gbps），其网络流量呈现出一种间歇性的特征，模型推理中使用的集合通信操作是以亚毫秒级的间隔爆发的

意味着：计算网络存在闲置时间，可以利用其缓解存储网卡的瓶颈

近年来 GPU 硬件的发展趋势与 Agentic（智能体）推理负载的需求严重错配，导致系统撞上了“内存墙”和“通信墙”：

左图：统计了从 2020 年（NVIDIA Ampere 架构）到 2024 年（Blackwell 架构）这几年间，GPU 核心指标的增长倍数

算力狂飙： 蓝线（FLOPS 算力）呈指数级飙升，增长了 28.8 倍。
I/O 与显存拖后腿： 绿线（网卡带宽）和红线（HBM 显存容量）增长极其缓慢，分别只增长了 2.0 倍和 2.4 倍
硬件的“I/O-算力比（I/O-compute ratio）”剧烈下降了 14.4 倍。这意味着 GPU 算得越来越快，但“喂数据”的网卡以及“存数据”的显存却跟不上。在 Agentic 这种极度依赖从外部读取海量历史 KV Cache 的场景下，低迷的网卡带宽会直接导致 GPU 算力被闲置等待

右图：在典型的 Agentic 负载下（30K 历史上下文，仅新生成 300 个 token），随着 Batch Size（并发处理的请求数量）的增加，系统吞吐量（Token Throughput）的变化曲线

结合左图，因为 HBM 显存容量太小（只涨了 2.4倍），系统根本装不下更多并发请求的 KV Cache
因为显存装不下，所以 Batch Size 上不去；因为 Batch Size 上不去，就无法生成足够多的并行计算任务去填满 GPU 庞大的算力单元（Tensor Core），进一步加剧了算力浪费

核心贡献

提出 DualPath 双路径加载架构：设计并实现了一个全新的推理系统，打破了以往只能将KV-Cache直接读取到预填充引擎的限制
配套设计动态调度与流量隔离机制：
- 负载感知调度：提出了一种全局调度算法，能够根据当前的请求特征、GPU负载以及磁盘读取队列长度，动态决定每条请求的读取路径，从而在预填充与解码引擎之间平衡计算和网络资源的利用率。
- 流量隔离：采用以网卡为中心（NIC-centric）的流量管理方案，严格隔离了KV-Cache的数据传输流量，避免其干扰模型执行阶段对延迟极其敏感的集合通信
在实际的Agent工作负载测试中，DualPath系统将离线推理吞吐量提升了最高1.87倍。在线服务吞吐量平均提升了1.96倍

DualPath 双路径 KV-Cache 加载架构

粗箭头（Full Block）：代表包含所有网络层的完整 KV-Cache 数据块（详见附录 Layer Prefill）
细箭头（Layer Block）：代表只有单层的 KV-Cache 数据块
Persistent Storage（持久化存储）：外部的分布式 SSD 存储系统（如文中的 3FS），用来存放海量历史多轮对话的 KV-Cache。
SNIC（存储网卡）：专门连接外部存储的网卡（南-北向流量）。传统架构中，只有 Prefill 节点的 SNIC 在干活，Decode 节点的 SNIC 是闲置的。
CNIC（计算网卡）：专门负责节点间高速通信（如 RDMA）的网卡（东-西向流量），带宽高且支持优先级调度。注意：图中的一个关键设计是，主机内存(DRAM)与GPU显存之间的数据拷贝（H2D/D2H），也强制绕道经过 CNIC，这是为了利用计算网卡的 QoS 功能隔离不同优先级的流量（防止传 Cache 影响模型并行计算的延迟）。
DRAM（主机内存）：在这里专门划分了一小块作为缓冲区，文中称为 PE Buffer（预填充节点缓存）和 DE Buffer（解码节点缓存）

左图为传统PD分离架构加载路径，这里只解析右图：

从存储到 DE 内存 [箭头 1、2]：系统调度器决定把某条请求的读取任务派发给 DE 节点。历史 KV-Cache 通过 DE 节点的 SNIC，以 Full Block 形式读取到 DE 节点的 DRAM（DE Buffer）中。
从 DE 传给 PE 进行计算 [箭头 3、4 (向左)、5]：当 PE 开始计算某一层的注意力机制时，它需要的这一层历史 KV-Cache，会从 DE Buffer 取出，经过 DE 的 CNIC，跨节点 RDMA 传给 PE 的 CNIC，最后落入 PE 的 GPU 显存。（同样以细箭头的单层形式传输，且与计算时间重叠掩盖延迟）。
将新计算的 Cache 补回 DE [箭头 4 (向右)、6]：PE 计算完这一层后，历史 Cache 原本就是从 DE 拿来的，所以不用再传回去了。PE 只把新输入的 Token（Miss tokens）计算出的增量 KV-Cache，跨节点发回给 DE 节点，并与 DE Buffer 中的历史数据合并。
DE 节点准备解码 [箭头 7]：同样，所有层计算完毕后，DE Buffer 里拥有了拼好的完整上下文 Cache。DE 将其送入 GPU，开始解码生成

DualPath 无瓶颈分析 (Bottleneck-Free Analysis)

核心目的：通过理论建模，推导出一个“安全运行区间”，即 P / D 的合理范围。在这个区间内，DualPath 架构可以 100% 榨干所有的存储网卡带宽，同时保证 计算网卡（CNIC） 和 主机内存（DRAM） 不会超载

三大限制条件：

Prefill (PE) 节点的计算网卡不超载

要处理普通的计算流量，还要接收来自 DE 节点传来的历史 Cache，并把新计算的 Cache 传给 DE 节点

Decode (DE) 节点的计算网卡不超载

既要作为“中转站”把读到的 Cache 通过计算网卡发给 PE，又要接收 PE 算完的 Cache

主机内存 (DRAM) 带宽不超载

由于内存是半双工的（读写共享总带宽），需要将读流量和写流量相加。PE 节点的内存压力通常没问题，但 DE 节点因为要频繁做中转，内存压力较大

详细推演见：附录（DualPath 无瓶颈分析完整推演）

结论：

$\frac{s}{g-s} \le P/D \le \min\left\{ \frac{g-2s}{s}, \frac{g-s}{2s}, \frac{M/Bs-3}{2} \right\}$

$P$ 和 $D$ ：分别为 Prefill（预填充）节点和 Decode（解码）节点的数量。这是我们要求解的核心比例 ( $P/D$ )。
$g$ ：每个节点的 GPU 数量（通常 $g=8$ ）。
$B$ ：单张计算网卡（CNIC）的带宽（例如 400Gbps = 50GB/s）。
$s \times B$ ：每台机器（节点）的存储网卡总带宽。其中 $s$ 是存储带宽相对于单张计算网卡的倍数（例如通常机器有1张 400G 存储网卡，则 $s=1$ ）。
$M$ ：每台机器的主机内存（DRAM）读写带宽（例如 500GB/s）

以计算网卡（CNIC）为中心的流量管理器

痛点：后台新增路径上的KV Cache流量与前台GPU的模型并行计算流量抢夺物理通道（PCIe 总线），导致模型推理延迟暴增

传统方案无法解决此问题：

GPU 的 PCIe 总线在硬件层面上不支持 QoS（服务质量优先级控制）
传统的 GPU 拷贝工具（如 CUDA copy）拥有自己独立的数据路径，它们和计算网卡（CNIC）不在同一个 QoS 管理体系下。这就导致系统无法在全局层面对流量进行统一的高低优先级调度
模型计算时的网络通信不是持续平缓的，而是间歇性、亚毫秒级（不到1毫秒）的瞬间爆发。因为爆发时间太短，试图在软件层面写一个“限流器”来让 Cache 传输主动避让计算流量，是根本反应不过来、也极其不切实际的

解法：强行绕道 CNIC

放弃所有的传统直接拷贝方法。任何进出 GPU 显存的数据（哪怕只是在同一台服务器上的 Host 内存拷到 GPU 显存，即 H2D/D2H），统统不允许直接走 CUDA copy，而是强行交由该 GPU 绑定的计算网卡（CNIC），通过 GPUDirect RDMA 绕一圈来完成搬运

好处：

白嫖高级网卡的硬件 QoS：计算网卡（如 InfiniBand）在硬件层面拥有极其强大的 QoS 能力（虚拟链路 Virtual Lanes, VLs）
绝对的物理隔离：把所有流量都交给网卡管之后，DualPath 就可以在网卡的硬件仲裁器上定下死规矩：
- 分配 99% 的带宽最高优先级给“模型推理的集合通信”。
- 剩下的 1% 带宽（以及高优先级空闲时的所有带宽）分配给“KV Cache 搬运”
只要模型计算一开始瞬间爆发，网卡硬件就会立刻把 Cache 传输按住；等计算爆发间隙的几毫秒，网卡又会满载传输 Cache
意外的性能红利：在处理大量小数据块时，这种“绕道”CNIC 的拷贝方式（1微秒）反而比原生的 CUDA 拷贝引擎（5～7微秒）更快

流量隔离机制

针对Infiniband网络

InfiniBand 具有原生的硬件级流量隔离机制，称为 虚拟链路（Virtual Lanes, VLs）。

流量分流：
- 高优先级 VL：专门分配给模型推理时的集合通信（如 AllGather, AllToAll 等对延迟极度敏感的流量）。
- 低优先级 VL：专门分配给 KV-Cache 的后台传输流量。
权重分配（核心）：在所有的网卡和网络交换机上，配置加权轮询（Weighted Round-Robin）仲裁器。
- 给予高优先级 VL 约 99% 的带宽保障。
- 给予低优先级 VL 剩下的 1% 带宽（为了防止 KV-Cache 传输被完全“饿死”/Starvation）。
实际效果：当模型计算瞬间爆发时，立刻占用 99% 带宽，几乎不受影响；当计算处于亚毫秒级的空窗期时，KV-Cache 传输就会趁机把闲置的带宽全部吃满

针对RoCE网络

对于基于以太网的 RoCE 网络，由于底层协议不同，DualPath 采用了另一套等效的映射机制：

流量标记与映射：利用 DSCP（差分服务代码点） 对数据包进行分类标记，并将这些标记映射到网卡和交换机上不同的 TC（流量类别/硬件队列） 中。
无损网络保障：配置 4 个支持 PFC（优先级流量控制） 的无损 RDMA 队列，来对齐 IB 网络的 4 条虚拟链路（图中仅画出2条）
权重分配：与 IB 网络类似，在以太网交换机和网卡队列上配置极度倾斜的调度权重（如 99% vs 1%），实现同样强度的物理级带宽隔离

自适应请求调度器

**功能：**作为全局大脑，动态规划每个请求的最优 KV-Cache 加载路径，从而充分聚合所有引擎的存储网卡带宽并实现系统级的负载均衡。

维持两个维度的平衡：

网卡流量平衡
GPU的利用率平衡

与流量管理器的关系：

调度器负责在顶层指派最优的传输路线，而部署在各个引擎内的流量管理器则负责严格通过计算网卡（CNIC）的 QoS 机制来执行这些底层数据搬运，确保庞大的 I/O 流量绝不阻塞核心的模型推理过程

引擎间调度

核心任务是解决三个问题：

这个请求分配给哪个 Prefill 引擎（PE）？
分配给哪个 Decode 引擎（DE）？
最终从哪边的网卡去读 KV-Cache？

**引擎分组：**同一节点上相同类型的引擎（全是 PE 或全是 DE）会被分在同一个组，每次只有组内的“Leader 引擎”（rank 0）出面统一向调度器拉取任务

当拉取任务时，每个引擎会汇报三个“核心负载指标”：

$seq_e$ ：分配给该引擎但还没完成的请求数量。
$tok_e$ ：这些未完成请求的总 Token 数。由于 GPU 负载、磁盘读取和网络负载都与 Token 数量高度相关，系统将其作为衡量负载的最核心代理指标。
$read\_q_{n(e)}$ ：该引擎所在节点的磁盘读取队列长度

PE调度

对于 Prefill 引擎，调度器维护了一个全局等待队列，并严格按照先进先出（FIFO）的顺序处理请求。

调度器预设了两个阈值：短读取队列阈值 $\alpha$ 和未完成 Token 上限 $\beta$ 。基于这两个阈值，所有 PE 会被划分为三个梯队：

第一梯队（优先救火区）：磁盘读取队列短（ $read\_q_{n(e)} \le \alpha$ ）且未超载（ $tok_e \le \beta$ ）的 PE 。系统会最优先把任务派给它们，因为它们的存储网卡马上就要闲置了，需要赶紧补充读取任务以防网卡利用率低下。
第二梯队（正常排队区）：磁盘读取队列较长（ $read\_q_{n(e)} > \alpha$ ）且未超载（ $tok_e \le \beta$ ）的 PE 。
第三梯队（拒绝服务区）：已经超载（ $tok_e > \beta$ ）的 PE，调度器不会给它们分配任何新请求。

最终选择：调度器会在最高优先级的非空梯队中，挑出 $tok_e$ 最小的那个 PE 来接单，并立刻更新它的 $tok_e$ 记录

DE调度

与 PE 不同，Decode 引擎的调度不保证全局的 FIFO 顺序，而是分为“跨组”和“组内”两个阶段来进行

阶段一：跨组分配 (Phase 1: across groups)
新请求首先进入全局队列。当 DE 组来拉取任务时，调度器会把请求分配给组内所有引擎 $tok_e$ 总和最小的那个 DE 组。这一步直接从宏观上拉平了不同组之间的网卡和 GPU 负载。

阶段二：组内微操 (Phase 2: within a group)
进入组内私有队列后，调度器会先计算组内所有 DE 剩余的 HBM（显存），算出一个理论上能调度的最大请求集合 $R$ 。
接着，计算出一个“高 Token 阈值” $Z$ ：

$Z = 1.05 \times (\sum_{r \in R} len_r + \sum_{e \in E} tok_e) / |E|$

在那些显存足够容纳当前请求的 DE 中，调度器会将它们分为两类：

常规组：接单后总 Token 数不超标（ $\le Z$ ）。调度器优先从这里选，并挑出 $seq_e$ 最小的引擎，以此来平衡各个引擎手里的请求个数。
高 Token 组：接单后总 Token 数会超标（ $> Z$ ）。只有在常规组空了的时候才从这里选，并挑出 $tok_e$ 最小的引擎，以降低显存被彻底耗尽的风险

最终选择

经过上述筛选，调度器为当前请求确定了 1 个 PE 和 1 个 DE。最后：调度器会直接对比这个 PE 节点和 DE 节点的磁盘读取队列，哪边的排队更短，KV-Cache 就从哪边读

引擎内调度

宏观的引擎间调度决定了“请求分配给哪台机器”，而引擎内调度（Intra-Engine Scheduling）则专注于“这台机器上的多张 GPU 显卡如何协同工作”
引擎内调度专门针对 Prefill 引擎（PE）。Decode 引擎（DE）不需要这一层调度，因为 DE 总是把所有请求放在一个批次里统一执行

**痛点：**如右图“Original”部分

在现代大语言模型推理中，注意力层（attention layers）通常采用数据并行策略，这意味着不同的 GPU 会同时处理不同的请求集。
由于并行组中的所有 GPU 必须在注意力阶段结束后进行同步，才能一起进入前馈网络（FFN）阶段。
正如图中“original”时间线所示，早完成计算的 GPU 必须空闲并等待较慢的 GPU 。这种等待导致的空闲时间被称为“气泡（Bubble）”，它代表了 GPU 计算资源的浪费

**解决方案：**计算配额（左侧 - Compute Quota）

目标：确保所有 GPU 能够大致在同一时间完成注意力层的计算。
系统通过引入“计算配额（Compute Quota）”来实现这一点，根据请求的特征来预测其在注意力层所需的执行时间。
调度器按照先进先出（FIFO）的顺序将请求打包进计算批次中，并不断添加请求，直到预测的执行时间达到预设的“计算配额”上限。
分块预填充（Chunked Prefill）：正如图中箭头所指的深蓝色部分，如果加入队列中的下一个完整请求会导致时间超过配额限制，调度器会通过二分查找找出一个刚好能填满剩余计算配额的较小请求块。它将该部分（chunk）放入当前批次进行预填充，而把该请求剩余的部分留在队列中等待下一次调度

Q：这里所谓的“计算”，到底是什么？

A：是注意力机制（Attention）中海量的矩阵乘法运算。

预填充阶段（Prefill），当一个请求进入预填充阶段时，它通常包含了一段较长的新文本（例如用户刚输入的 300 个 Token）

模型必须同时为这 300 个新 Token（论文中称为 $bsz$ ）计算它们的 Query、Key、Value 矩阵，并与已经存在的KV Cache进行复杂的注意力分数（Attention scores）计算
不一致的来源：分配给不同 GPU 的请求，其包含的新 Token 数量（ $bsz$ ）和历史 Token 数量（ $cached$ ）各不相同。这就导致了它们在计算注意力层时的“理论计算量”和最终的执行时间（也就是图 6 中绿色 Attention 方块的长度）参差不齐

解码阶段（Decode），模型每次前向传播仅仅生成 1个新的 Token

此时的注意力计算变成了 1 个 Token 的向量与庞大的历史 KV-Cache 矩阵相乘（矩阵对向量乘法，GEMV）。
这个过程的瓶颈不再是 GPU 算不过来，而是受限于将海量的 KV-Cache 从显存中读取出来的速度

实验评估

离线批处理推理（Offline Batch Inference）

结论：DualPath 相比基础架构有显著提速；逼近理论性能极限，成功打破 I/O 瓶颈；压力越大，优势越明显

三个维度（行与列）：
- 行（不同模型）：从上到下分别对应了 DS 27B（顶部）、DS 660B（中部）和 Qwen 32B（底部）这三款大语言模型。
- 列（最大上下文长度 MAL）：从左到右测试了三种不同的 Agent 最大上下文长度，分别为 32k、48k 和 64k 。
- 横轴（并发数量）：X 轴表示同时运行的 Agent 数量（Number of Agents），随着数值增大，系统的并发压力显著增加。Y轴 (JCT)表示任务完成时间（Job Completion Time），单位为秒
对比基线（图例柱状图）：
- Ours(oracle)（灰色）：理论性能上限。它是在 DualPath 的基础上，直接绕过了所有磁盘读取和内存传输操作，假设 I/O 开销为零。
- Ours（深橙色）：本文提出的 DualPath 系统。
- Ours(basic)（浅黄色）：未经修改的基础内部推理框架。
- SGL(MC)（蓝色）：集成了 Mooncake 存储的 SGLang 开源框架（注意：DS 27B 模型不支持该框架，故顶部图无此柱子）

基础设置：这次单独测试的是参数量较小的 DS 27B 模型。横轴和不同的图表面板依然代表并发的 Agent 数量（512 到 2048）以及最大上下文长度（32k 到 64k）。纵轴是任务完成时间（JCT），数值越低代表系统跑得越快

图例的含义（颜色与纹理交叉组合）：

看颜色对比系统：深橙色代表本文提出的 DualPath（Ours），浅黄色代表基础内部框架（Ours(basic)）。
看纹理对比硬件比例：纯色块代表 1P1D（1 个预填充节点配合 1 个解码节点）；密集点状图代表 1P2D；斜线阴影代表 2P1D

结论：

DualPath 在任何比例下都全面碾压基础框架，在这些配置下平均实现了 1.64倍 的加速，最高加速比达到了 2.46倍
** 巧妙的等量代换验证了“存储带宽”是核心瓶颈：**
- 传统系统 Basic 1P1D 和 Basic 1P2D 的性能几乎一样（浅色实心柱和浅色点状柱高度相似）
- DualPath 1P1D 与 Basic 2P1D 的性能非常接近
- DualPath 2P1D 与 DualPath 1P2D 的性能也非常接近

因为在传统 Basic 架构中，只有 Prefill 节点（P节点）会去存储端读取海量的 KV-Cache 。所以增加 Decode 节点（D节点）对提升 I/O 没有任何帮助（解释了为何 Basic 1P1D = Basic 1P2D）

而 DualPath 的核心创新在于它能够同时利用所有节点（包括 P 和 D）的网卡带宽来读取存储。

因此，DualPath 1P1D（共2台机器出力读取）的性能就追平了 Basic 2P1D（也是2台机器出力读取）

在线服务（Online Serving）场景

X轴 (APS)：代表智能体的到达率（Agent arrival rate per second），即每秒系统接收到的新智能体请求数量。数值越往右，代表系统面临的并发压力越高。
Y轴 (延迟指标)：分别展示了三个关键的在线生成延迟指标（单位均为秒）：
- TTFT (Time to First Token)：首 Token 延迟，即从发送请求到系统输出第一个字的时间。
- TTST (Time to Second Token)：第二个 Token 的延迟。
- TPOT (Time Per Output Token)：每个输出 Token 的平均生成耗时。
上下两排子图：上排展示的是运行 27B 参数模型（DS 27B）的结果，下排展示的是运行 660B 参数大模型（DS 660B）的结果。
服务等级目标 (SLO)：论文为系统健康运行设定了红线——TTFT 不超过 4秒，且 TPOT 不超过 50毫秒。在 TTST 和 TPOT 图表中，任何超过此阈值的数据点都会被直接省略（这就是为什么有些线条中途断掉或没有画全）

结论： 在面临真实、不可预测的在线服务请求时，它同样能大幅提升系统吞吐量，同时不牺牲任何用户的延迟体验

DualPath 显著提升了系统的服务容量上限（承载能力）
- 在最左侧的 TTFT 图表中，随着请求到达率（APS）的增加，传统基础架构 Ours(basic)（浅橙色线）的延迟会迅速飙升并触碰 4秒的终止线。相比之下，采用了双通道加载的 Ours（深橙色线）能够在更高的并发压力下依然保持延迟稳定。具体数据显示，DualPath 能够支撑的 APS 容量在 DS 27B 模型上是基础架构的 1.67倍，在 DS 660B 模型上更是达到了 2.25倍
** DualPath 没有带来额外的解码负担**
- 观察中间的 TTST 和右侧的 TPOT 图表， Ours（深橙色）的曲线几乎与 Ours(basic)（浅橙色）完全重合。证明了虽然 DualPath 为了加速预填充（Prefill）阶段的 KV-Cache 读取而引入了复杂的双通道调度和网卡流量管理，但这并没有拖慢后续逐字生成的解码（Decode）阶段的性能

视角：整个智能体任务（Trajectory）的端到端平均完成时间。是一张“压力测试成绩单”
X轴 (APS)：代表智能体的到达率（Agent arrival rate per second），即系统每秒接收到的新任务并发量
Y轴 (Avg. JCT)：平均任务完成时间（Average Job Completion Time），单位为秒
实线（Solid line）：代表运行参数量高达 660B 的 DeepSeek V3/V3.2 大模型的结果。
虚线（Dashed line）：代表运行 27B 小模型的结果

**结论：**DualPath 在面对海量、长文本的 Agent 任务洪流时，不仅跑得快（JCT 低），而且扛得住（APS 上限高）

DualPath（深橙色）能够将曲线大幅向右推进，在极高的并发压力下依然能完成任务，展现了远超传统架构的系统吞吐量上限
DualPath（深橙色曲线）在很长一段区间内都紧紧贴着灰色曲线（没有任何I/O瓶颈的理想状态），证明了 DualPath 的双通道加载和调度算法极大地隐藏/消除了 KV-Cache 的读取开销，让系统的性能表现几乎达到了硬件计算能力的理论极限

消融实验

X轴是并发请求的到达率（APS）。
Y轴是首字延迟（TTFT）内部各个阶段的时间占比（Percentage）。
柱子分布：在每个 APS 下，柱子成对出现，左侧是 DualPath（Ours），右侧是传统架构（Basic）。
颜色代表的阶段：Sch. 代表调度与排队（Scheduling），A. 代表内存分配（Allocating），R. 代表读取 KV-Cache（Reading KV-cache），PF. 代表预填充计算（Prefill）

左图：在线服务首字延迟（TTFT）的时间切片分析

随着系统并发压力（APS）从 0.15 增加到 0.25，传统系统（右侧柱子）中代表排队/调度时间的 Sch. 阶段（顶部浅色区域）急剧膨胀。这说明大量请求卡在了等待有限的存储网卡带宽上，导致严重的排队积压
DualPath（左侧柱子），无论并发压力如何上升，其内部各个阶段的时间比例始终保持在一个相对健康的常态。这证明了 DualPath 成功打通了存储带宽瓶颈，系统没有因为 I/O 拥塞而陷入瘫痪

右图：离线推理的消融实验（Ablation Study）

基于 660B 模型、64K 上下文长度，分别测试了 1024 和 2048 个智能体并发的情况
X轴代表逐步叠加各项优化技术：从最原始的 Basic 架构，加上分层预填充（+Layer），再叠加双通道加载（+DPL），最后加上调度算法（+Sched）。
Y轴是任务总完成时间（JCT，秒）

存储网卡（Storage NIC）流量的负载均衡

X轴：系统运行时间（Time，单位为秒）。
Y轴：最大/平均流量比（Max/Avg Ratio）。这是在一个小时间窗口内，所有存储网卡中流量最大的一张网卡与所有网卡平均流量的比值。**这个数值越接近 1.0，代表各张网卡的干活量越平均，也就是完美的负载均衡 **
线条对比：红色的虚线是没有使用智能调度算法（Ours w/o scheduling，即简单的轮询调度）；蓝色的实线是开启了 DualPath 智能调度的结果（Ours）

结论：** **DualPath 的智能调度算法将存储网卡的流量负载不均衡比例（最大值/平均值）从 1.53 显著降低至 1.18，成功避免了局部 I/O 拥塞并实现了全局网卡资源的均匀利用

注意力层（Attention）计算时间的负载均衡

X轴：任务的相对时间进度（Relative Time in Task (%)）。这里只展示了前 50% ，因为在任务的后半段，随着并发请求完成，系统会处于低负载状态，此时再计算比例就失去意义了。图表分为 512 个和 1024 个并发智能体两组对比。
Y轴：注意力计算时间的最大/平均比（Attn. Time Max/Avg）。这是在一个专家并行（Expert Parallel）组内的所有 GPU 中统计的。
线条对比：与 Fig 13 一样，红色虚线为无调度，蓝色实线为 DualPath 智能调度

结论： 通过精准预估和分配计算量，DualPath 将各 GPU 间 Attention 层的计算时间差异在任务最繁重的初期压低至 1.06，有效减少了并行计算中因等待同步而产生的 GPU 算力闲置（气泡）

附录

Layer Prefill（分层预填充）

传统 Prefill 痛点：显存撑爆导致算力闲置

在传统的 Prefill（预填充）阶段，GPU 需要把一个 Batch 内所有请求的 完整 KV Cache（包含所有网络层） 一次性全部加载到显存（HBM）中。

对于 Agentic 这种动辄几万 Token 的长上下文场景，完整的 KV Cache 极其庞大。
这导致 GPU 显存瞬间被占满，系统被迫极大地缩小并发请求数（Batch Size）。并发数一低，GPU 强大的计算单元（Tensor Core）就“吃不饱”，造成算力严重浪费

Layerwise Prefill 的核心原理：利用计算的局部性

LLM的计算是一层一层（Layer-by-Layer）串行向后推进的。计算第 i 层时，根本不需要用到其他层的 KV Cache

因此，Layerwise Prefill 改变了策略：

按层加载与释放：GPU 在执行前向传播时，每一层只在显存中分配并加载当前这一层需要的 KV Cache。
当这一层计算完毕后，立刻将这一层的 KV Cache 释放（或转移走），腾出显存空间，再去加载下一层的 KV Cache

DualPath ---DeepSeek V4 推理框架创新 论文学习笔记