Closed
【RFC】HyperParallel Multicore HyperMegaMoE 正反向融合算子 #312
hedongdongAdd on Aug 3Closed at Sep 18
Hhedongdong
Aug 3 Change title to "【RFC】HyperParallel Multicore HyperMegaMoE 正反向融合算子", originally titled "【RFC】HyperParallel Multicore HyperMegaMoE 正反向融合算子交付".
Aug 3 Change title to "【RFC】HyperParallel Multicore HyperMegaMoE 正反向融合算子", originally titled "【RFC】HyperParallel Multicore HyperMegaMoE 正反向融合算子交付".
Sep 18 changed custom state from TODO to DONE
Sep 18 Close issue
1 背景与目标
MoE 训练中的 Expert Parallel 计算链路同时包含 AllToAll 通信、Grouped MatMul、激活计算和路由归并。若各阶段按独立 kernel 串行执行,会导致通信暴露、AIC/AIV 资源交替空闲,以及中间结果的频繁读写。
本期计划交付面向 Multicore 场景的完整 MoE-FFN 融合算子 HyperMegaMoE,目标是:
DFunction自动求导接口,通过 HyperParallel 自定义算子 API 对外提供;2 交付范围
2.1 正向融合
正向算子的逻辑名称为
HyperMegaMoE,ACLNN 执行接口为aclnnHyperMegaMoE。融合计算链路为:
各阶段按 token/expert tile 拆分为任务,由 AIC worker 和 AIV worker 并发执行。任务之间通过事件计数表达生产者—消费者依赖,满足数据就绪条件后即可放行下游任务,不引入全局屏障。
正向对外输出最终 token 结果
y,shape 与输入x一致。中间的 dispatch buffer、GMM 输出、SwiGLU 输出和 combine buffer 不作为公共返回值。2.2 反向融合
反向算子的逻辑名称为
HyperMegaMoEGrad,ACLNN 执行接口为aclnnHyperMegaMoEGrad。反向计算链路为:
反向必须生成:
dx;up_proj_weight梯度d_up_proj_weight;down_proj_weight梯度d_down_proj_weight;d_topk_weights;None。W2Grad 与激活梯度分支可并行执行,W1Grad 与 Combine(dX) 可并行执行,以充分利用通信和计算之间的独立性。
2.3 命名约定
HyperMegaMoEHyperMegaMoEGradaclnnHyperMegaMoEGetWorkspaceSizeaclnnHyperMegaMoEGradGetWorkspaceSizeaclnnHyperMegaMoEaclnnHyperMegaMoEGradHyperMegaMoEDFunctionbackward自动调用HyperMegaMoEGradhyper_mega_moe3 用户接口
3.1 Python API
通过 HyperParallel 自定义算子接口导出:
from hyper_parallel.custom_ops.experimental import hyper_mega_moe y = hyper_mega_moe( x, topk_ids, topk_weights, up_proj_weight, down_proj_weight, )hyper_mega_moe保持完整 MoE 语义:路由预处理、offset 构造、unpermute 和 top-k 加权归并均由接口内部完成。基础多核算子的融合边界为 Dispatch → GMM1 → SwiGLU → GMM2 → Combine;Permute/Unpermute 进一步融入核心 kernel 属于可选性能增量,不改变公共签名。公共接口仅暴露以下必要参数:
x[T, H]topk_ids[T, K]topk_weights[T, K]up_proj_weight[E_local, H, 2I]down_proj_weight[E_local, I, H]返回值:
y:完成 top-k 加权归并后的 token 输出,shape 为[T, H]。3.2 DFunction 语义
HyperMegaMoEDFunction封装完整的正反向语义:forward调用HyperMegaMoE,并仅保存反向必需的激活、路由信息和权重;backward调用HyperMegaMoEGrad,向自动求导系统返回与公共参数一一对应的梯度;y的 DeviceMesh 与 token 维布局与x保持一致;3.3 内部管理的运行时资源
下列内容属于算子实现和运行时资源,不进入 Python 公共签名:
上述资源根据 Tensor/DTensor 的 shape、dtype、DeviceMesh、Placements 和路由结果生成或复用,并保证多次迭代时的事件状态正确重置。
4 功能语义
4.1 路由与专家并行
topk_ids使用全局专家编号;topk_ids展开为 K 个 expert slot;GMM1 → SwiGLU → GMM2;topk_weights完成加权归并。4.2 数值与边界约束
topk_ids的取值必须落在全局专家编号范围内;topk_weights的 token 维和 top-k 维必须与topk_ids一致;up_proj_weight的输出维必须等于2I,down_proj_weight的输入维必须等于I;5 多核调度与性能目标
5.1 AIC/AIV 并发
5.2 通信—计算重叠
5.3 运行时要求
6 可选增量能力
以下能力不作为 HyperMegaMoE 基础交付的阻断项,可根据本期资源与性能收益选择纳入。
6.1 共享专家融合 MoE
支持可选共享专家权重,将共享专家的 GMM1、SwiGLU、GMM2 与路由专家流水协同调度,并在 Combine 阶段合并共享专家输出。公共接口仅在启用该能力时增加 keyword-only 共享专家权重参数。
6.2 Permute/Unpermute 融合扩展
将 top-k token 展开、按专家排序、路由计数、反排序与 top-k 加权归并进一步融入 HyperMegaMoE 执行流程,减少额外 kernel launch 和中间 token 读写。扩展前后保持
hyper_mega_moe公共签名与数学语义不变。6.3 GMM 专家计算分组粒度优化
将 GMM 就绪与调度粒度从单一专家级拓展为
expert × block,根据专家实际 token 数选择 block M。小批次或长尾专家使用较小 block 缩短首块等待,大批次使用较大 block 保持 GMM 效率。6.4 Token Wave 优化
将专家 token 分成多个 wave,为每个
expert × wave设置独立就绪事件。前缀 wave 到齐后立即启动对应 GMM M-tile,并将局部完成信号逐级传递到 SwiGLU、GMM2 和 Combine。尾 wave 的就绪阈值使用真实 token 数,避免等待不存在的补齐 token。7 正确性与测试
7.1 功能测试
AllToAll + GroupedMatMul + SwiGLU + GroupedMatMul + AllToAll + weighted combine参考实现对齐;dx、d_topk_weights、d_up_proj_weight和d_down_proj_weight与参考实现对齐;rtol=atol=1e-3作为基础精度阈值,并在测试记录中说明 shape 和路由分布。7.2 路由与边界测试
7.3 稳定性测试
8 性能验收
性能验收使用固定的硬件、CANN 版本、dtype、T/H/I/E/K、EP 规模和路由分布,并同时报告正向、反向与端到端训练步耗时。
必须提供以下数据:
性能结论不跨硬件、精度、shape 或路由分布做直接排名。
9 文档与示例
交付内容包含:
hyper_mega_moeAPI 文档,说明参数、shape、dtype、DTensor layout、返回值和异常;10 验收标准
11 非本期必须项
以下内容只在选入可选增量时纳入对应验收:
expert × block的动态 GMM 分组粒度;expert × wave的 token wave 就绪与流水。