AI训练和推理为什么需要高速网络
一个训练团队先用单张GPU把模型跑了起来，估算完整训练要八天。为了赶进度，他们把任务扩到八张卡，心里的算盘打得很直接：算力翻了八倍，一天左右总该结束了吧。
结果任务真跑起来，八张卡都在忙，训练时间却只缩到三天。等任务跨到第二台服务器，GPU利用率还会一阵一阵地往下掉。盯着监控看会发现一个奇怪的画面：最先算完的那张卡并没有立刻进入下一轮，而是停在原地，等其他卡把答案传回来。
网络在AI里最要紧的作用，恰恰就发生在这一刻——计算已经拆开了，结果却必须重新汇到一起。
这篇导读不讲交换机怎么配置，而是想先陪你走完一轮训练，看清网络到底是从哪一步挤进计算过程的，再把后面要学的概念一个个放到它们该在的位置上。
人手加多了，大家却都堵在电梯口
可以把这场训练想象成一次集体搬家。一个人干的时候，既要打包又要搬运，快慢基本就看个人体力。换成八个人分头进不同房间，打包这一环明显快了；可每完成一轮，所有箱子都得挤进同一部电梯运到楼下清点。
要是这部电梯又窄又慢，先打包完的人就只能在门口干等。你会发现一个反直觉的现象：人手一多，房间里的活是快了，电梯前排的队反而更扎眼了。分布式计算也是这样，它天生包含"各自计算"和"彼此通信"两段时间——加GPU主要压缩的是前一段，却可能把后一段放得更大。
所以卡多，并不保证就能按比例加速。多出来的那点计算收益，必须大过通信、同步和等待添出来的成本。把这层关系想明白，才算真正踏进了AI网络的门。
一轮数据并行，网络是在哪一步进场的
设想有四张GPU，每张都存着一份一模一样的模型，各自处理一小批不同的训练数据。它们做完前向计算和反向传播，会各自得到一份梯度。可问题来了：如果每张卡都拿自己那份梯度直接更新模型，四份模型很快就会各走各的路，越跑越不像同一个模型。
所以在进入下一轮之前，它们必须先把梯度汇总，再让每张卡都拿到同样的结果。这类活儿通常交给AllReduce来干：所有参与者一起对数据做一次归约运算，归约后的结果再分发回每一个参与者手里。NCCL这类集合通信库，会根据GPU数量、消息大小和互联拓扑，自动挑环形、树形或者组合算法来完成传输。第一次读到这里，你完全不用急着钻研算法细节，只要先记住AllReduce在这轮训练里的角色就够了：它让各算各的GPU重新对齐，好接着一起训练同一个模型。
也正因为大家绑在了一起，网络一慢，遭殃的就不止某一张卡。同步训练里，只要有一个进程算得慢、一条链路堵了、或者某个节点抖了一下，整组GPU都得陪着一起等。单看一次也许只慢几毫秒，可成千上万轮累下来，就是一段实打实的训练时间。
带宽、延迟和拥塞，说的是三种不同的"等"
工程师发现通信变慢，第一反应通常是去看带宽。带宽回答的是"一秒能搬多少数据"。梯度和张量都很大的时候，通道有多宽，直接决定一轮传输要花多久。
但要留个心眼：网卡上标的100Gb/s或者400Gb/s，只是链路的规格。数据真跑起来，还得穿过PCIe、网卡、各层协议和交换网络，应用最后实际拿到的速度，往往要比标称值低一截。
另一些任务，每次要传的数据其实不大，却传得特别频繁。这时候更该盯的是延迟，也就是一条消息从发出到抵达，中间要等多久。带宽再大，也只是让大块数据搬得更快，它并不能抹掉每次传输启动和转发所需的那段固定时间。
还有一种情况：许多GPU差不多同时算完，流量呼啦一下全涌进网络。交换机端口或者共享的上行链路一旦接不住，消息就开始排队，这就是拥塞。排队会把延迟顶高，一旦丢包、要重传，又反过来啃掉带宽。所以这三个词，不是采购表上并排的三个参数，而是帮工程师判断"数据为什么没能按时到"的三个观察角度。
再往深里学，你还会碰到有效带宽、尾部延迟、丢包、拥塞控制、通信与计算重叠这些概念。但在入门阶段，先把它们和"GPU在等谁"这件事挂上钩，比单独背下每一条定义都管用。
节点内还是节点外，决定了消息要跑多远
在一台服务器内部，多张GPU一般通过PCIe通信，有些机型还提供NVLink、NVSwitch这类带宽更高的互联。可任务一旦跨到另一台服务器，消息就得先过网卡、穿过交换网络，再钻进目标GPU。原本在机箱里几步就能完成的交换，一下子变成了一段长途跋涉。
拓扑，描述的就是这些设备和路径到底是怎么连起来的。两张需要频繁交换数据的GPU，要是被摆得很远，每一轮都要为通信多付出一点成本。所谓拓扑感知调度，就是希望在分配资源时别只数"还剩几张卡"，还得看看这些卡分别在哪台机器上、彼此又是通过什么路径连的。
这也顺带解释了开头那个疑问：集群里明明总共还空着八张GPU，一个八卡任务却未必能立刻开跑。因为那些空闲卡可能零散地分布在不同节点上——数量是够了，位置却让通信绕了一大圈远路。
RDMA、RoCE和InfiniBand，该摆在概念图的哪一格
当跨机路径成了瓶颈，工程师往下会接触到RDMA，也就是远程直接内存访问。它允许网卡在受控的条件下，直接读写已经注册好的远端内存，从而省掉操作系统内核路径上的多次复制、减少CPU的介入。GPUDirect RDMA更进一步，让兼容的网卡和GPU显存之间能通过DMA直接交换数据，不必先搬到CPU内存里再转一道手。
要看清这类技术的边界：它们解决的是"怎么让数据少绕路"，既不会凭空变出更多带宽，也消不掉交换网络里的拥塞。而且硬件拓扑、驱动和通信库要是没配合好，这条"直接路径"未必真能走通。
Ethernet、RoCE和InfiniBand，说的则是另一回事——网络体系和承载方式。Ethernet是应用最广的网络体系；RoCE是在以太网上承载RDMA的一条路线；InfiniBand则是一整套面向高性能计算和低延迟通信的网络架构，本身就支持RDMA语义。入门阶段不必急着给它们排座次。更靠谱的顺序，是先弄清自己的任务为什么要通信、通信量有多大、要跨多少个节点，再回过头看不同网络各自怎么满足这些要求。至于交换机配置、拥塞调优和具体的选型，留给后面的专题去处理就好。
训练和推理，对网络的依赖并不一样
大规模训练会让同一组GPU一遍遍地做集合通信。网络每一轮慢那么一点，累加起来就会把整个训练周期拖长，所以团队通常盯着整体吞吐、并行效率、稳定性和尾部抖动。
推理则要看模型是怎么部署的。如果是多个互相独立的副本、各自处理完整请求，GPU之间未必需要频繁通信；可一旦模型必须跨卡拆分，或者用上了预填充与解码分离、远端KV Cache、专家并行这些做法，中间状态就会进到网络里，链路延迟便可能直接体现成用户的等待时间。
所以学AI网络，心里得始终装着"负载"这件事。训练关心的是一项大任务最终跑多久，在线推理更在意的是某一个请求要等多久——两者用的概念很像，追求的目标却常常不同。
这条网络学习路线，可以怎么走
理解AI网络，不妨按问题冒出来的先后顺序，一层层往下学：
先学并行计算：搞清数据并行、张量并行、流水线并行分别会带来什么样的通信。
再学集合通信：认识Broadcast、Reduce、AllReduce、AllGather和All-to-All各自让参与者怎样交换数据。
接着学性能指标和拓扑：把带宽、延迟、拥塞、节点内互联和跨节点路径，都放进一轮真实任务里去观察。
最后进入网络技术：继续学NCCL、RDMA、GPUDirect RDMA、RoCE、InfiniBand，以及配套的监控和调优方法。
反过来说，如果你的任务只是在单张GPU上做本地推理，网络可能主要影响的是模型下载和远端数据读取，没必要一上来就跳进最复杂的集群网络。只有当模型或者状态开始跨越设备和节点的边界时，网络才慢慢变成AI计算本身的一部分。
接下来可以读什么
刚接触算力资源，可以先读算力总览打个底；准备动手做多卡训练，可以接着读集群导读，再进入数据并行、NCCL和AllReduce专题；如果你负责的是基础设施，那还得在这之上继续学RDMA、RoCE拥塞控制、网络拓扑和拓扑感知调度。
站内关联阅读
参考资料
PyTorch Distributed：https://docs.pytorch.org/docs/stable/distributed
PyTorch DistributedDataParallel：https://docs.pytorch.org/docs/stable/generated/torch.nn.parallel.DistributedDataParallel.html
NVIDIA NCCL User Guide：https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/overview.html
NVIDIA GPUDirect RDMA：https://docs.nvidia.com/cuda/gpudirect-rdma/contents.html
Meta, Building Meta's GenAI Infrastructure：https://engineering.fb.com/2024/03/12/data-center-engineering/building-metas-genai-infrastructure/