导言
判断并行能力不能只搜索配置名。一个并行轴至少要经过 配置校验、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 当前已有开关。
导言
VeRL async 的核心问题不是“开异步就一定更快”，而是把 rollout 长尾、训练更新、参数同步和旧样本容忍度放到同一个队列系统里调参。这篇笔记梳理 VeRL 老版 one_step_off_policy / fully_async_policy 与新版 trainer v1 的关系，解释 staleness 的真实语义，并给出 64P、128P NPU 场景下选择训推资源比例的第一轮计算方法。
导言
