导言
能否把 MOV A, B 的直觉扩展到跨 device、跨节点甚至跨超节点：应用只给出源地址和目标地址，系统自动选择 HCCS、RDMA 等路径，把大 tensor 直接搬到消费者附近？可以把它做成 verl TransferQueue 的可插拔数据面，但不应把这件事直接称为“MTE 跨超节点”。MTE 是 Ascend 内存层级和部分 HCCS 路径上的搬运引擎；真正向应用提供远端地址、单边 put/get、注册和完成语义的是 SHMEM、MemFabric 一类软件层；样本字段、ready、consumed、staleness 和恢复仍应由 TransferQueue 管理。
导言
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 放在一起，整理一个后续实验可执行的评测地图。
导言
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：只把官方博客、技术报告、模型卡、开源仓库中明确披露的内容写成结论；如果资料只披露能力提升而没有披露训练阶段，就标注为“未公开”，不反推、不补脑。
导言
最近一直在出差，现实问题很直接：远端服务器连不上、GPU 不稳定、集群排队慢，但 SE 的核心工作并不会因此消失——还是要读代码、跑代码、改设计、做验证。
这篇系列草稿要解决的，不是“在 Mac 上替代生产集群”，而是一个更现实的问题：能不能在本地 Mac M4 16GB 的约束下，把 VeRL 的关键路径跑起来，做最小功能验证、快速 debug 和设计迭代。
如果这条路能走通，它不仅能改善出差场景下的开发效率，也会让后续的 AI 接管式功能开发 更容易落地：本地可复现、日志可追踪、入口可脚本化、失败可定位。
导言
RL 训练的指标不能只看 reward、loss 和 throughput。真正可用的 DFX 体系，需要同时解释 正确性、稳定性、显存、性能、负载均衡和数据质量。