大语言模型训练全流程解析：从Token到SFT与RLHF的工程实践

1. 先建立整体坐标系：LLM的四大训练阶段与核心概念地图

聊大语言模型之前，我觉得最重要的事不是急着看某个公式或者某个库的API，而是先把整个训练流程的“地图”装进脑子里。很多人一上来就盯着“上下文窗口”“Token”这些名词逐个查，查完发现更懵了，因为它们之间不是孤立的关系，而是一条流水线上不同工位的产物。

我习惯把现代LLM的生命周期分成四个阶段：预训练、监督微调（SFT）、偏好对齐（RLHF/RLAIF）、以及部署期的上下文工程。预训练负责让模型“懂语言、懂世界”，SFT负责让模型“懂指令、懂对话”，偏好对齐负责让模型“懂审美、懂安全、懂人类偏好”，而上下文窗口这个属性更像是模型工作时的“内存大小”，它贯穿前三个阶段，又在部署阶段成为最需要精打细算的资源。

Token是模型读取文本的基本单位，Embedding是模型理解文本的第一层表示，上下文窗口是模型在一次推理中能“看到”的全部Token范围。这四个概念都在预训练阶段就定死了底子：词表决定了Token怎么切，Embedding维度决定了表示空间的容量，上下文窗口决定了注意力机制能覆盖多远。而SFT和RLHF则是在这套底子上做“行为塑形”。

所以这篇文章我打算按一条我能自洽的路线来讲：先讲Token和Embedding这两个最底层的表示问题，再讲预训练这个“量变产生质变”的阶段，然后用大量篇幅讲SFT和RLHF/RLAIF这两个大家平时接触最多、也最容易踩坑的阶段，最后单独聊上下文窗口在推理和工程上的那些事。适合刚接触LLM不久、想系统建立概念框架的开发者，也适合已经在用开源模型微调、但对底层原理还比较模糊的算法工程师。

1.1 为什么要把训练分成预训练、SFT、对齐三个阶段

一句话解释：预训练学的是“语言能力”，SFT学的是“行为方式”，对齐学的是“价值判断”。

预训练阶段用的是海量无标注文本，目标是让模型学会预测下一个Token。这个目标听起来简单，但它逼迫模型学会语法、事实知识、推理链条、跨句指代等大量隐含规律。你可以把预训练想象成一个小孩在海量书籍里泡了几年，他学会了语言，但你问他“帮我写一封请假邮件”，他不一定知道“邮件”是什么东西，更不知道该怎么回复你。

SFT阶段就是用一批“问答对”告诉模型：当人类给出这样的指令时，你应该给出这样的回答。这个阶段修正的是“行为模式”，不是“知识总量”。模型在预训练阶段已经知道怎么遣词造句，SFT只是把回答方式从“文本续写”变成“指令响应”。

RLHF/RLAIF阶段则更进一步，它不教模型具体怎么回答，而是教模型“什么是更好的回答”。偏好数据告诉模型，在几个候选回答中，人类更喜欢哪一个，模型通过这个信号学会举一反三：不仅仅是背下答案，而是理解“详细但不啰嗦”“承认错误”“拒绝不当请求”这类抽象偏好。

1.2 六个概念按什么顺序理解才不会乱

我建议按“表示层 → 学习层 → 对齐层 → 应用层”的顺序来理解：Token和Embedding是表示层，预训练是学习层，SFT和RLHF/RLAIF是对齐层，上下文窗口是横跨学习和应用两端的约束条件。

打个比方，预训练像是在“识字+博览群书”，SFT像是在“学社交礼仪”，RLHF像是在“建立价值观”，而上下文窗口是你办公桌上能摊开的纸张大小——纸越大，你能同时参考的材料越多，但你翻找资料的代价（注意力计算量）也越大。

2. Token：模型看到的最小文字单位

很多刚入门的朋友会以为模型是按“字”来读文本的，其实不是。对于中文来说，一个汉字在LLM的词表里不一定是一个独立Token，可能是半个字、一个词，也可能是几个字组合在一起。Token就是模型真正“看到”的最小文本单位，它决定了你的文本会被切分成多少段，也直接决定了两件事：API费用和模型能感知的文本长度。

2.1 Token是什么，为什么中文用户尤其要关注

举个例子，“大语言模型”这四个字，在不同的分词器下可能被切成这样：

OpenAI的GPT系列用了BPE（Byte Pair Encoding，字节对编码），会把常见词保留成完整Token，把生僻词拆成多个Token。中文在大模型词表里的“待遇”通常不如英文，因为中文常用字有几千个，而英文常用词只有几百个基础词根加上常见前缀后缀。很多中文Token在词表里对应的是两到三个字的词，生僻词甚至会被切成四五个Token，导致同一句话的中文Token数明显多于英文。

Token数为什么重要？第一，它直接决定了推理成本，绝大多数商业API按Token计费；第二，它决定了一个模型宣称的“上下文窗口”实际能装多少内容，如果中文Token效率低，那实际能装的中文字数就会缩水。所以做中文LLM应用的同学，一定要养成分词器自查的习惯，不要凭感觉估Token数。

2.2 BPE如何工作，以及词表设计背后的取舍

BPE的核心思路是“贪心合并”：先把文本拆成单字节级别的最小单元，然后统计相邻单元对的出现频率，把最高频的单元对合并成一个新单元，重复这个过程直到词表达到预设大小。

你不需要背实现细节，但要知道下面几点：

• 词表大小是预训练之前定死的超参数，常见的有32000、50000、100000等。词表越大，单个Token能表达的信息越丰富，但Embedding矩阵也越大，显存和训练成本随之上升。
• BPE切分有一个严重后果：同一个词在不同上下文中可能被切成不同的Token组合，因为BPE合并是贪心的，会优先匹配词表里最长的Token。这就是为什么“跟”“的”这类高频字与前后字组合时，切分结果不稳定。
• 用不同语料训练出来的BPE词表，对中文的支持度差异很大。有些开源模型在中文上表现好，一个重要原因就是它在预训练语料里加入了足够多的中文，BPE合并出了大量中文词Token。

实操建议：如果跑开源模型做微调，先用模型自带的tokenizer把一批真实业务数据统计一下Token数量分布。我见过不少项目，以为自己的语料只有几万条、每条几百字，结果算Token总量时发现比想象中多了两三倍，预算直接翻倍。

3. Embedding：把Token变成向量，但不等于“理解语义”

Embedding这个词听起来玄乎，其实它解决的是一个非常朴实的问题：模型没法直接处理文字，必须把Token变成一串数字。这串数字在模型看来就是一个高维向量，不同的Token对应不同的向量。

3.1 从映射表到分布表示

最简单的方案是one-hot编码：词表里有50000个Token，就用一个50000维的向量表示，当前Token的位置是1，其他位置是0。这种方案的问题很明显：维度爆炸且没有任何语义信息，“猫”和“狗”的两个向量完全正交，看不出任何相关性。

Embedding层做的事，本质上就是让模型在训练过程中自动学习一张“Token到向量”的映射表。刚初始化时，这张表里的向量是随机的，随着预训练不断推进，模型会不断调整这些向量，让语义相近的词在向量空间中靠得更近。关键是模型的深层网络会继续加工这些向量，Embedding只是第一层输入表示。

一个常见误解是“词向量相似=语义相似”。这个结论在传统Word2Vec时代比较明显，但在大模型时代要打折扣。LLM的Embedding经过多层变换后，每一层的语义表征已经高度上下文化——同一个词在不同句子里对应的语义向量是不同的，因为模型不是查表，而是根据上下文动态计算表示。

3.2 几个实操中容易误解的地方

第一，Embedding维度不是越高越好。主流开源模型的Embedding维度通常在2048到8192之间。维度越高，表示能力越强，但计算量和显存占用也越大。第二，微调模型时，Embedding层也会被更新，但它的更新通常不会太大。如果你用LoRA微调，很多人会忽略对Embedding层和LM Head（输出层）的适配，这其实会影响效果，尤其是指令遵循类任务。

第三，有个特别反直觉的现象：你在微调时对Embedding层做了大幅更新，模型在训练集上表现很好，但一到新数据就崩。原因是Embedding层被过度拟合到了训练数据里的表面词汇模式上。所以我的经验是，在SFT时对Embedding层设置较小的学习率，甚至冻结它，往往能让泛化更好。

4. 预训练：海量文本中的自监督学习

预训练是整个LLM能力的地基。这一阶段不依赖任何人工标注，只是让模型反复做一件事：给定前面所有的Token，预测下一个Token最可能是什么。听起来简单到有点无聊，但当训练数据达到万亿Token级别、模型参数达到千亿级别时，“预测下一个词”这个单一目标就逼着模型学会了语法、事实、常识、推理等极其丰富的能力。

4.1 预训练到底在学什么：next token prediction

你可能会问：预测下一个词怎么能学出推理能力？举个例子，如果模型在海量代码语料上学“if”，它得知道后面通常会跟条件表达式和冒号，这逼它理解代码语法；如果在科学论文里学“因此”，它得学会前后文的因果逻辑；如果在小说里学“她推开窗户”，它得理解动作主体、动作对象和场景关系。

模型经过多层Transformer的堆叠，每一层都在捕捉不同粒度的模式：浅层学词法和句法，中层学语义和指代，深层学抽象逻辑和长程依赖。这也解释了为什么模型规模越大，能力越强——更大的参数量、更深的网络，意味着它能记住并泛化更复杂的模式。

预训练阶段，loss曲线是一个很有参考价值的指标。经过充分的训练，模型在验证集上的loss通常能降到2.0~3.0之间。如果你用小规模数据做实验，loss数值会高一些，但核心要看的不是绝对值，而是下降趋势是否平稳。如果某个chunk的loss突然升高，再降下来，说明数据里有噪声或分布突变；如果loss整体不降，那大概率是学习率、数据混比或模型结构出了问题。

4.2 数据清洗、混合比例、以及在少量数据上跑小模型的经验

预训练数据的处理是一门硬功夫。原始数据里充满了重复段落、HTML标签、乱码、广告文案、机器生成文本，如果不洗，模型会学到大量垃圾模式，轻则浪费算力，重则污染语义表示。

我梳理了一套比较稳妥的清洗流程，供参考：

1. 按行做规则过滤：去掉过短行、过长行、纯符号行、含有大量非法字符的行。
2. 做精确去重和模糊去重：精确去重可以做哈希，模糊去重可以用MinHash或SimHash，把相似度高的段落踢掉。
3. 按文档粒度清洗：只保留有价值的文档字段，去掉页面导航、版权声明等噪音。
4. 预训练语料的领域配比也很关键：网页、书籍、论文、代码的比例要设计好，常见配置是网页类占比高、书籍和论文占比显著低但权重高，代码占比取决于你想让模型擅长什么。

如果你只是个人开发者，大概率没有几千张卡做千亿模型的预训练，但“预训练思维”依然有用：你可以用开源基础模型+领域数据做领域自适应预训练（Domain Adaptive Pretraining），用较小的学习率在领域语料上继续训练几步，让模型“熟悉”你所在领域的词汇和表达方式。这个操作放在SFT之前做，效果经常会让你惊喜。

5. SFT监督微调：把通用模型变成“会回答问题的助手”

预训练出来的模型就像一个读过万卷书的聪明人，但你不问他、他就不说话，你问了他，他可能会把答案写成一篇跑题的作文。SFT就是拿着大量“问题-标准答案”样例，告诉他：人类提问的时候，你要按这个格式回答。

5.1 SFT要解决什么问题

从技术实现上看，SFT就是在预训练模型基础上，用指令数据继续做有监督训练，优化目标依然是交叉熵loss。但和预训练不同的是，SFT只对回答部分计算loss，问题和系统提示词部分通常会被mask掉。

SFT真正解决的是“分布偏移”问题。预训练时模型见到的文本是互联网上自然存在的文本，而用户提问时是对话式的、命令式的，多个对话轮次之间还有衔接。如果不在这些对话数据上微调，模型根本不知道“现在该我说话了”这个边界在哪。

还有一点值得强调：SFT并不能给模型注入新的知识。它只是在调整模型的输出行为。模型不知道某个冷门事实，你就算拿一万条包含这个事实的问答对去微调，它也只是在背答案，遇到换个角度提问的新题照样答不上来。

5.2 构造一份高质量SFT数据的实际经验

这是所有做微调的人最关心的问题。我的建议可以浓缩成一句话：数据质量优先，多样性优先，数量锦上添花。

一份好的SFT数据应该具备：

• 指令清晰：每个问题都有明确的意图和约束条件，不要出现模棱两可的表述。
• 答案准确且风格统一：答案不是越长越好，该简洁就简洁，该详细就详细。
• 覆盖多轮对话：不仅要单轮问答，还要包含上下文依赖的多轮对话，模型才能学会“记住前面说过的话”。
• 难度梯度合理：从简单事实类问题，到需要推理、对比、总结的复杂问题，都要有。
• 候选数据要经过清洗：去掉有毒内容、错误内容、重复内容。一条坏数据的影响力远大于十条好数据。

用开源模型微调时，我的经验是epoch数不宜太多，一般1~3个epoch就够。SFT和预训练不同，数据量小、任务明确，反复多轮反而会让模型过拟合到训练集的模式上，表现就是“背答案”能力强，泛化能力下降。学习率也要比预训练低很多，比如全参微调用1e-5到2e-5，LoRA可以用稍高一点。

一条经典的SFT训练经验是观察训练loss的走势。正常情况下，loss会迅速下降，然后在一个平台区平稳。如果你发现验证集loss在某个时刻开始反弹，说明过拟合已经出现，应该立即停止训练，回退到那个检查点。

提示：SFT的最终评估一定要用“模型没见过的指令”来测，而不是训练集里的答案重述。最好准备一套与训练数据分布不同的“考试题”，这些题不会参与训练。

6. RLHF与RLAIF：对齐的工程实现与简化路线

如果说SFT是“让模型知道该怎么答”，那RLHF就是“让模型知道什么答案是更好的”。这个阶段不再提供标准答案，而是提供偏好比较：对同一个问题，有两个或更多答案，告诉模型哪个更好。通过这种方式，模型学到的是抽象偏好，而不是具体内容。

6.1 RLHF三件套：RM训练、PPO、KL控制

经典的RLHF流程分三步：

1. 训练奖励模型（Reward Model，简称RM）
2. 用强化学习(通常是PPO)优化策略模型
3. 在整个过程中加入KL散度约束，防止模型偏离原始能力太远

第一步需要构造偏好数据：一个提示词对应两个由SFT模型生成的回答，人工标注员判断哪个更好。RM模型的输入就是这段提示词+候选回答，输出一个标量分数。训练目标是让“更被偏好的回答”的分数高于另一个。

第二步是整个RLHF最复杂的环节。PPO算法中会有四个模型同时工作：被训练的Actor模型、提供参考分布的Reference模型、给回答打分的RM模型，以及一个评论家Critic模型。Actor生成回答，RM给回答打分，Critic预估优势值用于计算策略梯度，然后Actor更新参数。Reference模型的作用是计算KL散度，防止Actor跑偏。

第三步中KL散度的权重很关键。如果KL权重大，模型会更保守，对偏好的学习变慢；如果权重小，模型可能为了分数产生“奖励作弊”行为——生成高分数但人类根本不喜欢的回答，比如过分冗长、谄媚、堆砌关键词。

从工程角度看，RLHF最大的门槛是“不稳定”。PPO对超参数极其敏感，学习率、clip范围、batch大小、KL系数，任何一个波动都可能导致训练崩溃或奖励崩塌。我在调参时的经验是：先在很小的batch上跑通流程，确认loss和reward曲线形态正常，再放大训练规模，否则你会浪费大量算力在无效调试上。

6.2 RLAIF与DPO等轻量级路线对比

RLAIF（AI Feedback）是把RM训练中的人工标注换成AI标注：用另一个更强大的模型（比如规模更大的LLM）来比较两个回答哪个更好。这种做法大幅降低了数据成本，缺点是强模型也可能有偏见，且弱模型学到的偏好上限不会超过强模型太多。

DPO（Direct Preference Optimization）是比PPO轻量得多的对齐方法。它的核心洞察是：不需要显式训练一个RM再跑强化学习，而是直接从偏好数据中构造一个替代性损失函数，一步更新策略模型。DPO实现简单、训练稳定，对显存和工程复杂度也友好得多，所以目前很多开源社区的对齐工作已经在从PPO往DPO迁移。

我个人的经验是：如果你的数据规模不大（几万条以下）、算力有限，DPO是一个性价比极高的选择；如果你追求极致效果、有成熟的RL基础设施和充足算力，PPO的上限仍然更高。RLAIF则适合作为冷启动方案，先用AI标注生成一批偏好数据，再跑DPO，这条组合路径是目前很多小团队的实际选择。

不过无论走哪条路，评估都不能只看奖励分数。我每次做对齐实验都会同时做三件事：跑固定评测集看自动指标、人工抽测一批代表性提示词、检查模型在“对抗性提问”下的表现是否变差。对齐阶段最容易出现的副作用是“过于谨慎”——模型为了安全，什么都拒绝回答，这在很多业务场景里比回答错误更致命。

7. 上下文窗口：能记住多长，和怎么“记住”不是一回事

上下文窗口是很多人在选模型时最在意的数字：4K、8K、32K、128K、1M，看着越来越大。但这里有两个完全不同的维度：一个是模型在训练时见过的最大长度，另一个是模型在推理时能够处理并保持稳定性能的长度。这两个数字经常被混淆。

7.1 注意力机制与KV Cache的代价

Transformer的核心是注意力机制，它的计算量随序列长度的增加呈平方级增长。假设序列长度是n，模型计算注意力分数时要生成一个n×n的注意力矩阵，每个Token都要与其他所有Token做计算。所以长度从4096翻到8192，注意力计算量不是翻倍，而是翻了四倍。

为了不重复计算历史Token的注意力，推理时会用到KV Cache：把已经算好的Key和Value存下来，新的Token只需要用自己的Query去和历史KV做注意力计算。但KV Cache非常吃显存。一个7B模型，输入长度4096，单条请求的KV Cache可能就要占用约1GB显存。长度拉到32768，这个数字会成倍膨胀。

另外还有一个更隐蔽的问题：模型在超长上下文中会出现“注意力迷失”现象，也就是中间被忽略掉，模型只记得开头和结尾的内容，这被戏称为“lost in the middle”。这跟窗口大小本身无关，而是注意力机制对长距离依赖建模的固有问题。所以你不该指望模型对几万Token的上下文做到“逐字精读”。

7.2 处理长上下文的工程手段

解决长上下文问题，要从模型、数据、推理策略三个层面同时下手。

模型层面，常用手法是改进位置编码。比如RoPE旋转位置编码已经成了事实标准，而处理更长的上下文会用位置插值或NTK-aware插值，让模型在微调时“看到”更长距离的位置关系。

推理策略层面，我建议：

1. 把长文本做分区（Chunking），按语义切成小段分别检索，只把最相关的段落填进Prompt，而不是一股脑全塞进去。
2. 善用摘要压缩：对长文档先生成摘要，把摘要填入上下文，完整原文放到外部存储，按需再取。
3. 评估时一定要做“长文本压力测试”：让模型读完一份长文档后回答位于中间位置的问题，如果答错率很高，不要慌，换个位置编码方案或者改用RAG架构往往能缓解。

我的一个实际经验是：在长上下文场景下，把“上下文窗口”当作产品参数宣传没问题，但在算法选型时一定要把它当作一个“预算上限”而不是“建议使用量”。最稳的做法是，让真实场景里的平均Prompt长度远低于模型的窗口上限，留出充足的余量。

8. 实操中踩过的坑与经验总结

最后这部分，我把这几年做LLM训练和微调时实际遇到的一些问题，整理成一份“踩坑实录”，没有放在前面是因为这些问题通常都在你跑通流程之后才会暴露。

8.1 从PEFT到全参微调的临时清单

如果你准备在自己的业务数据上微调一个开源模型，我建议按下面这个顺序走：

1. 先用一个小数据集（几百条）跑通训练流程，确认数据格式、代码路径、显存占用都正确。
2. 再用LoRA做一轮小规模SFT实验，观察loss下降趋势和生成效果，这一步主要用来验证“数据是否有效”。
3. 如果LoRA效果好，再考虑要不要做全参微调或继续加数据规模。
4. 在多个检查点做评测，不要只看最终epoch的结果，有时中间的检查点泛化更好。
5. 对齐阶段先用DPO跑一版，确认偏好数据有效后，再决定有没有必要上PPO这类复杂路线。

这份清单的核心思想是“先小后大、先简后繁”。我见过太多人一上来就搞全参微调加大规模数据，跑了两天发现数据格式有问题，全部返工。小规模的快速验证能帮你把问题隔离在可控范围内。

8.2 常见问题速查表

最后我再分享一条非常个人的体会：整个大语言模型训练的链路里，最难的不是模型结构，不是loss公式，而是对自己数据的理解。预训练、SFT、RLHF每一步都在修改模型在某个层面的行为，但你的评测如果只看一两个指标，很难定位到底是哪一步出了问题。我现在的习惯是给每个阶段都建一套独立的评测集：SFT有自己的，对齐有自己的，长上下文有自己的。每一套评测集的通过标准都写清楚，这样才能在模型出问题时快速定位归因。这个习惯，比任何一条调参技巧都值钱。