判断并行能力不能只搜索配置名。一个并行轴至少要经过 配置校验、process group/device mesh、模型计算、loss/backward 和目标训练流程，才能算后端支持。

截至本文固定的 verl commit，结论最明确的一项是：原生 FSDP2 支持 Ulysses Sequence Parallel（USP），但不支持 Expert Parallel（EP）和 Context Parallel（CP）。如果希望 FSDP2 同时使用 EP，应选 VeOmni；如果需要 TP、PP、EP、CP 的完整模型并行组合，应选 Megatron。

XTuner 的 Domino EP 不是一种新的 EP 通信算子，而是位于 MoE 层内部的跨微批调度方法：把多个原本独立做梯度累积的 micro-batch 一起送入模型，用异步通信流把一个 micro-batch 的 token dispatch/combine 与另一个 micro-batch 的专家计算重叠。

普通 EP 定义专家如何切分；All-to-All、DeepEP、AGRS 决定 token 如何搬运；Domino EP 决定多个 micro-batch 如何交错；MC2 则把相邻通信和矩阵乘融合进一个算子。只有先分清这些层次，才能正确讨论它们的优劣和组合关系。

HybridEP 论文进一步提出了一个更上游的问题：跨数据中心带宽太低、通信已经无法完全隐藏时，是否还应坚持“专家不动、所有 token 都跨域搬运”？它通过比例 (p) 在 token All-to-All 与压缩 expert AllGather 之间选择，改变的是通信对象与专家放置，而不是给 DeepEP 或 MC2 换一个名字。

2026 年 8 月的增量观察再补两层：MoonEP 与 UltraEP 都根据当前 micro-batch 的真实路由结果复制热点 expert，但 MoonEP 自己拥有 dispatch/combine 并追求每 rank 固定 S×K 行，UltraEP 则把配额规划、跨层副本 buffer 和权重/梯度同步做成独立运行时，继续复用外部 dispatcher 与 Grouped GEMM。HyperParallel-MoE 则在 Ascend A3 上把 Dispatch、两次 GMM、SwiGLU 和 Combine 编译成 AIC/AIV 瓦片任务流。这些路线分别回答“热点怎么摊平”和“单个 MoE-FFN 怎么细粒度交错”，都不是 XTuner 当前已有开关。

训练 profiling 通常围绕 forward、backward、optimizer 和通信几类稳定阶段展开；推理 profiling 则更像一条被压扁的多层时间带：prefill、decode、spec decode、采样、图模式、host 同步、调度空隙和特殊融合算子会叠在同一个 step 里。

这篇文章用一次 vLLM-Ascend trace 作为样本，先把 Free、vllm::gdn_attention_core、FusedInferAttentionScore、GemmaRmsNorm、fused_sigmoid_gating_delta_rule_update_kernel_0、aclnnInplaceUniform_DSARandomUniform_DSARandomUniform 这些名字拆开，再总结一套以后跟踪新模型融合算子的 checklist。

截至 2026-07-07，Ascend 950 A5 对多模态生成的公开支持已经不是零，但它更像三层拼图：vLLM-Omni 已把 Ascend NPU、Wan2.2/Qwen-Image 等 diffusion 量化路径写进文档；vLLM-Ascend 主分支出现 A5/950 与 MXFP/W8A8 等后端代码；VeRL-Omni 已能用 vLLM-Omni 做 Ascend NPU rollout，但量化默认仍是空配置，公开 recipe 还没有给出 A5 量化 RL 的性能和精度结论。本文只写可追溯来源，尤其区分“文档支持”“代码路径”“验证效果”和“仍需实测”。

这篇文章记录一次从“pod4 比 pod8 跑 Qwen3.5 397B SFT 慢约 10%”出发的集群健康定位。普通 allgather 打流没有复现差异，并不等于训练链路健康；真实慢点可能在 CPU 绑核、H2D、固定两卡 D2D、背景设备负载、rank-to-core 放置和框架调度之间。ClusterHealthDetect 的作用，是把这些变量拆成可复现实验矩阵，成为训练性能模型里的校准账本。

讨论 BSND/TND 时，最容易误判的是把 推理 prefill 支持 当成 训练全链路支持。对 Qwen3.5 这类含 Gated Delta Net 的模型，TND 不只是把 [B, S, N, D] reshape 成 [T, N, D]：训练还要覆盖 backward、recurrent state、cu_seqlens、label / loss mask、old logprob、ref logprob、actor update 和框架并行契约。

本文的结论是：推理 TND 是中等工程量，训练 TND 是大工程量；verl 已经支持 Qwen3.5 RL，但具体 layout 支持取决于 FSDP/Megatron/MindSpeed/vLLM 路径，不能一概而论。

这篇文章记录 AI infra、post-training 和 multimodal serving 方向的每日 PR / issue 雷达。每轮只深入少量 P0/P1 项：优先性能、多模态、调度、attention、padding、KV cache、MTP、NPU / Ascend 相关变化。

VeRL async 的核心问题不是“开异步就一定更快”，而是把 rollout 长尾、训练更新、参数同步和旧样本容忍度放到同一个队列系统里调参。这篇笔记梳理 VeRL 老版 one_step_off_policy / fully_async_policy 与新版 trainer v1 的关系，解释 staleness 的真实语义，并给出 64P、128P NPU 场景下选择训推资源比例的第一轮计算方法。

这篇笔记记录一次很窄的接入设计：在 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。