大模型怎么训练？预训练与微调两条路线对比

一、对比背景：为什么这个选择如此关键

很多人对“大模型训练”的理解停留在“喂数据、跑显卡”，但真实的大模型生产是一条完整的流水线，通常包含九个环节：

数据获取 → 数据处理 → Tokenizer 构建 → 预训练→ 监督微调→ 强化学习对齐（RLHF/DPO）→ 评估对齐 → 部署推理 → 持续迭代（数据飞轮）

在这条流水线上，技术团队面临的最关键的分叉点是：从零开始做预训练，还是基于已有基座模型做微调与对齐？ 这两条路线直接决定了数据规模、算力预算、团队结构乃至项目成败。本文围绕这两条路线展开系统对比，并覆盖全流程中的关键难点。

二、对象定义：两条路线分别是什么

路线A：从零预训练（Full Pre-training）

从随机初始化的模型参数出发，使用海量无标注语料训练出一个通用基座模型。训练数据来源通常包括：

• 网络爬取：使用爬虫程序系统性遍历和下载网页内容；
• 公共网页语料：由非营利组织维护的开放网络爬取数据集，规模可达数十亿网页，是几乎所有基座模型的基础语料来源；
• 数据许可：从出版商、数据供应商处购买或授权获取的高质量专有数据；
• 代码仓库、书籍、论文等补充语料。

预训练的目标是让模型掌握语言规律、世界知识与推理的“底子”，它决定模型能力的上限。

路线B：基于基座模型的微调与对齐（SFT + RLHF/DPO）

以训练完成的基座模型为起点，分两步走：

1. 监督微调（SFT）：用高质量的“指令—回答”样本，教会模型听懂指令、按预期格式回答；
2. 偏好对齐（RLHF/DPO）：RLHF 通过“奖励模型 + 强化学习”让模型输出向人类偏好靠拢，但训练链路长、稳定性差；DPO 则绕开显式奖励模型，直接用偏好数据对进行优化，工程上更简单、更稳定。

这条路线不追求“重新教会模型知识”，而是塑造“模型怎么回应”。

三、相同点分析

尽管两条路线的投入量级差异巨大，但在技术逻辑上存在大量共性：

1. 都高度依赖数据工程。原始语料必须经过去重、清洗、质量过滤、敏感信息剔除等处理，“垃圾进、垃圾出”在两条路线上同样成立，数据质量往往比模型结构更影响最终效果。
2. 都以 Tokenizer 为共同前提。Tokenizer 负责把文本切分为 token 并映射为词表 ID，词表大小与切分策略直接影响序列长度、编码效率和多语言覆盖，任何一条路线都绕不开这一步。
3. 都需要评估与对齐闭环。没有评估基准就无法判断模型好坏；没有对齐，模型输出就难以符合业务预期与安全要求。
4. 都遵循数据飞轮逻辑。线上反馈 → 数据回流 → 再训练 → 再评估，是两条路线共同的持续迭代方式，也是长期效果的分水岭。
5. 都面临分布式训练与部署难题。显存瓶颈、通信开销、断点恢复、训练不稳定性、推理成本控制等问题贯穿始终。

四、核心差异分析：六个关键维度

4.1 数据需求：万亿 token 与十万样本的量级差异

预训练需要万亿级 token 的语料，且来源庞杂、噪声比例高，清洗 pipeline 本身就是一项庞大工程；微调路线通常几千到几十万条高质量标注样本即可启动，重点是“精”而不是“多”。对大多数团队而言，标注规范的一致性与质量控制，比盲目扩大数据规模更值得投入。

4.2 算力成本：千卡集群与单机多卡的差距

预训练一般需要千卡级 GPU 集群连续运行数周至数月，且伴随可观的故障恢复与重跑成本；微调在单机多卡环境即可完成，通常数小时到数天出结果。若采用 LoRA 等参数高效微调方法，可训练参数量大幅下降，显存与算力门槛还能进一步降低。

4.3 技术门槛与团队结构

预训练要求团队具备数据并行、张量并行、流水线并行等分布式训练能力，以及集群调度、监控告警、断点续训等系统工程能力，属于“重型研发”；微调更偏数据工程与算法调优，中小型算法团队即可承担。

4.4 能力边界：上限与下限的分工

预训练决定模型“知道什么”，微调与对齐决定模型“怎么表达”。这带来两个重要推论：

• 微调很难给模型注入基座中完全缺失的知识体系。如果领域知识与通用语料重叠度低（如专业语种、行业私有格式），单纯微调效果会受限；
• 反过来，预训练产出的基座模型并不能直接用于业务，缺乏指令遵循与安全对齐，直接部署的体验通常很差。

4.5 迭代周期与纠错成本

预训练周期以月计，一旦发现数据配比或训练策略有问题，回滚代价极高；微调以天甚至小时计，可以快速验证假设、小步快跑。这也是业界普遍建议“先微调验证价值，再评估是否需要更重训练投入”的原因。

4.6 安全与合规

预训练数据来源复杂，版权归属、许可协议、敏感内容过滤的法律与工程成本高；微调数据多来自企业自有业务，可控性更强，但仍需注意训练数据脱敏、权限隔离与输出内容的安全护栏。

五、对比表格总结

对比维度	路线A：从零预训练	路线B：基座模型微调 + 对齐
数据规模	万亿级 token，来源庞杂	数千~数十万条高质量样本
算力投入	千卡级集群，周~月级	单机多卡，小时~天级
技术门槛	分布式训练与集群运维要求极高	以数据工程与调优为主，门槛中等
能力上限	可自定义知识底座，上限高	受基座模型能力约束
迭代速度	慢，纠错成本高	快，可快速验证
合规风险	数据来源合规压力大	相对可控，需做数据脱敏
适用团队	大型研发机构	绝大多数企业与产品团队

六、典型场景选择

可以用一条简单的判断链描述常见场景：

业务需求
 ├─ 领域知识与通用语料重叠度极低（专业语种/私有格式）
 │    → 考虑增量预训练或从零预训练
 ├─ 基座能力足够，只需适配任务格式与领域话术
 │    → 以 SFT 为主
 ├─ 需要精细控制风格、拒绝策略与安全边界
 │    → SFT + RLHF/DPO
 └─ 知识频繁更新、需要可追溯的引用来源
      → 优先检索增强（RAG），微调解决不了"知识保鲜"问题

七、选型建议

• 默认起点是微调，而不是预训练。除非有明确证据表明基座模型能力无法覆盖业务，否则预训练的投入很难被证明划算。
• 数据比模型更稀缺。无论哪条路线，高质量数据的持续生产能力（数据飞轮）才是长期壁垒。
• 善用托管能力降低门槛。在团队运维能力有限时，可优先考虑托管化程度更高的方案，例如使用百度智能云等云服务平台提供的模型精调、评估与推理托管能力，把精力集中在数据质量与业务效果上，而不是集群运维上。
• 组合策略最常见。实践中更常见的是“通用基座 + 领域增量预训练（可选）+ SFT + 偏好对齐”的组合路线，而不是非此即彼的单选题。

八、迁移与使用注意事项

如果团队从“直接调用通用模型”切换到“自建微调模型”，或在不同基座之间迁移，需要提前评估：

1. 评估体系重建：不同模型的公开基准分数不可直接比较，需要建立与业务指标挂钩的自有评测集；
2. 接口与格式兼容：不同模型的 Tokenizer 不同，会导致上下文长度、token 计量口径发生变化，依赖 token 数量的逻辑需要适配；
3. 版本回归风险：基座模型升级可能带来行为漂移，微调数据需要随版本重新验证，必要时重新训练；
4. 训练与推理一致性：训练时使用的对话模板、系统提示词必须与推理服务严格一致，否则效果会明显衰减；
5. 数据飞轮建设：上线只是开始，需要设计线上反馈采集、badcase 挖掘、标注回流与再训练的闭环机制，否则模型效果会随业务演进逐渐衰减。

九、总结

回到最初的问题：大模型是怎么训练的？它是一条“数据获取 → 处理 → Tokenizer → 预训练 → SFT → RLHF/DPO → 评估 → 部署 → 数据飞轮”的完整闭环，难点分布在每一个环节：数据的规模化获取与清洗、Tokenizer 设计、分布式训练的稳定性、对齐过程中的人类偏好建模、评估体系的搭建，以及部署推理的成本控制。

而“从零预训练”与“基于基座模型微调”的对比，本质上是在“能力上限与自主性”和“成本、速度与确定性”之间做权衡：预训练买的是上限与自主权，微调买的是速度与确定性。对绝大多数团队而言，务实的路径是从微调切入、用数据飞轮沉淀壁垒，再把更重的训练投入留给被业务验证过、确实必要的那一部分。