AI集群网络面试核心：从IB与RoCE到拥塞控制的实战指南

1. 为什么AI集群网络能单独成为一个面试板块

说实话，两三年前大家面AI Infra岗位，问的还是“用过什么框架、怎么调参、CUDA优化熟不熟”。但这两年风向明显变了，AI集群网络被提到了一个几乎必考的位置。我自己面过不少候选人也被人面过，这个转变背后的逻辑其实很直接：预训练模型动辄千卡万卡并行，跨节点的通信开销已经从“辅助因素”升级成了“决定训练能效的上限因素”。

打个比方，你把一万张卡用网线连成一个大水池，单卡算力是水泵的功率，但最终出水效率取决于水管有多粗、水闸怎么开、堵不堵塞。如果网络设计不合理，哪怕水泵功率再大，整体流量也会被压下来。放到大模型训练里，就是MFU（模型算力利用率）在30%和55%之间的差距，这个数字直接决定一个训练集群的盈亏。

所以，面试官问“AI集群网络基础”，真正想考察的不是你会不会配交换机，而是三个层次：

第一层，知不知道训练场景下网络的核心作用是什么，比如集合通信、数据并行、张量并行是怎么依赖网络的。

第二层，懂不懂关键协议和拓扑的取舍，比如IB和RoCE怎么选，胖树和Torus各自适合什么场景。

第三层，有没有在真实集群上踩过坑。比如拥塞导致训练抖动、ACK超时引发连锁反压，这些现象你怎么分析定位。

这篇文章就把这三层拆开揉碎讲清楚，不是背概念，而是按我实际面试和被面的经验来梳理。阅读对象是准备AI Infra岗位面试的工程师，也可以是刚接触集群训练的研发，希望能帮你们把网络这块的认知补完整。

2. 集群网络在AI训练中的真实地位与流量模型

2.1 从单机到集群：通信不再是配角

先明确一个基本认知：AI集群网络不是普通的“上网用的网络”，它是为了完成分布式训练而专门设计的一套高性能通信系统。在单卡或单机训练里，数据都在本地内存和显存之间流动，不涉及跨节点通信。但到了大规模并行训练，模型参数被切到多张卡上，前向计算和反向传播过程中必须不断同步梯度、传递张量，跨节点通信变成每次迭代的必经环节。

我在面试时候经常用一个数据来说明问题：一个千亿参数的模型，如果用纯数据并行训练，每个step光同步梯度就需要交换数百GB的数据。这个吞吐如果跑不满，GPU就在空转等数据。你可以想象每辆车都在高速上排队等收费站，GPU利用率自然上不去。

集群网络的任务本质上是两条：

• 在尽可能短的时间内完成跨节点的数据交换；
• 在大量并发流量下保持稳定、低抖动、不丢包。

这个“稳定”和“低抖动”非常关键。训练不是跑一次就结束，而是几万步迭代连续跑。偶尔一次网络延迟尖峰会让某些GPU等待，导致其他节点也跟着等，最终整个集群的训练效率被拉低。所以面试官特别喜欢问“为什么AI集群网络需要无损特性”，答案的核心就是：训练任务对网络的要求不只是带宽大，更是要可预测的延迟表现。

2.2 集**合通信产生的流量模型

理解了流量从哪来，才能真正理解为什么网络拓扑和设备选型如此重要。分布式训练中的通信主要依赖MPI（消息传递接口）风格的集合通信，其中最核心的几种操作包括：

• AllReduce（全规约）：所有节点先进行本地梯度计算，再全局求和/求平均，最终每个节点都得到完整的聚合梯度。这是数据并行训练中频率最高的操作。
• AllGather（全收集）：每个节点把自己的数据分发给所有其他节点，最终所有节点汇聚到完整数据，常用于张量并行和MoE模型的部分场景。
• AlltoAll（全交换）：每个节点把自己的数据按目标节点切分，再发给对应节点，同时从其他节点接收数据。专家并行（Expert Parallelism）的Token分发就是典型的AlltoAll场景。

不同集合通信模式对网络的压力完全不同。AllReduce通常表现为多对多的广播流量，AlltoAll则是细粒度的多点交叉流量，容易在交换机端口形成拥塞。面试中如果有人能把这几种通信模式的流量特征讲清楚，基本上就能证明他真正做过大规模训练，而不是只在书上读过概念。

我用一个大家容易理解的类比来解释这几种流量：AllReduce像是全班同学各自算出自己那份题目答案，然后互相交换核对，最终每个人都得到全班的完整结果；AllGather像每个人手里有一个拼图块，最后每人手里都拿到整套拼图；AlltoAll则像是每个班级出一部分人去其他班级，同时接收来自其他班级的同学。三种模式对教室过道（也就是网络）的占用方式完全不同。

大模型训练还有一个普遍趋势是混合并行，数据并行、张量并行、流水线并行、专家并行结合在一起。张量并行通常发生在节点内，走NVLink等高速总线；数据并行和专家并行跨节点，需要走集群网络。所以集群网络设计需要适配多种流量混合的情形，而不仅仅是应付单一的AllReduce模式。这也是为什么面试时还经常追问“为什么有了NVLink还要设计跨节点网络”，本质是不同并行模式的通信域不同。

2.3 网络性能指标：带宽、时延和抖动

AI集群网络面试中最重要的性能指标主要有三个：

• 聚合带宽（Aggregated Bandwidth）：所有节点并发通信时的总吞吐量。集群网络设计的首要目标之一就是让聚合带宽能随节点数线性扩展，这就是所谓的“无阻塞”或“低阻塞”网络设计。
• 时延（Latency）：单次小包通信的往返时间。对同步训练来说，时延决定了每一步迭代的通信开销下限。小消息通信（如控制信号、同步标识）非常依赖低时延。
• 抖动（Jitter）：时延的波动程度。训练迭代一旦出现抖动，就可能出现某个节点等待时间不可预测，进而造成整个集群的效率损失。

我面试时经常用一个很务实的提问方式：“给你一个千卡集群，怎么评估网络是否达标？”答案通常分几步：先看聚合带宽能不能达到理论峰值的80%以上；再测AllReduce的耗时是否接近理论最优值；最后看长时间的稳定性，是否有周期性抖动或突发性延迟尖峰。这些测试在真实集群上都用得上，推荐大家动手试试，特别是用nccl-tests跑一遍，数据非常直观。

3. 两大技术路线：InfiniBand与RoCE的取舍

3.1 InfiniBand为什么成了大模型集群的主流选择

目前全球头部的大规模GPU集群，绝大多数选择了InfiniBand（IB）作为跨节点网络的物理层方案。原因很直接：IB从设计之初就是为HPC（高性能计算）场景服务的，它的协议栈天然支持RDMA（远程直接内存访问），数据传输可以绕过CPU和操作系统内核，直接从GPU显存到网卡再到对端显存，延迟低、CPU占用量少。

IB生态里最让工程师省心的一个特性是Credit-Based流控机制。网络设备只有在确认对端有足够缓冲区接收数据时才会发送，这种端到端的信用机制能从根本上避免丢包。大模型训练的通信流量通常是burst式的，一瞬间可能并发大量数据，如果网络出现丢包，TCP重传的代价极高，训练效率会断崖式下跌。IB的无损特性正好匹配这个需求。

另外，IB交换机的端口速度升级迭代非常快。目前主流的400G HDR已经普及，800G NDR也在逐渐落地。大集群要支撑十万卡规模，对端口数和交换架构都有超高要求，IB在这块的产品成熟度和生态完整性，目前确实领先于其他方案。

不过IB的劣势也很突出：贵。无论是网卡、交换机还是光模块，价格都远高于以太网方案。而且IB的生态相对封闭，很多传统网络工程师对它不熟悉，运维技能门槛高。所以不是所有团队都适合无脑选IB，要看预算、团队能力和集群规模。

3.2 RoCE：在以太网之上实现RDMA

RoCE（RDMA over Converged Ethernet）是把RDMA能力移植到以太网的一种方案。它有两种主要版本：RoCEv1是二层协议，无法跨三层路由；RoCEv2引入了IP和UDP封装，可以走三层网络，灵活性大大增强，目前实际部署基本都是RoCEv2。

RoCE的优势在于能复用已有的以太网基础设施和运维体系，成本显著低于IB。特别是一些中型训练集群，或者混合云场景，RoCE的兼容性和灵活性更有吸引力。加上近年来无损以太网技术逐步成熟，RoCE在高带宽场景下的表现越来越接近IB。

但RoCE有一个绕不开的痛点：它依赖底层网络提供无损传输能力，否则一旦丢包性能就会雪崩。传统以太网本身会丢包，所以RoCE部署必须配合DCQCN、PFC、ECN、ETS等一系列机制来保证无损，调试难度相当大。我在面试中通常用一个连环问题来考候选人：RoCE场景下拥塞产生了，网卡侧会收到什么信号？交换机侧怎么调度？如果出现PFC风暴怎么定位？能完整答上来的人确实不多。

3.3 两种方案的实际选型对比

选IB还是RoCE，不是简单看性能跑分，而是要结合实际训练负载、运维能力和预算综合判断。下面这份对比表是我自己整理多年项目的经验：

选型时我的经验判断标准是：如果集群规模超过一千卡，且预算允许，直接上IB，省心、稳定、性能上限高。如果是百卡规模或者预算受限，RoCEv2完全足够，关键在于提前设计好QoS和无损策略，并且预留运维调试时间。

还有一个容易被忽视的点：新入局者在选RoCE时，务必提前测试不同厂商交换机的PFC和ECN兼容性。很多项目死不是死在理论性能上，而是死在多厂商设备策略不一致导致的隐性丢包上。

4. 集群拓扑设计：从胖树到Torus再到3D Torus

4.1 胖树（Fat-Tree）：大集群的基本盘

大模型训练集群里最常见的拓扑就是胖树结构。胖树的核心思想是：每一层链路的带宽总和等于或大于下一层的总带宽需求，从而保证任意节点对之间的通信都能获得接近线速的性能。

以经典的三层Clos架构为例：自下而上分别是边缘层（接入层）、聚合层（汇聚层）和核心层（脊层），每个下层交换机向上层多台交换机同时连接。这样任何节点之间的通信路径有多条可选，可以通过ECMP（等价多路径）进行负载均衡，不容易出现单点瓶颈。

千卡级GPU集群实际布线时，我们通常会按“计算节点-边缘交换机-聚合交换机-核心交换机”的顺序逐层汇聚。单个计算节点通常放4到8张GPU，节点的网卡通过高速线缆接入边缘交换机。聚合层和核心层的数量按带宽收敛比来算，一般要求无收敛，也就是每一层总带宽大于等于上一层需求。

胖树的另一个好处是容错性好，某条链路故障或某台交换机故障时，流量可以快速切换到其他等价路径，对训练任务的影响相对有限。从运维角度看，故障域更小，更好排查。所以面试时如果问到“为什么大多数集群选胖树”，核心答两点：一是可水平扩展，二是路径冗余天然支持故障恢复。

4.2 Torus与3D-Torus：高密度低成本的选择

胖树虽然性能好，但它需要大量的核心交换机和高带宽线缆，投资非常重。在某些场景下，特别是节点间通信局部性较强的任务中，可以用更低成本的Torus拓扑。

Torus可以理解成一个环形网格。每个节点只与相邻的节点连接，组成一个二维或三维的格状结构，并且在边缘处回环相连，相当于把整个拓扑的头尾接起来。它最大的优点是线缆总量大幅减少，构建成本远低于胖树。但缺点是任意两个节点之间的通信可能需要多跳转发，时延随着跳数增加而上升，对通信的局部性要求较高。

3D-Torus是在二维基础上再加一个维度，例如每台机器有6个网络端口，分别连接X、Y、Z三个轴上的前后两个邻居。这种设计主要被用于一些超算系统，以及节点间通信以邻居通信为主的场景。对大模型训练来说，由于集合通信中有大量跨随机节点的流量，纯Torus拓扑并不理想，所以它更多出现在超算场景，或者配合胖树做混合组网。

4.3 大模型集群的主流趋势：RDMA over Fabric

近几年在万卡集群设计中，一个明显的趋势是走向RDMA over Fabric的架构，本质上就是把高性能RDMA网络与可编程交换机结合起来，实现路径动态调度。

最典型的例子是英伟达的NVLink + InfiniBand融合架构，以及Google的TPU Pod采用的OCS（Optical Circuit Switch，光路交换）架构。OCS可以根据训练任务的需求动态调整拓扑连接，让通信频繁的节点组物理上更靠近。这种做法比固定拓扑更灵活，但代价是控制逻辑很复杂，而且光路切换本身有时间开销。

从面试角度看，你不需要真的去设计一个万卡网络，但至少要掌握这些拓扑解决的关键问题：胖树解决的是无阻塞高带宽，Torus解决的是结构成本约束，OCS解决的是动态流量适配。能讲清楚每种方案的适用边界，面试官就会觉得你有架构视野，而不只是会照着文档配机器。

5. 集合通信中的网络瓶颈分析

5.1 为什么AllReduce会成为训练性能的关键

在大模型数据并行训练中，AllReduce是出现频率最高的集合通信操作。每个训练step，所有GPU需要先把各自的梯度算完，然后通过AllReduce把梯度聚合成全局梯度。通信完成前，任何一张卡都不能进入下一轮参数更新，所以AllReduce的耗时直接叠加在每次迭代的关键路径上。

我习惯用一个直观的公式来解释：

迭代总耗时 ≈ 计算耗时 + 通信耗时 - 计算通信重叠部分

也就是说，如果计算耗时从100毫秒优化到90毫秒，但通信耗时50毫秒没变，最终收益远远不如把通信从50毫秒压缩到20毫秒来得明显。这就是为什么在大规模训练里，网络优化带来的收益往往比微调算子更显著。

那AllReduce底层到底是怎么在集群网络上实现的？通常做法是用Ring-AllReduce算法。把N张卡组织成一个虚拟环，每个节点只和前后两个邻居通信。梯度数据被切成N份，每个节点先把自己的第i份数据发送给下一个节点，同时从上一个节点接收数据，经历N次数据转发后，所有节点都聚合出完整的梯度。Ring算法最大的优点是把通信负载均匀分摊到所有节点，不依赖中心节点，不会出现单点瓶颈。

因为没有中心节点，Ring-AllReduce的通信时间理论上随节点数增长但扩展效率远优于Tree-AllReduce等中心化方案。许多面试题会问到“为什么大集群里用Ring而不用中心化方案”，另一个因素就是负载均衡和容错。

5.2 如何估算AllReduce的最低带宽需求

面试中经常出现的一道估算题：给定N张GPU卡、单卡梯度量G字节，问Ring-AllReduce理论上需要多久完成全局聚合。

我的计算方法如下：

• Ring-AllReduce的通信过程，每张卡在每一轮只需要发出N份数据中的一份，总共需要N-1轮传完。但实际上，每个数据分片经过环上每一条链路，所以总传输量与节点数无关，更准确的表述是：每个节点的发送量为2(N-1)/N × G，当N足够大时约等于2G。
• 也就是说，在这个理想模型下，千卡集群完成一次AllReduce的通信时间约等于2 × 单卡梯度大小 / 单卡有效带宽。

我用一个实际数字来演示：假设单卡梯度大小为200MB，网卡带宽为400Gbps（换算约为50GB/s）。那么理论AllReduce耗时约为2 × 200MB / 50GB/s ≈ 8毫秒。这在真实集群中已经是非常好的水平，如果实际测量值超过这个理论值两倍以上，说明网络存在拥塞、拓扑收敛或设备配置问题。

这个估算方法我自己在一次面试中被问到过，当时用这个模型快速算出预期值，再让候选人分析实际值与理论值偏差的可能原因。能在现场快速做这类估算的人，通常对网络系统的理解比较扎实。

5.3 AlltoAll：容易被忽视但难点集中的通信模式

相比AllReduce，AlltoAll在面试中出现的频率稍低，但实际难度更高。AlltoAll要求每个节点把数据切分成N份，分别发给其余N-1个节点，同时接受来自其余节点的数据。这个模式下每个节点都要同时和多点通信，流量交叉严重，对网络的并发能力要求非常高。

MoE（Mixture of Experts）模型是AlltoAll的典型应用场景。每个Token需要被路由到对应的专家节点，而Token的分配模式是动态的、无法预先确定的，导致网络流量出现突发性不均衡。这种场景下，胖树拓扑的多路径调度能力尤为重要。

如果面试官问你“MoE模型对网络有什么特殊要求”，你可以说三点：一是流量动态变化，需要网络路径的快速适应能力；二是单个Token的数据量很小但数量极大，对消息调度效率要求高；三是不同专家的负载天然不均衡，可能造成某些网络链路的局部拥塞。能在这种问题上给出多维度的回答，基本就能展示出你对网络与模型训练的交叉理解，这在面试中是加分项。

6. 拥塞控制与无损网络的底层机制

6.1 为什么无损网络对AI集群至关重要

传统以太网的设计逻辑是“尽力而为”：数据包一旦冲突或拥塞就丢弃，由上层协议重传。这种策略对普通网页浏览和视频流媒体没问题，但对RDMA并不适用，因为RDMA直接访问远程内存，操作系统不参与重传逻辑。一旦丢包，只能靠网卡硬件重传，而硬件重传的机制恢复慢，会让通信时间呈现“悬崖式”恶化。

AI训练通信以Burst流量为主，GPU每完成一次计算，所有梯度几乎同时涌向网络，形成瞬间并发。如果网络没有无损能力，交换机的缓存就会被瞬时填满，丢包就会发生。一个集群一旦开始频繁丢包，训练的稳定性就会急剧下降，严重时甚至出现训练直接中断。

所以，无损网络的目标就是保证数据在传输过程中不被丢弃，靠三层手段实现：流控（PFC）、显式拥塞通知（ECN）、以及端到端的拥塞控制算法（DCQCN）。这套机制组合在一起，让RDMA在以太网上也能获得接近InfiniBand的稳定传输表现。

6.2 PFC、ECN、DCQCN到底在干什么

PFC（Priority Flow Control，优先级流控）是一种逐跳的流控机制。它给交换机上的队列配置了不同的优先级，当某个优先级队列的缓存达到阈值时，交换机会向上一跳设备发送暂停帧，让上一跳暂停发送该优先级的数据。PFC能防止数据包丢失，但代价是有可能引发“拥塞树”问题，一个队列的暂停会层层向上传播，最终形成网络风暴，也就是面试中常说的PFC风暴。

ECN（Explicit Congestion Notification，显式拥塞通知）则是在IP层标记拥塞状态。交换机检测到队列深度超过阈值后，会在数据包头部打上CE（Congestion Experienced）标记。接收方看到CE标记后，反馈给发送方一个拥塞信号，发送方据此降低发送速率。ECN的好处是“通知”而非“停发”，避免了PFC那种长链路连锁反应。

DCQCN是把ECN和速率控制算法结合起来。具体来说，接收方收到CE标记的数据包后生成CNP（Congestion Notification Packet，拥塞通知包）发给发送方，发送方收到CNP后，按比例降低当前速率，再在后续过程中逐步恢复速率。这套机制可以让RoCE网络在拥塞时快速降速、拥塞消失后快速恢复，兼顾了无损性和吞吐利用。

面试官往往会追问：“如果PFC和ECN同时存在，谁优先？”从实际部署效果看，理想状态是在网卡侧拥塞控制生效之前，尽量避免触发交换机队列的PFC。因为PFC一旦介入，暂停帧可能在网络里扩散，造成多路径上的入口队列无谓堆积。所以部署RoCE网络时，一个核心策略是调优ECN阈值和DCQCN参数，让ECN先报警、先降速，PFC是最后一道防线而不是常态手段。

6.3 网卡侧参数到底怎么调

这部分是真正动手调优时最实用的内容，也经常成为面试中的深挖点。以常见的Mellanox网卡为例，RoCE模式下需要调整的关键参数如下：

• cqe_version：RoCEv2场景下应设置为1，使用MOD_ERR模式。
• ecn_enable：必须开启，这是让网卡识别交换机的CE标记并触发拥塞控制的前提。
• dcqcn_enable：是否开启DCQCN算法，通常配合ECN一起用。
• ratelimit：设置最大发送速率上限，避免单条流把集群出口带宽打满。
• priority：设置RoCE流量对应的优先级队列，确保与交换机的PFC优先级设置一一对应。

不少团队反映“RoCE性能上不去”且“训练时偶发中断”，我排查下来经验是七成问题都在参数错配上。比如网卡配置ECN开启，但是交换机端口没有开启ECN，或者网卡到交换机之间的PFC优先级不一致，都会导致流控机制失效。这里需要特别提醒：不同交换机厂商对ECN阈值的默认配置差异很大，必须要结合实际的队列深度做针对性调优。RTT（往返时延）也直接决定DCQCN的反应速度，跨机柜布线距离相差几米都会影响队列的初始设置。

7. AI集群网络面试常见问题与排查思路

7.1 高频面试问题速查表

按照我在面试中的经验，下面这些问题的出现频率极高，而且往往是连环问的开端。

面试不能只背答案，最好能结合实际项目讲清楚一个具体案例。比如我面试过一个候选人，滔滔不绝讲了一堆协议原理，但问他“你的训练集群网络遇到了什么问题、怎么定位的”，他却支支吾吾答不上来。所以如果你有实际项目经历，哪怕只是帮人调过一台交换机或排查过一次网卡降速，也要提前整理成条理清楚的case，这在面试中的说服力远超背答案。

7.2 实战排查：从现象到根因的定位路径

分享一个真实场景：一个192卡集群在训练过程中频繁出现“慢节点”，某几张卡的AllReduce时间比其他卡高出10倍以上，但GPU利用率（DCGM监控）并没有发现明显异常。

我当时排查路径是这样的：

第一步，先确认是哪张卡慢。用nccl-tests跑一轮AllReduce测试，发现慢节点集中在同一个机柜。

第二步，看网络监控数据。查看交换机端口出现大量丢包计数，以及该机柜接入交换机上联端口流量接近带宽上限。此时基本判断是物理链路饱和或配置问题。

第三步，检查RoCE参数。发现该机柜交换机的ECN阈值被设置得极低，流量稍微波动就触发CE标记，网卡侧反复降速，导致通信变慢。

第四步，调优ECN阈值和网卡DCQCN参数后，重新跑测试，慢节点现象消失，AllReduce时间恢复均值水平。

这个case给面试官的信号比背一堆理论更有效，因为它说明了候选人能根据现象判断根因类别，并且有实际动手调参的经验。我认为面试中讲这种故事的价值在于能展示提问者自己的分析框架和排错逻辑，而不是直接给结论。

7.3 网络性能验证常用工具

工具是日常运维和面试准备最实用的部分，推荐下面几个我实测下来特别顺手的：

• nccl-tests：英伟达官方集合通信测试工具，也是面试时最常提到的。可以分别测AllReduce、AllGather、ReduceScatter等操作的带宽和延迟，通过设置-b、-e、-f等参数控制消息大小范围。
• ib_write_bw/ib_read_bw：测试RDMA单链路带宽和延迟，用来验证网卡与交换机之间的物理链路状况。
• perftest：Mellanox官方性能测试套件，用法简单，适合直接跑点对点和集合通信测试。
• ethtool -S：查看网卡侧的丢包、PFC暂停帧技术，是定位RoCE网络问题最关键的命令之一。
• top/nvidia-smi：排查GPU利用率与网络通信是否符合预期，区分是计算瓶颈还是通信瓶颈。

我建议你在面试前花一个周末，在自己手头或申请的测试集群上跑一遍这些命令，把典型输出截图记录在案。面试时直接说“我用nccl-tests把千卡集群的AllReduce带宽从X提升到了Y”，这比任何堆砌概念都有说服力。技术面试中，权威工具输出比形容词更有可信度。

8. 从面试视角延伸：AI Infra岗位真正关心的三种能力

前面讲了很多具体知识点，但我想在最后，从面试官视角把考察点抽象一下。AI Infra岗位面试的候选人数不少，能完整背诵IB和RoCE知识点的人已经很多，真正稀缺的是把知识点组织成“系统能力”的人。

第一种能力叫“链路视野”。你在解决一个慢节点问题时，不是只盯网卡或GPU，而是能画出完整的数据路径，从GPU显存到NVLink、PCIe、网卡、线缆、交换机端口、远端网卡，每一跳都可能成为瓶颈。面试时如果被问“集群性能上不去怎么排查”，你会从最细的链路开始逐段隔离定位，这属于系统性的能力，靠背题练不出来，必须通过实操积累。

第二种能力叫“成本判断”。任何网络方案都是在带宽、成本、规模、稳定性之间取平衡。我在实际项目里遇到过为了最优性能强行上全套IB方案，结果预算超支导致项目停滞的案例。面试时如果你能主动讨论“如果预算有限，我会优先保证无阻塞网络的哪几层”，面试官基本会给你打高分。这些判断中的细节（比如哪些层的带宽收敛比可以略微让步、哪些层必须无阻塞）来自对具体场景的长期观察，而不是教科书上的通用答案。

第三种能力叫“故障反应速度”。大模型训练集群故障发生频率不低，而且代价高昂——一个千卡集群闲置一小时的成本，抵得上很多普通项目的整体预算。面试时考察的不只是你会不会修，而是你的修复过程有没有章法，能否快速定位、隔离、止血，而不是盲目反复重启。训练任务恢复时，安全和规范操作要优于“立刻恢复训练”的冲动，这点在面试中谈出来也很加分。

最后分享一个小心得：如果你正在准备AI Infra面试，不要只盯着面试题去刷，找一个真实的分布式训练集群，哪怕只有几十张卡，把集合通信测试、RoCE参数调优、PFC排查这些操作亲手做一遍，收获会远超你背二十篇八股文。网络是一个实践性极强的领域，纸上得来终觉浅，面试官也是从实践的泥潭里爬出来的，你聊到哪个深度，他自然知道你是真懂还是背题，这个装不了。