研究作者Michael Barlow发布时间2026年5月22日引言模型训练发展迅速新的阶段不断加入训练流程现有阶段也变得更加复杂这使得模型训练成为一项工程挑战主要有以下三个关键原因。其一复杂度增加意味着出错的可能性增大。数据、代码或配置中的错误或不一致可能导致整个训练运行失败或偏离预期。其二失败的成本不断上升。模型规模越来越大GPU价格上涨每次运行处理的数据也越来越多。当消耗数千个GPU小时时失误的代价可不小。其三也是最具挑战性的问题是组织协调。这种复杂度早已超出了个人的能力范围因此像我们这样的实验室组建了大型的专业团队。随之而来的问题是如何协调这些团队。团队成员如何在自主探索其专业领域最新研究的同时将他们的更改集成到生产流程中而不破坏流程或干扰彼此的工作他们又如何确保各个阶段的改进最终能转化为更优秀的模型传统的手动模型训练流程无法很好地解决这些问题。手动模型训练的隐性成本从宏观层面看模型训练似乎很简单先进行预训练以学习互联网上的知识然后进行后训练以学习遵循指令。但实际上第一次尝试很难训练出优秀的模型。找到合适的数据组合、架构和训练方案是一个迭代的、计算密集型的过程需要通过评估来指导以下每个步骤的成本都与相对的GPU消耗相关。这些组件中的每一个都足够复杂需要多个专门的团队来负责。例如现代的后训练包括监督微调SFT阶段和强化学习RL阶段。SFT和RL需要不同的技能和工具但必须集成起来才能训练出模型。在手动实验室中单个模型在训练流程中的经历如下数据团队完成了新的数据组合并通过Slack将数据库路径发送给预训练团队预训练团队随即启动为期数周的训练。两周后存储配额已满训练运行崩溃。由于文件系统是手动管理的没人确定是否可以删除那个文件名中带有 do_not_delete 的30TB数据集预训练团队在解决这个问题时GPU只能闲置。最终重新启动时他们凭借记忆和Slack聊天记录重建原始设置祈祷没有忘记设置某个标志。这就是第一个隐性成本每一个手动步骤都可能导致人为错误。预训练最终完成后预训练团队将检查点交给SFT团队。为了找到合适的方案SFT团队手动启动一系列不同配置和数据组合的并行训练。随着检查点不断生成团队对每个检查点运行评估脚本并在Slack上分享结果和分析。有些方案看起来很有前景有些则不然他们会重复这个过程几周直到确定一个合适的方案。不知不觉中团队重复了几个月前为上一个预训练检查点做过的一些实验。这就是第二个隐性成本团队会遗忘之前的经验教训。对于超参数的当前值没有持久的记录说明其背后的原因数据组合与其组成数据集之间没有正式的关联模型与生成它的训练方案之间也没有明确的归属关系。在手动实验室中这些信息分散在Slack、文件系统、实验管理器和各种维基页面中随着时间的推移很容易丢失。SFT团队将检查点交给RL团队RL团队以此为基础启动训练。最终模型的表现不佳。是RL方案对上一个月的SFT检查点过拟合还是SFT检查点本身有问题经过两周的调试RL团队确定是后者的问题。由于两个团队都无法执行对方的阶段每个团队都只针对自己负责的流程部分进行优化而不是考虑最终的模型。而且由于集成是手动交接这种交接很少进行每次都需要花费一个月的时间来解决差异。这就是第三个隐性成本手动、不频繁的交接会分散团队的所有权。显然手动模型训练无法应对规模的增长而自动化并不是唯一缺失的环节。这些隐性成本都源于同一个根本问题训练流程只存在于团队成员的脑海中而没有形成一个共享的、持久的产物。为了实现规模化训练流程本身需要成为一个可处理的、团队可以协作的对象。介绍以代码形式进行模型训练我们的模型工厂代号为Savanna它以命令式代码实现了整个模型训练流程和处理过程。我们将其称为“以代码形式进行模型训练”Model Training as CodeMTaC。以下是一个简单的Savanna后训练流程的伪代码示例async post_train(config: PostTrainConfig) - PostTrainEvaluation: sft_checkpoint await sft(config.sft) sft_eval spawn evaluate(config.eval, sft_checkpoint) rl_checkpoint await rl(config.rl, sft_checkpoint) rl_eval spawn evaluate(config.eval, rl_checkpoint) return PostTrainEvaluation(await sft_eval, await rl_eval)将训练流程转化为代码有三个好处可组合性、共识和可追溯性。1. **可组合性**可组合性源于将手动步骤表示为具有类型化输入和输出的函数这样就可以围绕这些函数构建抽象并将它们组合成一个端到端的流程只需一键即可运行。修改流程就像编辑一个函数一样简单像评估中间检查点这样的重复性工作可以通过for循环自动化测试也很直接因为可以使用不同的参数运行流程的子集或缩小版本。2. **共识**共识来自版本控制。主分支代表了团队对如何训练模型的集体最佳理解。代码包含了完整的训练方案因此在启动训练运行时无需重建设置或担心忘记设置标志。3. **可追溯性**可追溯性来自代码注释和提交历史。这些记录了导致主分支的经验教训和决策。过去的训练运行仍然可以重现因为生成它们的代码被固定在一个提交中可以检出并重新运行。当任何团队都可以自行启动完整的训练流程时他们就可以运行其他团队负责的阶段并对整个模型进行迭代而不仅仅是自己负责的部分。实验室在扩大规模时通常会按时间顺序分解模型训练每个团队负责流程的一个阶段。MTaC开启了基于能力分解的可能性即团队可以从头到尾负责模型的一种行为如多语言能力。小步集成频繁集成将训练流程转化为代码后标准的代码协作最佳实践就可以应用了。要充分发挥MTaC的优势就需要遵循这些实践。其中最重要的是基于主干的开发即更改尽快以小增量合并到 main 分支这样团队就可以尽早在彼此的工作基础上进行构建如果方法错误也能快速失败。如果将更改累积在长期分支中就会像以前一样产生集成成本。使用SavannaSavanna托管在GitHub上其持续集成CI是模型训练的入口。你可以通过推送到分支或从GitHub UI手动启动运行来触发CI。训练我们的最佳模型就像在 main 分支上触发CI一样简单。我们还在拉取请求上使用CI通过小规模的端到端训练运行快速验证流程。这个过程在5分钟内完成因此为Savanna做贡献不会感觉很慢这也让我们对更改有信心。为了检测流程中的语义回归我们每晚运行一次大规模的端到端训练测试通过确保生成的模型在评估套件中取得可衡量的改进来验证训练逻辑。MTaC通过 git blame 提供决策追溯Savanna在此基础上扩展了工件追溯。运行是封闭的所有非代码工件如数据、模型和分词器都是不可变的并在注册表中进行版本控制因此你可以确保每次都能得到相同的结果。当你启动一个运行时引用的工件、训练日志、指标和评估结果都与该运行和生成的检查点相关联这样你就可以轻松地将输出归因于输入。要确定哪些模型是在特定数据集上训练的你可以使用工件追溯图而不是在Slack中搜索。Savanna使大规模运行变得容易但要改变这些运行的样子需要能够在较小的规模上对流程的各个方面进行实验性修改包括数据、超参数、流程步骤、环境、分片拓扑等。在Savanna中进行实验就像将更改推送到分支并从那里运行CI一样简单。如果你想尝试一个新的数据集可以将其添加到消融训练配置中并运行CI。如果评估结果显示有改进你可以将此更改合并到 main 分支使其成为下一次大规模运行的一部分。超参数搜索也很容易。由于训练流程只是一个函数你可以通过编程方式多次调用它使用不同的参数。例如以下是一个实验用于找出前面所示后训练流程中SFT和RL的最佳学习率async post_training_learning_rate_experiment(config: PostTrainConfig) - str: post_train_runs [] for sft_learning_rate in (1e-4, 1e-5): for rl_learning_rate in (1e-4, 1e-5): run_config config .with_sft_learning_rate(sft_learning_rate) .with_rl_learning_rate(rl_learning_rate) post_train_runs.append(spawn post_train(run_config)) post_train_evaluations gather post_train_runs experiment_report_url create_report(post_train_evaluations) return experiment_report_urlSavanna会自动编排搜索过程并将最终结果整理成报告供你分析。以下是这个实验在Savanna工作流引擎UI中的可视化展示。蓝色节点表示“正在运行”橙色节点表示“等待缓存”。虽然我们调用了四次 post_train但SFT阶段只会运行两次Savanna的工作流引擎会识别出哪些阶段具有相同的输入并在相应的运行阶段完成后从缓存中读取其输出。这让你可以启动修改流程多个方面的搜索而不用担心冗余计算的组合爆炸问题。对于预训练运行或长时间运行的RL任务我们会逐步生成并评估检查点以便更好地了解模型在训练过程中的变化。训练完成后Savanna会自动在我们的基准测试套件上评估模型并将所有结果和指标收集到一个运行报告中。Savanna还会自动更新我们的模型排行榜我们将其展示在海德堡总部的大屏幕上这样当我们训练出新的最佳模型时每个人都能一同感受这份喜悦。Savanna的工作原理当你触发一个运行时Savanna会在我们选择的工作流引擎Flyte上启动一个作业Flyte在Kubernetes中运行。Flyte提供了一种方便的方式来运行任意任务支持持久执行、排序、并行处理、重试、缓存并提供一个UI来可视化运行过程。我们将模型和数据工件不可变地存储在我们的本地对象存储中并在Weights Biases中跟踪它们的版本。这使我们能够轻松分配清理策略保持存储系统的整洁并提供一个UI来交互式地探索工件追溯。然后我们将这些数据流式传输到我们的Kubernetes GPU集群进行训练。在训练过程中我们的作业会将指标记录到我们的监控系统中以便实时跟踪进度和性能如果需要干预还会发送警报。Savanna对我们有何帮助我们知道随着领域的发展模型训练的复杂度只会不断增加组织协调的挑战也会随之增大。MTaC使我们能够将组织协调的复杂度转化为代码从根本上改变了我们的工作方式。在日常工作中我们的迭代速度更快了。我们的大部分工作是小规模的实验和搜索Savanna自动化了以前手动启动和评估的过程。现在我们可以将精力投入到分析结果和设计下一个实验中。对于单次大规模运行情况则有所不同。在最近一次大规模预训练运行中我们多次恢复训练以便根据自动化的中间评估结果调整设置。每次重新启动都快速且风险低因为MTaC提供的共识意味着无需重建设置或担心忘记设置标志。而且由于重新启动很容易不需要每次都是同一个人操作所以任何在场的人都可以安全地接手。从更高层面来看MTaC使我们能够组建多个以能力为导向的后训练团队这些团队从头到尾负责模型某种行为的集成和改进。例如我们的多语言团队正在通过构建SFT数据集、RL环境和评估套件使模型在德语语言和文化方面表现出色。自从采用Savanna并融入工程文化以来我们作为一个组织的学习速度显著提高。随着我们的训练流程变得更加复杂团队规模不断扩大这种方法的价值也越来越凸显。展望未来我们认为MTaC是自动研究的关键推动因素。由于我们的整个训练流程都以代码形式存在一个大语言模型LLM代理可以自主读取、修改和运行它我们现在已经开始探索这一可能性。我们希望有一天我们的模型能够通过Savanna实现自我改进。致谢本文由Michael Barlow撰写。这项工作反映了Aleph Alpha研究团队众多贡献者的集体努力是他们让Savanna得以实现。感谢Martin Reinhardt、Dominik Kellner和Jordan Sassoon提供的宝贵反馈这些反馈塑造了这篇博客感谢Paige Reddington和Noé Beckerle Vallejo让文章更具可读性。联系信息Speyerer Straße 1469115 海德堡Wallstraße 1610179 柏林Weiherstraße 2695448 拜罗伊特Einsteinstraße 17481677 慕尼黑法律声明* [ 隐私政策 ](/en/privacy/)* [ 版权声明 ](/en/imprint/)社交媒体* [ LinkedIn (在新窗口中打开) ](https://de.linkedin.com/company/aleph-alpha)* [ X (在新窗口中打开) ](https://x.com/Aleph__Alpha)* [ GitHub (在新窗口中打开) ](https://github.com/Aleph-Alpha)咨询方式* [ 联系我们 ](/en/contact/)* [ 支持 (在新窗口中打开) ](https://supportportal.aleph-alpha.com)* [ 职业机会 (在新窗口中打开) ](https://jobs.ashbyhq.com/AlephAlpha)版权所有 © 2026 Aleph Alpha GmbH