Initial commit

learnings/2026-07-20-001-gpu-server-network-review.md

@@ -0,0 +1,122 @@
+---
+id: 2026-07-20-001
+date: 2026-07-20
+status: distilled
+tags: [gpu-server, network, pcie, numa, nccl, training, inference]
+sources: [user-provided instruction]
+references:
+  - "nvidia-smi topo -m（用户提及，本次未独立核验）"
+  - "NCCL logs and nccl-tests（用户提及，本次未独立核验）"
+---
+
+# GPU 服务器网络配置五步评审法
+
+## 原始输入
+
+> 学习：以后评审 GPU 服务器配置，不要只问“几卡几网”。
+> 建议按五步算。
+>
+> 第一步：算外部网卡出口
+> 比如：
+> 8 张 400G NIC = 3.2T 网络出口。
+> 4 张 400G NIC = 1.6T 网络出口。
+> 注意是 bit，不是 byte。
+>
+> 第二步：算 PCIe 主机侧带宽
+> 看每张 NIC 是：
+> PCIe 4.0 x16
+> PCIe 5.0 x16
+> PCIe 5.0 x8
+> 是否共享 PCIe Switch 上行
+> 如果 PCIe 主机侧喂不满，网卡端口标多大都没用。
+>
+> 第三步：算 GPU 到 NIC 路径
+> 看：
+> 是否同 NUMA
+> 是否同 PCIe Switch
+> 是否跨 socket
+> 是否共享上行
+> 是否 Socket Direct
+> 是否拓扑一致
+>
+> 第四步：算业务通信需求
+> 训练要看：
+> AllReduce / ReduceScatter / AllGather
+> MoE All-to-All
+> 通信占 step 比例
+> 多机规模
+> bucket / overlap
+> checkpoint 干扰
+> 推理要看：
+> 多机 TP
+> KV Cache 迁移
+> P/D 分离
+> TTFT / p99
+> Decode 热路径
+>
+> 第五步：验证 NCCL 是否真能用起来
+> 看：
+> nvidia-smi topo -m
+> NCCL 日志
+> nccl-tests
+> HCA 利用率
+> 每条 rail 流量
+> slow rank
+> CNP / ECN / PFC
+> step time
+
+## 内容蒸馏
+
+评审 GPU 服务器通信配置不能停留在 GPU 和 NIC 的数量或端口标称速率，而应沿着“外部出口—主机侧入口—GPU 到 NIC 路径—业务需求—运行时实测”逐层核算。每一层都可能成为约束，前一层的峰值规格只有在后续路径、拓扑、workload 和软件运行时都能承接时才有意义。
+
+五步方法如下：
+
+1. **外部网卡出口**：先把 NIC 数量乘以单端口速率，得到聚合标称出口。示例中，8 张 400G NIC 对应 3.2 Tbit/s，4 张对应 1.6 Tbit/s；这里的单位是 bit/s，不是 byte/s。
+2. **PCIe 主机侧带宽**：逐卡确认 PCIe 代际和 lane 数，例如 PCIe 4.0 x16、PCIe 5.0 x16 或 PCIe 5.0 x8，并检查多张设备是否共享 PCIe Switch 上行。若主机侧路径无法持续供给端口速率，NIC 的标称带宽不是可达带宽。
+3. **GPU 到 NIC 路径**：检查 GPU 与 NIC 是否处于同一 NUMA node 或 PCIe Switch，是否跨 socket、共享上行、采用 Socket Direct，以及各 GPU/NIC 路径是否对称一致。不能只看单个器件规格而忽略端到端拓扑。
+4. **业务通信需求**：训练侧结合 AllReduce、ReduceScatter、AllGather、MoE All-to-All、通信占 step 比例、多机规模、bucket 与 overlap、checkpoint 干扰来评估；推理侧结合多机 TP、KV Cache 迁移、P/D 分离、TTFT、p99 和 Decode 热路径来评估。硬件是否合适由具体通信模式和服务目标决定。
+5. **NCCL 与端到端验证**：使用 `nvidia-smi topo -m`、NCCL 日志和 `nccl-tests` 检查拓扑识别与通信能力，同时观察 HCA 利用率、每条 rail 的流量、slow rank、CNP / ECN / PFC 信号和最终 step time，确认理论配置是否在真实运行时兑现。
+
+## Taste 信号
+
+### 明确偏好
+
+- 以后评审 GPU 服务器配置时，不接受只问“几卡几网”或只复述端口标称规格。
+- 建议固定按五层核算：外部 NIC 聚合出口、PCIe 主机侧带宽、GPU 到 NIC 拓扑路径、训练或推理的实际通信需求、NCCL 与端到端运行指标。
+- 带宽计算必须明确 bit 与 byte，避免单位混淆。
+- 纸面规格必须通过拓扑、通信库、链路计数器和业务指标验证，不能直接当成应用可用带宽。
+
+### 推断信号
+
+- 偏好用端到端瓶颈链路而非器件清单评审系统：任何共享上行、跨 socket 路径或拓扑不一致都可能使聚合规格失真。
+- 偏好把硬件配置判断绑定到 workload；训练 collectives、MoE 和推理的 TP、KV Cache、P/D 分离具有不同通信模式，不能用同一峰值数字代替分析。
+- 偏好同时观察平均能力、路径均衡和尾部异常；slow rank、每 rail 流量、p99 与 step time 都是验收信号。
+
+### 领域知识
+
+- NIC 数量乘以每端口标称速率可得到聚合线速上界，但该结果使用 bit/s，且不等于应用有效吞吐。
+- PCIe 代际、lane 数和 Switch 上行共享关系决定主机侧能否承接 NIC 线速。
+- NUMA、PCIe Switch、socket、共享上行、Socket Direct 和路径对称性会影响 GPU 到 NIC 的通信路径。
+- 训练通信评审需要覆盖 collective 类型、MoE All-to-All、规模、overlap 和 checkpoint；推理通信评审需要覆盖多机 TP、KV Cache 迁移、P/D 分离与延迟热路径。
+- 拓扑命令、NCCL 日志与测试、HCA/rail 计数器和端到端业务指标共同构成从配置到实际效果的证据链。
+
+## 边界与反例
+
+- 聚合 NIC 线速是理论入口，不是验收结论；协议开销、传输方向、消息大小、并发、路由、拥塞和软件栈都可能使实际吞吐低于标称值。
+- 五步法主要评审 GPU 服务器的通信子系统。算力、HBM 容量与带宽、CPU 内存、存储、功耗、散热、可靠性和运维仍需另行检查。
+- 不同 collective、模型并行策略和服务目标需要不同指标与 workload，不能只用 `nccl-tests` 峰值替代训练 step time、TTFT 或 p99。
+- 列出的 PCIe 形态和观测项是检查维度，不构成固定的合格阈值；材料没有给出 oversubscription、利用率或延迟的通用判定线。
+- Socket Direct、同 NUMA 或路径对称通常是重要拓扑信号，但单一特征不能脱离整机布线、路由策略和实测结果独立判定优劣。
+
+## 可执行影响
+
+- 收到 GPU 服务器 BOM、拓扑图或采购方案时，先建立五层表格，分别记录理论上界、共享关系、潜在瓶颈、待核验信息和实测证据。
+- 所有带宽数字显式标注 `bit/s` 或 `byte/s`；做换算时写出倍率，区分聚合端口线速与有效 payload 吞吐。
+- 为每张 NIC 记录 PCIe generation、lane width、Switch/CPU 上行及共享设备；为每组 GPU-NIC 记录 NUMA、PCIe Switch、socket、rail 和路径对称性。
+- 在给出“配置足够”的结论前，先固定训练或推理 workload、并行策略、多机规模和目标指标，再估算通信量及可 overlap 部分。
+- 验收时组合静态拓扑、NCCL 路径日志、微基准、链路/拥塞计数器和端到端指标；若它们不一致，优先定位 slow rank、rail 不均衡、跨 socket 或共享上行等具体约束。
+- 报告中区分纸面上界、基准可达值和业务实测值，并明确尚未获得的证据，不用“几卡几网”替代结论。
+
+## 画像更新
+
+- 新增：[GPU 服务器评审 / 从端口规格追到业务有效带宽](../TASTE.md#gpu-服务器评审--从端口规格追到业务有效带宽)