Orbit：把万亿模型 RL 后训练改写成部署一致性问题
Orbit 的价值不只是“单节点训练 1T 模型”这个标题，而是把 RL 后训练里的显存、权重同步、低精度服务和 log-prob 漂移放到同一个系统边界里处理：base model 保持部署精度并冻结，梯度只落到 BF16 adapter 上，rollout engine 围绕 adapter 版本热更新。
核心判断
这个帖子最容易被读成一句 marketing：Orbit 能在单个 8×B200 节点上做万亿参数模型 RL。更准确的读法是：Orbit 在挑战“后训练默认必须 full-parameter、高精度、多节点”的工程假设。
我的判断：Orbit 的主贡献不是把 LoRA 换成 OFT，也不是某个单独的异步优化，而是把 RL policy 的定义扩大到部署精度、adapter 应用方式、rollout engine 版本、reference policy 和 log-prob 数值路径。只要这些部分不一致，优化器看到的 policy 和 rollout 采样的 policy 就不是同一个对象。
因此 Orbit 更像一个 deployment-aligned RL infrastructure 提案。它把 base model 放在 INT4 / FP4 / FP8 这类部署精度中并冻结，把可训练自由度收缩到 BF16 adapter，然后围绕 adapter 的版本同步、异步生成和热切换重写训练流程。它要解决的不是“RL 算法该用 PPO 还是 GRPO”这种上层选择，而是“RL 系统到底有没有在优化自己实际 rollout 的那个策略”。
问题背景
万亿参数模型后训练的难点不只是参数多。真正麻烦的是 full-parameter update 会把显存、optimizer state、权重同步、serving reload、reference policy 和数值精度差异一起拖进 hot path。
full-FT 需要为 base 权重、梯度、optimizer state 和 activation 付费。模型越大，单节点越快被 weight-state footprint 打穿。
RL 中 rollout 产生的 token log-prob 会进入训练目标。serving 端和 training 端只要精度、kernel 或 adapter 应用不一致，就会制造 policy drift。
每轮都把 full model 推给 rollout engine，会触发权重导出、格式转换、分发和暂停生成。这个成本会掩盖算法本身的训练效率。
Orbit 的切入点是承认一个现实：很多 RLVR、数学、代码和推理后训练并不一定需要全参可塑性。对于已经很强的 base model，策略移动可能可以被限制在一个小得多的 adapter 子空间中。这个约束牺牲了一部分表达自由度，但换来了显存、训推一致性和 rollout 编排上的巨大简化。
机制拆解
Orbit 的机制可以拆成四层：低精度 frozen base、BF16 adapter、adapter-native rollout sync、以及 double-buffered async activation。四层都成立时，单节点 1T 级 RL 才有现实意义。
训练和 rollout 不再分别使用高精度 base 与低精度 serving base，而是共享同一份低精度权重。这样做的目标是从结构上减少 train-rollout log-prob gap。
adapter 很小，权重态、梯度态和 optimizer state 都集中在 PEFT 参数上。base 的巨大参数量仍然参与 forward，但不再承担 backward 更新成本。
base 不变，serving engine 不需要每步重建；trainer 只把新 adapter 版本传给 rollout backend。
新 adapter 可以先写入 inactive slot，旧 adapter 继续服务 in-flight 请求，切换点再做短暂停顿和原子激活。
为什么 OFT 重要：OFT 指 Orthogonal Finetuning，这里的 adapter 更像对权重空间施加局部正交变换。作者选择 OFT 的理由包括低精度 base 上的稳定性、对预训练能力的保留、serving 时更低的跨卡通信成本，以及对 fused projection / split-projection kernel 的工程适配。
系统瓶颈
Orbit 补充页里最关键的实验不是 1T 曲线，而是五种 rollout 架构的对照。它说明：只把 full-weight push 换成 adapter push，但训练和生成仍串行，系统不会真正快起来。
| 架构 | 关键行为 | 观察 |
|---|---|---|
| Sync full-weight | 生成、训练、全量权重推送串行 | trainer 和 rollout pool 轮流等待，straggler waste 明显 |
| Sync adapter-only | 只推 adapter，但 loop 仍串行 | Qwen3-4B OFT warm step time 仍约 8.651s，说明 push payload 不是唯一瓶颈 |
| Async full-weight | 训练和生成重叠，但每次更新仍要推 full model | overlap 有帮助，但 full-weight update 会让 rollout engine 滞后多个版本 |
| Async adapter single-slot | 只推 adapter，更新时短暂停止生成 | warm step time 降到约 3.165s，rollout throughput 明显改善 |
| Async adapter double-buffer | 新 adapter 先广播到 inactive slot，再短暂停顿原子切换 | warm step time 约 2.531s，train wait 和 rollout throughput 继续改善 |
这组对照的 insight 是：万亿模型 RL infra 的核心瓶颈往往不是“某个函数慢”，而是同步边界放错了。adapter 让更新 payload 变小，async 让训练和生成重叠，double-buffer 让版本切换不阻塞绝大多数 in-flight 请求。三者叠加才构成 Orbit 的系统收益。
术语和概念边界
这里指在预训练和常规指令调优之后，用 reward / verifier / environment feedback 继续优化模型策略的阶段。它关注的不是语言建模 loss，而是任务奖励和行为分布。
指训练端计算出的 policy log-prob 与 rollout / serving 端实际采样策略之间的差异。差异可能来自量化、kernel、temperature、adapter 版本或 tokenization 路径。
Orthogonal Finetuning，一类通过正交变换调整模型权重行为的 PEFT 方法。本文语境中，它是 Orbit 默认使用的 BF16 adapter 形态。
意思是训练时的 base 权重、量化精度和 rollout / serving 时尽量一致。它不是单纯追求低精度，而是让优化目标对应真实部署策略。
RL 中用于 KL 约束或行为比较的参考策略。Orbit 的 PEFT 路线可以通过禁用 adapter 来恢复 frozen base，减少单独加载 reference model 的成本。
rollout engine 维护两个 adapter slot：active slot 继续服务当前请求，inactive slot 接收新版本。切换时只做短暂停顿和原子激活。
边界与风险
Orbit 的公开材料很有工程价值，但不能把博客中的系统能力验证直接等同于完整论文级结论。它证明的是路线可行性，而不是所有后训练任务都应放弃 full-FT。
如果任务需要深度改写知识、专家路由、工具协议或长上下文行为，adapter-only 可能会撞到表达上限。OFT 的稳定性不等于无限能力。
train-rollout gap 小只是系统健康条件。最终质量仍取决于 reward 设计、数据分布、采样策略、KL 约束和 eval 是否真实。
Orbit 依赖 Megatron / SGLang / CUDA / quantization / checkpoint conversion 的组合工程。普通团队拿到代码后，仍需要很强的底层维护能力。
Kimi-K2.6 与 DeepSeek V4-Pro 的结果目前主要来自作者报告。数据集、reward、失败案例、长期训练稳定性和外部复现仍是关键缺口。
容易误读的一点：“单节点 1T RL”不是说在单节点上做完整全参 RL，而是说通过 frozen low-precision base + adapter-only update，把训练状态和 rollout 编排压缩到单节点可承受范围内。
工程启发
对做 agentic RL、数学 RLVR、代码 RL 或垂直模型后训练的团队，Orbit 的启发不是照搬 OFT，而是先把数值一致性和 rollout 热路径整理清楚。
每轮训练都记录 training forward 与 rollout engine 的 log-prob diff。没有这个指标，很难判断 reward 波动是算法问题还是系统漂移。
adapter 不只是参数文件，还应该有 monotonic version、active / inactive slot、staleness metric 和回滚策略。
如果使用 PEFT，优先评估能否通过禁用 adapter 得到 reference log-prob，避免额外复制一个巨大的 base。
如果训练和生成仍然串行，单个权重更新函数再快也有限。应先看 trainer wait、rollout utilization 和 straggler waste。
Megatron 训练端和 SGLang rollout 端应该在 tokenization、quantization、attention backend、adapter application 上做启动前一致性检查。
对于已有强 base 的后训练，先用 adapter-first 路线测 reward 和 eval 边界，再决定是否值得支付 full-FT 的系统成本。
证据边界与资料索引
这篇笔记基于 X 原帖、作者公开 profile、Orbit 英文博客、GitHub README、rollout 架构补充页、仓库 raw 配置与示例文档。中文微信短链当前会进入验证码页，因此没有把中文稿作为独立证据展开。GitHub REST API 当时触发未认证限流，仓库核验改用公开页面、raw 文件和 git remote 引用。