我前后做过差不多两年的垂直领域大模型项目从最初拿着开源权重瞎跑到后来把整套流程跑通中间踩的坑比写出来的代码多得多。今天这篇东西我想把所有能沉淀下来的东西一次性倒出来不搞那些虚头巴脑的原理复述全部是个人开发者真正能用上的实操经验。核心一条主线从预训练到领域适配一个普通开发者没有A100集群的那种究竟该怎么走完这条路。先说一个很多人刚入坑时的误区个人开发者做LLM一上来就想着“从零预训练”。这事不是说绝对不行而是你的算力、数据、时间都撑不起百亿参数模型的从头训练。真正适合个人开发者的是“继续预训练”和“领域适配”也就是在开源基座模型Qwen、Llama、DeepSeek这套的基础上用领域数据把模型往你想要的方向掰。整条链路其实可以拆成四个环节数据工程、继续预训练CPT、指令微调SFT、偏好对齐DPO/ORPO最后再加一个评测闭环。每一步都有取舍每一步都会踩坑下面逐个展开。1. 全流程整体设计与方案选型1.1 先想清楚你在解决什么问题而不是先想用什么模型很多个人开发者拿到项目的第一步就是纠结模型选型用Qwen还是Llama7B还是13B但我建议先反过来想你到底要解决什么任务是做一个法律问答助手还是让模型学会你们公司内部的文档格式是追求泛化能力还是死磕某一类领域问题的准确率这个问题直接决定你的技术路线。如果只是做通用对话增强那其实用现成的API就完了根本不需要自己训练。真正需要走“预训练到领域适配”这条路的场景通常有这几个特征领域有自己的术语体系比如医疗诊断术语、法律条文引用、通用模型在这些领域上表现很差、你有一定量的领域数据但没有多到能训练通用模型的规模。另一个容易忽略的问题是你手里的数据到底是什么样的我接过不少咨询对方说“我们有几百万条领域数据”结果打开一看全是PDF扫描件和没清洗过的聊天记录。数据的真实可用率能到30%就算不错了。所以第一步不是选模型是盘数据。1.2 模型选型的具体思路基座模型远比你想的更重要选基座模型时很多人只看榜单分数但榜单分数反映的是通用能力跟你垂直领域的表现关系不大。我更建议按这几个维度筛开源协议是否允许商用尤其要检查是否有附加条款比如Llama系列有地区和使用规模限制社区生态是否活跃有人维护、有人踩坑、有大量现成微调教程的模型能省你大量时间分词器的语言覆盖情况中文场景要检查词表里中文字符覆盖率不然同样的英文词表中文训练效率会低很多同参数量下的显存占用同样7BQwen和Llama可训练参数规模一样但激活显存和推理显存都有差异我自己的经验是中文垂直场景首选Qwen系列Llama做英文场景更顺手。不是说Qwen一定好而是它的分词器对中文更友好——这一点在继续预训练阶段特别关键。如果基座模型的中文词表覆盖不全你喂进去的中文文本会被拆成碎片学起来效率低不说生成的句子还容易磕磕绊绊。同时一定要想清楚硬件条件。个人开发者手头常见的配置单张409024GB或者两张309048GB。这个显存能做7B模型的完整微调用LoRA或者QLoRA能做14B模型的LoRA微调但如果想全参数微调13B以上那基本没戏。所以方案选型的第一步是用硬件倒推模型的参数量级。1.3 定留存方案继续预训练 vs 增量训练 vs 领域适配很多人把“继续预训练”、“增量预训练”、“领域适配”这几个词混着用但实际训练目标和策略差别很大继续预训练CPT用大量领域无监督语料继续训练模型的预训练目标Next Token Prediction目的是让模型“理解”领域知识。增量训练IT在已有模型权重上继续训练但数据可能来自新领域或新语言往往会伴随词表扩展。领域适配Domain Adaptation通常是一个组合拳继续预训练打底再配上指令微调和偏好对齐目的是让模型在具体任务上的表现达标。对个人开发者来说最优路径通常是以“领域适配”为最终目标用“继续预训练指令微调”作为核心手段必要的时候再补一轮偏好对齐。只做继续预训练不微调模型就像个读过很多书但不会答题的学生只做指令微调不预训练碰到专业术语照样一头雾水。两者是串联关系不是二选一。2. 数据工程全流程的地基也是最大的坑2.1 领域语料的采集与清洗质量比数量重要两个量级继续预训练阶段数据规模从几个G到几十个G都有人做但真正决定效果的是数据质量。我见过一个极端例子有人扔进去2TB的法律文书训完模型反而变笨了因为数据里有大量重复文本、扫描错误和无关的广告页面。清洗环节我建议至少过四道关第一关格式清洗。把PDF、HTML、Word全部转成纯文本去除页眉页脚、目录、表格碎片。这一关最容易被忽略但做完之后数据量通常会直接蒸发20%到30%。第二关去重。这一条我建议优先用MinHash做模糊去重而不是简单的哈希去重。领域语料里大量存在“同一篇文章被不同网站转了多次、措辞略有改动”的情况简单去重根本滤不掉。个人开发者没必要自己写分布式去重直接上datasketch库就够了几行代码的事。第三关语言和质量过滤。用fastText做语言识别把非目标语言比如一篇中文论文里夹带的英文摘要单独筛掉用ppl困惑度过滤掉乱码和高度重复的“废话文本”——高质量文本的ppl通常较低垃圾文本的ppl会异常高。第四关隐私和敏感信息过滤。这块没有统一的库需要按场景自己写规则。比如医疗数据要过滤姓名、电话、身份证号法律数据要过滤当事人的隐私信息。这个环节不能用自动化一劳永逸必须人工抽检。一个实操经验清洗完之后按文本长度做一次分布统计。如果大量文本集中在200到500字这个长度段说明你的数据源过于单一比如都是新闻短讯模型学不到长文本的上下文连贯性。理想状态是文本长度分布要尽量多样化短到几十字的产品描述、长到几千字的行业报告都要有。2.2 指令数据的构建数量不重要多样性才是王道指令微调阶段的数据和继续预训练数据完全是两个物种。预训练数据是无监督的纯文本指令数据是“问题-回答”配对。很多人在这一步又犯数量迷信——收集了十几万条指令数据结果模型训完只会回答三种句式的变体。我自己的标准种子指令数据2000到5000条高质量样本足够覆盖一个具体场景的SFT了。问题的关键不是数据多而是覆盖的场景维度多。怎么判断你的指令数据覆盖度够不够我整理过一套很土但很好用的方法把种子数据按“任务类型”打标问答、摘要、分类、生成、改写、提取把种子数据按“问题形式”打标指令式、选择题式、填空式、多轮对话式把种子数据按“领域子场景”打标比如法律的合同审核、法条检索、判决预测每个标签下面都要有至少几十条样本没有覆盖到的标签就是后续采集的重点。指令数据的质量怎么保证我的做法是“仿写人审”找领域专家写20到50条金标样本然后在此基础上用通用大模型做话术改写最后人工抽检。完全不建议直接拿通用模型批量生成指令数据生成出来的东西同质化严重训练出的模型会有明显的“模型味”回答模式千篇一律。2.3 Tokenizer要不要扩展大多数人不需要动它网上有人说领域适配必须扩展词表把领域专有名词加进去。这个话听着有道理实际做起来坑很深。扩展词表意味着embedding矩阵和lm_head都要随机初始化新增的行——这些参数没有经过预训练相当于在训练一开始就引入了一堆“噪声参数”需要额外的训练步数去磨平工程复杂度上升一个台阶。我的判断标准是先不扩展词表跑通整条链路观察领域专有名词的切分质量。如果模型能把你喂进去的领域文本里的专业词汇合理切分比如“心肌梗死”不会被拆得太碎训练效果也够用那就别动词表。只有当分词器把领域词切得非常离谱严重拉低训练效率时才考虑扩展词表而且扩展之后要做“嵌入空间初始化”或者“前缀/后缀初始化”这种平滑方案新手别轻易尝试。3. 实操过程继续预训练与SFT的全套配置3.1 继续预训练CPT实操LoRA和全参微调的取舍继续预训练阶段很多人会犯一个很要命的错误直接把通用模型拿去全参数训练然后灾难性遗忘catastrophic forgetting就爆发了——模型把之前学会的通用知识丢了个精光领域知识倒是学了点最后变成一个“偏科生”。这里的关键策略是用LoRA而不是全参微调。LoRA通过低秩分解把可训练参数量降到原来的千分之一左右训练时只更新一小部分参数原始权重被冻结这样能最大程度保住基座模型的通用能力。继续预训练的LoRA rank不需要很大8到16就够alpha取rank的两倍也就是16到32。训练时长的控制也特别关键一个epoch往往就已经足够最多不超过两个epoch。实测下来7B模型在单张4090上跑继续预训练如果序列长度设2048batch size取1梯度累积设8大约需要看数据量决定训练时间——但相信我一个epoch训完就开始验证一下模型效果千万别猛猛跑十个epoch。还有一个反直觉的点继续预训练阶段的学习率应该比SFT更低。很多人继续沿用SFT的2e-4结果模型loss震荡得厉害。继续预训练我建议1e-4到1e-5这个区间LoRA本身的低秩特性决定了它对学习率更敏感稍高一点就会造成扰动。3.2 SFT指令微调实操数据和参数的最优解SFT阶段最核心的目标是“让模型学会指令格式的输入输出”。这阶段推荐的做法还是LoRArank可以比继续预训练时大一些32到64。学习率取1e-4到2e-4之间batch size能大就大——理论上SFT对学习率不那么敏感但batch size太小会导致收敛慢、泛化差。训练数据格式上用ChatML格式|im_start|和|im_end|已经成了事实标准Qwen系原生支持Llama 3系也支持。个人开发者不要再自创模板格式直接用基座模型官方的对话模板就好——你用官方的格式模型在预训练阶段学到的能力才能迁移过来。SFT训练里一个最容易被忽视的细节是序列拼接策略packing。很多人把一条样本填到2048长度就送进去剩下全是Padding这会让模型在大量Padding token上学到“注意pad位置都是空转”浪费算力。更推荐的做法是动态拼接一定长度的短样本进同一个序列把实际计算量压缩到一半甚至更低。HuggingFace上有对应的实现constant_length_dataset直接拿来用就行。3.3 偏好对齐要不要做DPO什么时候做很多人SFT做完就急着部署上线结果发现模型的知识倒是懂但回答风格冷冰冰、答非所问、拒绝回答的姿势也不对。这时候就该考虑偏好对齐了。偏好对齐的主流方案是DPODirect Preference Optimization它不需要训练一个单独的Reward Model也不需要繁琐的RLHF三阶段流程——只需要准备“偏好对”好回答和坏回答的Pair然后直接在SFT模型上继续训练。DPO的loss目标明确拉大好回答的生成概率和坏回答的生成概率之间的距离。个人开发者在准备偏好对时没有必要自己从头写可以基于SFT模型的输出人工打分排序也可以在通用大模型比如GPT-4 API的辅助下做初步标注但一定要人工抽检。偏好对数量建议300到1000对少于300对效果不明显多于1000对的边际收益已经很低了。DPO训练的超参数里beta温度系数最值得调这个值控制对“好回答”和“坏回答”差距的敏感程度。默认0.1到0.5之间如果模型回答变得僵硬又乏味试着把beta调低一点如果模型没有明显学到好的偏好把beta调高一点。DPO的学习率远低于SFT建议5e-6到1e-5之间——注意是5e-6不是5e-4。这块新手特别容易踩爆拿SFT的学习率跑DPO直接重蹈灾难性遗忘。3.4 显存优化一张4090如何跑完7B全流程个人开发者最常问的问题是我只有一张卡能跑吗能。我顺手列一下我最常用的一套显存作战方案基座模型加载用4bit量化QLoRA技术。这不是说LoRA本身量化而是基座权重存储和计算走4bitLoRA旁路参数保持正常的float16精度。训练时用梯度检查点gradient checkpointing用一点计算换显存这个必开。梯度累积解决batch size问题显存放不下大batch那就把batch拆成小份按顺序算累加梯度后统一更新。序列长度从2048起步7B模型在24GB显存上配4bit量化batch size取2到4。如果OOM把序列长度砍到1024或者把batch size砍到1配梯度累积16。我还想特别提一个容易踩的坑不要在LoRA的基础上继续套LoRA训练。理论上可以做多层LoRA的叠加训练但实践中非常容易让模型失去稳定性——每一层旁路参数都注入低秩扰动扰动叠加扰动最终效果没法控制。正确做法是每轮训练结束时做一次“LoRA合并”把训练好的LoRA权重合并回基座模型然后以合并后的模型为基座再做下一轮训练。4. 领域适配的完整链路设计4.1 “继续预训练SFTDPO”的组合策略领域适配不是单一技术而是一条组合链路。我的标准流程是第一步继续预训练CPT。用清洗过的领域无监督语料LoRA方式这个阶段让模型“记住”领域术语、文体风格和知识结构。第二步SFT。用领域指令数据让模型学会“面对指令时用领域知识给出回答”的行为模式。第三步DPO。用偏好对打磨模型的回答风格让它拒绝乱答、能承认不知道、学会更自然的领域表达。三步耗时参考CPT通常4到8小时数据量10G以内SFT一到两小时5000条指令DPO一小时内搞定500对偏好。这里指的都是单卡4090的实际体验网上那些动不动“训练了2400 GPU小时”的项目对个人开发者不具备参考价值。这里要特别强调“分阶段验证”。CPT做完就瞎猜效果是不行的两步之间必须插评测。比如CPT做完用困惑度perplexity在留出的验证集上测一版同时跑几个标准NLP任务如CLUE、CMRC确认通用能力没有大幅退水。通用能力掉得太多说明灾难性遗忘已经发生了这时候就要调整CPT的训练步数或者提高LoRA的稀疏程度用更低rank更窄的注入半径。4.2 评测体系设计Open LLM Leaderboard上的分数不是一切领域适配做完效果怎么量化很多人一股脑把模型丢进Open LLM Leaderboard上的公开榜单任务里跑分分数涨了就开心跌了就自闭。这个思路对个人开发者来说是歧途——公开榜单测的是通用能力根本测不出你的领域适配到底是好是坏。个人开发者最需要的是一个自己定义的“领域评测集”。构建领域评测集有三个渠道从领域数据中挖把已有的标注数据、真实用户问题整理成评测集注意要分训练/测试防止信息泄露用通用大模型生成评测集把领域背景发给GPT-4级的模型让它生成潜在用户会问的问题人工盲测找几个真正用这个领域产品的人拿模型跑真实用例做主观评测要求每条评测用例都有“期望回答”或“评分要点”不是只有一个开放式问题。目标检测和分类任务可以量化算准确率生成任务建议写成“包含哪些关键词/信息点”你来判断模型是否完成了关键内容的覆盖。评测集不用多200到500条足够覆盖一个具体场景的验收。4.3 通用能力保护策略怎么避免“学一分知识、丢一分常识”领域适配最让人头疼的问题就是灾难性遗忘但是完全避免不现实只能把损失降到可接受的范围。除了前面说的“优先用LoRA”之外还有几个管用的土办法混合通用语料训练时除了领域数据再掺20%左右的通用数据比如从开源语料里筛一些常识性、百科性的数据。这能让模型在学领域知识的同时保持通用知识的“肌肉记忆”。降低训练步数上限CPT阶段设置Early Stopping在验证集ppl开始反弹前就停。控制学习率衰减的阶段把学习率安排成“低-中-低”的曲线后在训练末期把学习率降到接近零让模型稳定收敛减少对通用知识权重的扰动。我个人的经验是20%的通用语料混入比例足以保护通用能力再高了领域的适配效果就会变差。这个比例算是一个经过多轮项目验证的“甜点位”。5. 部署与落地真正让模型“能用”的最后一公里5.1 模型量化与推理加速从FP16到INT4训练完之后要面对的是部署环节。很多人在这一步才发现训练搞定很容易部署才是大坑——模型显存占用太高、推理速度太慢完全没法用。部署第一步是量化。FP1616GB显存和INT44GB显存之间差了4倍内存占用推理速度也能提升两三倍。推理阶段推荐的量化工具是GPTQ用于显存足够的情况和AWQ用于极致压缩的情况。GPTQ的量化质量在7B这个级别上很稳定AWQ对特定模型的结构兼容性更好。注意一个关键点量化不应该让领域适配的效果出现断崖式下降。用自己建的领域评测集在生产环境里再跑一遍评测不能只对比量化前后的ppl数值——ppl跌了不一定是坏事可实际生成质量可能被量化的噪声毁得一塌糊涂。5.2 推理服务框架选择vLLM是当前的最优解部署到生产环境最值得用的推理框架还是vLLM。它对连续批处理continuous batching的实现非常成熟吞吐量比原生HuggingFace pipeline高一两个数量级。个人开发者不需要重复造轮子。vLLM几个必须记住的参数--tensor-parallel-size如果一张卡装不下模型可以在多卡间做张量并行但对个人开发者的单卡场景来说默认1就好--max-model-len这个参数直接影响显存占用建议根据业务实际需要来设置比如你的领域问答上下文中位数是800个token就没必要设成8192--gpu-memory-utilization默认0.9建议调整到0.85左右留一点余量给KV Cache之外的计算开销另一个绕不开的点是“与RAG结合的部署形态”。领域适配模型最好的落地方式不是让它存储所有领域知识而是让它做“基于检索的回答”。模型负责理解问题、组装答案、提炼信息RAG负责把相关知识片段检索出来喂给模型。这样领域适配的重心从“背知识”转向“会利用知识”。RAG的检索部分可以用BGE或bge-m3这类开源embedding模型跑在CPU或者一张低端GPU上就行检索服务的成本也不高。5.3 上线后的评测回流与持续迭代模型部署了不代表工作结束。真正的长期工作是建立“数据回流”机制。我见过太多项目训练一次部署上线之后就再也没人管模型效果没有任何升级机制用户一旦遇到坏case也没法反馈产品慢慢变成鸡肋。建议至少做三件事第一在服务层加日志系统记录每次请求的输入输出、耗时、用户的显式反馈点赞/点踩结构化成半结构化数据存下来。第二每周跑一次回流评测把这一周的坏case和新涌现的高频问题补充进评测集重新跑一遍效果。第三当坏case累积到一定规模比如500条就触发新一轮的指令微调把旧模型和新模型在评测集上做AB对比决定是否替换线上模型。这套闭环机制比任何“再训练一次”都重要。领域适配不是一次性的手术而是持续性的保养。6. 常见问题与排查技巧实录6.1 训练loss不下降、反弹、爆掉——逐个分析训练中遇到loss不降反升的情况首先排查几个最经典的原因学习率过高。现在动辄2e-4的配置是SFT的继续预训练往1e-5到1e-4走。如果loss直接冲到NAN那就是学习率爆炸了直接降一个数量级。数据问题。最常见的是数据里混了大量空文本、重复文本、噪音文本——清洗一定要做扎实否则模型就在那学“怎么预测随机噪声”loss曲线看起来很低实际生成一点规律都没有。混合了多任务但loss权重失衡。多任务训练时不同任务的loss量级可能差很多生成任务的loss通常远大于分类任务需要用任务权重或梯度裁剪来平衡否则小任务会被大任务彻底淹没。如果loss数值很漂亮但生成效果差那就需要检查是不是评测指标和训练目标脱节了。模型可能是把“格式正确”学到了但“内容正确”没有学到——这个时候要把目光放到数据质量上而不是继续调参。6.2 灾难性遗忘与过拟合的对抗灾难性遗忘和过拟合这两个看起来相反的问题训练中经常成对出现。灾难性遗忘的表现是领域知识得分上升通用能力比如常识问答、基础数学、中英文翻译得分骤降。应对方案前面已经写了混入通用语料、控制训练步数、把学习率曲线调成“低-中-低”。过拟合的表现是训练集上的loss很好看、评测集上的指标却很拉胯。这时优先检查训练数据是否有信息泄露比如评测集的数据被混进了训练集其次检查训练轮数——SFT阶段超过3个epoch且batch size太小几乎是过拟合的必现条件。6.3 显存不足、调试效率低——几个救急技巧OOM显存溢出是个人开发者训练里最频繁的客人。除了常规的梯度检查点、梯度累积之外还有一个容易被忽略的技巧把模型的torch_dtype从float32改成bfloat16。BF16在NVIDIA Ampere以上的架构上有完整支持内存占用直接减半。调试效率低的问题也很典型每改一次参数就要重新加载模型、启动训练来回折腾半小时起步。我的建议是先在极小规模的数据比如200条上跑通完整流程确认所有代码路径都正确再切换到全量数据。这个习惯能帮你省下一个周末的时间。6.4 关于“评测骗局”的最后提醒最后再提醒一件事很多人在评测时会把训练时见过的提示词原封不动拿去考模型分数自然漂亮到不行。这种“数据泄露型评测”没有任何意义。真正的评测必须用模型在训练时没见过的问题最好是在部署前留出10%的领域数据不进训练集专门做评测上线之后再拿一段时间的真实用户流量做效果对比。评测不是给自己交差用的是摸清模型真实能力边界的唯一途径。我在实际项目里反复体会最深的一点是这套全流程里每一步单独拎出来都不难难的是步骤之间的衔接。CPT做完直接做SFTSFT做完直接做DPO每个阶段效果都会互相影响。最稳妥的执行方式就是每过一个阶段就用领域评测集测一次用通用语料做一次“体检”确认没退化到不可接受再往下一阶段走。这个习惯到现在还在项目里用我把它简化成了一句口诀小步快跑、每步验证、坏了就回滚、别妄图一步登天。 个人开发者大模型领域适配全流程：从CPT到SFT与DPO的实战指南
我前后做过差不多两年的垂直领域大模型项目从最初拿着开源权重瞎跑到后来把整套流程跑通中间踩的坑比写出来的代码多得多。今天这篇东西我想把所有能沉淀下来的东西一次性倒出来不搞那些虚头巴脑的原理复述全部是个人开发者真正能用上的实操经验。核心一条主线从预训练到领域适配一个普通开发者没有A100集群的那种究竟该怎么走完这条路。先说一个很多人刚入坑时的误区个人开发者做LLM一上来就想着“从零预训练”。这事不是说绝对不行而是你的算力、数据、时间都撑不起百亿参数模型的从头训练。真正适合个人开发者的是“继续预训练”和“领域适配”也就是在开源基座模型Qwen、Llama、DeepSeek这套的基础上用领域数据把模型往你想要的方向掰。整条链路其实可以拆成四个环节数据工程、继续预训练CPT、指令微调SFT、偏好对齐DPO/ORPO最后再加一个评测闭环。每一步都有取舍每一步都会踩坑下面逐个展开。1. 全流程整体设计与方案选型1.1 先想清楚你在解决什么问题而不是先想用什么模型很多个人开发者拿到项目的第一步就是纠结模型选型用Qwen还是Llama7B还是13B但我建议先反过来想你到底要解决什么任务是做一个法律问答助手还是让模型学会你们公司内部的文档格式是追求泛化能力还是死磕某一类领域问题的准确率这个问题直接决定你的技术路线。如果只是做通用对话增强那其实用现成的API就完了根本不需要自己训练。真正需要走“预训练到领域适配”这条路的场景通常有这几个特征领域有自己的术语体系比如医疗诊断术语、法律条文引用、通用模型在这些领域上表现很差、你有一定量的领域数据但没有多到能训练通用模型的规模。另一个容易忽略的问题是你手里的数据到底是什么样的我接过不少咨询对方说“我们有几百万条领域数据”结果打开一看全是PDF扫描件和没清洗过的聊天记录。数据的真实可用率能到30%就算不错了。所以第一步不是选模型是盘数据。1.2 模型选型的具体思路基座模型远比你想的更重要选基座模型时很多人只看榜单分数但榜单分数反映的是通用能力跟你垂直领域的表现关系不大。我更建议按这几个维度筛开源协议是否允许商用尤其要检查是否有附加条款比如Llama系列有地区和使用规模限制社区生态是否活跃有人维护、有人踩坑、有大量现成微调教程的模型能省你大量时间分词器的语言覆盖情况中文场景要检查词表里中文字符覆盖率不然同样的英文词表中文训练效率会低很多同参数量下的显存占用同样7BQwen和Llama可训练参数规模一样但激活显存和推理显存都有差异我自己的经验是中文垂直场景首选Qwen系列Llama做英文场景更顺手。不是说Qwen一定好而是它的分词器对中文更友好——这一点在继续预训练阶段特别关键。如果基座模型的中文词表覆盖不全你喂进去的中文文本会被拆成碎片学起来效率低不说生成的句子还容易磕磕绊绊。同时一定要想清楚硬件条件。个人开发者手头常见的配置单张409024GB或者两张309048GB。这个显存能做7B模型的完整微调用LoRA或者QLoRA能做14B模型的LoRA微调但如果想全参数微调13B以上那基本没戏。所以方案选型的第一步是用硬件倒推模型的参数量级。1.3 定留存方案继续预训练 vs 增量训练 vs 领域适配很多人把“继续预训练”、“增量预训练”、“领域适配”这几个词混着用但实际训练目标和策略差别很大继续预训练CPT用大量领域无监督语料继续训练模型的预训练目标Next Token Prediction目的是让模型“理解”领域知识。增量训练IT在已有模型权重上继续训练但数据可能来自新领域或新语言往往会伴随词表扩展。领域适配Domain Adaptation通常是一个组合拳继续预训练打底再配上指令微调和偏好对齐目的是让模型在具体任务上的表现达标。对个人开发者来说最优路径通常是以“领域适配”为最终目标用“继续预训练指令微调”作为核心手段必要的时候再补一轮偏好对齐。只做继续预训练不微调模型就像个读过很多书但不会答题的学生只做指令微调不预训练碰到专业术语照样一头雾水。两者是串联关系不是二选一。2. 数据工程全流程的地基也是最大的坑2.1 领域语料的采集与清洗质量比数量重要两个量级继续预训练阶段数据规模从几个G到几十个G都有人做但真正决定效果的是数据质量。我见过一个极端例子有人扔进去2TB的法律文书训完模型反而变笨了因为数据里有大量重复文本、扫描错误和无关的广告页面。清洗环节我建议至少过四道关第一关格式清洗。把PDF、HTML、Word全部转成纯文本去除页眉页脚、目录、表格碎片。这一关最容易被忽略但做完之后数据量通常会直接蒸发20%到30%。第二关去重。这一条我建议优先用MinHash做模糊去重而不是简单的哈希去重。领域语料里大量存在“同一篇文章被不同网站转了多次、措辞略有改动”的情况简单去重根本滤不掉。个人开发者没必要自己写分布式去重直接上datasketch库就够了几行代码的事。第三关语言和质量过滤。用fastText做语言识别把非目标语言比如一篇中文论文里夹带的英文摘要单独筛掉用ppl困惑度过滤掉乱码和高度重复的“废话文本”——高质量文本的ppl通常较低垃圾文本的ppl会异常高。第四关隐私和敏感信息过滤。这块没有统一的库需要按场景自己写规则。比如医疗数据要过滤姓名、电话、身份证号法律数据要过滤当事人的隐私信息。这个环节不能用自动化一劳永逸必须人工抽检。一个实操经验清洗完之后按文本长度做一次分布统计。如果大量文本集中在200到500字这个长度段说明你的数据源过于单一比如都是新闻短讯模型学不到长文本的上下文连贯性。理想状态是文本长度分布要尽量多样化短到几十字的产品描述、长到几千字的行业报告都要有。2.2 指令数据的构建数量不重要多样性才是王道指令微调阶段的数据和继续预训练数据完全是两个物种。预训练数据是无监督的纯文本指令数据是“问题-回答”配对。很多人在这一步又犯数量迷信——收集了十几万条指令数据结果模型训完只会回答三种句式的变体。我自己的标准种子指令数据2000到5000条高质量样本足够覆盖一个具体场景的SFT了。问题的关键不是数据多而是覆盖的场景维度多。怎么判断你的指令数据覆盖度够不够我整理过一套很土但很好用的方法把种子数据按“任务类型”打标问答、摘要、分类、生成、改写、提取把种子数据按“问题形式”打标指令式、选择题式、填空式、多轮对话式把种子数据按“领域子场景”打标比如法律的合同审核、法条检索、判决预测每个标签下面都要有至少几十条样本没有覆盖到的标签就是后续采集的重点。指令数据的质量怎么保证我的做法是“仿写人审”找领域专家写20到50条金标样本然后在此基础上用通用大模型做话术改写最后人工抽检。完全不建议直接拿通用模型批量生成指令数据生成出来的东西同质化严重训练出的模型会有明显的“模型味”回答模式千篇一律。2.3 Tokenizer要不要扩展大多数人不需要动它网上有人说领域适配必须扩展词表把领域专有名词加进去。这个话听着有道理实际做起来坑很深。扩展词表意味着embedding矩阵和lm_head都要随机初始化新增的行——这些参数没有经过预训练相当于在训练一开始就引入了一堆“噪声参数”需要额外的训练步数去磨平工程复杂度上升一个台阶。我的判断标准是先不扩展词表跑通整条链路观察领域专有名词的切分质量。如果模型能把你喂进去的领域文本里的专业词汇合理切分比如“心肌梗死”不会被拆得太碎训练效果也够用那就别动词表。只有当分词器把领域词切得非常离谱严重拉低训练效率时才考虑扩展词表而且扩展之后要做“嵌入空间初始化”或者“前缀/后缀初始化”这种平滑方案新手别轻易尝试。3. 实操过程继续预训练与SFT的全套配置3.1 继续预训练CPT实操LoRA和全参微调的取舍继续预训练阶段很多人会犯一个很要命的错误直接把通用模型拿去全参数训练然后灾难性遗忘catastrophic forgetting就爆发了——模型把之前学会的通用知识丢了个精光领域知识倒是学了点最后变成一个“偏科生”。这里的关键策略是用LoRA而不是全参微调。LoRA通过低秩分解把可训练参数量降到原来的千分之一左右训练时只更新一小部分参数原始权重被冻结这样能最大程度保住基座模型的通用能力。继续预训练的LoRA rank不需要很大8到16就够alpha取rank的两倍也就是16到32。训练时长的控制也特别关键一个epoch往往就已经足够最多不超过两个epoch。实测下来7B模型在单张4090上跑继续预训练如果序列长度设2048batch size取1梯度累积设8大约需要看数据量决定训练时间——但相信我一个epoch训完就开始验证一下模型效果千万别猛猛跑十个epoch。还有一个反直觉的点继续预训练阶段的学习率应该比SFT更低。很多人继续沿用SFT的2e-4结果模型loss震荡得厉害。继续预训练我建议1e-4到1e-5这个区间LoRA本身的低秩特性决定了它对学习率更敏感稍高一点就会造成扰动。3.2 SFT指令微调实操数据和参数的最优解SFT阶段最核心的目标是“让模型学会指令格式的输入输出”。这阶段推荐的做法还是LoRArank可以比继续预训练时大一些32到64。学习率取1e-4到2e-4之间batch size能大就大——理论上SFT对学习率不那么敏感但batch size太小会导致收敛慢、泛化差。训练数据格式上用ChatML格式|im_start|和|im_end|已经成了事实标准Qwen系原生支持Llama 3系也支持。个人开发者不要再自创模板格式直接用基座模型官方的对话模板就好——你用官方的格式模型在预训练阶段学到的能力才能迁移过来。SFT训练里一个最容易被忽视的细节是序列拼接策略packing。很多人把一条样本填到2048长度就送进去剩下全是Padding这会让模型在大量Padding token上学到“注意pad位置都是空转”浪费算力。更推荐的做法是动态拼接一定长度的短样本进同一个序列把实际计算量压缩到一半甚至更低。HuggingFace上有对应的实现constant_length_dataset直接拿来用就行。3.3 偏好对齐要不要做DPO什么时候做很多人SFT做完就急着部署上线结果发现模型的知识倒是懂但回答风格冷冰冰、答非所问、拒绝回答的姿势也不对。这时候就该考虑偏好对齐了。偏好对齐的主流方案是DPODirect Preference Optimization它不需要训练一个单独的Reward Model也不需要繁琐的RLHF三阶段流程——只需要准备“偏好对”好回答和坏回答的Pair然后直接在SFT模型上继续训练。DPO的loss目标明确拉大好回答的生成概率和坏回答的生成概率之间的距离。个人开发者在准备偏好对时没有必要自己从头写可以基于SFT模型的输出人工打分排序也可以在通用大模型比如GPT-4 API的辅助下做初步标注但一定要人工抽检。偏好对数量建议300到1000对少于300对效果不明显多于1000对的边际收益已经很低了。DPO训练的超参数里beta温度系数最值得调这个值控制对“好回答”和“坏回答”差距的敏感程度。默认0.1到0.5之间如果模型回答变得僵硬又乏味试着把beta调低一点如果模型没有明显学到好的偏好把beta调高一点。DPO的学习率远低于SFT建议5e-6到1e-5之间——注意是5e-6不是5e-4。这块新手特别容易踩爆拿SFT的学习率跑DPO直接重蹈灾难性遗忘。3.4 显存优化一张4090如何跑完7B全流程个人开发者最常问的问题是我只有一张卡能跑吗能。我顺手列一下我最常用的一套显存作战方案基座模型加载用4bit量化QLoRA技术。这不是说LoRA本身量化而是基座权重存储和计算走4bitLoRA旁路参数保持正常的float16精度。训练时用梯度检查点gradient checkpointing用一点计算换显存这个必开。梯度累积解决batch size问题显存放不下大batch那就把batch拆成小份按顺序算累加梯度后统一更新。序列长度从2048起步7B模型在24GB显存上配4bit量化batch size取2到4。如果OOM把序列长度砍到1024或者把batch size砍到1配梯度累积16。我还想特别提一个容易踩的坑不要在LoRA的基础上继续套LoRA训练。理论上可以做多层LoRA的叠加训练但实践中非常容易让模型失去稳定性——每一层旁路参数都注入低秩扰动扰动叠加扰动最终效果没法控制。正确做法是每轮训练结束时做一次“LoRA合并”把训练好的LoRA权重合并回基座模型然后以合并后的模型为基座再做下一轮训练。4. 领域适配的完整链路设计4.1 “继续预训练SFTDPO”的组合策略领域适配不是单一技术而是一条组合链路。我的标准流程是第一步继续预训练CPT。用清洗过的领域无监督语料LoRA方式这个阶段让模型“记住”领域术语、文体风格和知识结构。第二步SFT。用领域指令数据让模型学会“面对指令时用领域知识给出回答”的行为模式。第三步DPO。用偏好对打磨模型的回答风格让它拒绝乱答、能承认不知道、学会更自然的领域表达。三步耗时参考CPT通常4到8小时数据量10G以内SFT一到两小时5000条指令DPO一小时内搞定500对偏好。这里指的都是单卡4090的实际体验网上那些动不动“训练了2400 GPU小时”的项目对个人开发者不具备参考价值。这里要特别强调“分阶段验证”。CPT做完就瞎猜效果是不行的两步之间必须插评测。比如CPT做完用困惑度perplexity在留出的验证集上测一版同时跑几个标准NLP任务如CLUE、CMRC确认通用能力没有大幅退水。通用能力掉得太多说明灾难性遗忘已经发生了这时候就要调整CPT的训练步数或者提高LoRA的稀疏程度用更低rank更窄的注入半径。4.2 评测体系设计Open LLM Leaderboard上的分数不是一切领域适配做完效果怎么量化很多人一股脑把模型丢进Open LLM Leaderboard上的公开榜单任务里跑分分数涨了就开心跌了就自闭。这个思路对个人开发者来说是歧途——公开榜单测的是通用能力根本测不出你的领域适配到底是好是坏。个人开发者最需要的是一个自己定义的“领域评测集”。构建领域评测集有三个渠道从领域数据中挖把已有的标注数据、真实用户问题整理成评测集注意要分训练/测试防止信息泄露用通用大模型生成评测集把领域背景发给GPT-4级的模型让它生成潜在用户会问的问题人工盲测找几个真正用这个领域产品的人拿模型跑真实用例做主观评测要求每条评测用例都有“期望回答”或“评分要点”不是只有一个开放式问题。目标检测和分类任务可以量化算准确率生成任务建议写成“包含哪些关键词/信息点”你来判断模型是否完成了关键内容的覆盖。评测集不用多200到500条足够覆盖一个具体场景的验收。4.3 通用能力保护策略怎么避免“学一分知识、丢一分常识”领域适配最让人头疼的问题就是灾难性遗忘但是完全避免不现实只能把损失降到可接受的范围。除了前面说的“优先用LoRA”之外还有几个管用的土办法混合通用语料训练时除了领域数据再掺20%左右的通用数据比如从开源语料里筛一些常识性、百科性的数据。这能让模型在学领域知识的同时保持通用知识的“肌肉记忆”。降低训练步数上限CPT阶段设置Early Stopping在验证集ppl开始反弹前就停。控制学习率衰减的阶段把学习率安排成“低-中-低”的曲线后在训练末期把学习率降到接近零让模型稳定收敛减少对通用知识权重的扰动。我个人的经验是20%的通用语料混入比例足以保护通用能力再高了领域的适配效果就会变差。这个比例算是一个经过多轮项目验证的“甜点位”。5. 部署与落地真正让模型“能用”的最后一公里5.1 模型量化与推理加速从FP16到INT4训练完之后要面对的是部署环节。很多人在这一步才发现训练搞定很容易部署才是大坑——模型显存占用太高、推理速度太慢完全没法用。部署第一步是量化。FP1616GB显存和INT44GB显存之间差了4倍内存占用推理速度也能提升两三倍。推理阶段推荐的量化工具是GPTQ用于显存足够的情况和AWQ用于极致压缩的情况。GPTQ的量化质量在7B这个级别上很稳定AWQ对特定模型的结构兼容性更好。注意一个关键点量化不应该让领域适配的效果出现断崖式下降。用自己建的领域评测集在生产环境里再跑一遍评测不能只对比量化前后的ppl数值——ppl跌了不一定是坏事可实际生成质量可能被量化的噪声毁得一塌糊涂。5.2 推理服务框架选择vLLM是当前的最优解部署到生产环境最值得用的推理框架还是vLLM。它对连续批处理continuous batching的实现非常成熟吞吐量比原生HuggingFace pipeline高一两个数量级。个人开发者不需要重复造轮子。vLLM几个必须记住的参数--tensor-parallel-size如果一张卡装不下模型可以在多卡间做张量并行但对个人开发者的单卡场景来说默认1就好--max-model-len这个参数直接影响显存占用建议根据业务实际需要来设置比如你的领域问答上下文中位数是800个token就没必要设成8192--gpu-memory-utilization默认0.9建议调整到0.85左右留一点余量给KV Cache之外的计算开销另一个绕不开的点是“与RAG结合的部署形态”。领域适配模型最好的落地方式不是让它存储所有领域知识而是让它做“基于检索的回答”。模型负责理解问题、组装答案、提炼信息RAG负责把相关知识片段检索出来喂给模型。这样领域适配的重心从“背知识”转向“会利用知识”。RAG的检索部分可以用BGE或bge-m3这类开源embedding模型跑在CPU或者一张低端GPU上就行检索服务的成本也不高。5.3 上线后的评测回流与持续迭代模型部署了不代表工作结束。真正的长期工作是建立“数据回流”机制。我见过太多项目训练一次部署上线之后就再也没人管模型效果没有任何升级机制用户一旦遇到坏case也没法反馈产品慢慢变成鸡肋。建议至少做三件事第一在服务层加日志系统记录每次请求的输入输出、耗时、用户的显式反馈点赞/点踩结构化成半结构化数据存下来。第二每周跑一次回流评测把这一周的坏case和新涌现的高频问题补充进评测集重新跑一遍效果。第三当坏case累积到一定规模比如500条就触发新一轮的指令微调把旧模型和新模型在评测集上做AB对比决定是否替换线上模型。这套闭环机制比任何“再训练一次”都重要。领域适配不是一次性的手术而是持续性的保养。6. 常见问题与排查技巧实录6.1 训练loss不下降、反弹、爆掉——逐个分析训练中遇到loss不降反升的情况首先排查几个最经典的原因学习率过高。现在动辄2e-4的配置是SFT的继续预训练往1e-5到1e-4走。如果loss直接冲到NAN那就是学习率爆炸了直接降一个数量级。数据问题。最常见的是数据里混了大量空文本、重复文本、噪音文本——清洗一定要做扎实否则模型就在那学“怎么预测随机噪声”loss曲线看起来很低实际生成一点规律都没有。混合了多任务但loss权重失衡。多任务训练时不同任务的loss量级可能差很多生成任务的loss通常远大于分类任务需要用任务权重或梯度裁剪来平衡否则小任务会被大任务彻底淹没。如果loss数值很漂亮但生成效果差那就需要检查是不是评测指标和训练目标脱节了。模型可能是把“格式正确”学到了但“内容正确”没有学到——这个时候要把目光放到数据质量上而不是继续调参。6.2 灾难性遗忘与过拟合的对抗灾难性遗忘和过拟合这两个看起来相反的问题训练中经常成对出现。灾难性遗忘的表现是领域知识得分上升通用能力比如常识问答、基础数学、中英文翻译得分骤降。应对方案前面已经写了混入通用语料、控制训练步数、把学习率曲线调成“低-中-低”。过拟合的表现是训练集上的loss很好看、评测集上的指标却很拉胯。这时优先检查训练数据是否有信息泄露比如评测集的数据被混进了训练集其次检查训练轮数——SFT阶段超过3个epoch且batch size太小几乎是过拟合的必现条件。6.3 显存不足、调试效率低——几个救急技巧OOM显存溢出是个人开发者训练里最频繁的客人。除了常规的梯度检查点、梯度累积之外还有一个容易被忽略的技巧把模型的torch_dtype从float32改成bfloat16。BF16在NVIDIA Ampere以上的架构上有完整支持内存占用直接减半。调试效率低的问题也很典型每改一次参数就要重新加载模型、启动训练来回折腾半小时起步。我的建议是先在极小规模的数据比如200条上跑通完整流程确认所有代码路径都正确再切换到全量数据。这个习惯能帮你省下一个周末的时间。6.4 关于“评测骗局”的最后提醒最后再提醒一件事很多人在评测时会把训练时见过的提示词原封不动拿去考模型分数自然漂亮到不行。这种“数据泄露型评测”没有任何意义。真正的评测必须用模型在训练时没见过的问题最好是在部署前留出10%的领域数据不进训练集专门做评测上线之后再拿一段时间的真实用户流量做效果对比。评测不是给自己交差用的是摸清模型真实能力边界的唯一途径。我在实际项目里反复体会最深的一点是这套全流程里每一步单独拎出来都不难难的是步骤之间的衔接。CPT做完直接做SFTSFT做完直接做DPO每个阶段效果都会互相影响。最稳妥的执行方式就是每过一个阶段就用领域评测集测一次用通用语料做一次“体检”确认没退化到不可接受再往下一阶段走。这个习惯到现在还在项目里用我把它简化成了一句口诀小步快跑、每步验证、坏了就回滚、别妄图一步登天。