企业官网建设流程全解析

1. 为什么AI Infra面试离不开网络基础

1.1 先看一个最真实的面试场景

有次我做模拟面试，A同学履历很漂亮，做过模型训练、调过分布式框架、对常用框架的API也门儿清。结果我问了一句“你们千卡集群用的什么组网，收敛比多少”，他愣了半天，最后说“这个我没太关注，运维那边管的”。

这一句话，基本就把他从候选人的第一梯队里拉下来了。

不是说他能力不行，而是这个问题太典型了。AI Infra岗位的核心职责，就是把大规模算力组织起来跑大模型训练，而“组织算力”这件事，绕不开网络。单机8卡再强，跨机通信一卡顿，整个训练集群的计算效率就崩给你看。你只要碰过真实的训练集群，就不可能对网络一无所知。

这篇内容就围绕AI集群网络基础展开，把面试里最常考的几块——RDMA、RoCE、IB、CLOS组网、拥塞控制、收敛比、性能排查——一次讲透。我自己经历过不少技术轮面试，也帮团队面过人，很清楚面试官在这个话题上到底想听什么、怎么答才能拿分。适合正在准备AI Infra方向面试的同学，也适合刚接触大规模训练集群、想补网络底子的工程师。

1.2 网络在大模型训练中的真实角色

很多人对网络的第一反应是“不就是把服务器连起来嘛”。在传统业务里，这话问题不大，但放到大模型训练场景，完全不是一回事。

大模型训练，尤其是千亿参数级别的训练，几乎清一色走同步训练模式。每一步迭代里，几百甚至几千张卡要互相交换梯度，交换完之后再进入下一步。这个交换过程，每一步训练都有，一秒钟要发生好几次，持续数周甚至数月。

这里有个关键的量化直觉：一张高端训练加速卡算力很高，一次迭代的计算时间可能只有几百毫秒，而整个集群一次梯度同步的网络耗时也必须控制到同样的量级，否则算力就得等网络。等一次两次没事，等一整天就是巨大的浪费。所以在AI集群里，网络不是配角，而是和计算并行运转的核心子系统。

也正因为这个原因，面试官考察网络基础，不是真的想让你背协议栈，而是想确认你有没有能力站在系统层面判断：一个训练任务跑慢了，到底是算力问题还是网络问题；要扩容集群时，网络架构能不能撑住；出现丢包时，你是抓瞎还是能有序排查。这几项能力，靠的都是扎扎实实的网络基础。

1.3 面试官真正想听到的是什么

围绕AI集群网络，面试题看着五花八门，其实核心就三层：

第一层，懂不懂网络全貌。也就是从GPU到交换机到协议栈，整个数据通路是怎么走通的。这层考察的是广度，你得知道数据从显存里出来之后，经过哪些组件才能到达另一张卡。

第二层，懂不懂“为什么”。也就是为什么AI训练网络和传统数据中心网络不一样，为什么要用RDMA，为什么要做无损网络，为什么拓扑要选CLOS。这层考察的是深度，也是区分“背概念”和“真理解”的分水岭。

第三层，懂不懂工程落地。集群规模一大，什么问题都会冒出来：拥塞导致性能抖动、多路径负载不均、网卡故障引发整个训练卡住……面试官很愿意听到你说“这个问题我们遇到过，当时是怎么排查的”，因为真实场景下的经验，才是岗位最需要的东西。

所以下面各部分，我会按这三个层次展开。你拿着这份内容去准备，基本能把AI集群网络方向的面试题覆盖掉七七八八。

2. AI集群网络的核心概念与协议底子

2.1 从DMA到RDMA：一次说清

网络面试题里，第一个高频名词就是RDMA。很多人会背“远程直接内存访问”，但问到你“为什么需要RDMA”“它到底解决了什么问题”时，又开始含糊。

要讲清楚RDMA，得先从DMA说起。DMA的中文全称是直接内存访问，意思是硬件设备可以绕过CPU，直接把数据从设备拷贝到内存里。没有DMA的年代，磁盘或网卡想往内存里写数据，得靠CPU一点一点搬运，CPU被占得死死的，机器性能自然差。DMA一出来，拷贝的活儿由硬件自己做，CPU就解放出来了。

传统的网络通信，流程大致是：网卡收到数据后，先把数据放到内核缓冲区，再让CPU把数据从内核缓冲区拷到用户程序的内存里。中间经历内核态到用户态的切换，CPU参与拷贝，延迟高、开销大。

RDMA做的事情，是把这套流程彻底简化。它允许网卡直接从一台机器的内存里取数据，跨过网络，写到另一台机器的内存里。全程不打扰CPU，也不进内核缓冲区。效果就是：延迟极低、带宽很高、CPU开销很小。

用生活化的方式理解：传统网络像是在邮局寄信，你得跑柜台排队、填单子、邮局再分拣派送；RDMA则是你在自己家和对方家之间挖了条专用管道，信直接吹过去，省了所有中间环节。

这个基本原理理解到位，后面的RoCE、IB、拥塞控制就都有锚点了。

2.2 RoCE、IB、TCP：三类传输方案的取舍

面试时经常会问“你们集群用的什么网络”，其实就是在问传输方案。当前AI训练集群里，主流就三种选择：TCP、RoCE、IB。

先说TCP。TCP最大的问题是CPU开销大、延迟高，而且它天生是“尽力而为”的网络，出现拥塞就丢包，丢包就重传。在大规模分布式训练里，如果梯度同步走TCP，延迟会让你崩溃。所以现在AI集群里真正的数据面传输，主流已经不是TCP了。

再说IB，也就是InfiniBand技术。它是专门为高性能计算设计的网络协议，早期就瞄准了低延迟、高带宽场景。做RDMA几乎是它的原生能力，整体生态也成熟，很多高性能计算集群都在用。优点很突出：时延低、可靠性高、有成熟的流量控制机制。缺点也很明显：贵，而且对网络设备有专门要求，意味着硬件成本、运维复杂度都高。

夹在中间的RoCE，全称是RDMA over Converged Ethernet，意思是跑在普通以太网上的RDMA。它对底层设备有一定要求——网卡和交换机都要支持相应能力，但整体上比IB便宜得多，也能复用相对熟悉的以太网运维体系。随着技术成熟，RoCE在AI集群里的占比现在越来越高，很多大规模GPU集群都选择了这个路线。

我自己接触过的集群里，比较新的一些项目组网就是RoCE方案。和用IB方案的集群相比，RoCE胜在可扩展性好、灵活，性能调优得当后，和IB的差距能被压缩到很小。面试里如果能把这个优劣势讲清楚，很加分。

2.3 拥塞控制是绕不开的硬骨头

如果把AI集群网络比作一条交通系统，拥塞控制就是红绿灯和交警。交通一乱，整条路就堵死；网络一拥塞，训练性能立刻暴跌。

拥塞的典型场景是这样的：某次训练里有多个节点同时向一个目的节点发数据，或者多个流的突发涌到同一个交换机端口。当流量超过端口容量，数据就得在交换机里排队，排队时间长了，延时就涨上去。更糟的是队列一旦溢出，就开始丢包。

在传统TCP网络里，丢包自有办法处理，TCP有自己的一套拥塞控制算法，会主动降速、重传。但在RDMA环境里，丢包的代价大得多，因为RDMA追求的是高带宽低时延，一旦丢包触发重传，整条链路的性能会断崖式下跌，训练任务就会从一个稳定的“流水线”变成反复卡顿的“拥堵路段”。

为了应对这个问题，无损网络的概念就被提出来了。无损网络要做的事情，简单说就是让网络交换机有足够多的缓冲区，配合流控机制，尽量做到不丢包。两条最常见的机制是PFC和ECN。

PFC大致是在以太网里提供按优先级暂停的能力：某个优先级的队列快满的时候，交换机会通知发数据的那一端暂停发送。听起来不错，但它有个著名的副作用——可能互相阻塞。PFC暂停信号一旦产生，整个有依赖关系的数据流都可能被卡住，甚至酿成“死锁式”拥塞。很多网络团队对PFC又爱又恨，就是这个原因。

ECN则是在报文里打标记：交换机检测到拥塞时，在包上做标记，接收方收到标记后反馈给发送方，发送方主动降速。这条机制更温和，也是RoCE网络里调优的重点。现在很多集群里实际是PFC和ECN配合着用，但在细节上需要非常多的调参经验。

这一块如果只背名词，面试官问一句“PFC为什么会产生拥塞扩散”就会露馅。最好能自己画一遍数据流的路径，把暂停信号如何产生、如何传播想清楚。

2.4 从单机通信到全集群通信：别忘了集合通信

聊完传输协议，面试里紧接着就会转向分布式训练里另外一个高频名词：集合通信。

训练的多卡通信模式和普通业务网络不一样。普通业务是一个客户端问一个服务器要数据，一对一；训练是每张卡都要和其他很多卡交换数据，一对多、多对多。通信库会把这些模式抽象成固定的集合操作：AllReduce、AllGather、ReduceScatter、Broadcast这些。

以AllReduce为例，它做的事情是把所有卡上的数据做一个求和之类的归约，再把结果广播给所有卡。训练梯度同步就大量用它。你可能会问，AllReduce只是定义了一种语义，它背后如何通信却是另一回事。A同学在面试时说过“我们直接用框架的AllReduce就行”，但我追问“那它内部是走什么算法，是Ring还是Tree”，他就答不上来了。

这个细节恰恰是AI网络相关的考察重点，因为不同的集合通信算法对网络流量模式影响巨大。比如Ring AllReduce把通信拆成环形流水线，链路利用率高，但对时延敏感；Tree则在扩展性上有优势。工程师如果能根据网络拓扑、集群规模选择通信模式，收益非常大。

实际上，集合通信库本身也提供了环境变量和日志开关，能让你看到每一步用了什么算法。面试或实际调优时可以打开观察，这个建议在后面排查部分会再提。

3. AI集群的组网形态与拓扑设计

3.1 从8卡机到千卡集群：网络规模变化带来的本质差异

早期训练，一张机器里插了8张加速卡，通过机内总线互连，模型并行、数据并行都跑得起来，这时候网络的问题不突出。等到参数规模增大，必须把多个节点连起来做分布式训练，真正的网络问题才浮出水面。

一台机器内部通信快，因为物理距离短、走专用通道；机器之间的通信就要靠网卡、网线、交换机。一旦跨越节点，网络时延相比机内通信高出一个数量级，带宽往往也受限，这两点同时决定了分布式训练的性能天花板。

这里有一种很直观的计算方式。训练迭代的总时间约等于计算时间加通信时间，通信占比越高，集群算力浪费越大。举例：如果一次迭代计算需要800毫秒，通信需要200毫秒，那就有20%的时间算力在空转。想要提高效率，要么减少通信量，要么加快通信速度。而加快通信速度，靠的就是网络基础设施的水平。

随着集群从几十卡扩展到几百、上千卡，通信模式也在变。两卡通信和你来我往就行，几百卡通信就必须考虑分组、分阶段、做拓扑感知。一个典型的做法是，在通信模式上按节点分组，节点内部先归约一次，节点之间再归约，这种层次化通信能大幅降低跨网络的数据量。这个思路在网络搭建时也同样适用，从设计架构到通信策略，都要考虑层级。

面试官问“你们多大集群、怎么组网”，本质上就是想看你对这个规模差异是否有体感：你说得出百卡规模下的瓶颈点，他才会信你能处理千卡。

3.2 CLOS架构与无收敛设计

提到大规模AI集群的网络拓扑，必须讲CLOS架构。

传统数据中心早期流行三层架构，核心层、汇聚层、接入层，数据大多要经过核心设备转发。这个模型在小规模时没什么问题，但到了大规模，核心层的带宽压力极大，很容易成为瓶颈。CLOS架构则不同，它的核心思想是“多级交换”，把网络设计成一个扁平的、多路径的架构，使得任何一层交换机都不需要承担过大的转发压力。

实际AI集群里最常见的组网方案，是两层CLOS，也叫“脊-叶”（Spine-Leaf）架构。叶子交换机（Leaf）直接连着计算节点，脊交换机（Spine）把所有的叶子交换机全连起来。每个叶子交换机都连到每一个脊交换机，形成全连接矩阵。

这样做的好处很直接：任意两个节点之间，存在多条等价路径。数据从这里到那里，可以走A脊，也可以走B脊，流量被分摊开，单台交换机压力小了，网络的整体带宽提升了。加上等价多路径路由技术，可以把流量散列到多条路径上，整体利用率明显提高。

面试里常考的一个词是“无收敛”。所谓无收敛，是指在设计上保证任何一层链路的带宽总和，不低于下一层请求的总带宽。一句话就是：不能因为上层转发能力不够，导致底层算力发出去的数据堵在半路。很多面试者把“无收敛”挂在嘴边，却说不清它到底是哪一条链路的带宽配平关系，这就是明显没理解到位。

具体到组网参数，一个常见的示例：某台交换机有32个高速端口，其中一半端口向上连脊，一半端口向下连计算节点，这就是1:1收敛的典型设计。如果向上连的端口数少于向下连的端口数，那么就会出现收敛，多条低带宽上行争用一条高带宽上行，超卖就发生了。

3.3 看明白拓扑再答收敛比：这个高频题不再翻车

收敛比是面试官最爱的陷阱题之一，因为候选人很容易把概念背串。

先理清定义。收敛比可以理解为“下行总带宽与上行总带宽之间的比”。如果下行带宽是80G，上行总共也是80G，那收敛比是1:1，也就是无收敛；如果上行只有40G，那就是2:1收敛，意味着满负荷时下行流量可能有一半上不去。

这个设计的本质是一个取舍问题。全无收敛的网络当然性能最好，但成本也最高，因为上行端口、交换机数量都要成倍增加。收敛比越接近1:1，代表网络越“奢侈”，越能扛高负载；收敛比越大，网络越省钱，但性能风险也越大。

AI训练集群为什么特别看重收敛比，原因是集合通信创造了大量突发、高密度的流量。在传统业务里，网络负载通常比较分散，局部收敛未必带得动问题；但训练任务里，全集群的卡每个迭代周期都要同步一次，这种同步行为会把流量在时间上高度集中，如果网络存在收敛，平时看起来还行的链路，峰值时就直接堵死。

我见过一些面试者在纸上分析得头头是道，但忘了问一句“你的场景里真的存在跨脊交换吗”。实际上，拓扑设计和通信调度绑定之后，有些流量在叶子内部就消化掉了，根本不会跨脊。这种“误解架构就盲目算级联”的情况在真实系统分析中很常见。

所以看到收敛比相关的问题，先别急着给出数字，先确认：你说的收敛，是叶子到脊这一段，还是脊到核心这一段？流量模型是跨机还是机内为主？这比快速背一个答案重要得多。

4. 性能指标与问题排查

4.1 衡量AI网络健康的核心指标：带宽、时延、抖动

面试官聊到网络性能，最常抛出的问题就是“你平时用什么指标评估网络有没有问题”。很多候选人第一反应是“带宽”，这个没错，但只有带宽是远远不够的。

在AI集群环境里，三个核心指标必须同时关注：带宽、时延、抖动。

带宽决定单位时间能传多少数据，是硬指标。看一台网卡能不能跑到标称速率，最简单的方法是跑一把点对点带宽测试，把两个节点之间的数据吞吐量测出来。如果结果远低于预期，就要怀疑硬件、配置或链路拥塞。

时延决定每一次通信的“起步价”。哪怕带宽再高，如果每一次握手和数据搬运都要多花几十微秒，在集合通信这种大量小消息的场景下，总耗时也会被明显拉长。

抖动则是很多人忽略的指标，它指的是时延的波动程度。AI训练对网络的稳定性要求很高，如果时延偶尔飙升，那么整体训练耗时不会线性增长，而是会卡在那些异常的尖峰上。我更愿意把这种做法理解成“木桶效应”：平均时延再低，训练速度也取决于最差的那几次同步。

4.2 集合通信对网络性能的隐性依赖

为什么单个节点测试带宽很高，一跑大规模训练就变慢？这里面最常见的解释是：集合通信的性能，取决于所有参与者中最慢的那个节点或链路。也就是说，AllReduce的整体完成时间，不取决于你的平均网络速度，而取决于最差的那条链路。

我用一个简单例子解释。你有256张卡做AllReduce，255张卡的网络都很快，只有1张卡的链路出了间歇性丢包。TCP模式下可能这个问题不致命，但在RDMA模式下，丢包带来的惩罚极高，重传一次要等很久，整体同步时间就会被拉长。训练系统里有“同步屏障”，所有卡必须等这次集合通信完成才能进入下一步，一张出问题，全员等待。

这也是为什么AI集群网络排查时，往往不是看这个集群的平均吞吐，而是要看全集群里最差节点的表现。做性能检查时，建议用脚本把每一张卡的点对点带宽和时延都测一遍，看有没有离群点。这一步成本不高，但往往能发现大的隐患。

我在一次集群测试里发现训练速度比预期慢了20%，先看整体流量觉得正常，后来仔细测了每张卡的通信性能，才发现有两张卡的测试结果明显异常，进一步核查才知道是网线接头松动。单看整体指标，这种问题很难暴露。

4.3 排查网络问题时，我的一套常用动作

网络问题排查，最重要的不是上来就抓包，而是有层次地筛查。以下是我在检查AI集群网络性能时的一套实际操作流程，可以供你参考。

第一步，先做连通性和带宽基线测试。在集群里随机抽几对节点，跑点对点带宽测试，确认测试出来的数据接近理论值。如果这一步都不过，不要继续往后排查，先解决最基础的链路问题。

第二步，跑全节点矩阵测试。把集群里每张卡的通信性能都测一遍，生成一个矩阵报表，直接看离群点。这一步能找到那些单看整体数据发现不了的坏节点。

第三步，观察训练日志里的同步耗时。打开集合通信库的调试日志，看每个迭代的同步开销。如果同步耗时突然升高，再去检查对应时间点的网络指标。

第四步，检查拥塞相关计数器。很多网络交换设备都有端口拥塞、丢包、PFC暂停帧计数器，通过这些计数器的累计情况，能判断是不是存在持续的拥塞。

第五步，确认路由和路径是否平均。多路径场景下，如果负载分担算法把大量流量放到同一条链路上，会造成某条链路拥塞而其他链路空闲。这时候可以试试重新散列流量，或者调整负载均衡的哈希因子。

这套流程走下来，大部分网络问题都能定位到方向和范围。它有两条实用的心得：一条是，记录基线。任何系统，在日常运行正常时就应该把关键指标摸清存好，出现问题时才有对比依据。另一条是，别一上来就怀疑硬件。很多“网络问题”其实是配置问题和流量模型问题，先看设计和配置，再碰物理层。

5. 面试高频问题与实操心得

5.1 高频问题与应答参考

把面试里最常碰到的网络问题整理成一份速查表，这些问题几乎每个投AI Infra方向的人都会遇到。

特别说一下最后一类问题。候选人在回答无损网络时，普遍爱把它当成“完美方案”。实际上无损只是手段，不是目的，它只是为了保障RDMA的稳定传输。真正网络调优工作里，PFC风暴、ECN水位设置不合理导致的吞吐下降都是很常见的，答出这类细节，面试官会明显感兴趣。

回答这些问题时，还有一个通用的原则：不要只给结论，要给“原因+过程”。面试官问RoCE和IB怎么选，你如果只答“RoCE便宜所以选RoCE”，评分不会高；你要是答“在我们几百卡规模下，IB的生态优势发挥不出来，RoCE配合ECN调参已经能满足95%以上的性能需求”，这就体现了系统思维。

5.2 我在实际集群踩过的坑

讲几个我自己踩过、周边团队也踩过的坑，这些都是面试里能直接拿来当案例的真实素材。

第一个坑是误把网卡协商速率当成实际可用带宽。有一次我们看网卡状态显示速率正常，但跑训练总是慢，排查了好几天，最后发现是交换机和网卡之间的自动协商把工作模式降级了。表面速率显示没毛病，实际走的链路能力大打折扣。现在我的习惯是，不管设备状态显示多少，都以实际测试为准。

第二个坑是多个训练任务共用一个集群时，网络相互干扰。大模型的训练任务往往不是单个跑齐，有时候并行好几个训练任务，这些任务产生的流量一旦交织，会把网络拥塞瞬间拉到很高。这个问题的难点在于，不是单条链路的问题，而是多租户流量打架，必须从流量调度或者任务调度层面解决。

第三个坑是PFC风暴导致的全集群性能雪崩，这个现象非常“诡异”。表面上没有丢包，但时延飙升，训练速度断崖下跌。排查到最后发现在某个交换机端口上，PFC暂停帧数量异常，高优先级的流量把低优先级的流量彻底堵住，形成了一种“活锁”状态。由于网络本身没坏，传统排查手段几乎失效，最后是靠查看网卡和交换机的PFC计数器定位的。

这些案例说明了同一个经验：集群不等于单机，网络问题不能只看单点。训练任务卡住了，不要只盯着算力，先确认网络没有在“拖后腿”。

5.3 准备这部分内容的一点建议

如果你正在准备AI Infra面试，网络基础这一块不需要把所有协议细节背到极其深入，但要求核心链路能讲到逻辑自洽。我建议按以下的顺序准备：

先画一遍数据流，从一张卡发数据，到网卡、交换机，再到另一张卡的显存，把中间每一层涉及的技术名词都标出来，看看哪些你只是听说过、哪些能解释透。

然后找一个真实的集群拓扑，哪怕是小规模的8卡机、2机16卡也行，亲手看一遍配置，跑一次带宽测试，打开集合通信库的调试日志观察同步开销。不用多复杂的操作，关键是获得对真实数据的体感。

最后，把上面那份高频问题表当作自测清单，给自己做模拟问答。不要只看答案，试着口头表达一遍，直到能顺畅地解释清楚每一个“为什么”。如果某个问题说得磕磕绊绊，说明这里要么不理解，要么是知识太孤立，赶紧补。

AI集群网络看起来是个“小方向”，但它实际上是理解大模型基础设施运行逻辑的核心切口。你可以不懂网线怎么压、光模块选什么型号，但你要懂数据怎么流动、流量在哪里挤压、性能受限于什么。这几件事想明白了，无论面试题怎么换着角度问，你都能兜住。

我自己在带团队时，判断一个候选人有没有系统思维，很少直接问“你懂不懂网络”，而是请他讲一遍数据从生成到落地的完整路径。能把这条路径讲到有细节、有取舍、有真实例子的人，基本就是这个岗位想要的形态。希望这份内容，能帮你把这条路径理解得更扎实一点。