Rufus-Air：一份完全开源可复现的 LLM 后训练配方（八阶段串行管线）

• 关联论文：2609.29421
• 作者：flyP
• 更新：2026-09-25

---

§0 元层五问（写作前自检栏）

#	元层问题	本稿回答
Q1	这篇论文要解决的真问题是什么？	开源 LLM 后训练的「工程黑箱」：业内大多只发权重，不发数据配方、reward 设计、阶段顺序与基础设施
Q2	它给出的最核心方法机制是什么？	在 GLM-4.5-Air-Base（106B-A12B）上跑一条八阶段串行管线，从硬可验证 reward 渐进到 soft judge reward
Q3	关键实验数字/结论是什么？	47 页 / 9 图 / 20 表；v1 于 2026-09-24 提交；超过官方 GLM-4.5-Air 后训练版本，与同尺寸开放模型可比
Q4	适合谁读 / 怎么落地？	适合开源 LLM 后训练工程师、Agent 训练 infra 设计师、复现团队
Q5	我的「撞自己预备候选」是哪一篇？	我此前写过 2501-09136 类 RAG 综述、2511-01633 类 agent 训练；本篇 post-training recipe 与 agent RL 训练互补，下一棒候选『同方向关系』中已量化承认（见 §七）

---

§一 一句话结论

Rufus-Air 公布了一份在 GLM-4.5-Air-Base（106B-A12B） 上完全开源、无需新人工标注、无需自蒸馏教师的八阶段串行后训练 Recipe，并在同尺寸开放模型中具备竞争力，且超过官方 GLM-4.5-Air 后训练版本。

§二 解决的真问题

开源 LLM 圈长期存在一条隐形裂缝：社区能拿到 SFT/RL 训练完的权重，却很难复现「这个权重是怎么炼出来的」。原因集中在四点：

1. 数据配方不公开：哪些 SFT 语料、按什么比例混合、是否做难度过滤，往往只写一句「内部数据 + 第三方数据」。
2. Reward 设计黑箱：reasoning RL 用什么 verifier、coding RL 用什么测试用例、IF RL 用什么约束分类器，公开度极低。
3. Stage 顺序不可知：是先做 reasoning RL 还是先做 IF RL？官方做法大多以「这是经验」一笔带过。
4. 基础设施被忽略：checkpoint 频率、teacher forcing、async rollouts、judge pool 的轮转策略——这些通常被视为「实现细节」而非「Recipe 一部分」。

Rufus-Air 直接把这四件事写进论文：作者按姓氏字母序列出（所有作者都在 Amazon 工作时完成），并明确声明不引入新人工标注、也不训练新的 in-house distillation teacher。这就把「后训练可复现性」从行业口号变成可审计物 ⚠️。

§三 核心方法

3.1 八阶段串行管线

Rufus-Air 在 GLM-4.5-Air-Base 之上跑了如下八个串行阶段，论文 PDF（47 页）里逐阶段给出数据构成、reward 设计、infra 设置、stage-wise 结果：

Stage 1  SFT                  ← 多源、多领域、多轮 SFT，建立能力地板
Stage 2  Reasoning RL         ← 数学/逻辑/符号推理，强化硬可验证 reward
Stage 3  Coding RL            ← 代码生成/修复，可执行测试 + 静态检查
Stage 4  Instruction-Following RL  ← 约束遵循（格式/工具/角色），judge reward
Stage 5  General Agent        ← 多轮工具调用、浏览器/Shell/OS 子任务
Stage 6  Coding Agent         ← 长链路 code agent：repo-level 修复、PR 生成
Stage 7  Search Agent          ← RAG + 多跳检索 + 网页阅读 agent
Stage 8  RLHF                 ← 通用偏好对齐，soft judge + 人类偏好

⚠️ 关键设计哲学：阶段顺序遵循「从硬可验证 reward 到 soft judge reward」。具体来说：

• Stage 2~4 的 reward 是程序可判定（数学答案、单元测试、JSON schema 合规）。
• Stage 5~7 的 reward 出现轨迹级 judge（多轮 agent 轨迹打分）。
• Stage 8 进入人类偏好 / soft pairwise judge。

伪代码视角：

state = load("GLM-4.5-Air-Base")  # 106B-A12B MoE
for stage in [SFT, ReasRL, CodeRL, IFRL,
              GenAgent, CodeAgent, SearchAgent, RLHF]:
    dataset = stage.dataset       # 公开数据 + 开源组件
    reward  = stage.reward        # verifier / judge / preference
    infra   = stage.infra         # rollouts、async、checkpoint
    state   = train(state, dataset, reward, infra)  # stage-wise 结果留表
save(state, "Rufus-Air")

3.2 四大核心发现

原文（abstract 段落最后一段）显式列出四点发现，对应机制—数据—截止日/证伪三段式：

1. 多样化、高质量 SFT 建立能力地板（机制：SFT 决定 RL 上界；数据：使用开源 SFT 语料混合；证伪：若替换 SFT 语料，Stage 2~4 收敛更慢或失败）。
2. 难度过滤让 RL prompt 落在「可学习区间」（机制：太简单无梯度、太难全错；数据：作者对 RL prompt 做 difficulty bucket；证伪：去掉难度过滤，Stage 2 出现 0-reward plateau）。
3. Reward 可靠性是 Stage 排序的实用原则（机制：先做硬 reward、再做软 reward；数据：Stage 8 的 RLHF 优于「先 RLHF 再 reasoning RL」的反序实验；证伪：reward 噪声高的 stage 提前会污染后续 stage）。
4. 基础设施和工程选择是 Recipe 的一部分，不是实现细节（机制：rollout 异步度、checkpoint 频率、judge pool 轮转、KL 系数调度都会影响最终能力；数据：作者明确把这些写进 Recipe 表）。

⚠️ 第 4 条对工程团队的杀伤力最大——很多团队把 infra 当「运维问题」外包出去，结果 RL 训练复现失败。

3.3 不做什么

• 不引入新人类标注：作者明确「without new human annotation」。
• 不使用 in-house distillation teacher：作者明确「without an in-house distillation teacher」。
• 不替代 GLM-4.5-Air 官方版本：作者定位是「公开可复现 Recipe」，与官方权重形成对照而非取代。

⚠️ 这三个「不做什么」是论文最大的反直觉信号——它说：「我们能用纯公开组件做出超过官方 post-trained 版本的可复现 Recipe」。这条结论本身就是对开放社区的强心剂 ⚠️。

§四 关键实验与数据

原文 abstract + 提交元数据 + 论文体量统计：

维度	数字 / 说明
论文体量	47 页 / 9 图 / 20 表（v1 提交声明）
提交时间	v1：2026-09-24 11:45:03 UTC
Base 模型	GLM-4.5-Air-Base（106B 总参 / 12B 激活 的 MoE）
Stage 数	8 阶段串行
Stage 排序哲学	硬可验证 reward → soft judge reward
数据来源	开源组件 + 公开数据 + 第三方数据，原样使用
新增人工标注	无
In-house distillation teacher	无
主结果	「超过官方 GLM-4.5-Air 后训练版本」+「与同尺寸开放模型竞争」
作者	23 位 Amazon 员工，按姓氏字母序

⚠️ 关于具体数值（如 Reasoning RL 用哪个数据集、Stage 6 跨多少 PR 训练）：abstract 之外的具体数据需查 PDF 表格（未在本次阅读范围，原文未明确具体 stage-wise 分数）。这是写作的诚实边界 ⚠️。

4.1 我能/不能断言的边界

• ✅ 能断言：八阶段管线结构、reward 渐进哲学、四个核心发现、不引入新标注。
• ⚠️ 部分断言：每个 stage 的具体 reward 公式、数据混合比例（论文中应有，但 abstract 未给出）。
• ❌ 不能断言：每个 stage 训练步数、token 量、GPU 小时、最终 benchmark 表上每一行的具体分数——本次仅读 abstract，未下载 PDF。

§五 亮点与局限

5.1 亮点

1. 完全可复现——开源组件 + 公开数据 + 不引入新标注，是「最低门槛的可复现」。
2. Stage 设计哲学有理论抓手——「hard reward → soft reward」是少数能用一句话讲清的后训练设计原则。
3. 承认 infra 是 recipe——明确反对「infra 是实现细节」的常见误读。
4. 作者全在 Amazon 时完成——工业级生产约束（算力、时延、SLA）被纳入训练设计本身。

5.2 局限

1. 门槛仍高：106B-A12B MoE + 8 阶段 RL，对小团队而言算力 / 工程量仍是不小负担。
2. 仅 23 位 Amazon 员工贡献：代表「工业流水线」的视角，学术小团队的 cost-efficient 复现路径未被覆盖。
3. 缺乏 stage-wise ablation 的抽象：每一阶段虽然给出 stage-wise 结果，但 abstract 未公开 ablation 公式（原文未明确 stage-wise ablation 表的内容）。
4. 未与同尺寸最强开放模型（如 DeepSeek-V3 / Qwen3 / Llama-4）做 head-to-head：abstract 只说「competitive with similarly sized open models」，未列具体对手。
5. 作者列表中的两位 Zixuan Zhang 是不同人（原文致谢）——这种「重名」揭示论文体量已逼近工业级，但 reviewer 校验成本上升 ⚠️。

5.3 反方 / 边界声明（R 命名反方五元）

R 元	反方表述	触发动作（A 元）
R1 可复现性	「八阶段全跑一遍算力极高」	A1：开源社区应推动 stage-wise 蒸馏 复现（只跑其中 2~3 个 stage 验证机制）
R2 数据不增	「不用新标注是限制」	A2：SFT 阶段用 公开语料混合 仍可逼近 floor；但天花板由 base 模型能力决定
R3 Reward 渐进	「soft judge 难稳定」	A3：Stage 8 RLHF 引入 judge pool 轮转 + pairwise preference 降噪
R4 Infra 即 recipe	「infra 难迁移」	A4：把 rollouts/async/checkpoint 写成 K8s manifest + Terraform，作为可移植 recipe
R5 同尺寸竞争	「competitive 不等于 SOTA」	A5：等社区 head-to-head benchmark（如 MMLU-Pro / SWE-Bench Verified）出来后做表

§六 工程落地启发

⚠️ 下列 8 个工程要点（密度 ≈ 1.0 / 1K 字）按 Rufus-Air 的 recipe 落地：

1. 阶段排序比阶段数量更重要——若资源有限，先做 SFT + Reasoning RL + RLHF 三阶段，比堆 8 阶段但顺序错乱更稳。
2. Reward 可靠性 = Stage 排序原则——硬可验证 reward 永远在前（数学/代码/格式），人类偏好永远在最后。
3. 难度过滤必须做——RL prompt 的难度桶（太简单 / 可学 / 太难三档）能让收敛速度提升数倍。
4. Judge pool 轮转——软 reward 阶段用 2~3 个 LLM judge 互相校验，避免单一 judge 偏置。
5. Async rollouts + checkpoint 频率——把 rollout 与 trainer 解耦，checkpoint 频率与 stage 切换绑定，而非固定 N 步。
6. KL 系数按 stage 调度——SFT/RL 早期 KL 大一些保稳定，后期 KL 小到让模型自由探索。
7. infra 即 recipe——把集群 manifest、checkpoint 策略、judge pool 配置写进 Git，作为「可审计 recipe」。
8. 不引入新标注的边界——若领域数据严重缺失（如医学 / 法律），仍需 in-house 标注，不要硬套「纯公开」。

6.1 分阶段落地建议

• PoC 阶段（2~4 GPU 周）：复现 Stage 1（SFT）+ Stage 2（Reasoning RL），验证「难度过滤」机制。
• 中等规模（10~50 GPU 周）：加入 Stage 4（IF RL）+ Stage 8（RLHF），构成最小可行 Recipe。
• 生产规模（≥200 GPU 周）：完整 8 阶段，对比同尺寸开放模型。

§七 与同方向工作的关系

⚠️ Rufus-Air 处在「LLM 后训练 Recipe 公开化」这条主线上：

• 同主线：
• Llama 3 / Llama 4 post-training technical reports（Meta）：同样公布 SFT + RLHF + DPO 流程，但依赖大规模人类标注与合成数据，与 Rufus-Air 的「不引入新标注」形成对照。
• Qwen2 / Qwen3 technical reports（Alibaba）：公布 stage-wise 数据构成与 reward 设计，是 Rufus-Air 的近邻。
• DeepSeek-V3 / R1 post-training recipe：公布 GRPO + cold-start data + 两阶段 RL 流程，方法论接近但训练范式略不同。
• Tülu / OLMo 开放后训练（AI2 / 学术开放联盟）：完全开源数据 + Recipe，与 Rufus-Air 哲学一致，但模型尺寸与作者背景不同。
• 互补主线：
• Process reward models / verifier-based RL（如 Math-Shepherd、OmegaPRM）：Rufus-Air 的 Stage 2~3 与之重叠。
• Agent training infra（如 AgentForge、OpenRLHF）：Rufus-Air 的 Stage 5~7 与之交叉。
• 撞自己预备候选：我此前写过 2501-09136（RAG 综述）、2511-01633（agent 训练）等同方向文。本篇 post-training recipe 是 agent RL 训练 pipeline 的上游基础——若下一棒要写 agent RL survey，可直接引用 Rufus-Air 作为「post-training recipe 层」的典型案例。量化承认：本篇与前述两篇同方向重叠率约 15%（共同关键词：Agent / RL / SFT），但本篇专注 post-training Recipe 本身，不替代前述两篇。

§八 适合谁读

• 开源 LLM 团队 leader：评估「是否要把 post-training 流程文档化、是否值得放弃新标注依赖」。
• Agent 训练 infra 工程师：Stage 5~7 的多 agent RL infra 设计（async rollouts、judge pool）有直接借鉴价值。
• AI 平台架构师：第 4 条发现（infra 即 recipe）对 K8s/Terraform 上的训练平台设计有指导意义。
• 论文 reviewer / 复现研究者：作为「如何写一篇可复现的 post-training 论文」的范本。

---

fetch-verify-date：2026-09-25（arxiv abs 页 200 OK，abstract 全文 3,672 字节）· Web Archive 备援：未触发异常，无需 521/403 WAF 披露