豆包背后的“超算大脑”：字节ByteRobust系统跑20多万张GPU，性能刷新SOTA

字节跳动自研了一套名为ByteRobust的系统，刚刚登上了计算机系统顶级会议SOSP 2025。

该系统部署在超过20万张GPU的生成平台上，通过在9600张GPU上进行为期三个月的大模型训练，做到了97%的有效训练时间（ETTR）。训练稳健性方面刷新SOTA。

训练规模越大，故障就越防不胜防

大语言模型训练的核心指标，是训练规模，已经攀升到数万块GPU，并且还在继续扩大。

规模膨胀，提升了更大模型的训练速度，代价也随之而来。

资源规模越大，故障就越频繁。

CUDA错误、NaN值、任务挂起，这些问题像幽灵一样，随时都可能出现，对训练的稳定性构成巨大挑战。

任何一个大规模的LLM训练基础设施，都必须面对三个核心诉求：最少的训练中断、高效的故障诊断、有效的故障容错。

只有这样，才能实现高效的连续训练。

Meta报告称，在16000个GPU上训练大型模型的过程中，硬件故障大约每2.78小时发生一次。

字节跳动开发的ByteRobust系统，就是一套专为LLM稳健、稳定训练定制的大规模GPU基础设施管理系统。

通过发挥LLM训练的并行性和自身特性，ByteRobust实现了高容量的故障容错、快速的故障界定和定位，并采用了一套有效的数据驱动方法，全面确保LLM任务高效地连续跑下去。

在一个万卡级别的GPU集群中，存在两种互联域：Scale-up和Scale-out。

它们分别负责不同级别的连接需求。

字节跳动基于以太网技术，为AI集群提供了低延迟、高带宽的下一代Scale-up网络方案，满足了AI应用对GPU之间高速互联传输的苛刻要求。

集群规模上去了，优化的挑战也接踵而至。

一个未经优化的2048张GPU集群，光是初始化时间就要1047秒。

优化之后，这个时间可以降到5秒以下。

对于万卡GPU集群，初始化时间也能降至30秒以内。

这些优化，为大规模LLM训练提供了高效的运行环境。

但硬件和基础软件的优化，只是第一步。

训练过程中层出不穷的故障，才是真正令人头疼的难题。

ByteRobust用体系化工程应对系统性难题

ByteRobust系统的设计目标，就是解决大规模LLM训练中的各种挑战，尽可能提高有效训练时间比率（Effective Training Time Ratio, ETTR）。

它要能自动诊断和处理各种训练事件，同时把非生产时间压缩到最低。

整个系统由两个核心组件构成：控制平面（Control Plane）和数据平面（Data Plane）。

控制平面独立于训练作业之外运行，它像一个总指挥，负责协调稳健的事件处理策略，检测异常、定位故障，并触发相应的恢复操作。

控制平面里有两个关键模块。

一个是鲁棒控制器（Robust Controller）。

它协调着整个自动化故障缓解框架，利用实时监控和停机诊断来处理绝大多数事件。为了实现可控的快速恢复，当没有机器被剔除时，它会使用一种原地热更新机制来重启训练。当决定需要剔除某些机器时，它会请求预先验证过的温备用机器来恢复作业。

另一个是运行时分析器（Runtime Analyzer）。

它专门解决任务挂起和性能下降这类棘手的问题。它通过聚合来自所有训练Pod（容器组）的堆栈跟踪信息，来隔离并（过度）驱逐可疑的机器。

数据平面则内嵌在每一个训练Pod内部。

它集成了监控、诊断、检查点管理和堆栈跟踪捕获等模块，提供实时的可观测性、中断时的即时诊断、快速的检查点回滚和按需的聚合分析能力。

数据平面的核心是一个名为Robust Agent的守护进程。

它在每个训练Pod里运行，处理来自鲁棒控制器的控制信号，并管理着四个子模块。

首先是监控器（Monitor）。

它负责收集多方面的数据来检测异常值，支持实时检查，并在发现异常时触发聚合分析。

其次是诊断器（Diagnoser）。

当作业暂停后，它会运行一些特定领域的基准测试和测试套件，对复杂的故障进行深入诊断。

然后是按需跟踪器（On-Demand Tracer）。

当需要进行聚合分析时，它会捕获训练进程的堆栈跟踪信息，并上传给运行时分析器。

最后是检查点管理器（CKPT Manager）。

它执行异步的检查点操作，将备份跨并行组分散到CPU（中央处理器）内存和本地磁盘，以此来最小化恢复成本。

故障来了，它能自动发现并快速修复

自动化容错，是把LLM训练规模做大的关键。

通过用最少的人工干预来检测、定位和解决事件，可以显著减少非生产时间。

GPU的计算周期是训练集群中最昂贵的资源。

因此，快速、粗粒度的故障隔离，通常比昂贵、细粒度的根本原因定位，在诊断覆盖率和效率之间提供了更好的权衡。

ByteRobust提出了一套自动化故障容错框架。

它结合了对常见错误的实时检查、对复杂故障的停机时间诊断、从瞬时故障中恢复的原地重试、从有缺陷的用户代码回滚，以及用于处理边缘情况（如SDC，静默数据损坏）的重放测试。

监控器使用检查线程，在预定义的秒级间隔内，执行一系列轻量级的系统健康状态查询。

这些检查对GPU不引入额外工作负载，对正在进行的训练作业是透明的。

检查主要覆盖三个方面。

网络侧项目，比如网卡（NIC）故障或抖动、数据包丢失率、交换机故障等。

GPU侧项目，包括DCGM（数据中心GPU管理器）服务状态、PCIe（高速串行计算机扩展总线标准）带宽、内存行重映射和GPU温度等。

主机侧项目，比如操作系统内核事件（dmesg日志中的Xid错误）。

监控器还会收集基于三类数据的各种指标。

包括与工作负载相关的训练指标，如损失值、梯度范数、模型浮点计算利用率（Model FLOPs Utilization, MFU）等。

也包括标准输出和标准错误日志（stdout/stderr）以及进程退出代码，这些都可以作为诊断的线索。

还包括各种事件，涵盖CUDA、RDMA（远程直接数据存取）、主机和存储事件。

在运行时，控制器会分析收集到的指标。

如果检测到用户空间错误，比如TypeError、IndexError，并且可以从日志和退出代码追溯到特定的代码模块，就会触发代码回滚。

如果训练崩溃，或出现异常指标（比如NaN损失），但没有明确的罪魁祸首，训练就会被暂停，并运行停机时间检查。

当发现性能异常时，例如10分钟内RDMA流量为零，或者TensorCore（张量核心）利用率过低，就会触发聚合分析，进行机器隔离。

主动的实时检查可以把大多数显式故障和有问题的机器关联起来。

但总有一些错误，仅靠实时收集的信息难以解决。

ByteRobust考虑到了潜在的人为错误，并进行分层的停机时间检查来处理这些情况。

诊断器会分析日志和退出代码进行故障诊断，运行相应的测试来定位根本原因。

举个例子，当出现NCCL（英伟达集体通信库）内部错误时，系统会进行NCCL测试。

首先运行NVIDIA扩展实用程序诊断（EUD），确认GPU中是否存在明显错误。

如果没有，就运行机内全到全测试，验证GPU之间的连接带宽是否符合预期。

如果机内测试通过，就进行机间通信测试。每台机器会与相邻的机器运行全聚集测试，以验证数据传输的连接性和完整性。

如果所有测试都通过了，诊断器会假设这次故障是由瞬 F 时性问题引起的，比如临时的链路抖动、交换机故障、连接重置等。

然后，它会直接重新启动训练作业。

如果重启训练未能解决问题，或者训练在机器被驱逐后再次崩溃，诊断器会假设是用户代码的最近更新存在高风险。

这时，它会使用热更新机制回滚用户代码，删除集成的那些新功能，并重新启动训练。

如果训练还是失败，ByteRobust会假设存在某种未知故障（比如SDC）。

它会在一个受控的环境中，采用分组测试的方法进行定位。

对于大规模的3D并行训练，机器压力测试和基准测试会破坏当前LLM作业原始的计算-通信模式和数据依赖性，从而损害问题的可复现性。

为了保持诊断的保真度，ByteRobust引入了一种双相、维度感知的重放机制。

它保持原始的TP（张量并行）和PP（流水线并行）大小不变，只改变DP（数据并行）的大小。

定位过程是这样的：系统将机器分为水平组和垂直组，减少模型层数，并在每个组上以减小的DP大小重放作业。

出现故障的水平组和垂直组的交集，就能精确定位出故障机器，然后将其驱逐。

基于在19个大规模LLM训练作业（每个都超过9600块GPU）中的经验观察，通过实时检查直接驱逐机器，解决了32.52%的故障。

重试恢复了22.70%的故障。

回滚处理了另外9.20%。

只有1.23%的故障，需要动用双相重放这个机制。

除了NaN值，隐性故障还表现为任务挂起和MFU下降。

当任务挂起时，没有任何可追踪的信息被记录下来用于停机时间诊断。

至于MFU下降，虽然任务变慢了，但所有机器是同时变慢的，IO（输入输出）和RDMA的吞吐量也同时下降。

所有这些因素，使得通过分析现有的外部信息来识别潜在的故障机器，变得极其困难。

为了克服这个挑战，ByteRobust在检测到这些“静默故障”时，会挂钩并检查所有内部训练进程的堆栈跟踪，以此来定位故障机器。

当控制器接收到聚合触发消息时，它会通知按需跟踪器捕获进程的堆栈跟踪，然后将其发送给运行时分析器，在后台进行聚合分析。

为了定位异常位置，聚合分析会比较不同机器中GPU等级的调用堆栈。

与事件、训练指标和日志相比，进程的堆decks跟踪为解决复杂事件提供了更丰富的信息源。

根本原因可能存在于主训练进程为数据获取或检查点等任务产生的子进程中。

只分析主训练进程的堆栈是不够的。

ByteRobust纳入了这一观察，并执行三步聚合来进行全面分析。

这个分析基于一个假设：在单个隐性故障下，大多数健康的机器会表现出相同的堆栈跟踪。

上图展示了一个静默的反向通信挂起。

ByteRobust通过一个三步过程，用“过度驱逐”的方式来隔离机器，从而解决这个问题，它避免了去精确定位根本原因。

这个案例展示了ByteRobust在处理隐性故障方面的有效性，即使在没有明确错误信息的情况下，也能准确定位问题机器。

恢复训练，不仅要快还要足够稳定

在故障检测和定位之后，ByteRobust要在一个一致的环境中快速重新启动训练，最小化停机时间，并避免引入新的故障。

在LLM训练期间，为了调整代码而手动重启训练是常态。

为了最小化开销并避免风险，ByteRobust引入了懒惰热更新机制。

它可以在不破坏现有Pod环境的情况下，进行原地代码修改。

每当发生机器驱逐时，ByteRobust会利用温备用实例，快速替换掉缺失的机器以恢复训练。

尽管在备用机器上引入了一些GPU的闲置时间，但减少的重启成本，转化为了集群中健康机器利用率的提高，尤其是在大规模训练期间高频中断的情况下。

系统维护着一个备用机器池。

备用机器的数量，是根据一个观察来决定的：大规模训练中的故障通常是独立发生的，涉及多个节点的同时故障极为罕见。

系统使用历史数据估计单台机器的日故障率，并通过二项分布对机器的同时故障进行建模。

温备用实例的数量，被设置为该分布的第99百分位数（P99），这可以在大多数场景中有效满足需求。

备用机器池是动态补充的。

每个新的备用机器都会执行Pod环境初始化，包括机器自检以确保其健康状态、镜像安装和库下载，然后进入低功耗的睡眠模式。

当发生机器驱逐时，如果有足够的备用机器，它们会被直接唤醒并集成到训练中。

如果没有，就进行快速补充，当所有需要的机器完成Pod环境初始化后，再重新启动训练。

ByteRobust倡导通过在本地和对等机器上保存和备份检查点，来进行内存检查点操作。

它采用分层检查点方案，利用主机CPU内存和SSD（固态硬盘）存储层，并结合一种能预料到机器过度驱逐的备份策略，来保证可用性。

通过消除对低带宽前端网络上远程存储服务的依赖，ByteRobust防止了由存储服务故障导致的潜在训练挂起或崩溃。

通过精心的操作调度，ByteRobust实现了接近零开销的内存检查点。

如上图所示，为了备份分片的模型和优化器状态，ByteRobust利用了每个训练步骤中的空闲通信周期，即在向前和向后计算期间。

它使用P2P通信，让每个等级与选定备份机器中的对等等级交换这些分片。

这些备份分片随后被保存到CPU内存中。

检查点的I/O操作以异步方式，与向前和向后计算一起执行。

备份策略考虑了并行组之间的故障隔离。

如上图所示，在一个3D并行配置（TP=2, PP=4, DP=2）中，每台机器的备份都位于一个不同的并行组中。

当过度驱逐发生时，即使整个并行组被驱逐，每台机器的备份仍然存在于其他组中，确保了检查点的可用性。

实际效果证明了它的价值

ByteRobust已经在生产环境中部署超过一年，用于支持字节跳动内部的LLM训练。

这些高性能生产集群的总容量超过了20万块GPU。

在三个月的时间里，ByteRobust通过其自动化故障容错训练框架，识别了38236个显式故障和5948个隐性故障。

下表总结了在生产平台上三个月内，所有LLM训练作业中捕获到的训练事件。

从表中可以看到，显式故障占总事件的69.3%，其中CUDA错误是最常见的故障类型，占了总事件的36.1%。

隐性故障占总事件的11.0%，其中任务挂起是最常见的隐性故障。

手动重启占了17.3%，主要用于算法和工程上的改进。

在16384块GPU上进行的微基准实验表明，温备用和热更新机制，分别实现了高达10.87倍和11.04倍的恢复速度提升。

ByteRobust中的高效检查点机制，实现了每一步都进行检查点操作，其开销小于0.9%，这极大地加速了故障转移。

部署实验显示，ByteRobust在一个为期三个月、使用9600块GPU的训练作业中，实现了高达97%的ETTR。

这个结果表明，ByteRobust在大规模LLM训练中，显著提高了训练的效率和稳定性。

ByteRobust的核心设计理念，可以总结为三点：优先快速隔离而非精确定位、在设计中考量人为错误、在快速恢复期间控制变异性。

这些理念，让ByteRobust能够在大规模LLM训练中，实现高效的故障诊断和处理，最大限度地减少非生产时间。

随着LLM的规模不断扩大，训练的稳定性将成为一个越来越重要的挑战。

ByteRobust为解决这一挑战提供了一个有效的解决方案，为大规模LLM训练的稳定性和效率，树立了一个新的标准。

参考资料：

https://arxiv.org/abs/2509.16293

https://dl.acm.org/doi/10.1145/3731569.3764838