参数标定
核心要点：
- 标定来源：nccl-tests 实测数据，覆盖 NVLink3/4/5 / PCIe / IB NDR / RoCEv2 多代际
- 规格书 $\neq$ 端到端：物理峰值忽略软件栈 / 协议效率，必须实测拟合有效值
- $\alpha$ 方法 B：流水线显式法 （ASTRA-sim 风格），$\alpha = 2(N-1) \times \text{hops} \times \ell_{\text{link}}$
- $\beta$ 利用率: $u_r = \text{BusBW}_{\text{peak}} / \beta_{\text{phys}}$, NVLink3 仅 0.75 而非默认 0.95
- NVLS 超线速：NVSwitch 网内归约使 BusBW > 物理线速，$\alpha$-$\beta$ 无法建模
$\alpha$-$\beta$ 模型的参数 $\alpha$ 和 $\beta$ 必须从实测数据拟合，不能直接使用硬件规格书的峰值数值。规格书给出的是物理链路理论峰值，而模型需要的是端到端的有效延迟和有效带宽，包含软件栈开销 / 协议效率损耗等系统性偏差。
标定数据从哪里来
核心问题：哪些公开 nccl-tests 数据可用于标定？覆盖哪些互联代际？
标定使用 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.csv | NVLink4 + NVLS | 8 GPU | 17 | nccl-tests issue #272 |
a100_allreduce_8gpu.csv | NVLink3 | 8 GPU | 14 | nccl-tests issue #149 |
a100_allreduce_4gpu_pcie.csv | PCIe Gen4 | 4 GPU | 15 | Ed Sealing Medium |
gb200_allreduce_nvl72_coreweave.csv | NVLink5 | 72 GPU (NVL72) | 5 | CoreWeave nccl-tests |
h100_allreduce_16gpu_2node_crusoe.csv | NVLink4 + IB NDR | 16 GPU （2 节点） | 17 | Crusoe Cloud |
h100_allreduce_16gpu_2node_ib.csv | NVLink4 + IB NDR | 16 GPU （2 节点） | 5 | Nebius |
h100_allreduce_16gpu_2node.csv | NVLink4 + RoCEv2 | 16 GPU （2 节点） | 5 | Oracle OCI Zettascale |
a100_allreduce_16gpu_2node.csv | NVLink3 + RDMA | 16 GPU （2 节点） | 11 | Oracle OCI |
gh200_allreduce_2gpu_2node_roce.csv | RoCEv2 (BF3) | 2 GPU （2 节点） | 29 | Ed Sealing Medium |
h20_allreduce_16gpu_2node_roce_asterfusion.csv | RoCE 400G | 16 GPU （2 节点） | 26 | Asterfusion |
h100_allreduce_64gpu_sharp.csv | NVLink4 + IB + SHARP | 64 GPU （8 节点） | 5 | Nebius |
@tbl-model-calib-datasets nccl-tests 标定数据集汇总
$\alpha$ 怎么标定
核心问题：把所有步开销叠加 （方法 A） 为什么系统性高估？流水线显式法 （方法 B） 怎么改？
方法 A：保守计步法
对 Ring AllReduce ($N$ 个节点), $\alpha$ 为 $N-1$ 步的总启动开销：
$$\begin{equation} \alpha = (N-1) \cdot \alpha_{\text{step}} \label{eq:model-calib-alpha-method-a} \end{equation}$$$\alpha_{\text{step}} = 2c_{c2c} + c_{ddr\_r} + c_{ddr\_w} + c_{noc} + 2c_{d2d}$，各分量为芯片级协议延迟参数 ($\mu s$)。
问题：方法 A 将所有步的全部开销叠加，系统性高估 $\alpha$。Ring AllReduce 流水线稳定后，后续步骤的 DMA 启动被前步传输掩盖，实际净等待时间只剩链路传播延迟，而非全部启动开销。
方法 B：流水线显式法 （ASTRA-sim 风格，推荐）
对 Ring AllReduce，实际步数为 $2(N-1)$ (ReduceScatter + AllGather 各 $N-1$ 步)，流水线稳定后每步只需等待链路传播延迟：
$$\begin{equation} \alpha = 2(N-1) \times \text{hops} \times \ell_{\text{link}} \label{eq:model-calib-alpha-method-b} \end{equation}$$$\ell_{\text{link}}$ 为单跳传播延迟 ($\mu s$), $\text{hops}$ 为每步经过的物理跳数 （NVSwitch 场景为 2 跳：GPU → NVSwitch → GPU）。
示例 (H200 NVLink4, 8 GPU, hops = 2):
$$\begin{equation} \alpha = 2 \times 7 \times 2 \times 0.936\ \mu s = 26.2\ \mu s \label{eq:model-calib-alpha-h200-example} \end{equation}$$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 MB | 150% | 18% | -88% |
| 1 ~ 128 MB | 39% | 20% | -49% |
| > 128 MB | 13% | 8% | -38% |
| Overall | 77% | 16% | -79% |
@tbl-model-calib-alpha-method-compare 方法 A vs 方法 B 的 RMSPE 对比
$\beta$ 怎么标定
核心问题：怎么从实测 BusBW 反推有效带宽 $\beta_{\text{eff}}$？两层拓扑的 5 自由参数怎么解？
$\beta$ （有效带宽） 通过带宽利用率 $u_r$ 表示:
$$\begin{equation} \beta_{\text{eff}} = \beta_{\text{phys}} \times u_r \label{eq:model-calib-beta-eff} \end{equation}$$标定步骤 （单层拓扑）：
Step 1 — 从大消息数据读取峰值 BusBW：大消息时 （带宽 bound），$\alpha$ 项可忽略，BusBW 趋近 $\beta_{\text{phys}} \cdot u_r$:
$$\begin{equation} \text{BusBW} = \text{algbw} \times \frac{2(N-1)}{N}, \qquad \text{algbw} = \frac{M}{T_{\mu s} \times 10^{-6}} \label{eq:model-calib-busbw} \end{equation}$$Step 2 — 计算 $u_r$：从 CSV 取最大消息大小对应的 BusBW，除以硬件规格书的物理单向带宽：
$$\begin{equation} u_r = \frac{\text{BusBW}_{\text{peak}}}{\beta_{\text{phys}}} \label{eq:model-calib-utilization-rate} \end{equation}$$两层拓扑 （节点内 NVLink + 节点间 IB）：有 5 个自由参数 ($u_{NV}$ / $\beta_{IB}$ / $\alpha_{nv}$ / $\alpha_{ib}$ / $T_{sw}$)，无法解析分离，采用网格搜索 — 枚举参数组合，对每组计算全消息段 RMSPE，选取最优组合。
不同互联类型的标定结果
核心问题：各互联代际的实测 $u_r$ 和 $\ell_{\text{link}}$ 是什么？默认值在哪些场景失效？
单层拓扑各互联类型标定结果：
| 互联类型 | 物理带宽 （单向） | 实测峰值 BusBW | 标定 $u_r$ | $\ell_{\text{link}}$ ($\mu s$) | RMSPE （延迟） |
|---|---|---|---|---|---|
| NVLink5 (GB200/NVL72, 72 GPU) | 900 GB/s | 839 GB/s | 0.96 | 2.1 | 2% |
| NVLink4 (H200, 8 GPU) | 450 GB/s | 475 GB/s | N/A (NVLS) | 1.3 | 9% |
| NVLink3 (A100, 8 GPU) | 300 GB/s | 226 GB/s | 0.75 | 2.3 | 8% |
| PCIe Gen4 (A100, 4 GPU) | 31.5 GB/s | 20.4 GB/s | 0.63 | — | 1% |
| InfiniBand NDR | 50 GB/s | 48 GB/s | 0.96 | — | — |
| RoCEv2 (400GbE) | 50 GB/s | ~40 GB/s | 0.80 | — | 变化大 (0.6~0.95) |
@tbl-model-calib-results 单层拓扑各互联类型标定结果
关键观察：
-
默认 $u_r = 0.95$ 对 NVLink3 / PCIe 严重高估: NVLink3 实测利用率仅 0.75 （高估 27%），PCIe 仅 0.63 （高估 51%）。必须按互联类型独立标定，不能使用统一默认值。
-
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$。
-
NVLink 代际规律：$\ell_{\text{link}}$ 反映互联代际 — NVLink4 (1.3 $\mu s$) < NVLink3 (2.3 $\mu s$) < PCIe。新一代互联延迟更低。
-
NVLink5 的 $\ell_{\text{link}}$ 高于 NVLink4 (2.1 $\mu s$ > 1.3 $\mu s$): NVL72 有 72 GPU 共享 18 个 NVSwitch，端口仲裁延迟随规模增加，这不是物理链路变慢，而是仲裁开销增大。
Takeaway
| 知识点 | 核心结论 |
|---|---|
| 数据来源 | nccl-tests 公开实测，覆盖 NVLink3/4/5 / PCIe / IB NDR / RoCEv2 |
| $\alpha$ 方法 B | $\alpha = 2(N-1) \times \text{hops} \times \ell_{\text{link}}$, H200 8-GPU 整体 RMSPE 77% → 16% |
| $\beta$ 利用率 | $u_r = \text{BusBW}_{\text{peak}}/\beta_{\text{phys}}$, NVLink3 仅 0.75, PCIe 仅 0.63 |
| 两层拓扑 | 5 自由参数无法解析分离，网格搜索拟合 |
| NVLS 不可建模 | NVSwitch 网内归约使 BusBW > 物理线速，H200/B200 保守 $u_r = 0.92$ |
| 代际趋势 | NVLink4 (1.3 $\mu s$) < NVLink3 (2.3 $\mu s$); NVLink5 (2.1 $\mu s$) 反弹来自端口仲裁 |