从nnScaler到大规模训练：谈一谈对多元化训练系统边界的一些理解

这篇文章来自我最近准备的一个技术分享。具体的主题是“分布式训练系统：从研究到生产”。整理成博客时，我不想把它写成整个训练入门，也不想借这个机会整理一下自己这几年对训练系统边界的理解。

知乎上讲 DP、TP、PP、FSDP、ZeRO、Megatron、DeepSpeed 的文章已经很多了。我这篇更想讨论一些偏判断的问题：一个环球训练系统从研究原型走向真实训练时，哪些问题会变得更重要？为什么一个看起来很自然的通用系统，到了真实的大模型训练生态里会遇到边界？

我的背景大概是：早期参与过OneFlow，后来主要参与了nnScaler / AutoDist相关工作，也支持过一些公开模型项目的多次训练。最近一段时间，我又接触到了更大规模、后期训练和强化学习工作流程相关的系统问题。下面很多判断都来自这些经历本身，也带有大量的个人视角。

1. 全局训练并不是把程序“跑快”这么简单

在单卡或单节点训练优化里，我们通常面对一个相对固定的训练程序：模型结构、参数、激活、梯度、优化器状态、检查点、损失计算都是比较在局部的局部里。优化时，更多的是在固定这个程序上做kernel、memory、fusion、layout、batching等局部改造。

它并不是简单地把同一个程序放在更多的 GPU 上运行，而是在改变程序状态的存在方式：

• 参数可以复制，也可以切分；

• 梯度可以全归约，也可以归约分散；

• 激活可以重算、检查点、按序列/上下文维度切；

• 优化器状态可以复制、分片、卸载；

• RNG、数据顺序、损失归一化、全局范数、-checkpoint/resume 都需要保持训练语义。

所以所谓的并行化计划，并不只是“用了DP/TP/PP/EP/CP哪几个名字”。一个真正执行的计划至少要回答：

• 哪些张量维度被切分？

• 每个哪些时刻排名拥有哪些状态？

• 通信在哪里发生？

• 哪些张量被物化、重新计算或释放？

• checkpoint、resume、RNG、hook、globalnorm 是否还能保持同样语义？

我现在更愿意把并行化计划理解成一个可执行的合约：它既是性能方案，也是语义承诺。这个承诺一旦没有说清楚，系统后面就会遇到非常多的正确性和信任的问题。

2.为什么自动家具在2022年看起来很自然

我最初接触训练系统时，一个重要的感受是：手动指定每个操作员怎么切分，虽然表达能力极大，但对用户来说太痛苦了，而且也不一定能得到好的方案。

在OneFlow里积累的一些经验，我觉得搜索自动填充策略是一个很自然的方向。2022年左右，大模型还没有像ChatGPT那样成为主流叙述，但模型规模已经开始明显变大，V100/A100这样GPU的显存也很有限，算法连接也开始有规模的需求。换句话说，围绕训练的需求已经出现了，当时很多人还没有把看成今天这么核心的问题。

AutoDist最初的想法比较直接：给定一个模型和硬件环境，配置文件计算和通信开销，然后寻找一个比较好的任务执行方案。优化目标主要有两个：

• 搜得快；

• 搜得好。

这件事和Alpa一类系统在方向上有相似之处：把一点点策略看成一个优化问题，然后用分析、成本模型和启发式搜索来降低搜索成本。在研究环境下，这个方向很干净，也很可怕。

后来AutoDist被集成nnScaler训练。nnScaler提供了一个编译器堆栈：前端捕获PyTorch程序，中间做图转换和计划生成，中间生成可以执行的PyTorch代码。

我们当时比较相信PyTorch生态，觉得如果一个系统能够紧密集成PyTorch，而不是要求用户迁移到一个全新的框架里，它的实际价值会更大。

这个判断我现在仍然真正觉得是对的。但后来困难的地方，远远不止“怎么找到一个快速的计划”。

3.从研究系统到真实训练，最难获得信任

做系统的人很容易首先关注速度：步长降低了多少，内存省了多少，不能扩展到更多卡。但从模型和算法用户的角度看，第一优先级往往不是快，而是：你这个系统不是对的？

这听起来很简单，但在很多事情中都非常困难。

从理论上讲，用户当然希望系统能够实现按位奇偶校验：同样输入、同样环境、同样随机种子，换成多次执行后结果完全一样。但真实情况会复杂很多：

• 浮点数累加顺序会变；

• 有些内核本身不是确定性的；

• 确定性模式可能带来明显的性能损失；

• NCCL集体的渠道和现实细节可能影响结果；

• profiler看到的性能可能受软件版本、形状、硬件状态影响；

• 神经网络本身会忽略一些错误，小错误可能很多步骤之后才在损失曲线或评估上体现出来。

早期做nnScaler时，我们在实践中更多依赖经验的奇偶测试：张量/值比较、短程损失曲线、和参考运行对齐、再定位用户做更大规模的验证。这种做法并不完美，但很接近很多训练框架在实践中的测试方式。

后来我逐渐意识到，正确性不是一个附属清单，而是一个单独值得研究的问题。nnScaler生成了全民执行计划和执行程序，但用户真正需要“我为什么应该相信这个程序”。这个思考自然也引向了后面类似TrainVerify的工作：把全民训练正确性从工程经验推进到形态化的验证问题。

这也是我从 nnScaler 里学到的最后一课：训练系统不是能跑、能快就够了，它必须让用户重要相信它改写后的执行仍然保持了训练语义。

4.灵活不是免费的

相比 FSDP、Megatron、DeepSpeed 这类系统，nnScaler/AutoDist 的一个优点是具有更大的搜索空间和更强的通用性。理论上，搜索空间更大，可能会找到适合某个模型和硬件环境的更好的方案。

但后来我越来越觉得，灵活不是免费的。

更大的搜索空间意味着：

• 需要生成、测试、解释更多计划；

• 图转换和运行时状态更多；

• codegen出错的方式更多；

• 奇偶校验和验证的案例更多；

• 用户在遇到问题时更难以判断问题在哪里。

在研究论文里，通用性往往是一个优点。但到了真实的训练中，通用性的成本会非常具体地落到开发、调试、验证、用户支持上。一个系统如果都想支持什么，很可能最后每一层都只能支持到“不够让人放心”的程度。

这并不是说通用系统没有价值，而是要问清楚：在哪些场景里，通用性真的值得为其带来巨大的成本？

我现在倾向于认为，nnScaler 这类系统最适合的场景是：

• 模型结构仍在快速变化；

• 用户不想手写复杂的策略；

• 系统能够从模型语义中推导或搜索出正确的结果；

• 工作负载相对静态，形状和控制流不会破坏编译器假设。

一旦模型架构逐步收敛，或者主流训练都围绕少量硬件/软件栈展开，专用系统的消耗就会变高。比如LLaMA-like模型、MoE模型、特定长上下文方案，如果已有威震天式堆栈、FSDP、verl或专门训练器能比较稳定地支持，用户不愿意为了通用编译器堆栈额外学习和调试成本。

5. 真实大规模训练取代系统边界继续推宽

如果说 nnScaler 让我看到了编译器/训练器层面的复杂性，那么最近接触更大规模的训练后，我的另一个感受是：环球训练系统的边界会被真实的工作量不断推宽。

在更大规模下，训练系统不再只是一个框架内部问题。它会涉及到：

• 存储和数据加载器 吞吐；

• 检查点保存/加载和恢复成本；

• 集群调度器；

• 机器验证、维修和重新放回资源池的管道；

• 网络拓扑、集体表现和掉队者；

• 容错性；

• 日志记录、指标、分析和诊断；

• 推理引擎；

• 模型架构和训练算法的协同设计。

这个时候优化目标基因变化。小规模时，我们很自然地看步骤时间、某个内核的 TFLOPS、某个层的配置文件。大规模时，更重要的单位可能会变成一次长时间运行的训练活动：

• 每日代币数；

• 有效训练时间；

• 失败作业的成本恢复；

• 调试周转；

• 训练过程中遇到异常时定位真实原因的速度。

MegaScale、Robust LLM Training Infrastructure、FALCON、XPUTimer、SuperBench、L4这些公开系统工作，之所以值得看，不只是因为它们报告了大规模集群经验，而是因为它们把“训练系统”这个概念从框架内部进行了集群、网络、诊断和运维闭环。

6.后面的训练和RL让推理也变成训练系统的一部分

另一个变化来自训练后和强化学习。

传统的预训练很容易被想象成一个相对干净的循环：向前、向后、更新，最多加上检查点和评估。但在强化学习/训练后里，训练往往变成一个闭环：

• 推出;

• 环境;

• 报酬;

• 过滤；

• 训练;

• 评估;

• 重新继续推出。

这个推理引擎不再只是训练结束后的服务组件，而会直接影响训练效率。比如rollout路由、负载均衡、前缀感知路由、推测性解码、MTP这类技术，都可能变成训练系统的一部分。

更麻烦的是，一些系统优化不是语义训练的。比如异步RL从系统利用率角度很有吸引力，但从算法角度可能会引入陈旧性和离策略效应。如果和算法侧边共同设计，很容易出现“系统上跑得更满了，但目标其实没有变”的问题。

这类问题给我的启示是：在后面的训练/强化学习场景里，系统优化不能只问“能不能更快”，还要问“是否保持了算法契约”。

7. 容错会成为训练系统本身的问题

随着预训练规模继续变大，机器故障并非异常，而是异常。

现有的很多训练栈本质上还是同步训练：一个等级出问题，整个任务就可能挂起、失败或被迫重启。检查点/重启是必要的能力，但如果训练规模足够大、训练时间足够长，重启成本本身就会显着影响有效训练时间。

所以更理想的方向不是“假设机器不坏训练”，而是让容错变成全局设计的一部分。例如FT-HSDP这类工作讨论的方向，就是在大规模同步训练里尝试隔离失败的副本，让健康副本继续前进，并在恢复后重新加入。

这和传统意义上的“运维可靠性”训练并不完全一样。到了足够大的训练规模，容错本身就是系统的语义和性能问题。

8. 现在最有价值的能力可能是验证/测试/诊断

大规模训练困难的一个原因是整个堆栈都在快速演进：

• GPU和网络设备在变；

• CUDA、NCCL、PyTorch、Transformer Engine、Megatron 变；

• 模型架构变体：MoE、long context、MLA、MTP、新注意力变体；

• 工作负载正在发生变化：预训练、后训练、强化学习、在线生成、推理密集型循环。

这些指标起来，使得“直接复用别人的经验和代码”变得越来越存在风险。即使一个方案在别人的模型、硬件组合、软件版本和集群拓扑上有效，也不代表在自己的环境里仍然有效。

因此，我越来越觉得验证、测试、诊断的价值被低估了。

一个好的诊断系统，应该重点地回答：

• 是模型实现问题，还是训练框架问题？

• 是内核问题，还是通信问题？

• 是数据问题，还是检查点/恢复问题？

• 是少数机器失败速度慢，还是整体配置不合理？

• 是性能漂移，还是正确性漂移？

很多时候，大规模训练最贵的并不是某次失败本身，而是失败之后不知道为什么失败。系统如果能更快定位真正的问题，就能显着提高工程效率。

这也是我认为未来训练系统长期有价值的方向之一：不仅仅是生成一个计划，而是让训练过程更可验证、可诊断、可恢复。

9. 扩展仍然有效时，训练系统市场会分层

最后说一个更偏颇的观点。

允许缩放律在前沿区间继续有效，前沿预训练就会继续往更大模型、更大数据、更大计算资源上推。能完整参与前沿预训练循环的组织会越来越少，因为它不只是需要GPU，还需要数据、算法、工程、稳定性、负载、诊断和长期训练经验。

但这并不意味着开源模型或中小模型会消失。更可能出现的是分层：

• 头部组织训练越来越大的旗舰模型；

• 同时发布一些小密模型，用于端侧、开发者生态、研究社区；

• 发布一些高效/闪存变体，用相关服务成本覆盖更多场景；

• 偶尔发布大型MoE或开放权重模型，作为生态入口。

这种分层会反过来影响训练系统。

如果公开模型架构逐渐回归，比如大部分是 LLaMA-like 主干，再加上一些attention、MoE、long-context、MTP等局部变化，那么为某个具体架构写专用训练器或改现有堆栈的成本会下降。现在编码代理也进一步降低胶水代码、适配器、基线训练器的开发成本。

这会压缩纯粹通用性的价值空间。一个系统如果只强调“我能支持更多模型”，可能不如以前有说服力。因为很多时候，用户可以基于运行公开基线快速改出能力的版本。

但这并不意味着训练系统没有价值。恰恰相反，真正困难的部分会继续存在：

• 平价;

• 检查点/恢复；

• 长期稳定性；

• 容错性；

• 沟通性能；

• 诊断；

• 快速适应实际工作负载。

所以我现在的判断是：通用分布式训练系统的价值不会消失，但它的价值函数会变化。持久的价值可能不等于“自动生成一个填充方案”本身，而足以使复杂的训练过程正确、可诊断、可恢复，并且能够快速配置真实工作负载。

10. 对做研究的一点启示

这篇文章不是说某一条系统路线一定对，或者某条路线已经没有价值。我更想表达的是：做系统研究时，需要非常敏锐地观察需求信号和生态变化。

2022年左右，自动装配是一个非常自然的问题，因为模型结构更多样，用户手写策略的成本非常大，硬件显存又是明显的约束。到了今天，如果模型架构、硬件栈、训练流程都发生变化，那么同一个系统方向的价值也会变化。

对研究来说，这不一定是坏事。它只是提醒我们：

• 不要只问一个系统能不能做什么更笼统的问题；

• 还要问一下普遍性在哪些场景中真正有价值；

• 不要只看性能数字；

• 还要看正确性、可观测性、可调试性、运营成本；

• 不要只研究一个孤立层；

• 要理解它上下游的真实约束。

我个人现在更相信这样一种判断：

多个高效训练系统的核心价值，正在从“找到一个饲料方案”，划分“让复杂训练过程可验证、可诊断、可恢复、可持续演进”。

这个判断肯定不完整，也可能有偏差。如果你在做大规模训练、后期、推理系统、集群调度、网络、检查点、验证或诊断，欢迎补充不同的观察。

作者：朱翼
https://zhuanlan.zhihu.com/p/2056045172111177252