openPangu-2.0开源全流程：预训练、SFT与后训练RL落地指南

1. 官宣信息量拆解：预训练、SFT、后训练 RL 分别对应大模型项目里的哪一步

看到 openPangu-2.0 这个开源消息，很多人的第一反应是“又一个模型权重放出来了”。但如果仔细把标题读一遍，你会发现这次的信息量其实比“发布权重”大得多。预训练、SFT、后训练 RL 三个阶段同时被明确列为正式上线内容，这说明开源的不只是成品模型，而是一整条大模型生产链路。对一个真正想做大模型落地的团队来说，这件事远比“哪个榜单又涨了几分”更值得关注。

1.1 三个阶段分别解决什么问题

我们用做产品的语言来翻译这三个词，而不是用论文的语言。

预训练解决的是“模型知道什么”的问题。这个阶段让模型在大规模文本语料里做自监督学习，本质上是在压缩人类知识的统计规律。一个模型能不能正确回答专业问题、能不能写出像样的代码、能不能理解复杂句式，几乎全在预训练阶段就决定了。它不是教模型“怎么说对话”，而是教模型“理解世界”。这也是为什么大家总说基座模型的天花板决定微调后模型能力的上限——SFT 和 RL 都改变不了知识储备本身，只能改变已有能力被调用时的呈现方式。

**SFT（监督微调）**解决的是“模型如何回答问题”的问题。预训练阶段模型学会的只是“词语在什么语境里更容易出现”，但它不知道人类希望它以“用户提问-模型回答”的形式来交互。SFT 用大量人工编写的指令-回答对，把模型从“续写机器”校准成“对话助手”。这一步决定了模型的格式感、遵循指令的能力、风格倾向，也决定了它在垂直场景里的可用性。

后训练 RL解决的是“模型如何做出更合用户心意的选择”的问题。SFT 是静态的，给定一个问题就有一个固定答案，但现实中很多问题没有唯一正确解。RL 阶段通过奖励信号和策略优化，让模型学会在多种合理回答里选择更受欢迎的那一种：更简洁、更诚实、更少幻觉、更符合安全规范。它能撬动基座里原本隐藏的能力，尤其是推理方向的能力，这是很多人实测 RL 之后感觉“模型突然变聪明了”的真实来源。

1.2 “正式上线”这几个字含金量在哪

开源圈有个不成文的现状：大多数项目只开源推理权重，少数会附带 SFT 脚本，能连 RL 训练流程一起放出来的凤毛麟角。原因很直接——推理权重只需要保证别人能跑起来，SFT 脚本需要保证别人能微调起来，而 RL 训练流程要求开源方把自己内部的奖励设置、训练稳定性方案、评估方法都暴露出来，这已经不是“分享成果”而是“分享研发过程”。

所以我说 openPangu-2.0 这次的公开方式，对不同角色的人群价值完全不一样：

• 对只做应用层的开发者，它意味着你能拿到一个公开了训练细节的稳定底座，比用那些“来路不明”的第三方微调模型更安心；
• 对做学术研究的团队，它意味着你不需要从零复现整个训练管线，可以直接在公开的 SFT、RL 框架上做实验对比；
• 对做企业私有化部署的团队，它意味着你买到的不是一个黑盒，而是可以自己继续训练、持续迭代的模型资产。

这种把“造模型的方法”也开源的做法，本质上是把大模型从“只可远观的技术”拉回到了“可以上手改造的工程组件”。标题里这三个关键词，其实就是在告诉你：这个项目按阶段拆得很清楚，你缺哪一块就取哪一块。

2. 动手第一步：从下载权重到把基座跑起来，这几件事最容易卡住

我把 openPangu-2.0 的下载链接拿到了之后，第一件事不是急着让他回答问题，而是先确认这个模型能不能被我们现有的训练推理框架正常加载。很多人在这一步翻车，翻车之后还说“模型有问题”，其实是格式和框架不匹配的问题。

2.1 拿到手先看权重目录，别着急跑代码

一个正规开源模型仓库里通常包含这几类东西：权重文件、tokenizer 文件、配置文件、示例代码、训练脚本说明。权重文件现在一般用 safetensors 格式，比老式 bin 格式更安全，加载速度也更快，因为 safetensors 可以避免 pickle 反序列化带来的代码执行风险，而且支持直接映射到内存，大模型加载时会明显感觉到差别。

建议按这个顺序检查：

1. 看 config.json：确认模型参数量、层数、注意力头数、上下文长度。这些参数决定了你后续打算用多长的 prompt、多大的 batch；
2. 看 tokenizer 相关文件：确认词表大小，以及是否带有 special_token。如果词表在 Finetune 时被改过，和权重里的 embedding 矩阵对不上，加载阶段会直接报错；
3. 看是否有训练脚本目录：先判断官方给的是原生训练流程还是只给了推理流程，这决定你能不能直接再训练。

很多开源模型发布时只带“demo 式”脚本，看起来能跑，实际上一训练就各种报错。openPangu-2.0 这次既然把 SFT 和 RL 标为正式上线，那么对应的脚本应该是可以真正用来跑训练的，而不是只放个玩具示例。即便如此，我也建议先单独写一个加载脚本测试一下权重和配置文件之间的匹配关系，再进入正式流程。

2.2 显存不是玄学：按参数量提前算好资源

模型加载前最核心的问题是“我这几张卡的显存到底够不够”。很多团队没有算清楚就开跑，结果不是 OOM 就是跑到一半被自动降级，浪费的时间比训练时间还长。

我一般按下面的估算方式做预算。先说推理场景：fp16 精度下，权重显存约等于参数量 × 2 字节。一个 7B 参数模型，光权重就是 14GB，加上推理过程的 key-value cache 和中间激活值，单卡 24GB 刚刚好能跑短上下文下的 7B 模型，13B 模型至少要 32GB 以上，单卡 24GB 跑 13B 会很紧张。

再说训练场景，情况复杂得多。全参数微调时你不仅需要存权重，还要存梯度，还要存优化器状态。以 Adam 优化器为例，它要为每个参数保留一阶动量 m 和二阶动量 v，这两个都是 fp32 精度的，所以优化器状态每参数大约要 8 字节。加上权重和梯度，粗略公式是：

全参数训练显存 ≈ 权重(2字节 × P) + 梯度(2字节 × P) + Adam状态(8字节 × P) + 中间激活值

按这个公式算，7B 模型全参数微调的账面显存就要到 100GB 以上，单卡不可能跑得动，必须用多卡并行或 ZeRO 优化。这也是为什么在绝大多数业务场景下，微调用的都是 LoRA、QLoRA 这类参数高效微调方法——它们在可接受的质量损失内，把显存需求压到了普通单卡能承受的范围。

我自己在搭环境的时候习惯做一个显存资源对照表，方便和运维沟通：

这张表不是绝对准确，因为没有把上下文长度、batch size 算进去，但它能帮你在部署前快速判断自己的硬件条件大概能做哪些事。上下文越长，激活显存增长越明显，所以如果你要处理长文档，显存预算要额外留出 20% 的余量。

2.3 微调之前先验证基座的基础能力

下载完权重、确认了显存之后，很多人直接跳过基座验证，马上开始准备微调数据。我的建议是反过来：先用原版基座跑一批“能力摸底问题”，把结果记录存档。

为什么要这一步？因为微调是会改变模型行为的，而你不会希望等微调完才发现基座在某些能力上本来就是残缺的，结果把账全算在微调头上。摸底测试不需要太多题目，但覆盖面要广：常识问答、数学逻辑、代码生成、长文本理解、拒答能力、格式跟随，每类准备 10 条左右就够了。把这些结果保存下来，等 SFT 跑完再跑一遍同样的题目，你就知道微调到底改了什么、哪里变好了、哪里崩了。

这一步看起来很笨，但它是整个项目后续所有决策的参照线。没有这条参照线，你会在模型出现幻觉时根本分不清这是预训练遗留问题还是微调引入的问题。

3. SFT 阶段最容易翻车的几个细节：不只是把数据喂进去那么简单

SFT 是大多数人第一次真正动手碰 openPangu-2.0 的地方。它看起来最简单——准备一批问答对，跑几个 epoch，模型就会变听话。但实际操作下来，翻车概率最高的恰恰是这个阶段。我总结了三类高频问题。

3.1 数据配比决定对齐质量，不是数据量决定

很多团队的 SFT 数据准备方式是“把能搜集到的问答对全部堆进去”，最后做出来的模型要么废话连篇，要么一个领域很好、其他领域全面退化。这里的关键不是数据量，而是配比。

我建议把 SFT 数据分四大类来组织：

• 通用对话数据：日常问答、开放话题、生活常识，负责让模型保持自然交互能力；
• 指令任务数据：改写、摘要、翻译、信息抽取，负责增强任务执行能力；
• 代码与逻辑数据：如果目标场景涉及代码生成或逻辑推理，这类数据必须单独占用合理份额；
• 领域业务数据：你自己场景里的真实问题，这是和通用模型拉开差距的核心。

配比决定模型的行为分布。如果领域数据占 80%，通用数据少得可怜，模型就会在自己的领域里表现很好，但一遇到常识问题就开始答非所问。我的经验里，领域数据占比在 40% 到 60% 之间是比较合理的区间，其余留给通用能力保持。

还有一个几乎所有人都会忽略的事：数据去重。同一个知识点以相近句式出现几十遍之后，模型会把它彻底背下来，结果就是训练集上 loss 很低，验证表现也不错，但稍微换个问法答案就飘了。数据预处理阶段花一天做去重、清洗、改写，比在训练阶段多跑几个 epoch 省钱得多。

3.2 学习率、epoch 与灾难性遗忘的边界

SFT 阶段最常见的错误是“唯 loss 论”。一看到训练集上的 loss 还在降，就觉得还能继续训练。结果训练完了，发现模型在通用能力上崩得一塌糊涂。这就是灾难性遗忘在作怪。

针对 openPangu 这类已经过完整预训练的基座，我推荐的 SFT 起点是：

• 学习率：1e-5 到 2e-5 之间。不要一上来就用 1e-4，那是预训练和从头训练的玩法，用在 SFT 上会直接把原始权重冲坏；
• epoch 数：先试 1 到 2 个 epoch，而不是拍脑袋定 3 个或 5 个。大模型微调很容易过拟合，尤其是在领域数据量不大时；
• 批次大小：如果显存允许，尽量用更大的 batch，但学习率要相应跟着调。一般把总 batch 大小从 32 改到 64 时，学习率也可以从 1e-5 提到 1.5e-5 左右。

如果你用的是 LoRA 这类参数高效微调方法，训练时只更新低秩矩阵，遗忘现象会轻很多，因为原始权重没有被直接修改。这也是我对大多数业务团队的建议：先做 LoRA 微调，效果好再考虑全参数微调。不要一上来就挑战全参数微调的资源和风险。

3.3 验收方式：为什么只看 Loss 不靠谱

训练结束之后，我建议把验收拆成三层来做。

第一层是训练指标：看训练 loss 有没有收敛、验证 loss 有没有回升，这只是排除明显故障用的。

第二层是能力基线对比：用我在第二节提到的同一套摸底问题，跑一遍 SFT 之后的模型，和微调前的答案做对比。这一层主要检查有没有严重的能力倒退。

第三层才是质检员介入：让人从业务角度把微调后的回答和基座回答做盲测对比，统计“更好、持平、变差”的比例。在数据隐私允许的前提下，盲测结果比任何指标都更能反映微调是否真的成功。

我见过好多次这样的情况：模型在评测集上的分数涨了 5 个点，但实际业务方反馈说“回答变端着了”“太模板化”。原因就是评估指标和业务诉求脱节。SFT 项目的验收标准，应该在开始训练之前就和业务方一起定好，而不是训练完了再回头找评估方式。

4. 后训练 RL 在工程上的真实门槛：奖励设置、算法选型与训练稳定性

如果说 SFT 是“模型开始懂规矩”，那后训练 RL 就是“模型开始懂取舍”。这也是 openPangu-2.0 官宣里最让我关注的部分——开源模型很多，敢把 RL 训练流程一起放出来的确实太少。原因是 RL 阶段的工程门槛和踩坑密度，比预训练和 SFT 加起来都高。

4.1 RL 阶段到底在优化什么

为了让不熟悉 RL 的读者不至于一头雾水，我先用一个类比。

SFT 像是照着优秀作文范例来学写作，模型学会了“格式正确”“措辞得体”。但范例是有限的，数据里没有覆盖到的问题，SFT 就不知道该怎么处理。而 RL 阶段像是有了一个“批改老师”，你每写一版答案，批改老师就给你打一个分数，模型根据这个分数反复调整自己的写作策略，慢慢地就会从“学着像”变成“知道怎样更好”。

在技术上就是先有一个奖励模型或者奖励函数，对模型的输出打分，然后用强化学习算法去更新模型策略，让分数的期望值最大化。这个阶段能显著改变模型的输出风格、思维链质量、拒答边界，但它也是最容易出训练事故的阶段。

4.2 PPO 的资源消耗与稳定性问题

经典 RLHF 用的是 PPO 算法，工程上各项挑战都很大。跑 PPO 时模型数量并不少：负责交互的 actor 模型、提供 KL 约束的 reference 模型、输出分数的 reward 模型、用于价值评估的 critic 模型，这四个模型加起来的显存消耗非常可观。在 7B 甚至 13B 的规模下，单节点基本跑不动的。

更棘手的是训练稳定性。PPO 的超参数非常敏感：KL 惩罚系数小了，模型会钻奖励函数的空子，输出一堆看似高分但逻辑崩坏的文本；KL 惩罚系数大了，模型又不敢偏离原始策略，那 RL 等于白跑。我在实践中遇到最典型的现象就是训练几步之后 reward 在涨，但人工看生成结果反而变差了——这是奖励作弊的典型信号。

遇到这种情况，不要急着加训练轮数，先做三件事：检查奖励函数是不是可以被轻松钻空子、检查 KL 散度是不是失控了、检查采样参数是不是让模型陷入了重复循环。

4.3 轻量替代方案：GRPO 与实际落地建议

PPO 太重，现在很多项目开始转向 GRPO 这类省略 critic 模型的强化学习算法。GRPO 的工程实现比 PPO 轻不少，因为它不需要单独维护价值模型，而是通过同一 batch 里的多组采样结果计算相对优势。这直接省掉了 critic 模型的显存开销，也让训练稳定性问题减轻了一个级别。

如果业务场景有明确可验证的答案，比如数学计算、代码单元测试、结构化信息抽取，GRPO 搭配规则奖励函数是性价比最高的做法。但要注意一个隐藏风险：规则奖励打分的覆盖面有限，模型很容易学会“蒙对形式”、没有理解本质，评估指标好看，但泛化一塌糊涂。

对大多数想跟进 openPangu-2.0 的团队，我的推荐路线是：

1. 先做 SFT，把数据质量和行为能力打磨稳定；
2. 用规则奖励做一个轻量 GRPO 实验，选择推理、格式、安全性这几个容易量化的维度做对比；
3. 不要一上来就上 PPO 和复杂奖励模型。先跑通轻量方案，积累足够多的模型输出和人工偏好数据，再考虑更大体量的高质量对齐。

4.4 RL 训练里的回滚机制

补充一个在 RL 阶段非常重要但经常被忽略的设计：回滚点。

SFT 阶段模型能力差一点，最多是回答质量下降；RL 阶段模型能力差，会出现胡言乱语、陷入循环输出、完全无视用户指令等“灾难性行为”。所以我的习惯是每次训练一定步数就留存一次 checkpoint，同时记录当前的平均 reward、KL 散度、采样文本样例。一旦发现指标异常，立刻停掉训练并回滚到上一个稳定节点。

把回滚机制当成和训练脚本同等重要的基础设施，这一点对 RL 训练尤其关键。这不是技术洁癖，而是 RL 训练的不确定性本身要求你必须把风险控制前置。

5. 从模型到业务：我建议的落地路径和最后想提醒的事

聊完了训练阶段的细节，最后说说我如果现在要在一个真实业务里用 openPangu-2.0，会怎么安排后续动作。

5.1 先建评测体系，再动模型

很多团队在模型选型阶段把大量时间花在刷公开榜上，拿到模型之后才去想业务评估方案。这是把顺序搞反了。正确做法是，在下载模型之前，先把你业务里最核心的 50 到 100 条真实问题整理成一个评测集，然后让候选模型都跑一遍，看谁最贴近业务需求。

评测集不要只放标准问题，还要放边缘情况：用户恶意输入、超长上下文、敏感话题、带错别字的中文、中英文混杂，这些才是业务现场的真实压力测试。openPangu-2.0 既然把 SFT 和 RL 流程都开源了，你完全可以拿它做基线，再用自己的数据不断迭代出一个更贴合业务的版本。

5.2 部署阶段的裁剪与量化

模型再强也要落到推理服务上。我实际做部署时一般按这个优先级来：

• 如果业务对延迟和成本很敏感，优先考虑量化方案。7B 模型用 INT8 量化之后显存占用能压到 10GB 以内，普通单卡就能服务；
• 如果业务需要高并发，用成熟的推理框架做连续批处理和动态调度，不要自己写推理服务；
• 如果业务必须私有化部署，建议把模型镜像、训练脚本和后续更新机制打包成一套可交付资产，而不是每次版本更新都现场操作。

有一点要特别提醒：量化会带来一定程度的效果损失。如果模型经过 RL 训练，输出质量本来就已经对齐得很好了，量化层级太高可能会把这种对齐效果削弱。所以量化和不量化之间一定要拿业务评测集跑一次分，不要凭感觉拍板。

5.3 长期价值的真正来源

从标题里你看到的预训练、SFT、RL，本质上是一套完整的模型生命周期管理方法论。openPangu-2.0 把这三个阶段开源，最大的价值不在于模型本身有多少分，而在于它把一个本来非常昂贵的“造模型”过程，变成了一个普通团队也能参与的“改模型”过程。

但我要说一句大实话：模型是开源的，训练流程是开源的，“你能拿它做出什么样的差异化业务”不是开源的。三五年之后，所有接入了开源基座的团队在模型能力上的差距会越来越小，真正拉开差距的只有一个东西——你积累的数据资产和反馈闭环。

所谓反馈闭环，就是你的业务每产生一次用户行为，都能转化为新的训练信号，回流到下一轮 SFT 或 RL 训练里去。模型开源反而让这个循环的门槛降低了：你不再需要从零训练一个大模型，只需要维护好自己那条小而精的数据流水线，就能让模型在业务里越用越顺手。

我自己的操作习惯是，每部署一个开源基座模型，都会同步建立一个“线上问题收集→数据清洗→回流训练→AB 评估→更新上线”的完整链路，而不是训完一个版本就撒手不管。这套链路不复杂，但它才是开源模型能不能在业务里持续变好的分水岭。openPangu-2.0 把三个训练阶段都放出来了，等于把最难的部分也拉到了同一起跑线，接下来拼的就是谁的数据飞轮转得更快、更稳。