多模态生成 RL 的评测不能沿用 VLM 问答评测的一套逻辑。理解任务可以用正确答案、选项或短文本验证；生成任务还要评价 视觉质量、语义一致、运动时序、编辑边界、音频质量、音画同步和人类偏好。

因此，评测方案要先回答一个问题：训练时 reward 优化的是哪一种生成能力，最终 benchmark 是否真的测了同一种能力。本文把 AISBench、VBench、VEFX-Bench、Flow-Factory 和 VeRL-Omni 放在一起，整理一个后续实验可执行的评测地图。

dLLM 的核心变化不是把 LLM 外面套一层 diffusion 名字，而是把语言生成从 left-to-right next-token prediction 改成 masked denoising over a token canvas。这会连带改变 SFT 的数据变换、loss 位置、attention mask、采样器，以及 RL 中最敏感的 logprob 对齐方式。

本文基于 2026-06-25 对 inclusionAI/dFactory、ZHZisZZ/dllm 和 ByteDance-Seed/VeOmni 的源码调研，回答三个工程问题：dLLM 相对传统 LLM 原理有何不同，SFT/RL 代码流程如何变化，以及如果迁移到传统 SFT 仓 VeOmni，大概需要补哪些模块。

想用 AISBench 评测多模态 RL 后模型效果时，最容易误判的是把“多模态”当作一个整体类别。更精确的判断应该是：训练数据、奖励函数、输出格式和评测集必须在同一个能力域内闭合。

本文围绕 verl 当前常见的 Geo3K 多模态 RL 样例，以及新增的 TinyLLaVA-Video-R1-NextQA、multimodal-open-r1-8k-verified 两类数据，比较它们的规模、文本长度、模态、任务类型和 AISBench 评测匹配关系。

这篇文章用于持续梳理前沿 LLM/VLM 模型的 RL recipe：它们在什么 RL 框架下训练，经历了哪几个 RL 阶段，每个阶段使用什么算法，以及这些设计到底想解决什么问题。

这里的核心原则是 evidence-first：只把官方博客、技术报告、模型卡、开源仓库中明确披露的内容写成结论；如果资料只披露能力提升而没有披露训练阶段，就标注为“未公开”，不反推、不补脑。

RL 训练的指标不能只看 reward、loss 和 throughput。真正可用的 DFX 体系，需要同时解释 正确性、稳定性、显存、性能、负载均衡和数据质量。

这篇文章只回答一个问题：一条 RL 样本从 prompt 进入系统，到 rollout、reward、logprob、advantage、loss、backward，最后回到下一轮训练时，数据到底怎么流、shape 怎么变、显存为什么涨。

异步 RL 的核心不是简单“并行化 PPO”，而是把 rollout、reward / logprob、训练更新和参数同步之间的同步屏障拆成可控队列与版本语义。它用 bounded staleness 换取更高 E2E throughput，但必须同时回答 old logprob 一致性、policy lag、partial rollout、样本丢弃和复现实验的问题。

RL checkpoint 比普通 SFT checkpoint 更复杂，因为它不仅要保存模型参数，还要保存 optimizer、scheduler、global step、采样状态，以及在异步模式下可能存在的队列和策略版本状态。

这篇文章作为索引页，专门回答每个特性：怎么开、代码在哪、逻辑是什么、实践效果怎样、为什么默认不开、对 MFU / SMA 有什么作用。

MFU / SMA 低不一定说明 kernel 慢，也可能是 rollout、reward、checkpoint、通信、异步队列或 token 分布造成的等待。性能优化的第一步不是开特性，而是建立 E2E 性能模型。