企业官网建设流程全解析

说实话，今年看完云栖大会上AI基础设施相关的分享，我最深的感受不是又出了多少新模型、哪个榜单分数又涨了，而是身边好几个做训练优化和平台架构的朋友，都在反复讨论同一个话题：集群规模从几百卡扩到几千卡之后，训练效率怎么反而往下掉？

绕来绕去，最后都归结到一个之前不太受重视的环节——AI系统网络架构。这个在芯片参数对比面前显得“没什么存在感”的东西，恰恰是大规模智算集群里最容易变成瓶颈、也最容易被人忽略的部分。这篇文章我就把这次大会前后看到的、听到的、以及自己实际踩过的一些关于AI系统网络架构的坑，整理成一份实打实的技术复盘。不管你是做训练框架、搞平台调度，还是维护智算中心网络的同学，应该都能从中找到一些有价值的东西。

1. AI系统网络架构为什么突然成了智算集群的胜负手

1.1 从“纸面算力”到“有效算力”的跨越

先聊一个很多人没想透的问题：我们常说的“集群有多少P算力”，其实是一个非常虚的数字。它代表的是所有加速卡的理论峰值之和，是一个纯粹物理层面的上限。而真正决定训练跑得快不快、钱花得值不值的，是系统的有效算力，也就是模型实际训练时能够用起来的那部分计算能力。

在AI训练场景里，衡量有效算力最常用的指标叫模型利用率（Model FLOPs Utilization, MFU）。简单理解，就是模型实际跑出来的吞吐量，除以集群理论峰值算力得到的百分比。一个几千卡规模的训练集群，MFU能稳定跑到50%以上，已经算是不错的水平；但在网络链路有瓶颈、通信拓扑不合理的情况下，MFU掉到30%甚至更低也很常见。也就是说，你花了几个亿买的算力，可能有将近一半是“睡着”的。

为什么网络对MFU的影响这么大？我习惯用一个生活化的类比来解释：把整个训练集群想象成一条流水线工厂，GPU是车间里的工人，显存是工人的操作台，而网络就是车间之间的传送带。工人的手速再快，如果传送带运料不及时、或者物料在传送带上堵住了，整个工厂的产出照样上不去。AI系统网络架构就是这套传送带系统，它的带宽、时延、拥塞控制能力，直接决定了“物料”能不能及时送到每个工人手边。

很多团队在做算力规划的时候，眼睛只盯着买了多少张卡、单卡算力多高，却忽略了网络拓扑设计和通信协议调优。等到集群真正跑起来，才发现GPU之间“互相等数据”的时间比算的时间还长。这时候再回头改网络架构，代价极高。这也是为什么我建议所有做AI基础设施的人，都应该把AI系统网络架构放到跟芯片选型同等重要的位置来看。

1.2 一个训练迭代里的网络账单

要真正理解AI系统网络架构对训练的影响，不能只看抽象概念，得算一笔具体的账。我们以一个大模型训练的场景为例，假设模型参数量是7B，采用BF16精度混合精度训练。BF16下每个参数占2字节，那么一份模型参数大约是14GB。在做数据并行（Data Parallelism）训练时，每个训练步结束时，所有GPU需要把各自计算出来的梯度汇总到一起，再更新模型参数，这个动作就是集合通信里的AllReduce。

让我们算一下这次AllReduce的通信量。假设集群有128张GPU，梯度总量和模型参数一样大，也就是14GB。在N个节点做AllReduce，每个节点实际需要收发大约2*(N-1)/N*D的数据量。代入N=128、D=14GB，通信量大约是27.8GB。如果每张GPU的网络带宽是400Gbps，也就是大约50GB/s的理论带宽，那么理想情况下一次AllReduce需要大约0.56秒。算上协议开销、由于消息切分产生的效率损耗，实际操作中跑到40GB/s已经算不错，那就是0.7秒左右。

看起来0.7秒不长，可问题在于：一个训练迭代的计算时间是多少？如果是7B模型、单卡batch size较小、序列较长的情况，一个迭代的计算时间可能在3到5秒左右。也就是说，光是梯度同步这一项，就要占掉整个迭代时间的15%到20%。如果网络拓扑不合理、出现拥塞，通信时间翻倍也毫不意外，这时候通信占比可能接近三分之一。

这还只是纯数据并行的场景。如果模型用了张量并行（Tensor Parallelism）、流水线并行（Pipeline Parallelism），甚至更激进的专家并行（MoE），通信模式会复杂得多。特别是MoE模型里的All-to-All通信，每个token都要去跟远端的专家做数据交换，通信量呈爆发式增长。我见过一些MoE训练场景，通信时间甚至能占到整个迭代时间的40%以上。所以AI系统网络架构要解决的问题，从来不是“能不能通”，而是“通得够不够快、有没有让计算一直在走”。

1.3 训练、推理、数据管道，三种场景三种诉求

AI系统网络架构并不是一个单一维度的东西，它在训练、推理、数据预处理这几个不同场景下的诉求差异非常大。

先看大模型训练。训练阶段是“高带宽、高并发、强同步”的典型场景。每个训练步里都有大量GPU之间的数据交换，而且是周期性的、可预测的流量模式。这对网络的要求是：带宽尽量跑满、时延尽量低、不丢包、不重传。训练集群的网络架构设计重点在于集合通信的性能优化、拓扑结构对通信模式的适配、以及拥塞控制策略的精细化调优。

再看推理场景。推理阶段更看重“低时延、高吞吐、动态负载均衡”。在线推理请求是稀疏的、突发的、不可预测的，而且每个请求可能打到不同的GPU实例上。这时候网络要能快速响应突发的流量，不能被某个慢链路拖住整个请求。Preemption、动态路由、QoS这些能力，比纯粹把带宽跑满更重要。

最后说说数据管道。数据处理阶段反而是很多团队忽视的地方。训练数据要不停地从存储系统流到GPU显存里，如果数据管道带宽不够，GPU会长时间空转等数据。我之前遇到过一个项目，GPU利用率一直上不去，排查到最后，发现是数据加载环节的网络路径设计不合理，跨交换机的流量全部挤在一条链路上，把数据管道堵死了。

所以，评估AI系统网络架构的时候，不能只盯着训练这一个场景，要把训练、推理、数据流整个链路都纳入设计范围。这也是为什么现在的智算中心普遍把钱花在构建一张“统一承载”的网络底座上。

2. 智算中心网络怎么搭：从拓扑到无损的三大关键选择

2.1 两层还是三层：CLOS拓扑背后的逻辑

聊AI系统网络架构，绕不开的一个基础话题是网络拓扑。现在智算中心几乎清一色采用CLOS（Clos Network）架构，也叫叶脊（Leaf-Spine）架构。它的核心思想是把网络分成两层：Leaf层交换机直接连接GPU服务器，Spine层交换机负责把Leaf层互联起来，任意两个Leaf之间都通过Spine一跳可达。

为什么CLOS架构能统治AI数据中心？原因有三点。第一，无阻塞扩展性。CLOS架构天然支持横向扩展——Leaf交换机数量翻倍，只需要把Spine交换机也翻倍，网络容量基本可以线性增长。第二，故障域隔离。如果某台Leaf交换机宕机，影响的只是它下挂的那几台服务器，其他部分不受影响，这比传统三层树形结构安全得多。第三，东西向流量优化。AI训练的大部分流量是GPU之间的东西向流量（GPU到GPU），而不是传统的南北向流量（客户端到服务器）。CLOS架构让任意两个Leaf之间的路径都很短，不用绕路上层的核心交换机。

在实际工程中，小规模集群（几十卡到几百卡）通常用两层CLOS就够了。Leaf交换机负责接入GPU服务器，Spine交换机负责互联，两层之间全互联。但当集群规模上到几千卡甚至几万卡的时候，两层CLOS的Spine交换机端口数量会成为一个物理瓶颈，这时候就需要升级为三层CLOS结构：在最上面加一层核心层（Super Spine），中间是Spine层，下面还是Leaf层。

我在设计网络方案的时候，有一个经验值供参考：对于一千卡以内的集群，两层CLOS是比较合适的，控制简单、故障排查也容易；超过一千卡，建议直接上三层CLOS架构。另外还有一个容易被忽略的点：Spine层交换机之间不要用堆叠（Stacking）技术把多台物理交换机虚拟成一台。虽然堆叠能简化配置，但它在AI集群这种高负载、低时延场景下，容易引入跨设备的转发瓶颈，而且故障域会变大。CLOS的哲学本来就是“用多台小交换机撑起一个大网络”，不要破坏这个前提。

2.2 无损网络不是“打开开关”就行

AI系统网络架构里，另一个核心概念是“无损网络”。为什么需要无损？因为AI训练普遍走RDMA（Remote Direct Memory Access）通信。RDMA允许网卡直接读写远端内存，绕过了CPU，极大降低时延，但它有一个硬性要求：不能丢包。一旦RDMA报文在网络里丢了，发送端要等待重传，这个重传时间在高速网络里是非常致命的，会导致训练性能雪崩式下降。

为了不让RDMA报文被丢弃，传统的做法是加大交换机buffer（暂存队列）来吸收拥塞。但AI集群的流量是典型的“多打一”（Incast）模式——多个GPU同时把数据发给一个GPU，交换机收到的流量瞬间超过出端口能力。再大的buffer也扛不住这种突发流量，于是业界普遍采用基于优先级的流控机制（Priority Flow Control, PFC）来构建无损网络。

PFC的原理说起来很简单：把交换机端口划分成多个优先级队列，当某个队列快装满的时候，交换机向对端发暂停帧，让对方先别发了，等队列缓过来再继续发。这套机制确实能在一定程度上保证“不丢包”，但实际运维中远不是打开开关就万事大吉。

这里有一个我在实际项目中反复踩过的坑：PFC是有“传染性”的。当某个Leaf交换机因为下游拥堵发暂停帧时，暂停帧会一级一级往上传递，形成“拥塞树”，把整个网络的可用带宽都拉低，严重时甚至出现“所有流量都卡住”的假死现象。这种现象业内叫PFC风暴。

所以，真正专业的做法是把PFC和ECN（显式拥塞通知）配合起来使用。ECN的思路是“提前预警”：交换机检测到队列超过阈值时，不再是直接丢包，而是在报文里打上一个“我被堵了”的标记，接收端看到标记后，主动告诉发送端降低发送速率。这样网络就从“被动暂停”进化成了“主动调速”，拥塞的影响面会被控制在一个很小的范围。一个经验是：ECN的阈值设置不要照搬厂商默认值，要结合交换机buffer大小和网络拥塞程度来调。阈值设得太大，ECN的预警作用就不明显；设得太小，又容易误报，导致链路利用率下降。这需要反复压测，找到合适的平衡点。

2.3 无损网络两大流派：IB和RoCE v2的取舍

聊到无损网络，就绕不开一个经典的选型问题：用InfiniBand（IB）还是RoCE v2？这次大会上，我听到的讨论也基本集中在这些方案上，说明这确实是大家最关心的话题之一。

先给不太熟悉的朋友简单区分一下。IB是专为高性能计算设计的完整网络方案，从链路层到传输层都是“自带干粮”，无损是它与生俱来的能力，而且它支持自适应路由，可以动态选择更优的路径绕开拥塞。RoCE v2则是基于标准以太网的RDMA实现，它的优势是继承了以太网的生态——世界上几乎所有工程师都懂以太网，它可以跟传统TCP/IP流量混跑在同一个网络里，而且成本要低于IB。

在实际的智算集群建设中，我见过不少团队一开始倾向于选IB，因为它“开箱即用、性能稳定”。这在纯AI训练场景下确实成立。但一旦涉及多租户、混合负载（训练、推理、存储流量混跑），IB的封闭生态就会带来麻烦，调试工具的丰富程度、跟开源框架的适配便利性都不如RoCE v2。

RoCE v2的挑战在于，无损特性需要你自己搭——要配PFC、要调ECN、要确保网络里所有设备都正确支持这些机制。这是一件“看起来简单、做起来痛苦”的事，但它换来的是开放的生态和更灵活的选择空间。我的个人判断是：如果团队的网络运维能力比较强，又有混合负载的需求，RoCE v2是更合理的选择；如果纯粹是单一大模型训练集群、追求极致稳定，IB也完全可以考虑。没有绝对的好坏，只有适不适合自己的场景和能力。

3. 集合通信：藏在AI系统网络架构背后的“隐形操作系统”

3.1 从AllReduce到All-to-All：不同的并行策略，不同的通信模式

如果只看网络硬件，容易忽略一个关键事实：AI系统网络架构最终服务的，是上层那些集合通信操作。这些操作定义了大模型训练里GPU之间到底怎么“对话”。理解不了这一层，网络优化就无从下手。

最核心的集合通信操作有以下几种，我整理了一个表方便对比：

不同并行策略对网络的压力点完全不一样。张量并行（TP）是把一个Transformer层切成多份放在不同GPU上，每个计算步骤里都需要AllReduce交换中间结果。它的特点是消息小（可能只有几十KB到几MB）、频率极高，对时延非常敏感，对带宽反而不太敏感。数据并行（DP）是每个GPU持有完整模型副本，各自吃不同batch的数据，只在梯度同步时需要一次大的AllReduce。它的特点是消息极大、周期性出现，把AllReduce这个动作优化好，或者把它跟反向计算重叠掉，收益最明显。

最“凶残”的是MoE模型的All-to-All通信。MoE模型把网络层替换成一组专家模块，每个token都需要被路由到合适的专家上。由于token的路由结果是不确定的，每个GPU都要向其他GPU发送自己那一部分token数据，同时接收其他GPU发来的token。这是个N平方量级的通信模式，在不做优化的情况下，通信量极其惊人。我实测过一些MoE模型，通信等待时间占比可以高到让人怀疑是不是机器挂了。

所以如果要用MoE模型做大规模训练，网络架构设计一定要提前考虑All-to-All的流量特性。至少要保证交换机有足够大的buffer，尽量采用全连接或高维度拓扑，避免任何一条链路成为All-to-All流量瓶颈。还有一点心得：MoE模型里专家往往不是均匀分布的，有些热门专家接收的token特别多，会造成局部的热点。网络上要有应对这种局部拥塞的能力，否则一个热门专家的带宽被挤爆，整个训练都得等它。

3.2 通信计算重叠：把等待藏起来

网络优化做到极致，目标并不是把通信时间压缩到零，而是让通信时间不要暴露在关键路径上，这就要靠通信计算重叠（Overlap）。

以大模型训练中最重要的梯度AllReduce为例。一个训练迭代分前向传播和反向传播两个阶段。反向传播是从输出层往输入层逐层计算梯度。理论上，等所有层的梯度都算完，再发起一次全局AllReduce就行。但这样通信和计算是完全串行的——先算完所有梯度，然后停下来等AllReduce结束，网络空转的同时GPU也在干等。

更聪明的做法是：反向传播一层、算完一层的梯度，就立刻把这一层的梯度送进通信队列，跟远端GPU做聚合。这样通信动作和后续层的反向计算是并行发生的，AllReduce的时间被“藏”在计算时间里。这就是所谓的“梯度分桶重叠”（Gradient Bucket Overlap），NCCL（NVIDIA Collective Communications Library）原生支持这个机制，但需要用对参数。在NCCL里，梯度分桶默认是按消息大小切分，如果你把bucket size设得过大，通信块的粒度太粗，重叠效果就不好；设得太小，又会增加通信调度本身的CPU开销。我调参的经验是，起步可以用8MB到16MB这个范围，然后观察通信占比变化来做微调。

除了把AllReduce和反向计算重叠，还有一个思路是利用多个通信流（Stream）并发。把大块数据切分成多个小块，在不同通信流上同时传输，可以更充分地利用多路径带宽，同时减少单一大消息对网络缓冲区的冲击。但要注意，通信流开的数量不是越多越好，太多会让控制平面（CPU）负担过重，反而拖慢整体效率。

3.3 从拓扑感知到交换机组播：集合通信的进阶优化

有时候，集合通信的性能瓶颈不是单次通信本身的效率，而是通信模式跟网络拓扑的匹配度。经典的AllReduce环状算法里，消息要沿着逻辑环挨个接力传输。如果逻辑环的节点分布在网络的各个角落，数据要走很多跳，延迟和拥塞概率都会增加。于是出现了拓扑感知（Topology-Aware）优化：在分配训练任务的时候，尽量让参与同一个AllReduce的GPU落在同一个Leaf交换机下，减少跨Spine的流量。这跟现实生活很相似——同一个团队的人坐在同一个办公区，沟通成本自然低。

更进一步的方案是“分层通信”（Hierarchical Communication）。把GPU分成组，组内先做一次归约，把结果平均成一个中间值，然后在组间做一次归约，最后再广播回去。这样可以把大量跨网络的数据交换转换成少量的小规模交换，大幅降低对核心交换层的压力。我自己在跑大规模数据并行训练时，就经常用这招来解决跨Spine链路拥塞的问题。

最近还有一个趋势，是让交换机和网卡直接参与计算，叫“网内聚合”（In-Network Aggregation）。传统AllReduce的通信量是数据量的约2倍（先归约再广播），如果能交换机和DPU（数据处理单元）在数据经过时顺路做掉“归约”这个计算，GPU之间的通信量就能大幅下降。有人做过实验，带上网内聚合之后，AllReduce的整体完成时间可以缩短到原来的三分之一左右。对超大集群来说，这是个值得持续投入的方向。

4. 大规模训练集群的网络问题排查与实战心得

4.1 训练效率上不去？先看通信占比和网络健康度

很多团队遇到“训练效率上不去”的问题，第一反应是调batch size、调学习率、换并行策略，折腾了一大圈没啥效果。我自己的排查习惯是：先看通信占比，也就是看一个训练迭代里，GPU有多少时间花在“等网络”上。

怎么测？最简单的方法是用NVIDIA官方的NCCL测试工具（nccl-tests）。跑一个AllReduce性能测试，输入消息大小设为256MB左右，观察实际能达到的带宽。以400Gbps网卡为例，如果你的AllReduce带宽只能跑到线速的50%以下，那网络大概率有问题。健康状态下，non-blocking模式的AllReduce至少应该达到线速的70%到80%以上。这个数据可以作为基线，以后每次做网络变更，都用同一套测试来回测，看性能是否退化。

除了集合通信测试，还要做网络链路的单流测试。用perftest工具里的ib_write_bw（如果是IB环境）或者rdma_write_bw，测任意两台GPU服务器之间的点对点带宽。如果单流带宽远低于预期，就要去检查对应的光模块、线缆和交换机端口，很多问题在这一步就能暴露出来。

训练日志层面，建议在训练框架里开启通信时间的trace。NCCL提供了NCCL_DEBUG=INFO级别的日志，可以打印出每个通信操作的时间细节。把日志捞出来统计一下，你就能看到一次迭代里AllReduce花了多少时间、Overlap的效果如何、是不是某个通信操作卡了很久。我遇到过一些看起来“很慢”的训练任务，排查下来就是某个GPU的PCIe链路降速了，导致它作为AllReduce环节里的“拖油瓶”，把整个环的通信时间都拉长了。

4.2 三个高频故障：丢包重传、PFC风暴、慢节点

AI训练网络的故障，翻来覆去就是那么几类。把这三类搞清楚，大部分问题都能解决。

第一类是RDMA丢包重传。注意，这里不是说绝对丢包，而是相对RDMA而言的“丢包”。哪怕网络里丢包率只有万分之一，对RDMA训练性能的打击都是毁灭性的——一个重传的报文需要等待超时之后重新发送，这个等待时间在几十微秒级别的RDMA通信里是灾难性的。排查丢包，用ethtool -S看网卡统计里的rx_missed、tx_dropped等计数，用交换机管理口看端口上有没有CRC错误或过大/过小的包。如果发现问题集中在某个端口，通常是光模块脏了、线缆老化或者端口协商速率异常。对付这种问题，我唯一的建议是：机房里的线缆和光模块一定要按高质量标准采购，这地方省下来的钱，最后都会花在无数个加班的深夜里。

第二类是PFC风暴。这比丢包更隐蔽，表现是网络带宽整体下降，但看不出哪个端口有明显错误。排查方法是登录交换机看PFC暂停帧的统计数据。如果某个端口的PFC暂停帧计数持续快速增长，说明这里正在发生拥塞。这时候要顺着暂停帧的来源一层层找，通常能定位到某个“多打一”的流量模式。解决办法有二：一是优化上层应用的通信节奏，尽量避免大流量同时打到同一目标；二是调整PFC队列的阈值，给不同流量类型设置隔离策略，防止PFC暂停扩散成“拥塞树”。

第三类是慢节点问题。AI训练集群里，“木桶效应”非常明显——一个训练迭代的速度，取决于最慢的那个GPU什么时候完成通信。偶尔一次网络抖动，让某个GPU的通信慢了10%，整个集群都得等它。这就是为什么监控单条链路平均带宽还不够，要监控“尾延迟”（Tail Latency）。实践中我们会在网络监控里特别留意那些时延明显偏高的长尾链路，把它们列为重点盯防对象。别小看这个问题，几万卡的集群里，每隔一段时间总有几个节点会掉链子，让这些慢节点及时得到修复，对训练效率的稳定贡献非常明显。

4.3 网络监控和告警的实用清单

网络运维和训练平台运维往往分属不同团队，AI训练集群的网络监控要想真正有效，需要一套双方都认可的指标和操作流程。我把自己在做的指标清单列出来，供大家参考：

• 单流带宽与集合通信带宽基线：每台GPU服务器上线时，跑一次标准测试，记录基线值。
• 丢包重传计数器：训练过程中周期性抓取网卡和交换机的错误/丢包统计，异常增长要告警。
• PFC暂停帧计数：特别是RoCE v2环境，这是判断网络是否“亚健康”的核心指标。
• 端口光功率与温度：光模块衰减是慢节点的常见前兆，光功率跌落超过3dB就要关注。
• 链路利用率最大值与均值：AI训练流量波动大，只看均值会掩盖瞬时拥塞，要同时看5分钟内的峰值。
• 通信时间占比指标：从训练框架侧统计通信等待时间占比，超过阈值触发异常通知。

还有一点值得提醒：不要把所有告警都设置成“问题已经发生了才报”。无损网络的好处是能提前发现问题，比如ECN标记率上升，往往是拥塞的前兆，这时候介入处理，可能只需要调整流量路径，问题就能消解于无形。如果等PFC风暴已经形成了再去处理，影响的可能就是整个集群的性能了。

5. 从云栖大会看AI系统网络架构的后续演进方向

5.1 超节点化：把“小集群”变成“大单体”

看大会上的分享，有一个很明显的信号：AI系统网络架构正在朝着“超节点”（SuperPod）的方向演进。什么意思呢？过去是几百张卡组成一个训练任务，卡与卡之间靠网络互联。现在大家尝试把几千张甚至上万张卡放进一个“超节点”里，用更高带宽、更低时延的互联方式把它们组合成一个逻辑上的“大GPU”。

超节点的好处在于，它能把原来跨网络的通信变成“机内通信”，带宽和时延都能得到很大提升。随之而来的网络架构变化是：单机内部互联密度大幅提高，GPU之间除了传统意义上的“网络交换”，还出现了各种直连拓扑。这对原有的AI系统网络架构来说是个不小的挑战——过去我们习惯把“机内”和“机间”分开考虑，现在这两者的界限越来越模糊。

另一个方向是带宽代际跃升。当前主流的AI集群网络带宽在400Gbps级别，但多个头部厂商已经在布局800Gbps，甚至1.6Tbps的方案。带宽翻倍不是简单的换光模块，整个交换芯片、线缆、网卡都要跟着升级，这是一整套系统协同工程。我自己的体会是，带宽升级带来的收益是阶段性的，但拥塞控制算法要跟上链路速率的变化，否则单纯把带宽加大，只会让拥塞发生得更猛。

5.2 网络与算力调度的深度协同

接下来值得关注的是“网络感知调度”。传统作业调度器（比如Slurm）分配GPU资源时，通常只看显卡数量够不够，很少考虑GPU落在网络的什么位置。在大规模集群里，这种“盲分配”很容易导致一个训练任务的一批GPU散布在多个Leaf交换机下，大量流量都压到Spine层，造成不必要的拥塞。

更好的做法是让调度器带上网络拓扑信息，分配资源时优先把同一个任务的GPU尽量集中到同一片网络区域。这个优化不需要改硬件，只需要在调度器和网络控制器之间增加一个拓扑感知的插件，就能显著减少跨Spine流量。我在实际项目里观察到，仅仅是做好拓扑感知调度，某些训练任务的通信时间就能减少20%以上，效果相当可观。

再往前一步，是“弹性训练”与网络的配合。大模型训练经常伴随节点的动态加入或退避，流量因此会动态变化。如果网络能跟训练框架联动，任务收缩时及时释放网络路径，任务扩张时快速为新节点配置好网络策略，整个集群的资源利用率还能再上一个台阶。

5.3 给从业者的几个判断与建议

看完这一轮AI系统网络架构的演进，我有几个判断想分享给同行：

第一，RDMA和无损网络会成为AI基础设施的标配，未来几乎所有大模型训练集群都会跑在这个底座上。所以无论是做网络研发还是做训练平台，都需要把无损网络的原理吃透。第二，对于大多数公司来说，直接买成品方案比自己搞定制硬件更划算。网络底层的交换芯片、光模块、网卡技术壁垒很高，除非有海量规模和极强的研发能力，否则把精力花在上层的网络优化和调度策略上，ROI更高。第三，网络问题与训练框架问题会越来越纠缠在一起。未来最需要的人才，是既懂NCCL底层原理、又能看懂交换机配置的双栖工程师。我正在带团队，越来越感觉到这类人的价值有多高。

最后还想起一句话，是这次大会上某位做架构分享的朋友说的：“AI系统网络架构的问题，本质上不是在造网络，而是在造一台由几千个GPU组成的巨型计算机的操作系统。”这句话我越想越觉得到位。网络基础设施的能力上限，决定了这台“巨型计算机”能跑多快、能用多稳。对每一个做AI基础设施的人来说，这既是挑战，也是全新的机会窗口。