Repository Reading Site

第二十课：大模型训练、SFT、LoRA、Checkpoint、Adapter 与模型产物原理

前一课我们把“数据是什么、样本长什么样、为什么要清洗和版本管理”讲清楚了。但如果你只知道数据，不知道训练过程到底在做什么，你还是会停留在一种很浅的理解：这当然不对。真正的训练过程，本质上是一套非常明确的优化过程：所以这一课的目标不是教你“会跑一个训练命令”，而是要把下面这些核心问题彻底讲透： 1. 训练到底在优化什么？ 2. 一次前向、一次反向、一个

Markdown20-第二十课-大模型训练-SFT-LoRA-Checkpoint-Adapter与模型产物原理.md2026年4月10日 10:53

第二十课：大模型训练、SFT、LoRA、Checkpoint、Adapter 与模型产物原理

为什么这一课必须紧接着“数据治理”来学

前一课我们把“数据是什么、样本长什么样、为什么要清洗和版本管理”讲清楚了。

但如果你只知道数据，不知道训练过程到底在做什么，你还是会停留在一种很浅的理解：

把数据喂给模型
跑一会儿
就得到了一个更聪明的模型

这当然不对。

真正的训练过程，本质上是一套非常明确的优化过程：

文本先被切成 token
token 变成向量
向量经过 Transformer 多层计算
模型输出每个位置的概率分布
和“正确答案”比，算出损失
再通过反向传播修改参数

所以这一课的目标不是教你“会跑一个训练命令”，而是要把下面这些核心问题彻底讲透：

训练到底在优化什么？
一次前向、一次反向、一个 step 各自是什么意思？
预训练、继续预训练、SFT、偏好优化到底有什么边界？
LoRA 为什么能少改参数却学到新能力？
Checkpoint 到底是什么，为什么它不等于最终上线模型？
Base model、adapter、merged model、runtime package 分别是什么？
模型训练结束后，磁盘上到底会留下哪些文件？
企业里怎么管理模型版本、训练血缘和产物发布？

如果你未来要做到架构设计、平台治理和问题排查，这一课是核心中的核心。

先给你一张总图：训练不是一个黑盒，而是一条可拆解的流水线

清洗后的样本
  -> tokenizer 切 token
  -> token ids
  -> embedding 向量
  -> Transformer 前向计算
  -> logits
  -> loss
  -> backward 反向传播
  -> optimizer 更新参数
  -> 定期保存 checkpoint
  -> 评估
  -> 导出 adapter / merged model / runtime package
  -> 注册到模型仓库

请你先把一个认识钉牢：

训练不是“往模型里写知识文件”，而是“通过损失函数和梯度，反复调整参数”。

模型不会在内部存一个：

Kubernetes 知识表
法律知识表
运维知识表

它真正存的是：

大量参数
这些参数共同塑造出的概率分布和行为偏好

所以模型学到的不是“字面答案库”，而是：

语言模式
任务模式
概念关联
输出风格
回答习惯

第一章：训练到底在优化什么

最朴素的理解

对于文本大模型，训练目标可以先粗暴理解成一句话：

给定前文，预测下一个 token。

如果一句话是：

Kubernetes 中最小的可部署单元是

模型会给出下一个 token 的概率分布，例如：

Pod: 0.78
Node: 0.08
Service: 0.04
其他 token: 若干

训练的目标，就是让“正确 token”的概率越来越高。

什么叫“正确 token”

所谓正确 token，不是模型自己想出来的，而是来自训练样本。

例如真实目标文本是：

Kubernetes 中最小的可部署单元是 Pod。

那模型在看到前缀：

Kubernetes 中最小的可部署单元是

时，监督信号就是：

下一个 token 应该更接近 Pod

再往后一个位置，模型看到：

Kubernetes 中最小的可部署单元是 Pod

监督信号又变成：

下一个 token 应该更接近 。

于是整段文本会在多个位置上分别计算损失。

训练不是“记答案”，而是“改参数”

你一定要建立这个工程直觉：

样本只是监督信号
参数才是模型真正被修改的对象

也就是说，训练时发生的不是：

把一句知识直接存入模型数据库

而是：

用样本推着参数往一个更优方向移动

这就是为什么模型会：

泛化
迁移
有时答得像“懂了”

同时也会：

幻觉
过拟合
忘掉旧能力

因为它学到的是分布和模式，不是字面规则表。

第二章：一条文本样本是怎么穿过模型的

这一章你必须真正看懂，因为后面所有排障都依赖这个过程。

Step 1：Tokenizer 先把文本切成 token

例如文本：

Pod 会共享网络命名空间。

不会直接一整句送进模型，而是先由 tokenizer 切成 token。

注意，token 不等于：

一个汉字
一个英文单词
一个字节

它是 tokenizer 规则下的最小切分单元。

不同模型的 tokenizer 不同，所以：

同一句话
在不同模型里
token 数可能不同

这也是为什么：

上下文长度
训练成本
推理成本

都不能只看“字符数”，而要看 token 数。

Step 2：Token id 变成 embedding 向量

Tokenizer 输出的不是向量，而是整数 id。

例如：

[30002, 1821, 91827, 45123]

模型会通过 embedding table，把每个 id 映射成一个高维向量。

你可以把 embedding 粗略理解成：

token 在高维空间中的坐标表示

但不要误会为：

一个 token 对应一个静态“意义”

因为真正进入 Transformer 后，它还会在上下文中不断变化。

Step 3：经过多层 Transformer

每一层通常包含两大块：

自注意力
前馈网络

自注意力解决的问题是：

当前 token 在理解自己时，应该关注上下文里的哪些 token。

例如在句子：

Pod 被调度到某个节点后，容器共享 Pod 的网络命名空间。

模型在处理“共享”时，会更关注：

容器
Pod
网络命名空间

而不是平均关注所有 token。

前馈网络可以粗略理解成：

对每个位置做更复杂的非线性变换

多层叠加后，模型逐步形成更高层次的表示。

Step 4：输出 logits，而不是直接输出汉字

模型最后输出的是每个位置对整个词表的打分，通常叫：

logits

logits 经过 softmax 后，才变成概率分布。

所以模型内部不是直接说：

“答案是 Pod”

而是说：

“在这个位置，词表里每个 token 的相对可能性分别是多少”

Step 5：用 loss 衡量“差多远”

如果正确 token 概率太低，loss 就大。

如果正确 token 概率很高，loss 就小。

对于因果语言模型，最常见的是：

交叉熵损失

你不必一开始就沉迷公式，但要知道它的直觉：

模型越把正确答案当回事，损失越小；越偏离正确答案，损失越大。

第三章：前向、反向、梯度、优化器，到底各自是什么意思

这是训练最核心的一章。

什么叫前向传播

前向传播就是：

输入样本
经过模型计算
得到 logits 和 loss

它回答的是：

以模型当前参数来看，它会怎么预测？

什么叫反向传播

反向传播就是把：

当前 loss 对每个参数的影响

从输出端一路往回传，算出每个参数的梯度。

梯度可以先粗略理解成：

如果这个参数往某个方向改一点，loss 会变大还是变小

所以梯度不是参数本身，也不是知识本身，而是：

参数更新方向的信息

什么叫优化器

优化器负责根据梯度真正修改参数。

你最常看到的是：

SGD
Adam
AdamW

在大模型里，AdamW 非常常见。

它不是简单地“参数减去梯度”，而是会结合：

梯度的一阶统计
梯度的二阶统计
学习率
权重衰减

来决定每一步怎么走。

所以你要知道：

loss 决定优化目标
backward 计算梯度
optimizer 决定怎么改参数

这三者不是一回事。

一个训练 step 到底包含什么

一个 step 通常包含：

取一个 batch
前向计算
计算 loss
反向传播
优化器更新
清理梯度

如果用了梯度累积，则会变成：

连续吃多个 micro-batch
每个 micro-batch 只做 forward + backward
累积到一定次数再 optimizer.step()

这就是：

gradient_accumulation_steps

存在的意义。

Batch、Micro-batch、Step、Epoch 是最容易混的四个词

你必须区分：

名词	含义
batch	一次送进模型的一批样本
micro-batch	单卡或单次实际前向处理的更小批次
step	一次参数更新
epoch	整个训练集被完整看一遍

一个常见误区是：

以为 step = batch = epoch

这是错的。

例如配置里：

每卡 batch size = 1
4 张卡
gradient accumulation = 16

那一次 optimizer step 的等效 batch 大约就是：

1 x 4 x 16 = 64

所以你看训练日志时，一定要先搞清楚：

当前看到的 loss 是哪个粒度
当前 global step 是参数更新次数，还是 micro-step

第四章：为什么训练这么吃显存和算力

很多人知道“大模型训练贵”，但不知道贵在什么地方。

如果你未来要做平台和排障，这一层必须吃透。

训练时显存主要被谁吃掉

训练显存通常由四大块构成：

模型权重
激活值
梯度
优化器状态

这里最容易被忽略的是：

优化器状态

以 AdamW 为例，它通常还要为每个参数维护额外统计量。

于是一个参数不只是存一份权重，而可能还要额外存：

梯度
一阶动量
二阶动量

这就是为什么：

训练显存远大于推理显存

为什么序列长度会把成本迅速拉高

在大模型里，成本不只受参数量影响，也强烈受：

sequence length

影响。

因为序列越长：

激活值越多
注意力计算更重
每个 batch 需要的显存越高

这也是为什么很多训练事故并不是模型变了，而是：

同样模型
只是把 max_seq_length 从 2048 提到 4096
就突然 OOM

为什么会有 gradient checkpointing

很多人第一次看到这个词，以为它和“保存 checkpoint”是一回事。

不是。

这里的 checkpointing 指的是一种显存优化技巧：

前向时不保存所有中间激活
反向传播时再把部分前向重算一遍

这本质上是：

用更多计算
换更少显存

所以：

gradient_checkpointing

是训练中的算存折中策略，不是模型版本保存机制。

第五章：预训练、继续预训练、SFT、偏好优化，到底怎么区分

这一组概念必须分清，不然后面你会把训练流程彻底混掉。

1. 预训练 Pretraining

目标是学习广泛语言分布和世界模式。

数据通常是：

大规模网页
书籍
代码
论文
文档

特点是：

数据量巨大
更偏“学语言和知识分布”
成本极高

产物通常是：

一个基础模型 base model

2. 继续预训练 Continual Pretraining

也有人叫：

domain pretraining
continued pretraining

它是在已有 base model 上，再用某个领域语料继续训练。

例如：

医疗文本
法律文书
运维和 Kubernetes 文档

目的不是让模型更会“听指令”，而是让它更熟悉某个领域分布。

3. 监督微调 SFT

SFT 的目标是：

让模型更像一个“会按要求回答的人”。

数据通常是：

user -> assistant
多轮对话
指令 -> 回答
问题 -> 解释

SFT 对模型的核心影响不是：

注入海量新知识

而更多是：

调整回答格式
调整任务跟随能力
调整风格、礼貌性、结构性
强化某类任务的可用性

4. 偏好优化 DPO / RLHF 一类

这一步不再只是告诉模型“标准答案是什么”，而是告诉它：

哪种回答更好
哪种回答更差

例如同一个 prompt：

chosen 是更符合偏好的回答
rejected 是较差的回答

它训练的是：

回答排序偏好
风格偏好
安全边界

这几种训练方式的边界

阶段	主要目标	典型数据	典型产物
预训练	学语言分布与通用知识	大规模连续语料	base model
继续预训练	强化某领域分布	领域连续语料	domain-adapted base model
SFT	学会听指令和回答风格	指令问答 / 对话	instruct model 或 adapter
DPO / RLHF	学偏好和对齐	chosen / rejected	aligned model 或 adapter

你要建立一个特别重要的边界感：

RAG 不属于上面这些训练阶段中的任何一个。

RAG 是推理时把外部知识接入上下文，不是训练时把参数改掉。

第六章：SFT 到底在学什么，为什么它不等于“喂问答题”

很多小白会以为：

SFT 就是把很多问答丢给模型背下来

这很不准确。

SFT 的本质

SFT 仍然是 next-token prediction，只不过样本组织方式变了。

例如一条样本可能长这样：

{
  "messages": [
    {"role": "user", "content": "什么是 Pod？"},
    {"role": "assistant", "content": "Pod 是 Kubernetes 中最小的可部署单元。"}
  ]
}

模型并不是“理解了 role 字段这个数据库结构”，而是：

在特定聊天模板下
学会对 user 指令之后的 assistant 文本进行预测

为什么很多 SFT 训练只对 assistant 部分算 loss

这是个很关键的工程点。

如果一条样本包含：

system
user
assistant

通常我们并不希望模型去学习“把 user 提问复述出来”，而是希望它重点学习：

assistant 应该怎么答

所以训练时经常会做：

loss mask

也就是：

assistant token 参与损失
system/user token 不参与损失或权重更低

这也是为什么在示例配置里：

00-sft-lora-training-config.yaml

故意放了：

loss_mask: "assistant_only"

为什么 SFT 后模型“更会聊天了”

因为它学到的不是单纯知识，而是：

问答结构
格式控制
解释方式
拒答模式
风格模式

所以一个 base model 做完 SFT 后，常常会表现得：

更会遵守指令
更会分点回答
更会拒绝危险请求

这不是魔法，而是输出分布被重新塑形了。

第七章：全参数微调和 LoRA，到底差在哪里

这是工程上最重要的一组取舍。

全参数微调 Full Fine-tuning

全参数微调的意思是：

基础模型的所有参数都参与更新

好处是：

表达能力最强
可塑性最高

代价是：

显存消耗极大
训练成本高
存储成本高
容易把原模型能力改坏

LoRA 的核心思想

LoRA 不是直接改完整权重矩阵 W，而是写成：

W' = W + ΔW
ΔW = (alpha / r) * B * A

其中：

W 是冻结的原始权重
A 和 B 是两个低秩小矩阵
r 是 rank，远小于原矩阵维度

这意味着：

不动大权重
只训练一小部分增量参数

为什么低秩近似能工作

它背后的直觉是：

很多任务适配，并不需要把整个高维权重空间都重新学习一遍，只需要在某些关键方向上做小而有效的修正。

换句话说，LoRA 假设：

任务适配所需的变化
可以用一个低秩更新来近似表达

这当然不是永远完美，但在很多实际任务上非常有效。

LoRA 为什么这么省资源

因为训练时真正需要更新和存储的，不再是整套大模型权重，而只是：

A 矩阵
B 矩阵

于是你得到三个直接收益：

训练显存更低
训练产物更小
一套基础模型可以挂多个 adapter

LoRA 常见会改哪些模块

在 Transformer 里，LoRA 常见目标模块包括：

q_proj
k_proj
v_proj
o_proj
gate_proj
up_proj
down_proj

你在示例文件：

adapter_config.json

里能看到这些 target modules。

这不是随便选的，而是因为这些层对模型表达能力影响很大。

LoRA 的限制

你一定不能把 LoRA 神化。

它的限制包括：

对极大分布偏移任务，可能不如全量微调
rank 太小可能学不动
base model 选错，LoRA 救不了
推理时要额外挂载 adapter，工程链更复杂

QLoRA 又是什么

QLoRA 可以粗略理解成：

把基础模型以更低精度量化后加载
再在其上做 LoRA 训练

它进一步降低了资源门槛，但你要注意：

量化是近似
数值稳定性更敏感
训练和推理链路更复杂

所以不是所有场景都应该默认 QLoRA。

第八章：Checkpoint 到底是什么，为什么它不等于最终模型

这是新手最容易混淆的地方之一。

Checkpoint 的本质定义

Checkpoint 是：

某个训练时刻的状态快照。

注意，关键词是：

训练时刻
状态快照

它不是只保存“模型长什么样”，而是要尽可能保存“从这里继续训练所需的一切”。

一个 checkpoint 里通常有什么

常见内容包括：

当前模型权重或 adapter 权重
优化器状态
学习率调度器状态
随机数状态
训练参数快照
trainer 状态

你可以直接看这个示例目录：

checkpoint-000120

以及其中真实保留的两个文本文件：

为什么优化器状态这么重要

因为如果你想恢复训练，只恢复模型权重往往不够。

优化器内部已经积累了：

动量
二阶统计
学习率进度

如果这些状态丢了，再继续训练时，训练轨迹可能就变了。

所以：

checkpoint 面向“继续训练”
final model 更偏向“部署和推理”

为什么 checkpoint 常常比你想象得大

因为它可能不仅包含：

模型参数

还包含：

优化器状态
梯度相关状态
其他训练状态

尤其在 AdamW 一类优化器下，存储开销会明显膨胀。

这也是为什么企业里经常要控制：

save_steps
save_total_limit

否则磁盘会很快爆掉。

第九章：训练跑完后，磁盘上的模型产物到底长什么样

这是最需要“看见形状”的一章。

很多人一直听：

base model
adapter
merged model
runtime package

但根本不知道它们在文件系统里长什么样。

这一节我们把它们彻底拆开。

1. Base model

基础模型目录通常包含三类关键文件：

模型结构配置
tokenizer 配置
权重文件

你可以看这个示例目录：

03-base-model

里面我保留了最关键的文本文件：

真实项目里还会有：

model.safetensors

或者多分片权重文件。

每类文件是干什么的

config.json

描述模型结构
层数、隐藏维度、头数、词表大小等都在这里

tokenizer*.json

定义文本如何切 token
special token 是什么
聊天模板从哪里来

generation_config.json

描述默认生成策略
比如 temperature、top_p、max_new_tokens

model.safetensors

真正的参数本体

2. Adapter

LoRA 训练完成后，常见产物目录是：

04-adapter

里面最关键的配置文件是：

adapter_config.json

真实项目里还会有：

adapter_model.safetensors

这个文件非常关键，它存的是：

增量权重

而不是整套基础模型。

所以你要形成一个特别清晰的认识：

adapter 不是完整模型，它是“要挂在某个 base model 上才能工作的增量部分”。

3. Merged model

有些团队会把：

base model
adapter

离线合并，得到一套新的完整权重。

这就是：

merged model

可以看这个说明文件：

06-merged-model

合并后的好处是：

线上加载简单
推理服务不用额外处理 adapter

代价是：

文件重新变大
失去“一套 base model + 多个小 adapter”这种灵活性

4. Runtime package

很多人以为部署时就是把训练产物原封不动扔上线。

这也不准确。

线上运行时往往还要再做一层打包或转换，例如：

为 vLLM 准备目录
为 TensorRT-LLM 准备 engine
为 GGUF 生态导出量化文件

你可以看这个示例：

runtime-manifest.yaml

它强调的一个关键边界是：

训练恢复用文件不一定进线上
线上真正要的是“可加载、可推理、可观测”的最小必需集

第十章：为什么训练产物、部署产物、推理引擎产物经常不是同一套东西

这是平台设计时必须明确的一层分层。

训练产物

关注的是：

能继续训练
能恢复实验
能复现实验

所以会包含：

optimizer state
scheduler state
rng state
trainer state

部署产物

关注的是：

可稳定加载
可稳定回答
版本可追踪

因此往往只需要：

model weights
tokenizer
generation config
必要元数据

推理引擎产物

关注的是：

吞吐
延迟
显存
特定后端兼容性

所以可能还会进一步做：

量化
图优化
分片布局调整
引擎序列化

这就是为什么你会在企业里同时看到：

原始 checkpoint
adapter 目录
merged model
awq / gptq / gguf / tensorRT engine

它们不是重复，而是服务不同阶段。

第十一章：模型为什么会“加载失败”或“行为不对”，很多时候不是权重问题

这是非常实战的一章。

很多人一出问题，就说：

模型坏了

其实很多时候坏的不是权重，而是配套文件和边界关系。

常见问题 1：Tokenizer 不匹配

症状可能包括：

输出乱码
特殊 token 异常
终止条件不对
评测结果离谱

根因常常是：

base model 和 tokenizer 不是同一版本
special_tokens_map.json 错了
chat_template 变了

常见问题 2：Adapter 和 base model 不匹配

症状可能包括：

加载时报 shape mismatch
能加载但回答很怪
推理结果退化明显

根因通常是：

adapter 是基于另一版 base model 训练的
target modules 不一致
合并时版本搞错了

常见问题 3：Checkpoint 能恢复训练，但不能直接上线

因为 checkpoint 面向的是：

继续训练

而线上更关心：

简化后的可部署产物

如果你把一堆中间 checkpoint 直接当线上模型管理，通常会很乱：

体积大
文件多
语义不清
生命周期不清

常见问题 4：Loss 下降了，但回答没有变好

这是很多训练任务最坑的一类问题。

原因可能包括：

训练样本过于模板化
评测集泄漏
只学会了表面格式
业务目标和 loss 不一致

所以专家不会只看：

train loss

还会看：

eval loss
人工评测
任务准确率
拒答通过率
幻觉率
线上反馈

常见问题 5：SFT 后模型“更听话了”，但基础能力下降

这可能是：

训练数据过窄
学习率过大
训练步数过多
发生灾难性遗忘

所以微调不是：

数据越多越好
轮数越多越好

而是要控制：

数据分布
学习率
训练强度
评测覆盖面

第十二章：模型注册、版本管理和血缘，为什么是企业里真正的大头

当你只有一个模型文件时，你会觉得：

模型管理很简单

一旦进入真实公司，很快就会出现：

多个 base model
多个 adapter
多个数据版本
多次训练运行
多套评测结果
多种部署形态

这时候如果没有 registry，几乎一定出事。

模型 registry 至少要记录什么

至少要有这些维度：

模型是谁训练的
基于哪个 base model
用了哪个数据版本
用了哪版训练代码
训练参数是什么
评测结果如何
安全扫描是否通过
当前处于什么阶段

你可以看这个示例：

model-version.yaml

为什么血缘 lineage 这么重要

因为一旦线上出问题，你必须能反查：

这版模型来自哪个 run
这个 run 用了哪版数据
数据是否有问题
训练代码是哪次提交
是否换过 tokenizer
是否做过量化

没有血缘，你只能靠猜。

这在企业里是不可接受的。

专家视角下，模型版本绝不是一个“文件名”

模型版本其实是一条链：

base model
  + dataset version
  + training code commit
  + hyperparameters
  + evaluation report
  + approval status
  = 一个真正可追踪的模型版本

所以“模型管理”不是把 model.safetensors 丢到对象存储里就结束了。

第十三章：你必须能把一条训练链路讲给别人听

如果你要成长为架构师或 CTO，这一段你应该能用自己的话完整复述出来：

我们先拿治理后的数据集，
按照 tokenizer 切成 token，
通过聊天模板组织成训练序列，
送入 Transformer 做前向计算，
基于目标 token 计算交叉熵损失，
再通过反向传播得到梯度，
由 AdamW 或类似优化器更新参数。

如果采用全量微调，就更新所有参数；
如果采用 LoRA，就冻结基础模型，仅更新低秩增量矩阵。

训练过程中会定期保存 checkpoint，
checkpoint 既包含模型侧状态，也常包含优化器、调度器和随机数状态，
目的是为了恢复训练和复现实验。

训练完成后，根据部署策略，
可以直接发布 adapter，
也可以把 adapter 和 base model 合并成 merged model，
再进一步转换为推理引擎所需的 runtime package。

最后，所有产物和评测结果都应该进入模型 registry，
与数据版本、代码版本和审批状态形成可追踪血缘。

如果你能把上面这段讲顺，而且能解释每个名词背后的边界，那你已经不再是“会跑命令的人”，而是开始具备平台和架构视角了。

第十四章：这一课最容易被记错的 10 个边界

最后我帮你把最容易混的地方再钉一遍。

训练目标不是“存知识条目”，而是“调整参数分布”。
token 不是字符，也不是单词，而是 tokenizer 定义的切分单元。
前向传播是算输出和 loss，反向传播是算梯度，优化器才负责更新参数。
gradient_checkpointing 是显存优化技巧，不是保存训练快照。
预训练主要学分布，SFT 主要学指令跟随和回答风格。
LoRA 不是完整模型，而是挂在 base model 上的增量权重。
checkpoint 是训练状态快照，不等于最终线上模型。
merged model 是部署选择，不是训练的唯一产物。
runtime package 面向推理引擎，不一定保留训练恢复所需文件。
模型版本不是一个权重文件名，而是一整条可追踪血缘。

本课配套样例

这一课建议你一定把样例目录也一起看掉：

建议你的阅读顺序是：

先读本课正文，建立概念图。
再打开样例目录，把每类产物的“磁盘形状”看一遍。
然后自己试着回答：checkpoint、adapter、merged model、runtime package 到底分别服务哪个阶段。

如果你能把这三步走通，你对“大模型训练到底产出什么”这件事的认知就真正立起来了。