硬件与基础设施：GPU/TPU 等加速器特性、CPU、内存、NVLink/InfiniBand 等互联技术

大模型训练的每一次迭代，本质上是数据在“计算单元—存储层次—互联网络”之间高速流动的过程。当模型规模达到千亿甚至万亿参数时，单卡算力早已不是瓶颈，瓶颈转移到了硬件系统的协同效率上。本章从加速器核心特性出发，逐层拆解 CPU、内存与互联技术如何共同决定集群的实际吞吐，并给出可操作的选型与配置方法。

4.1 加速器核心特性：从峰值算力到有效算力

GPU 与 TPU 的标称算力（TFLOPS）只是理论峰值，实际训练中能达到的算力利用率（MFU，Model FLOPs Utilization）通常在 40%～60% 之间。理解加速器特性，首先要区分三个关键指标：

峰值算力（Peak TFLOPS）：硬件在理想时钟频率、无内存停顿下的最大浮点运算次数，通常区分 FP16/BF16 与 FP32。
内存带宽（Memory Bandwidth）：加速器从显存读取数据的速率，单位 GB/s。Transformer 中的 LayerNorm、Softmax 等算子属于内存密集型，带宽不足会直接拉低 MFU。
互连带宽（Interconnect Bandwidth）：加速器之间或加速器与 CPU 之间的数据交换速率，决定张量并行与流水线并行的通信开销。

以 NVIDIA H100 SXM 为例，其 BF16 峰值算力约 989 TFLOPS，HBM3 内存带宽 3.35 TB/s，NVLink 双向带宽 900 GB/s。但实际训练中，若使用 8 卡张量并行，每步迭代的 All-Reduce 通信量约为模型参数量的 2 倍（ZeRO 阶段除外），通信占比可能达到 15%～25%。因此，有效算力 = 峰值算力 × 计算密度 × 通信效率，三者缺一不可。

选型判断依据：当模型单层参数量超过 1B 时，优先关注显存容量与 HBM 带宽；当模型并行度超过 32 卡时，优先关注 NVLink/InfiniBand 拓扑与拥塞控制能力。

4.2 CPU 与内存：被低估的“慢速路径”

CPU 在大模型训练中承担三类职责：数据预处理（DataLoader）、算子调度（Launch Kernel）、以及分布式通信的编排（如 NCCL 的 CPU 端初始化）。CPU 性能不足时，会出现 GPU 等待数据的“气泡”（Bubble），表现为 GPU 利用率周期性掉零。

内存子系统则包含三个层级：CPU 主存（DDR5）、加速器显存（HBM）、SSD 缓存。训练数据的读取路径通常是：SSD → CPU 内存 → GPU 显存。若 CPU 内存带宽不足，或 PCIe 通道数不够，数据加载会成为瓶颈。

一个典型的 7B 模型训练场景，训练集约 1TB，DataLoader 每 epoch 需要读取全部数据。若使用 8 卡节点，每卡每步消费 4K tokens，则每步需读取约 16MB 数据。在 PCIe Gen5 x16（单向带宽约 64GB/s）下，理论传输仅需 0.25ms，但实际因 CPU 拷贝与内存分配开销，可能放大到 2～5ms。若 GPU 每步计算仅需 50ms，则数据加载占比约 10%，尚可接受；但当模型规模增大、每步计算缩短到 20ms 时，数据加载就会成为显著瓶颈。

# 检查 CPU 内存带宽与 NUMA 拓扑（Linux）
numactl --hardware
# 查看 PCIe 链路速率与带宽
lspci -vvv | grep -E "LnkSta:|LnkCap:"
# 监控 GPU 利用率与数据加载等待时间
nvidia-smi dmon -s puc -d 1

4.3 互联技术：NVLink、InfiniBand 与集群拓扑

互联技术决定了多卡、多节点之间的通信效率。当前主流方案分为两类：节点内互联（NVLink/NVSwitch）与跨节点互联（InfiniBand/RoCE）。

4.3.1 NVLink 与 NVSwitch：节点内全互联

NVLink 是 NVIDIA 私有点对点互联协议，提供高带宽、低延迟的 GPU-GPU 通信。在 8 卡 H100 节点中，NVSwitch 实现全互联拓扑，任意两张 GPU 之间的通信带宽均为 900 GB/s（双向）。这意味着张量并行（Tensor Parallelism）所需的 All-Reduce 操作可以在节点内高效完成。

关键配置参数：

NVLink 连接数：H100 SXM 每卡 18 条 NVLink 连接，PCIe 形态（如 H100 PCIe）仅 12 条，带宽下降约 33%。
NVSwitch 数量：8 卡节点通常配备 4 颗 NVSwitch，任何 GPU 到 NVSwitch 的带宽均等。
拓扑感知：NCCL 支持通过 NCCL_TOPO_DUMP_FILE 导出拓扑文件，用于优化通信路径。

4.3.2 InfiniBand：跨节点扩展的脊梁

跨节点通信依赖 InfiniBand（IB）或 RoCE（RDMA over Converged Ethernet）。IB 提供无损网络传输，支持自适应路由与拥塞控制，是大规模集群的首选。当前主流为 HDR（200Gbps）与 NDR（400Gbps）规格。

集群拓扑通常采用 Fat-Tree（胖树）或 Torus（环状）结构。胖树拓扑提供全带宽无阻塞通信，但需要更多交换机；Torus 拓扑节省成本，但多跳通信延迟增加。对于 1000 卡以上集群，推荐采用胖树 + 自适应路由的组合。

互联类型	带宽（单向）	延迟	适用场景
NVLink 4.0（SXM）	450 GB/s	~1.2μs	节点内张量并行
PCIe Gen5 x16	64 GB/s	~2.0μs	CPU-GPU 数据交换
InfiniBand NDR	50 GB/s	~1.5μs	跨节点数据并行/流水线并行
RoCE v2	25～50 GB/s	~3.0μs	低成本跨节点方案

4.4 方法流程：从硬件选型到拓扑验证

硬件基础设施的调优不是一次性工作，而是一个持续验证与迭代的过程。推荐以下流程：

需求分析：根据模型参数量、序列长度、全局批量大小，估算显存需求与通信量。例如，175B 模型使用 Adam 优化器，需要至少 2.8TB 显存（参数+梯度+优化器状态），因此至少需要 32 张 H100（80GB）。
选型与配置：确定加速器型号、CPU 核数（建议每 GPU 至少 16 核）、内存容量（建议每 GPU 至少 256GB 系统内存）、互联规格（节点内 NVLink，跨节点 IB）。
拓扑验证：使用 NCCL 的 all_reduce_perf 工具测试节点内与跨节点带宽，确认是否达到理论值的 80% 以上。
参数调优：设置 NCCL_IB_GID_INDEX、NCCL_IB_TIMEOUT、NCCL_BUFFSIZE 等环境变量，优化通信行为。
持续监控：部署 DCGM（Data Center GPU Manager）监控 GPU 温度、功耗、NVLink 错误率，以及 IB 交换机的丢包与重传计数。

# 节点内 NVLink 带宽测试（8 卡）
mpirun -np 8 -H node01:8 \
  /usr/local/nccl_2.20.5/build/all_reduce_perf \
  -b 128M -e 8G -f 2 -g 1

# 跨节点 IB 带宽测试（2 节点各 8 卡）
mpirun -np 16 -H node01:8,node02:8 \
  /usr/local/nccl_2.20.5/build/all_reduce_perf \
  -b 128M -e 8G -f 2 -g 1

4.5 案例：千卡集群的互联瓶颈定位

某团队部署 128 节点（每节点 8 卡 H100）集群训练 70B 模型，发现 MFU 仅 32%，远低于预期的 45%。通过 nvidia-smi dmon 观察，GPU 利用率周期性跌至 20%，且伴随 NVLink 错误计数上升。

排查步骤：

第一步，检查节点内通信：运行 all_reduce_perf，发现 8 卡带宽仅 600 GB/s（理论 900 GB/s），定位到 NVSwitch 固件版本过旧。
第二步，升级 NVSwitch 固件后，节点内带宽恢复至 850 GB/s，但 MFU 仅提升至 36%。
第三步，检查跨节点通信：使用 ib_write_bw 测试 IB 带宽，发现 2 节点间带宽仅 35 GB/s（理论 50 GB/s），进一步检查发现 IB 交换机端口存在 CRC 错误。
第四步，更换 IB 线缆并启用自适应路由后，跨节点带宽恢复至 48 GB/s，MFU 最终提升至 44%。

常见误区：不要只关注 GPU 利用率而忽略通信错误。NVLink 或 IB 的静默重传（Silent Retransmission）不会直接报错，但会显著增加延迟。务必定期检查 nvidia-smi -q -d NVLINK 与 ibstat 的错误计数。

4.6 误区与复盘：硬件调优的五个陷阱

误区一：只看峰值 TFLOPS。忽略内存带宽与互连带宽，导致选型后 MFU 远低于预期。
误区二：CPU 核数不足。DataLoader 使用多进程时，CPU 核数少于 GPU 卡数的 2 倍，会造成数据供给中断。
误区三：PCIe 通道分配不当。GPU 与 NVMe SSD 争抢 PCIe 通道，导致数据加载与梯度同步互相干扰。
误区四：IB 拥塞控制未开启。默认配置下，多节点 All-Reduce 容易触发 PFC 死锁，表现为带宽骤降。
误区五：忽略 NUMA 亲和性。GPU 与 CPU 跨 NUMA 节点访问时，内存延迟增加 30% 以上，影响 H2D 拷贝效率。

硬件与基础设施的调优，本质上是在“算力、带宽、延迟、成本”四者之间寻找平衡。加速器决定了计算上限，互联技术决定了扩展效率，而 CPU 与内存则决定了数据供给的稳定性。下一层级的软件栈（如 NCCL 配置、并行策略）都建立在这套硬件基础之上，只有将硬件特性吃透，才能为后续的通信优化与算子调优打下坚实基础。