Files
ai-dist/learnings/2026-07-20-001-gpu-server-network-review.md
2026-07-20 15:26:30 +08:00

123 lines
6.9 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
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/s4 张对应 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-服务器评审--从端口规格追到业务有效带宽)