面试AI Infra岗位网络知识这一块几乎是必考的。我面过不少团队也帮团队招过人一个很深的感受是很多人对训练框架、模型结构能聊得头头是道但一提到集群网络往往只知道“用RoCE”“上IB”再往深问——为什么无损、怎么调拥塞、链路怎么算——就开始含糊了。这其实挺吃亏的因为在大模型训练这个场景里网络就是整个系统的血管血管堵了GPU再强也白搭。这篇文章我想把AI集群网络基础里最常考、也最实用的部分串成一条线讲清楚覆盖四块流量模型、协议选型、拓扑组网、拥塞控制与排查。不管你是准备面试还是刚开始接触AI Infra、想系统补一下网络基础应该都能从中拿到可直接用的东西。1. 先搞懂流量模型AI集群网络到底在传什么1.1 集合通信是集群网络的“灵魂”面试里我经常先问一个问题“训练一个千亿参数模型集群网络上的流量主要是什么”很多人会答“梯度同步”这个方向对但不够精确。真正决定网络压力的是一类叫集合通信Collective Communication的操作最常见的四个AllReduce、AllGather、ReduceScatter、AllToAll。以AllReduce为例它的目的是让所有GPU都拿到所有GPU梯度的和或者均值。朴素做法是有一个中心节点收集所有梯度、算完再广播回去但这样中心节点会成为瓶颈流量也无法均摊。业界主流是用Ring-AllReduce把集群里的GPU看成一个环每个GPU只跟相邻的两个GPU通信每次传递一个chunk的梯度经过2*(N-1)次传递后所有节点都拿到完整结果。这个细节在面试里很重要Ring-AllReduce为什么带宽利用率高因为每一步都在做“计算与通信重叠”数据在流卡在算网络空闲时间被压得很低。NCCL底层就是把GPU组织成ring或者tree来跑集合通信通信模式直接决定了网络流量特征——大块连续数据传输、延迟敏感、需要稳定的高带宽。理解这一点后面讲RoCE、讲拥塞控制才有落脚点。另一个常被忽略的是通信量与模型规模的关系。梯度通信量与模型参数量成正比而反向传播一次每个参数至少产生4字节的梯度数据FP32。千亿参数模型一次全量梯度同步光AllReduce就要传几百GB数据。如果用的是Adam优化器还会涉及到状态同步这里不展开但你可以借此说明为什么梯度压缩、混合精度训练FP16梯度能显著降低网络压力这也是面试加分项。1.2 网络性能指标延迟、带宽和尾部抖动面试官问“怎么评估一个AI集群的网络性能”实际考的是你对指标的理解深度。基础指标有三个带宽Bandwidth、延迟Latency、抖动Jitter。但对AI训练来说还有一个更关键但容易被忽略的指标——尾部延迟Tail Latency。为什么尾部延迟重要因为同步训练里每一次iteration的耗时取决于最慢的那张卡而不是最快的。任何一个网络链路出现微突发拥塞都会拖慢整个集群的同步节奏。所谓“木桶效应”在AI集群里体现得特别明显。面试时如果能主动讲到“我们不仅看平均延迟更看P99、P99.9延迟”会让面试官觉得你真懂生产环境。衡量工具方面业界常用的是NCCL自带的perftest工具里面有all_reduce_perf、all_gather_perf等测试程序。跑一遍全集群的all_reduce_perf能测出在不同数据量下的算法带宽Alg Bandwidth和总线带宽Bus Bandwidth。这两个带宽的比值能反映通信效率。我一般会先跑小数据量的延迟测试再跑大数据量的带宽测试分别对应延迟敏感型和带宽敏感型场景。实测中一个健康的RoCE集群all_reduce_perf跑128MB数据量时有效带宽应该能稳定在理论峰值带宽的70%到80%以上如果低于50%基本可以判断网络有拥塞或配置问题。除了带宽也建议掌握PPS包转发率的概念。RoCE是多队列的如果中间交换机或网卡在小报文场景下PPS能力不足也会拖慢延迟敏感型通信。面试时提到“我们看带宽的同时也看小包PPS”显得有实操经验。2. RDMA和RoCE把协议栈整明白2.1 IB和RoCE面试必须答出“技术”而不能只答“生态”AI集群网络里RDMA远程直接内存访问是大规模分布式训练的底线技术。RDMA允许网卡直接读写远端内存绕过内核、绕过CPU拷贝把延迟做到微秒级、节省CPU资源。实现RDMA的两种主流方案是InfiniBandIB和RoCERDMA over Converged Ethernet。面试高频问题IB和RoCE选哪个为什么国内现在很多大厂转投RoCE我总结的答题思路分三层。第一层技术层面IB是专为RDMA设计的从物理层到网络层全无损RoCEv2运行在标准以太网上需要把以太网“调教”成无损网络依赖PFC和ECN机制。理论上IB更“省心”时延更低。第二层生态与成本IB交换机、线缆、网卡价格高而且IB网络通常是独立一张网运维工具链不如以太网通用RoCE能复用现有数据中心以太网技术用成熟交换机设备软硬件供应多元化成本优势明显。第三层发展趋势随着RoCEv2生态成熟、拥塞控制算法越来越完善RoCE在AI集群中的渗透率越来越高。很多头部云厂商的大规模训练集群都在走RoCE路线IB更多用于超算中心或对网络稳定性要求极高、预算充足的传统HPC场景。答完之后记得补一个关键观点选型的本质是“在可接受的性能损耗下换取成本与可运维性”。面试官要的不是唯一答案而是你有框架性的权衡能力。2.2 RoCEv2为什么走UDP而不是TCP这是另一个容易翻车的深水区问题。要理解这点先看TCP干了什么可靠传输、乱序重排、拥塞控制、流控。这些功能对RDMA来说反而是负担。TCP的状态机、缓冲区管理、ACK机制都依赖内核协议栈报文收发和数据处理消耗大量CPU资源更重要的是TCP的拥塞控制遇到丢包就退避而RDMA要的是高带宽低延迟退避导致的带宽抖动对训练来说是非常痛的。所以RoCEv2选择了UDP作为承载只做简单的传输把可靠性、流控、拥塞控制都以硬件或上层机制来解决。实现可靠性的方式包括网卡上的重传机制如RoCE的Go-Back-N和上层NCCL的超时与checkpoint。拥塞控制则靠优先级流控PFC和显式拥塞通知ECN。RoCEv2把RDMA报文封装进UDP/IP报文头可以走普通IP网络的路由和交换这也是它能大规模铺开的基础。面试中如果把“为什么不用TCP”答到“因为TCP的拥塞控制、ACK机制、CPU开销无法满足RDMA微秒级延迟和高带宽要求而UDP足够简单可以承载报文复杂逻辑交给网卡”这个颗粒度基本就过了。2.3 无损网络的核心机制PFC和ECN提到RoCE必须提到无损网络Lossless Network。以太网本身是有损的出拥塞就丢弃报文。但RDMA的硬件重传机制对丢包极其敏感一旦丢包性能可能断崖式下降。为了让以太网“变无损”业界用了两板斧PFC优先级流量控制和ECN显式拥塞通知。PFC的原理是交换机某个优先级队列的水位超过阈值时向上游发送pause帧让上游暂缓发送该优先级的流量。这能防止丢包但会引入一个非常麻烦的问题——拥塞扩散Head-of-Line Blocking一个端口的拥塞可能导致整条链路多个流被暂停甚至波及无关流。PFC用的不好反而会让网络“堵死”。所以现在行业里对PFC的态度已经从前几年的“大规模依赖”转成了“慎用、尽量少依赖”核心思路是用ECN做主动拥塞控制PFC只是兜底。ECN机制更好理解交换机检测到队列拥塞时在报文的IP头里打上CECongestion Experienced标记接收端网卡收到后生成CNPCongestion Notification Packet报文通知发送端降低发送速率。发送端根据CNP频率逐步降速拥塞消除后再逐步恢复。这比PFC那种“一刀切暂停”要精细得多。面试中如果你能说出“PFC是逐跳的、基于队列水位的被动反压ECN是端到端的、基于显式标记的主动速控”“我们生产环境大部分场景依赖ECNPFC只在极端情况下兜底”这种经验型表述会非常加分。有次面试我遇到一个候选人能把DCQCN数据中心量化拥塞通知的公式写出来但问他生产环境CNP报文比例一般是多少、怎么监控拥塞热点时他就答不上来了。而实际上NCAR/DPU的计数器、交换机的CNP统计、ethtool -S里的rx_ecn_marked都是可以直接拿到数的。面试考基础但真正拉开差距的是“基础实践”的结合。3. 拓扑与组网集群网络怎么“铺”出来3.1 从胖树到Clos架构带宽均匀分配的艺术AI集群的组网核心目标只有一个字均匀。训练节点之间的通信模式是全局性的出现一个“热点”链路就够拖慢整体性能。所以今天AI集群几乎都采用Clos架构也叫Leaf-Spine架构。这种架构把网络分成两层或三层Leaf层接入计算节点Spine层做核心转发。每一台Leaf交换机和每一台Spine交换机之间都有链路连接任何两台Leaf之间的通信要么直达Spine转发要么最多经过两个Spine端到端路径短而确定路径数量也足够多理论上可以实现任意节点之间的同带宽通信。面试可能问Clos比传统三层网络核心-汇聚-接入强在哪核心答案在于“过载比Oversubscription Ratio”。传统树形结构越往上带宽收敛越厉害一般汇聚层的收敛比在4:1甚至更高而Clos架构可以做到1:1无收敛也就是任意ToR机架顶部交换机接入的带宽等于它往上走的总带宽。对AI训练来说无收敛几乎是一个硬性需求因为AllReduce流量是对全网均匀分布的不希望你某一段链路出现天然瓶颈。举例算一下假设一个训练单元有64台GPU服务器每台服务器2张400G网卡主备或双网卡承担不同流量那每台Leaf接入带宽就是800G64台就是51.2T。如果要做到对外无收敛这台Leaf往上一级Spine连接的总带宽也得是51.2T通常用16个400G口去连Spine每个Spine再往下接多台Leaf形成一个高分支数的无阻塞网络。具体数字不重要但“用链路数推带宽收敛比”这个思路要熟练。3.2 流量局部性NCCL的拓扑感知与GPGPU直连另外要了解一个常被问题错过的点AI集群的通信并不总是跨节点的很大一部分流量是节点内的。NVIDIA的HGX服务器里8张GPU之间通过NVLink全连接NVLink带宽远高于网卡带宽。所以NCCL在做集合通信时默认会优先利用NVLink实现节点内通信、跨节点才走网卡。这里衍生出NCCL拓扑感知的话题。NCCL启动时会探测每个GPU到每个网卡的相对距离通过查询设备拓扑如nvidia-smi topo -m决定采用哪种通信模式GPU直连网卡、通过PCIe Switch连接、还是通过CPU内存中转。面试中问到“为什么NCCL要设计Rail优化方案”本质就是在回答“如何让GPU与网卡的对应关系与网络拓扑配合避免跨Spine转发”。一个常见误区是把所有GPU卡加到一个NCCL通信域里就行了网络拓扑无所谓。实际不是的。如果节点内部GPU到网卡的归组Rail不匹配会导致一部分流量走PCIe Switch绕路另一部分流量跨Spine交换带宽和延迟都不可控。所以在组建AI集群时一个核心操作是进行nvidia-smi topo -m查看GPU与网卡的连接结构然后把同一Rail上的GPU和网卡拉进同一个NCCL通信组或者配置NCCL_P2P_LEVEL控制Peer-to-Peer的使用范围。面试时讲到这里可以顺势说说大规模集群的块间设计几百上千张卡的集群一般按照计算块Pod划分块内做到1:1无收敛块间用稀疏连接或更高层Spine互联。设计理念是“块内高速、块间尽力”。因为跨块训练时会引入额外的网络跳数和拥塞风险所以训练任务的调度也会尽量把同一个任务放在同一个块内减少跨块流量。这种“以大化小、层层收敛”的策略几乎是所有大规模AI集群的通用设计思想。4. 拥塞控制与性能调优NCCL里的门道4.1 拥塞是怎么在训练网络里产生的面试里让你讲拥塞控制如果你直接背ECN/PFC概念就太书生气。更好的切入方式是先讲一个生产场景50台机器的训练集群所有GPU同时进入反向传播AllReduce的流量在瞬间涌入网络多对一的流量模式导致某个Leaf端口的队列水高涨过阈值。如果是RoCEv2网卡系统有两种选择一是阈值触发ECN标记让流量自动降速二是触发PFC反压让叶子交换机暂停上层发送。在实践中PFC反压是很“物理”的它暂停的是整个优先级队列里的所有流不管你是重要的梯度通信还是背景流量。一旦PFC向上游逐跳传播拥塞窗口就会像多米诺骨牌一样向全网扩散形成所谓的拥塞树。最终结果往往是没有拥塞的链路也被迫暂停整体训练吞吐大幅下降。所以有经验的网络工程师在调RoCE时第一件事不是加带宽而是检查PFC和ECN的配置是否合理。比如PFC的buffer阈值不能设得太浅否则微突发就会触发反压ECN的标记阈值也不能设得太低否则正常突发也都被降速。这块参数调优很依赖交换机厂商和具体流量模型常见做法是先跑NCCL all_reduce_perf反复观察带宽和时延在拥塞时的曲线再反向调节ECN watermark。ECN与PFC配合的精细配置在AI Infra圈子里有一个更具体的名词动态ECN门限。静态门限的问题是不知道流量会有多突发设低了误伤设高了无效。动态门限会基于剩余buffer空间自适应调整ECN标记水位等于让交换机“聪明”地判断哪些流该降速。这些都属于网络设备的高级特性面试能提到说明你有实战经验而不仅仅是背理论。4.2 NCCL网络调优实用参数面试不至于让你直接调NCCL源码但常用环境变量需要知道是怎么影响网络行为的。先说NCCL_IB_DISABLE和NCCL_P2P_LEVEL。前者强制关闭InfiniBand/RoCE适合排查问题时确认是不是走网络后者控制GPU间是否通过NVLink/P2P通信可选值有NONE、SYS、PXB、PHB等分别对应不同的PCIe层级。生产环境中如果节点内有PCIe Switch通常设置NCCL_P2P_LEVELPXB避免P2P跨PCIe Switch带来的带宽抖动。再说带宽相关参数NCCL_BUFFSIZE通信buffer大小默认大概在几MB量级、NCCL_MAX_NCHANNELSNCCL通信通道数。这两个参数直接影响NCCL能占用的QDQueue Depth和并行度。调大channel数能提升带宽利用率但也会增加CPU和线程开销。一个常见技巧是先用NCCL_DEBUGINFO启动一次测试看NCCL实际探测到的网卡、通道数和每通道带宽再根据瓶颈点CPU、PCIe、网卡、交换机决定要不要调整。另一个很有用的环境变量是NCCL_IB_QPS_PER_CONNECTION。默认每个NCCL连接会创建多个QPQueue Pair增大这个值可以提升RoCE的多队列并发但也会增加端点的连接数交换机表项和网卡资源的压力都会变大。实测中在500卡规模的集群上把这个值从4调到8all_reduce_perf的带宽能提升10%左右但继续放大就没有明显收益反而出现CPU占用上升。生产环境建议测试不同取值找到甜点。还有NCCL_IB_TIMEOUT、NCCL_IB_RETRY_CNT这类可靠性参数。RoCE无损网络理论上不丢包但实际生产中还是可能遇到链路抖动、设备bug导致的丢包。这两个参数控制的是网卡层重传的耐心程度设小一点能快速暴露丢包问题设大一点则让训练更稳但对延迟敏感度也会下降。我的经验是调优阶段设小值快速测性能稳定上线时设大值保证训练连续性。4.3 如何判断网络瓶颈在硬件还是配置这是面试问“网络调优从哪里入手”时的高分回答思路。我总结了一个从底向上的排查链第一层看物理链路用ibstatusRoCE/IB或ethtool -S查看端口状态、丢包计数、CRC错误、link flap。如果物理层都不干净上层调优全白费。第二层看交换设备登录Leaf交换机看端口队列深度、ECN标记数、CNP报文数。如果某个端口CNP报文特别多基本可以定位为热点拥塞端口。这一步需要交换机支持Telemetry能用INTIn-band Network Telemetry数据的话会更精准。第三层看NCCL日志跑NCCL_DEBUGINFO关注NCCL初始化时探测到的拓扑、每张卡绑定的网卡、连接数和选择的算法。如果发现某张卡走了CPU中转而不是P2P性能肯定会掉调整NCCL_P2P_LEVEL或Topology文件就能解决。第四层看训练框架侧是否开启了gradient accumulation以减少通信频率是否合理设置了bucket size让梯度累积到一定大小再发起NCCL通信。这四层下来大部分性能问题都能定位到。面试时能讲出这条链面试官会觉得你确实在线上环境排查过问题而不是只看过文档。我之前有一次在一个160卡集群上排查all_reduce带宽低的问题折腾半天最后发现是Leaf到Spine的光模块速率协商成了100G而不是400G——这类“低级”物理问题在真实环境里其实占比不低。5. 面试高频问题与排查实战5.1 五道高频题的回答思路整理一下我面试或者被面试经常遇到的五类题目以及我会怎么答第一类“训练为什么需要无损网络”回答框架分布式训练大量使用集合通信流量是大规模突发RDMA硬件依赖无丢包链路丢包会导致重传与性能断崖无损网络提供稳定低延迟满足迭代式同步训练的需求。第二类“RoCE的拥塞控制是怎么工作的”不要只提ECN和PFC要讲一个完整路径交换机ECN打标→接收端CNP反馈→发送端降速→恢复。顺带说一句“DCQCN算法里rate恢复有个中间态不会立刻恢复到满速”。第三类“如果训练任务变慢如何定位是不是网络问题”按上面的四层排查链回答即可关键是要有“数据支撑”比如看NCCL日志里的带宽数值、看交换机CNP计数、看PFC暂停帧计数。如果能说“我们先看all_reduce_perf空测再看加负载后的实际吞吐对比”就更显专业。第四类“如何设计一张256卡的训练网络”给出思路256卡64台4卡机或32台8卡机按Clos两层或三层组网先算每台服务器接入带宽比如8卡每卡1400G3.2T再算Leaf往Spine的收敛比软件侧注意GPU与网卡的Rail-Pinned绑定和NCCL拓扑感知。回答里带一个“如果预算有限可以块内做1:1、块间做4:1收敛优先保证块内训练性能”会显得务实。第五类“RDMA为什么比传统TCP快”要点绕过内核、零拷贝、硬件卸载、低CPU占用、微秒级延迟。注意不要一句话带过最好展开讲“data path从上到下怎么走了一遍”——从应用缓冲区到网卡再到远端内存这能体现你对全链路有理解。5.2 常见网络问题与排查速查表问题现象可能原因排查命令/工具解决思路all_reduce带宽远低于预期网卡驱动版本旧、PCIe降速nvidia-smi topo -m、ethtool -S更新固件驱动、检查GPU与网卡拓扑绑定NCCL初始化超时网络不通、防火墙或路由问题ib_write_bw、ping、nccl-tests检查IP路由、RoCE流控、QP连接数训练时PFC死锁ECN阈值过浅、PFC反压扩散交换机show qos、PFC暂停帧计数调大buffer、改用动态ECN门限CNP报文比例过高拥塞热点、负载不均交换机CNP计数器优化任务调度、调整NCCL channel偶发训练中断链路抖动、光模块问题dmesg、交换机日志、ibstat更换光模块、检查线缆、调整NCCL_IB_RETRY_CNT同一模型不同时刻性能波动大数据链路噪声、邻居流量干扰Telemetry、perftest多次取均值隔离网络分区、配置QoS队列这个表格不是让你背答案而是提示你排查问题的核心永远是对“现象→原因→工具→动作”的闭环把握。面试官看你答这类问题就是在看你的排障逻辑是否完整。5.3 一个典型排障实战PFC反压风暴最后分享一个我实际踩过的坑也建议面试时讲成小案例。某次在128卡集群上跑GPT类训练整体吞吐比预期低了接近30%。任务本身不变网络的all_reduce_perf空测也是正常的所以我们一开始没怀疑网络。后来登录Leaf交换机发现几个端口的PFC暂停帧计数疯长这说明有反压在向前传播。进一步看问题出现在一个很不起眼的配置Leaf交换机上RoCE优先级队列的buffer分配不均某个大缓冲区队列占用了太多共享内存导致其他队列的buffer余量不足。微突发一上来PP暂停帧就满天飞。排查动作分三步第一步抓perftest多轮测试取平均确认确实带宽劣化第二步看交换机的PFC pause帧计数和ECN CNP计数定位到具体端口第三步调整队列buffer分配给RoCE队列保留更多独立buffer同时降低ECN标记阈值让拥塞在更早阶段被发现。恢复后同一测试跑下来带宽回升到正常水平训练吞吐也恢复。这个案例的启发是RoCE调优不是一次性的训练集群流量增长、任务变多后原参数可能失效定期做健康检查和压力测试是必要的。面试时讲“一个真实排障案例”比背十遍概念都管用。6. 我对网络调优的一些体会做AI Infra这段时间我越来越觉得网络是“看似简单、越调越深”的领域。很多问题表面是NCCL层根子却在物理链路、交换机buffer、光模块质量这些不起眼的细节里。建议准备面试的朋友不要只盯着NCCL的环境变量列表而是尽量把整个数据通路串起来GPU显存→PCIe/NVLink→网卡→交换设备→对端网卡→远端显存。每一个环节的瓶颈都是AI集群网络的基础问题。面经里那些“为什么用RoCE”“怎么调ECN”的题目本质都是在考你这个链路画得够不够完整。我在实际工作中体会最深的一点是NCCL网络调优的“最佳参数”往往不是网上抄来的而是根据自己集群的拓扑、流量模型和硬件配置一遍一遍测试调出来的。测试方法也要讲究不能只跑一次all_reduce_perf就下结论建议跑多次取中位数和P95结合训练实际任务看总耗时。网络问题的随机性很强一次测试遇到偶发抖动很容易误判。另外面试时如果被问到“网络性能差”先别急着分析拥塞控制先从物理层、驱动层、链路层逐层排查。有些时候问题简单到“某个网卡link down了”但因为你默认所有卡都正常反而绕了一大圈。拿数据做判断不靠猜这是AI Infra从业者的基本素养。