孙秀龙最近被问得最多的一类问题，基本都集中在大模型预训练和微调这两个词上。很多人不理解预训练和微调到底是什么关系，也不清楚SFT、RLHF、LoRA这些概念之间有什么联系。这篇内容我整理成了问答版，把核心概念一个一个拆开讲，尽量做到说人话，不堆术语。
内容主线是这样安排的：先讲预训练阶段在做什么，再讲为什么需要微调，然后逐个拆解高频名词，最后给一套可以照着用的微调实操流程。适合刚接触大模型、准备做领域微调、或者正在面试前突击基础概念的人。
1. 预训练：大模型最基础的“通识教育”
1.1 预训练到底在训练什么
问：预训练这个过程，本质上是在做什么？
答：一句话，预训练就是让模型反复做“预测下一个词”的游戏。给你一段文本，比如“今天天气真”，模型要预测下一个词大概率是“好”“不错”“冷”还是别的什么。预测之后和真实文本对比，错了就调整参数，对了就保持。在几万亿个词上反复玩这个游戏，模型就把语言的规律记在了参数里。
这个“下一个词预测”任务，学术上叫自监督学习。它最大的优点是数据不需要人工标注，互联网上现成的文本直接拿来用就行。也正因为不需要标注，数据规模才能做到极大，这是后续一切能力的源头。
问：为什么预测下一个词，就能让模型学会那么多知识？
答：关键在于“压缩”。预测下一个词，模型必须理解上下文里隐含的语义关联。比如它要预测“北京是中国的____”，就需要把“北京”“中国”“首都”这些概念之间的关系编码进参数。说句实话，模型本身不产生知识，它只是把海量文本中反复出现的规律提炼出来，存在参数里。
我打个比方。预训练就像一个人读了海量书籍，他记住了语法、常识和大量事实，甚至能触类旁通，进行推理。但他没有看过具体的提问格式，也不知道别人希望他“回答问题”而不是“接句子”。预训练模型的表现形式，本质上还是“补全文本”。
1.2 数据规模与算力的现实账本
问：预训练需要多少数据？普通人有条件做吗？
答：直接回答：预训练的数据量级通常是数万亿token。一个token大约相当于0.7个汉字或者0.3个英文单词。数万亿token是什么概念？假设一部网络小说有几百万字，那需要几千万部小说的文本量。数据来源一般是网页抓取、书籍、论文、维基百科、代码仓库等。
算力方面，更大规模的预训练往往需要数千张高端GPU连续跑几个月。这不是个人开发者能承担的成本，甚至大部分公司都承担不起。所以行业里普遍的共识是：预训练责任在少数基座模型厂商，而绝大多数人接触的是微调。
问：那开源社区的基座模型是怎么回事？
答：开源社区常见的基座模型，是把预训练好的参数权重开放出来，供大家下载使用。这些模型已经具备很强的语言理解、推理和生成能力。普通人完全可以基于这些基座模型做微调，而不需要从零预训练。这也是为什么去年以来微调领域这么火的核心原因：基座能力已经足够强，我们只需要教它“干具体的活”。
1.3 预训练模型的能力边界
问：预训练模型已经很强了，为什么还要微调？
答：因为“能力强”和“听话”是两件事。
预训练模型的输出风格是“接着写”，而不是“回答问题”。你给它一句“请写一封请假邮件”，它可能真的会接着这句话往下写，而不是把它当成一条指令来执行。它还容易出现无关痛痒的废话、编造事实、立场偏移等问题。用行话说，叫“没有对齐”。
还有一个更实际的问题：预训练数据里，关于某个特定垂直领域的知识可能只占很小比例。比如医疗、法律、金融的专业术语和问答格式，预训练模型虽然知道一些，但回答的专业度和准确性往往达不到可用标准。
微调，就是把一个“通才”模型，定向培养成某个岗位上的“专才”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 微调：从“会说话”到“会办事”
2.1 为什么说微调是“定向培养”
问：微调到底改变了什么？
答：微调的本质，是在预训练模型的基础上，用特定格式的少量数据，让模型学习某种输入输出模式。它不是一个从零开始的学习过程，更像是在已有能力之上做“行为矫正”。
举一个场景例子：假设你想做一个电商客服助手。你需要准备大量“用户提问——客服回复”的数据对。微调之后，模型看到用户问“这个商品可以七天无理由退货吗”，就会按照你提供的客服风格给出回复，而不是像预训练模型那样回答“七天无理由退货政策因平台而异”。
很多人对微调有个误解，以为微调是在给模型“灌入新知识”。实际上，微调更多是在调整模型的输出习惯和格式。模型真正“学会新知识”的能力，远没有我们想象中那么强。如果想让模型知道一个全新的领域概念，更靠谱的办法是给它检索工具，或者在提示词里提供资料，而不是反复靠微调去记。
问：微调数据需要多少？
答：这要看任务复杂度。简单的指令遵循和格式调整，几千条高质量数据就够。如果是领域知识融合，几万到几十万条也不嫌多。现实是，数据质量和多样性比数量重要得多。我见过有人用一千条精挑细选的数据，效果比用十万条随抓取的数据好得多。
2.2 SFT与RLHF：先学说话，再学做人
问：经常听到SFT和RLHF，能解释一下吗？
答：SFT，全称是Supervised Fine-Tuning，中文叫监督微调。这是最基础的微调方式。你准备一批输入输出对，让模型模仿这些答案去学习。它的核心是把模型从“接续文本”的模式，转变成“回答问题”的模式。这是一切后续优化的地基。
RLHF，全称是Reinforcement Learning from Human Feedback，基于人类反馈的强化学习。这一步做的事情，是让模型的回答更符合人类偏好。简单说，SFT负责“让模型说人话”，RLHF负责“让模型说讨人喜欢的话”。
RLHF的传统流程分三步：先训练一个奖励模型，用来给模型的输出打分；再用强化学习算法调整策略，让模型输出的分数越来越高。不过近几年DPO方法越来越流行，它跳过奖励模型，直接用偏好数据做优化，工程上更简单，效果也比较稳定。
问：那什么时候用SFT，什么时候用RLHF？
答：我的经验是，如果你只需要解决“格式不正确、不按指令执行”的问题，SFT就够了。只有当模型回答的内容涉及主观偏好、安全边界、风格取舍时，才值得考虑RLHF或DPO。对于大多数垂直领域场景，SFT在前，RLHF在后，但很多团队做完SFT就已经满足需求了。
2.3 全参微调与参数高效微调
问：全参微调是怎么回事？
答：全参微调，就是在原有基座模型的所有参数上继续训练。以7B模型为例，大约有70亿个参数，每个参数需要一定的显存来存储梯度、优化器状态和中间激活值。全参微调对显存的要求极其夸张，单卡基本跑不动，至少需要多张高端GPU配合。
全参微调的优点是上限高，模型能学习到的行为调整更彻底。缺点是训练成本高、容易破坏预训练学到的通用能力。尤其在数据量不大时，全参微调很容易导致“灾难性遗忘”，也就是模型忘了自己原本会的东西，只会做你教的那点任务了。
问：那为什么现在主流都推LoRA？
答：因为LoRA这类参数高效微调方法，把成本降低了一个数量级。它不修改原始模型参数，而是为模型额外训练一小批低秩矩阵，推理时把两个矩阵的效果合并回原始权重。训练时只需要更新额外的小矩阵，显存占用显著下降，单张消费级显卡也能跑起来。更关键的是，由于原始参数没变，模型不容易遗忘原有能力。
用一句话总结：全参微调是“重新装修”，LoRA是“在墙上挂画”。
3. 核心概念速查：高频问题的详细答案
3.1 Token、词表与上下文窗口
问：Token到底怎么理解？
答：Token是模型处理文本的最小单位。它不等于“词”，也不等于“字”。模型内部把文本拆成Token序列，再转成向量。不同模型的分词策略不同，有的把“人工智能”拆成“人工”“智能”两个Token，有的拆成四个甚至更多。分词通常用BPE、WordPiece这类算法，目的是在词表大小和编码效率之间找平衡。
我举个直观的例子：一个中文Prompt“请写出高质量文章”，不同分词器可能产生6到10个Token。很多API是按Token计费的，所以控制Token数量就是控制成本。长文本场景里，一个词可能被拆成多个Token，响应速度也会慢一些。
问：词表大小一般是多少？
答：常见词表在3万到15万之间。中文模型的词表往往偏大，因为要把常用汉字和词都装进去。词表越大，每个词表达越精细，但模型层会变宽，训练和推理的参数量都会增加。
问：上下文窗口又是什么？
答：上下文窗口是模型一次能“看到”的最大Token数量。比如一个8K上下文窗口的模型，一次最多能处理约8000个Token，超出部分就会被截断或丢弃。很多实际场景的坑都出在这里：把几千页公司资料一次性塞进Prompt，结果后面内容根本没被模型看到。
这几年上下文窗口一直在变大，从2K、4K到32K、128K都有。但窗口大不代表效果好，长距离信息建模依然有挑战。工程上，我常用的思路是：长文档先做检索，把相关片段摘出来再丢给模型，而不是盲目堆长窗口。
3.2 学习率、轮次与过拟合
问：学习率在微调里怎么设置？
答：微调的学习率一般比预训练小很多。预训练常用1e-4到3e-4，微调则更推荐1e-5到5e-5。理由很简单：你已经站在预训练模型这个“巨人”的肩膀上，不希望更新太猛，把辛苦学到的能力冲掉。
我在实操中一般先用1e-5起步，观察loss曲线。如果loss下降太慢，就提到2e-5或3e-5；如果训练过程出现loss震荡，就降一点。LoRA微调因为只更新低秩矩阵，学习率可以稍微高一点，比如1e-4，但也得观察验证集表现。
问：Epoch是不是越大越好？
答：不是。Epoch指完整过几遍训练数据。微调数据通常不大，常见做法是跑3到5个epoch。跑太多轮，模型很容易把训练数据“背”下来，但对没见过的输入就不会举一反三了，这就是过拟合。
判断过拟合的方法很直观：看训练集loss和验证集loss的差距。训练集一直降、验证集反而上升，说明开始过拟合了，赶紧保存当前最好的checkpoint走人。我习惯在训练过程中每半个epoch保存一次权重，避免最后一步崩了没得选。
3.3 采样参数：temperature与top_p
问：temperature是温度吗？它控制什么？
答：翻译成“温度”容易误解，它其实是控制生成随机性的参数。temperature越高，采样越随机，输出越发散；temperature越低，模型总是倾向于最高概率的Token，输出越保守、越稳定。范围一般是0到2。
实际经验是：做代码生成、数学题解、事实问答，temperature设在0.1到0.3之间；做创意写作、头脑风暴、文案拓展，可以调到0.7到1.0。再强调一次：不要试图用temperature来提升回答的“质量”，它控制的是“确定性”和“多样性”之间的取舍。
问：top_p和temperature配合使用吗？
答：top_p控制的是候选Token的累积概率范围。比如top_p=0.9，表示只从累积概率达到90%的最小候选集中采样。它和temperature不冲突，很多框架推荐两者组合使用。通常的做法是固定一个，调整另一个。比如temperature设为0.7，top_p设为0.9。如果两个指标都调得很低，输出会几乎确定，失去了生成类任务的意义。
3.4 Checkpoint与推理阶段
问：微调之后为什么还要合并checkpoint？
答：LoRA训练完，得到的是一个小体积的适配器权重，需要和基座模型合并，或者推理框架加载两个权重。很多框架只在加载时同时加载LoRA权重，不需要物理合并。但如果你想部署成单文件、用原生推理引擎提升速度，就需要把LoRA权重合入基座模型。
合并过程本身不神秘，就是做一次矩阵加法。一旦合并，LoRA权重就无法单独分离了，所以合并前要注意保留原始LoRA权重备份，方便后续继续调整。
问：微调后的模型推理时还需要做什么？
答：看看采样参数。微调时如果用了特定格式的指令模板，推理时也要用同样的模板，否则模型走样。我曾经犯过错误，训练时模板是“用户问：...助手答：...”，推理时图省事直接输入一句话，结果模型输出格式完全不对。保持模板一致性，是微调推理环节最容易忽略但极其关键的细节。
4. 主流微调方法对比：LoRA、QLoRA与提示微调
4.1 LoRA的原理：低秩分解
问：LoRA凭什么能用小参数完成微调？
答：LoRA的出发点是：预训练模型在微调过程中的参数变化，往往具有低秩特性。也就是说，真正有效的更新，可以用一个很小的矩阵来近似。于是LoRA冻结原始权重，并额外插入两个低秩矩阵A和B。原始权重不更新，只更新A和B，参数量大幅下降。
具体来说，如果模型某个线性层输出维度是4096，LoRA的秩r设为16，那么新增参数量约等于4096乘16乘以2，约13万。相对原来几千万的参数，几乎可以忽略。后文涉及的r是核心超参数，r越大，可学习的参数越多，表达能力越强，但过拟合风险也相应增加。
4.2 QLoRA：把量化与LoRA结合
问：QLoRA又是什么意思？
答：QLoRA是量化版LoRA。它先把基座模型量化为4-bit精度加载进显存，再用LoRA方式微调。4-bit量化后，7B模型的权重显存从约14GB降到约4GB，训练时加上梯度和优化器，一张24GB显存的卡也能跑13B模型的微调。
量化听起来很玄，但实际上它就是减少每个参数存储位数的技术。精度从16bit降到4bit，存储降为四分之一，但带来了量化误差。QLoRA的做法是感知量化，尽量把误差控制在小范围内。实际测试中，QLoRA微调后的效果和全精度LoRA差距很小，性价比极高。
4.3 P-Tuning与提示微调
问：提示微调和LoRA有什么区别？
答：提示微调不改变模型权重，只在输入序列前面加一段可学习的“软提示”向量。模型看到这些新增的连续向量后，行为会发生偏移。它可以理解为用连续的“隐式提示词”来引导模型。
P-Tuning v2是这类方法的代表。它比LoRA更省显存，因为连低秩矩阵都不需要训练，只训练少量前缀向量。但它也有明显局限：对复杂任务的适应能力不如LoRA。我的建议是，如果你只是为了固定风格、简单任务，提示微调够用；要真正提升任务的准确率和多样性，还是LoRA更稳妥。
做一个横向对比：
| 方法 | 可学习参数量 | 显存占用 | 效果上限 | 适用场景 |
|---|---|---|---|---|
| 全参微调 | 全部参数 | 极高 | 最高 | 数据量大、算力充足 |
| LoRA | 约0.1%-1% | 较低 | 接近全参 | 大多数垂直场景 |
| QLoRA | 约0.1%-1% | 极低 | 接近LoRA | 单卡微调大模型 |
| P-Tuning v2 | 极少量前缀 | 最低 | 比LoRA略低 | 风格迁移、简单任务 |
5. 实操复盘：做一次7B模型的领域微调
5.1 基座选择与显存规划
问：第一次做微调，基座模型怎么选？
答：我的建议是先选7B规模，别贪大。7B模型在消费级显卡上跑QLoRA是可行的，13B更勉强，33B以上基本需要多卡。在动手之前，先算好显存账：以LoRA训练为例，显存占用大约等于“基座模型权重 + 优化器状态 + 梯度 + 激活值”。QLoRA把权重压缩到4-bit以后，7B模型的权重部分只要约4GB，剩余空间留给中间过程，24GB显存比较从容。
如果你只有12GB左右的显存，也还有选择：用更小的3B或4B模型，或者减少batch size。batch size小会让训练不稳定，可以配合梯度累积，间接扩大batch size，又不会增加显存压力。
5.2 数据准备与格式规范
问：数据要整理成什么格式？
答：最常用的是对话格式。每一条数据包含system、user、assistant三个字段。system是系统设定，比如“你是一名专业的技术文档工程师”；user是用户问题；assistant是标准答案。训练时，这些字段会被拼成一段带特殊分隔符的文本，模型只对assistant部分的Token计算loss。
数据质量检查，我只信一个笨办法：把数据挑几十条打印出来，人眼逐条看。模型能学到的上限不会超过数据质量的上限。数据里有错别字、错误逻辑、格式混乱，模型都会学过去。真实项目里，花在清洗数据上的时间通常远大于训练时间。
5.3 训练过程与超参数参考
问：训练时的核心参数有哪些？
答：我习惯用这样一组初始参数：LoRA秩r=8或16，学习率2e-4（LoRA常用），batch size按显存能容纳的最大值设定，配合梯度累积让有效batch size达到32或64。epoch跑3轮。warmup步数设成总步数的5%-10%，让学习率先小步增长再逐步下降。
命令行训练示例：
bash复制python train.py \
--model_name_or_path /data/base_model \
--dataset_path /data/train.jsonl \
--lora_rank 16 \
--learning_rate 2e-4 \
--num_train_epochs 3 \
--per_device_train_batch_size 4 \
--gradient_accumulation_steps 8 \
--save_strategy epoch \
--output_dir /data/output_lora
训练过程中最值得关注的是loss曲线。正常情况，loss会从几十缓慢下降，最后稳定在一个低位。如果loss一开始就非常低（比如0.1以下），可能指数据格式有误，模型在背模板而不是学习内容。如果loss迟迟不降，要考虑学习率是否过小、数据是否质量太差。
5.4 翻车记录与排查手册
问：训练和推理阶段最容易翻车的地方在哪儿？
答：第一个高频问题是显存OOM（Out of Memory）。训练中途报OOM，最常见的原因是句子太长，导致激活值暴涨。解决办法包括减小batch size、开启gradient checkpoints、或者限制最大输入长度。我会优先检查数据里是否有个别超长文本，把它截断或过滤掉。
第二个问题是推理效果“看似好但格式不对”。训练时加了指令模板，推理时忘了加，输出就是一团乱。更隐蔽的是模板里多了空格或换行，导致模型没能识别出角色分隔符。这类问题排查主要靠肉眼对比训练和推理时的输入文本，一字一字对。
第三个问题是效果差得离谱，loss却正常下降。原因基本都在数据。把几十条训练数据拿出来自己问一遍，看看是否逻辑一致、答案是否完整。还有一种常见情况是问题重复度高、答案覆盖度窄，模型被迫“死记硬背”，泛化自然无从谈起。
第四个问题，关于中文内容，注意分词与特殊Token的冲突。某些基座模型在分词阶段会把连续数字、URL、代码块当成多个Token，如果训练数据的特殊符号格式和基座模型分词不匹配，会让loss异常偏高。这时候最粗暴但也最有效的办法，是统一数据清洗时的标点符号和格式。
问：有没有必要做RLHF？
答：阶段上做，但先确认是否真有必要。很多垂直场景只要SFT，输出质量就已经达到线上可用标准。RLHF适合追求回答风格稳定、偏好对齐的场景。如果你想试试DPO，我建议在SFT完成、且数据质量足够好的基础上再做，因为DPO对初始策略的依赖很强，SFT做不好，DPO也救不回来。
6. 从概念到落地的最后一块拼图
我个人在实际操作中的体会是，大多数人卡住的地方不在模型原理，而在对“数据”和“格式”的敏感度。你不需要把Transformer结构的每个矩阵都推导一遍，但你必须清楚：模型吃的是什么文本，期望吐出什么文本，两者之间用什么样的指令模板衔接。
关于踩坑，我最想强调的就是那个格式问题。曾经有一个7B基座微调项目，训练时用的模板里加了几个空格，推理时我把空格删掉了。结果模型回答的质量明显下降，一度以为参数没调好。后来逐行对比输入才知道，模型对这种细节敏感得近乎苛刻。所以建议所有做微调的人，把“训练模板等于推理模板”这句话贴在屏幕上。
后续可以扩展的方向是：把准确率指标化、做多轮对话的上下文管理、接入检索增强让模型随时查知识库、用DPO做一轮偏好优化，甚至尝试把多个LoRA适配器做动态路由组合。每一步都不难，但每一步都建立在对预训练和微调基础概念的清晰理解之上。
这篇稿子没有讲太深的理论推导，目的就是让刚入门的同学先把骨架立起来。等基础概念通了，再去看那些偏数学的论文，你会有完全不一样的感受。