MegaScale 的 12,288 块 GPU 一课：最慢的机器定下节奏

字节跳动研究员、MegaScale 合著者林海滨；照片为 2024 年 Systems @Scale 项目采用的官方肖像。画面标明了参与这项工作的工程师之一，12,288 块 GPU 的集群没有出现在照片中。[5]

想到一次 12,288 块 GPU 的训练，人们很容易在脑中铺开一整面相同的加速器，所有设备同时运转。MegaScale 给出的经验少了几分银幕感：投入真实运行后，这些机器很快显出差异。同步作业要向前推进，相互依赖的 rank（通信进程编号）必须全部就绪。一块变慢的 GPU、一条受损链路、一个停滞的数据 worker，或一项埋在深处的通信错误，都能为整个集群定下节奏。到了这一规模，最弱的参与者已经从偶发的边缘情形进入性能模型之中。[2]

这段 16 分钟的 USENIX 录像介绍了字节跳动与北京大学团队在 NSDI ’24 发表的工作。论文报告的核心成绩是：在 12,288 块 NVIDIA Ampere GPU 上训练一个 175B 参数模型，模型 FLOPS 利用率达到 55.2%。这个数字值得关注，沿着数字背后的顺序看，技术价值更加清楚：排布并行任务、隐藏通信开销、逐个测量 rank、查找异常，并在保住训练任务其余进度的同时恢复运行。开放获取的会议论文与录像并列，供读者查阅其中的技术证据。[1][2]

观看这场演讲时，主线落在持续吞吐量上，超大型计算机本身退到背景。下方的注释节点沿着演讲顺序，从 benchmark 走向软件栈，再进入运行稳定性。所有测量都对应作者指定的模型、网络、软件和比较基准，记录的是一套经过工程设计的系统；其他系统若要从 GPU 数量推到训练速度，仍需各自的测量证据。[2]

0:00–2:25 — 利用率数字需要一个分母

开场有意把结果收束成三个数字：12,288 块 GPU、一个 175B 模型，以及 55.2% 的模型 FLOPS 利用率，也就是 MFU。MFU 的分子是由模型定义的有效浮点运算量，分母是加速器的理论峰值能力。它包含的性能信息多于单纯的 GPU 数量；模型质量和单个晶体管的有效工作情况都在这一指标的测量范围之外。它追问的是，随时间累计，标称算力上限有多大比例真正进入了模型计算。[2]

在论文报告的配置中，一次迭代耗时 6.34 秒，每秒处理约 198 万个 token。论文估算，按这一速度处理 3000 亿个 token 约需 1.75 天。作者将 55.2% MFU 与其测试的特定 Megatron-LM baseline 所达到的 41.2% 相比，由此得到经常被引用的 1.34× 提升。理解这个比较需要保留完整条件：固定的 175B 稠密模型配置、2,048 的序列长度、6,144 的全局 batch、包含 64,000 个 token 的词表，以及 Megatron-LM 的一个历史代码版本。结论范围止于这组配置和当时的代码版本，没有覆盖此后的每个版本与各种模型架构。[2]

第一个观看问题也由此变得清楚：缺失的时间去了哪里，系统又能追回其中哪些损失？MegaScale 把答案分布在算法、kernel、数据交付、集合通信、网络与运行维护之间。利用率数字是整条链共同作用的结果，移到另一座集群时，需要重新检验整条执行链。

2:25–7:30 — 更多并行也带来更多等待

演讲中段把一个模型拆成数套彼此牵连的调度。数据并行在不同 batch 上复制模型计算；流水线并行把模型层切分成多个 stage；张量并行拆开一层内部的算术操作；序列并行进一步改写激活值和通信在执行过程中的位置。这些技术让一个模型得以跨越数千台设备，每一次拆分也会增加一项依赖：张量必须到达，流水线 stage 必须接收任务，或归约必须完成，下一项有效操作才能继续。[1][2]

MegaScale 把解法铺在整套软件栈上，核心是让通信与计算彼此重叠，单项新集合通信只覆盖其中一段。系统重排 Transformer block 的计算，使通信可以和其他 kernel 同时运行；它把 3D 并行与优化后的算子结合起来，其中包括 FlashAttention-2 和 fused kernels；异步数据处理也减少了输入 pipeline 让加速器空转的时间。论文还写到，在超过 10,000 块 GPU 上初始化 NCCL 通信组，耗时低于 30 秒。这些工作的共同思路，是尽早暴露等待窗口，让另一项有效任务填入其中。[2]

这也是演讲中算法—系统协同设计的具体含义。数学上等价的模型调度，会生成差异很大的通信图。快速 kernel 有时只会更早暴露下一个集合通信已经迟到。扩大张量并行组可以节省内存，也会让更多 rank 等待同一次交换。MegaScale 的成绩来自对这些部分的统筹取舍，随后再观察组合后的执行；单个组件各自的 benchmark 只作为局部参考。

7:30–10:45 — 网络是训练算法的一部分

到了集群规模，网络要由拓扑、链路和流量共同描述，单一带宽数字覆盖不了全貌。论文描述了一套三层 Clos-like 网络，使用 Broadcom Tomahawk 4 交换机和 400 Gbps 链路，每一层级的汇入与汇出总容量相等。团队针对模型集合通信反复生成的规则化流量，调整了路由与传输行为。彼此独立的服务在某种拓扑上可以运行良好，同一拓扑面对数千个 rank 同时启动全归约时，未必仍有同样表现。[2]

这里的重点从峰值容量转向协调。通信重叠要发挥作用，消息必须落在计算留下的时间窗口内。名义上相同的路径，在拥塞或硬件退化时会呈现不同表现。因此，系统需要 rank 级计时和 RDMA 遥测；相比只显示每条链路仍处于在线状态的 dashboard，这两类信息更接近同步作业的真实情况。一条能够传输流量、却在负载下持续波动的链路，给同步作业带来的代价会高于一次干净故障。它既反复拉长关键路径，又迟迟不发出明确的失效信号。[2]

标题里的成绩也要放回具体物质条件中理解。它属于一代特定加速器和一套专门搭建的网络。硬件约束始终在场；当大规模硬件预算就位，软件决定了其中多少能够穿过同步损耗，真正转化为有效计算。

10:45–13:25 — 最慢的 0.5% 成为 benchmark

演讲中最具迁移价值的观察来自慢节点。MegaScale 使用 CUDA Event 计时和热力图比较不同 worker 的执行。作者报告，约 0.5% 的机器会明显落后，最慢的参与者则决定同步工作的节奏。排除或修复这些离群机器后，多次运行所得的峰值 MFU 明显趋于一致。[2]

这个很小的比例改写了性能工程的重心。在一块 GPU 上，偶发的慢 kernel 可以被视为噪声；放到 12,288 块 GPU 上，0.5% 约等于 61 台机器，足以让几乎每个协调步骤都有机会碰上迟到的 rank。设备平均性能可以保持健康，作业却仍然反复等待。真正相关的统计量包含均值、rank 耗时分布的尾部，以及当时占据尾部的 worker 身份。

MegaScale 的可观测工具继续把这一身份映回系统组成。心跳信号覆盖 executor、进程、硬件、日志和 RDMA 行为。3D 可视化工具重建数据并行、流水线并行和张量并行的依赖，让运维人员能够分辨最先失效的参与者，以及随后连锁出现的 NCCL 超时。监控画面的美观退到次要位置，核心工作是压缩因果链：从数千条后续警报中，找出真正拖慢或打断该步骤的组件。[2]

13:25–16:26 — 重启是常态；成本在丢失的进度

结尾对生产运行的叙述，为“稳定性”给出了具体尺度。在另一项独立的专有模型训练中，超过 10,000 块 GPU 持续运行数周，作业重启超过 100 次。作者报告，超过 90% 的故障由系统自动识别并处理，平均诊断时间低于 10 分钟；作业从最近的 checkpoint 恢复，并在 15 分钟内追平崩溃前的训练位置。有效训练时间也超过 90%。[2]

这些数字与 175B benchmark 属于两组评估，需要分开阅读。生产模型拥有数千亿参数，训练数据达到数万亿 token，具体架构和集群细节没有公开。它提供运行层面的证据；175B 测试则给出可复核的扩展测量轮廓。两组评估各自承担不同的证据功能，分开之后更容易理解。

运行层面的经验仍然鲜明。容错是一条完整动作链：及时发现故障、诊断最初原因、保留近期 checkpoint、替换受损资源，并让作业重新回到原有节奏。若修复用了 5 分钟，随后又耗费数小时重算，事故成本仍要计入后半段。MegaScale 以追平进度所需时间衡量恢复区间，重启耗时只记录其中一段。

画面之外还留着什么

这场演讲呈现的仍是字节跳动内部训练栈，距离其他实验室可以直接复现的完整套件尚有很长距离。硬件清单、调度器策略、网络配置、模型形态和运行实践彼此耦合，生产环境中的大量细节仍属专有信息。字节跳动公开的 veScale 仓库说明了分布式训练工作的延续，其 README 同时写明，当前发布内容只占内部库的一小部分。2024 年接受评估的完整 MegaScale 系统，范围远比这部分开源内容更广。[4]

其他限制也需要保留。算法改动的收敛检查使用了 13B 级 microbenchmarks，完整的 175B 训练曲线仍留在公开材料之外。1.34× 的比较固定在一个 baseline 版本上。大规模实验集中于稠密 Transformer 配置和 NVIDIA Ampere 硬件。一旦换成 mixture-of-experts 模型、不同的 interconnect、异构加速器或更晚的软件栈，瓶颈位置与最佳调度需要重新测量。[2]

这些材料也无法把那一匿名 benchmark 模型直接指认为豆包。字节跳动 Seed 在 2024 年 12 月的一份中文一手记录中写道，北京大学—字节跳动有关超大集群管理的更广泛工作已经部署到豆包生产环境，并把 MegaScale 的 10,000-plus-GPU 设计描述为该领域较早的公开工作。这份记录建立了机构合作与生产应用的延续关系；论文中的 175B 测试配置是否对应商业模型，记录中没有披露。[3]

AI-China 信号落在一套运行纪律上

模型竞争发生在一次次头条训练之间，MegaScale 对 AI-China 版图的意义也由此显现。五位数加速器集群的合影记录了物质前提，持久能力则体现在通信、硬件和人员持续带来波动时，依然维持有效计算。这种能力落实在一批不起眼的工具中：逐 rank 热力图、依赖关系重建、RDMA 信号、checkpoint 节奏和自动资源替换。

接下来值得追踪的证据同样来自实际运行。内部软件栈中会有多少内容进入外部可检视范围？后续系统会不会在峰值 MFU 之外同时报告有效训练时间？面对异构硬件、长上下文模型或稀疏模型时，恢复指标能否继续成立？另一组织能否拿出尾延迟诊断的复现结果，超越对 55.2% 这一数字的引用？

视频中的 12,288 块 GPU 让 MegaScale 易于被记住。更值得留下的一课落在更小的粒度：每一个同步步骤，都有一台机器决定节奏。当团队能够找到那台机器、理解它迟到的原因，并赶在 checkpoint 变旧之前让整个作业恢复有效计算，大规模训练便会得到改善。

cronfeed.work