导语

在AI大模型竞赛中，“万卡集群”几乎成了头部厂商的标配。但一个反直觉的事实是：集群规模扩大带来的训练效率提升，往往远低于线性预期。当集群从千卡迈向万卡、甚至十万卡时，通信开销、故障率、调度复杂度、网络拥塞和存储压力会同时放大，形成一道隐形的“规模墙”。本文从工程视角梳理规模与效率的非线性关系，并讨论企业如何判断自己的合理集群规模。

一、规模墙的本质：并行效率的边际递减

大模型训练依赖多种并行策略的组合：数据并行、张量并行、流水线并行，以及近年来的专家并行。每种并行都会引入额外的通信与同步成本。

• 数据并行需要在每步梯度更新时做全局归约，通信量与集群规模正相关。
• 张量并行把单层计算切分到多卡，层内通信频繁，对互联带宽极其敏感。
• 流水线并行引入气泡（bubble）开销，规模越大、切分越细，气泡占比越难压低。

结果是：当集群规模翻倍，有效算力利用率（MFU）通常不会翻倍，甚至可能因通信占比上升而下降。规模与效率之间不是直线，而是一条逐渐走平的曲线——这正是“规模墙”的第一层含义。

二、通信开销：规模越大，等得越久

集群扩张首先撞上的是通信墙。

• 集合通信的延迟随节点数增长。全局归约、全对全等操作的耗时随参与节点增加而上升，同步等待会直接吃掉计算时间。
• 跨机通信远慢于机内通信。机内 NVLink 类高速互联与跨机网络之间存在数量级差距，规模扩大意味着更多流量被迫走跨机路径。
• 通信与计算难以完全重叠。即便采用通信隐藏技术，规模越大，重叠的难度和残差开销越高。

换句话说，集群越大，GPU 花在“等数据”上的时间比例越难控制。这也是为什么互联拓扑、带宽和协议设计，往往比单纯堆卡更能决定实际训练效率。

三、故障率：规模放大的是概率

大规模集群的第二个敌人是可靠性。

• 单点故障概率随规模累积。假设单卡或单节点的平均无故障时间固定，集群规模越大，单位时间内发生故障的期望次数就越高。万卡集群每天出现若干次硬件或软件异常，是行业普遍面临的现实。
• 故障恢复成本高昂。一次节点掉线可能触发检查点回滚、任务重调度和通信重建，恢复时间随集群规模和并行策略复杂度上升。
• 长周期训练的稳定性挑战。大模型训练动辄数周甚至数月，期间故障几乎不可避免，容错机制（检查点、弹性训练）成为必需而非可选。

规模墙在这里体现为：你买到了更多算力，但也买到了更多故障和更多恢复开销。

四、调度复杂度：资源越多，越难喂饱

调度是容易被低估的一环。

• 拓扑感知调度难度上升。为了减少跨机通信，调度器需要把通信密集的任务尽量放在同一机架或同一互联域内，规模越大，这种约束越难满足。
• 碎片化与资源利用率。异构任务、不同并行度、抢占与优先级并存时，大集群容易出现“总量充足但局部碎片”的情况，导致部分资源闲置。
• 作业排队与公平性。多团队共享大集群时，调度策略要在吞吐、公平和优先级之间权衡，复杂度随规模非线性增长。

调度做不好，集群规模再大也可能“看着满、跑不满”。

五、网络拥塞：流量模式的隐性成本

大规模训练产生的流量具有明显的突发性和同步性：大量节点在同一时刻交换梯度或激活值，容易在特定链路上形成瞬时拥塞。

• 拥塞导致长尾延迟。集合通信是“木桶效应”，最慢的那条流决定整体完成时间，个别链路的拥塞会拖慢整个同步步。
• 负载不均放大问题。并行切分不均、热点参数集中，都会让部分链路成为瓶颈。
• 拥塞控制与路由策略变得关键。规模越大，越依赖精细的流量调度、拥塞控制和拓扑设计来削峰。

网络不是“带宽够大就行”，规模扩大后，流量模式的治理本身就是一门工程。

六、存储压力：检查点与数据供给的双重考验

存储常被放在最后讨论，但在大集群中同样是瓶颈。

• 检查点写入压力。为应对高频故障，训练需要定期保存检查点。集群越大、模型越大，检查点体积和写入频率带来的存储带宽压力越显著，写入时的停顿还会影响训练连续性。
• 数据读取与预处理。大规模训练对训练数据的吞吐要求很高，数据管道若不能持续供给，GPU 就会空转。
• 元数据与并发访问。海量小文件、多任务并发读写，对存储系统的元数据服务能力提出更高要求。

存储跟不上，算力再强也会被“饿着”。

七、非线性关系：为什么“堆卡”不等于“堆效率”

把上述因素叠加，可以得到一个基本判断：集群的有效训练吞吐随规模增长呈次线性甚至阶段性饱和。

• 通信、故障、调度、拥塞、存储五类开销，都会随规模以不同方式放大。
• 当规模超过某个临界点，新增算力带来的边际收益可能被新增开销抵消。
• 这个临界点因模型结构、并行策略、网络拓扑、运维能力而异，不存在放之四海皆准的“最优卡数”。

因此，“规模墙”不是某一项技术的失败，而是系统工程中多约束共同作用的结果。

八、企业如何确定合理集群规模

依据现有素材判断，企业确定集群规模时，可以从以下几个维度做务实评估，而非盲目对标最大规模：

1. 以目标模型和训练周期反推算力需求。先明确要训多大的模型、在多长时间内完成，再估算所需有效算力，而不是先买卡再找用途。
2. 评估并行策略的可扩展性。在小规模上验证通信占比和 MFU 随规模的变化趋势，找到效率开始明显下滑的区间。
3. 把可靠性成本计入总账。容错、检查点、运维人力和故障恢复时间，都是规模带来的隐性成本。
4. 匹配网络与存储能力。互联带宽、拓扑设计和存储吞吐必须与算力同步规划，避免“算力等网络、算力等存储”。
5. 优先提升单集群效率而非单纯扩规模。通过优化并行策略、通信重叠、调度和容错，往往能在现有规模上获得可观收益。
6. 采用分阶段扩展。从小规模验证到逐步扩容，边扩边测效率曲线，比一次性上大规模更可控。

趋势判断

• 效率优化将比规模扩张更受重视。当规模墙逐渐显现，MFU、有效训练时间和单位算力成本会成为更核心的指标。
• 软硬协同成为关键。互联拓扑、通信库、调度器与容错机制的协同设计，决定集群能否“跑满”。
• 弹性与容错走向标配。面对高频故障，弹性训练和快速恢复能力将从加分项变为基础设施能力。
• 规模决策更趋理性。企业会更倾向于根据业务需求确定“够用且高效”的规模，而非单纯追逐卡数纪录。

结论

AI集群的“规模墙”并非危言耸听，而是通信、可靠性、调度、网络和存储等多重工程约束在规模放大后的集中体现。规模与效率之间是典型的非线性关系：越过某个临界点，堆卡的边际收益会明显下降。对企业而言，真正的竞争力不在于拥有多少张卡，而在于能否让这些卡高效、稳定、持续地跑起来。理解规模墙、测量自己的效率曲线、找到合理规模，比盲目扩张更重要。

生成标记：本文由 ITPUB 文章生成平台基于已选素材整理生成。