跳到主要内容

参数标定

$\alpha$-$\beta$ 模型的参数 $\alpha$ 和 $\beta$ 必须从实测数据拟合，不能直接使用硬件规格书（datasheet）上的峰值数值。规格书给出的是物理链路的理论峰值，而模型需要的是端到端的有效延迟和有效带宽，包含软件栈开销、协议效率损耗等系统性偏差。

标定数据来源​

标定使用 nccl-tests（NVIDIA 开源的 NCCL 性能评测工具）的输出数据。nccl-tests 对一组预定义的消息大小运行集合通信操作，输出每个消息大小的延迟（time_us）和算法带宽（algbw）。

典型运行命令：

NCCL_ALGO=Ring ./all_reduce_perf -b 1K -e 4G -f 2 -g 8
# -b: 最小消息大小；-e: 最大消息大小；-f: 增长因子（2 = 每次翻倍）；-g: GPU 数量

标定所用数据集（已收集的 nccl-tests 实测数据）：

文件互联类型规模数据点来源
h200_allreduce_8gpu.csvNVLink4 + NVLS8 GPU17nccl-tests issue #272
a100_allreduce_8gpu.csvNVLink38 GPU14nccl-tests issue #149
a100_allreduce_4gpu_pcie.csvPCIe Gen44 GPU15Ed Sealing Medium
gb200_allreduce_nvl72_coreweave.csvNVLink572 GPU（NVL72）5CoreWeave nccl-tests
h100_allreduce_16gpu_2node_crusoe.csvNVLink4 + IB NDR16 GPU（2 节点）17Crusoe Cloud
h100_allreduce_16gpu_2node_ib.csvNVLink4 + IB NDR16 GPU（2 节点）5Nebius
h100_allreduce_16gpu_2node.csvNVLink4 + RoCEv216 GPU（2 节点）5Oracle OCI Zettascale
a100_allreduce_16gpu_2node.csvNVLink3 + RDMA16 GPU（2 节点）11Oracle OCI
gh200_allreduce_2gpu_2node_roce.csvRoCEv2（BF3）2 GPU（2 节点）29Ed Sealing Medium
h20_allreduce_16gpu_2node_roce_asterfusion.csvRoCE 400G16 GPU（2 节点）26Asterfusion
h100_allreduce_64gpu_sharp.csvNVLink4 + IB + SHARP64 GPU（8 节点）5Nebius

$\alpha$ 的标定方法​

$\alpha$ 的标定分两种方法，适用于不同建模精度需求。

方法 A：保守计步法​

对 Ring AllReduce（$N$ 个节点），$\alpha$ 为 $N-1$ 步的总启动开销：

$\alpha = (N-1) \cdot \alpha_{\text{step}}$

其中 $\alpha_{\text{step}} = 2c_{c2c} + c_{ddr\_r} + c_{ddr\_w} + c_{noc} + 2c_{d2d}$，各分量为芯片级协议延迟参数（μs）。

问题：方法 A 将所有步的全部开销叠加，系统性高估了 $\alpha$。Ring AllReduce 流水线稳定后，后续步骤的 DMA 启动被前步传输掩盖，实际净等待时间只剩链路传播延迟，而非全部启动开销。

方法 B：流水线显式法（ASTRA-sim 风格，推荐）​

对 Ring AllReduce，实际步数为 $2(N-1)$（ReduceScatter + AllGather 各 $N-1$ 步），流水线稳定后每步只需等待链路传播延迟：

$\alpha = 2(N-1) \times \text{hops} \times \ell_{\text{link}}$

其中 $\ell_{\text{link}}$ 为单跳传播延迟（μs），$\text{hops}$ 为每步经过的物理跳数（NVSwitch 场景为 2 跳：GPU → NVSwitch → GPU）。

示例（H200 NVLink4，8 GPU，hops = 2）：

$\alpha = 2 \times 7 \times 2 \times 0.936\ \mu s = 26.2\ \mu s$

NVLink4 链路延迟约 $\ell_{\text{link}} = 0.936\ \mu s/\text{hop}$。

方法 A vs 方法 B 精度对比（H200 NVLink4 8-GPU，对延迟的 RMSPE）：

消息区间方法 A（$\alpha=59.5\ \mu s$）方法 B（$\alpha=26.2\ \mu s$）改善
< 1 MB150%18%-88%
1 ~ 128 MB39%20%-49%
> 128 MB13%8%-38%
Overall77%16%-79%

$\beta$ 的标定方法​

$\beta$（有效带宽）通过带宽利用率 $u_r$ 表示：

$\beta_{\text{eff}} = \beta_{\text{phys}} \times u_r$

标定步骤（单层拓扑）：

Step 1 — 从大消息数据读取峰值 BusBW

大消息时（带宽 bound），$\alpha$ 项可忽略，BusBW 趋近 $\beta_{\text{phys}} \cdot u_r$：

$\text{BusBW} = \text{algbw} \times \frac{2(N-1)}{N}, \qquad \text{algbw} = \frac{M}{T_{\mu s} \times 10^{-6}}$

Step 2 — 计算 $u_r$

从 CSV 取最大消息大小对应的 BusBW，除以硬件规格书的物理单向带宽：

$u_r = \frac{\text{BusBW}_{\text{peak}}}{\beta_{\text{phys}}}$

两层拓扑（节点内 NVLink + 节点间 IB）：有 5 个自由参数（$u_{NV}$、$\beta_{IB}$、$\alpha_{nv}$、$\alpha_{ib}$、$T_{sw}$），无法解析分离，采用网格搜索：枚举参数组合，对每组计算全消息段 RMSPE，选取最优组合。

标定结果示例​

单层拓扑各互联类型标定结果：

互联类型物理带宽（单向）实测峰值 BusBW标定 $u_r$$\ell_{\text{link}}$（μs）RMSPE（延迟）
NVLink5（GB200/NVL72，72 GPU）900 GB/s839 GB/s0.962.12%
NVLink4（H200，8 GPU）450 GB/s475 GB/sN/A（NVLS）1.39%
NVLink3（A100，8 GPU）300 GB/s226 GB/s0.752.38%
PCIe Gen4（A100，4 GPU）31.5 GB/s20.4 GB/s0.63—1%
InfiniBand NDR50 GB/s48 GB/s0.96——
RoCEv2（400GbE）50 GB/s~40 GB/s0.80—变化大（0.6~0.95）

关键观察：

  1. 默认 $u_r = 0.95$ 对 NVLink3/PCIe 严重高估：NVLink3 实测利用率仅 0.75（高估 27%），PCIe 仅 0.63（高估 51%）。必须按互联类型独立标定，不能使用统一默认值。

  2. NVLS 超线速无法建模：H200 8-GPU 实测 BusBW 475 GB/s 超过 NVLink4 的 450 GB/s 物理线速，这是 NVSwitch 网内计算（NVLS，In-Network Reduction）效应。$\alpha$-$\beta$ 模型无法建模 NVLS，H200/B200 场景应保守使用 $u_r = 0.92$。

  3. NVLink 代际规律：$\ell_{\text{link}}$ 反映互联代际——NVLink4（1.3 μs）< NVLink3（2.3 μs）< PCIe。新一代互联延迟更低。

  4. NVLink5 的 $\ell_{\text{link}}$ 高于 NVLink4（2.1 μs > 1.3 μs）：NVL72 有 72 GPU 共享 18 个 NVSwitch，端口仲裁延迟随规模增加，这不是物理链路变慢，而是仲裁开销增大。

参考文献​