384 卡集群验收与性能基线：从硬件核对到 NCCL busbw

验收最怕"跑通了算完"——跑通只证明功能存在，不证明性能达标、更不证明边界在哪。本文是 384 卡 L40S IB 集群的验收路径：分层核对、基线存档、不达标逐层排查，每一步都在证伪而不是确认。

1. 验收哲学：逐步证伪，而不是"跑通即通过"

验收不是一次大检查，是分层证伪：

层	验证什么	通过标准
硬件层	BOM 与实测一致	内存 24×32GB@4800、PCIe 16GT/s x16、7 块网卡
网络层	IB 链路与拓扑正确	ibstat Active、ib_write_bw 接近线速、拓扑局部性生效
系统层	版本一致 + 参数统一	包版本一致、Ansible --check 零变更
性能层	基线达标	STREAM/HPL/NCCL 达到预期区间
稳定性	长跑不炸	72h 压测无 OOM/挂死/降速

判断：每一层通过只证明"这层没问题"，不能顺带证明上一层——所以验收顺序必须从下往上，每层独立存档。

2. 硬件核对：BOM 不是"出厂即对"

• 上电自检逐台核对：dmidecode（内存）、lspci（PCIe 速率、网卡数）、nvidia-smi（8 卡识别）；
• 拓扑核对：nvidia-smi topo -m 确认 GPU/NIC 与 NUMA 归属，偏差直接改亲和脚本；
• RAID 核对：系统卷 RAID1、写缓存 Enabled（storcli 查）。

3. 网络与性能基线：三张表存档

IB 网络基线（每节点）：

ibstat                  # Port Active, Rate 200
ib_write_bw -a          # 单口接近 200G 线速
ib_read_lat             # 时延在预期区间

计算基线（抽测 + 全量）：

基准	目标	用途
STREAM	达理论带宽 85%+	内存子系统健康
HPL（CPU/GPU）	达预期效率区间	算力交付
NCCL allreduce	busbw 随节点数线性	拓扑正确性
FIO	存储带宽达标	数据面

关键：基线不是"测一次"，是记录环境快照（版本、参数、拓扑）与数值一起存档——否则三个月后对比时不知道基线是什么环境下测的。

4. 不达标怎么办：逐层排查，不调参数瞎试

NCCL busbw 不随节点数线性增长时，排查顺序：

1. 拓扑：4 口是否真的各入 4 个 rail？错接 = 拓扑失效（ibstat/交换机端口核对）；
2. 驱动/模式：LINK_TYPE 是否 IB、MLNX_OFED 版本是否匹配；
3. 系统：C-states 是否禁深睡眠、中断亲和是否钉对；
4. 参数：NCCL_GDR/P2P 是否生效（NCCL_DEBUG=INFO 看路径）；
5. 应用：绑核是否正确、消息大小是否饱和。

原则：一次只改一个变量，改完重测、记录、对比。混着改三个参数"试出"的性能，无法回退、无法复现、无法归档。

5. 交付清单

1. 硬件层：BOM、拓扑、RAID 三核对全过，偏差记录在案；
2. 网络层：ibstat/ib_write_bw/ib_read_lat 每节点达标；
3. 性能层：STREAM/HPL/NCCL/FIO 基线 + 环境快照存档；
4. 稳定性：72h 压测通过；
5. 排查路径文档化：不达标时的逐层 checklist 固化到交付文档。

---

本文基于 384 卡 L40S IB 集群交付实测整理；具体版本号与命令以现场实测为准。