1. 带宽测试概述：为什么带宽是AI训练的命脉？
做AI训练这么多年，我见过太多团队把精力全砸在模型架构上，结果一跑起来，GPU利用率惨不忍睹。说白了，你的模型再牛，数据喂不进去也是白搭。今天咱们就来聊聊这个最基础、也最容易被忽视的问题——带宽。
1.1 带宽、延迟与吞吐量：别再傻傻分不清
这三个词经常被混着用，但它们的区别，直接决定了你的训练效率。我习惯用一个水管比喻来解释：
- 带宽：水管有多粗。单位是GB/s或Gbps。它决定了数据搬运的“上限速度”。
- 延迟：水龙头打开后，水多久能流到你家。单位是微秒(μs)或毫秒(ms)。它决定了“第一次握手”的速度。
- 吞吐量：你家水龙头实际接了多少桶水。单位是样本/秒或TFLOPS。它才是你真正关心的训练速度。
嗯，这里要注意：带宽是理论值，吞吐量是实际值。中间差的那一大截，就是各种开销和瓶颈。我在项目中遇到过，有人买了800Gbps的网卡，结果吞吐量只有理论值的30%，一查发现是PCIe链路没配好——这就是典型的“水管够粗，但阀门没拧开”。
核心观点： 带宽决定了你的训练能不能“吃饱”，延迟决定了你“饿不饿死”。对于AI训练这种大规模并行计算，带宽往往是第一瓶颈。
1.2 为什么带宽是AI训练的命脉？
你想想看，现在的大模型动辄几百亿参数。训练一次，数据要在GPU、CPU、内存、网络之间来回搬运无数次。每一次搬运，都在消耗带宽。
具体来说，带宽影响三个关键环节：
- 数据加载：从硬盘读到内存，再从内存搬到GPU显存。如果带宽不够，GPU就只能干等着——这就是所谓的“I/O瓶颈”。
- 梯度同步：多卡训练时，每张卡算完梯度，要互相交换数据。这个环节对网络带宽极其敏感。我记得有一次调一个千卡集群，发现通信时间占了总训练时间的40%，就是因为网络带宽被其他任务抢占了。
- 模型并行：当模型大到一张卡放不下，需要切分到多张卡上。每张卡算完一部分，要频繁地把中间结果传给下一张卡。这时候，卡间带宽（比如NVLink）就是命根子。
个人经验： 我建议你在开始大规模训练前，先跑一遍带宽测试。这花不了多少时间，但能帮你提前发现90%的硬件配置问题。我曾经就因为没做这个测试，浪费了整整一周的集群排期——教训深刻。
1.3 带宽测试的核心逻辑
说白了，带宽测试就是测量数据从一个地方搬到另一个地方的速度。但怎么测、测什么，这里头有讲究。
我一般把带宽测试分成三个层次：
| 层次 | 测试对象 | 典型工具 | 关注点 |
|---|---|---|---|
| 节点内 | CPU↔GPU, GPU↔GPU | nvidia-smi, bandwidthTest | PCIe带宽、NVLink带宽 |
| 节点间 | 跨机器网络 | iperf, NCCL tests | 网卡带宽、交换机瓶颈 |
| 端到端 | 数据加载+训练 | 自定义profiling | 实际吞吐量、瓶颈定位 |
为什么会这样分层？因为不同层次的瓶颈，表现完全不一样。节点内带宽不够，你会看到GPU利用率忽高忽低；节点间带宽不够，你会看到通信时间占比异常高。
1.4 一张图看懂带宽测试知识体系
下面这张图，是我自己总结的带宽测试知识框架。你可以把它当作整个课程的地图：
避坑指南： 我曾经犯过一个低级错误——只测了节点内带宽，就以为万事大吉。结果上了集群，发现跨节点通信慢得像蜗牛。后来才意识到，节点间网络才是大规模训练的“隐形杀手”。所以，三个层次的测试，一个都不能少。
1.5 一个简单的带宽测试示例
光说不练假把式。这里给一个最基础的GPU带宽测试命令，用NVIDIA官方的bandwidthTest工具：
# 测试GPU到GPU的带宽（同一节点内）
./bandwidthTest --device 0 --device 1
# 输出示例：
# [GPU] Device 0: Tesla A100
# [GPU] Device 1: Tesla A100
# Bandwidth: 112.5 GB/s (NVLink)
# 注意：如果走PCIe，带宽会降到25 GB/s左右这个命令很简单，但能告诉你很多信息。比如，如果测出来带宽远低于理论值，那就要检查：是不是有别的进程在抢带宽？PCIe链路是不是降速了？NVLink是不是没连上？
嗯，这里有个小技巧：我习惯在跑训练前，先跑一遍这个测试，把结果记录下来。这样一旦训练中出现性能问题，就能快速对比，判断是不是硬件出了问题。
个人建议： 别只看峰值带宽。多测几次，取平均值，看看波动大不大。如果波动超过10%，说明系统不稳定，需要排查。我曾经遇到过电源供电不足导致带宽波动的情况，就是通过这个办法发现的。
好了，这一章我们理清了带宽、延迟、吞吐量的区别，也知道了为什么带宽是AI训练的命脉。下一章，我会带你手把手搭建带宽测试环境，从硬件配置到软件安装，一步步来。