云栖大会的AI系统网络架构专场几乎每个分享时段都是满座。我在现场听过某团队讲他们训练集群的调优经历有一句话被反复提起网络是AI系统里最容易被低估、却又最能决定上限的环节。这话不夸张。GPU算力这些年涨得飞快但要同时调动几十上百块卡去算同一个任务卡与卡之间交换数据的效率跟不上整条训练流水线就得在这里空转。这篇文章我想把AI系统网络架构这条线完整梳理一遍AI场景为什么会让传统网络失效、主流方案怎么选型、硬件和拓扑怎么搭配、落地上有哪些必须调的参数以及我在真实项目里踩过的坑和排障经验。内容不一定高深但每一条都是能直接拿去用的东西。1. AI系统为什么把网络推到了聚光灯下1.1 大模型训练里的通信账本很多人第一次接触AI集群时第一反应是“算力够不够”但真正把训练跑起来之后才会明白通信往往是那个最先卡脖子的环节。拿一个500亿参数50B的模型举例。训练时每次迭代结束所有GPU要把自己算出的梯度同步一遍这个过程叫AllReduce。50B的参数每个参数至少对应1个梯度值梯度用常见的32位浮点表示就是4字节那一次全局同步的通信量就达到200GB。假如网络是400Gbps理论峰值每秒50GB即使不做任何优化光传完这份梯度就要4秒。实际训练里还要算上协议开销、拥塞和排队翻倍到8秒甚至更久都是常事。可以打个比方多卡训练像一队人分工打扫一套大房子每个人扫完自己负责的房间后必须把所有垃圾汇总分类才能决策下一步怎么处理。房间再多只要“汇总”这个动作没完成所有人都得停下来等。网络就是那条汇总通道通道越窄、越容易堵整套流程就越慢。所以AI系统对网络的第一条要求是在高并发集合通信模式下仍然能保持大带宽、低丢包。普通办公网络遇到突发流量时丢几个包无所谓TCP重传也能撑住训练场景下一个包丢了就可能让几百张卡同步等待损失以秒计。1.2 推理场景里的低延迟压力训练看重带宽和吞吐推理则更看重延迟和稳定性。现在大模型推理普遍用多卡张量并行模型被切分到多张卡上每生成一个token各卡之间都需要同步当前层的计算结果。这个同步动作就发生在一次推理的关键路径上网络哪怕多抖动一下用户的“首token延迟”和“每token速度”都会立刻变差。对比一下最直观维度训练场景推理场景通信频率每次迭代一次大规模同步每个token都有多轮小规模同步带宽需求极高上百GB级同步相对低但要求充足余量延迟敏感度中等但卡死就会训练中断极高抖动直接影响用户体验流量特征周期性突发强度大持续低延迟小流数量极多现在很多平台训练和推理共用一套集群这就带来一个很现实的问题推理的延迟敏感流量如果和训练的突发流量混跑很容易被挤成“受害者”。所以后面做网络架构时一定要考虑给不同业务流做隔离或优先级调度。2. 主流AI网络架构与技术选型分析2.1 RoCEv2与InfiniBand的取舍逻辑AI网络中RDMA远程直接内存访问已经成为事实标准。它最大的价值在于绕过CPU和操作系统内核让网卡直接把数据从一块GPU的显存搬到另一块GPU的显存省掉了大量拷贝和中断开销延迟和CPU占用都比传统TCP好太多。RDMA有两个主流载体InfiniBandIB和基于以太网的RoCEv2。IB是专用网络从芯片到协议都是为高性能计算设计的可靠性、性能、延迟都表现极佳。但它的问题是贵、封闭、对运维团队要求高一旦遇上兼容性问题日常调优会非常被动。RoCEv2则是在现有以太网基础上承载RDMA成本低很多能复用已有的交换机、线缆和运维经验。代价是它依赖“无损网络”环境——换句话说必须额外配置流量控制、拥塞标记等一系列机制否则稍有拥塞就丢包性能还不如TCP。选型没有绝对答案还得看场景对比项InfiniBandRoCEv2单机性能极强端到端优化强但依赖无损配置成本高专用设备锁定较低复用现有以太网运维难度需要专门技术栈可用已有网络技能存量资产兼容差基本全换好可与普通业务共存生态成熟度高性能计算圈成熟互联网大厂普遍在用从我自己的实践看30张卡以内的小规模集群RoCEv2完全够用性价比很高上百卡、上千卡规模而且有专职网络团队的话IB的稳定性和可预测性会更省心。如果公司已经有一大片以太网资产硬上新IB网络反而会变成两套体系双倍维护成本。2.2 拓扑结构从三层网络到CLOS传统园区网络是经典的三层结构接入层、汇聚层、核心层流量主要是南北向——用户从外面访问服务器。但AI集群的流量主流是东西向卡与卡之间相互通信大量流量在同一层交换机内部甚至同一机柜内完成。所以AI网络的拓扑设计核心思路从“南北向汇聚”变成了“东西向无阻塞”。最常见的方案是两层CLOS也就是叶子-脊Leaf-Spine架构。叶子交换机负责接GPU服务器脊交换机负责把叶子们连起来形成一个全网状的二层逻辑网络。只要“叶子下行接服务器的总带宽”不大于“叶子上行接脊的总带宽”逻辑上就是无收敛网络理论上任何两张卡之间都能跑满带宽。简单算一笔账一台GPU服务器通常有8块卡每卡配1张200G网卡那单台服务器对外总带宽就是1.6Tbps。一个机柜放8台这样的服务器叶子交换机这边要承载12.8Tbps接入。如果用64口400G交换机做叶子32口接8台服务器每台占4个400G口剩下32口全部上行接脊那上行带宽也是12.8Tbps收敛比就是1:1。这个比例对AllReduce这类全网同步场景是必须的不能省。还有一个关键认知拓扑必须跟着并行策略走。数据并行、张量并行、流水线并行对网络的依赖完全不同。张量并行通信量极大但只在相邻卡之间发生所以尽量要把做张量并行的卡放在同一台机器内至少放同一机柜数据并行的梯度同步是对全网发起的才是真正考验CLOS带宽和收敛比的地方。3. AI网络硬件选型与关键参数调优3.1 网卡、交换机的带宽匹配计算做硬件选型时最容易犯的错就是“一味追求高规格网卡”。网卡带宽要是超过服务器总线能提供的吞吐上限那就是浪费。关键要看GPU服务器的PCIe代数和通道数。PCIe 4.0 x16单向上限大约32GB/s也就是256GbpsPCIe 5.0 x16单向上限大约64GB/s对应512Gbps。所以如果服务器是PCIe 4.0平台配200G网卡是务实选择配400G网卡大概率跑不满。如果服务器是PCIe 5.0平台配400G网卡才合理。拿400G网卡插在PCIe 4.0槽位上跑出来可能比200G还差因为总线要先成为瓶颈同时还占用更多通道资源挤压其他设备。交换机选型上也容易踩坑。AI集群用的交换机不只是“端口速率够”就行。RoCEv2依赖无损网络交换机必须有足够的包缓冲来做反压吸收。普通三层交换机或者家用交换机缓冲小到一次突发拥塞就直接丢包RDMA立马性能崩溃。选型时至少要关心这几个指标是否支持PFC、ECN、是否支持RoCE流量可视化、每端口缓冲和共享缓存大小。可以简单对比一下设备类型适用场景关键能力数据中心级交换机AI训练/推理主网络大缓存、PFC、ECN、低时延普通三层交换机管理网、带外监控低成本但别承载RoCE流量家用/入门交换机只适合小规模调试别上生产任何无损能力都别指望3.2 无损网络配置与调优细节RoCEv2跑得稳不稳配置细节决定成败。下面几项是每一次落地上都要检查的MTU最大传输单元全链路必须统一开启巨型帧建议9000或9216字节。MTU不一致时RoCE流量会因分片而大幅降速甚至直接丢包。检查方法很简单从GPU服务器上发送指定大小、禁止分片的大包到另一台服务器# 从服务器A ping到服务器B测试8972字节负载 ping -M do -s 8972 目标IP这里-s 8972是ICMP负载大小加上IP和ICMP头部正好达到9000字节的MTU限值。如果通说明链路支持巨型帧如果不通就要检查两端网卡和交换机端口的MTU设置。PFC优先级流控制这是RoCE无损的核心机制原理是当下游交换机端口缓存快满时向上游发送暂停帧让上游先“刹车”而不是直接丢包。但PFC必须精细控制只对RoCE流量所在的优先级队列开启绝不能全局无脑开。全开容易产生“PFC死锁”——一个队列堵住暂停帧层层上传最后把整个网络都卡死。ECN显式拥塞通知相比PFC的“刹车”ECN更像“预警”。交换机检测到拥塞时在报文上打一个标记接收端收到后通知发送端主动降速。配置时要注意ECN的阈值一般把队列缓存的水线设置为端口缓存的30%到50%。阈值设太高等于没开设太低正常的短突发流量也会被误伤。QoS优先级映射给RoCE流量打上高优先级DSCP标签并把它们映射到专门的队列中。最理想的情况是网络里只保留两种队列RoCE高优先级队列和普通流量尽力而为队列队列数量越少越不容易出问题。网卡驱动侧也要配合。以常用环境为例可以设置这些NCCL环境变量来验证和调优通信路径export NCCL_DEBUGINFO export NCCL_IB_ENABLE1 export NCCL_IB_HCAmlx5_0,mlx5_1 export NCCL_SOCKET_IFNAMEeth0 export NCCL_IB_TIMEOUT22 export NCCL_IB_RETRY_CNT7NCCL_DEBUGINFO会把通信日志打出来能看到用的具体网卡和传输类型NCCL_IB_HCA指定使用哪张RDMA网卡NCCL_IB_TIMEOUT和RETRY_CNT是RDMA传输的兜底参数用来控制链路异常时的重试判断。注意这些参数只是交通规则里的“安全带”真正决定性能的还是底层的无损配置。3.3 光模块与线缆的匹配问题硬件层面还有一种特别隐蔽的坑光模块匹配。现在做400G网络光模块有很多种封装和标准交换机和服务器侧的光模块必须协议一致。否则链路虽然能up但误码率居高不下表现为网络通、带宽上不去、偶发掉包。建议在项目刚交付时就做一次全链路光功率测试确保每个光模块的接收光功率在正常范围内不能光看链路状态是“up”就认为万事大吉。4. 真实项目实操某公司跨机房AI集群网络改造复盘4.1 改造前问题全暴露在训练指标里这里分享一个我经历过的真实改动为方便叙述叫它“模拟项目X”规模不大但很有代表性。某公司内部要训练一个领域大模型集群一共64张GPU卡分布在两个机房。改造前整个AI网络跑在传统三层IP网络上NCCL用的是Socket模式也就是TCP。现象非常典型训练迭代一轮要22分钟GPU利用率长期在45%上下波动。从监控上看网络链路平均利用率其实只有15%看起来“远没有跑满”但训练却一直卡顿。这就很迷惑。后来打开NCCL_DEBUG日志一看问题清楚了大量时间耗在等待梯度同步上。链路偶尔出一次突发拥塞TCP立马重传重传导致某个GPU的梯度迟迟没到其他所有GPU只能干等。也就是说瓶颈根本不是平均带宽而是突发时刻的丢包和重传。顺带还发现一个隐藏问题跨机房通信链路之间还经过了一道传统防火墙防火墙对长连接做了限流训练流量一大直接被丢包丢到天荒地老。4.2 改造方案拓扑重构与无损参数落地改动分三步走。第一步把网络拓扑改成RoCEv2 两层CLOS。机房内采用叶子-脊架构全链路400G上行收敛比做到1:1。核心思路是把大部分流量留在同一机房内解决让跨机房流量只承担数据并行的梯度同步把最密度的张量并行通信全部限制在同一台服务器或同一个机柜内。第二步对所有涉及RoCE的交换机和网卡做无损参数配置。统一的MTU、PFC队列、ECN、DSCP映射全部同步铺开。这里有一个关键教训PFC不是一次性开完就完事必须区分队列。我们把RoCE流量固定在一个队列并把它与普通管理流量彻底隔离开。第三步把跨机房的防火墙从数据路径上移除。换成一条专用的二层或三层直连链路不再做任何会话层限流。这一步是很多人容易忽略的AI集群之间需要的是可靠大通道不是安全网关。交换机侧的配置思路可以这样理解不同厂商命令略有差异# 为RoCE流量定义高优先级队列 # 仅对队列3开启PFC priority-flow-control enable queue 3 # 队列3设置ECN水线 queue 3 ecn-threshold high 100KB low 50KB # 管理流量、普通业务流量不受PFC控制这一段是通用概念映射意思是要把“刹车”和“预警”精确作用到RoCE流上其他流量尽量别受影响。4.3 切换后的指标变化改造完成后再跑同一个模型单轮迭代时间从22分钟降到了9分钟GPU利用率从45%提高到72%。网络重传率几乎降到0训练过程中的周期性卡顿也消失了。这里有个值得说的点我们并没有盲目提升带宽核心链路还是400G实际吞吐提升幅度远没有2倍。真正带来收益的是消除了丢包和超时等待。在AI训练里一次丢包导致的全网等待代价远高于带宽降低10%或20%。另一个切身感受是一定要重视IP地址规划。RoCEv2虽然可以在VLAN间路由但每跨一次VLAN就要多做一次优先级映射PFC的控制范围也会跟着变化排障时异常痛苦。我们后来把所有RoCE服务器的IP都规划在同一个大网段里全网广播域内直接二层互通问题一下子少了很多。5. 常见故障排查与避坑指南5.1 高频问题与排障思路实际运维中下面几个问题最容易反复出现我按“现象-原因-排查-解决”的方式整理成一个速查表现象常见原因排查手段解决方向训练周期性停顿NCCL超时RoCE丢包、MTU不一致ethtool -S查丢包计数ping -M do -s 8972测大包统一9000MTU开启PFC/ECN网络全通但带宽只有标称30%ECMP哈希不均流量集中在少数链路看各端口出口流量分布更换哈希因子或使用动态负载均衡所有RoCE流量突然全卡住PFC死锁队列互相阻塞查看交换机PFC帧计数持续增长只开一个RoCE队列加PFC老化检测跨机房训练不稳定抖动大中间链路拥塞、经过防火墙限流持续ping测RTT波动查中间设备丢弃计数专用链路把跨机房通信移出关键路径链路up但误码高、偶发掉包光模块不匹配、光衰过大查物理层错包计数测光功率更换兼容模块清洁接头每个问题展开细说都能写成一篇排障案例这里重点说两个我栽过跟头的。第一个是MTU不一致的坑。当时有批交换机配置脚本写错了一部分端口MTU还是1500另一部分已经改成9000。训练没有立刻崩但性能衰减极其诡异时好时坏。排查了一个下午最后用一条ping -M do -s 8972命令从服务器A打服务器B才发现中间链路MTU不连续。所以这类项目交付时一定要把“全链路MTU一致性”列入验收清单。第二个是PFC死锁。一次网络设备升级后我们图省事把所有队列都开了PFC结果一个小流量突发就触发了连锁暂停整个RoCE网络瘫了十几分钟。教训就是PFC是控制在故障域范围里的让PFC生效的范围越小故障越容易定位和恢复。把普通业务流量也纳入PFC等于把无关的故障引入了AI集群。5.2 监控与日常检查建议网络架构上线只是起点日常监控才是保证长期稳定的关键。建议至少盯这几类指标交换机端口的PFC触发次数和持续时间RoCE网卡侧的丢包计数、重传计数ECN标记报文的占比和趋势交换机缓存占用率尤其RoCE队列NCCL训练日志里的超时和重试记录另外不要只在业务跑挂了才去看网络。每条新链路交付时建议先用NCCL测试集做一遍全链路通信压测把通信基准数据留存下来。比如跑AllReduce性能测试all_reduce_perf -b 128M -e 8G -f 2 -g 8-b指定起始报文大小-e指定结束大小-f是倍数递增-g是参与通信的GPU数。跑完之后记录不同消息大小下的总线带宽。正常情况下实际带宽应该能达到理论链路带宽的70%以上。如果某一次压测数据明显低于历史基线就可以提前定位网络问题而不是等训练卡死才来救火。还有一个小建议每次变更配置都要把变更前后的压测数据留档。很多间歇性问题最后都是靠对比历史Baseline才找到触发点的。网络优化不是“调完就完”的一次性工作而是一个持续记录、持续对比的过程。我个人踩过几次坑之后最大的体会是AI系统网络架构的难点从来不是把设备买回来连上线而是你能不能回答清楚“为什么这样设计、为什么设这个值、故障发生时最先该看哪里”。云栖大会专场里那些让人眼前一亮的案例背后几乎都是大量琐碎的配置、压测、监控和复盘堆出来的。希望这篇梳理能让你在自建AI网络时少走几段弯路至少在最容易出问题的几个环节上心里提前有个底。