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