DQPLB
通信库如何用 CQE 反馈在多 QP 间动态调度负载
核心要点：
- 决策位置从 ASIC 哈希上移到通信库，按 CQE 反馈动态调度每个 QP 发送速率
- 按 connection class（rack-local / cross-rack / cross-DC）分配 BDP-aware 的 QP 数 + outstanding
- 跨 QP 乱序用 IMM opcode 携带 sequence number + 接收端重排序队列保序
- Meta Llama 4 集群（96K GPU）实测 steady-state step latency -12%，启动 11×
DQPLB（Dynamic QP Load Balancing）是 Meta NCCLX 在 Llama 4 训练（96K+ GPU）中部署的端点驱动路由方案：将每对 GPU 之间的通信拆分到多个 QP（Queue Pair），通过 CQE（Completion Queue Entry）反馈动态调度各 QP 的发送速率。DQPLB 是 E-ECMP + QP Scaling 思路在 100K GPU 规模下的演进——决策粒度从交换机 ASIC 的哈希进一步上移到通信库的运行时调度。
为什么 E-ECMP 在 100K GPU 规模下不够？
E-ECMP 在 100K GPU 规模的局限
E-ECMP 通过将 RoCEv2 BTH 中的 QP Number 纳入 ASIC ECMP 哈希（见 02-ecmp.md §E-ECMP），让每对节点间多个 QP 散列到不同物理路径。Meta SIGCOMM 2024 在 24K GPU 规模下已经把 AllReduce 有效带宽利用率从 60-70% 提升到 80-90%[1]。
但在 100K+ GPU 规模下 E-ECMP 仍然面临三个根本约束：
- 哈希碰撞概率随 QP 数量退化：QP 数从 4-16 提升到 32+ 时，同一 ECMP 组的桶被超线性占据，碰撞概率仍然接近生日悖论上限（见 $\href{/interconnect/路由算法/ecmp}{\text{(3.2)}}$）
- 静态分配无法响应运行时拥塞：E-ECMP 的 QP→path 映射在 QP 建立时由哈希一次性决定，运行时无法感知特定路径的拥塞或链路抖动
- 连接类别异构：rack-local、cross-rack、cross-DC 三类连接的 BDP（Bandwidth-Delay Product）差异可达 100×，静态 QP 数和 outstanding 上限无法同时适配所有类别
DQPLB 的设计动机正是针对以上三点：保留多 QP 散列的优势，但将"每个 QP 实际发多少数据"这一决策从 ASIC 哈希上移到通信库运行时。
决策点上移：从 ASIC 哈希到通信库主动管理
DQPLB 的核心思想：
- QP-path 映射仍由 E-ECMP 哈希决定（沿用 ASIC 多路径基础设施，不引入新硬件依赖）
- 每个 QP 的发送速率由通信库根据 CQE 反馈动态调节——拥塞低的 QP 自动获得更多 segment，拥塞高的 QP 被自然节流
每对通信节点之间，DQPLB 实际由 1 个 control QP + $N$ 个 data QP 构成：
- Control QP：用于交换内存地址、握手等控制平面消息（单 QP 即可）
- Data QP 池：承载实际的 RDMA Write 数据流量，是 DQPLB 调度的对象
把 DQPLB 与 ECMP / AR / Packet Spraying 按决策位置对比：
| 决策位置 | 代表方案 | 拥塞感知 | 部署难度 |
|---|---|---|---|
| 交换机 ASIC | ECMP / E-ECMP | 无 | 低（通用 ASIC） |
| 交换机 ASIC | AR per-flowlet | 有（本地队列深度） | 中（需 AR ASIC） |
| 端点 NIC | Packet Spraying | 无（统计均匀） | 中（需 UEC NIC） |
| 通信库（host） | DQPLB | 有（CQE 反馈） | 低（仅软件改造） |
@tbl-route-dqplb-decision-position 各路由方案的决策位置对比
DQPLB 的工程优势：仅需通信库改造，不依赖新硬件，可在现有 RoCEv2 + 通用 ASIC 集群上直接部署。
Rail-Optimized 拓扑如何与 DQPLB 耦合？
DQPLB 与 Rail-Optimized 拓扑设计耦合紧密。理解 plane / rail 概念是理解 DQPLB QP 分配策略的前提。
物理结构
以 DGX H100 / Meta GenAI 集群为代表的 Rail-Optimized 节点：每个 GPU 节点（8 GPU）配备 8 个独立的 NIC，每个 GPU 通过 PCIe 绑定一个专属 NIC。
- 节点内：8 GPU 通过 NVLink 全互联，节点内通信不经过 IB
- 节点间：每个 NIC 连接到独立的 leaf 交换机，对应一个独立的 leaf-spine 子网（rail）
- 整个集群有 $R$ 个并行的 rail（典型 $R = 8$）
Plane / Rail 概念
一个 rail = 一个 plane——指一组 NIC + 它们连接的专用 leaf-spine 子网。Rail-Optimized 设计中：
- 同一节点的 GPU $g$（$0 \le g < R$）只接入 rail $g$ 上的 NIC
- 跨节点通信时，GPU $g$ → GPU' $g$ 保持在 rail $g$ 内，不跨 rail
- 跨 rail 通信（GPU $g_1$ → GPU' $g_2$，$g_1 \ne g_2$）需要在节点内经过 NVLink 中转到目标 rail 对应的 NIC
NCCL 默认尽量保持通信在同 rail 内（NCCL_CROSS_NIC=0）[2]，避免跨 rail 的 NVLink 中转开销。
平面内通信 vs 平面间通信
| 通信类型 | 路径 | 瓶颈 |
|---|---|---|
| 同 rail（rail-aligned） | NVLink （本节点） + IB rail $g$ + NVLink （远端节点） | IB rail 单链路带宽 |
| 跨 rail | NVLink （本节点换 rail） + IB rail $g'$ + NVLink （远端） | NVLink 跨 rail 中转 + IB 带宽 |
@tbl-route-dqplb-rail-traffic 平面内 vs 平面间通信路径
集合通信库（NCCL/NCCLX）在算法层做 rail 对齐——AllReduce 的 Ring 拓扑被设计为环路尽量在同一 rail 内闭合。
fabricId 编码
NCCL 2.30+ 引入 fabricId 标识[3]，支持多 DC + 多 rail 的二级编码：
通过 NCCL_IB_HCA=device:port:fabricID 显式声明每张 NIC 所属的 (DC, rail)。DQPLB 根据通信双方的 fabricId 推断连接类别（同 DC 同 rail / 同 DC 跨 rail / 跨 DC），并对应不同的 QP 数和 outstanding 配置。
DQPLB 的核心算法是什么？
Per-Connection-Class QP 分配
DQPLB 按"连接类别"配置 QP 数和 outstanding segment 上限。每个类别的 outstanding 上限按 BDP 估算：
$$\begin{equation} N_{\text{outstanding}} = \left\lceil \frac{R_{\text{target}} \cdot \text{RTT}}{s_{\text{seg}}} \right\rceil \label{eq:route-dqplb-bdp} \end{equation}$$其中 $R_{\text{target}}$ 为目标带宽，$\text{RTT}$ 为往返时延，$s_{\text{seg}}$ 为 segment 大小。该公式确保流水线填满 BDP，但不会因过度 in-flight 导致路由器缓冲溢出。
工程推荐范围（基于 $\eqref{eq:route-dqplb-bdp}$ BDP 公式与 Meta 集群部署量级推算，非直引论文具体配置）：
| 连接类别 | RTT 量级 | BDP 量级 | QP 数 | outstanding |
|---|---|---|---|---|
| rack-local | < 5 μs | 数十 KB | 4 | 4-8 |
| cross-rack | 5-20 μs | 数百 KB | 8-16 | 8-32 |
| cross-DC | 1-10 ms | 数十 MB | 16-32 | 64-256 |
@tbl-route-dqplb-conn-class 连接类别与 QP/outstanding 工程推荐范围
cross-DC 的 outstanding 比 rack-local 大 2-3 个数量级——这正是静态 QP 配置无法适配的核心原因。
Segment 切分与 Round-Robin 投递
DQPLB 将待发送的消息切分为大小相等的 segment（典型 64 KB - 1 MB），按 round-robin 顺序投递到该连接的 $N$ 个 QP：
消息 M = [seg_0, seg_1, ..., seg_{K-1}]
QP 池 = {QP_0, QP_1, ..., QP_{N-1}}
for i in 0..K:
target_qp = QP_{i mod N}
if outstanding[target_qp] < N_outstanding:
post_send(target_qp, seg_i)
outstanding[target_qp] += 1
else:
pending.append(seg_i) # 该 QP 满，先排队
每个 QP 维护独立的 outstanding 计数。达到 outstanding 上限的 QP 暂停 post，等待 CQE 触发的恢复。
基于 CQE 的动态调度
收到某个 QP 的 CQE（一个 segment 发送完成）后，DQPLB 立即恢复对该 QP 的 segment 投递：
on CQE for QP_k:
outstanding[k] -= 1
if pending != empty:
next_seg = pending.pop_front()
post_send(QP_k, next_seg)
outstanding[k] += 1
关键效果：拥塞低的 QP 完成 segment 快，CQE 返回快，自动获得更多 segment 投递；拥塞高的 QP CQE 慢，segment 投递自动减少。整个负载均衡过程不需要任何显式的拥塞反馈协议，仅依赖 CQE 这一标准 IB verbs 信号。
这与 ECMP / E-ECMP 的"决策一次后不变"形成根本区别：DQPLB 在 segment 粒度持续重平衡，控制环路延迟约为 BDP 量级。
保序机制
Round-robin 跨多个 QP 投递必然产生乱序——不同 QP 走不同物理路径，segment 到达顺序无保证。NCCLX 通过三层机制保序：
- 发送端：每个 segment 携带递增的 sequence number
- 接收端：维护"下一个期望序号"，乱序到达的 segment 缓存到重排序队列，按序号补齐后交付上层
- IB opcode：典型实现使用
IBV_WR_RDMA_WRITE_WITH_IMM（而非标准IBV_WR_RDMA_WRITE），利用 IMM 字段携带 sequence number，避免修改 RDMA 数据载荷——NCCLX 论文[4]披露 DQPLB 采用此 opcode 实现保序
接收端重排序队列的最大占用约为：
$$\begin{equation} B_{\text{reorder}} \approx N \cdot N_{\text{outstanding}} \cdot s_{\text{seg}} \label{eq:route-dqplb-reorder-buf} \end{equation}$$cross-DC 场景下（$N=32$、$N_{\text{outstanding}}=256$、$s_{\text{seg}}=1$ MB）单条连接的重排序缓冲约 8 GB——这是 cross-DC 部署的关键资源约束。
DQPLB 与 NCCL 标准 multi-QP 差在哪？
NCCL 上游版本已支持 multi-QP（通过 NCCL_IB_SPLIT_DATA_ON_QPS）[5]，但与 DQPLB 有关键差异：
| 特性 | NCCL multi-QP | DQPLB |
|---|---|---|
| QP 分配粒度 | 全局统一（同一 N） | Per-connection-class |
| 投递策略 | 静态均分（split）或轮询（round-robin） | Round-robin + CQE 反馈 |
| 拥塞响应 | 无 | 有（拥塞低 QP 自动加权） |
| Outstanding 控制 | 全局 | Per-class BDP-aware |
| 异构链路适配 | 弱 | 强（按 fabricId 分类） |
| 保序机制 | 依赖 IB QP 内有序 | 跨 QP 序号 + IMM opcode |
@tbl-route-dqplb-vs-nccl-multiqp NCCL multi-QP 与 DQPLB 对比
NCCL multi-QP 解决了"哈希散列"问题，DQPLB 在此基础上进一步解决"运行时动态均衡 + 异构链路自适应"问题。
DQPLB 与 SHARP / AR 如何分工？
DQPLB 不取代 SHARP / AR，而是与它们正交分工：
| 层级 | 机制 | 解决的问题 |
|---|---|---|
| 算法层（数据） | SHARP（网内规约） | 减少需要传输的字节数 |
| 路径层（交换机） | AR per-flowlet | 单条路径上的多路径拥塞均衡 |
| 调度层（host） | DQPLB | 多 QP 之间的速率分配 + 异构链路适配 |
@tbl-route-dqplb-coordination DQPLB / SHARP / AR 三层分工
三层是正交的，可叠加部署：SHARP 减少数据量，AR 在物理路径上做拥塞规避，DQPLB 决定每个 QP 发多少 segment。
DQPLB 在 Llama 4 训练（96K GPU）实测改进了多少？
实测改进
NCCLX + DQPLB 在 Meta 96K GPU Llama 4 训练集群上相对 NCCL baseline 的改进：
| 指标 | 改进幅度 | 备注 |
|---|---|---|
| Steady-state 训练 step latency | -12% | 与 NCCL baseline 对比 |
| 训练启动时间 | 11× 加速 | 96K scale 初始化阶段 |
| Llama 4 Maverick 推理 e2e decoding latency | -15% ~ -80% | 不同 distributed 配置区间 |
@tbl-route-dqplb-llama4 Llama 4 训练实测改进
改进来源分解
NCCLX 论文[4]将上述改进归因于三个层次的协同：
- DQPLB 本身：动态 QP 调度减少链路拥塞导致的尾延迟
- fabricId-aware 连接分类：让 cross-rack / cross-DC 连接获得适配的 outstanding 配置，避免小 BDP 连接因过度 in-flight 而拥塞
- 保序优化：IMM opcode + 重排序队列让 multi-QP 不再受限于 IB 标准的 QP 内有序约束
DQPLB 综合性能特性？
| 指标 | DQPLB | NCCL multi-QP | E-ECMP（对照） |
|---|---|---|---|
| 100K GPU AllReduce 有效带宽 | 高（动态平衡） | 中 | 中（哈希碰撞限制） |
| 拥塞响应 | 有（CQE 反馈） | 无 | 无 |
| 异构链路适配 | 优 | 弱 | 弱 |
| 跨 DC 训练支持 | 强 | 弱 | 弱 |
| 硬件门槛 | 通用 RoCEv2 ASIC | 通用 | 支持 UDF 的 ASIC |
| 部署复杂度 | 中（通信库改造） | 低 | 低 |
@tbl-route-dqplb-perf 性能特性对比
何时该用 DQPLB，何时不该？
适用场景：
- 100K+ GPU 规模的训练集群
- 异构连接（rack-local + cross-rack + cross-DC 混合）场景
- 已有 Rail-Optimized 拓扑 + RoCEv2 + 多 NIC GPU 节点的部署
- 希望避免引入 AR ASIC 或 UEC NIC 等新硬件的环境
局限：
- 需要通信库（NCCL/NCCLX）改造，NCCL 上游版本尚未集成完整 DQPLB
- 接收端的重排序缓冲在 cross-DC 场景下需求量大（GB 级，见 $\eqref{eq:route-dqplb-reorder-buf}$）
- CQE 反馈延迟限制了响应速度——sub-RTT 级别的拥塞抖动无法捕捉
- 依赖
IBV_WR_RDMA_WRITE_WITH_IMMopcode，需要 NIC 固件支持
选型建议：
- Rail-Optimized + 100K GPU + 异构链路：DQPLB 是当前最优选择
- Rail-Optimized + 24K GPU + 同构链路：E-ECMP + QP Scaling 已足够
- 单 NIC 节点或非 Rail-Optimized 拓扑：DQPLB 退化为多 QP scaling，收益降低
Takeaway
| 知识点 | 核心结论 |
|---|---|
| 决策上移 | QP-path 映射仍由 E-ECMP 哈希，但每 QP 发送速率由通信库按 CQE 动态调 |
| Connection class | rack-local / cross-rack / cross-DC 三类，按 BDP 配 QP 数 + outstanding |
| Round-robin + CQE | 拥塞低 QP CQE 快 → 自动获得更多 segment，无需显式拥塞协议 |
| 保序机制 | IMM opcode 携带 sequence number + 接收端重排序队列 |
| 与 SHARP/AR 关系 | 三层正交：SHARP 减数据量 / AR 路径拥塞 / DQPLB 多 QP 速率分配 |
| Llama 4 实测 | step latency -12%；启动 11×；decoding latency -15~-80% |
| 工程门槛 | 仅通信库改造，无新硬件；cross-DC 重排序缓冲 GB 级是核心约束 |
参考资料
- Gangidi et al., RDMA over Ethernet for Distributed AI Training at Meta Scale, SIGCOMM 2024. https://dl.acm.org/doi/10.1145/3651890.3672233
- NVIDIA, NCCL Environment Variables. https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/env.html
- NVIDIA, NCCL Deep Dive: Cross Data Center Communication, 2025. https://developer.nvidia.com/blog/nccl-deep-dive-cross-data-center-communication-and-network-topology-awareness/
- Collective Communication for 100k+ GPUs, arXiv:2510.20171 (Meta, 2025). https://arxiv.org/abs/2510.20171
- NVIDIA, Doubling all2all Performance with NCCL 2.12. https://developer.nvidia.com/blog/doubling-all2all-performance-with-nvidia-collective-communication-library-2-12/