持续预训练(CPT)实战:把通用大模型调教成行业专家 最近不少做AI落地的朋友跑来问我同一个问题手里的通用大模型明明能写诗、能聊天但一用到自己这个行业里就“掉链子”——问它设备故障原因它给你背一段百科全书问它合同条款合规性它绕来绕去就是不提关键风险点。问题出在哪说白了通用模型学的是全人类知识的“平均值”而你要的是自己这片领域的“优等生”。想从“通用”走向“行业”有一关绕不过去就是今天要聊的这套东西Continued Pre-Training持续预训练下文简称CPT。这个标题下的内容适合谁适合正在做企业大模型落地的算法工程师、技术负责人也适合刚接触大模型、想搞清“微调和持续预训练到底啥区别”的学习者。我把做行业模型这件事从思路、数据、训练到部署按实战流程拆开讲清楚。它解决的核心问题是如何让模型在不大改底层能力的前提下把你们行业的术语、规则、上下文逻辑真正“长进参数里”而不是靠临时塞提示词去糊弄。1. 为什么通用大模型到了行业里就变“外行”1.1 通用模型在行业场景的三个尴尬现场我先说三个常见场景你感受一下。第一个是面向政策条款的问答。你问通用模型“某地高新技术企业认定管理办法里研发费用占比要求是多少”模型能给你一个有模有样的回答但条款编号是错的比例是按其他省份的三年前版本背的。这就是典型的“知识过时领域不精”。第二个是医疗场景问“这组肺结节影像指标下建议优先排查哪些方向”通用模型会堆一堆通用健康建议却不会基于专科诊疗指南给出分层处理逻辑。第三个是制造业设备运维给模型一段设备运行日志希望它定位故障根因结果它把“主轴温度偏高”和“环境气温炎热”强行捆绑成因果关系逻辑上通顺但行业内看完全站不住脚。这三个场景的共同点是什么不是模型没有推理能力是它压根没见过你们行业的“内部语言”。行业知识不只是几个名词还包括行文逻辑、判断框架、默认前提、风险红线。这些东西散落在大量文档和真实业务数据里通用大模型在预训练阶段没学过后面你再怎么提示都不牢靠。1.2 CPT 和微调SFT到底是不是一回事很多人一开始接触的是 Supervised Fine-TuningSFT也就是拿一批“问题-标准答案”对模型做监督训练。SFT 擅长的是让模型学会某种“回复格式”或“交互风格”比如把模型调成客服语气、让模型总是先给结论再解释。但 SFT 有一个很要命的特点它的数据量通常不大少则几千条多则几十万条而且都是“问答对”。这种训练方式只会让模型在已有知识基础上调整“输出方式”很难塞进去真正的新知识。CPT 就不一样它做的是在通用模型已经学会的语言能力基础上继续用大规模纯文本语料做自监督学习。训练目标还是“预测下一个词”但语料全是你们行业的文档、规范、真实报告。模型在这段时间里会把行业词表、术语搭配、行文规则、知识关系一点点吸收进权重里。所以有个很形象的比方SFT 是给一个刚毕业的大学生做岗前培训教他话术和流程CPT 是直接让他去业务部门轮岗半年天天泡在真实项目里熟悉行业逻辑。这里我放一张对比表方便你对照做技术方案时选型。维度Continued Pre-Training监督微调SFT训练数据大规模领域纯文本文档、报告、语料库小规模“问题-标准答案”对学习目标预测下一个词吸收领域知识学会指令跟随与输出格式改变的内容模型内部的世界知识和语义空间模型的指令理解和回复策略数据规模需求通常是 GB 级以上越多越好千条到几十万条都有典型耗时数天到数周取决算力和数据量数小时到数天单独使用的价值能增强领域理解但不能直接当问答助手能变“听话”但知识量没有实质增加实际项目里CPT 和 SFT 不是二选一而是前后脚的关系。CPT 先把领域基础打牢SFT 再教模型怎么把这些知识用问答方式吐出来。1.3 什么阶段才需要上 CPT先别急着跟风CPT 听着很高级但不是所有企业所有场景都需要。我见过不少团队业务还没跑明白先攒了一堆服务器要预训练结果训完发现该回答错还是错反而把通用能力搞退化了。我的判断标准一般有三条你对照一下。第一你的场景是否高度依赖领域内部知识如果只是让人工智能帮忙写周报、做摘要、翻译通用模型已经够了不需要投入做 CPT。第二你是否长期使用同一个固定场景的模型如果是一次性活动比如临时搭个客服机器人用 RAG检索增强生成临时引用知识库成本更低。第三你手上是否有足够高质量、成体系的领域语料做 CPT 最怕的就是“数据凑数”如果只有几十篇文档训出来的模型基本白搭甚至更差。一句话RAG 是“临时抱佛脚”CPT 是“长期培养”。你要是想让模型真正成为这个行业的半个老师傅且愿意在这个方向上持续投入那 CPT 就是正确的路。2. 项目整体设计动手之前先把这三件事想明白2.1 圈定领域范围别把“行业”想得太宽“行业模型”这个词听起来很大但落到实际项目里你必须先把领域边界切出来。你做医疗是做临床辅助决策还是医保控费你做法律是做合同审查还是裁判文书分析不同子领域的术语体系、知识结构、判断标准相差非常大。模型在一个过宽的领域里做 CPT往往每个方向都学个皮毛单个任务上反而表现平平。我的做法是先写一份“领域知识清单”把业务方实际关心的知识点都列出来再对照手头语料逐项打勾。比如做电力设备运维清单可以分成四块设备结构原理、历史缺陷记录、运维检修规程、故障案例库。每一块都对应一批文档训练完以后评估也按照这张清单逐项测。这样既能控制数据范围也能让老板和业务方清楚知道模型到底学到了什么哪些还没覆盖。2.2 底座模型怎么选不仅是看参数大小选底座是 CPT 项目的第一个大决定这里我给的策略是“三看”看语言能力、看协议合规、看生态工具。中文行业场景我对 Qwen 系列和 DeepSeek 系列用得相对多原因是这两个系列的中文语料占比本来就高继续预训练时中英文混杂的问题会少一些。Llama 系列底子很强但词表里中文 token 覆盖率偏弱CPT 时你往往需要同时扩充词表这会增加不少工程工作。另外一定要看模型的开源协议很多模型只允许研究使用商用需要额外申请不要等产品上线了才发现授权链路有坑。参数规模方面我见过 7B 模型在单一行业场景做到可用也见过 70B 模型训偏了没法收拾。没有绝对的“越大越好”只有“匹配算力、匹配数据量、匹配场景复杂度”。如果你只有单卡 24G 显存老老实实用 7B 或 13B如果有整机多卡再考虑更大的底座。这里的原则是先把一个中小模型跑通端到端流程再往上放大成本可控得多。2.3 评估体系要在训练前就搭好别等训完了才想怎么测这是我在项目里最深的体会之一很多团队是模型训完了才开始手忙脚乱找测试题结果测出来的指标说不清楚是数据问题还是训练问题。我建议在启动 CPT 之前先建三套评估集。第一套是“领域知识填空题”从行业文档里挖一些术语定义、参数范围、流程步骤做成填空题或判断题用来测模型“有没有把知识长进参数里”。第二套是“业务真实问答”收集业务方日常问得最多的 200 个问题由行业专家给标准答案用来测模型在真实场景的可用度。第三套是“通用能力基线”跑一些公开的常识推理、数学、代码题用来监控模型有没有在 CPT 后被“训傻了”。评估集不用一次性做得很大核心是能重复使用。训练前先跑一遍基线训练中每隔几个 checkpoint 跑一遍训练后再跑一遍你就非常清楚每一步对模型能力的影响。3. 数据工程CPT 成不成七成看数据3.1 语料来源与清洗规则CPT 的数据来源可以很广但质量门槛必须锁死。我常用的来源有这么几类行业出版的标准规范比如国标、行标、企业内部的作业手册和流程文档、高校和研究院公开的领域教材与课件、经过脱敏的历史业务报告、以及有授权许可的行业资讯与论坛讨论。这些原始语料进来以后清洗是第一步也是最枯燥但最不能省的一步。我一般会做这几道工序去掉页眉页脚和重复段落用 minhash 或向量相似度做全局去重过滤掉乱码、图片裁剪后留下的半截文字把明显的表格和列表结构化保留因为行业文档里大量参数在表格里最后一定要做敏感信息筛查把身份证号、手机号、具体客户名称、内部项目代码这些信息提前抹掉否则训练完的模型可能在回答中“复读”这些信息那是妥妥的数据安全事故。清洗完之后的数据要留一份“数据血缘表”也就是每一批数据是从哪个文件夹、哪份文档来的。后面发现模型回答有问题可以顺着数据血缘表去回溯是哪批语料引入了错误这是纯靠玄学调参解决不了的。3.2 领域数据与通用数据的配比做过 CPT 的人都知道只用纯领域数据是会把模型“训窄”的。模型疯狂学习行业文档逐渐忘掉通用知识最后变成只能聊行业的“偏科生”。所以我强烈建议在 CPT 数据里掺入一部分通用数据充当模型老知识的“保鲜剂”。我在项目里常用的配比是 4:1 到 5:1 之间也就是每 4 份领域数据配 1 份通用数据。通用数据不一定要多高级用公开的百科语料、新闻语料、网页语料都行关键是让模型在训练过程中周期性回顾通用语言模式。如果你的领域数据本身比较少比如只有 5GB通用数据比例可以提高到 1:1防止过拟合。举个例子假设你准备了 40GB 的医疗语料你可以混入 10GB 的通用中文语料然后总数据 50GB做一个 epoch 或者最多两个 epoch。不要贪多做多个 epoch 会显著加速过拟合我在 7B 模型上试过超过两个 epoch 后领域能力提升已经基本停滞通用能力却肉眼可见地往下掉。3.3 合成数据数据不够怎么“无中生有”行业语料往往严重不足尤其是一些新兴领域能拿到的有效文档可能就一两个 GB。这时候可以考虑用更强的模型来合成行业语料。合成数据不是让大模型随便编我总结了一套相对稳的流程先把手头真实的领域文档做切片抽取其中的关键概念和主题词然后用一个能力更强的模型比如更大的闭源模型或血缘更清晰的商业模型基于这些主题写“科普式讲解文”要求句式平实、知识准确最后用规则和人工抽检把明显有幻觉风险的句子滤掉。合成的语料可以补充到训练集中但比例我建议控制在 20% 以内否则模型会学到生成模型那股“一本正经胡说八道”的味儿。这里我得提醒一句合成数据最大的风险是幻觉传染。母模型如果对某个细分知识点说了假话学生模型会把假话当成真理牢牢记住后面再改就难了。所以合成语料一定要留出足够的抽检比例建议至少人工抽检 5%哪怕只是快速扫一遍标题和开头也能挡掉大部分明显错误。4. 训练细节参数怎么配、过程怎么盯4.1 超参数配置参考很多人微调时习惯沿用 SFT 的参数结果做 CPT 直接“爆训”。这里我把一套我验证过、比较稳妥的 CPT 超参配置放在下面供你参考。超参数推荐配置说明学习率1e-5 到 2e-5CPT 学习率要低于 SFT目的是小步慢走别把原有能力冲垮Batch Size按显存能容纳的最大值设置尽量大让每个 step 的梯度更稳定训练轮数Epoch1 到 2多了必过拟合最大序列长度2048 或 4096行业文档长文多短序列学不到上下文关系Warmup 比例3% 到 5%让学习率平稳上升防止开局震荡权重衰减0.1 左右帮助抑制过拟合梯度裁剪1.0防止 loss 突然 spike 时梯度爆炸学习率这块我要多说两句。CPT 是在已经训练好的底座上继续学习学习率如果开得太高模型会像失忆一样把原本的通用能力迅速破坏掉。我踩过最狠的一次是拿 5e-5 跑了一个 7B 模型三个小时后困惑度确实在下降但一跑通用测试集分数直接掉了十几个点那叫一个心疼。后来我把学习率压到 1.5e-5同样数据量下训练时间翻倍但通用能力几乎没受影响领域效果反而更好。慢就是快这句话在 CPT 里特别适用。4.2 基于 HuggingFace 的 CPT 训练代码框架现在开源工具有很多最常用的路径还是基于 HuggingFace Transformers Accelerate 或者 Deepspeed 来写训练脚本。如果你用的底座是 Qwen 或 Llama 系列直接用官方代码稍作修改把训练目标改成原生预训练目标即可。我贴一段我用过的简化训练脚本基于 transformers 的 Trainerfrom transformers import ( AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments, DataCollatorForLanguageModeling ) from datasets import load_dataset # 加载底座模型和 tokenizer model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B, torch_dtypeauto) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B) tokenizer.pad_token tokenizer.eos_token # 读取清洗后的领域通用混合语料 dataset load_dataset(text, data_files{train: data/train.txt, validation: data/val.txt}) # 分桶并 tokenize保持序列长度一致 def tokenize_function(examples): return tokenizer(examples[text], truncationTrue, max_length4096) tokenized_dataset dataset.map(tokenize_function, batchedTrue, remove_columns[text]) # 语言建模的 data collator动态 mask data_collator DataCollatorForLanguageModeling(tokenizertokenizer, mlmFalse) training_args TrainingArguments( output_dir./cpt_output, per_device_train_batch_size4, per_device_eval_batch_size4, gradient_accumulation_steps8, learning_rate1.5e-5, warmup_ratio0.03, num_train_epochs1, logging_steps50, save_steps500, eval_strategysteps, eval_steps500, save_total_limit3, fp16True, deepspeedds_config.json, ) trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_dataset[train], eval_datasettokenized_dataset[validation], data_collatordata_collator, ) trainer.train() resume_from_checkpointTrue这里几个关键点说一下。第一DataCollatorForLanguageModeling 的 mlmFalse 表示做的是自回归语言建模也就是 CPT 和预训练一致如果设成 True 那就变成 BERT 那种掩码语言模型了不适用于 GPT 类底座。第二deepspeed 配置我建议用 ZeRO-213B 以下模型基本上够用能省不少显存。第三训练时日志里除了关注 loss还要看一眼梯度范数如果突然冲高到 10 以上说明该降学习率或检查数据了。4.3 多卡并行与断点续训的工程要点单卡跑 7B 的 CPT 不是不行但数据量一大就要等好几天。企业项目里一般都会上多卡。我用得比较多的是 FSDP 和 DeepSpeed 两种方案DeepSpeed 对新手更友好配置起来直接套模板就行FSDP 在异构卡多的环境里表现更稳。断点续训一定要从一开始就打开save_steps 设成固定步数比如 500 步保存一次save_total_limit 设成 3防止磁盘被塞爆。续训的时候用 resume_from_checkpointTrueTrainer 会自动从最近的 checkpoint 恢复。我吃过一次亏是训练第二天机器崩溃重启后才发现之前没设 resume浪费了一整天算力打那以后我再也不敢省这一步。还有一个容易坑到人的地方多卡训练时的数据 shuffle 顺序。建议在预处理阶段固定随机种子使得各卡的 batch 划分是确定的。否则你中途续训时数据顺序变了模型会看到一个跟之前不一样的“课程安排”轻则增加额外 epoch 的震荡重则影响最终效果。5. 训练完成后评估、对齐与部署5.1 评估别只盯着困惑度业务盲测才是终审CPT 训练过程中你会看到一个现象train loss 在稳步下降val loss 也在降看起来一切正常。但 val loss 降不代表模型在真实业务里好用它只能说明模型对这批数据的“预测能力”变好了。所以我强烈建议做完 CPT 以后不要急着上业务先在之前搭好的三套评估集上完整跑一遍。领域知识填空题如果正确率明显提升、业务问答的专家评分过了及格线、通用能力基线没有大幅回退那这一步 CPT 就算稳了。如果领域效果好了但通用能力掉太多优先检查是不是学习率太高、通用数据掺少了或者训练轮数多了。如果困惑度降了但业务问答还是很差那多半是训练数据和真实业务场景之间存在 gap你训的内容覆盖不了真实问题这时候要回到数据层面去补样本。另外项目里我会专门安排一次“人工盲测”。把 CPT 前后的模型放在同一个 Web 页面里让行业专家同时看两边的回答但不知道哪个是旧模型哪个是新模型按“知识准确性、逻辑条理、行业规范性”三个维度打分。盲测的作用是消除心理预期有时候人是会倾向于觉得“花了钱的模型一定更好”的盲测一上真相立即水落石出。我经历过不止一次专家评分出来新旧模型差距微弱这时候你就知道数据或训练配置还有问题别急着开庆功会。5.2 与 SFT 和偏好对齐的衔接顺序CPT 训完的模型本质上还只是一个“更懂行业知识但没有被教会对话格式”的模型。你直接拿它上线它会像一台打字机一样给你续写段落而不是回答问题。所以常规的企业落地链路是CPT 完成后再用一批准行业问答对做 SFT把模型调成“问什么答什么”的形态如果还需要控制回答的口吻、避免高风险内容再进一步做偏好对齐训练比如 DPO。顺序上我建议严格按 CPT→SFT→(可选 DPO) 推进。如果你把 SFT 放在 CPT 前面模型在后续预训练阶段会把对话格式又冲淡掉SFT 的成果就白做了。反过来CPT 做完再 SFTSFT 能很顺地继承已经内化的行业知识训练量也不用太大。我在一个法律文本项目里试过CPT 后只用了两万条问答做 SFT效果就超过了之前十万条 SFT 的效果这就是“先长知识、再学表达”的优势。5.3 部署与推理优化VLLM 上线注意这几处细节评估通过后的模型我一般用 vLLM 做推理部署吞吐量比原生 HF 推理高不少尤其适合企业里多个业务同时调用的情况。部署的时候有几个细节值得留意。首先是上下文长度CPT 阶段如果用 4096 训练部署时 max-model-len 可以先保留在 4096贸然拉到 8192 或更长很多基础模型是支持位置编码外推的但如果训练阶段没专项训练回答长文时可能会出现“讲到一半开始糊涂”的情况。我建议上线初期保守一些稳定以后再逐步加长。其次是 vLLM 的缓存命中率。企业场景里用户的问题重复度很高尤其是客服和运维场景。打开 vLLM 的 prefix caching可以在处理高频问题前缀时大幅减少重复计算显著降低首 token 延迟。实测在制造业问答场景里开不开 prefix caching高峰期平均显存占用能差 20% 上下响应速度也有肉眼可见的提升。显存不够的话可以配合 AWQ 或 GPTQ 做量化推理。一般 7B 模型量化到 4bit 后在 24G 显存的卡上能很舒服地跑起来效果损失在大部分业务场景里可以接受。但要注意量化对模型回答的稳定性有一定影响尤其是长文本生成时可能出现重复句子。上线前建议专门用一个长文用例集做一轮回归测试。6. 常见问题与排查技巧6.1 训练后通用能力明显下降这是 CPT 项目里最经典的翻车现场。现象是领域问答变好了但模型忽然连“鸡兔同笼”这类小学数学都不会了或者做简单代码补全时错误率暴增。原因通常是学习率太高、领域数据配比过重、训练轮数太多。排查思路分三步。第一步立刻把学习率降到 1e-5 以下这是最直接的手段。第二步检查领域数据和通用数据的配比如果领域数据占比超过 85%建议降到 80% 以下把通用数据补上来。第三步看训练日志如果 loss 还在缓慢下降但通用测试集分数已开始跳水说明该提前停掉了不要恋战。我在项目里通常会设置一个“通用能力哨兵任务”每几百步跑一次简单的通用能力测试一旦分数跌破阈值就自动告警这样不用等整轮训完才发现问题。6.2 数据噪声放大了幻觉模型开始一本正经编造术语行业语料里通常带着各种非标准写法比如同一台设备有三种叫法同一个参数在不同部门文档里单位不一样。模型会把这种不一致当成“知识”学进去回答时就会表现为同一个概念前后说法打架甚至把 A 文档里的错误数字当成标准答案。这类问题预防比事后修更重要。清洗数据阶段就要做两件事一是术语归一化把同义不同写的词统一成标准说法比如“PLC 控制器”“可编程逻辑控制器”“Programmable Logic Controller”这类训练前尽量统一成一种二是数值单位校验把明显不在合理范围的数据拦下来比如一个写着“温度 9999℃”的断行数据基本就是 OCR 识别错误直接过滤。如果模型已经训完并出现了混乱可以试一次“专项纠正 CPT”单独挑一批规范化的领域语料用更低的学习率比如 1e-5 以下再做小步长训练有概率把错误的模式压下去。但如果错误知识混得太多可能就得回炉重做数据了这也是为什么我一直强调数据清洗阶段多花一倍时间都是值得的。6.3 困惑度降了业务效果却变差这个现象最迷惑人因为从训练指标看你做的一切都是对的。我遇到过一例领域语料困惑度从 12 降到 8表现相当漂亮但专家盲测时却发现模型经常在回答里引入一个训练数据里根本不存在的新概念而且神情笃定。排查之后发现是评估集和训练集出现了数据重叠。那批用于评估的业务问答很多是从训练文档里直接改写来的数据泄漏让指标虚高。解决方法是把评估集重新构建彻底排除和训练数据高度相似的样本。另外也要检查是不是训练数据本身覆盖面太窄模型在某几个知识点上“过于自信”稍有相关性的问题都会强行往那个方向答。这时候要给模型补充更多元化的反例数据让它知道哪些情况“不属于它管”。6.4 超参数与硬件资源冲突CPT 对显存的需求比 SFT 大不少因为你要一次性把很长的一段文本喂进去batch 又得尽量大。很多团队在启动前没算好显存导致 batch size 被迫压到 1训练稳定性很差。我建议启动前用一个小样先做一轮“干跑”把 batch size、梯度累积步数、序列长度、并行策略全部调好再上全量数据。干跑时观察两点一是显存占用是否在训练过程中缓慢上升如果是可能某个操作有内存泄漏二是吞吐量是否合理7B 模型在单张 A100 上4096 序列长度时通常每秒能处理几十到上百个 token如果慢到离谱检查一下是不是 CPU 数据加载成了瓶颈。数据加载这块别心疼内存用 num_workers 多开几个进程预加载数据实测能把 GPU 利用率从 60% 拉到 95% 以上。最后按我的习惯再分享一个实操技巧一个项目启动前我总会在正式训练之前做一次“最小化验证”拿 1% 的领域数据和 1% 的通用数据用真实参数跑几十步确认 loss 在降、梯度范数正常、checkpoint 能正常保存、续训能恢复。这个流程看似浪费时间实际上帮我挡掉过至少三次“配置错误导致白跑一整天”的灾祸。你说你配好了没问题但等模型跑到第 800 步才发现数据路径配错你已经浪费了几千元算力。先花 20 分钟做最小化验证收益是最高的。做 CPT 这件事技术上没有想象中那么神秘难点全在数据质量、配比耐心和对训练过程的感知上。希望这篇文章能帮你少走几步弯路顺利把自家的大模型调教成真正的行业老师傅。