CPT 实战指南：企业如何把通用大模型训练成行业模型
作者：吴佳浩Alben
撰稿时间：2026.5.3 更新时间：2026.8.18
今天咱们的目标读者是：负责大模型落地的工程师、算法团队、AI Infra 团队
筒子们今天咱们要讲的的不是"CPT 是什么"，而是企业真正需要回答的四个问题：什么时候做 CPT、用什么数据、如何训练、怎样证明投入值得。
为什么企业还需要训练自己的行业模型？
通用大模型越来越强，但企业仍可能需要行业模型。原因通常不是"通用模型完全不知道行业知识"，而是企业要把成本、稳定性、专业性和数据控制放在一起考虑。
| 企业诉求 | 通用模型 API 的限制 | 行业模型可能提供的收益 |
|---|---|---|
| 成本 | 高频、长上下文调用的累计费用较高 | 通过私有化部署或短上下文降低单位任务成本 |
| 稳定性 | 模型版本、服务策略和输出风格可能变化 | 固定模型版本，配合 SFT 和评测控制输出 |
| 专业性 | 认识术语不等于掌握行业表达和概念关系 | 适配领域语言、文档结构和任务分布 |
| 数据控制 | 敏感数据需要经过外部 API 边界 | 在企业环境中保留数据和推理链路 |
| 延迟 | 网络调用和长上下文会增加时延 | 通过参数内化稳定能力，减少部分上下文负担 |
例如，通用模型可能知道什么是债券和久期，但金融研究助手还需要理解券商研报的表达方式、评级体系、监管文件语言和指标之间的关系。行业模型的价值不只是"知道更多词"，而是让模型更接近行业文本和任务的数据分布。
但这不意味着训练行业模型总比调用更强的通用模型划算。企业应先比较三条路线：
只有当行业模型在长期总成本、输出稳定性、领域收益或数据控制方面具有明确优势时，企业才应投入 CPT。
CPT 真正改变模型什么能力？
CPT 改变的首先是模型对领域文本分布的拟合，不是直接把模型变成某个行业专家。可以把影响拆成三个层次：
| 能力 | CPT 的典型影响 |
|---|---|
| 认识行业术语 | 通常较明显 |
| 生成行业表达 | 通常较明显 |
| 学习领域知识关联 | 可能提升，需要独立评测 |
| 复杂行业推理 | 不一定，不能仅凭 PPL 推断 |
| 工具调用 | 不会自动获得，通常需要 SFT 或系统设计 |
| 安全策略和拒答 | 不会自动获得，需要专门训练和运行时控制 |
例如，医疗 CPT 可能让模型更熟悉疾病、药物和临床文本的表达方式，但这不等于模型获得医生资质，也不等于它能在没有来源核验的情况下提供安全诊疗建议。
LoRA CPT 与全参数 CPT
LoRA CPT 和全参数 CPT 都可以用于领域适配，但定位不同：
text
LoRA CPT：
Base Model 权重冻结 + 低秩增量参数
↓
快速验证数据价值和领域适配方向
全参数 CPT：
模型参数整体更新
↓
评估长期维护的行业基础模型能力LoRA CPT 更适合作为数据价值验证和快速适配方案。它能改变模型的输出分布，但受低秩增量的表达能力、注入位置和训练配置限制。它的真正价值不仅是省显存，更是降低错误方向的试错成本。LoRA CPT 不是全参数 CPT 的廉价替代品，而是扩大到全参数训练前的低成本实验工具。若目标是构建长期维护的行业基础模型，通常仍需要评估全参数 CPT 或持续预训练方案。最终是否全参数训练，要由独立评测、成本和部署需求共同决定。
RAG、CPT，还是直接换更强模型？
| 业务问题 | RAG | CPT | 更强通用模型 |
|---|---|---|---|
| 今天发布的新政策 | 适合 | 不适合 | 可辅助理解，但仍需新信息 |
| 内部知识库查询 | 适合 | 通常不优先 | 可与 RAG 配合 |
| 行业报告生成 | 部分适合 | 适合稳定的领域表达 | 适合快速验证 |
| 专业写作风格 | 有限 | 适合长期稳定的语言模式 | 通常可通过提示词解决一部分 |
| 固定格式输出 | 不负责 | 不负责 | 优先 SFT 或结构化约束 |
| 降低上下文长度 | 有限 | 可能有帮助 | 取决于模型和提示设计 |
| 降低长期推理成本 | 视检索链路而定 | 可能更有优势 | API 成本需要长期核算 |
| 知识需要实时更新 | 适合 | 不适合 | 仍需 RAG 或 API |
| 需要私有化部署 | 可部署 | 可部署 | 取决于模型许可和硬件 |
可以用一句话概括：
经常变化的事实放在外部；长期稳定的行业语言和任务模式，才值得考虑写入参数。是否选择 CPT，还要和"直接使用更强模型"的总成本与效果做对比。
一、什么时候应该做 CPT
可以用下面的表格快速判断：
| 业务现象 | 优先方案 | 是否优先考虑 CPT |
|---|---|---|
| 只缺少最新文档、实时数据或长尾资料 | RAG | 通常不考虑 |
| 模型不会按要求回答，格式或风格不稳定 | SFT（监督微调，Supervised Fine-Tuning） | 通常不先做 CPT |
| 模型只是不认识少量术语，任务结构简单 | RAG / SFT / LoRA | 先做轻量实验 |
| 领域语言和概念关联在同领域基准上明显偏弱 | CPT PoC | 值得验证 |
| 稳定知识重复检索已成为主要延迟或成本来源 | CPT + SFT | 评估是否内化部分能力 |
| 领域数据每天变化 | RAG / API / 数据库 | 不应依赖 CPT |
| 高质量领域数据不足 50M token | RAG / SFT / LoRA | 暂不做全参数 CPT |
1. 领域语言分布发生了明显变化
如果需求只是让模型知道几个新名词，RAG 或 SFT 通常已经够用。CPT 更适合以下情况：
- 领域术语密集，且术语之间存在稳定的共现关系；
- 文本结构、表达习惯和通用互联网语料差异较大；
- 任务需要跨文档、跨概念组织领域语言；
- 与同领域、同分布的基准模型或 Base Model 对照相比，模型在领域验证集上的 PPL 明显偏高；
- 如果大量稳定的领域知识在每次推理中都需要重复检索和拼接，且上下文开销已经成为主要延迟或成本来源，可以评估通过 CPT 内化部分稳定能力；
- 领域知识相对稳定，不需要每天更新。
例如，金融领域中"久期、凸性、信用利差、Basel III"并不是孤立词条。若任务要求模型持续生成研究报告、理解指标之间的关系并保持行业表达，单纯在提示词里拼接定义不一定足够。此时可以评估 CPT。
但对于当日行情、实时政策、库存和价格等时效性信息，知识应该继续放在 RAG 或业务系统中。CPT 不适合替代实时数据源。
2. 数据量达到值得训练的范围
没有统一的 token 门槛。下面只是企业做资源规划时的经验区间：
| 去重后的高质量领域 token | 通常优先考虑 | 说明 |
|---|---|---|
| < 50M | RAG / SFT / 小规模 LoRA | 全参数 CPT 通常不划算，过拟合风险较高 |
| 50M~数百 M | LoRA CPT / 小规模对照实验 | 用于验证数据是否有价值 |
| 数百 M~数 B | LoRA CPT 或小规模全参数 CPT | 可以评估稳定的领域适配收益 |
| 数 B 以上 | CPT 更值得进入正式评估 | 是否全参数训练仍取决于模型规模和预算 |
这些数字只能用于项目规划，不代表训练成功门槛。CPT 效果还取决于数据重复率、质量、领域跨度、训练目标、学习率、通用语料回放比例，以及训练 token 与模型参数量的关系。高质量的 300M token 监管文件、研报和年报，可能比 20B token 的低质量网页语料更有价值。
| 去重后的高质量领域 token | 适合用途 |
|---|---|
| 50M~500M | 验证领域数据价值 |
| 500M~数 B | 稳定领域适配实验 |
| 数 B~数十 B | 生产级领域继续训练候选 |
| 数十 B 以上 | 大型行业模型的长期训练候选 |
正式实验应同时记录有效 token 数、重复率、数据来源占比、领域相关性、模型规模、目标任务收益和 GPU hours。不要把 token 数单独当作是否成功的判据。
3. 数据规模与模型规模的关系
模型越大，通常越需要更多样、质量更稳定的训练数据，但不存在"1B token + 70B 模型 = 行业模型"的简单关系。模型规模、领域跨度、数据质量和训练强度必须一起评估。小模型实验只能验证数据方向，不能保证大模型会按比例获得同样收益。
4. 是否需要把能力稳定地放进参数
CPT 的优势是推理时不必总依赖长篇检索上下文，模型可以更自然地生成领域语言。但这也带来两个代价：
- 更新知识需要重新训练或增量训练；
- 领域训练可能造成通用能力遗忘。
因此，企业应把"需要永久内化的领域能力"和"需要实时更新的业务事实"分开：
text
稳定的领域语言与概念模式 → CPT
实时、长尾、可追溯事实 → RAG / API / 数据库
行为规范、格式、拒答策略 → SFT / Preference Training二、先做决策实验，不要直接训练生产模型
最常见的错误路线是：
text
下载 70B Base Model
↓
准备几十到上百 B token
↓
搭建多机训练集群
↓
训练数周
↓
才发现数据、评测集或训练配比有问题更稳妥的路线是：
text
7B/8B Base Model
↓
50M~200M token 快速实验
↓
LoRA CPT
↓
Domain PPL + 行业评测 + 通用能力评测
↓
Go / No-Go
↓
扩大数据、模型和训练规模PoC 的目的不是得到最终行业模型，而是回答一个问题：
这批数据在独立测试集上是否产生了稳定的领域收益？
如果小模型和 LoRA 在合理的训练配置下完全看不到收益，优先检查数据质量、领域任务定义和评测集，而不是直接扩大到 70B。
Go / No-Go 判定
阈值应在实验开始前由业务团队和算法团队共同确定。下面是一份可直接改写到项目验收单中的示例：
text
Go：
- 独立行业测试集达到预设提升目标；
- Domain PPL 在独立验证集上稳定下降；
- 通用能力下降不超过预设阈值；
- 至少两次配置相近的实验得到一致方向；
- 训练成本和推理成本符合预算。
No-Go：
- 只有训练集或近重复测试集提升；
- Domain PPL 下降，但行业任务没有提升；
- 通用能力明显退化；
- 结果只在单一 prompt 或单一评测集上成立；
- RAG 或业务 API 能以更低成本解决同一问题。不要把示例中的阈值当作通用标准。比如"行业分数提升 10%"是否足够，要看业务基线、错误成本和上线收益。
最小对照实验
建议至少保留以下实验：
| 实验 | 领域数据 | 通用回放 | 用途 |
|---|---|---|---|
| Base baseline | 0% | 0% | 评估原始模型 |
| Domain-only | 100% | 0% | 观察领域收益和遗忘 |
| Mixed-data | 70% | 30% | 观察领域与通用能力的平衡 |
| LoRA ablation | 按实验设计 | 可选 | 观察 rank 和训练强度的影响 |
所有实验应固定模型版本、Tokenizer、评测脚本、数据划分和推理参数。
三、CPT 数据工程 Pipeline
CPT 的成败通常更受数据影响，而不是受训练脚本影响。生产管线可以拆成以下阶段：
text
Raw Corpus
↓
Extraction
↓
Filtering / Classification
↓
Deduplication
↓
Safety / Copyright / PII
↓
Train / Validation / Test Split
↓
Tokenizer
↓
Sequence Packing / Indexed Dataset
↓
Training1. 完整的数据处理链路
CPT 的成败通常更受数据影响，而不是受训练脚本影响。生产管线可以拆成以下阶段：
- PDF 多栏顺序是否正确；
- 表格是否被错误展开；
- 公式和单位是否损坏；
- OCR 是否引入大量字符错误；
- HTML 导航、广告和脚本是否被清除；
- 文档标题、章节和页码是否保留。
建议保留原始文件和抽取结果的映射关系，便于追溯和重新处理。
2. 数据污染与评测集泄漏
行业语料很容易出现"训练文档 → 自动生成问答 → 评测集"的间接污染。测试集必须与训练数据在文档级和语义级上隔离：
- 同一法规、报告或知识库文档的不同版本不能随机拆到训练集和测试集；
- 自动生成问答的原始文档不能进入测试集；
- 测试集原文不能出现在训练语料中；
- 至少做段落级近似去重，重要任务再做语义相似度检查；
- 测试集、答案和评分标准要版本化，并记录创建时间；
- 参与训练数据制作的人员不应直接根据测试集调参。
如果测试集被污染，模型分数上升不能证明发生了泛化。报告中应说明数据划分规则和污染检查方法。
3. Filtering
过滤不应只依赖通用质量模型。专业文档可能句子短、符号多，但仍然具有训练价值。可以组合使用：
- 语言识别；
- 文档长度和字符比例规则；
- 领域分类器；
- 质量评分；
- 黑名单和重复模板；
- 人工抽样审核。
过滤器必须在领域样本上做误杀率检查。过严的过滤会把真正有价值的标准、公式和术语一并删除。
4. Deduplication
至少应区分三类去重：
- 文档级精确去重：文件哈希或规范化文本哈希；
- 段落级近似去重：MinHash、SimHash 或 n-gram 相似度；
- 语义级去重：对高价值语料使用 embedding 相似度。
内部知识库、网页转载和模板化报告的重复率可能很高。训练前应统计：
text
原始文档数
清洗后文档数
去重后文档数
原始字符数
有效 token 数
重复率
各来源占比5. Safety、版权和 PII（大模型中的 PII 指的是个人身份可识别信息Personally Identifiable Information）
企业需要明确数据使用边界，尤其是：
- 个人姓名、联系方式、身份证号、病历号；
- 客户合同和内部机密；
- 未获授权的版权内容；
- 受访问权限控制的知识库；
- 不应被模型复述的敏感信息。
脱敏不能只做一次正则替换。应保留审计记录，并对脱敏后的训练文本做抽样复核。
6. 存储和训练格式
原始数据可以采用 JSONL 或 Parquet：
json
{"text":"金融市场中，久期表示债券价格对利率变化的敏感程度......","source":"internal_report_001"}但大规模训练通常不会在每个 epoch 重新解析 JSON。常见链路是：
text
JSONL / Parquet
↓
Tokenizer
↓
Token IDs
↓
Indexed Dataset / mmap binary
↓
Sequence Packing
↓
Training Batch文档边界是否跨样本拼接，要根据训练框架和数据语义决定。连续预训练通常可以进行 packing，但应避免把大量不相关的特殊控制信息拼入同一序列，并记录 EOS、文档边界和截断策略。
四、CPT 训练目标与工程框架
1. CPT 的训练目标
CPT 使用连续文本进行 causal language modeling。给定 token 序列：
text
输入： [x1, x2, x3, ..., xN]
目标： 在每个位置预测下一个 token
损失： L = -Σ log P(x_t | x_<t>)因此，CPT 数据通常是 text 字段或其 tokenized 形式，而不是 instruction、input、output 三段式 SFT 数据。CPT 不需要为每段文本人工编写问题，但仍需要验证文本质量、文档边界、EOS、截断和 packing 策略。
本节只补充训练目标和工程差异，能力定位见前文。CPT 使用连续文本和 causal language modeling，训练强度通常低于原始预训练；SFT 使用高任务相关性的指令数据，直接优化条件回答行为。
2. 技术栈全景
text
Domain Corpus
↓
Spark / Ray / Datatrove / Datasets
↓
Tokenized Dataset
↓
PoC：LLaMA-Factory / Axolotl / HF Trainer + PEFT
生产：Megatron-Core / Megatron-LM / DeepSpeed / FSDP
↓
lm-evaluation-harness / OpenCompass / 自建行业 Benchmark3. 分阶段选择
| 阶段 | 模型规模 | 推荐框架 | 目标 |
|---|---|---|---|
| 数据验证 | 任意 | Datasets、Spark、Datatrove、Ray | 统计 token、质量和重复率 |
| CPT PoC | 7B/8B | LLaMA-Factory、Axolotl、PEFT | 一周内验证数据价值 |
| 中等规模 | 14B~32B | DeepSpeed、FSDP、Axolotl | 训练领域模型初版 |
| 生产级 | 70B+ | Megatron-Core、DeepSpeed、FSDP | 提升吞吐和分布式效率 |
LLaMA-Factory 更适合 LoRA CPT 和小规模实验。它适合验证数据读取、训练目标和评测流程，但不代表它是 70B 级别、数十 B token 生产 CPT 的最佳方案。达到几十亿 token、几十张以上 GPU 或 70B 级别全参数训练时，应重新评估 Megatron-Core、NeMo、DeepSpeed 或 FSDP。
五、资源估算与训练配置
1. 计算量估算
Dense Transformer 的训练 FLOPs 可以用下面的公式做初步预算：
text
Training FLOPs ≈ 6 × 参数量 × 训练 token 数实际 GPU hours 还取决于：
- MFU；
- 序列长度；
- FlashAttention；
- 激活检查点；
- TP、PP、DP 配置；
- 网络带宽；
- 数据读取和 checkpoint 开销；
- 训练是否发生中断和重试。
因此，表格估算只能用于初步排期。举例来说，70B 模型训练 100B token 时：
text
Training FLOPs ≈ 6 × 70B × 100B
≈ 4.2 × 10²² FLOPs这个数字不能直接换算成训练天数。正式预算必须结合目标硬件的实测 tokens/s 或 MFU，再加上数据读取、通信、checkpoint、验证和失败重试开销。
2. 训练成本核算模板
实际预算不要只按理论 FLOPs 计算。可以先记录下面这些指标：
text
训练成本 ≈ GPU 数量 × 单卡小时价格 × 训练小时数 × 重试系数
+ 存储成本 + 数据处理成本 + 评测成本
训练小时数 ≈ 有效训练 token 数 / 实测 tokens_per_second| 成本项 | 记录值 |
|---|---|
| GPU 数量 | |
| 单卡价格 / 小时 | |
| 实测 tokens/s | |
| 有效训练 token 数 | |
| 预计训练小时 | |
| checkpoint 次数 | |
| 失败重试次数 | |
| 总 GPU hours | |
| 存储和数据处理成本 | |
| 总成本 |
预算时还要考虑 checkpoint 保存、验证集评测、多机通信、集群排队和失败重试，这些开销可能明显高于理论估算。
3. 量级参考
| 模型规模 | CPT token 量 | 训练配置参考 | 结果用途 |
|---|---|---|---|
| 7B~8B | 50M~1B | 单机多卡 LoRA 或小规模全参数 | 数据价值验证 |
| 7B~8B | 1B~10B | 多卡 LoRA / FSDP | 稳定性和配比实验 |
| 32B | 数 B~数十 B | 多机 FSDP、DeepSpeed 或 Megatron | 领域模型初版 |
| 70B+ | 数十 B 以上 | Megatron-Core + TP/PP/DP | 生产级持续训练 |
不要把"GPU 数量"和"训练质量"直接画等号。小规模验证的关键是可复现和可比较，而不是堆卡。
4. 典型训练配置
这里给出的是搜索空间，不是标准 recipe。
yaml
model: Qwen/Llama Base Model
mixture:
domain_data: tune
general_replay: tune
training:
objective: causal_language_modeling
optimizer: AdamW
learning_rate: tune
warmup_ratio: tune
scheduler: cosine_with_warmup
precision: bf16
sequence_length: tune
epochs: tune
search_space:
learning_rate: 5e-6 ~ 2e-5
domain_data_ratio: 50% ~ 100%
epochs: 0.5 ~ 2
lora_rank: 32 ~ 128上面是实验搜索空间，不是通用答案。对不同领域和模型，应该通过小规模对照实验调节：
- 领域数据与通用回放比例；
- 学习率和 warmup；
- LoRA rank、alpha 和 target modules；
- 序列长度；
- global batch size；
- 是否冻结 embedding 或部分层；
- checkpoint 和 early stopping 策略。
对于 70B 级别、长上下文训练，常见的工程手段包括 FlashAttention、Activation Checkpointing、TP、PP、ZeRO-3 或 FSDP。但具体组合必须通过目标集群实测，不能把它们当作固定配置直接套用。
六、用 LLaMA-Factory 快速验证 CPT
1. 安装
bash
git clone https://github.com/hiyouga/LLaMA-Factory.git
cd LLaMA-Factory
pip install -e .2. 数据准备
预训练数据是连续文本：
json
[
{"text":"糖尿病是一种慢性代谢疾病，其主要病理机制包括......"},
{"text":"二型糖尿病治疗指南建议根据患者的血糖水平......"}
]它不是 SFT 的指令数据：
json
{
"instruction":"解释二型糖尿病的治疗原则",
"input":"",
"output":"......"
}数据集字段和注册方式可能随 LLaMA-Factory 版本变化。实际运行前应以当前版本文档和仓库中的数据集配置为准，并先用极小数据集验证：
text
数据集是否被正确发现
text 字段是否被正确读取
Tokenizer 是否正常工作
loss 是否能下降
checkpoint 是否能保存和恢复3. 示例配置
在正式训练前，先用 2~3 条样本验证数据集注册和字段映射。不同 LLaMA-Factory 版本的 dataset_info.json 规范可能不同，应以当前版本仓库为准，不要直接复制旧版本配置。
启动成功的最低检查项：
text
- 没有 dataset mapping 或字段解析错误；
- 第一个 step 能正常计算 loss；
- loss 不是 NaN；
- checkpoint 能正常保存；
- checkpoint 能重新加载；
- 验证集 PPL 能正常计算。4. CPT 常见失败模式
loss 降低，但行业能力没有提升
常见原因包括：
- 训练数据过于容易；
- 数据重复率过高；
- 测试集被训练数据或近似文本污染；
- 训练目标与业务任务不一致。
排查时应优先检查独立验证集、数据去重和改写后的行业测试任务。
行业能力提升，但聊天能力下降
Domain-only CPT 容易放大领域信号并造成通用能力遗忘。可以加入 General Replay，先从领域数据 70%、通用回放 30% 的配比做对照实验，再根据评测结果调整。
模型开始胡说行业知识
CPT 可能增强了行业语言的流畅度，却没有保证事实正确性。模型"说得像"不等于"说得对"。应结合 RAG、来源引用、事实核验任务和拒答策略，不能只依靠参数记忆。
训练日志和配置不能只保留最终 adapter。至少记录：
yaml
stage: pt
model_name_or_path: Qwen/Qwen3-8B
dataset: medical_corpus
finetuning_type: lora
lora_rank: 64
lora_alpha: 128
cutoff_len: 8192
learning_rate: 1.0e-5
num_train_epochs: 1.0
bf16: true
gradient_checkpointing: true
logging_steps: 10
save_steps: 500启动：
bash
llamafactory-cli train cpt.yaml至少记录：
text
Base Model 版本
Tokenizer 版本
数据版本和 hash
有效 token 数
训练步数
学习率
LoRA 配置
实际 tokens/s
GPU hours
验证集 PPL
评测结果七、生产级 CPT 为什么通常切换到 Megatron、DeepSpeed 或 FSDP
当模型达到 32B70B，数据达到数十亿 token，序列长度达到 16K32K 后，瓶颈通常不再是"能否启动训练"，而是吞吐、显存、通信和恢复能力。
| 技术 | 主要解决的问题 |
|---|---|
| Tensor Parallelism | 切分单层矩阵计算 |
| Pipeline Parallelism | 按层切分模型 |
| Data Parallelism | 扩展样本吞吐 |
| ZeRO / FSDP | 切分参数、梯度和优化器状态 |
| FlashAttention | 降低长序列 attention 开销 |
| Activation Checkpointing | 用重计算换显存 |
| Indexed Dataset + mmap | 降低训练期间文本解析和 IO 开销 |
生产环境还需要把以下问题纳入设计：
- checkpoint 是否能在中断后恢复；
- 数据和模型版本是否可追溯；
- 多机网络是否成为瓶颈；
- 训练期间如何跑验证集；
- 如何监控 loss、PPL、tokens/s、MFU 和显存；
- 如何判断训练已经过拟合；
- 如何回滚到上一个可用 checkpoint。
八、数据配比与训练策略
1. Domain Data 与 General Replay
领域数据和通用回放的比例会影响领域收益与通用能力遗忘之间的平衡。70% / 30% 只是一个实验起点，不是行业标准。对代码、医疗、金融、法律等不同领域，最佳 mixture 可能完全不同。真正应该优化的是"领域收益 / 通用能力退化"的 Pareto 平衡：
| 实验 | 领域数据 | 通用回放 | 主要观察 |
|---|---|---|---|
| A | 100% | 0% | 领域收益上限和遗忘风险 |
| B | 70% | 30% | 常见的平衡起点 |
| C | 50% | 50% | 更保守的通用能力保持方案 |
每组实验至少比较：
- 独立 Domain PPL；
- 通用 benchmark；
- 行业任务集；
- 训练 loss 和验证 loss；
- 推理延迟与 GPU hours。
如果 100% Domain 训练带来明显领域收益但通用能力下降，可以增加 General Replay、降低学习率、减少训练步数，或改用 LoRA 等更保守的方案。如果 50% Domain 的领域变化不足，则需要重新检查数据质量、训练强度和任务定义，而不是只提高领域数据比例。
2. 学习率、训练强度和遗忘
CPT 通常使用低于原始预训练阶段的学习率。学习率过高或重复训练轮数过多，可能破坏 Base Model 已有能力。建议通过短跑实验观察：
- 领域验证集 loss 是否继续下降；
- 通用回放集 loss 是否明显恶化；
- 行业评测是否出现过拟合；
- 不同 checkpoint 的能力曲线是否一致。
九、CPT 与 SFT 的工程区别
| 维度 | CPT | SFT |
|---|---|---|
| 目标 | 拟合领域文本分布 | 学习指令和输出行为 |
| 数据 | 连续文本 | 指令、输入、回答 |
| 规模 | 通常为百万至数十亿 token | 通常为数千至数百万样本 |
| 训练目标 | next-token prediction | 条件生成损失 |
| 训练周期 | 较长 | 较短 |
| 主要收益 | 术语、表达和领域关联 | 格式、风格、任务执行 |
| 风险 | 遗忘和领域过拟合 | 过拟合模板、回答风格偏移 |
不要把企业文档全部转换成问答对，再把 SFT 结果称为 CPT。文档转问答再做 SFT 可能对特定问题有效，但它主要训练的是条件回答行为，不能自动替代领域连续文本上的 CPT。
CPT、SFT 和 Preference Training 也不一定严格执行一次 CPT → 一次 SFT 的线性流程。复杂的代码、Agent 或推理模型可能多次交替进行继续预训练、监督微调和偏好对齐，具体顺序由数据、任务和评测结果决定。
十、效果评估：不要只看训练 loss
1. Domain Perplexity
PPL 是 CPT 最直接的内在指标之一。评估时必须使用独立的领域验证集，不能直接使用训练数据：
text
Base Model Domain PPL: A
After CPT Domain PPL: BPPL 下降说明模型更好地拟合了领域文本分布，但不等于业务能力一定提升。可能出现以下情况：
- PPL 下降，但问答能力没有提升；
- 训练集 PPL 下降，独立集 PPL 不变；
- 行业能力提升，但通用能力明显退化；
- 模型记住了文档，却不能迁移到新的问法。
因此 PPL 只能作为内在信号，不能单独作为上线依据。
2. 通用能力
根据业务需要选择 MMLU、CMMLU、C-Eval、GSM8K、HumanEval、MBPP 等评测集。不要为了追求所有通用指标不下降而拒绝任何领域适配，也不要忽略明显退化。阈值应在项目开始前确定。
3. 行业能力
公开 benchmark 只能作为参考。企业应建立独立的业务测试集，覆盖：
- 常见任务；
- 长尾任务；
- 跨概念任务；
- 反事实或改写问题；
- 需要引用来源的任务；
- 容易诱发幻觉的任务；
- 不应回答的任务。
测试集必须与训练数据去重，并限制参与训练数据制作的人员直接调参到测试集。
4. 遗忘和成本
建议在训练前后统一记录：
| 指标 | CPT 前 | CPT 后 | 变化 |
|---|---|---|---|
| Domain PPL | A | B | 越低越好 |
| 通用能力 | C | D | 下降是否可接受 |
| 行业能力 | E | F | 是否达到目标 |
| 推理延迟 | G | H | 是否影响服务 |
| 训练 GPU hours | - | I | 成本 |
最终判断不是"行业分数是否上升"这一项，而是：
text
独立行业能力提升
+ 通用能力退化可接受
+ 成本与收益匹配
+ 结果能够复现
= 才有扩大规模的理由十一、企业 CPT 最小闭环
一个小团队可以按下面的节奏组织第一次验证：
| 时间 | 工作 | 产出 |
|---|---|---|
| Day 0 | 固定 Base Model、Tokenizer、评测协议 | Baseline |
| Day 1~3 | 数据清洗、去重、token 统计 | 数据报告 |
| Day 4~6 | 7B/8B LoRA CPT | PoC checkpoint |
| Day 7 | 计算独立 Domain PPL | 内在指标 |
| Day 8~9 | 运行通用和行业评测 | 对比表 |
| Day 10 | 计算 GPU 成本并做 Go / No-Go 决策 | 决策记录 |
如果结果没有提升，按下面顺序排查：
- 测试集是否真的覆盖业务任务；
- 训练文本是否与任务相关；
- 是否存在严重重复或污染；
- 数据字段和训练目标是否配置正确；
- 学习率、训练步数和 LoRA rank 是否合理；
- 是否把需要 RAG 的实时知识错误地交给 CPT；
- 是否把行为问题误判成知识问题。
只有当小规模实验在独立数据上反复得到稳定收益，才进入 14B/32B 或 70B 级别训练。
十二、模型部署与上线
CPT 通常不会改变 Base Model 的参数规模。比如：
text
Qwen-32B Base
+ CPT
= 仍然是约 32B 参数模型CPT 完成后，部署团队仍需重新测量：
- checkpoint 的实际存储大小；
- 推理显存和 KV Cache 占用；
- batch size、并发和 tokens/s；
- 量化后的精度变化；
- vLLM、TensorRT-LLM 或其他 serving runtime 的兼容性；
- 长上下文和 RAG 场景下的端到端延迟。
如果使用 LoRA CPT，部署形态还要区分"Base Model + Adapter"与"合并后的模型权重"。合并可以简化服务拓扑，但会影响存储、回滚和多 Adapter 管理；不合并则便于按租户或领域切换 Adapter，但服务端需要明确支持和压测。
十三、行业模型是持续迭代的系统
CPT 不是行业模型的终点。企业上线后仍会积累新的业务数据、错误案例和评测样本，模型需要进入持续迭代周期：
一个典型生命周期可以是：
| 时间 | 阶段 | 主要工作 |
|---|---|---|
| Month 0 | Base Model | 固定模型、Tokenizer 和基线评测 |
| Month 1 | Domain CPT | 训练领域语言和知识分布 |
| Month 2 | SFT | 对齐任务、格式、风格和安全策略 |
| Month 3 | 上线 | RAG、工具调用、监控和灰度发布 |
| Month 6 | 增量迭代 | 加入新增数据和错误样本，重新评测 |
| Month 12 | 模型升级 | 对比新 Base Model，决定继续训练或迁移 |
持续训练不等于把所有线上日志直接喂给模型。每一轮迭代都需要重新做权限检查、PII 脱敏、去重、数据划分和回归评测。
十四、企业生产链路总览
行业模型不是一个 checkpoint，而是一套持续进化的系统。CPT、SFT、偏好对齐、RAG、工具和数据飞轮分别承担不同职责，最终通过线上反馈和离线评测形成迭代闭环。
十五、最终决策清单(筒子们不妨看看我的建议)
- 先区分信息问题、行为问题和领域分布问题，分别评估 RAG、SFT 和 CPT。
- 不把 token 数当作成功门槛，用数据质量、重复率、领域相关性、模型规模和业务收益综合判断。
- 先用 7B/8B + LoRA 低成本验证数据价值，再决定是否扩大模型和 GPU 规模。
- CPT 数据是连续领域文本，不是自动生成的问答对。
- 数据管线必须包含抽取、过滤、去重、安全检查、数据划分和 token 统计。
- PPL 应在同领域、同分布的独立验证集上比较，不能简单拿通用文本 PPL 与领域文本 PPL 横向比较。
- 70% / 30% 只是 Domain Data 与 General Replay 的实验起点，不是固定 recipe。
- LLaMA-Factory 适合 PoC；大规模生产训练应根据吞吐和分布式需求评估 Megatron-Core、NeMo、DeepSpeed 或 FSDP。
- CPT 通常不会增加模型参数量，但部署前仍要重新验证显存、KV Cache、量化、吞吐和 serving runtime 兼容性。
- 所有行业评测都应使用独立测试集，并同时观察通用能力遗忘、事实性和推理迁移。
- 真实实验结果必须来自可复现的模型、数据、脚本和推理配置，不能用示意分数代替验收结果。
- CPT、SFT 和 Preference Training 可能多次交替，行业模型不是一个 checkpoint，而是一套持续进化的系统。
总结
CPT 从来不是"有数据就训练"，而是一个投资决策问题。
真正成熟的企业不会一开始就投入数百张 GPU 去赌一个方向，而是遵循低成本验证 → 小规模训练 → 独立评测 → 大规模投入的闭环：先用 LoRA 和小规模数据证明领域数据确实能够带来收益，再用独立评测证明模型能力真的发生了迁移，最后才值得用大规模 GPU 将这种收益放大。
很多团队失败，并不是训练技术不过关，而是在没有验证 ROI 的前提下，就把算力投入到了一场并不确定的实验中。
记住一句话：GPU 只是放大器，数据决定上限，评测决定方向，而业务价值才决定这笔训练是否值得。
当企业真正建立起数据 → CPT → 评测 → 业务反馈 → 持续训练的闭环后，大模型就不再是一次性的项目，而会逐渐沉淀为企业最核心的 AI 能力和长期竞争壁垒。
下一代企业之间真正拉开差距的，不会是谁调用了更大的 Foundation Model，而是谁能够持续把行业知识、高质量数据和业务经验，沉淀成只属于自己的 Foundation Model。
今天就讲到这里 筒子们 ，See ya！！！