训练与微调实践

权重如何变化的理论在 第 17 章（监督微调与参数高效方法）与 第 10 章（把优化器分片到众多加速器上）讲。落到实践里，问题更窄也更直接：现在是 2026 年年中，手上有一个任务和一笔预算，该用哪些工具改变模型权重，怎样把它接进剩下的技术栈，以及到底该不该训练。答案既有立场，也有时效。先立住那些经久耐用的大类和权衡， 至于每一个版本号、价格、排名，都当成一张快照，用时再核实。

这一层及其内容

训练与微调是改变权重的那一层。它有别于只做前向传播的服务层（第 82 章），也不同于用上下文引导冻结模型的智能体和检索层（第 85 章、第 86 章），尽管冻结模型本身也可以被训练去行动、而不只是去回答（第 37 章）。在实际的 2026 年技术栈里，它分成三个子层，这三层容易搞混，工作方式却很不一样。

1. 分布式引擎。 把模型和优化器状态分片到许多加速器上的底层系统：PyTorch FSDP2 和 TorchTitan、NVIDIA Megatron-Core、Microsoft DeepSpeed（ZeRO），还有 TPU 上的 JAX/XLA（MaxText）。4D 和 5D 并行、FP8 训练、万亿级参数规模都在这儿。 第 10 章 会讲解机制。
2. 后训练工具包。 封装这些引擎的高层库，用于监督微调（SFT）、偏好优化（DPO，即直接在「优选与落选」答案对上调参，以及 ORPO）和强化学习（GRPO，即对一组采样答案打分，以及 GSPO、PPO）：Hugging Face TRL、Axolotl、Unsloth、 LLaMA-Factory。这是大多数团队实际接触的层。
3. 参数高效方法与托管服务。 PEFT 库实现的 低秩适配（LoRA）、量化低秩适配（QLoRA）、DoRA，加上完全隐藏加速器的托管微调 API。

有两个 2026 年的主题把这层和全书串起来。一是 FP8 训练已经主流化：Google 的 Ironwood TPU 在矩阵单元里原生支持 FP8，Megatron-Core 提供 FP8 训练，Unsloth 做 FP8 强化学习（Google Cloud, 2026）。二是与基础设施视角更相关的变化：RL 后训练已把训练和推断服务融合在一起。现代 RL 工具包内嵌一个推断引擎（几乎总是 vLLM）来生成 rollout（模型对任务采样得到的尝试），于是训练的盒子里就装着一个服务的盒子；后面的工具链接线，正是从这个事实展开。

第一个岔路：到底要不要训练？

挑工具之前，先回答更难的问题。在 2026 年，对很多任务而言，现实的默认是「别训练权重」。提示工程、少样本示例、检索（第 86 章）和结构化输出，已经覆盖了过去人们经常靠微调才能解决的大部分需求。OpenAI 一边收缩自助微调产品，一边引导用户改用提示缓存、更小的基座模型和 RAG（explainx.ai，二手）。

只有当需要一种上下文窗口无法以低成本承载的「持久行为改变」时，才去微调：

• 提示总是偏离的一致输出格式或固定文风，
• 基座模型里缺少的某个狭窄领域的词汇或约定，
• 把大模型的行为蒸馏成一个小型专用模型，换来延迟或成本上的收益（这对应下层约束），
• 靠强化学习对着一个可验证的奖励塑造出来的能力，即 第 28 章 讲的推理和智能体情形。

如果这些都不成立，就把这一周花在把提示和检索做得更好上，别去跑训练。

一次微调成本和两个服务价格会决定两条成本线的交叉点；这些数字只是示意。盈亏平衡点以下，大型 API 模型便宜；以上，微调过的小模型赢。

import numpy as np
import matplotlib.pyplot as plt

# 仅作示意：展示权衡的形态，并非报价。
finetune_cost = 50.0      # 一次性微调运行，美元
big_price = 5.0           # 大型 API 模型，美元/百万词元（服务）
small_price = 0.5         # 微调小模型，美元/百万词元（服务）

vol = np.linspace(0, 40, 200)            # 服务词元数（百万）
big_total = big_price * vol              # 不训练，按词元付费
small_total = finetune_cost + small_price * vol

break_even = finetune_cost / (big_price - small_price)
print(f"服务 {break_even:.1f}M token 时盈亏平衡")

plt.plot(vol, big_total, label="大型 API 模型")
plt.plot(vol, small_total, label="微调小模型")
plt.axvline(break_even, ls="--", color="gray")
plt.xlabel("服务 token 数（百万）"); plt.ylabel("总成本（美元）")
plt.legend(); plt.title("微调何时回本？")
plt.show()

主要参与者（2026 年年中）

这些表格有时效，也标注了来源。

分布式引擎

后训练工具包（多数团队接触的层）

托管服务（无需自有加速器）

参数高效方法

这些是技术，不是产品；它们活在 PEFT、Unsloth 和 TRL 里。低秩更新为什么够用，理论见 第 17 章。

• LoRA。 低秩适配器，默认选。合并进基座权重后，推断没有额外延迟。
• QLoRA。 4-bit NF4（一种权重数值格式）冻结基座加 LoRA；约 1K 到 50K 样本时单 GPU 的甜区。
• DoRA。 权重分解 LoRA（幅度加方向）；收敛更好，数据量大时值得，约 50K 到 500K 样本。
• rsLoRA。 高秩用的秩稳定 LoRA。
• 更新的 arXiv 变体（RandLoRA、激活空间方法）有，但还不是默认。视为前沿、生产未验证 （AppScale 2026）。

如何选择

一旦确定真的需要训练权重，四个问题就能定下工具。

运行规模。 一块消费级或单块 GPU 指向 Unsloth，因为它有专用 kernel 和低显存。几块 GPU 加配置即代码指向 Axolotl 或 LLaMA-Factory。多节点预训练或继续预训练指向 TorchTitan/FSDP2、Megatron-Core，或 TPU 上的 MaxText。

身处什么生态。 NVIDIA GPU 加想要厂商支持，指向 Megatron-Core/NeMo。PyTorch 原生且能改，指向 FSDP2/TorchTitan + TRL。TPU 指向 JAX/MaxText。纯 Hugging Face 肌肉记忆，直接上 TRL。

方法。 文风或格式加小数据指向 QLoRA。更深的领域迁移加更多数据指向 DoRA 或高秩 LoRA。结构性的领域变化加 500K 以上样本指向 全量微调。针对奖励的推理或智能体行为，指向 GRPO/GSPO：单 GPU 用 Unsloth，多节点生产运行用 verl，纯 PyTorch 路线用 TRL 或实验性的 torchforge（第 28 章）。

自托管还是托管。 托管赢在首次运行的时间、无需 GPU 运维、弹性成本，以及按训练词元的可预测定价。自托管赢在数据驻留、IP 控制、不常见训练配方、可摊销硬件的重复或大型运行，以及避免厂商锁定或突然弃用。注意便利税：Together 按训练词元给 LoRA 计费，还要再加一个单独的按小时专用端点来服务结果，所以便宜的标价并不是全部账单。

具体怎么选：

• Unsloth，当在一块 24 到 80GB GPU 上、要最快最省显存的 SFT 或长上下文 GRPO 时。
• Axolotl，当想要几块 GPU 上可复现的 YAML 配置运行、并且看重 CI 里的配置即代码时。
• LLaMA-Factory，当需要模型支持的广度，或给非专家用的低代码 UI 时。
• TRL，当在编写自定义后训练逻辑、要权威训练器时直接选它。
• TorchTitan/FSDP2 或 Megatron-Core，当在做真正的多节点预训练或继续预训练时。
• MaxText，当在 TPU 上时。
• 一个托管服务，当没有 GPU 运维意愿、且是标准的 SFT/LoRA/DPO/RFT 工作负载时；但考虑 2026 年的弃用先例，要设计好导出路径。

一个合理的默认（2026 年年中）

对一个已确定真的需要微调开放权重模型的典型产品团队，截至 2026 年 6 月：

默认：在 TRL + PEFT 之上用 Axolotl（YAML 配置）做 QLoRA，跑在租用的 GPU 上（Modal、 Runpod 或自有的云）。它可复现，配置即代码契合 CI 与评估（第 87 章），QLoRA 让微调停在单块或几块 GPU，权重和数据都还在自己手里。起步配方是 r=16、开启 DoRA、 target_modules="all-linear"，难一点的任务再加秩（AppScale 2026）。

• 备选 A，最大单 GPU 效率或 RL： Unsloth，尤其适合消费级 GPU 或长上下文 GRPO。
• 备选 B，完全没有 GPU 运维： 托管服务。Together 用于低成本的开放权重 LoRA/SFT， Fireworks 用于调优与服务合一，Bedrock 用于 AWS 原生，Tinker 用于训练循环仍要自己写、只向对方租用分布式 GPU 的场合。设计好导出和可移植路径；别以为 托管 FT 产品会永远存在。OpenAI 在 2026 年 5 月宣布的自助收缩，就是个教训。

如果是多节点预训练而非微调，默认就转向 TorchTitan/FSDP2 或 Megatron-Core，或 TPU 上的 MaxText。

接进技术栈

2026 年最有标志性的接线事实是：RL 后训练如今内嵌了推断层。 一个 GRPO 或 PPO 循环从当前策略生成 rollout，用奖励打分，然后更新权重。生成是瓶颈，工具包就把它交给一个快速推断引擎，几乎都是 vLLM。Unsloth 驱动 vLLM 做 rollout；torchforge 用 vLLM 做生成、TorchTitan 做训练，通过一个 RDMA 张量存储在两者之间搬运权重（PyTorch 博客）；verl 则是生产级多节点的情形，在一个混合控制器下调度 vLLM 或 SGLang 的 rollout worker 与 FSDP 或 Megatron 的训练器，vLLM 自家 2026 年 6 月推出的 vime 沿用的正是这个模式。所以架构图里的训练盒子，里面就装着一个服务盒子。这正是 第 82 章 里同一个 vLLM，如今被当作训练的一个子组件来用，恰好印证本书的论点：这些层本是一套基础设施。切分训练回路的架构模式（同址还是分离），以及异步对同策略的取舍，是 第 37 章 的主题。

训练完成后，合并适配器，或用一个适配器感知的引擎直接服务它，把权重交给网关（gateway）背后的服务层（第 82 章），并在晋升之前对它跑一遍评估 harness（第 87 章）。检索与 智能体层随后消费这个已由服务层托管的模型。适配器感知的服务，也就是一个基座上挂众多 LoRA，正是托管适配器平台历来契合的地方。整个流程汇入 第 88 章 的端到端技术栈。

一份可改写的配置与启动

一份最小的 Axolotl QLoRA 配置可以这样写；它只是示意：

# qlora.yml
base_model: Qwen/Qwen3-8B
load_in_4bit: true          # QLoRA: 4-bit NF4 frozen base
adapter: lora
lora_r: 16
lora_alpha: 32
lora_target_modules: all-linear
datasets:
  - path: ./data/sft.jsonl
    type: chat_template
gradient_checkpointing: true
sequence_len: 4096
micro_batch_size: 2
num_epochs: 3
# distributed backend (FSDP2 or DeepSpeed) configured via accelerate

启动它，然后为服务合并适配器：

# train (single or few GPUs via accelerate)
accelerate launch -m axolotl.cli.train qlora.yml

# merge the LoRA adapter back into the base for adapter-free serving
python -m axolotl.cli.merge_lora qlora.yml --lora_model_dir ./out

合并后的权重再交给服务栈。把配置放进版本控制，让一次训练成为一个可审的 diff，和对技术栈其余部分的纪律一样。

微调实际改变什么

微调首先是一种「能力」手段，即提示承载不了的持久行为改变。它也越来越是一种「效率」手段，把大模型蒸馏成服务成本低的小模型，这正是服务成本频繁向上塑造设计的原因。它还是一个「信任」问题：微调后的模型吸收了训练所用的数据，所以数据驻留、可复现的配置即代码、晋升前的评估关口，都不是锦上添花，而是让权重可以进入生产的控制条件。2026 年现实的默认，仍然是先去做好提示和检索，只有当行为改变必须活在权重里时，才去训练。

延伸阅读

一手来源放前面。