DeepSeek新论文DualPath学习

💡

推荐渣总的解读：https://mp.weixin.qq.com/s/vrUw-a_6QiQkbiBaC3rC6Q

推荐AI闲谈的解读：https://mp.weixin.qq.com/s/42HQhnYM5X4PMDiyBlyaFQ

通读下来是想利用PD分离中D端闲置的存储网络带宽，同时针对现有分布式部署和网络系统设计了一套调度方案，思想比较简单，但是具体实现细节估计会比较多和复杂（pd, layerwise io, overlap, 调度request，调度compute等等），而且需要进行更多的online验证。

引用渣总最后说的存储接入scaleout网络是比较干净的方案：

ScaleOut可以承载存储流量, 并接入到存储网络中, 实现FrontEnd和ScaleOut并网. 对于存储和集合通信的干扰问题也可以通过QoS很好的解决. 相对于DualPath会更加干净.

进一步来看, 由于PCIe带宽约束和缺乏QoS控制机制, 将能够接入存储的NIC直接接入到ScaleUP Fabric甚至在ScaleUP域内构建一些额外的内存节点也是工业界正在演进的方向. 例如Nvidia未来在CX10中有接入NVLink的打算来避免PCIe的诸多限制

DualPath 是一款针对智能体化 LLM 推理场景设计的高性能推理系统，场景比如多轮长输入，短追加的输入和输出，prefix cache命中高等，核心目标是解决 PD（Prefill-Decode）解耦架构中 KV-Cache 存储 I/O 瓶颈，通过创新的双路径加载、CNIC 中心流量管理和自适应调度，实现存储带宽的全局优化利用。

1. 核心组件构成

DualPath 的系统架构基于 PD 解耦架构演进，包含三大核心组件，各组件协同实现“带宽聚合、流量隔离、负载均衡”的设计目标：

组件	功能定位	核心职责
推理引擎（Inference Engines）	计算与存储交互的核心载体	分为预填充引擎（PE）和解码引擎（DE），每台引擎管理 1 个 GPU； PE：负责 KV-Cache 加载、层式预填充计算，处理批量 compute-bound 任务； DE：负责 autoregressive 解码、KV-Cache 持久化，处理 latency-sensitive 任务；两类引擎均配备独立的 SNIC（存储网卡）和 CNIC（计算网卡），支持双路径数据交互。
流量管理器（Traffic Manager）	数据传输的“调度中枢”	嵌入每个推理引擎，统一处理三类数据操作：1. 主机-设备（H2D/D2H）内存拷贝；2. PE 与 DE 间的 KV-Cache RDMA 传输；3. 基于 SNIC 的存储读写操作；核心特性：采用 CNIC-Centric 设计，通过 QoS 机制隔离推理通信与 KV 传输流量（先保证LLM推理的正常并行通信）
请求调度器（Request Scheduler）	全局资源的“负载均衡器”	分为引擎间调度和引擎内调度两层：引擎间：分配请求至 (PE, DE) 对，动态选择 KV-Cache 加载路径；引擎内：优化批量任务的计算配额，最小化 GPU 同步等待气泡；核心输入：存储队列长度、GPU token负载、请求 token 量等实时 metrics

2. 核心技术细节

2.1 双路径 KV-Cache 加载（核心创新）

打破传统“存储→PE”的单路径依赖，通过两条路径聚合所有引擎的 SNIC 带宽，从根本上解决 PE 侧带宽饱和、DE 侧带宽闲置的不平衡问题。

两条路径的数据流设计

传统路径（存储→PE→DE）：适配短上下文、高计算占比场景

存储中的 KV-Cache（命中 tokens）通过 SNIC 加载至 PE 的 DRAM 缓冲区（PE Buffer）；

层式预填充时，逐层将该层 KV-Cache 从 PE Buffer 传输至 PE HBM，与新生成的 KV-Cache（未命中 tokens）合并；

每层计算完成后，将完整 KV-Cache 通过 RDMA 传输至 DE Buffer，重复至所有层完成。

新增路径（存储→DE→PE）：适配长上下文、高 I/O 占比场景

存储中的 KV-Cache 通过 DE 的 SNIC 加载至 DE Buffer（利用 DE 闲置 SNIC 带宽）；

PE 执行层式预填充时，通过计算网络（CNIC）以 RDMA 方式逐层读取 DE Buffer 中的对应层 KV-Cache，与本地计算的新 KV-Cache 合并；

仅将未命中 tokens 的 KV-Cache 回传至 DE Buffer 合并，减少数据传输量。

块布局优化：Full Block + Layer Block

为适配层式预填充和双路径传输，设计两种 KV-Cache 块格式，避免内存布局转换开销：

Full Block：形状为 [layer, tokens, bytes]，包含所有层的 KV-Cache，用于与存储交互（减少存储 I/O 次数）；

Layer Block：形状为 [1, tokens, bytes]，仅包含单一层的 KV-Cache，用于 PE/DE 间的层式流式传输（匹配预填充的层粒度执行）；

核心逻辑：存储中以 Full Block 存储，传输时自动拆分为 Layer Block，计算完成后拼接为 Full Block 持久化。

缓冲区设计：PE Buffer + DE Buffer

作用：临时缓存 KV-Cache，实现“存储读取-计算-传输”的并行重叠；

大小：仅占用少量 DRAM（DeepSeek 模型单节点 80GB，Qwen32B 单节点 320GB），避免 GPU HBM 占用；

优势：DE Buffer 可减少解码阶段的 GPU 内存占用，降低 TTFT（首 token 延迟）占比。

2.2 无瓶颈架构的理论推导

通过数学推导明确预填充/解码节点数（P/D）的合理范围，确保双路径加载不会引入新的 CNIC 或 DRAM 瓶颈。

假设：PCIe 拓扑配置合理、任务调度负载均衡、计算网络无拥塞；

关键符号：

P/D：预填充/解码节点数；
g：单节点 GPU 数（默认 8）；
s：单节点存储带宽系数（默认 1，即 SNIC 带宽 = CNIC 带宽）；
B：单 CNIC 带宽；
M：单节点 DRAM 带宽（默认 500GB/s）。

P/D 比例约束公式通过 CNIC 带宽、DRAM 带宽约束推导，最终得到瓶颈-free 范围：

实际配置（g=8, s=1）：1/7 ≤ P/D ≤ 3.5，覆盖 1P1D、2P4D、1P2D 等主流部署场景。

2.3 CNIC-Centric 流量管理

解决双路径传输中“KV 流量与推理通信冲突”的核心挑战，确保低优先级 KV 传输不影响高优先级模型执行。

（1）流量隔离机制

基于计算网络的 QoS 能力，将流量分为两类，实现物理隔离：

高优先级流量：模型推理通信（如专家并行的 AllToAll、张量并行的 ReduceScatter）；

低优先级流量：KV-Cache 传输、存储读写；

具体实现：

InfiniBand 网络：通过虚拟通道（VL）划分，高优先级 VL 占用 99% 带宽，低优先级 VL 占用 1% 带宽；
RoCE 网络：通过 TC（Traffic Class）和 DSCP 标记划分硬件队列，确保推理通信优先调度。

（2）CNIC 辅助 KV-Cache 拷贝

替代传统的 CUDA Copy Engine 和 GPUDirect Storage，避免 PCIe 带宽竞争：

流程：存储→主机 DRAM→CNIC→GPU HBM（加载）；GPU HBM→CNIC→主机 DRAM→存储（持久化）；

性能优势：

小数据块传输更高效：RDMA Write 请求延迟仅 1μs，远低于 cudaMemcpyAsync 的 5-7μs；
支持门控批处理（Doorbell Batching），进一步降低传输开销。

自适应请求调度算法

实现“存储带宽-计算负载-网络流量”的全局平衡，核心分为两层调度：

（1）引擎间调度（跨 PE/DE 组）

PE 调度：

按“未完成 token 量（tok）”和“存储队列长度（read_q）”将 PE 分为三类：过载（tok>β）、短队列（read_q≤α 且 tok≤β）、长队列（read_q>α 且 tok≤β）；

优先将请求分配给短队列且 tok 最小的 PE，避免存储 NIC 闲置；

关键参数：α（3 秒内可读取的 token 量）、β（单 GPU 5 秒可处理的 token 量），均通过预 profiling 确定。

DE 调度：

组间调度：将请求分配给总 tok 最小的 DE 组，平衡组间负载；

组内调度：计算 DE 剩余 HBM 容量，优先分配给 tok+请求长度≤阈值 Z（1.05×平均负载）的 DE，避免 HBM 耗尽；

阈值 Z 公式：

KV 路径选择：为每个请求选择存储队列更短的一侧（PE 或 DE）加载 KV-Cache，未来可支持请求拆分到双路径并行加载。

（2）引擎内调度（PE 内部）

针对层式预填充的负载不平衡问题，引入“计算配额（Compute Quota）”机制：

核心逻辑：通过预 profiling 确定单批次注意力层的最大执行时间（默认 300ms），按 FIFO 顺序打包请求；

超限处理：若新增请求导致执行时间超配额，通过二分查找拆分请求的 batch size（bsz'），执行块化预填充（Chunked Prefill）；

优化效果：GPU 注意力层执行时间的 Max/Avg 比低至 1.06，显著减少同步等待气泡。

关键实现细节

层式预填充集成：复用 LayerKV/PrefillOnly 的层粒度 KV 管理，GPU 仅保留当前层 KV-Cache，有效提升 batch size（约为层数倍）；

存储后端适配：采用 3FS 分布式存储，支持 io_uring 内核旁路接口，可饱和 400Gbps SNIC 带宽；

CUDA 内核优化：基于 FlashMLA（稀疏注意力）、DeepGEMM（矩阵乘法）、DeepEP（专家并行通信）优化，匹配主流开源框架性能；

代码改动量：基于自研推理框架修改约 5K 行代码，可快速集成到现有 PD 解耦架构。

3. PD配比计算

CNIC 在 PCIe 一侧的“read/write”指的是 NIC 的 DMA 行为：

CNIC read：CNIC 通过 PCIe 从 GPU HBM 或 Host DRAM 读入数据（DMA read）。

CNIC write：CNIC 通过 PCIe 向 GPU HBM 或 Host DRAM 写出数据（DMA write）。

论文 4.2 明确说：因为有 loopback（H2D/D2H 不经过交换芯片但仍走 PCIe），所以只要算 PCIe 侧压力就能上界交换方向压力。

图 4(a) ：先 (1)(2) 把 hit KV 读进 PE buffer (DRAM)，然后每层用 (3)(4) 把该层 hit KV 搬到 PE HBM 做计算，最后 (5)-(7) 把 KV 送到 DE buffer (DRAM)；decode 开始前 DE 再做 H2D（8)(9)

编号	数据走向（图 4a）	触发的带宽压力
(1)	Persistent Storage → PE SNIC	存储网卡（SNIC），不算进 CNIC/DRAM
(2)	PE SNIC → PE DRAM (PE buffer)	PE DRAM write
(3)	PE DRAM → PE CNIC	PE CNIC read（从 DRAM 读）
(4)	PE CNIC → PE GPU (HBM)	PE CNIC write（写入 HBM，H2D 的后一段）
(5)	PE GPU (HBM) → PE CNIC	PE CNIC read（从 HBM 读，D2H 的前一段）
(6)	PE CNIC → DE CNIC（网络）	走计算网络；不额外消耗 PCIe 侧 read/write（数据已在 NIC 内）
(7)	DE CNIC → DE DRAM (DE buffer)	DE CNIC write（写入 DRAM）+ DE DRAM write
(8)	DE DRAM → DE CNIC	DE CNIC read（从 DRAM 读，H2D 的前一段） + DE DRAM read
(9)	DE CNIC → DE GPU (HBM)	DE CNIC write（写入 HBM，H2D 的后一段）

图 4(b) ：hit KV 先 (1)(2) 读进 DE buffer (DRAM)；prefill 过程中每层用 (3)-(5) 把该层 hit KV 从 DE buffer 送到 PE HBM；最后 decode 开始前 DE 再做 H2D（(6)(7)）

编号	数据走向（图 4b）	触发的带宽压力
(1)	Persistent Storage → DE SNIC	SNIC（不算 CNIC/DRAM）
(2)	DE SNIC → DE DRAM (DE buffer)	DE DRAM write
(3)	DE DRAM → DE CNIC	DE CNIC read + DE DRAM read
(4)	DE CNIC → PE CNIC（网络）	计算网络；不额外算 PCIe read/write
(5)	PE CNIC → PE GPU (HBM)	PE CNIC write（H2D 的后一段）
(6)	DE DRAM → DE CNIC（decode 前）	DE CNIC read + DE DRAM read
(7)	DE CNIC → DE GPU (HBM)（decode 前）	DE CNIC write

先定义以下符号：

(P)：prefill 节点数；(D)：decode 节点数。

每个节点有 (g) 张 GPU（也就是 (g) 个引擎/进程）。

每张 GPU 配 1 个 CNIC，其带宽为 (B)。

每台机器的存储侧读带宽总和为 ()（作者把它写成 “(sB)” 这种乘积形式；可以理解为“存储网卡总带宽 = (s) 倍的 CNIC 带宽”）。

(M)：每台机器的 DRAM 带宽（memory bandwidth）。

此外，作者假设：

调度负载均衡（流量均匀摊到所有引擎/节点）

计算网络无拥塞

PCIe 拓扑配置良好（GPU–NIC 同一 PCIe switch）

作者要证明：在合理的 Prefill/Decode 节点比例 (P/D) 下，系统可以把所有机器的“存储网卡（SNIC）读带宽”吃满，同时不会把“计算网卡（CNIC）/PCIe”或“主存 DRAM”压爆。

核心做法：假设存储读带宽已经被完全利用（storage NIC saturated），然后把“每条链路/每块资源上会承受多少流量”算出来，要求它不超过对应带宽上限，从而得到对 (P/D) 的范围约束。

图 4 里，hit KV-cache 的搬运最终都是 PE 与 DE 之间成对发生（哪个 PE 服务哪个 DE 的请求）。作者用“pair 流量”把后续所有链路的流量都表示成 “每对 * 对数 * 路径条数”。

在 PE read path 下，hit KV 首先从存储读到 PE 所在机器（图 4a 的 (1)(2)）。这意味着：

每台 PE 机器能从存储侧读到的总带宽是 (sB)。

这 (sB) 要在该机器的 (g) 个 PE 引擎之间均分，所以 每个 PE 引擎分到

负载均衡意味着：这个 PE 引擎服务的请求，会均匀分摊到所有 DE 引擎（总数 (Dg)）上，于是 每个 (PE,DE) 对分到

同理，在 DE read path 下，hit KV 首先从存储读到 DE 所在机器（图 4b 的 (1)(2)），于是：

每台 DE 机器存储读带宽 (sB)，均分给 (g) 个 DE 引擎 → 每个 DE 引擎 ((sB)/g)

均匀分摊到所有 PE 引擎（总数 (Pg)）→ 每对

接下来分别算 PE CNIC 和 DE CNIC 上的“读方向/写方向 PCIe 压力”。它强调因为存在 loopback（H2D/D2H 这类不出机的数据搬运），PCIe 侧的总压力 ≥ 交换机方向压力，所以只需要算 PCIe 侧即可。

PE CNIC 的 read 操作包含图 4a 的 (3) 和 (5) 两段，因此对每个 (PE,DE) pair 会产生 2 次规模为 (T_p) 的 read 流量。

每个 PE 引擎会和所有 DE 引擎配对：pair 数 = (Dg)

每个 pair 带来 2 条 read 流：总 read 压力 , 代入：, 要求不超过 CNIC 带宽 (B)，得到式 (1)：

作者随后用工程经验说明这通常满足（典型配置 (g=8, s=1) 时左边 (=0.25B)）。

PE CNIC 的 write 操作包含：

PE path (4)（来自图 4a）

DE path (5)（来自图 4b）

pair 数仍按 “每个 PE 对所有 DE” 计：(Dg)

总 write 压力：, 要求 (≤ B)，就是式 (2)：

整理得出式 (3): 。

直觉：如果 (P/D) 太小（prefill 节点太少），大量流量会“倒灌”到少数 PE 的 CNIC 写方向上，导致 PE CNIC 成瓶颈，因此需要一个 prefill 不能太少 的下界。

DE CNIC 的 read 操作包含：

PE path 8（图 4a）

DE paths 3/6（图 4b，两条）

对于“某个 DE 引擎”，它会和所有 PE 引擎配对，pair 数 = (Pg)。因此总 read 压力：, 要求 (≤B)，得到式 (4)：, 整理得式 (5):

直觉：如果 (P/D) 太大（prefill 节点太多），DE 需要面对太多 PE 的请求，DE CNIC 的 read 会被打满，所以这给出 prefill 不能太多 的上界。

DE CNIC write 操作包含：

PE paths 7/9（图 4a，两条）

DE path 7（图 4b，一条）

所以每个 pair 的 write 贡献是 (2T_p + T_c)，pair 数仍为 (Pg)：, 整理得式 (7):

注意：式 (7) 通常比式 (5) 更紧（因为 ((g-s)/(2s)) 往往小于 ((g-2s)/s)）

作者接着看内存带宽（DRAM）。关键点：DRAM 是 half-duplex（论文直接假设半双工），所以要把读写压力相加看总占用。

对 PE 侧 DRAM，作者给出压力是 (2sB)，并认为一般不会超过 (M)，hit KV 从存储搬到 DRAM 至少 1 次写入，再从 DRAM 取走至少 1 次读出，形成“约 2 倍”系数

对 DE 侧 DRAM，作者给出压力：, 并要求它 (≤ M)，于是得到式 (8):

这里的 “(3)” 和 “(2P/D)” 本质上是作者对 DE buffer 相关 DRAM 读写次数的计数结果：
固定项 3：与“从存储进 DE DRAM、从 DE DRAM 发出、DE 再做一次面向 GPU 的 H2D”等基础搬运有关；
可变项 (2P/D)：当系统也在用 PE read path（图 4a）时，PE 机器也在以 (sB) 的速率从存储读入 hit KV，然后这些 hit KV 最终必须进入某个 DE 的 DE buffer（图 4a 的 (5)-(7)）
全部 PE 机器的存储读入总量：(P * sB)
负载均衡下，这些数据会被均匀摊到 (D) 台 DE 机器上
⇒ 每台 DE 平均接收的速率是 ((P/D) * sB)
而对这部分“从 PE 来”的 KV，在 DE DRAM 上至少会发生两次带宽消耗（看图 4a）：
写入一次：DE CNIC → DE DRAM（编号 (7)）
⇒ DE DRAM write (= (P/D)* sB)
读出一次（decode 用）：DE DRAM → DE CNIC（编号 (8)）
⇒ DE DRAM read (= (P/D) * sB)

汇总得到式 (9)：可行的 (P/D) 区间

把前面得到的：

下界（来自 PE CNIC write）：（式 3）

上界（来自 DE CNIC read/write、DE DRAM）：式 (5)(7)(8)

合并，得到式 (9)：

最后作者代入一个典型配置例子：

(g=8, s=1)

就得到：, 覆盖了大部分实际系统配置。

4. 调度算法

DualPath的自适应请求调度是实现“双路径负载均衡、全局资源最大化利用”的核心，其核心设计目标是同时平衡存储网卡（SNIC）流量、计算网卡（CNIC）负载和GPU利用率，避免单路径/单引擎过载，适配双路径KV-Cache加载的特性。具体实现分为引擎间调度（跨PE/DE分配请求、选择KV加载路径）和引擎内调度（PE内部批量任务优化）两层，DE无需引擎内调度（直接全量入批）。

3.1 调度核心前提与负载指标

调度触发条件

主动触发：PE/DE引擎组定期向中央调度器发起“任务 fetch 请求”（同节点引擎为一组，仅组内“主引擎”与调度器交互，减少调度开销）；

被动触发：新请求进入全局等待队列，调度器根据当前负载动态分配。

核心负载指标（实时上报）

每个引擎实时向调度器上报3类关键指标，作为调度决策依据：

seq：该引擎未完成的请求数量；

tok：未完成请求的总token量（关联GPU计算负载、网络传输量）；

read_q：引擎所在节点的存储读取队列长度（关联SNIC带宽负载）。

关键参数（预profiling确定）

α（短读取队列阈值）：节点3秒内可处理的最大KV-Cache读取token量，用于区分“短队列”和“长队列”；

β（未完成token上限）：单GPU5秒内可处理的最大token量，用于判断引擎是否“过载”；

计算配额（Compute Quota）：单批次attention层的最大允许执行时间（默认300ms），用于PE内部批量控制。

3.2 引擎间调度（核心：跨PE/DE分配请求+路径选择）

引擎间调度的核心是“将请求分配给最优（PE, DE）对，并选择最优KV-Cache加载路径”，分为PE调度、DE调度、路径选择三部分。

PE调度（预填充引擎：compute-bound，批量处理）

PE的请求队列遵循FIFO顺序，调度流程如下：

引擎分类：调度器根据上报的tok和read_q，将所有PE分为3类：

C1（过载）：tok > β → 不分配新请求，避免PE侧SNIC和GPU双重饱和；

C2（优先分配）：read_q ≤ α 且 tok ≤ β → 存储队列短+计算负载低，优先利用其SNIC带宽；

C3（次选）：read_q > α 且 tok ≤ β → 存储队列长但计算负载低，仅当C2为空时分配。

请求分配：

从全局等待队列头部取出请求，优先分配给C2中tok最小的PE（平衡计算负载）；

若C2为空，分配给C3中tok最小的PE；

分配后更新该PE的tok（累加当前请求的token量），重复直到C2、C3均为空或请求队列耗尽。

核心目的：避免PE侧SNIC带宽饱和，同时平衡不同PE的计算负载，最大化预填充吞吐量。

DE调度（解码引擎：latency-sensitive，低延迟处理）

DE调度为两级调度（组间→组内），不保证全局FIFO（优先保障低延迟），流程如下：

第一级：组间调度（平衡组间负载）：

所有新请求先进入全局等待队列；

当DE组发起fetch请求时，调度器将请求分配给“组内所有DE的tok总和最小”的DE组，平衡组间SNIC和GPU负载。

第二级：组内调度（平衡组内HBM与负载）：

计算组内所有DE的剩余HBM容量，确定“无HBM碎片时可调度的请求集R”（上限）；

计算高token阈值 Z = 1.05 × (ΣR中请求长度 + Σ组内DE的tok) / 组内DE数量（1.05为负载冗余系数）；

从组内私有队列头部取出请求，分配策略：

优先选择“剩余HBM足够 + tok + 请求长度 ≤ Z”的DE（低负载，避免HBM耗尽）；

该类DE中，选择seq（未完成请求数）最小的，平衡请求数量；

若该类DE为空，选择“剩余HBM足够 + tok最小”的DE（避免单点过载）；

若无DE剩余HBM足够，终止本次fetch，返回已分配请求。

核心目的：在保障解码低延迟的前提下，平衡DE的HBM容量和负载，避免解码阶段GPU闲置或HBM溢出。

KV-Cache读取路径选择（自适应双路径）

当请求分配至（PE, DE）对后，调度器根据实时read_q选择KV-Cache加载路径：

比较PE所在节点和DE所在节点的read_q，选择队列更短的一侧作为加载端（PE侧或DE侧）；

核心逻辑：利用DE侧闲置的SNIC带宽，避免PE侧SNIC饱和，实现全局存储带宽池化；

未来优化方向：支持将单个请求拆分为两部分，双路径并行加载（当前为单路径选择）。

3.3 引擎内调度（仅PE：优化GPU计算负载均衡）

PE是compute-bound，采用层式预填充（Layerwise Prefill）时，数据并行容易导致不同GPU的attention层执行时间差异，产生“同步气泡”（GPU等待其他节点完成）。引擎内调度的核心是“计算配额机制”，具体实现：

attention层执行时间估计：

每个请求用（cached，bsz）描述：cached是已命中KV-Cache的token量，bsz是需计算的新token量；

通过预profiling拟合“理论计算量（PFLOP）→ 实际执行时间（ms）”的映射关系（依赖硬件和并行配置）。

批量请求打包策略：

按FIFO顺序从PE的本地队列中添加请求，累计预测执行时间不超过“计算配额”（默认300ms）；

若新增请求导致累计时间超限，对该请求的bsz执行二分查找，拆分出bsz'（满足剩余配额），对该请求执行“块化预填充”（Chunked Prefill），剩余部分后续批次处理。

优化效果：

所有GPU的attention层执行时间Max/Avg比低至1.06，显著减少同步等待气泡，GPU利用率提升17%以上（来自消融实验）。

3.4 调度的自适应特性与协同设计

动态调整：负载指标（seq、tok、read_q）实时更新（每批次任务完成后上报），调度策略随负载变化动态调整（如高负载时优先短队列节点，低负载时优先填满GPU批次）；

与流量管理协同：调度器选择路径时，会避开CNIC高负载的节点，配合“CNIC-Centric流量隔离”（高优先级推理通信预留99%带宽），避免KV传输干扰模型执行；

大规模扩展性：调度器CPU占用≤10核（1152 GPU集群测试），支持P/D比例在1/7~3.5范围内的所有配置，无调度瓶颈。

自适应请求调度整体主流程（引擎间+引擎内全链路）:

PE引擎间调度（α/β为核心阈值，FIFO顺序）

DE两级引擎间调度（非全局FIFO，低延迟优先）

KV-Cache双路径选择（双路径架构核心衔接）

PE引擎内调度（计算配额机制，解决GPU同步气泡）

5. 技术组件的性能贡献（ ablation 实验验证）

通过离线推理场景（64K 上下文、1024 代理）的消融实验，各核心组件的性能贡献如下：

优化组件	JCT 降低比例	核心价值
层式预填充（Layerwise Prefill）	17.21%	缓解 PE 的 HBM 瓶颈，隐藏传输开销
双路径加载（DualPath Loading）	38.19%	聚合所有 SNIC 带宽，突破 PE 侧 I/O 瓶颈（核心贡献）
自适应调度（Scheduling Algorithm）	45.62%	平衡存储/NIC/GPU 负载，最大化硬件利用率