训练一个自己的7B模型这个想法听起来很唬人但拆开看就是一条被很多人验证过的固定流程。先说结论从零造这个说法有歧义真正从随机权重开始预训练一个7B光算力成本就是几百万人民币的量级这不是个人或小团队能碰的。我这里讲的从零是指从开源基座权重出发把数据、继续预训练、微调、对齐、量化、部署这一整条链路完整走一遍最终得到一个能上线服务业务、甚至能商用的大模型。这个路径是现实可行的也是目前绝大多数中小企业、科研团队、独立开发者真正在用的方案。这篇文章我会把这条路拆成八个环节来讲每个环节都给出可以直接照抄的操作步骤、参数配置和排坑经验。适合谁看准备在业务里落地大模型的技术负责人、想自己训练领域模型的算法工程师、以及那些对如何造模型有完整好奇心、想搞清楚大模型流水线到底长什么样的朋友。整篇文章没有那种调一下API就完了的玄幻描述全是实打实的训练日志和工程决策你照着走一遍就能拥有一个属于自己、可部署、可迭代的7B模型。1. 方案选型与整体路径设计1.1 先算清楚算力账为什么选基座领域定制先说算力。业界有个经验公式一个Transformer模型前向加反向的计算量大约等于 6 × 参数量 × 训练token数。7B模型参数量约70亿就算只训练5000亿token这已经是很节俭的规模也要 6 × 7e9 × 5e11 ≈ 2.1e22 FLOPs。拿一张H100的FP8算力约2000 TFLOPS来折算而且要打个五折因为实际利用率到不了理论峰值单卡得跑将近6000天。哪怕集齐64张H100也要跑3个月光是电费和机器折旧就是天文数字。所以从零预训练这条线绝大多数团队都走不通。但换一个思路就完全不一样了基座模型已经在大规模通用语料上预训练过了你只需要在这个底座上继续喂领域数据、做监督微调和对齐训练量从5000亿token骤降到几十亿token甚至几亿token就够。这个成本是什么概念一张A100跑几天到两周或者四张4090跑一个周末就能完成一次高质量的领域微调。这就是站在巨人的肩膀上造自己的模型也是现在行业里几乎所有实际落地项目的标准做法。1.2 基座选型Qwen2.5-7B、Llama-3.1-8B、Mistral-7B如何选基座选型是整个链路里最重要、也最容易犯错的决策。我自己的评判标准有四条中文能力、上下文长度、生态友好度、以及周边工具链的成熟度。Qwen2.5-7B中文场景首选。阿里开源训练时中文数据占比很高词汇表对中文做了专门优化token效率高。Qwen2.5系列原生支持128K上下文虽然7B这个量级拉到128K会有些吃紧但32K内体验很好。社区生态非常丰富LLaMA-Factory、vLLM、ollama全都把Qwen列为头等公民踩坑少很适合作为第一条路径的基座。Llama-3.1-8B英文和代码能力强但中文字表覆盖弱中文场景直接用它需要大量中文语料补课而且词汇表里中文token切分效率低同样的中文内容Llama要消耗更多token。除非你的业务是纯英文或纯代码否则中文场景我不推荐拿它当第一选择。Mistral-7B欧洲团队出品推理效率做得好但中文表现不如Qwen生态也比不上Llama和Qwen的规模。我个人最终选了Qwen2.5-7B-Instruct作为基础底座。注意我选的是Instruct版带对话能力不是base版。原因是后续做领域微调时Instruct版已经具备较强的问答和指令遵循能力我再叠加领域知识和特定任务格式的数据即可训练收敛更快效果也更稳。如果你是从base版开始调相当于还得自己教它学会基本对话格式多走一段弯路。1.3 全链路规划从数据到部署的八个环节整个路径我拆成了八个环节后续章节逐一展开数据工程、继续预训练、SFT监督微调、DPO对齐、评测迭代、量化压缩、推理部署、以及最后的蒸馏扩展。这里先给一张总览表帮你建立全局观。环节核心工具/框架主要产物关键风险数据工程Python、Spark、LLaMA-Factory的dataset模板清洗后的训练集数据质量差导致训练白做继续预训练DeepSpeed、Transformers领域增强的基座权重loss spike、灾难性遗忘SFT监督微调LLaMA-Factory、ms-swift具备指令跟随能力的模型过拟合、格式崩坏DPO对齐TRL、LLaMA-Factory对齐后的模型奖励黑客、训练不稳定评测迭代C-Eval、MMLU、人工评估集评估报告迭代方向benchmark过拟合量化压缩AWQ、GPTQ、llama.cpp4bit量化后的GGUF/AWQ模型精度损失过大推理部署vLLM、Ollama、TGI可对外服务的API显存管理不当导致OOM蒸馏可选小模型蒸馏脚本更小体量的轻量模型蒸馏后能力丢失2. 数据工程这个环节决定生死2.1 数据从哪来开源语料、业务日志、合成数据三分法很多初学者上来就问训练数据在哪个网站下载这是没想清楚数据形态的问题。真实项目里数据来源基本是三分法开源语料、自有业务数据、合成数据。开源语料是大头用来保持和扩展模型的通用能力与领域基础。中文场景常用的有跃问的WuDaoCorpora、智源的Wanjuan、TigerBot的预训练数据、以及HuggingFace上各种filtered中文语料。注意直接拿原始下载包就用是大忌必须先做清洗——这是所有踩过坑的人的第一条血泪教训。我在实际项目里对开源语料做的第一件事永远是去重MinHash去重第二件事是语言识别过滤去除机器翻译味太重的段落第三件事是做质量打分用perplexity或分类器打分排序砍掉低质量尾巴。自有业务数据是真正的护城河。比如你做的是医疗AI你手里的病历、医患对话、临床指南这些是任何开源语料里都找不到的稀缺资源。但是业务数据往往脏、乱、带着大量隐私信息必须做脱敏和格式规整。我会把每一份业务数据都转成统一的Schema做清洗比如把JSON里的嵌套结构拉平、把乱码符号剔除、把重复段落按simhash去重。脱敏这里多说一句人名、身份证号、手机号、地址必须用正则实体识别双重清洗这个环节出了问题后面模型上线就是合规事故。合成数据这两年越来越重要尤其是当你需要拟人化的问答对时。常用套路是拿通用大模型领域资料生成种子问答然后人工抽检修正。比如我有一个领域知识切片→生成问题→生成答案→人工打分的流水线生成的数据只保留4分以上的样本5分制。注意合成数据一定要做强负样本过滤否则模型会学到大量看起来像那么回事但全是幻觉的回答模式。2.2 数据清洗的五个实操步骤我每次拿到新数据集都会按下面五步走顺序不能乱格式规整全角转半角、统一换行符、去除控制字符、修复截断的HTML/JSON。语言过滤用fastText的lid.176模型做语言识别按业务需要筛出中文/英文/代码丢掉混合识别结果置信度低于0.9的段落。去重Minhash LSH做近似去重simhash做语义级别去重。预训练语料的重复率往往超过20%去重后能明显降低后续训练loss震荡的概率。质量打分用规则小模型打分。规则包括长度阈值、标点符号密度、乱码比例小模型可以直接拿一个通用的文本质量分类器比如基于BERT的分数模型也可以拿目标基座给文本算perplexityperplexity过高的一律不要。隐私与安全过滤正则清洗证件号、手机号等关键词表过滤违规内容再做一轮人工抽检抽检比例不低于1%。2.3 tokenizer是否要扩展这是一个很少被讲透的问题做领域模型时有一个非常隐蔽但影响巨大的决策点tokenizer要不要动我自己做过对比实验。在某个法律领域的项目里基座用的是Qwen2.5-7B原始中文词表对通用中文支持得已经很好但遇到大量的法条编号、当事人姓名很多生僻字、案由专业词汇时token化效率明显下降。表现形式就是相同内容文本经过tokenizer后序列长度比正常文本多出20%~30%。序列变长直接导致训练变慢、上下文窗口浪费、以及模型对低频token的学习不充分。所以这里有两个选择。第一个选择是扩展tokenizer把领域词表比如几万个法律高频词加进原词表重新初始化这些新token的embedding和lm_head然后做一次embedding热身训练。这个方案效果好但工程复杂度高你得处理embedding维度扩展带来的权重文件变化很多下游工具链会出兼容问题。第二个选择是不动tokenizer接受一定的序列膨胀靠增加max_length上限来兜底。这个方案简单稳妥大多数场景够用。我的建议除非领域术语导致的token膨胀真的影响到了训练效率和效果否则不要动tokenizer。动了tokenizer就意味着你后面所有的微调、对齐、部署都要带着这套定制词表走生态兼容性会大打折扣。性价比最高的做法是在第一轮评测里对比几个高频领域样本的token数如果能接受就按不动处理确实膨胀严重再考虑扩展。3. 继续预训练把领域知识灌进去3.1 继续预训练与SFT的分工先理清一个概念继续预训练Continue Pretraining也叫领域预训练和SFT是两件事。继续预训练是用大规模无标注的领域文本让模型在底层学更多领域知识、词汇、句式SFT是用有标注的指令-回答对教模型学会按人类期望的方式回答问题。为什么需要继续预训练因为开源基座是在通用语料上训练的它可能连你领域的专有名词、缩写、行话都不认识。比如在工业制造场景下设备型号、工艺参数名词、报警代码这些在通用语料里非常稀疏。如果你不喂上下文直接上SFT模型就是在一堆它不认识的名词上硬记映射效果非常差幻觉率会很高。继续预训练的数据格式很简单纯文本段落一篇文章一条不需要标注。因为目标只有一项——用自回归的方式预测下一个token让模型在领域数据上做next-token prediction损失函数和预训练一致。3.2 超参设置与训练稳定性控制继续预训练的超参和从零预训练、和SFT都不一样。我给出我跑过多次、稳定可靠的配置记住这几组数字可以少踩很多坑学习率2e-5 ~ 5e-5。这个量级远低于从零预训练1e-4量级因为基座已经不是随机初始化过大的学习率会破坏原有权重出现灾难性遗忘。Batch size尽量大但要匹配显存。我习惯用梯度累积把有效batch size撑到128个样本或以上保证梯度稳定。序列长度4096起步。领域文本往往有长程依赖序列太短学不到上下文。训练步数不要机械地用epoch来算而是按数据量估算。领域继续预训练通常跑1~3个epoch。数据量太大就抽样子集数据量小就重复几轮。我自己实践的体量参考10亿~50亿token的领域语料在7B模型上跑一轮效果和成本比较均衡。混合精度bf16不要用fp16。fp16在训练时经常出现loss溢出和精度下溢的问题bf16的指数位更宽训练更稳。优化器AdamWbeta10.9beta20.95weight_decay0.1。学习率调度用cosine衰减前500~1000步warmup。下面是DeepSpeed ZeRO-3 bf16的配置片段我的惯用模板# ds_config.json { train_batch_size: 128, gradient_accumulation_steps: 8, zero_optimization: { stage: 3, offload_optimizer: { device: cpu, pin_memory: true }, overlap_comm: true, contiguous_gradients: true }, bf16: { enabled: true }, gradient_clipping: 1.0, steps_per_print: 50 }训练启动命令长这样deepspeed --num_gpus8 \ src/train_continue_pretrain.py \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --dataset_dir data/domain_pretrain \ --output_dir output/continue_pretrain \ --deepspeed ds_config.json \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 3e-5 \ --num_train_epochs 1 \ --max_length 4096 \ --bf16 True \ --logging_steps 10 \ --save_steps 500训练过程中我需要盯几个关键指标训练loss是否在缓慢下降、验证集loss是否同步下降、有没有loss spike。如果出现loss突然暴涨比如从2.0跳到5.0大概率是数据里有脏样本或学习率过高我会先停训练检查最近一个batch的数据再决定是降学习率还是清理数据。3.3 灾难性遗忘怎么防继续预训练最常见的问题就是灾难性遗忘——模型在领域数据上loss降得漂亮但通用能力一测就崩C-Eval分数大幅下滑。防遗忘这件事没有银弹但有几个非常有效的实操手段通用语料混入不要让模型只吃领域数据。我通常按领域数据:通用数据 4:1的比例混合保证模型不会把通用知识忘光。这个比例可以根据领域特殊性微调但通用数据占比不要低于10%。降低学习率继续预训练的学习率设置比SFT还要保守。如果SFT用2e-5那继续预训练我一般用1e-5~2e-5宁慢勿快。检查点对比训练过程中定期在固定评测集上跑通用benchmark比如C-Eval、MMLU的子集画一条领域loss vs 通用分数的曲线找到拐点。一旦发现通用分数持续下滑立即停止训练回滚到之前效果最好的检查点。Rehearsal在训练数据中始终混入一部分通用数据做复习让模型保持对通用知识的记忆。4. SFT监督微调教它学会说话和办事4.1 SFT数据怎么构造过了继续预训练模型有了领域知识但还没学会按用户的指令回答问题。SFT就是解决这个问题的。SFT数据的核心是一个个三元组system、instruction/user、response。在实际构造时我建议把所有样本统一成一套模板方便训练和后续解析。以Qwen2.5为例它的chat template长这样|im_start|system 你是一个专业的法律助手精通中国法律法规。|im_end| |im_start|user 请问以下合同条款是否违反劳动法条款内容...|im_end| |im_start|assistant 根据《劳动合同法》相关规定该条款存在以下问题...|im_end|数据量用多少很多教程会说越大越好这是误导。我做过的对比实验表明在质量有保证的前提下3千到2万条高质量SFT数据就能让7B模型在特定任务上达到非常好的效果而当你数据量涨到30万条但质量参差时效果反而可能更差——模型会被脏数据带偏学到错误的回答模式。所以SFT数据的核心策略是宁缺毋滥每条数据都要经过严格筛选。我在实际项目中通常会把SFT数据分为几个任务类型来构造指令遵循型完成具体任务比如总结这篇文章翻译下面这段话问答型领域知识问答改写/生成型把原文改写成指定风格多轮对话型带上下文的连续对话拒绝型对不合法、不合规、不知道的问题给出合理拒绝4.2 训练超参与关键技巧SFT的训练配置和继续预训练有差异我给出下面一套可复现的参数参数推荐值说明学习率1e-5 ~ 2e-5与继续预训练量级接近但不能太大epoch数2~3数据量小的时候可以适当增加序列长度4096要能覆盖较长的指令和回答LoRA rank64~128如果想用LoRA做轻量微调优化器AdamW与预训练一致调度器cosine同样带warmup关键技巧一loss要在response部分上算不在prompt部分算。也就是说训练时prompt部分对应的token位置其损失权重要置为0用ignore_index-100只让模型学习如何生成response。否则模型会浪费大量训练量去背你的prompt且学到错误的生成模式。在LLaMA-Factory里这个选项往往已经默认处理好但我见过很多自己写训练脚本的工程师踩这个坑。关键技巧二做格式稳定性训练。通俗讲就是让模型稳定地输出可解析的格式。如果你要让模型输出JSONSFT数据里就大量包含JSON格式的输入输出并且在评测时严格校验JSON可解析率。我自己会刻意把任务A-输出JSON和任务B-输出JSON设计成不同字段名的样本让模型学会从指令中领会字段含义而不是死记某一组字段名。关键技巧三使用LoRA还是全量微调我的经验是数据量小于5万条且算力有限LoRA训练更划算如果你有足够算力和数据量并且希望模型在领域上有更强的深度改造就上全量微调。LoRA的秩我一般设128alpha设为rank的两倍target_modules覆盖q_proj、k_proj、v_proj、o_proj、gate_proj、up_proj、down_proj。LoRA的好处是训练快、切换任务方便不同LoRA插拔坏处是某些工具链在导出和部署时对LoRA合并不够友好vLLM虽然支持LoRA但配置要比全量模型更细心。以LLaMA-Factory为例LoRA微调的配置长这样model_name_or_path: Qwen/Qwen2.5-7B-Instruct stage: sft finetuning_type: lora lora_rank: 128 lora_alpha: 256 dataset: domain_sft template: qwen cutoff_len: 4096 learning_rate: 2e-5 num_train_epochs: 3 lr_scheduler_type: cosine warmup_ratio: 0.1 bf16: true per_device_train_batch_size: 2 gradient_accumulation_steps: 84.3 微调后容易出的两个怪病第一个怪病是复读机现象模型回答永远以作为一个人工智能开头或者回答翻来覆去说同一句话。这通常是因为数据里存在大量安全对齐话术或某一类模板样本重复过多。解决方法是降低这类样本占比同时检查是否有重复样本没去重干净。第二个怪病是丧失拒绝能力你问什么它都顺着说哪怕问吃了过期的药怎么办它也给你编一套治疗建议。这往往是因为SFT数据里缺少拒绝型样本或者拒绝样本的措辞不够多样化。我的做法是构造一批该拒绝但模型容易答错的样本显式训练模型学会承认不知道、建议咨询专业人士。这类样本不在多每种拒绝场景放几十上百条就够了。5. DPO对齐让模型学会说人话5.1 为什么要做对齐SFT之后的模型可能表现得无所不知但仍然有大量问题生成内容不够体贴、不理解用户的真实意图、偏好表达生硬、甚至会说谎。对齐Alignment就是要把模型的输出从能用提升到好用。对齐的主流方法有RLHF基于人类反馈的强化学习和DPO直接偏好优化。RLHF需要先训练一个奖励模型再通过PPO算法优化策略模型整个流程工程复杂度高、训练不稳定7B量级做RLHF性价比很低。而DPO的思路非常优雅**直接在偏好数据上进 从零训练7B大模型：开源基座+领域微调，全流程实战指南
训练一个自己的7B模型这个想法听起来很唬人但拆开看就是一条被很多人验证过的固定流程。先说结论从零造这个说法有歧义真正从随机权重开始预训练一个7B光算力成本就是几百万人民币的量级这不是个人或小团队能碰的。我这里讲的从零是指从开源基座权重出发把数据、继续预训练、微调、对齐、量化、部署这一整条链路完整走一遍最终得到一个能上线服务业务、甚至能商用的大模型。这个路径是现实可行的也是目前绝大多数中小企业、科研团队、独立开发者真正在用的方案。这篇文章我会把这条路拆成八个环节来讲每个环节都给出可以直接照抄的操作步骤、参数配置和排坑经验。适合谁看准备在业务里落地大模型的技术负责人、想自己训练领域模型的算法工程师、以及那些对如何造模型有完整好奇心、想搞清楚大模型流水线到底长什么样的朋友。整篇文章没有那种调一下API就完了的玄幻描述全是实打实的训练日志和工程决策你照着走一遍就能拥有一个属于自己、可部署、可迭代的7B模型。1. 方案选型与整体路径设计1.1 先算清楚算力账为什么选基座领域定制先说算力。业界有个经验公式一个Transformer模型前向加反向的计算量大约等于 6 × 参数量 × 训练token数。7B模型参数量约70亿就算只训练5000亿token这已经是很节俭的规模也要 6 × 7e9 × 5e11 ≈ 2.1e22 FLOPs。拿一张H100的FP8算力约2000 TFLOPS来折算而且要打个五折因为实际利用率到不了理论峰值单卡得跑将近6000天。哪怕集齐64张H100也要跑3个月光是电费和机器折旧就是天文数字。所以从零预训练这条线绝大多数团队都走不通。但换一个思路就完全不一样了基座模型已经在大规模通用语料上预训练过了你只需要在这个底座上继续喂领域数据、做监督微调和对齐训练量从5000亿token骤降到几十亿token甚至几亿token就够。这个成本是什么概念一张A100跑几天到两周或者四张4090跑一个周末就能完成一次高质量的领域微调。这就是站在巨人的肩膀上造自己的模型也是现在行业里几乎所有实际落地项目的标准做法。1.2 基座选型Qwen2.5-7B、Llama-3.1-8B、Mistral-7B如何选基座选型是整个链路里最重要、也最容易犯错的决策。我自己的评判标准有四条中文能力、上下文长度、生态友好度、以及周边工具链的成熟度。Qwen2.5-7B中文场景首选。阿里开源训练时中文数据占比很高词汇表对中文做了专门优化token效率高。Qwen2.5系列原生支持128K上下文虽然7B这个量级拉到128K会有些吃紧但32K内体验很好。社区生态非常丰富LLaMA-Factory、vLLM、ollama全都把Qwen列为头等公民踩坑少很适合作为第一条路径的基座。Llama-3.1-8B英文和代码能力强但中文字表覆盖弱中文场景直接用它需要大量中文语料补课而且词汇表里中文token切分效率低同样的中文内容Llama要消耗更多token。除非你的业务是纯英文或纯代码否则中文场景我不推荐拿它当第一选择。Mistral-7B欧洲团队出品推理效率做得好但中文表现不如Qwen生态也比不上Llama和Qwen的规模。我个人最终选了Qwen2.5-7B-Instruct作为基础底座。注意我选的是Instruct版带对话能力不是base版。原因是后续做领域微调时Instruct版已经具备较强的问答和指令遵循能力我再叠加领域知识和特定任务格式的数据即可训练收敛更快效果也更稳。如果你是从base版开始调相当于还得自己教它学会基本对话格式多走一段弯路。1.3 全链路规划从数据到部署的八个环节整个路径我拆成了八个环节后续章节逐一展开数据工程、继续预训练、SFT监督微调、DPO对齐、评测迭代、量化压缩、推理部署、以及最后的蒸馏扩展。这里先给一张总览表帮你建立全局观。环节核心工具/框架主要产物关键风险数据工程Python、Spark、LLaMA-Factory的dataset模板清洗后的训练集数据质量差导致训练白做继续预训练DeepSpeed、Transformers领域增强的基座权重loss spike、灾难性遗忘SFT监督微调LLaMA-Factory、ms-swift具备指令跟随能力的模型过拟合、格式崩坏DPO对齐TRL、LLaMA-Factory对齐后的模型奖励黑客、训练不稳定评测迭代C-Eval、MMLU、人工评估集评估报告迭代方向benchmark过拟合量化压缩AWQ、GPTQ、llama.cpp4bit量化后的GGUF/AWQ模型精度损失过大推理部署vLLM、Ollama、TGI可对外服务的API显存管理不当导致OOM蒸馏可选小模型蒸馏脚本更小体量的轻量模型蒸馏后能力丢失2. 数据工程这个环节决定生死2.1 数据从哪来开源语料、业务日志、合成数据三分法很多初学者上来就问训练数据在哪个网站下载这是没想清楚数据形态的问题。真实项目里数据来源基本是三分法开源语料、自有业务数据、合成数据。开源语料是大头用来保持和扩展模型的通用能力与领域基础。中文场景常用的有跃问的WuDaoCorpora、智源的Wanjuan、TigerBot的预训练数据、以及HuggingFace上各种filtered中文语料。注意直接拿原始下载包就用是大忌必须先做清洗——这是所有踩过坑的人的第一条血泪教训。我在实际项目里对开源语料做的第一件事永远是去重MinHash去重第二件事是语言识别过滤去除机器翻译味太重的段落第三件事是做质量打分用perplexity或分类器打分排序砍掉低质量尾巴。自有业务数据是真正的护城河。比如你做的是医疗AI你手里的病历、医患对话、临床指南这些是任何开源语料里都找不到的稀缺资源。但是业务数据往往脏、乱、带着大量隐私信息必须做脱敏和格式规整。我会把每一份业务数据都转成统一的Schema做清洗比如把JSON里的嵌套结构拉平、把乱码符号剔除、把重复段落按simhash去重。脱敏这里多说一句人名、身份证号、手机号、地址必须用正则实体识别双重清洗这个环节出了问题后面模型上线就是合规事故。合成数据这两年越来越重要尤其是当你需要拟人化的问答对时。常用套路是拿通用大模型领域资料生成种子问答然后人工抽检修正。比如我有一个领域知识切片→生成问题→生成答案→人工打分的流水线生成的数据只保留4分以上的样本5分制。注意合成数据一定要做强负样本过滤否则模型会学到大量看起来像那么回事但全是幻觉的回答模式。2.2 数据清洗的五个实操步骤我每次拿到新数据集都会按下面五步走顺序不能乱格式规整全角转半角、统一换行符、去除控制字符、修复截断的HTML/JSON。语言过滤用fastText的lid.176模型做语言识别按业务需要筛出中文/英文/代码丢掉混合识别结果置信度低于0.9的段落。去重Minhash LSH做近似去重simhash做语义级别去重。预训练语料的重复率往往超过20%去重后能明显降低后续训练loss震荡的概率。质量打分用规则小模型打分。规则包括长度阈值、标点符号密度、乱码比例小模型可以直接拿一个通用的文本质量分类器比如基于BERT的分数模型也可以拿目标基座给文本算perplexityperplexity过高的一律不要。隐私与安全过滤正则清洗证件号、手机号等关键词表过滤违规内容再做一轮人工抽检抽检比例不低于1%。2.3 tokenizer是否要扩展这是一个很少被讲透的问题做领域模型时有一个非常隐蔽但影响巨大的决策点tokenizer要不要动我自己做过对比实验。在某个法律领域的项目里基座用的是Qwen2.5-7B原始中文词表对通用中文支持得已经很好但遇到大量的法条编号、当事人姓名很多生僻字、案由专业词汇时token化效率明显下降。表现形式就是相同内容文本经过tokenizer后序列长度比正常文本多出20%~30%。序列变长直接导致训练变慢、上下文窗口浪费、以及模型对低频token的学习不充分。所以这里有两个选择。第一个选择是扩展tokenizer把领域词表比如几万个法律高频词加进原词表重新初始化这些新token的embedding和lm_head然后做一次embedding热身训练。这个方案效果好但工程复杂度高你得处理embedding维度扩展带来的权重文件变化很多下游工具链会出兼容问题。第二个选择是不动tokenizer接受一定的序列膨胀靠增加max_length上限来兜底。这个方案简单稳妥大多数场景够用。我的建议除非领域术语导致的token膨胀真的影响到了训练效率和效果否则不要动tokenizer。动了tokenizer就意味着你后面所有的微调、对齐、部署都要带着这套定制词表走生态兼容性会大打折扣。性价比最高的做法是在第一轮评测里对比几个高频领域样本的token数如果能接受就按不动处理确实膨胀严重再考虑扩展。3. 继续预训练把领域知识灌进去3.1 继续预训练与SFT的分工先理清一个概念继续预训练Continue Pretraining也叫领域预训练和SFT是两件事。继续预训练是用大规模无标注的领域文本让模型在底层学更多领域知识、词汇、句式SFT是用有标注的指令-回答对教模型学会按人类期望的方式回答问题。为什么需要继续预训练因为开源基座是在通用语料上训练的它可能连你领域的专有名词、缩写、行话都不认识。比如在工业制造场景下设备型号、工艺参数名词、报警代码这些在通用语料里非常稀疏。如果你不喂上下文直接上SFT模型就是在一堆它不认识的名词上硬记映射效果非常差幻觉率会很高。继续预训练的数据格式很简单纯文本段落一篇文章一条不需要标注。因为目标只有一项——用自回归的方式预测下一个token让模型在领域数据上做next-token prediction损失函数和预训练一致。3.2 超参设置与训练稳定性控制继续预训练的超参和从零预训练、和SFT都不一样。我给出我跑过多次、稳定可靠的配置记住这几组数字可以少踩很多坑学习率2e-5 ~ 5e-5。这个量级远低于从零预训练1e-4量级因为基座已经不是随机初始化过大的学习率会破坏原有权重出现灾难性遗忘。Batch size尽量大但要匹配显存。我习惯用梯度累积把有效batch size撑到128个样本或以上保证梯度稳定。序列长度4096起步。领域文本往往有长程依赖序列太短学不到上下文。训练步数不要机械地用epoch来算而是按数据量估算。领域继续预训练通常跑1~3个epoch。数据量太大就抽样子集数据量小就重复几轮。我自己实践的体量参考10亿~50亿token的领域语料在7B模型上跑一轮效果和成本比较均衡。混合精度bf16不要用fp16。fp16在训练时经常出现loss溢出和精度下溢的问题bf16的指数位更宽训练更稳。优化器AdamWbeta10.9beta20.95weight_decay0.1。学习率调度用cosine衰减前500~1000步warmup。下面是DeepSpeed ZeRO-3 bf16的配置片段我的惯用模板# ds_config.json { train_batch_size: 128, gradient_accumulation_steps: 8, zero_optimization: { stage: 3, offload_optimizer: { device: cpu, pin_memory: true }, overlap_comm: true, contiguous_gradients: true }, bf16: { enabled: true }, gradient_clipping: 1.0, steps_per_print: 50 }训练启动命令长这样deepspeed --num_gpus8 \ src/train_continue_pretrain.py \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --dataset_dir data/domain_pretrain \ --output_dir output/continue_pretrain \ --deepspeed ds_config.json \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 3e-5 \ --num_train_epochs 1 \ --max_length 4096 \ --bf16 True \ --logging_steps 10 \ --save_steps 500训练过程中我需要盯几个关键指标训练loss是否在缓慢下降、验证集loss是否同步下降、有没有loss spike。如果出现loss突然暴涨比如从2.0跳到5.0大概率是数据里有脏样本或学习率过高我会先停训练检查最近一个batch的数据再决定是降学习率还是清理数据。3.3 灾难性遗忘怎么防继续预训练最常见的问题就是灾难性遗忘——模型在领域数据上loss降得漂亮但通用能力一测就崩C-Eval分数大幅下滑。防遗忘这件事没有银弹但有几个非常有效的实操手段通用语料混入不要让模型只吃领域数据。我通常按领域数据:通用数据 4:1的比例混合保证模型不会把通用知识忘光。这个比例可以根据领域特殊性微调但通用数据占比不要低于10%。降低学习率继续预训练的学习率设置比SFT还要保守。如果SFT用2e-5那继续预训练我一般用1e-5~2e-5宁慢勿快。检查点对比训练过程中定期在固定评测集上跑通用benchmark比如C-Eval、MMLU的子集画一条领域loss vs 通用分数的曲线找到拐点。一旦发现通用分数持续下滑立即停止训练回滚到之前效果最好的检查点。Rehearsal在训练数据中始终混入一部分通用数据做复习让模型保持对通用知识的记忆。4. SFT监督微调教它学会说话和办事4.1 SFT数据怎么构造过了继续预训练模型有了领域知识但还没学会按用户的指令回答问题。SFT就是解决这个问题的。SFT数据的核心是一个个三元组system、instruction/user、response。在实际构造时我建议把所有样本统一成一套模板方便训练和后续解析。以Qwen2.5为例它的chat template长这样|im_start|system 你是一个专业的法律助手精通中国法律法规。|im_end| |im_start|user 请问以下合同条款是否违反劳动法条款内容...|im_end| |im_start|assistant 根据《劳动合同法》相关规定该条款存在以下问题...|im_end|数据量用多少很多教程会说越大越好这是误导。我做过的对比实验表明在质量有保证的前提下3千到2万条高质量SFT数据就能让7B模型在特定任务上达到非常好的效果而当你数据量涨到30万条但质量参差时效果反而可能更差——模型会被脏数据带偏学到错误的回答模式。所以SFT数据的核心策略是宁缺毋滥每条数据都要经过严格筛选。我在实际项目中通常会把SFT数据分为几个任务类型来构造指令遵循型完成具体任务比如总结这篇文章翻译下面这段话问答型领域知识问答改写/生成型把原文改写成指定风格多轮对话型带上下文的连续对话拒绝型对不合法、不合规、不知道的问题给出合理拒绝4.2 训练超参与关键技巧SFT的训练配置和继续预训练有差异我给出下面一套可复现的参数参数推荐值说明学习率1e-5 ~ 2e-5与继续预训练量级接近但不能太大epoch数2~3数据量小的时候可以适当增加序列长度4096要能覆盖较长的指令和回答LoRA rank64~128如果想用LoRA做轻量微调优化器AdamW与预训练一致调度器cosine同样带warmup关键技巧一loss要在response部分上算不在prompt部分算。也就是说训练时prompt部分对应的token位置其损失权重要置为0用ignore_index-100只让模型学习如何生成response。否则模型会浪费大量训练量去背你的prompt且学到错误的生成模式。在LLaMA-Factory里这个选项往往已经默认处理好但我见过很多自己写训练脚本的工程师踩这个坑。关键技巧二做格式稳定性训练。通俗讲就是让模型稳定地输出可解析的格式。如果你要让模型输出JSONSFT数据里就大量包含JSON格式的输入输出并且在评测时严格校验JSON可解析率。我自己会刻意把任务A-输出JSON和任务B-输出JSON设计成不同字段名的样本让模型学会从指令中领会字段含义而不是死记某一组字段名。关键技巧三使用LoRA还是全量微调我的经验是数据量小于5万条且算力有限LoRA训练更划算如果你有足够算力和数据量并且希望模型在领域上有更强的深度改造就上全量微调。LoRA的秩我一般设128alpha设为rank的两倍target_modules覆盖q_proj、k_proj、v_proj、o_proj、gate_proj、up_proj、down_proj。LoRA的好处是训练快、切换任务方便不同LoRA插拔坏处是某些工具链在导出和部署时对LoRA合并不够友好vLLM虽然支持LoRA但配置要比全量模型更细心。以LLaMA-Factory为例LoRA微调的配置长这样model_name_or_path: Qwen/Qwen2.5-7B-Instruct stage: sft finetuning_type: lora lora_rank: 128 lora_alpha: 256 dataset: domain_sft template: qwen cutoff_len: 4096 learning_rate: 2e-5 num_train_epochs: 3 lr_scheduler_type: cosine warmup_ratio: 0.1 bf16: true per_device_train_batch_size: 2 gradient_accumulation_steps: 84.3 微调后容易出的两个怪病第一个怪病是复读机现象模型回答永远以作为一个人工智能开头或者回答翻来覆去说同一句话。这通常是因为数据里存在大量安全对齐话术或某一类模板样本重复过多。解决方法是降低这类样本占比同时检查是否有重复样本没去重干净。第二个怪病是丧失拒绝能力你问什么它都顺着说哪怕问吃了过期的药怎么办它也给你编一套治疗建议。这往往是因为SFT数据里缺少拒绝型样本或者拒绝样本的措辞不够多样化。我的做法是构造一批该拒绝但模型容易答错的样本显式训练模型学会承认不知道、建议咨询专业人士。这类样本不在多每种拒绝场景放几十上百条就够了。5. DPO对齐让模型学会说人话5.1 为什么要做对齐SFT之后的模型可能表现得无所不知但仍然有大量问题生成内容不够体贴、不理解用户的真实意图、偏好表达生硬、甚至会说谎。对齐Alignment就是要把模型的输出从能用提升到好用。对齐的主流方法有RLHF基于人类反馈的强化学习和DPO直接偏好优化。RLHF需要先训练一个奖励模型再通过PPO算法优化策略模型整个流程工程复杂度高、训练不稳定7B量级做RLHF性价比很低。而DPO的思路非常优雅**直接在偏好数据上进