这两年看AI Infra方向的面试网络基础真的是绕不开的一道门槛。翻了不下三百份简历也面过上百个候选人一个特别明显的趋势是框架层、算法层的知识大家普遍准备得很充分什么Transformer结构、显存优化、流水线并行都能聊得有来有回但只要话题一转到“集群里梯度同步走什么链路”“RoCE为什么要配无损网络”“收敛比怎么算”很多人就明显接不住了。我自己早期做过训练框架后来长时间泡在集群网络运维和性能调优的坑里对这个转变体会特别深。这篇文章我就把AI Infra面试里集群网络最常考的几条主线串一遍包括拓扑、收敛比、传输协议、无损网络与拥塞控制以及集合通信如何把网络变成训练性能的关键变量。内容不追求面面俱到重点放在“面试官到底想问什么、背后能不能体现出工程判断力”上。1. 为什么AI集群网络会高频出现在面试以及面试官真正想考察什么1.1 从一次实际面试对话反推考察逻辑有一次我面一个候选人简历写得很漂亮做过大模型训练平台的框架开发也处理过数据并行训练的性能问题。问到“你们的训练任务跑在多少卡规模的集群上”他对答如流继续问“这64张卡之间的梯度同步是走NVLink还是走网络你平时怎么判断”他开始犹豫再往下问“如果训练任务突然变慢交换机上PFC计数涨得很厉害你会先查哪个方向”他直接说“这应该是网络工程师的活”。这不是个例。类似的对白在面试里反复出现几乎可以总结成一条固定的“考察阶梯”第一层你负责的训练框架在多大规模的集群上跑过第二层跨机通信用什么协议走TCP还是RDMA为什么这样选第三层如果遇到AllReduce耗时飙升你会怎么定位网络指标里哪些值得先看第四层让你设计一个128节点的训练集群你打算用什么拓扑、什么收敛比、什么拥塞控制策略看到这个阶梯你就会明白面试官问“集群网络”并不是要候选人去讲OSI七层模型也不是考你交换机怎么配。真实意图是你能不能把“模型训练过程”和“底层通信设施”这两张图在脑子里拼到一起去。大规模训练一旦跑起来通信就是最大的性能瓶颈之一。一个只会调框架接口、完全不理解底层链路怎么工作的工程师在真实业务里很难独立做完性能优化出了故障更是无从下手。1.2 面试考察的三个维度和一条暗线我习惯把AI集群网络面试题归成三个维度。第一个是拓扑与带宽设计。集群有多少节点、分几层网络、上下行带宽配比是多少、会不会出现收敛过载。考察目标很明确你能不能从零设计一个可扩展的集群而不是只会照着教程搭。第二个是传输协议。TCP为什么不够用RDMA为什么能站出来RoCE和InfiniBand之间到底是什么关系。这组问题几乎是传输层的固定套餐背后考察的是对高性能网络工作机制的理解包括硬件卸载、报文封装、无损以太网这些概念是否真的落地过。第三个是拥塞控制与稳定性。PFC、ECN、DCQCN这些协议各自解决什么问题又带来了什么副作用。这类问题没有标准答案面试官更愿意听你对“丢包、暂停、降速”这些现象的描述和排查思路。三个维度之外还有一条暗线就是集合通信。面试官不太会单拎出来考但一定会用“你这段训练代码里AllReduce具体花了多长时间”这类方式自然带出。集合通信卡在训练框架和网络之间把通信原语、拓扑结构、拥塞控制全部串了起来。把这条暗线理清楚才算真正理解了网络在AI集群中的存在意义。2. 集群拓扑基本功三层Clos和收敛比计算2.1 为什么AI集群几乎都长成“三层树”大型GPU集群的网络拓扑不管底层是InfiniBand还是无损以太网最典型的形态就是三层Clos结构也常被称为Leaf-Spine-SuperSpine。最下面一层的Leaf交换机直接连接计算节点每个Leaf的上行端口全部接到一组Spine交换机集群规模大到Spine端口不够用的时候在Spine之上再加一层SuperSpine形成完整的脊-脊-叶三级架构。这个结构能成为事实标准靠的是无阻塞和可扩展之间的平衡。在一个完整的三层Clos里任意一台Leaf和另一台Leaf之间都不止一条路径。比如Leaf3下面的GPU想和Leaf5下面的GPU通信它可以选择经过Spine1、Spine2或者Spine3中的任意一台流量可以均匀打散到所有Spine上不存在“某一台交换机成为天然瓶颈”的设计缺陷。扩容也简单往上加一排Spine整网带宽随着端口数线性增长。面试中需要留意的点在于很多候选人对网络拓扑的理解停留在“交换机越多带宽越大”这种粗糙的层面一旦被问到具体的端到端路径、等价路由数量、多路径流量怎么无害化就会露馅。能说出源Leaf经过Spine到达目标Leaf有几条等价路径以及多路径之间怎么避免哈希冲突才算真正理解了Clos的工程价值。2.2 收敛比的计算并不是越大越合适收敛比是集群网络面试中出现频率最高的计算题。它的定义是一个区域内所有终端设备所需带宽之和与该区域接入上层网络的带宽之和的比值。收敛比等于1:1就叫无收敛大于1就说明上层网络存在过载。给一个最容易理解的计算例子。某Leaf交换机提供48个100G下行端口每个端口接一台计算节点那么这台Leaf的下行总带宽是48×1004800G。如果上行端口配置成8个100G上行总带宽是800G收敛比就是4800:8006:1。这个6:1表示当48台节点里任意两台之间同时满速通信时大约只有六分之一的流量能同时通过上行链路。普通业务集群里收敛比做到6:1甚至10:1都很常见。原因在于业务流量有很强的局部性不是所有机器同时都在互传存储和计算分离的架构也让大部分流量集中在东西向内部。但AI训练集群不一样梯度同步是典型的全局流量每个节点在同一个迭代周期内几乎同时发起满带宽的通信请求而且是持续一段时间的批量传输。收敛比只要大于1训练总时长就会被通信排队显著拖慢。所以现代AI集群的骨干网络基本都按“无收敛”或者“低收敛”设计。Leaf到Spine之间通常要求1:1Leaf下行端口和上行端口的带宽也按1:1配置避免任何可能出现的阻塞点。不过有一个细节特别容易丢分计算节点内部可能放了8张GPU这8张卡之间的数据交换主要通过NVLink完成真正送到Leaf的流量是整个节点对外的通信量而不是每张GPU各自独占一份网卡带宽。面试时如果默认一张GPU卡对应一个网卡带宽忽略NVLink的卸载作用算出来的收敛比和真实情况差得很远。2.3 面试官在收敛比上的两道典型追问收敛比的定义不难难的是延伸问题。面试官最常见的追问是“什么业务适合高收敛比集群”以及“如果收敛比太高你有哪些手段缓解”。第一道题的回答核心是区分流量特征。任务间通信频次低、通信量占比小的场景比如推理服务、数据预处理、模型评估完全可以用高收敛比因为请求天然分散不会出现千卡同时争抢带宽的局面。反过来分布式训练尤其是大批量同步训练必须走低收敛甚至无收敛的配置。第二道题发散性更强。面试官期待听到的不是训练算法层面的优化而是网络工程层面的手段。比如通过ECMP等价多路径把流量均匀分布到所有Spine避免某条路径过载再比如启用ECN让交换机更早感知拥塞触发端到端降速或者使用PFC在瞬时突发时用缓冲吸收风险。这些措施并不能直接弥补带宽的缺口但能把过载的负面影响压制到可控范围。能主动说出“高收敛比通常搭配拥塞控制和缓冲调优一起做”这种工程判断比单纯报一个比值概念要加分得多。3. 传输层选择题TCP为什么不够用RDMA强在哪里3.1 分布式训练流量和TCP天生有矛盾要理解传输层的选择先想清楚训练集群里真正在网络上流通的是什么流量。每次迭代结束后每个节点都要把本地计算出来的梯度和其他节点做交换等所有人都拿到全量的平均梯度下一轮前向计算才能开始。这决定了两个关键特征一是通信对延迟极度敏感通信时间直接进入训练的关键路径二是通信呈现周期性的同步突发成百上千个节点会在毫秒级的时间窗口内同时发起满带宽传输。TCP在这种流量模式下非常被动。它的设计目标是可靠传输通过确认、重传、拥塞窗口退避来保证不丢包、不拥塞但整套机制运行在操作系统内核协议栈里。发送每个数据包都要经历系统调用、数据拷贝、中断处理CPU占用率随吞吐线性上升。现在训练集群动辄需要10Gbps甚至100Gbps级别的节点间带宽靠CPU去搬运数据等同于让一个餐厅服务员同时管理几百桌的点单迟早全部瘫痪。更致命的是TCP对丢包的处理方式。一旦网络出现拥塞TCP拥塞窗口直接减半然后慢慢恢复。但分布式训练的通信流量高度同步所有节点的通信进度是绑在一起的一个节点退避其他节点的数据也跟着被堵住整个全局同步周期被拉长。这也是为什么在AI集群里TCP始终不是主力传输路径它更多出现在管理面、控制面或者传输模型权重文件这种对实时性要求不高的场景里。3.2 RDMA把数据搬运从CPU手里抢过来RDMARemote Direct Memory Access的核心思想就是“旁路”。它允许应用程序把数据直接从用户态内存交给网卡硬件通过网络把数据写入远端机器的用户空间内存中间不经过操作系统内核参与也不需要接收端CPU介入。传统网络的数据搬运链路是应用内存→内核发送缓冲区→网卡→网络对端是网卡→内核接收缓冲区→用户态内存每个环节都在消耗CPU和内存拷贝资源。RDMA的模型则是应用内存→网卡→网络→对端网卡→对端应用内存网卡上的专用硬件把数据搬运的任务接过去CPU只需要负责任务初始化和事后结果通知。这个模型天然适合高带宽、低延迟、CPU还有大量计算任务要处理的场景AI训练就是典型代表。面试中谈到RDMA最好能进一步区分两种主流实现。InfiniBand是一个专门为RDMA设计的封闭式系统包括网卡、交换机、子网管理协议所有组件深度协同带宽利用率高、稳定性好但设备成本高生态绑定强。RoCE是建立在普通以太网基础上的RDMA方案它让既有的以太网硬件具备RDMA能力成本低、运维惯性小代价是底层网络必须提供“无损”环境一旦出现丢包RoCE的性能衰减非常剧烈。很多面试官心中的理想答案是“看预算和运维团队能力”。愿意全栈投入InfiniBand的集群往往是为了极致性能和稳定互联网公司更普遍的选择是RoCE v2跑在无损以太网上因为能复用已有的交换机和运维体系。两者没有绝对优劣关键是配套的拥塞控制能不能做好。3.3 一个经典的选型追问套路面试官如果发现你对RDMA理解得不错接下来通常会给一个场景化问题“现在要搭一个64节点的训练集群你选InfiniBand还是RoCE”这类问题没有标准答案但很考察决策框架。我自己的答题逻辑是分三段。先说约束条件训练任务对节点间带宽的需求是几十Gbps还是几百Gbps硬件预算有多少现有网络是否具备无损能力。然后说选择方向预算充足、追求性能可控选InfiniBand希望复用现有以太网设施、团队更熟悉交换机运维选RoCE。最后补权衡RoCE需要投入大量精力在PFC和ECN调优上否则性能和稳定性都很难达到InfiniBand的水平InfiniBand则意味着绑定硬件供应商后续扩容的灵活性会差一些。这个三段式能把面试官从“你是不是只背过几个名词”的怀疑里拉出来因为它展示的是把技术选择当成工程决策来做的视角而不是在ABCD里挑一个标准答案。4. 无损网络的核心矛盾PFC和DCQCN为什么反复被问4.1 PFC先解决丢包却带来新的问题RoCE被部署到以太网上后第一个绕不开的问题就是以太网不保证不丢包。而RoCE遇到一次丢包就要走重传重传的代价在高速硬件转发场景里被无线放大直接击穿训练性能。为了保住RoCE的传输效率底层网络必须变成“无损以太网”PFCPriority Flow Control就是实现无损的主力协议。PFC的原理其实并不复杂交换机上维护多个基于优先级的队列当某个队列的缓冲占用超过阈值交换机就向对端发送一个暂停帧要求对端暂停发送属于该优先级队列的流量一段时间。这样微突发被缓冲吸收而不是被直接丢弃链路保持“不丢包”状态。听起来很完美但部署到生产集群后会暴露一个非常反直觉的问题PFC的暂停控制会沿着链路向源头方向层层传递形成一条“暂停链”。这条暂停链的杀伤力在于头部阻塞。假设某个Leaf交换机的队列缓冲区因为一条拥塞流而持续触发暂停帧那么排在同一个队列后面的其他无关流量也会被迫暂停。流量A本来一点问题都没有只因为和流量B排在同一个队列里就被一起按住了。这个效应会在整条链路上扩散最终导致集群内大量通信延迟被无谓拉高。更严重的是PFC风暴。我在实际环境里见过一次某台Leaf交换机上一个队列的缓冲参数配置过小高负载训练一开始该队列持续触发暂停帧暂停帧本身又有硬性的频率上限一旦超过交换机的CPU就被暂停帧处理打满转发能力大幅下降训练任务从正常几小时直接拖到接近卡死。排查这种问题有一个经典切入点先看交换机上PFC计数器的数值如果某个端口在短时间内增长异常基本可以锁定暂停风暴。4.2 ECN和DCQCN让拥塞被主动感知而不是靠丢包发现PFC只能告诉上游“先停一停”它不能告诉发送端“你的速率太高了需要降低”。缺少端到端的主动降速机制拥塞就只能依赖PFC在一跳接一跳的范围内被动吸收吞吐受损的同时公平性也非常差。为了解决这个问题ECNExplicit Congestion Notification和DCQCNData Center Quantized Congestion Notification登场了。ECN的思路是让交换机在队列拥塞时主动在数据包上打个标记而不是像TCP那样一定要等到丢包才意识到问题。接收端看到带标记的包之后生成一个拥塞通知包CNP反馈给发送端发送端据此降低发送速率。DCQCN就是为RoCE网络定制的ECN反馈方案把拥塞反馈和速率调整分开处理收到CNP后发送端以乘法方式降速在空闲时以加法方式恢复整体上是一个“快速反应、缓慢恢复”的控制回路。面试中围绕ECN/DCQCN有两个常问细节。一个是交换机上的标记阈值K怎么设置。K设太小链路稍有一点波动就频繁触发降速吞吐被过度压制K设太大拥塞信号传递太慢队列延迟过高。很多没动过真实集群的人会在这里卡住因为这个问题没有固定答案K值的选取取决于带宽延迟积和实际队列深度必须靠测量而不是套公式。另一个细节是CNP的转发机制它必须被交换机优先快速转发如果这个反馈包在路上被排队耽搁了拥塞控制就变成滞后控制整个算法退化严重。4.3 一点丢包为什么会让训练“伤筋动骨”很多候选人把“丢包的影响”简化成“丢包→重传→延迟增加”这个答案太浅了。在RoCE无损网络里一次丢包的影响远比一次重传大得多。假设一个训练迭代里某节点需要发送100MB的梯度数据做AllReduce只要出现一次拥塞窗口减半理论上后续吞吐会骤降。实际观察中0.1%的丢包率在RoCE网络上可能带来20%到50%的吞吐下降原因是降速后的恢复过程极其漫长。训练流量又是全局同步的一个节点变慢其他节点都在等它整体迭代时间就被这个慢节点拖住了。还有一类面试变体是“训练变慢时你会看哪些网络指标”。我自己的排查顺序是先看网卡层的丢包计数和重传计数再看交换机的PFC计数再看队列深度最后看ECN的标记率。丢包计数异常说明硬件链路有问题PFC计数异常说明存在瞬时突发或者队列配置不当队列深度持续偏高说明流量排队严重ECN标记率高说明拥塞控制触发频繁。把四个指标和四个层次对应起来才算真正摸到了无损网络的脉搏。如果候选人能把这些问题串成一条完整的排查链路面试官通常都会非常认可。5. 集合通信是AI网络存在的意义AllReduce与带宽放大5.1 先把通信模型讲清楚拓扑和传输协议最终都要为训练框架服务而训练框架里对网络需求最大的操作就是集合通信其中最常见的是AllReduce。AllReduce的含义是所有节点各自持有数据经过规约汇总后再把汇总结果分发给所有节点。在梯度同步场景里每个节点输入本地梯度输出全量平均梯度然后开始下一轮计算。很多人的误区是把AllReduce理解成“把数据广播给所有人”。实际上当N个节点各自持有一份数据时每一对节点之间都需要交换信息这在物理上就决定了AllReduce会产生极其庞大的网络流量。N个节点两两交换整体信息量级是O(N^2)的但每个节点真正需要的最终结果只有一份汇总数据。这个巨大的差异就是所谓的“通信放大”现象也是网络在AI集群中占据大量成本的根本原因。5.2 Ring AllReduce的通信量到底省在哪为了把通信量压下来业界最常见的实现是Ring AllReduce。思路是把N个节点串成一个环每个节点只和左右相邻的两个节点通信。数据切分成N份每个阶段每个节点只给下一跳发一份数据同时从上一跳接收一份数据。这个算法有一个非常简洁的通信量结论总通信量是2×(N-1)/N×M其中M是数据总字节数N是节点数。N越大这个值越接近2M。举个例子8个节点、每个节点要同步的梯度大小是100MBRing AllReduce的总传输量是2×(7/8)×100×81400MB。如果是两两广播的朴素方案通信量会按N的数量级膨胀几倍于Ring实现都很正常。这个结论背后有几个前提值得在面试里主动提一下。一是Ring AllReduce假设节点间链路带宽对等如果每个节点有多个网卡数据还可以切成更多份在多条物理链路上并行传输总时间会进一步缩短二是它默认通信和计算完全串行实际训练中通信库通常会做分桶切碎实现通信和计算的重叠这部分在后面的NCCL话题里还会遇到。5.3 实战计算不该只看公式面试官通常不会只考公式而是给一个具体场景“N卡训练任务单次迭代要同步的梯度是M字节估算一下同步通信的最小网络通信量并指出瓶颈在哪里。”回答时首先要判断GPU之间的通信方式。如果一张GPU和一个外部网卡绑定那单卡的网络传输量就是2×(N-1)/N×M再除以单次迭代可以分配给通信的时间得到单卡带宽需求。但如果节点内有8张GPU它们之间通过NVLink互联通常会先在NVLink域内做一个Reduce-Scatter把节点内通信做一次汇总再通过跨节点网络做全局AllReduce最后回到节点内部做AllGather分发。这样算下来真正进入机房网络的流量和“一张卡一个网卡”的简化模型并不一致。面试时如果能在公式之外主动提到“NVLink带宽通常远高于网卡带宽所以节点内通信会先聚合再通过节点间网络做全局同步实际网络流量要比单卡模型低一个系数”回答的深度立刻就不一样了。这个细节需要真的在集群上做过压测才能讲得自然硬背反而容易被追问打穿。5.4 “分桶”和“多流重叠”为什么总被追问集合通信库在工程实现上有两个高频词分桶数据分片和多流重叠。面试中不一定需要背源码但至少要理解它们解决什么问题。分桶就是把一次通信的大块数据切成很多小的chunk让多个chunk交替传输。目的并不是简单地把数据拆散而是为了让传输管线和计算管线能并行交替计算单元处理一个chunk的时候网卡同步传输另一个chunk。如果AllReduce让所有数据包在同一个流里串行传输等待通信完成的过程里计算核心只能闲置训练吞吐往往直接腰斩。多流重叠则是把不同的数据分片分配到独立的传输流上利用网卡的多队列和交换机的多路径实现更高的并发度。配合分桶之后训练框架可以在一个迭代周期内让计算、通信、甚至参数更新三个环节像流水线一样同时运转。面试中考这些概念本质上还是在考察“网络与训练之间的交互”是否真正理解而不只是停留在画图层面。6. 准备阶段最有价值的几件事以及一个通用答题框架6.1 动手跑一遍比背十篇文章都管用如果时间允许我强烈建议准备AI Infra面试的人在两台物理机上搭一个最小的RoCE测试环境。不需要太多资源两张支持RoCE的网卡加一台普通交换机就够了但要在操作系统层面真正配置一遍开PFC、按RoCE v2的DSCP字段配置ECN策略、设置网卡和交换机两侧同步的暂停参数。跑完这些基础网络参数配置再用RDMA的带宽和延迟测试实测一下两台机器之间能跑到多少对照官方标称值看差了多少。第二步是跑集合通信工具。用NCCL自带的测试模拟2卡、4卡、8卡的AllReduce对比不同节点数下的实际带宽和公式推导数值。这个对比结果会让人非常直观地感受到官方文档里的理论值和真实集群的差距往往就藏在PFC队列配置、ECN阈值、网卡多流等容易被忽略的细节里。真实环境里做一轮排查比看十篇讲RTT和带宽的文章都有用。这个过程不需要真的深入Linux内核源码但足够把抽象概念变成可以亲手触达的工程体验。6.2 一套能应对大多数问题的答题结构最后说一个我面试时用了很多次的答题框架先描述场景再拆解约束条件最后落在权衡选择上。无论题目从拓扑、传输协议还是拥塞控制切入这个框架都能帮你把碎片知识组织成完整的回答链条。如果面试官问“你怎么设计一个256节点的RoCE训练集群”正确的打开方式是先不要急着报拓扑。先拆解约束每个节点有几张GPUGPU是否直连网卡训练算法的迭代频率多高权重同步的通信量有多大。这些参数直接决定收敛比需要选1:1还是可以放宽。然后落到拓扑Leaf层需要多大端口数Spine层需要多少台上下行带宽怎么配比。最后说拥塞控制策略PFC做底层无损保障ECN做端到端反馈DCQCN做降速调节上线前先用压测工具把阈值K调好再长时间跑训练任务观察PFC计数和ECN标记率。这套框架的底层逻辑是“场景—约束—权衡”三段递进它有一个额外的好处能逼着我把平时零散积累的知识整理成自洽的推理链。面试官顺着回答追问两三轮我依然能从同一逻辑上继续延展不会出现一被追问就翻车的情况。我自己后来的候选人面试中凡是回答问题能自然落到场景和权衡的通常最后评级都不低。
