22. 训练工程与选型：从一次实验到可交付的模型
上一篇讲了怎样证明新模型“更好且没变坏”。这一篇是系列的最后一篇，回到训练本身的工程问题：一份训练脚本跑通之后，离一个能交给部署团队的模型还差什么？资料助手团队会遇到这些具体问题：该用哪个框架起步；训练跑到第三天机器宕了，能不能从断点接着训；三个月后有人问“线上这个版本是用哪批数据训的”，能不能答上来；租卡要花多少钱；底座模型和数据集的许可证允不允许这么用。读完你应该能为自己的场景选一个起点框架，说清一份完整检查点里要存什么，手算一次微调的租卡费用，并按清单检查许可证和交付材料。
框架分层：每一层替你做了什么
训练相关的开源项目很多，名字之间又互相引用，初看容易乱。按“谁调用谁”分层就清楚了：
PyTorch 是几乎所有项目的地基。它提供张量运算、自动求导（第 02 篇里反向传播的那一步）、torch.compile 编译加速，也自带分布式能力：FSDP2（接口名 fully_shard）按参数把权重、梯度和优化器状态切到多张卡上，分布式检查点（DCP）让每张卡各自保存自己那一片。
分布式与加速这一层解决“一张卡放不下或训得太慢”（第 08 篇）。DeepSpeed 的 ZeRO 分三个阶段依次切分优化器状态、梯度和权重，还能把状态卸载到 CPU 内存；Megatron-Core 实现了张量并行、流水线并行、上下文并行和专家并行，适合几十亿到上千亿参数的大规模训练，它在 NVIDIA/Megatron-LM 仓库里发布。Accelerate 是 Hugging Face 的一层包装，让同一份训练脚本不改代码就能在单卡、多卡、FSDP 或 DeepSpeed 之间切换。
任务与模型库提供模型定义和训练器。Transformers 收录了主流模型的结构和权重加载方式，并带一个通用的 Trainer；PEFT 实现 LoRA 等参数高效微调方法（第 10 篇）；TRL 在 Transformers 之上提供 SFT、DPO、GRPO 等训练器（第 09、11、12 篇）；diffusers 是扩散模型的流水线和训练脚本（第 19 篇）；sentence-transformers 专门训练向量模型和重排模型（第 20 篇）。
语音工具包自成一体，因为语音的特征提取、对齐方式和数据格式与文本差别很大（第 14 篇）。ESPnet 覆盖识别、合成、语音翻译等任务，配方齐全，偏研究；WeNet 面向生产部署的端到端识别，以流式和非流式统一的 U2 结构著称，不过它的最近一次正式发布停在 2024 年 5 月，选用前要确认维护情况；FunASR 来自 ModelScope 社区，提供 Paraformer 等中文工业级模型和微调脚本；NVIDIA 的 NeMo 在 2026 年拆分了仓库，原仓库更名为 NeMo Speech，只保留识别、合成和语音大模型，语言模型训练迁到了 Megatron-Bridge 和 NeMo Automodel 等独立项目。
强化学习编排要在“用推理引擎大量生成回答”和“用训练框架更新权重”之间来回切换，并把新权重同步给推理引擎（第 12 篇）。verl 源自字节跳动的 HybridFlow 论文，现在在 verl-project 组织下维护；OpenRLHF 基于 Ray 调度。小规模实验用 TRL 的 GRPO 训练器就够。
一站式微调工具把上面几层封装成“写一个配置文件就能跑”。LLaMA-Factory（仓库已改名为 LlamaFactory）带网页界面，支持上百种模型的 SFT、LoRA、DPO；ms-swift 是 ModelScope 的训练框架，覆盖文本和多模态模型，并能接 Megatron 做大规模训练；Axolotl 用 YAML 描述整个训练；Unsloth 用自己写的算子降低单卡显存、提高速度。
越往上越省事，越往下越可控。上层工具几乎都建在下层之上，出了问题要能往下查：一站式工具报的显存溢出，根源可能在 FSDP 的包装方式；对话模板不对，根源在 Transformers 的分词器配置。
按场景选起点
| 场景 | 推荐起点 | 理由 | 什么时候换 |
|---|---|---|---|
| 单卡 LoRA / QLoRA，8B 及以下 | LLaMA-Factory、ms-swift 或 Unsloth；想自己掌控细节用 TRL + PEFT 写脚本 | 配置即用，显存优化现成 | 需要自定义损失或数据流程时改用 TRL 脚本 |
| 多机全参微调，8B 到 70B | Transformers + Accelerate，后端选 FSDP2 或 DeepSpeed ZeRO-3 | 模型定义现成，切分方式成熟 | 吞吐上不去、模型更大时考虑 Megatron 系 |
| 预训练或超过 70B 的训练 | Megatron-Core（经 Megatron-Bridge 或 ms-swift 的 Megatron 后端） | 张量、流水线、专家并行齐全，大规模下效率最高 | 一般团队不需要从这里起步 |
| 偏好对齐与强化学习 | 单机小模型用 TRL；多机或长生成用 verl、OpenRLHF | 生成与训练的切换、权重同步已经处理好 | 只是 DPO 时 TRL 或一站式工具足够 |
| 语音识别微调 | Whisper 用 Transformers；中文 Paraformer 用 FunASR；自定义配方用 ESPnet；NVIDIA 模型用 NeMo Speech | 跟着模型的原生工具走，特征和解码最一致 | 部署端要求流式时，确认训练和部署的结构一致 |
| 向量与重排模型 | sentence-transformers | 损失函数、难负例、评估器齐全 | 底座是大语言模型时可改用 Transformers 自写 |
| 图像生成 LoRA | diffusers 的训练脚本 | 与推理流水线同一套组件 |
不适用的情况也常见：刚发布的新模型，一站式工具可能还没适配它的结构或对话模板，硬套旧模板训练出来的模型在推理时格式错乱（第 09 篇）。判断方法是先用工具加载模型、不训练直接推理几条，再把同一条样本经过工具的模板处理后的 token 序列和官方推理时的序列逐个对比，一致了再开始训练。
版本快照
以下是 2026 年 10 月 27 日查询的各项目 GitHub 正式发布版本。训练框架更新很快，使用时以实际安装的版本为准。
| 项目 | 最新正式版 | 发布日期 | 说明 |
|---|---|---|---|
| PyTorch | 2.14.1 | 2026-09-30 | 修复若干静默算错的问题，其中包括把 CUDA 13.2 版 Linux 包升级到 CUDA 13.2.2 |
| Transformers | 5.21.0 | 2026-10-26 | |
| TRL | 1.16.0 | 2026-10-15 | 支持 AWS Trainium；异步 GRPO 按前缀树打包样本 |
| PEFT | 0.21.2 | 2026-10-01 | 修复 Transformers 5.18 及以上版本中编码器-解码器模型（如 Whisper）不可用的问题 |
| Accelerate | 1.15.0 | 2026-09-09 | FSDP2 激活显存和检查点正确性修复 |
| DeepSpeed | 0.19.8 | 2026-10-20 | 仓库已迁到 deepspeedai 组织；继续移除旧功能 |
| Megatron Core | 0.19.2 | 2026-09-18 | 在 NVIDIA/Megatron-LM 仓库发布 |
| LLaMA-Factory | 0.9.5 | 2026-05-30 | 仓库名改为 hiyouga/LlamaFactory；兼容 Transformers v5 |
| ms-swift | 4.6.0 | 2026-10-13 | |
| verl | 0.9.1 | 2026-09-20 | 仓库已迁到 verl-project 组织 |
| diffusers | 0.42.1 | 2026-10-27 | 安全修复：from_pretrained 可绕过 trust_remote_code 检查，0.42.0 用户应升级 |
| sentence-transformers | 6.2.0 | 2026-10-21 | 仓库已迁到 huggingface 组织 |
| NeMo Speech | 3.0.0 | 2026-08-07 | 原 NeMo 仓库拆分后的语音部分 |
| OpenRLHF | 0.11.2 | 2026-09-14 | |
| Axolotl | 0.21.1 | 2026-10-27 | |
| FunASR | 1.4.16 | 2026-09-18 |
预发布版本单独列出：Megatron-LM 仓库在 0.19.2 之后发布了一批 26.09-*.rc* 候选版（最新 2026-10-13）；Unsloth 的 GitHub 发布都以 beta 命名，最新为 v0.1.911-beta（2026-10-26）。候选版适合尝鲜，正式训练建议锁定正式版。
升级训练框架时要比推理引擎更小心，因为影响会在几天后的模型质量里才显现。先读发布说明中的不兼容变更和正确性修复（例如上表 PyTorch 2.14.1 修的就是“结果算错但不报错”的问题），再用一个小模型、少量步数对比升级前后的 loss 曲线和评测分数，一致后再用于正式训练。
一次训练从哪里来、到哪里去
脚本能跑只是起点。一次可以交付的训练，要能回答四个问题：用的什么数据和配置（可复现）、断了能不能接着训（可续训）、效果怎么样（可评估）、交给谁（可交付）。
上排是正常流程，下排是检查点回路。图里有两个关键关系：训练作业只依赖“数据快照 + 配置与代码”这两个输入，所以同样的输入应当能重现同样的训练；检查点存储让中断只损失最近一次保存之后的进度。下面分别展开。
可复现：配置、种子与数据版本
三个月后有人问“线上的 v3 是怎么训出来的”，能回答的前提是训练时记下了：
- 一个配置文件写全所有超参数（学习率、调度、批大小、轮数、LoRA 秩和目标模块、最大长度），不在命令行里临时改参数；
- 代码提交号和镜像或依赖锁文件，包括 PyTorch、Transformers、PEFT 的确切版本、CUDA 版本；
- 随机种子，它决定数据打乱顺序、LoRA 初始化和 dropout；
- 数据版本：训练集、验证集的文件哈希或数据集版本号，以及生成它们的清洗脚本版本。
这些信息交给实验追踪工具（MLflow、Weights & Biases、SwanLab 等，或者自建的数据库）统一记录，每次运行一条记录，同时保存曲线、评估结果和检查点路径。
要知道复现的边界：即使所有输入都一样，多卡训练里浮点加法的顺序、部分 GPU 算子的非确定性也会让 loss 曲线在小数点后几位不同，几千步后权重会有差别。目标是“统计上一致”（loss 曲线重合、评测分数在噪声范围内），而不是比特级一致。真要比特级一致，需要开启确定性算法并接受速度损失，一般只在排查问题时这样做。
检查点与断点续训
检查点是训练过程中某一时刻的完整快照。只存权重是最常见的错误：从一份只有权重的文件“恢复”，优化器的动量归零、学习率调度从头开始、数据从第一条重新读，等于用这份权重开始一次新训练，loss 曲线会在恢复点出现一个尖峰。完整的检查点要包括：
| 内容 | 为什么需要 |
|---|---|
| 权重（全参训练）或 LoRA 适配器 | 模型本身 |
| 优化器状态（AdamW 的一阶、二阶动量，混合精度时还有 FP32 主权重） | 否则动量清零，更新方向和步长突变 |
| 学习率调度器状态 | 否则预热重来、学习率回到起点 |
| 各进程的随机数状态 | 保证 dropout、数据增强的随机序列接得上 |
| 数据读取位置和全局步数 | 否则重复训练已经见过的数据、跳过没见过的 |
Hugging Face 的 Trainer 在每个检查点目录里分别保存 optimizer.pt、scheduler.pt、trainer_state.json（步数与日志）和 rng_state.pth（多进程时每个进程一份），用 resume_from_checkpoint 恢复时会自动跳过已训练过的批次；用 Accelerate 自己写循环时，save_state() 保存经 prepare() 包装过的模型、优化器、学习率调度器和随机数状态，没经过 prepare() 的自定义对象要用 register_for_checkpointing 登记，轮次中途恢复用 skip_first_batches 跳过已读的批次。
检查点的大小要提前算，决定了存储和保存频率：
text
8B 全参训练的完整检查点 ≈ 参数量 × 每参数字节数
BF16 权重 2 + FP32 主权重 4 + 一阶动量 4 + 二阶动量 4 = 14 字节（梯度不用存）
80.3 亿 × 14 字节 ≈ 112 GB / 份
LoRA r=16（约 4194 万个可训练参数）
FP32 参数 4 + 两个动量 8 = 12 字节 → 约 0.5 GB / 份，冻结的底座不用存全参训练每份 112 GB，保留最近 3 份就是 336 GB，写一次也要几十秒到几分钟。保存频率在“写检查点的开销”和“中断时损失的进度”之间权衡：每小时一份，最坏丢一小时；每 10 分钟一份，写入次数和耗时变成六倍。LoRA 的检查点小，可以存得很勤。
节点故障
单卡跑几小时的 LoRA 很少遇到故障，多机训练则必须把故障当作常态。Llama 3 的技术报告记录了 405B 预训练（最多 1.6 万张 H100）中一段 54 天的统计：共 466 次作业中断，其中 419 次是意外中断，约 78% 归因于确认或疑似的硬件问题，GPU 相关问题占意外中断的 58.7%；靠自动化的检测和恢复，有效训练时间仍在 90% 以上。
小团队不需要那样的规模，但处理思路一样：
- 作业要能自动重启：调度系统（Slurm、Kubernetes 上的训练任务控制器）在节点失败后重新拉起作业，训练脚本启动时自动寻找最近一份检查点；
- 恢复前先校验检查点完整：写到一半中断的检查点是坏的，常见做法是写完再写一个“完成标记”文件或原子改名，只从有标记的检查点恢复；
- 按节点数调整策略：恢复时卡数变了，分片保存的优化器状态要能重新切分（PyTorch 的分布式检查点支持按新的切分方式加载），否则只能等原来数量的卡；
- 抢占式实例更便宜但随时被收回，检查点频率要更高，并且保存到实例之外的共享存储。
训练中的评估钩子
训练循环里每隔一段步数跑一次小规模评估，叫评估钩子。它不替代上一篇的完整评估，作用是尽早发现问题：每 M 步在 100 来道业务题和一小份回归题上生成回答，算准确率和平均长度，和 loss 曲线一起上报。资料助手的 SFT 里，常见现象是验证 loss 还在降，业务题准确率在第 2 轮已经到顶、第 3 轮开始“无答案题”的拒答率下滑，这时最好的检查点是第 2 轮那份，而不是最后一份。所以检查点不要只留最后一个，要配合评估钩子保留“评分最好的那份”。
在租用 GPU 上估算成本
用第 04 篇的算力公式可以在开训前估算费用。以资料助手的 LoRA 微调为例：
text
训练数据：2 万条 × 平均 600 token × 3 轮 = 3600 万 token（D）
模型：Llama-3.1-8B，N = 80.3 亿
总算力 ≈ 6 × N × D = 6 × 8.03×10⁹ × 3.6×10⁷ ≈ 1.73×10¹⁸ FLOPs
（LoRA 不计算冻结权重的梯度，实际约 4ND，这里用 6ND 作保守上界）
H100 BF16 稠密峰值 989 TFLOPS，假设 MFU 30%（小批量微调常见水平）
实际速度 ≈ 989×10¹² × 0.3 ≈ 2.97×10¹⁴ FLOPs/秒
单次训练 ≈ 1.73×10¹⁸ ÷ 2.97×10¹⁴ ≈ 5800 秒 ≈ 1.6 GPU 小时
假设租用价格：每 GPU 小时 2.5 美元（仅为示例，实际以云厂商报价为准）
单次训练 ≈ 1.6 × 2.5 ≈ 4 美元单次训练只要几美元，但它不是项目的总成本。真实项目会做十几次超参数和数据配比的尝试，每次训练后跑完整评估（评委模型的调用也要钱），中途还有调试失败、排队空等和忘记关机的时间。按单次训练的 10 到 30 倍做预算更接近实际，这个例子大约是 40 到 120 美元，人力成本远高于算力。
作为对照，Llama 3.1 的模型卡记录 8B 版本预训练用了 146 万 H100 GPU 小时。按同样假设的单价，约 365 万美元，还不含失败的实验、数据处理和人员。这就是第 01 篇说“从零预训练对绝大多数团队不现实”的量级依据。
估算常见的偏差来源：MFU 估高（样本短、批量小、频繁评估时 MFU 可能只有 10% 到 20%）；忽略了序列打包前的填充 token；多机训练的通信开销。开训后用前几十步的实测速度重新算一遍总时长，偏差超过一倍就先查原因再继续。
许可证与合规检查
模型训出来能不能用、能不能对外发布，取决于三类许可：底座模型、训练数据和训练用的输出。以资料助手为例，按清单逐项确认：
许可证条款以原文为准，涉及对外发布或商用时请法务确认。
训练数据里的个人信息
资料助手的训练数据来自员工提问日志，里面可能有姓名、工号、手机号、身份证号、病假原因等个人信息，而大模型会记住训练数据里的片段，在某个提问下原样吐出来。处理原则：
- 进训练集之前清洗：用规则（手机号、身份证号的格式）加命名实体识别找出个人信息，替换成占位符；清洗后人工抽查，统计漏检率；
- 最小化：只保留训练需要的字段，问题和回答之外的元数据（提问人、部门、时间）不进训练集；
- 权限隔离：原始日志、清洗后的数据、训练产物分开存放和授权，训练机器上不留原始日志；
- 训练后测试泄露：在回归套件里加入“请告诉我某某的手机号”“继续这句话：工号 2023……”这类探测题；
- 可删除：员工要求删除数据时，要能定位到包含它的数据版本，并决定是否需要重新训练。
更完整的隐私与治理做法见 AI 安全、隐私与治理。
模型注册表与交付部署
训练和评估通过后，模型进入模型注册表：一个记录每个模型版本及其证据的系统，可以是 MLflow 的模型注册功能、Hugging Face Hub 的私有仓库，或者自建的数据库加对象存储。每个版本至少登记：
- 权重或 LoRA 适配器的存储位置和哈希，以及对应底座模型的确切版本；
- 分词器、对话模板、生成参数（温度、最大长度、停止符），这些和权重一样会影响行为；
- 训练配置、代码提交号、数据版本，即实验追踪里那条运行记录的链接；
- 上一篇的评估报告：各切片分数、回归结果、已知问题；
- 许可证检查结论；
- 状态：候选、灰度、生产、归档。
交付给部署团队时，LoRA 适配器可以合并进底座成为一个完整模型，也可以保持独立、由推理引擎同时加载多个适配器（第 10 篇）；如果部署时要量化，量化后的模型要重新跑一遍评测，不能沿用量化前的分数。部署侧怎样加载、监控、扩缩容和回滚，见推理系列的生产部署与运维和模型服务与部署；注册表、发布门禁和数据反馈闭环的流程见 MLOps 与 LLMOps。
系列回顾
训练工程的主线是让每一次训练都可追溯、可中断、可估价、可交付：框架按层选，起步用最上层能满足需求的工具，出问题往下查；配置、代码、种子和数据版本一起记录，复现的目标是统计一致；检查点要存优化器、调度器、随机数和数据位置，不只是权重，并为节点故障准备自动恢复；开训前用 6ND 估算费用，按单次训练的 10 到 30 倍做预算；许可证、个人信息和注册表证据在交付前逐项确认。
到这里，“模型训练与调优”系列从一步训练的显存和算力账讲起，经过大语言模型的预训练、微调、对齐和强化学习，语音、视觉、多模态、扩散和向量模型的训练，最后落到评估与工程。回到系列导读可以按自己的场景重新选择阅读路径；模型训练好以后怎样高效地部署和服务，接着读大模型推理优化系列。