VeRL Feature Matrix
导言
这篇文章作为索引页，专门回答每个特性：怎么开、代码在哪、逻辑是什么、实践效果怎样、为什么默认不开、对 MFU / SMA 有什么作用。
1. Feature Matrix 表头¶
| feature | how to enable | code path | default | dependency | expected benefit | MFU / SMA impact | risk | verified |
|---|---|---|---|---|---|---|---|---|
2. 当前特性清单¶
| feature | 当前状态 | 后续要补的信息 |
|---|---|---|
| TQ | 待验证 | 准确含义、开关、代码路径、调度逻辑 |
| mooncake checkpoint | 待验证 | 保存语义、存储依赖、恢复流程、失败模式 |
| FullAsync | 待验证 | 配置项、异步队列、policy version 管理 |
| full async one-step offset | 待验证 | 与 FullAsync 的差异、错位方式、精度影响 |
| dynamic batch | 待验证 | use_dynamic_bsz 的配置路径、训练/推理口径 |
| SP / CP | 待验证 | 后端支持、切分维度、通信策略、mask / position 语义 |
| inference serving | 待验证 | 部署方式、权重同步、服务接口、监控指标 |
| fused kernels | 待验证 | use_fused_kernels 的支持范围和收益 |
3. 每个特性的标准写法¶
3.1 如何开关¶
- 配置文件字段。
- 启动脚本参数。
- 环境变量。
- 依赖版本或硬件条件。
3.2 代码位置¶
- trainer 层。
- worker 层。
- backend 层。
- rollout engine 层。
- platform / Ascend adapter 层。
3.3 特性逻辑¶
- 它改变了哪条数据流。
- 它改变了哪个 shape 或 shard 关系。
- 它改变了哪个生命周期或同步边界。
- 它是否引入新的队列、缓存、通信或状态。
3.4 实践效果¶
- baseline 指标。
- 开启后的指标。
- 单特性收益。
- 组合特性收益。
- 适用场景与不适用场景。
3.5 为什么默认不开¶
- 环境依赖强。
- 收益场景不稳定。
- 兼容性未完全覆盖。
- 精度、复现或恢复语义存在风险。
- 小规模场景收益小于复杂度成本。
4. TQ 条目模板¶
待验证
TQ 的准确含义必须从代码和文档确认，不能先入为主。
- 开关方式：待查。
- 代码位置：待查。
- 逻辑假设：可能与请求队列、token 队列、任务队列或传输队列有关。
- 预期收益：可能降低调度等待，提高推理侧吞吐或平滑 token 负载。
- 默认关闭原因：待确认，可能与环境依赖、兼容性或收益稳定性有关。
5. Mooncake Checkpoint 条目模板¶
- 开关方式：待查。
- 代码位置：待查。
- 逻辑：确认是否是异步保存、分布式分片保存或外部存储加速。
- 预期收益：减少 checkpoint 阻塞，提高长跑有效训练时间。
- 默认关闭原因：依赖存储环境，恢复语义需要验证。
6. FullAsync 条目模板¶
- 开关方式：待查。
- 代码位置：待查。
- 逻辑：拆开 rollout、reward、logprob、update 的同步边界。
- 预期收益：减少 stage idle，提高 E2E throughput。
- 默认关闭原因：staleness、复现、debug 和稳定性风险。
7. Full Async One-Step Offset 条目模板¶
- 开关方式：待查。
- 代码位置：待查。
- 逻辑：待确认是否是 step 级数据或权重错位。
- 预期收益：进一步减少同步等待。
- 默认关闭原因：policy lag 和精度稳定性风险。
8. Feature 验证流程¶
- 先确认代码路径和配置开关。
- 再跑最小可复现实验。
- 然后做单特性消融。
- 最后进入客户近似场景验证。
9. 验收标准¶
- 每个 feature 至少有一个可运行配置。
- 每个 feature 有明确 code path。
- 每个 feature 有 baseline 对比数据。
- 每个 feature 明确默认关闭原因。
- 每个 feature 明确对 MFU / SMA 或 E2E throughput 的作用路径。