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是什么为什么中文用户尤其要关注举个例子“大语言模型”这四个字在不同的分词器下可能被切成这样分词器切分结果Token数量按单个汉字切“大”“语”“言”“模”“型”5按词语切“大语言”“模型”2子词切分“大”“语言”“模型”3OpenAI的GPT系列用了BPEByte 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标签、乱码、广告文案、机器生成文本如果不洗模型会学到大量垃圾模式轻则浪费算力重则污染语义表示。我梳理了一套比较稳妥的清洗流程供参考按行做规则过滤去掉过短行、过长行、纯符号行、含有大量非法字符的行。做精确去重和模糊去重精确去重可以做哈希模糊去重可以用MinHash或SimHash把相似度高的段落踢掉。按文档粒度清洗只保留有价值的文档字段去掉页面导航、版权声明等噪音。预训练语料的领域配比也很关键网页、书籍、论文、代码的比例要设计好常见配置是网页类占比高、书籍和论文占比显著低但权重高代码占比取决于你想让模型擅长什么。如果你只是个人开发者大概率没有几千张卡做千亿模型的预训练但“预训练思维”依然有用你可以用开源基础模型领域数据做领域自适应预训练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-5LoRA可以用稍高一点。一条经典的SFT训练经验是观察训练loss的走势。正常情况下loss会迅速下降然后在一个平台区平稳。如果你发现验证集loss在某个时刻开始反弹说明过拟合已经出现应该立即停止训练回退到那个检查点。提示SFT的最终评估一定要用“模型没见过的指令”来测而不是训练集里的答案重述。最好准备一套与训练数据分布不同的“考试题”这些题不会参与训练。6. RLHF与RLAIF对齐的工程实现与简化路线如果说SFT是“让模型知道该怎么答”那RLHF就是“让模型知道什么答案是更好的”。这个阶段不再提供标准答案而是提供偏好比较对同一个问题有两个或更多答案告诉模型哪个更好。通过这种方式模型学到的是抽象偏好而不是具体内容。6.1 RLHF三件套RM训练、PPO、KL控制经典的RLHF流程分三步训练奖励模型Reward Model简称RM用强化学习(通常是PPO)优化策略模型在整个过程中加入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等轻量级路线对比RLAIFAI Feedback是把RM训练中的人工标注换成AI标注用另一个更强大的模型比如规模更大的LLM来比较两个回答哪个更好。这种做法大幅降低了数据成本缺点是强模型也可能有偏见且弱模型学到的偏好上限不会超过强模型太多。DPODirect 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插值让模型在微调时“看到”更长距离的位置关系。推理策略层面我建议把长文本做分区Chunking按语义切成小段分别检索只把最相关的段落填进Prompt而不是一股脑全塞进去。善用摘要压缩对长文档先生成摘要把摘要填入上下文完整原文放到外部存储按需再取。评估时一定要做“长文本压力测试”让模型读完一份长文档后回答位于中间位置的问题如果答错率很高不要慌换个位置编码方案或者改用RAG架构往往能缓解。我的一个实际经验是在长上下文场景下把“上下文窗口”当作产品参数宣传没问题但在算法选型时一定要把它当作一个“预算上限”而不是“建议使用量”。最稳的做法是让真实场景里的平均Prompt长度远低于模型的窗口上限留出充足的余量。8. 实操中踩过的坑与经验总结最后这部分我把这几年做LLM训练和微调时实际遇到的一些问题整理成一份“踩坑实录”没有放在前面是因为这些问题通常都在你跑通流程之后才会暴露。8.1 从PEFT到全参微调的临时清单如果你准备在自己的业务数据上微调一个开源模型我建议按下面这个顺序走先用一个小数据集几百条跑通训练流程确认数据格式、代码路径、显存占用都正确。再用LoRA做一轮小规模SFT实验观察loss下降趋势和生成效果这一步主要用来验证“数据是否有效”。如果LoRA效果好再考虑要不要做全参微调或继续加数据规模。在多个检查点做评测不要只看最终epoch的结果有时中间的检查点泛化更好。对齐阶段先用DPO跑一版确认偏好数据有效后再决定有没有必要上PPO这类复杂路线。这份清单的核心思想是“先小后大、先简后繁”。我见过太多人一上来就搞全参微调加大规模数据跑了两天发现数据格式有问题全部返工。小规模的快速验证能帮你把问题隔离在可控范围内。8.2 常见问题速查表现象大概率原因排查方向训练loss不下降学习率过大或过小、数据格式错误、梯度爆炸检查learning rate、查看输入mask是否正确、观察梯度范数验证集loss反弹过拟合减小epoch数、增大数据量、加正则化或早停模型回答越来越短SFT数据里短答案比例过高重新平衡数据长度分布模型什么都拒绝回答对齐过头、偏好数据里安全拒绝样本过多降低拒绝类样本比例、调整RLHF KL权重长文档中间内容答不上来上下文过长、注意力迷失切块检索、压缩摘要、换长上下文位置编码方案LoRA微调后效果反而变差数据分布与基座能力不匹配、学习率不合适降低学习率、增加高质量数据、用领域继续预训练过渡最后我再分享一条非常个人的体会整个大语言模型训练的链路里最难的不是模型结构不是loss公式而是对自己数据的理解。预训练、SFT、RLHF每一步都在修改模型在某个层面的行为但你的评测如果只看一两个指标很难定位到底是哪一步出了问题。我现在的习惯是给每个阶段都建一套独立的评测集SFT有自己的对齐有自己的长上下文有自己的。每一套评测集的通过标准都写清楚这样才能在模型出问题时快速定位归因。这个习惯比任何一条调参技巧都值钱。
