On Policy Distill

把这一点跟 slime 的实现对比就很清楚——它们在框架层是同一个抽象：

• slime: advantages[i] = adv_grpo[i] - opd_kl_coef * (student_logp - teacher_logp)
• MiMo: Â_MOPD = α * Â_ORM + sg[log π_T - log π_θ]

但 MiMo 在 batch 内的 teacher 路由（每条 sample 根据 prompt 的 domain 选不同的 teacher）和 student rollout 已经偏离 teacher 时的 train-inference IS 重加权（参照 IcePop³ 截断 ratio 越界的 token 不更新）这两点上做了 slime 暂时没做的扩展。

MOPD 实验结果解读：超越 best teacher

报告 Table 7 给了一组比较彻底的数据，我把"具有特殊意义"的几行抽出来：

要点：

1. Student 在多个 benchmark 上反超了"该 domain 最强的 teacher"——这跟传统蒸馏"student 性能 ≤ teacher" 的直觉相反。MOPD paper 把这个现象归功于 multi-teacher 之间的"知识互补"——一个 prompt 在 math 域归 math teacher 管，但 student 跨域学到的 generalization（特别是来自 self / SFT teacher 的 instruction-following 信号）会反过来加强 math 域上的具体推理能力。
2. 失败的两个 case 都很有趣：
   • GPQA-Diamond 退步是因为 best teacher 是 student 自己（即没有 specialized teacher 提供新信号），MOPD 的 reverse KL 在 self-teaching 上等于 self-distill，会有轻微 mode collapse；
   • BrowseComp 大幅退步（-6.3）说明 SFT teacher 在 search 这种长链条 agent 任务上的监督质量本身就不够稳，dense token-level reverse KL 把 SFT teacher 的"风格"学得太彻底反而拖累了下游能力。

这两个 case 是对面试官非常好的"诚实回答素材"——“我们 MOPD 的 wins/losses 边界很清晰：当 best teacher 比 student 强、且监督信号的质量稳定时收益最大；当 best teacher 是 student 自己或是低质 SFT 时，MOPD 反而可能伤害”。

MOPD 训练的 RL Infra：四大支柱

MOPD 的算法本身要落地，离不开 MiMo 在 SGLang + Megatron-LM 之上做的四个 infra 优化（报告 §4.6）。这四个组件加起来才让 309B/15B 的 MoE student 能在 10k+ 并发 K8s pod 的 agentic 环境下稳定跑 OPD：

(1) Rollout Routing Replay (R3) — MoE on-policy 的"原子级一致性"修复

问题：MoE 模型里，router 给每个 token 决定送进哪 8 个 expert。由于推理引擎（SGLang，FP8/BF16，特定 kernel）和训练引擎（Megatron，BF16，不同 kernel）在数值精度、累加顺序、attention backend 上完全不同，同一 token 在 inference 时可能路由到 expert {3, 17, 88, …}，在 training forward 时却路由到 {3, 19, 88, …}——这一个 expert 之差就让 logits 出现明显偏差，直接破坏 on-policy RL 的核心假设（即 student 在训练时看到的 logprob 与采样时是同一分布）。这个问题在 OPD 里更严重，因为我们要算的就是 student 自己的 logprob 和 teacher 的 logprob 之差，路由不一致会让这个差值的方差爆炸。

R3 解法：

Inference (SGLang)                     Training (Megatron)
┌──────────────────────┐               ┌──────────────────────────┐
│ Router 决策:          │               │ 用 inference 时记录的     │
│   token i → expert   │  ─ record ─►  │   expert 选择直接 replay,│
│   {e_a, e_b, ..., e_h}│               │   跳过 router 重计算       │
└──────────────────────┘               └──────────────────────────┘
       ▲                                            │
       │     训练 KL ↓ ~10×                          │
       └──────── 等价于"训练分布 = 推理分布" ────────┘

工程实现是：rollout 阶段把每个 token 在每层 MoE 的 top-k expert id 序列化下来（典型形态 [seq_len, num_layers, top_k] int32），跟着 sample 一起送进 train batch；training forward 时拦住 router 输出，强制用 replay 的 expert assignment。这套机制在 slime 代码里能直接看到对应物——slime/utils/routing_replay.py:RoutingReplay、use_rollout_routing_replay、环境变量 ROUTING_REPLAY_STAGE 三态（record / replay_forward / replay_backward / fallthrough）。所以前面讲 slime OPD 时提到的 teacher forward 走 fallthrough，正是为了让 teacher 走自己的 router、不被 student rollout 时的 routing 拖偏——这是 R3 的反向用例。

R3 的出处可以追溯到 OpenReview 上的同名论文（Xiaomi 团队作品）；同时在 vLLM/veRL 上也有第三方落地，可让 token 级 KL 差异降低约一个数量级⁶。

(2) Request-Level Prefix Cache — 多轮 agent 的 KV + routing 双缓存

问题：Agentic RL 里一条 trajectory 通常是 <prompt, reasoning_1, tool_call_1, tool_result_1, reasoning_2, ...> 这样的多轮结构。每一轮新 reasoning 都会带上前面所有轮次作为 context；如果不缓存，rollout 就要在每轮重新前向整个长 context。

Prefix Cache 解法：在 SGLang 引擎里同时缓存两套东西：

• KV state：标准 prefix cache 已有；
• Routed expert 选择：和 R3 配合，确保前几轮的 KV cache 在重用时所走的 expert 还和上次一致。如果只缓存 KV 不缓存 expert 选择，那么 R3 的一致性会在多轮间断掉。

这个设计专门服务于 agentic OPD/RL 场景——大量 prompt 是 long-horizon 的，每轮重算 prefill 是 GPU 算力的最大浪费源。

(3) Fine-Grained Data Scheduler — 把 batch-level 调度降到 sequence-level + partial rollout

问题：传统 RL rollout 是 batch-level 的——一个 batch 的 N 条 sample 全部跑完才能进 train step。但 agentic task 的 rollout 长度方差极大：一个简单 SWE 任务可能 2k token 收尾，一个复杂的 100k context 任务可能要跑 1 小时。straggler 拖整个 batch，长尾可能让 GPU 闲置 50% 以上。

MiMo 解法（与 GLM-5 的 C3PO++ 思路一致）：

• Sequence-level scheduling：调度单元从 batch 降到 sequence；
• Partial rollout：rollout 没跑完的 sample 也可以送进 trainer（带上 done=False 标记），等下一轮再续接；
• Dynamic batch packing：trainer 端按到达顺序攒 batch。

效果是 GPU idle time 下降 + on-policy 性质保持——partial sample 在被续接前不会发生策略漂移（reward / advantage 的归因正确性需要在续接时仔细处理）。

(4) Toolbox & Tool Manager — 10k+ 并发 K8s pod 的工具执行层

问题：Agentic RL 涉及大量 tool call（bash / web search / code execution）。每个 tool call 如果都临时拉一个新 docker / pod，冷启动延迟会 dominate trajectory 生成时间。MiMo 的训练规模是 10000+ 并发 pod、覆盖 8 种编程语言。

两层架构：

1. Lower layer (Tool Manager)：Ray actor pool，预热 N 个 actor，每个 actor 持有一组 K8s pod，按需分发；失败 pod 自动回收；资源限额 + 优先级队列。
2. Upper layer (Toolbox)：暴露给 student rollout 的同步接口（bash、str_replace、finish 三个原子工具），把任务逻辑和系统策略隔离。

70% 的 K8s pod setup 成功率 + 大规模 actor pool 的 graceful degradation 是 MOPD 之外、agentic RL 阶段才用得满的 infra，但 MOPD 的 search/code agent teacher 训练阶段也会用到同一套。

MTP：让 small-batch on-policy rollout 真正可行

MOPD 是天然的 on-policy + small batch 训练形态——on-policy 一定要用当前 student 的样本，所以 batch 不能开很大；但 small batch 又会让 GPU 算力浪费在 attention 这种 memory-bound 算子上。

MiMo 在 MTP 上的关键决定是：MTP 不只是推理时的 speculative decoding 加速器，更是 RL/OPD rollout 阶段的 throughput 提升器²。具体两条收益：

1. Lifts arithmetic intensity for both FFN and attention：MTP 一次 forward 出 K 个 draft token，main model 并行 verify。这个 K 倍的 token-level parallelism 直接抬升了 attention 的 arithmetic intensity（不再是每次 1 个 token 的 batch=1 算 attention），FFN 也跟着受益。
2. Mitigates long-tail straggler GPU idleness：rollout 进入长尾阶段后（少数 sample 还在跑、大部分已完成），active batch size 可能逼近 1。这种状态下的 vanilla decoding 对 GPU 极其不友好；MTP 通过 token-level 并行救场。

MiMo-V2-Flash 设计了一个轻量化 MTP block，专门服务这两个用例：

• dense FFN 而非 MoE（避免 MTP 自身又引入 MoE routing 不一致）；
• SWA 而非 GA（KV cache 占用极小）；
• 单 block 仅 0.33B 参数；
• pre-training 阶段挂 1 个 head；post-training 阶段把 head 复制 K 次（K=3 时 3.6 acceptance length, 2.6× decoding speedup）。

📌 这一点对你简历里"通过 MTP 蒸馏的优化 rollout 加速"那个 bullet 是非常硬的支撑：MiMo-V2-Flash 的报告把 MTP-for-RL 单独立小节论证了它和 small-batch on-policy 的天然契合，可以直接引用。

MOPD 与 GLM-5 cross-stage / slime OPD 的设计差异

把上面剖析整合成一张总对比表：

两者并不互斥：一个完整的 OPD pipeline 完全可以是「在 stage 内用 MOPD 多 teacher 并行融合，stage 之间再用 cross-stage OPD 防遗忘」——这正是 MiMo-V2-Flash 在 Stage 3 后接续 Agentic RL 时实际做的（Agentic RL 阶段自然会偏向 code agent，那时再回头用 MOPD 后的 ckpt 当 anti-forgetting teacher）。

关键数字 & 简历素材

把 MiMo 这一节里能够直接进简历当锚点的硬数字汇总：

• 309B 总参 / 15B active MoE student（256 experts / 8 active per token）
• 27T tokens 预训练 + 256K context
• 多个 trillion-class teacher（与 Kimi-K2 1T、DeepSeek-V3.2 671B 同档）
• R3 让 train-inference logits KL 降低约 1 个数量级
• MTP K=3 时 3.6 acceptance length, 2.6× decoding speedup
• 10k+ 并发 K8s pod，70% 环境 setup 成功率
• MOPD 让 student 在 5/8 reasoning benchmark 上反超 best specialized teacher
• MOPD 之后的 MiMo-V2-Flash 用 1/2~1/3 参数追平 DeepSeek-V3.2 / Kimi-K2

📌 Resume 钩子：这一节可以让你在简历里写 “Built MOPD-style multi-teacher on-policy distillation infra for trillion-scale MoE training, with R3-based MoE routing replay, MTP-accelerated rollout, and disaggregated multi-teacher serving”——能引出"R3 怎么实现的？““multi-teacher 路由怎么编排？““MTP 在 RL rollout 怎么 verify？““partial rollout 时 advantage 怎么续接？“等几乎一整套面试技术问题，这些问题你在 ByteDance Seed 上都做过对应的工作。

DeepSeek-V4 中的 Full-Vocabulary OPD 实现剖析

DeepSeek-V4⁷ 在 OPD 上做出了一个比 slime/GLM-5 cross-stage 和 MiMo MOPD 都更激进的工程决定：把整个 post-training 中的 mixed RL 阶段完全替换成 On-Policy Distillation，并采用 full-vocabulary logit 蒸馏而非业界主流的 sampled-token 估计。这一节剖析他们为什么这么做、怎么做的，以及这套设计与前面两套（slime / MiMo）的根本差异。

设计决定：mixed RL 整段被 OPD 替换

DeepSeek-V4 报告 §5.1 的原文（line 1536-1539）非常直白：

“Following pre-training, we conducted a post-training phase to yield the final models of DeepSeek-V4 series. Although the training pipeline largely mirrored that of DeepSeek-V3.2, a critical methodological substitution was made: the mixed Reinforcement Learning (RL) stage was entirely replaced by On-Policy Distillation (OPD).”

这跟前面两个案例的对比非常鲜明：

DeepSeek-V4 团队把"模型合并"这一步看作 OPD 的 sole job——不再让 student 同时做 RL 探索 + KL 蒸馏，而是把 RL 的探索全部前置到每个 specialist 的训练阶段，最后用 OPD 把多个 specialist 的能力logits-level 合并到一个 unified student 里。报告里把这个判断说得很明确：

“the knowledge from physically distinct expert weights is consolidated into a unified parameter space via logits-level alignment, practically circumventing the performance degradation often encountered in traditional weight-merging or mixed RL techniques.”

也就是说他们认为 mixed RL（一个统一 RL pipeline 同时学多个 domain）的"see-saw effect"问题——这个问题在 MiMo 报告里也被点名——可以通过把 RL 拆成单领域 specialist + OPD 合并来彻底回避。

Specialist Training：teacher 的产生（含 GRM）

DeepSeek-V4 的 teacher 不是"训好的别人家模型”，而是基于 V3.2 训练 pipeline 自己跑出来的 domain specialist。每个 specialist 走的是 SFT → GRPO RL 的标准路径，但有几个值得抽出来讲的设计点：

1. 三档 reasoning effort（Non-think / Think High / Think Max）：每档配不同的 length penalty 和 context window，实际上是用同一个 specialist 训出三个变体——这就让最终 OPD 的 teacher 池可以同时覆盖"快/中/深思考"三档，student 学完之后也支持三种模式切换。
2. Generative Reward Model (GRM)：处理"难以 rule-based verify"的任务时，DeepSeek-V4 没用传统的 scalar reward model，而是让 actor 自己同时充当 GRM——同一份权重既出 response 又出 evaluation。RL 优化时联合优化生成和 judging 两个能力。这套思路使得最后 teacher 池里既有 verifier 训出来的，也有 GRM-judge 训出来的。
3. Tool-Call Schema 用 XML（<|DSML|...|>）：避免 JSON-based tool call 的 escape 问题；这点是为后续 OPD 阶段保持 student 与各 teacher tool-call 格式一致服务的。
4. Interleaved Thinking：reasoning trace 在 tool-result 轮次间完全保留（V3.2 是丢弃），充分利用 1M-token context。这意味着 OPD 时 teacher logits 是在"完整 reasoning history"上计算的，dense token 信号包含跨轮 reasoning 的连续性。

最终 OPD 阶段 超过 10 个 teacher（“more than ten teacher models covering various domains are employed”），每个 teacher 都可能是 trillion-class 模型——这是 V4-Pro 自身就是 1.6T/49B 的规模，所以 teacher 跟 student 是同一档数量级。

算法形态：multi-teacher full-vocabulary reverse KL

OPD 目标函数（报告 Eq. 29）：

其中：

• $\pi_{E_1}, \ldots, \pi_{E_N}$ 是 N 个 specialist teacher（N>10）；
• $w_i$ 是各 expert 的权重，按 importance 分配；
• 整体仍然是 reverse KL（student 在前），所以 mode-seeking 的属性保留；
• trajectory 由 student $\pi_\theta$ 采样——保持 on-policy；
• “the unified policy 𝜋𝜃 selectively learns from the specialized expert relevant to the current task context” — 即 teacher 之间通过 prompt domain 分流（和 MiMo MOPD 的 domain-routing 同理）。

与业界主流的根本差异：full-vocabulary 而非 sampled-token

这是 DeepSeek-V4 OPD 与前面 slime / MiMo / TML 全都不同的一点。报告 §5.1.2 末尾（line 1750-1760）单独写了一段对比：

“In handling the above OPD objective, prior works usually simplify the full-vocabulary KL loss into a token-level KL estimate at each token position, and reuse RL framework by replacing $\text{sg}\!\left[\log \frac{\pi_{E_i}(y_t|x,y_{it leads to high variance in gradient estimation and often causes training instability. Therefore, we adopt full-vocabulary logit distillation in our OPD. Preserving the complete logit distribution in calculating reverse KL loss yields more stable gradient estimates and ensures faithful distillation of the teachers’ knowledge.”

把这段对比成表：

V4 团队认为对于 trillion-class teacher × 10+ teacher × 1M-context 这种规模，sampled-token 的方差代价已经超过 full-vocab 的存储代价——但前提是要把 “full-vocab logit 怎么便宜地拿到训练 loop 里” 这个工程问题解掉。下一节就是他们的解法。

让 Full-Vocabulary OPD 可行的四件事

DeepSeek-V4 §5.2 列了四个 RL/OPD 共用的基础设施优化，其中两个对 OPD 是 enabler 级的关键。

(1) FP4 Quantization Integration — 让 teacher inference 便宜

报告 §5.2.1：

• MXFP4 量化用在所有 rollout 和所有 inference-only forward——包括 teacher 和 reference model 的 forward；
• Rollout/inference 阶段直接用 native FP4 权重；
• Training step 用 lossless FP4→FP8 dequantization simulate，复用既有的 FP8 mixed-precision 框架（FP32 master weights），backward pipeline 完全不动。

这里关键是把 teacher 的 forward（OPD 里最频繁的算子之一）整体降到 FP4 推理路径——10+ 个 trillion-class teacher 同时存在的时候，光 KV cache + activation 就可能成倍于 student，FP4 几乎是必需的。

(2) Efficient Teacher Scheduling for Full-Vocabulary OPD — 这一节是核心

报告 §5.2.2 是整个 V4 OPD 设计最浓缩的工程章节，逐条拆开：

问题 1：N>10 个 trillion-class teacher 的权重不可能同时驻留 GPU。

解法 1：所有 teacher weights offload 到 centralized distributed storage，ZeRO-like sharding 按需拉取——OPD forward 时才加载某个 teacher 的当前 layer。这就把 GPU DRAM 压力 → 网络 I/O 压力（V4 的 3FS 集群存储就是为这个服务的）。

问题 2：vocab size > 100k，把所有 teacher 的 full logits 拉出来 materialize 即使写到磁盘也吃不消。具体感受一下：100k vocab × 1M context × 10 teacher × FP16 = 2 TB / 一条 sample，完全不可行。

解法 2（最关键的工程 trick）：只缓存每个 teacher 最后一层的 hidden state，logits 在 training step 用 student 自己的训练前向重新过 teacher 的 prediction head 算出来。

Teacher forward (offline-ish, FP4):
  prompt + student rollout
        │
        ▼
   ── teacher backbone ──▶ last-layer hidden state h^T_t  ── cache
                                                              │
                                                              ▼
                                                       centralized buffer
                                                              │
Training step (later, in main loop):                          │
  cached h^T_t  ──▶  teacher prediction head W_T  ──▶  full vocab logits
                                                              │
                                                              ▼
                                                  TileLang KL kernel
                                                  (exact full-vocab D_KL)

收益：

• 存储：从 [T tokens × |V|] floats → [T × hidden_dim] floats，节省一个 vocab/hidden 比例（~10×–20×）；
• 重算成本：只有 prediction head 一次矩阵乘（hidden→vocab），相比 backbone 是几乎可以忽略的；
• 完整性：拿到的还是 exact full-vocab logits，不是 top-k 近似。

问题 3：多 teacher 时即使只放 prediction head，10+ 个 head（每个都是 hidden→100k 的大矩阵）同时驻留 GPU 还是吃不消。

解法 3：按 teacher index 排序训练样本，让一个 mini-batch 里的所有样本走同一个 teacher。这样：

• 每个 distinct teacher head 只在一个 mini-batch 里加载一次；
• 任何时刻 GPU 上至多有 1 个 teacher head；
• 所有参数 / hidden state 的 load/offload 都 异步在后台进行，不阻塞计算 critical path。

问题 4：full-vocab KL 计算本身在 100k+ vocab 上很贵。

解法 4：用 TileLang 写专用 KL kernel——把 logsoftmax + KL 融成一个 fused kernel，避免动态显存分配，加速明显。这一点关联到 V4 §3.2（TileLang 训练框架）和 §3.3（高性能 batch-invariant deterministic kernel libraries）的整套基础设施。

(3) Preemptible & Fault-Tolerant Rollout — token-granular WAL

报告 §5.2.3 引入了一个 OPD 之外但 OPD 同样受益的组件——token-granular Write-Ahead Log：

• 每个 generation request 一个 WAL；
• 每生成 1 个 token 立即 append 到 WAL；
• preempt 时暂停推理引擎、保存未完成 request 的 KV cache；
• resume 时按 WAL + KV cache 续接 decode；
• 即使硬件故障：用 WAL 里的 token 重 prefill 重建 KV cache。

报告里最有意思的是这一段（line 1815-1818）的"为什么不能直接重生"的分析：

“it is mathematically incorrect to regenerate unfinished requests from scratch, as this introduces length bias. Because shorter responses are more likely to survive interruption, regenerating from scratch makes the model more prone to producing shorter sequences whenever an interruption occurs.”

也就是说"被打断的多是长 sample”，如果直接丢掉重生，那训练数据就被人为偏向短样本——这会让 student 的输出分布漂移到偏短，伤害 reasoning quality。WAL 是一个比"记 RNG seed 重 decode"更高效的 length-bias-free 解法。

这点对 OPD 尤其重要，因为 OPD 的 teacher 监督是 token-level 的，每个被丢弃 / 重生的 token 都意味着一份对应的 teacher logit 监督被浪费或被错配。

(4) Million-Token Context Scaling for RL/OPD

§5.2.4 的核心是rollout 数据格式分层：

• 把 rollout data 拆成 lightweight metadata（用于 global shuffle、packing layout 计算）+ heavy per-token fields（cached teacher hidden states, logprobs 等）；
• per-token fields 走 shared-memory data loader——一个 node 内多个进程共享同一份内存，消除 intra-node 冗余；
• mini-batch granularity 释放，CPU+GPU 内存压力可控；
• 单设备 mini-batch 数动态调整，平衡 compute throughput 与 I/O overlap。

(5) DSec — 沙盒基础设施

§5.2.5 的 DSec 是面向 agentic 场景的 sandbox 平台（Rust 写、3FS 上、单集群百万级并发 sandbox）。和 OPD 直接相关的有：

• Trajectory logging + preemption-safe resumption：当 RL/OPD 训练任务被抢占，sandbox 资源保留；resume 时 DSec replay 已完成的 command 的缓存结果，不重新执行非幂等操作（比如已经 commit 的 git 操作、已经发送的 HTTP）。
• 4 种执行 substrate 共享同一个 Python SDK 接口（Function Call / Container / microVM via Firecracker / fullVM via QEMU），从 lightweight tool 到 full SWE pipeline 全覆盖。
• 与 MiMo Toolbox + Tool Manager 思路类似，但 DSec 是有完整 trajectory 重放语义的设计，对长 horizon agent OPD 更友好。

跟 slime/GLM-5/MiMo 的总对比表（更新版）

把 DeepSeek-V4 的设计纳入前面两节的对比框架：

核心设计取向的差异可以一句话概括：

• slime / GLM-5：minimal-invasive，OPD 作为 RL 的扩展点；
• MiMo MOPD：multi-teacher knowledge fusion，OPD 是 RL 的主要 reward source；
• DeepSeek-V4：以"具备完整 logit 信号的 SFT-on-self-rollout"取代 mixed RL，把 RL 的探索完全留给上游 specialist。

关键数字 & 简历素材

DeepSeek-V4 OPD 这一节里能直接进简历当锚点的硬数字：

• DeepSeek-V4-Pro 1.6T 总参 / 49B activated；V4-Flash 284B / 13B
• 1M-token context 训练与 OPD（业界第一档）
• N > 10 个 trillion-class teacher，full-vocabulary OPD
• Vocab > 100k，靠 last-layer hidden state cache 把 logits 物化代价完全消除
• 每 mini-batch 至多 1 个 teacher prediction head 在 GPU 上（teacher index 排序调度）
• MXFP4 量化所有 teacher/ref forward
• TileLang fused KL kernel
• Token-granular WAL 解决长样本被抢占时的 length bias
• DSec：单集群数十万并发 sandbox

📌 Resume 钩子：DeepSeek-V4 这一节是简历里"为大规模 OPD 做了系统级 infra 工作"最有说服力的对照。可以写成 “Designed full-vocabulary OPD infrastructure for trillion-scale multi-teacher distillation: teacher hidden-state caching with on-the-fly logits reconstruction, teacher-index aware mini-batch scheduling, FP4 teacher inference, and token-granular WAL for length-bias-free preemption recovery”——能引出"为什么 full-vocab 不爆？““teacher head 怎么轮换？““为什么不能直接重生 unfinished rollout？““你怎么写 fused KL kernel？““1M context 下 rollout 数据怎么分层？” 这样一连串系统设计问题，全部都是你在 ByteDance Seed 的训练系统里直接对应的工作。

应用场景

参考资料

• https://zhuanlan.zhihu.com/p/690748958
• https://bytedance.larkoffice.com/wiki/DARvwNZaYiGDDukQfcgcTJSTnWc
• https://bytedance.larkoffice.com/wiki/Q0mjwdFKHiHUoPkYeGIcAAP2nUc
• https://zhuanlan.zhihu.com/p/1976701764272145341
• https://zhuanlan.zhihu.com/p/1966521167360790856
• https://github.com/volcengine/verl/tree/main/recipe/gkd