TransferQueue 不是普通 FIFO queue，也不只是 rollout 侧的 token queue。它更像 RL 后训练的数据系统：controller 仍然负责编排训练流程，但大 tensor 的读写、字段就绪状态、样本消费记录和跨 worker 数据传输被拆到独立 data plane 中。

Router Replay 的核心不是让 MoE 路由更快，而是把 rollout、old logprob 重算和 new logprob 更新三段路径的专家选择对齐。MoE 的 top-k routing 是离散分叉，微小数值差异会导致 expert 集合突变；一旦 old/new logprob 的差异混入“路由换了”而不是“策略变了”，PPO / GRPO 的 ratio、clip 和 KL 都会失真。

RL rollout 中的 speculative decoding 不是普通推理加速的简单移植。普通 serving 只关心 latency、throughput 和用户体验；RL rollout 还必须保证 response、old logprob、reward、advantage 和 policy loss 都对应同一个 verifier policy。

换句话说，draft model 可以帮助系统更快地产生候选 token，但训练语义必须仍然属于 target / verifier policy。

这篇文章现在作为 verl / RL infra 特性地图：把 vLLM 图模式、speculative decoding、router replay、FullAsync / AsyncFlow 和 TransferQueue 放到同一张系统图里，但不再承载所有细节。

核心结论仍然是：这些特性不在同一层。 有的减少推理执行开销，有的解决 decode 串行性，有的保证 MoE 路由一致性，有的把 rollout 与训练重叠，有的把数据从 single controller 中解耦。真正的收益来自先定位瓶颈，再打开对应特性。

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

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

想用 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、样本丢弃和复现实验的问题。