精度验证
核心要点：
- 单层拓扑大消息：RMSPE < 5%, $\alpha$ 计算从方法 A 改为方法 B 使整体 RMSPE 77% → 16%
- 两层拓扑：网格搜索 + 串行三阶段公式，H100 + IB NDR 16-GPU RMSPE 42.5% → 9.9%
- 误差按消息分段：< 1 MB 由 $\alpha$ 误差 + NCCL kernel launch 主导，> 64 MB 由 $u_r$ 决定
- 结构性失效：NVLS / SHARP / ECMP 哈希冲突 / 大规模 AllToAll, RMSPE > 30%
- 工程建议：推理 TP AllReduce (> 10 MB) 可用；小消息 (< 1 MB) 不建议
本文记录 $\alpha$-$\beta$ 通信模型在不同互联类型和消息大小下的预测精度验证结果，包括验证数据集 / 单层 + 两层拓扑验证 / 误差分析 / 已知精度边界。
核心结论：给定正确的参数标定，大消息 (>64 MB) AllReduce 的延迟预测 RMSPE < 10%，适合推理场景的 TP / PP 通信建模。单层拓扑改进 $\alpha$ 计算逻辑后整体 RMSPE 从 77% 降至 16%；两层拓扑修正分层公式后 RMSPE 从 42.5% 降至 9.9%。
验证用什么数据集
核心问题：验证覆盖哪些互联类型和节点规模？误差指标怎么算？
验证使用公开 nccl-tests 实测数据，覆盖主流互联类型 (NVLink3/4/5 / PCIe Gen4 / InfiniBand NDR / HDR / RoCEv2) 和节点规模 （8 GPU 单节点 ~ 64 GPU 8 节点）：
| 数据集 | 互联类型 | 规模 | 数据点 | 消息范围 |
|---|---|---|---|---|
| H200 8-GPU | NVLink4 + NVLS | 8 GPU | 17 | 64 KB ~ 4 GB |
| A100 8-GPU | NVLink3 | 8 GPU | 14 | 1 MB ~ 512 MB |
| A100 4-GPU PCIe | PCIe Gen4 | 4 GPU | 15 | 128 MB ~ 1 GB |
| GB200 NVL72 | NVLink5 （72 GPU 全连接） | 72 GPU | 5 | 64 MB ~ 4 GB |
| H100 16-GPU 2-node (Crusoe) | NVLink4 + IB NDR | 16 GPU | 17 | 64 KB ~ 2 GB |
| H100 16-GPU 2-node (Nebius) | NVLink4 + IB NDR | 16 GPU | 5 | 512 MB ~ 8 GB |
| H100 16-GPU 2-node (Oracle) | NVLink4 + RoCEv2 | 16 GPU | 5 | 1 GB ~ 16 GB |
@tbl-model-verify-datasets 精度验证使用的数据集
误差指标 RMSPE （均方根百分比误差）：
$$\begin{equation} \text{RMSPE} = \sqrt{\frac{1}{n}\sum_{i=1}^{n}\left(\frac{\hat{T}_i - T_i}{T_i}\right)^2} \times 100\% \label{eq:model-verify-rmspe} \end{equation}$$$T_i$ 为实测延迟 ($\mu s$), $\hat{T}_i$ 为模型预测延迟 ($\mu s$)。RMSPE 对相对误差敏感，大消息和小消息均等权重。
单层拓扑的精度怎么样
核心问题：标定 $u_r$ 后，各互联类型单层拓扑 RMSPE 是多少？
单层拓扑 （所有 GPU 通过同类链路全连接，如 NVSwitch 场景） 使用 Flat Ring AllReduce 公式：
$$\begin{equation} T = 2(N-1) \times \text{hops} \times \ell_{\text{link}} + \frac{2(N-1)}{N} \cdot \frac{M}{\beta_{\text{phys}} \cdot u_r} \label{eq:model-verify-flat-ring-ar} \end{equation}$$最优参数拟合结果 (方法 B, ASTRA-sim 风格 $\alpha$ 计算):
| 互联类型 | $N$ | hops | $u_r$ | $\ell_{\text{link}}$ ($\mu s$) | $\alpha$ ($\mu s$) | RMSPE （延迟） |
|---|---|---|---|---|---|---|
| NVLink5 (GB200/NVL72) | 72 | 2 | 0.96 | 2.1 | 606 | 2% |
| NVLink4 (H200 8-GPU) | 8 | 2 | 0.98 | 1.3 | 37 | 9% |
| NVLink3 (A100 8-GPU) | 8 | 2 | 0.72 | 2.3 | 65 | 8% |
| PCIe Gen4 (A100 4-GPU) | 4 | 2 | 0.66 | — | — | 1% |
@tbl-model-verify-flat-rmspe 单层拓扑各互联类型最优参数与 RMSPE
大消息 BusBW 预测精度 （消息 > 256 MB，带宽主导区间）：
| 互联类型 | 实测 BusBW | 模型预测 | 误差 |
|---|---|---|---|
| A100 NVLink3 8-GPU | 226 GB/s | 225 GB/s ($u_r=0.75$) | < 1% |
| H100 NVLink4 8-GPU | ~414 GB/s | 414 GB/s ($u_r=0.92$) | < 1% |
| H200 NVLink4 8-GPU (NVLS) | 475 GB/s | 414 GB/s ($u_r=0.92$) | -13% （NVLS 无法建模） |
| GB200 NVL72 | 839 GB/s | 837 GB/s ($u_r=0.93$) | < 1% |
@tbl-model-verify-flat-bw 单层拓扑大消息 BusBW 实测 vs 预测
结论：给定正确的 $u_r$，单层拓扑大消息 AllReduce 预测误差 < 3% （NVLS 场景除外）。
两层拓扑的精度怎么样
核心问题：跨节点场景下网格搜索能拟到多少精度？早期版本 Bug 的影响有多大？
两层拓扑 （节点内 NVLink + 节点间 IB） 使用三阶段串行分层 AllReduce 公式 (见 6.5 多跳拓扑建模)。
H100 16-GPU 2-node (Crusoe IB NDR) 参数校准 （网格搜索，17 个数据点，64 KB ~ 2 GB）：
| 参数 | 搜索范围 | 含义 |
|---|---|---|
| $u_{NV}$ （NVLink 利用率） | 0.85 ~ 0.98 | NVLink 带宽利用率 |
| $\beta_{IB}$ (GB/s) | 50 ~ 400 | IB 有效带宽 （取决于 NCCL 使用几个 NIC） |
| $\alpha_{nv}$ ($\mu s$) | 0 ~ 30 | NVLink 固定延迟 |
| $\alpha_{ib}$ ($\mu s$) | 0 ~ 50 | IB 固定延迟 |
| $T_{sw}$ ($\mu s$) | 0 ~ 20 | NCCL kernel launch + GPU barrier |
| 最优 RMSPE | 9.9% |
@tbl-model-verify-twolayer-grid 两层拓扑网格搜索参数与最优 RMSPE
旧代码 Bug 与修正的 RMSPE 对比：
| 版本 | group_size | 合并方式 | RMSPE |
|---|---|---|---|
| 旧代码 (Bug) | 2 （错误） | max （错误） | 42.5% |
| 正确公式 （串行 sum） | 8 （正确） | sum （正确） | 9.9% |
@tbl-model-verify-twolayer-bugfix Bug 修复前后 RMSPE 对比
跨节点验证汇总 （多种互联类型，均使用分层公式 + 网格搜索标定）：
| 数据集 | 数据点 | 消息范围 | 最优 RMSPE | 主要限制 |
|---|---|---|---|---|
| H100 IB NDR 16-GPU (Crusoe) | 17 | 64 KB ~ 2 GB | 9.9% | 小消息参数不可辨 |
| H100 IB NDR 16-GPU (Nebius) | 5 | 512 MB ~ 8 GB | 7.5% | 仅大消息数据点 |
| H100 RoCEv2 16-GPU (Oracle) | 5 | 1 GB ~ 16 GB | 5.4% | 仅大消息，IB 参数不可辨 |
| GH200 RoCE 2-GPU 2-node | 21 | 8 B ~ 2 GB | 33% | 中间消息段 RoCE 爬坡曲线偏差 |
| A100 RDMA 16-GPU (Oracle) | 11 | 32 MB ~ 1 GB | 67% | 数据质量问题 + RDMA 主导 |
| H20 RoCE 16-GPU (Asterfusion) | 24 | 512 B ~ 17 GB | 57% | ECMP 哈希冲突导致流量退化 |
@tbl-model-verify-twolayer-summary 各跨节点数据集的最优 RMSPE
误差来源是什么
核心问题：RMSPE 在小 / 中 / 大消息分别主要来自什么？哪些能修，哪些不能？
| 消息区间 | 主导因素 | 误差来源 |
|---|---|---|
| < 1 MB | 延迟主导 ($\alpha$ 决定) | $\alpha$ 参数估计误差 + NCCL 软件层开销 （模型未建模） |
| 1 ~ 64 MB | 过渡区 | 两者混合，$\beta(n)$ 曲线非线性 |
| > 64 MB | 带宽主导 ($\beta \cdot u_r$ 决定) | 带宽利用率 $u_r$ 估计误差 |
@tbl-model-verify-error-by-size 按消息大小分段的误差来源
分层误差来源：
-
$\alpha$ 高估 （方法 A 的系统性问题）：将所有 $N-1$ 步的全部 DMA / 协议开销叠加，但流水线稳定后这些开销大部分被掩盖。方法 B 将小消息误差从 150% 降至 18%。
-
NCCL 软件层开销 （所有场景的残差来源）：本模型建模硬件协议层延迟，不包含 NCCL kernel launch + GPU barrier (约 15–60 $\mu s$)。小消息中此开销占主导比例，导致模型预测系统性偏低。
-
NVLS 超线速 （H200 / B200 场景的结构性限制）：NVSwitch 网内计算 (in-network reduction) 使 AllReduce 步数从 $2(N-1)$ 降到 2 步，BusBW 超过物理线速。$\alpha$-$\beta$ 无法建模此效应。
-
ECMP 哈希冲突 （跨节点场景）：交换机等价多路径路由 (ECMP) 的哈希冲突导致某些流共享同一物理链路，实测 BusBW 出现非单调下降 （大消息反而更慢）。分析模型无法捕捉此行为。
模型在哪些场景可用 / 不可用
核心问题：工程上哪些 LLM 场景适合用本模型，哪些必须谨慎？
模型精度好的场景 （可达 RMSPE < 10%）：
| 场景 | RMSPE | 条件 |
|---|---|---|
| 单层拓扑大消息 AllReduce (> 64 MB) | < 5% | 正确标定 $u_r$，无 NVLS |
| 两层拓扑大消息 AllReduce （NVLink 主导） | 5~10% | 分层公式 + 网格搜索标定 |
| IB 节点间主导 （足够 NIC，大消息） | 7~10% | 参数校准后 |
@tbl-model-verify-good-cases 精度可用的场景
模型精度差的场景 （RMSPE > 30%，需谨慎使用）：
| 场景 | RMSPE | 根本原因 |
|---|---|---|
| 小消息 (< 1 MB) | 50~150% | NCCL 软件层开销未建模 |
| H200 / B200 NVLS 场景 | ~13% （大消息） + 更高 （小消息） | NVLS 超线速效应 |
| ECMP 退化场景 | > 50% | 流量非均衡无法建模 |
| AllToAll 大规模 (> 512 GPU) | > 100% | $N \times N$ 全局竞争 + CPU 串行瓶颈 |
| SHARP 网内计算 | > 50% | 算法结构改变，分层公式不适用 |
@tbl-model-verify-bad-cases 精度不可用 / 需谨慎的场景
工程建议：
- 推理场景 TP AllReduce （消息通常 > 10 MB）：模型精度 10–30%，可用于量级估算和并行策略对比
- 训练场景 DP AllReduce （消息数十 GB）：大消息段精度好，但竞争建模不足，实际吞吐需测量验证
- 小消息场景 (< 1 MB)：不建议使用 $\alpha$-$\beta$ 模型，误差过大
Takeaway
| 知识点 | 核心结论 |
|---|---|
| 单层 RMSPE | 大消息 < 5%，整体 8-9%；方法 B 比方法 A 整体 RMSPE 77% → 16% |
| 两层 RMSPE | 网格搜索 + 串行三阶段公式，H100 IB NDR 9.9% |
| 旧公式 Bug | group_size 错 + max 合并使 RMSPE 42.5%，修正后 9.9% |
| 误差分段 | < 1 MB 由 $\alpha$ + NCCL 软件层主导，> 64 MB 由 $u_r$ 决定 |
| 结构性失效 | NVLS / SHARP / ECMP / 大规模 AllToAll, RMSPE > 30% |
| 工程边界 | 推理 TP (> 10 MB) 可用；小消息 (< 1 MB) 不建议 |