真正跑过企业大模型项目的人应该都有同一个感触拿一个通用大模型回来不做任何加工直接放到行业场景里回答问题是会出事的。术语可以用错行业规范它敢编格式它敢不按你的来。我最近连续跟几个团队的负责人聊发现大家都在同一个地方打转做微调做了几轮效果总是差一口气。这个差的一口气很可能就是因为缺了Continued Pre-Training继续预训练这一步。行业内卷到今年光会调用API已经不算能力了真正值钱的是把手头的通用大模型训练成懂自己行业的模型。这篇内容我不讲虚的把我自己跑通的一套企业级行业模型训练流程完整拆开从数据怎么攒、训练超参怎么定、算力怎么估到上线评估怎么做、有哪些坑等着你全过一遍。适合正打算做行业大模型私有化部署、或者已经微调过但效果不理想的团队也适合想系统搞懂继续预训练这条路线的人。1. 为什么企业训行业模型首选Continued Pre-Training而不是只做微调1.1 微调解决不了的问题行业知识缺失和术语错乱先复盘一下大多数团队的做法。拿到一个开源基础模型比如千问、LLaMA这类第一反应是整理一批行业问答数据做几轮SFT监督微调跑完发现模型确实听话了——知道按固定格式输出不会再答非所问。但一旦涉及真正的行业深度内容就开始露馅专业名词张冠李戴内部规范体系完全混乱甚至一本正经地输出错误结论。为什么因为SFT的本质是教模型按照你的格式和风格回答问题它改变的是模型的输出行为而不是模型脑子里装的知识。模型不知道你们行业里良品率和直通率到底什么关系不知道你们设备故障代码的含义更不可能知道你们企业内部那些没有公开过的工艺参数。你没给它这些知识它当然只能靠编。LoRA这类参数高效微调更明显——它只调整一小部分参数训练出来的模型更像是带上了行业面具的通用模型面具一摘底子还是通用的。行业知识密度不够这是微调路线天然的短板。1.2 继续预训练和微调的分工先补知识再教规矩Continued Pre-Training做的事情和预训练阶段是一样的用大量无标注的领域文本继续训练模型的因果语言建模能力让模型在参数层面真正内化行业知识。和SFT的教规矩不同CPT解决的是懂行业的问题。我习惯把这条路拆成两步走先用CPT做大剂量的领域知识注入把行业术语、技术文档、制度规范、历史案例这些语料喂进去再做一轮SFT来对齐输出格式和交互方式。CPT管知识SFT管行为顺序不能反。如果先做SFT再做CPT模型学会的输出格式会被后续训练冲掉等于白做。这也是现在开源社区里跑行业模型的主流玩法。像有些团队基于千问做法律、医疗、金融模型跑出来的效果差异本质上就是CPT阶段语料质量和训练手法的差异——模型底座大家都一样拉开差距的是谁更会把行业知识灌进去。1.3 哪些项目真的需要CPT哪些不需要先说结论不是所有行业模型场景都需要CPT很多人其实被销售忽悠着上了这条路。如果你们的场景是模型已经能回答大部分问题只需要让它按固定格式输出、或者在已有知识基础上做润色改写那SFT甚至Prompt工程就够了没必要花算力和时间做CPT。真正需要CPT的信号有三个第一模型频繁出现行业术语混淆或编造而且这种错误在SFT之后依然存在第二你们有大量未公开的、网络上找不到的私有领域文档这些知识必须被模型内化而不是每次靠检索拼接第三模型的输出从内容正确性上被业务方判死刑——注意是内容本身错不是格式不对。我见过最典型的需求来自制造企业和金融机构设备的维修手册、历史故障记录、内部制度文件这些语料百度上搜不到通用模型连术语都认不全这时候做CPT才有意义。如果只是做个客服问答机器人且知识库内容稳定、更新不频繁那老老实实用RAG检索增强生成性价比高得多。CPT和RAG并不互斥后面我会细说它们的分工。2. 行业语料工程决定行业模型天花板的那80%工作2.1 领域语料从哪来内部文档、公开数据、合成数据大量做CPT的团队挂在第一步没数据。但其实数据从来不缺缺的是整理数据的决心。企业内部通常有大量沉睡的文档工艺文件、质检报告、历史邮件、客户投诉记录、设备日志、制度汇编。这些文件散落在各个部门、各种格式里先集中收拢能拿到什么算什么。公开数据方面行业报告、论文、专利、标准规范、龙头企业公开发布的技术白皮书这些都是高质量语料。还有一个容易被忽略的渠道是行业垂直网站的公开内容——只要注意版权作为补充没问题。如果预算允许也可以采购第三方行业数据集比自己爬省事得多。合成数据是这两年圈内越来越常用的手段。用通用大模型基于行业知识提纲生成解释性文本再经过人工抽检可以快速扩充语料。但要小心合成数据的知识密度和准确性有上限生成的内容一旦有错误模型学会之后比不会更麻烦。我一般把合成数据控制在总语料的一到两成以内而且必须经过领域专家抽检。2.2 清洗与去重别把脏数据喂给基座模型语料收回来不能直接训练否则就是灾难。原始文档里充斥着页眉页脚、乱码、表格错位、重复段落、广告噪声。我的清洗流程一般分四步第一步规则过滤把乱码行、超短句、无意义符号全部去掉第二步格式统一PDF转出来的文本经常有断行问题要做段落合并和标点修正第三步去重包括精确去重和模糊去重模糊去重用Minhash或者embedding相似度都行行业文档里大段复制的比例非常高不去重会让模型反复背诵同一段内容第四步敏感信息过滤把身份证号、手机号、内部机密信息做脱敏处理避免模型学会在回答里输出这些内容。有团队用OneKE这类知识抽取框架先从非结构化文档里抽实体和关系再反向生成训练语料效果也不错——本质上是把知识结构化后再文本化能提升知识密度。但注意这一步是锦上添花不要指望它替代基础清洗。2.3 数据配比与混合策略领域数据不是越多越好这是整个CPT里最容易被忽略、但影响最大的一个决策领域语料和通用语料的比例。很多人以为行业模型就是疯狂灌行业数据比例拉到95%以上结果训练完发现模型变笨了常识性能力暴跌、指令遵循变差这就是把模型的通用底座给冲垮了。我习惯的做法是控制领域数据占比在75%到85%之间剩余部分混合高质量通用语料包括通用知识、代码、多轮对话等。这样做的逻辑很简单CPT的目标是在不破坏原有能力的前提下叠加新知识保留一截通用语料等于给模型打记忆增强针防止灾难性遗忘。通用语料可以从开源数据集里采样比如中文的悟道、BELLE、或者用基座模型原始训练数据里公开的部分。数据配比还有一个隐藏考量行业内部的子领域平衡。比如做一个制造行业模型冲压工艺和质量管理的语料量如果严重失衡模型会对语料多的领域过度自信。建数据索引表按子领域统计语料总量把明显偏少的子领域想办法补数据或者做上采样。2.4 一个超实用的数据集自检方法训练前最后一步建议做一次抽读自检。把清洗后的语料随机抽1000条让人逐条读记录三个指标文本干净度格式是否正确、有没有乱码、知识有效性内容是否真的有行业价值、上下文完整性截断是否造成语义残缺。任何一个指标低于95%说明数据管线还有问题不要贸然开训。我吃过一次亏。当时赶进度数据清洗只做了规则过滤结果训练出来的模型经常在回答中间突然蹦出一段导语和目录就是因为语料里PDF转文本时的页眉页脚没清干净。后来加了规则过滤和embedding相似度去重再训练这个问题就消失了。数据清洗做不好后面的训练等于在垃圾堆上盖楼。3. 训练阶段的关键参数与实操细节3.1 学习率、批量大小和训练步数的设定逻辑CPT的超参和预训练一致但是数值要往低了调。基础模型已经收敛过了你是在它基础上精修步子迈大了容易把已有能力搞坏。学习率是最关键的参数。全参CPT我一般用1e-5到2e-5比预训练的3e-4低一个数量级LoRA方式的CPT可以稍微高一点3e-5左右。warmup占比设1%到3%让模型平稳进入训练状态。批量大小方面行业语料动辄几亿token单卡显存放不下大batch习惯用梯度累积模拟大batch。比如目标batch size是64单卡per-device batch设4梯度累积步数就是16。理论上大batch更稳但受显存限制32到128之间都是合理的。训练步数方面行业语料一般训练1到3个epoch就停。训练太少知识没学透训练太多模型开始过拟合回答会变得机械。一个直观的判断方法是看loss曲线领域语料上的loss持续下降是正常的但如果通用语料混合部分的loss开始上升说明遗忘在加速该停就停。3.2 用DeepSpeed跑起来ZeRO阶段怎么选分布式训练框架这块我主力用的是DeepSpeed偶尔也用PyTorch自带的FSDP。DeepSpeed的ZeRO优化器是当前跑大模型训练的标配它把优化器状态、梯度、参数按需切分到多张卡上解决单卡显存放不下的问题。ZeRO-1只切优化器状态ZeRO-2把梯度也切了ZeRO-3连参数都切了。选哪个取决于模型参数和卡数。跑7B模型用4卡A100ZeRO-2或者ZeRO-3都行显存紧张就上ZeRO-3跑13B以上、卡数少ZeRO-3几乎是必选。开启ZeRO-3之后需要额外配stage3_gather_16bit_weights_on_model_save: true否则保存模型时没法正常聚合并转成可加载的权重文件这个细节坑过很多人。混合精度方面绝大多数场景用bfloat16就够了。bf16动态范围大不容易溢出而且H系列显卡原生支持计算效率更高。FP16虽然也能用但loss经常无故震荡需要开动态损失缩放排查起来很痛苦。如果你是V100这类老卡不支持bf16再退回FP16。3.3 训练中的监控指标和中断恢复训练启动不是甩手不管。我习惯每50步记一次loss和梯度范数配合TensorBoard在Web端看着曲线实时跑。正常的训练曲线是训练loss平滑下降开始快后面慢梯度范数保持在一个相对平稳的区间。如果loss突然飙升后不回落通常是数据里有坏样本或者学习率过大先暂停排查数据再考虑调学习率。训练几亿token的时长是按天算的中断几乎一定会碰到。电源波动、机房维护、单卡故障哪个都躲不掉。我现在所有训练脚本都强制开启checkpoint保存间隔设1000步同时把最新的checkpoint存到独立磁盘或对象存储不做就地覆盖——防止checkpoint写到一半进程崩了导致模型权重文件损坏。恢复训练时用DeepSpeed的--resume_from_checkpoint加载最近的checkpoint验证一下step计数和loss曲线是连续的再继续。我还遇到过加载成功但优化器状态对不上的情况特征是恢复后loss有一段异常波动。处理办法是训练脚本里记录每次保存时对应的数据批次位置恢复时从数据流同一位置继续而不是靠随机抽样从头开始。3.4 loss不降或者震荡怎么办loss不降先别急着调超参按顺序排查。第一步看数据加载是否正常——我遇到过分词器对某些特殊字符处理出错导致模型学到一堆无意义token第二步看学习率如果已经低于1e-5还不降可以尝试小幅度调到3e-5观察第三步看数据配比领域数据和通用数据混合时如果采样比例不均匀loss曲线也会出现周期性波动。更隐蔽的问题是tokenizer词表和新语料的匹配度。领域语料里专业缩写、生僻符号特别多基础tokenizer可能把它们切得稀碎导致模型很难学到有效表征。遇到这种情况可以考虑扩展词表加入高频行业词再对embedding层做随机初始化。这个操作会增大embedding层的参数量训练时学习率需要单独调低一些让新增词向量稳定收敛。4. 算力评估、模型部署和上线评估4.1 算力需求估算不同参数量级要多少卡训练前先算清要多少算力别等任务跑起来才发现卡不够。有一个工程上常用的近似公式训练计算量约等于6倍参数量乘以训练token数。以7B模型训练50亿token的行业语料为例算下来约2.1×10^19次浮点运算。假设用8卡A100-80G单卡BF16算力约312 TFLOPS实际训练利用率按40%算每卡有效算力约125 TFLOPS总时长大约5.8小时。这个估算结果和我实测的差距在20%以内可以放心用来做规划。不同参数量级的建议配置我放在下面这张表里方便你按自己的资源情况对照模型规模训练语料量最低卡数建议显存要求耗时估算A100-80G7B5亿token4卡每卡40GB约12小时13B5亿token8卡每卡60GB约16小时14B10亿token8卡每卡70GB约28小时70B10亿token32卡需要ZeRO-3NVMe offload约3天如果只有单卡消费级显卡比如16G显存加32G内存想跑7B模型的CPT全参训练基本不可能但可以用LoRA做参数高效继续训练或者在推理阶段用量化后的模型跑本地部署。训练和推理是两码事很多人把本地能跑和本地能训混为一谈规划时很容易翻车。4.2 训练完之后的部署方案vLLM/Ollama/私有化接口模型训练完只是第一步怎么让业务方用起来才是真问题。我见过太多团队把训练好的模型权重扔给开发结果开发不知道怎么做推理服务化最后用transformers的generate接口硬扛并发一高直接卡死。有实际生产负载的直接上vLLM。它用PagedAttention管理显存支持连续批处理吞吐量比原生transformers提升数倍到十倍是目前开源社区做模型服务的事实标准。服务起来后暴露一个OpenAI兼容接口业务方几乎零成本接入。如果只是内部小范围试用、并发不高Ollama是一个更轻量的选择。它支持GGUF量化格式把训练好的模型导出为GGUF后可以直接跑还能用一条命令启动API服务。像我之前在一个工厂项目里本地用了一台带16G显存的机器部署7B量化模型配合Ollama跑内部问答演示完全够用。对外提供统一服务的场景建议在前面挂一层网关用Higress这类工具代理后端的vLLM服务做路由、限流、观测。企业内部如果要开放给多个系统调用不要直接暴露vLLM端口走网关是规范做法。4.3 评估不是只看loss用业务指标和对比测试说话训练结束后的评估环节很多团队敷衍了事看loss降了就宣布成功这是最大的误区。loss是训练指标不是业务指标loss降了不代表业务满意。我现在的评估体系分三层第一层是通用能力回退测试。用一组标准benchmark比如MMLU、CEval、CMMLU的抽样题对比训练前和训练后的得分。如果通用能力掉太多说明CPT过程中灾难性遗忘失控这个模型需要回炉调整数据配比。第二层是行业知识测试。由业务专家基于真实场景出100到300道题覆盖术语解释、案例分析、规范问答等分别跑基座模型、SFT后模型、CPTSFT后模型比较准确率。注意题目必须是训练语料之外的否则测的是背诵能力不是理解能力。第三层是LLM-as-judge对比测试。把同一个问题丢给训练前和训练后的模型用另一个更强的大模型当裁判对比回答的质量差异同时让人工抽检一部分结果防止误判。这个办法速度快、成本低特别适合用来筛明显变好或变差的case。4.4 上线后的持续监控和数据回流行业模型上线不是终点而是新一轮迭代的起点。我强烈建议在业务系统里记录用户反馈和badcase定期回流到数据池为下一个版本准备弹药。具体来说把线上的badcase按类型打标签知识错误、格式错误、逻辑混乱、安全违规。每周拉一次数据挑出高频问题类型针对性补充语料。这里有个技巧不要只收集问题case要把对应的正确答案也一起整理。问题case告诉你模型哪里不会正确答案告诉你应该怎么教。两个信息合在一起才能形成有效训练数据。同时注意观察线上模型的生成延迟、token消耗、请求失败率这些服务指标。如果准备用量化版模型上线评估阶段就要加上量化前后效果对比确认掉点可接受再推到生产。别让上线环节成为新的瓶颈。5. 避坑合集三个阶段最容易翻车的细节5.1 灾难性遗忘通用能力退化的识别与缓解灾难性遗忘是CPT最隐蔽的坑因为问题不是立刻显现的。训练阶段loss一切正常但部署后业务方反馈模型好像变傻了——基础代码不会写了、简单数学算错了、通用常识乱答了。这些其实就是通用能力被大量领域语料冲垮了。缓解办法有三个第一是数据混合保留15%左右的通用语料陪跑这是成本最低的手段第二是降低学习率把1e-5压到5e-6放慢学习节奏给模型更多空间去平衡新旧知识第三是训练过程中定时跑通用能力快照测试每训练一段就测一次MMLU的抽样题一旦发现明显下滑就提前停止而不是等全部epoch跑完。我习惯在训练脚本里挂一个定时评测逻辑每500步自动跑20道通用题和20道领域题记录分数变化趋势。有了这个数据就能判断当前训练是否处在一个合理的平衡点上。5.2 幻觉率和安全性的波动CPT之后幻觉不降反升这个问题也经常出现。原因主要有两个一个是语料里存在错误信息和自相矛盾的内容模型学会了但学歪了另一个是模型对领域知识过于自信即便不知道也会强行输出宁可不回答也不愿意承认不懂。针对第一个原因清洗语料时可以把信息可信度作为一维过滤指标。来自于内部正式制度、审计报告、专家审核过的文档优先级最高论坛讨论、未经验证的技术博客优先级调低甚至直接过滤。针对第二个原因在后续SFT阶段刻意加入一批拒答样本——数据里出现它不会的问题时教模型回答这个问题我暂时没有可靠信息建议参考XX文档这是很有效的幻觉抑制手段。我还想多提醒一句现在有些团队开始做投毒测试往训练语料里掺恶意样本验证模型是否会被误导。如果你的数据来源包含外部爬取内容建议在清洗阶段就加入内容安全审查别等模型上线了才发现语料被人动过手脚。5.3 工具链与版本管理的坑训练了一个月最后发现模型效果不对一问才知道训练脚本里用的transformers版本和当时验证脚本的不一致tokenizer的预处理逻辑都变了复现根本对不上。这类工具链问题在CPT项目里太常见了。我的做法是三步走第一用Docker镜像固定基础环境PyTorch、CUDA、transformers、DeepSpeed的版本全部写进镜像文件不随手升级第二训练代码进入版本管理每次跑训练打tag记录对应的数据集哈希值、模型基座版本、超参配置第三checkpoint和最终权重分目录存放命名里带上训练日期和数据版本号方便回滚到任意历史状态。5.4 最后想说的几条实战心得CPT这个方向听起来高大上做起来全是脏活累活。但恰恰是这些脏活累活决定了模型的最终效果模型架构大家都差不多区别就在数据处理和训练细节上。我自己的体会是CPT项目最容易失败的环节是数据工程最容易被低估的环节是评估设计最让人头疼的环节是训练稳定性。这三个环节顶住了整个项目就成功了大半。最后分享一个非常实用的收尾动作。模型训练完让几个业务方的真实用户先用一周收集他们的吐槽再决定要不要做下一轮训练。技术指标再好看业务方说还是不敢用就说明离生产还有距离。把这条反馈闭环做好行业模型的迭代节奏会健康很多。