导言
这篇笔记记录一次很窄的接入设计：在 verl release/v0.8.0 的 Qwen3.5 GRPO + FSDP 路径里，NPU 已经有 RMSNorm、RoPE、MoE GMM 等 patch，但 Gated Delta Net / GDN 仍然落在原始 eager 路径。目标不是改 GRPO 算法，而是给模型 forward 里的 chunk_gated_delta_rule 加一个可配置的 Triton 优先路径。
参考对象是 MindSpeed-MM 提交 5aaf0791d00abcbf5dd16af10091f4391030ad00：它把 Qwen3.5 的 GDN 计算模式显式化为 gdn_compute_mode，并区分 triton、ascendc、eager。本文给出的 verl 方案先接入 Triton，保留 eager 回退；AscendC 自定义算子作为后续扩展。
导言
MindSpeed core_r0.16.0 的 --use-fused-rotary-pos-emb 是普通 RoPE 路径：freqs -> cos/sin -> npu_rotary_position_embedding(x, cos, sin, mode)。torch_npu 另有 npu_rotary_mul、npu_interleave_rope、npu_mrope，其中 npu_mrope 可以覆盖推理侧多模态 MRoPE；这和 Megatron Bridge 的 config.apply_rope_fusion 不是同一个开关。
客户报错 Qwen3VLMultimodalRotaryEmbedding has no attribute get_rotary_seq_len 的直接含义是：Qwen3-VL 的 MRoPE 对象被送进了 Megatron Core 的普通 rope 分支。先修正分支：position_embedding_type="mrope"，apply_rope_fusion=False。如果要用 NPU MRoPE fused，应在 q/k rotary apply 处显式接 torch_npu.npu_mrope，不是打开普通 apply_rope_fusion。
导言
GMM 在 Qwen3.5 MoE 里的接入点是 routed experts 的两次矩阵乘：hidden -> gate/up 和 intermediate -> hidden。shared_expert 仍是普通 Qwen3_5MoeMLP，attention 不动，Dense 版 Qwen3.5 的普通 MLP 也不是替换对象。
PR #2664 的公开 diff 主要是给 mindspeed_mm.fsdp.ops.moe_ops.gemm.grouped_matmul 增加 fused/eager 一致性 UT，并放宽 unpermute UT 容差；它可以作为 GMM wrapper 接口被测试覆盖的证据，不能写成完整功能接入 PR。12
导言
MC2 的核心不是异步通信，而是 fused operator 内部的计算/通信切分与流水。MindSpeed-LLM 文档里的典型场景是 TP/SP 下的 matmul + all_reduce/all_gather/reduce_scatter；MindSpeed-MM PR #2480 接入的是 MoE expert parallel 下的 AllToAllv + GroupedMatmul 和 GroupedMatmul + AllToAllv。
本文只记录可迁移信息：PR 改了哪些文件、ep_mc2_forward 怎么跑、迁移前检查什么、怎么验证、哪些结论不能从公开资料直接外推。
导言
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 放在一起，整理一个后续实验可执行的评测地图。
导言
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，大概需要补哪些模块。