大模型训练做到上千卡、上万卡规模以后你会发现一个挺反直觉的现象瓶颈经常不在 GPU 算力而在 GPU 之间的那张网。Oracle 最近放出的 OCI Zettascale10 超级集群配上 Oracle Acceleron RoCE 网络架构恰恰就是在回答“当算力堆到边际的时候网络怎么接得住”这个问题。这套组合的目标很明确就是想把前沿 AI 负载从“勉强能跑”推到“性能边界持续扩展”的位置而不是在扩卡的过程中眼睁睁看着利用率一路滑坡。无论你是在规划自己的 AI 基础设施还是单纯想看清楚下一代训练集群长什么样这篇文章大概都能给你一些新视角。1. 大模型训练里真正的隐形瓶颈卡多了网先撑不住1.1 通信与算力的剪刀差GPU 在等谁我一直觉得很多人对 AI 训练集群的认知还停留在“买更多更强的 GPU”这个层面。单卡算力确实在飞快提升Tensor Core、FP8、稀疏化、更大显存每一代都有明显进步。但 GPU 之间的网络带宽提升并没有跟上这个节奏。你实际训练一个 70B 甚至更大参数的模型就会明白每个训练 step 都要做梯度同步。数据并行下每张卡算完一小批样本就得发起 AllReduce把几 GB 的梯度汇总到所有卡上。模型越大梯度越大卡数越多一次同步的通信量越大。如果网络拖后腿GPU 只能空转等数据。木桶效应在这里特别扎眼单卡算力是桶壁网络是桶底底不够深水位永远上不去。更要命的是大模型训练不是只有一种并行模式。数据并行要 AllReduce张量并行要高频的 AllGather 和 ReduceScatter流水线并行要 P2P 点对点传中间激活。这些通信模式叠加在一起对网络的要求是低延迟、高带宽、不丢包三者缺一不可。单卡再强这张网接不住集群整体照样跑不出效率。1.2 三个在大规模训练里被反复低估的瓶颈在我的观察里有三类问题几乎每次在大集群上跑训练都会遇到但经常被当成“运气不好”而非架构问题。第一类是拥塞。传统 TCP 在大规模 AI 场景里有天然劣势它的可靠传输和拥塞控制机制是为广域网设计的讲究稳定不讲究数据中心内的超低延迟。TCP 的慢启动、重传退避遇到 AI 训练这种同步的、周期性的突发流量表现出来就是“平均带宽还行尾延迟惨不忍睹”。而在同步训练里尾延迟就是全局延迟一条慢链路拖垮一整个集群是家常便饭。第二类是集体通信和网络拓扑不匹配。所有并行策略都对拓扑敏感。常见树形网络里不同叶子节点之间的通信要穿过多层汇聚链路大量流量挤上去就会拥塞。更麻烦的是传统 ECMP 的哈希转发经常把流量不均匀地甩到几条路径上导致某条链路爆掉而其他链路闲置。这就是为什么新一代 AI 网络要专门做拓扑感知、自适应路由和多路径负载均衡——不是炫技是真的被大作业打怕了。第三类是检查点。训练作业动不动跑几周集群越大任何一块 GPU、一根光纤、一个交换机出问题的概率都越高。为了扛住故障你必须周期性写 checkpoint。但写 checkpoint 本身就有代价全量保存几十 TB 权重和优化器状态存储和网络会在那一瞬间被打满。如果这个环节没有设计好GPU 就会变成“停车场”每个周期都有一段时间在干等。Acceleron 这类网络架构对拥塞和拓扑的优化本质上就是在压这三种瓶颈的生存空间。2. Zettascale10 到底在解决什么问题从堆卡到系统级扩容2.1 从“Zetta”这个单位看超级集群的定位先说个背景知识。“Zetta”是 10 的 21 次方比 Exa10 的 18 次方高三个量级。前几年大家还在谈百亿亿次Exascale超级计算机Zettascale 这个名字听起来就像直接跳到下一代目标。我理解 OCI Zettascale10 超级集群的定位不只是“把更多 GPU 塞进一个集群”而是把机柜、交换、存储、供电、散热、调度看成一套整体来设计。算力堆到这种刻度以后决定成败的往往不是某块卡跑多快而是整个系统的协同水平。就像高速公路上不是车越多通行效率就越高入口匝道、收费站、服务区任何一个环节跟不上整条路都会堵死。当然要到这个量级连基础设施的物理设计都得变。万卡级集群的走线方式、核心交换机端口数量、光模块密度、机柜散热方案每一项都是限制条件。很多团队在扩张到几千卡以后就发现网络架构从核心层就开始“卡脖子”换交换机都不是简单的堆叠问题。2.2 集群不只是堆 GPU存储、拓扑和调度都要配套如果你以为 Zettascale10 的亮点只是把 GPU 数量堆上去那可能低估了这个事的复杂度。一个超级集群想真正跑起来至少有三件事是同步升级的。存储和数据管线必须跟上。超大规模训练的数据读取速度是 TB/s 级别。如果你的训练集是海量小文件训练启动阶段就可能出现 IO 风暴——几千个进程同时抢读磁盘队列直接打爆。行业里常见做法是把数据集打包成更大块的大文件或者用高性能缓存层遮住对象存储的延迟。否则网络再快数据也送不进 GPU。调度器要有拓扑感知。你有一个 4000 卡的作业如果调度器不考虑物理拓扑可能把任务分到跨越多个网络分段的机器上跨交换机流量立刻把骨干链路打满。反过来如果调度器能感知“哪批卡在同一个叶子交换机下面”把通信量大的进程放在一起集群利用率能差出好几个点。还有一个经常被忽略的供电和散热在一万卡以上的集群里已经上升为架构问题。每机柜功率密度大幅提高液冷从可选项变成常见配置。这些话题看着和“AI”没什么关系但真正运营超级集群的人每天都在跟它们打交道。2.3 超级集群的实用价值实验周期和试错成本说到这很多人会想训练一个模型而已有必要搞到万卡吗实际上前沿大模型团队的竞争焦点早就不是“能不能训出来”而是“多久能训完一次一年能试多少个想法”。同样训练一个 175B 级模型如果你的集群只有 2000 卡可能要 3 个月才出一版结果。换成 10000 卡且线性扩展效率不错的架构三周左右就能跑完。这个差距直接影响团队的实验方法论——短周期意味着你可以跑更多超参组合、更多数据配比、更多模型架构变体而不用每次实验都小心翼翼。这就是超级集群真正的价值它压缩的是作业周转时间也就是从一个想法变成一组实验结果的时间。我见过太多团队在集群小的时候不敢乱试所有人排队用卡一个参数实验要排一周。集群够大的时候你终于可以把实验当成日常操作而不是成本决策。Zettascale10 打出的口号是“重新定义性能边界”在我看来性能边界不只是单项跑多快也包括这种试错速度和研发节奏的上限。3. Acceleron RoCE为什么偏偏是这一种网络架构3.1 RoCE 是干什么的一张标准以太网上的 RDMA要理解 Acceleron先得理解 RoCE 解决的核心问题。RoCE 的全称是 RDMA over Converged Ethernet也就是把 RDMA 的能力搬到以太网基础设施上。RDMA 技术本身不新鲜它允许网卡直接读写远端机器的内存绕过内核协议栈和 CPU 拷贝。传统 TCP 收发数据就像快递员把每个包裹登记、入库、再派送RDMA 则像是直接把仓库钥匙交给收件人快递可以从源头直达库房中间不经过 CPU 这个中转站延迟能做到微秒级。RoCEv2 把 RDMA 报文封装在 UDP/IP 里让它可以跨网段路由。这样一来原本属于 InfiniBand 的“低延迟、高吞吐”特性在普通数据中心以太网上也能用。Oracle Acceleron 这个架构名字看起来很新本质上做的是同一件事用一套可以大规模扩展的以太网系统承载 AI 训练的海量同步通信同时把拥塞、丢包、延迟波动压到最低。3.2 为什么不用 InfiniBand成本、生态和运维的三角权衡传统 HPC 领域长期是 InfiniBand 的天下超算中心几乎非 IB 不用。IB 在 RDMA、无损网络方面有原生优势性能表现确实好。但到了超大规模云上问题就来了IB 的专用交换机和线缆成本高生态相对封闭而且需要专门的网络工程师去运维可扩展性限制也不少。RoCE 方案吸引人的地方在于它可以复用成熟的以太网交换芯片和光模块供应链。你可以用更接近主流数据中心的价格买到支持 RoCE 的高性能交换设备。对 Oracle 这种要同时承载数据库、通用云计算和大规模 AI 负载的厂商来说尽量统一网络底座显然更实际。只要无损以太网技术足够成熟RoCE 就能在接近 IB 性能的同时保留更灵活的设备选型空间。我经常拿这个对比跟朋友解释InfiniBand 像一辆专门定制的高性能赛车赛道、后勤、维修全得配套RoCE 更像是在一条标准高速公路上开改装车虽然要花心思优化驾驶技术但路网是通用的成本也更可控。到了万卡以上规模这个灵活性比那一点点极限延迟更重要。维度InfiniBandRoCE以太网延迟极低原生 RDMA接近 IB但需精细调优带宽高高且随以太网迭代快成本专用硬件较贵复用标准以太网成本友好生态较封闭与主流网络设备/芯片生态兼容运维门槛需要专门专家更接近通用网络工程技能大规模扩展支持但供应链受限供应链成熟扩展灵活3.3 Acceleron 这类网络在补哪些短板RoCE 的性能发挥从来不靠“插上就能用”。它需要一系列增强技术来保证无损和低拥塞PFC优先级流控防止丢包ECN显式拥塞通知做端到端拥塞反馈DCQCN 这类拥塞控制算法动态调节发送速率再加上多路径负载均衡和自适应路由。Acceleron 作为围绕 RoCE 做的网络架构公开的信息里最值得关注的点是它把上述那一堆底层机制做成了系统级能力而不是让每个用户自己去调。哪些流量优先级高、ECN 水线怎么设置、多路径如何分配、拓扑感知如何与调度器联动这些都要和超大规模训练负载的特性匹配。很多工程团队可能意识不到这一层的影响网络吞吐稍微上不去GPU 利用率就差好几个点。比如从某条链路的瓶颈中解脱出来之后一个训练作业的 MFU 可能从 45% 提到 60% 以上——同样的硬件只是因为网络不拖后腿了收益就是实打实算力提升。这正是 Acceleron 这类网络架构的价值所在它在绝大多数人看不见的地方把底层的“路况”理顺了。4. 性能边界不是“理论算力”而是扩展效率、MFU 和容错4.1 线性扩展效率集群越大效率掉得越快评价一个 AI 集群不能只看理论峰值算力。更现实的指标是线性扩展效率假设 128 卡的时候跑出某个吞吐扩到 1024 卡时如果扩展效率是 1.0吞吐应该正好变成 8 倍。实际中这是不可能的通信、同步、负载均衡总会吃掉一部分效率。几百卡规模下做到 85% 以上扩展效率不难但上万卡时还能守住 70% 就非常了不起了。很多集群扩到几千卡算法效率掉到 50% 以下收益远低于预期因为 GPU 在训练的大部分时间里都在互相等数据。Zettascale10 超级集群这类架构的核心目标就是把扩展效率曲线往后推让大集群不再是“听起来很大但用起来想哭”。从工程角度看网络拓扑设计对扩展效率的影响是决定性的。卡间通信若能尽量留在叶子交换机内部完成跨交换机的流量占比就低扩展曲线就平缓。反之如果每次同步都要穿越整棵网络树无论买多贵的卡都会被通信拖死。4.2 用 MFU 而非峰值算力评价训练集群MFUModel FLOPs Utilization是我看训练集群时最在意的数字。简单说它是模型实际用到的有效计算量占 GPU 理论峰值算力的比例。为什么 MFU 重要因为它衡量的是 GPU 到底有多少时间在真正算东西而不是在等待。峰值算力再高MFU 只有 30%意味着 70% 的时间机器基本是空转的——这笔钱花得太冤枉了。大模型训练里MFU 做到 40%~60% 是常态能做到 70% 以上已经算顶尖水平。提升 MFU 不仅靠网络。并行策略切分、Flash Attention 这类计算优化、重计算机制、数据预取都会影响最终利用率。但网络往往是最先被忽略的那块短板。一套好的网络架构比如 Acceleron 这类方案能直接砍掉通信等待时间让 MFU 往上跳。这也是为什么我说峰值算力广告不能全信要结合 MFU 和线性扩展效率一起看。4.3 故障恢复和检查点超级集群真正难的点规模越大故障越不是“是否会发生”而是“多久发生一次”。万卡集群里某块 GPU 或某根光模块随机出问题几乎是常态。如果故障之后整个作业要回滚到最后一次 checkpoint重新算几小时甚至一天等于所有 GPU 都白跑了。你们可能没体会过那种痛苦一个训了半个月的模型因为一块卡掉线回退到 10 小时前的状态。所以超级集群的架构设计里容错和快速恢复是重中之重。实践里常见的手段包括更频繁但异步的 checkpoint、内存快照、任务级容错以及网络层对故障链路的快速切换。网络在这件事里的角色也很大。如果 RDMA 链路故障导致整个集群的集体通信中断恢复时间会非常难堪。Acceleron 这类架构要是能把故障屏蔽做成快速重试、路径切换让训练作业几乎无感地避开坏链路整个集群的有效运行时间就能大幅提高。这个价值在大规模集群上比“延迟低零点几微秒”更实在。5. 迁移到新一代 AI 集群前网络调优的实战经验5.1 先想清楚你真的需要超级集群吗写到这里我得泼盆冷水。如果你的模型在单机 8 卡上 3 天就能跑完完全没必要考虑万卡集群。我见过不少团队盲目租大集群结果集群规模上去了总吞吐反而没比小集群高太多钱却烧得飞快。需要超级集群的场景有清晰画像万亿参数级模型训练、长上下文多模态实验、超大数据集上的大量消融实验、需要一天跑完几十个任务的研究团队。在这些场景下超级集群的作业周转时间优势才会体现为真正的研发效率。如果你确定需要也建议优先考虑公共云上的按需集群而不是自建。自建万卡集群是一次重资产决策涉及供电、散热、机房改造、运维团队复杂度远超普通业务系统。云上租用可以把风险控制在项目周期内先尝到规模化收益再决定要不要深入自建。5.2 网络层调优里常见的几个坑如果你正在用 RoCE 网络跑分布式训练有几个坑特别值得注意。第一个是 ECN 水线设置。ECN 标记阈值设太低流量还没达到链路带宽就开始降速吞吐明显受损设太高拥塞已经发生时网卡还在猛发只能靠 PFC 硬扛甚至导致丢包。我建议从交换机 buffer 的 60%~70% 水线开始测试再结合实际作业吞吐微调不要照抄网上的模板参数。第二个是 PFC 的优先级范围。PFC 能防丢包但它是双刃剑如果普通 TCP 流量和 RDMA 流量混在一起PFC 可能引发优先级反转甚至死锁。经验上要给 RDMA 流量单独划分高优先级并严格限制 PFC 作用的流量类型同时用监控观察是否有 PFC 风暴。第三个是很容易忽略的主机侧调优。RoCE 的高吞吐高度依赖大页内存、CPU 中断绑定、以及网卡队列的合理设置。很多团队把注意力放在交换机上结果瓶颈出在宿主机内核配置。这里建议直接对比调优前后的通信基准测试数据别靠感觉判断。5.3 三条可以照抄的落地经验最后分享三条我自己的实操经验基本可以拿回去直接用。先做拓扑感知部署。无论用什么云平台部署任务时要尽量让通信量大的实例落在同一个网络分段或虚拟机组里避免跨区域通信。这个动作不花一分钱但带来的吞吐提升可能比升级网络硬件还明显。再跑通信基准。每次上线大任务之前先跑一轮 AllReduce、AllGather 的带宽和延迟基准确认网络没有异常。等真的开始训练才发现 AllReduce 只有预期的 60% 带宽排查起来会非常痛苦。这个检查流程就像出门前看车况简单但能避免大事故。最后把数据管线和 checkpoint 纳入设计。数据集提前打包成大文件、配置好预取缓存异步 checkpoint 落盘避免训练周期性卡顿。很多团队在网络上花大钱却被数据加载拖累属实可惜。记住一个 AI 训练系统是一个木桶网络、存储、调度、容错每块板都得够长。如果你本来就在用 Oracle 数据库那套生态其实这类低延迟无损网络带来的收益不只是 AI 训练对高可用数据库集群的实时同步同样有意义。新一代集群的价值终究是系统级协同设计撑起来的结果不是靠某一项单点参数。