| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[Feature] Support fused moe Co-authored-by: betta18<jiangmengyu1@huawei.com> # message auto-generated for no-merge-commit merge: !310 merge support_fused_moe_new into dev [Feature] Support fused moe Created-by: betta18 Commit-by: betta18 Merged-by: ascend-robot Description: <!-- PR描述模板更新日期：20251224 --> # Which issue(s) this PR fixes or accomplishes Fix part of #ISSUE ID # Purpose 本 PR 新增 MindIE-SD 的 fused_moe 融合算子接口，用于支持开源框架在 NPU 上执行 MoE 前向计算。当前 PR 接入的是 fused_moe 的 fallback 路径，已基于 vllm-omni 中 HunyuanImage-3.0 模型的 MindIE-SD MoE 组网路径完成适配验证。 当前 fused_moe 对外提供统一入口，并区分两条执行路径： - **融合算子路径**：预留融合 MoE 算子入口，当前版本暂不支持。 - **fallback 路径**：本 PR 接入的执行路径，用于完成 MoE 路由、专家计算和结果合并流程。 fallback 路径将 MoE 前向过程拆分为多个阶段： - prepare：整理输入激活和 router logits，并根据输入 layout 准备后续计算所需的数据。 - select_experts：根据 router 输出，为每个 token 选择对应的 top-k experts，并生成 routing weights。 - dispatch：根据专家选择结果，将 token 按 expert 路由并重排，生成专家计算所需的输入。 - mlp：执行专家侧 grouped MLP 计算，完成 routed experts 的前馈计算。 - combine：将专家输出按原 token 顺序合并，恢复 routed MoE 的输出结果。 - finalize：完成输出恢复和通信后的收尾处理。 通过 fallback 路径的阶段化封装，外部调用方只需要使用 fused_moe 统一入口，即可完成当前版本支持的 MoE 前向计算流程。 主要修改包括： - 新增并导出 fused_moe 融合算子接口。 - 预留融合 MoE 算子路径，并接入 fallback 路径作为当前执行实现。 - 新增 mindiesd.layers.moe 阶段化 MoE fallback 实现。 - 新增 runtime context 处理逻辑，用于集中校验外部入参、生成通信上下文并封装各阶段输入对象。 - 新增专家选择逻辑，支持 top-k routing、routing weight 归一化和自定义 routing function。 - 新增 static dispatcher，用于完成静态 token 分发、expert token 统计和结果恢复。 - 新增 dynamic dispatcher，用于完成动态 token 分发、all-to-all token 交换和结果恢复。 - 新增 grouped expert MLP 计算逻辑，基于 torch_npu.npu_grouped_matmul 完成专家前馈计算。 - 新增 MoE 通信上下文和基础通信算子封装。 - 扩展 NPU 平台识别，新增 A3 平台，并使相关 MoE/attention 路径能够识别 A3。 - 新增 fused_moe 中文特性文档，补充接口说明、参数约束、融合算子路径、fallback 路径、通信配置和使用示例。 后续计划： - 性能优化。 - 支持量化。 # Test Plan 测试重点包括： - fused_moe 入口： - 融合算子路径当前版本暂不支持时回退到 fallback 路径。 - fallback 路径调用阶段化 MoE 实现。 - fallback moe 主流程： - static dispatcher 路径。 - dynamic dispatcher 路径。 - 无通信组、TP 通信组、EP 通信组场景。 - runtime context： - 外部输入参数校验。 - prepare、routing、dispatch、MLP compute 阶段输入对象封装。 - MoE 通信上下文选择。 - 专家选择： - top-k expert 选择。 - top-k weight 归一化。 - 自定义 routing function。 - token dispatch/combine： - static dispatch 的 token 排序、expert token 统计和结果恢复。 - dynamic dispatch 的 all-to-all token 交换和顺序恢复。 - grouped expert MLP： - w13 / w2 两阶段 grouped matmul。 - bias 路径。 - swiglu activation。 - 通信算子： - all-gather。 - reduce-scatter。 - all-reduce。 - all-to-all single。 - 精度测试： - 对比 static MoE 输出与参考实现结果的一致性。 - 对比 grouped expert MLP 输出与参考实现结果的一致性。 - 验证 HunyuanImage-3.0 MindIE-SD MoE 组网路径下的推理结果正确性。 # Test Report 在 MindIE-SD 中新增 MoE 相关单元测试，主要覆盖 fallback 路径中的通信算子、专家选择、runtime context、主流程、专家 MLP 计算和 token dispatch/combine 等核心逻辑： - tests/layers/moe/test_comm_ops.py - tests/layers/moe/test_experts_selector.py - tests/layers/moe/test_runtime_context.py - tests/layers/moe/test_moe.py - tests/layers/moe/test_moe_mlp.py - tests/layers/moe/test_token_dispatcher.py 在 vllm-omni 框架中，基于 HunyuanImage-3.0 的 MindIE-SD MoE 组网路径完成端到端推理验证，结果正确。验证覆盖： - EP / TP 通信场景。 - static / dynamic dispatcher 路径。 - tokens_full 不同输入 layout。 - reduce_results 不同结果规约配置。 See merge request: Ascend/MindIE-SD!310 | 30 天前 | |
[Feature] Support fused moe Co-authored-by: betta18<jiangmengyu1@huawei.com> # message auto-generated for no-merge-commit merge: !310 merge support_fused_moe_new into dev [Feature] Support fused moe Created-by: betta18 Commit-by: betta18 Merged-by: ascend-robot Description: <!-- PR描述模板更新日期：20251224 --> # Which issue(s) this PR fixes or accomplishes Fix part of #ISSUE ID # Purpose 本 PR 新增 MindIE-SD 的 fused_moe 融合算子接口，用于支持开源框架在 NPU 上执行 MoE 前向计算。当前 PR 接入的是 fused_moe 的 fallback 路径，已基于 vllm-omni 中 HunyuanImage-3.0 模型的 MindIE-SD MoE 组网路径完成适配验证。 当前 fused_moe 对外提供统一入口，并区分两条执行路径： - **融合算子路径**：预留融合 MoE 算子入口，当前版本暂不支持。 - **fallback 路径**：本 PR 接入的执行路径，用于完成 MoE 路由、专家计算和结果合并流程。 fallback 路径将 MoE 前向过程拆分为多个阶段： - prepare：整理输入激活和 router logits，并根据输入 layout 准备后续计算所需的数据。 - select_experts：根据 router 输出，为每个 token 选择对应的 top-k experts，并生成 routing weights。 - dispatch：根据专家选择结果，将 token 按 expert 路由并重排，生成专家计算所需的输入。 - mlp：执行专家侧 grouped MLP 计算，完成 routed experts 的前馈计算。 - combine：将专家输出按原 token 顺序合并，恢复 routed MoE 的输出结果。 - finalize：完成输出恢复和通信后的收尾处理。 通过 fallback 路径的阶段化封装，外部调用方只需要使用 fused_moe 统一入口，即可完成当前版本支持的 MoE 前向计算流程。 主要修改包括： - 新增并导出 fused_moe 融合算子接口。 - 预留融合 MoE 算子路径，并接入 fallback 路径作为当前执行实现。 - 新增 mindiesd.layers.moe 阶段化 MoE fallback 实现。 - 新增 runtime context 处理逻辑，用于集中校验外部入参、生成通信上下文并封装各阶段输入对象。 - 新增专家选择逻辑，支持 top-k routing、routing weight 归一化和自定义 routing function。 - 新增 static dispatcher，用于完成静态 token 分发、expert token 统计和结果恢复。 - 新增 dynamic dispatcher，用于完成动态 token 分发、all-to-all token 交换和结果恢复。 - 新增 grouped expert MLP 计算逻辑，基于 torch_npu.npu_grouped_matmul 完成专家前馈计算。 - 新增 MoE 通信上下文和基础通信算子封装。 - 扩展 NPU 平台识别，新增 A3 平台，并使相关 MoE/attention 路径能够识别 A3。 - 新增 fused_moe 中文特性文档，补充接口说明、参数约束、融合算子路径、fallback 路径、通信配置和使用示例。 后续计划： - 性能优化。 - 支持量化。 # Test Plan 测试重点包括： - fused_moe 入口： - 融合算子路径当前版本暂不支持时回退到 fallback 路径。 - fallback 路径调用阶段化 MoE 实现。 - fallback moe 主流程： - static dispatcher 路径。 - dynamic dispatcher 路径。 - 无通信组、TP 通信组、EP 通信组场景。 - runtime context： - 外部输入参数校验。 - prepare、routing、dispatch、MLP compute 阶段输入对象封装。 - MoE 通信上下文选择。 - 专家选择： - top-k expert 选择。 - top-k weight 归一化。 - 自定义 routing function。 - token dispatch/combine： - static dispatch 的 token 排序、expert token 统计和结果恢复。 - dynamic dispatch 的 all-to-all token 交换和顺序恢复。 - grouped expert MLP： - w13 / w2 两阶段 grouped matmul。 - bias 路径。 - swiglu activation。 - 通信算子： - all-gather。 - reduce-scatter。 - all-reduce。 - all-to-all single。 - 精度测试： - 对比 static MoE 输出与参考实现结果的一致性。 - 对比 grouped expert MLP 输出与参考实现结果的一致性。 - 验证 HunyuanImage-3.0 MindIE-SD MoE 组网路径下的推理结果正确性。 # Test Report 在 MindIE-SD 中新增 MoE 相关单元测试，主要覆盖 fallback 路径中的通信算子、专家选择、runtime context、主流程、专家 MLP 计算和 token dispatch/combine 等核心逻辑： - tests/layers/moe/test_comm_ops.py - tests/layers/moe/test_experts_selector.py - tests/layers/moe/test_runtime_context.py - tests/layers/moe/test_moe.py - tests/layers/moe/test_moe_mlp.py - tests/layers/moe/test_token_dispatcher.py 在 vllm-omni 框架中，基于 HunyuanImage-3.0 的 MindIE-SD MoE 组网路径完成端到端推理验证，结果正确。验证覆盖： - EP / TP 通信场景。 - static / dynamic dispatcher 路径。 - tokens_full 不同输入 layout。 - reduce_results 不同结果规约配置。 See merge request: Ascend/MindIE-SD!310 | 30 天前 | |
[Feature][moe]Support NPU moe_gating_top_k and moe_gating_top_k_softmax in fused MoE module Co-authored-by: betta18<jiangmengyu1@huawei.com> # message auto-generated for no-merge-commit merge: !318 merge support_fused_softmax_topk into dev [Feature][moe]Support NPU moe_gating_top_k and moe_gating_top_k_softmax in fused MoE module Created-by: betta18 Commit-by: betta18 Merged-by: ascend-robot Description: <!-- PR描述模板更新日期：20251224 --> # Which issue(s) this PR fixes or accomplishes N/A - 内部特性开发，无对应 Issue。 # Purpose 在 fused_moe 模块中接入 torch_npu.npu_moe_gating_top_k 和 torch_npu.npu_moe_gating_top_k_softmax 两个 CANN 算子， 替代原先 Python 端 softmax/sigmoid + topk 组合实现， 将专家选择阶段下沉到 NPU，提升路由效率。 算子选择策略： - **npu_moe_gating_top_k_softmax**：应用于 softmax 非分组路由 （routing_method="softmax" 且分组路由参数为默认值），接口更轻量； - **npu_moe_gating_top_k**：应用于 sigmoid 路由或分组路由场景， 完整支持分组路由等高级功能。 性能对比（softmax + topk 组合，num_tokens=256, num_experts=64, top_k=8）： - 小算子实现（softmax + topk 分步执行）：114 us - 融合算子实现（npu_moe_gating_top_k_softmax）：61 us - 加速比：**约 1.87x** 同时新增以下能力： - **分组路由**：通过 k_group、group_count、group_select_mode 参数支持 先选 expert group、再从选中 group 选 top-k experts 的路由策略； - **路由方法**：routing_method 参数支持 softmax 和 sigmoid 两种打分方式； - **参数校验**：validate_moe_inputs 中新增分组路由相关边界校验； - **测试覆盖**：新增 NPU gating top-k 算子与 PyTorch 参考实现的一致性测试， 覆盖 softmax/sigmoid、分组/非分组、group_select_mode 0/1 共 4 种路由组合， 并新增 test_gating_topk_softmax_matches_torch_reference 专门验证 softmax 非分组路径在各种输入形状下的正确性。 此外，将 MoE 测试环境按 CPU 兼容和 NPU 依赖拆分： - CPU 兼容测试（MINDIE_TEST_MODE=CPU 跳过）仅验证 custom_routing_function 路径和参数校验逻辑； - NPU 依赖测试（MINDIE_TEST_MODE=NPU 跳过）验证算子与参考实现的一致性， 使 CI 可在无 NPU 环境下运行部分测试。 # Test Plan 1. **CPU 兼容测试**（MINDIE_TEST_MODE=CPU）：验证 custom_routing_function 路径 和参数校验逻辑； 2. **NPU 依赖测试**（MINDIE_TEST_MODE=NPU）：验证 NPU gating top-k 算子输出与 torch_grouped_topk_reference 参考实现的一致性，包括两种算子的各条路径； 3. **E2E 前向测试**：test_moe.py 中静态 MoE NPU 全流程前向测试； 4. **参数校验测试**：test_moe_context.py 中新增 routing_method、k_group、 group_count、group_select_mode 非法值校验。 # Test Report 已在 NPU 环境执行测试，结果如下： - TestExpertsSelectorNPU.test_gating_topk_matches_torch_reference：PASS （softmax、grouped_softmax、sigmoid、grouped_sigmoid 4 个子 case 全部通过） - TestExpertsSelectorNPU.test_gating_topk_softmax_matches_torch_reference：PASS （B=2/4/1/3, num_experts=8/16/32/64, top_k=2/4/1/8 共 4 种形状组合全部通过） - TestMoeFunction.test_static_moe_matches_torch_reference：PASS （top_k=1 和 top_k=2 两个子 case 全部通过，atol=5e-2, rtol=5e-2） - TestMoEContext 参数校验测试：PASS - TestExpertsSelector.test_custom_router_output_is_forwarded：PASS（CPU 通路） See merge request: Ascend/MindIE-SD!318 | 26 天前 | |
[Bugfix][moe]Fix MoE dispatcher routing and W8A8 precision alignment Co-authored-by: betta18<jiangmengyu1@huawei.com> # message auto-generated for no-merge-commit merge: !382 merge fix_dispatcher_default_routing into dev [Bugfix][moe]Fix MoE dispatcher routing and W8A8 precision alignment Created-by: betta18 Commit-by: betta18 Merged-by: ascend-robot Description: # Which issue(s) this PR fixes or accomplishes Fix part of #ISSUE ID # Purpose 本 PR 修复 MindIE-SD MoE 默认 dispatcher 选择和 W8A8 dynamic quant 路径中的精度问题。 主要修改包括： - 调整 MoE 默认 dispatcher 选择逻辑： - 原默认路由参考 vllm-ascend 的机型选择策略：A2 默认 static dispatcher，A3/A5 默认 dynamic dispatcher。 - 该策略主要适配大 EP 场景，通常满足 top_k < ep_size，dynamic dispatcher 更容易发挥通信优势。 - 同时，由于 A2 跨机 all-to-all 通信劣化较明显，因此 vllm-ascend 中 A2 默认使用 static dispatcher。 - MindIE-SD 作为通用 MoE 接口，不再直接按机型选择 dispatcher，而是根据 top_k 与 ep_size 的关系选择默认路径。 - 在 tokens_full=False 场景下，static dispatcher 需要先通过 all-gather 将各 rank 的 local tokens 拼成 full tokens，再在 finalize 阶段通过 reduce-scatter 返回 rank-local 结果。设全局 token 数为 T，hidden size 为 H，EP size 为 P，每个 token 选择 K 个 experts，则 static dispatcher 单 rank 通信量近似为 2 * T * H。 - dynamic dispatcher 不需要提前聚合 full tokens，而是在 dispatch/combine 两个阶段按 expert 所属 rank 交换被路由命中的 token。平均分布下，单 rank 通信量近似为 2 * T * K / P * H，约为 static dispatcher 的 K / P。 - 因此，当 top_k < ep_size 时，dynamic dispatcher 通常具有更低通信量；当 top_k >= ep_size 时，dynamic dispatcher 的通信优势下降，默认选择 static dispatcher 更稳妥。 - 非 EP 场景默认走 static dispatcher。 - 修复专家路由权重 dtype 导致的精度问题： - select_experts 输出的 topk_weights 转为 hidden_states.dtype。 - 避免 routing weight dtype 与后续 dispatch/combine 计算 dtype 不一致导致的 MoE 输出精度偏差。 - 对齐 W8A8 dynamic quant 行为： - W8A8 dynamic quant 显式指定 dst_type=torch.int8。 - 覆盖 prepare、dynamic dispatch 和 MLP 内部量化兜底路径，避免默认量化 dtype 带来的精度差异。 - 同步更新 MoE 相关测试： - 更新默认 dispatcher 选择测试，覆盖 top_k < ep_size 走 dynamic、top_k >= ep_size 走 static。 - 增加 W8A8 dynamic quant 显式 dst_type=torch.int8 的测试断言。 - 更新 W8A8 dynamic MLP 预量化路径精度对齐测试。 # Test Plan 测试重点包括： - MoE dispatcher 默认选择逻辑： - 非 EP 场景默认 static。 - EP 场景下 top_k < ep_size 默认 dynamic。 - EP 场景下 top_k >= ep_size 默认 static。 - 显式 dispatcher_type 可覆盖默认选择。 - MoE routing： - topk_weights dtype 与输入激活 dtype 对齐。 - 验证 routing weight dtype 对 MoE 输出精度的影响已修复。 - W8A8 dynamic quant： - dynamic dispatcher 在 all-to-all 前显式执行 INT8 dynamic quant。 - static prepare 在 all-gather 前显式执行 INT8 dynamic quant。 - MLP 内部量化路径与外部预量化路径保持一致。 # Test Report 在 MindIE-SD 中更新 MoE 相关单元测试，覆盖 dispatcher 路由选择、W8A8 dynamic quant 参数传递和 MLP 预量化精度对齐等场景。 涉及测试文件： - tests/layers/moe/test_moe.py - tests/layers/moe/test_moe_mlp.py - tests/layers/moe/test_token_dispatcher.py See merge request: Ascend/MindIE-SD!382 | 10 小时前 | |
[Bugfix][moe]Fix MoE dispatcher routing and W8A8 precision alignment Co-authored-by: betta18<jiangmengyu1@huawei.com> # message auto-generated for no-merge-commit merge: !382 merge fix_dispatcher_default_routing into dev [Bugfix][moe]Fix MoE dispatcher routing and W8A8 precision alignment Created-by: betta18 Commit-by: betta18 Merged-by: ascend-robot Description: # Which issue(s) this PR fixes or accomplishes Fix part of #ISSUE ID # Purpose 本 PR 修复 MindIE-SD MoE 默认 dispatcher 选择和 W8A8 dynamic quant 路径中的精度问题。 主要修改包括： - 调整 MoE 默认 dispatcher 选择逻辑： - 原默认路由参考 vllm-ascend 的机型选择策略：A2 默认 static dispatcher，A3/A5 默认 dynamic dispatcher。 - 该策略主要适配大 EP 场景，通常满足 top_k < ep_size，dynamic dispatcher 更容易发挥通信优势。 - 同时，由于 A2 跨机 all-to-all 通信劣化较明显，因此 vllm-ascend 中 A2 默认使用 static dispatcher。 - MindIE-SD 作为通用 MoE 接口，不再直接按机型选择 dispatcher，而是根据 top_k 与 ep_size 的关系选择默认路径。 - 在 tokens_full=False 场景下，static dispatcher 需要先通过 all-gather 将各 rank 的 local tokens 拼成 full tokens，再在 finalize 阶段通过 reduce-scatter 返回 rank-local 结果。设全局 token 数为 T，hidden size 为 H，EP size 为 P，每个 token 选择 K 个 experts，则 static dispatcher 单 rank 通信量近似为 2 * T * H。 - dynamic dispatcher 不需要提前聚合 full tokens，而是在 dispatch/combine 两个阶段按 expert 所属 rank 交换被路由命中的 token。平均分布下，单 rank 通信量近似为 2 * T * K / P * H，约为 static dispatcher 的 K / P。 - 因此，当 top_k < ep_size 时，dynamic dispatcher 通常具有更低通信量；当 top_k >= ep_size 时，dynamic dispatcher 的通信优势下降，默认选择 static dispatcher 更稳妥。 - 非 EP 场景默认走 static dispatcher。 - 修复专家路由权重 dtype 导致的精度问题： - select_experts 输出的 topk_weights 转为 hidden_states.dtype。 - 避免 routing weight dtype 与后续 dispatch/combine 计算 dtype 不一致导致的 MoE 输出精度偏差。 - 对齐 W8A8 dynamic quant 行为： - W8A8 dynamic quant 显式指定 dst_type=torch.int8。 - 覆盖 prepare、dynamic dispatch 和 MLP 内部量化兜底路径，避免默认量化 dtype 带来的精度差异。 - 同步更新 MoE 相关测试： - 更新默认 dispatcher 选择测试，覆盖 top_k < ep_size 走 dynamic、top_k >= ep_size 走 static。 - 增加 W8A8 dynamic quant 显式 dst_type=torch.int8 的测试断言。 - 更新 W8A8 dynamic MLP 预量化路径精度对齐测试。 # Test Plan 测试重点包括： - MoE dispatcher 默认选择逻辑： - 非 EP 场景默认 static。 - EP 场景下 top_k < ep_size 默认 dynamic。 - EP 场景下 top_k >= ep_size 默认 static。 - 显式 dispatcher_type 可覆盖默认选择。 - MoE routing： - topk_weights dtype 与输入激活 dtype 对齐。 - 验证 routing weight dtype 对 MoE 输出精度的影响已修复。 - W8A8 dynamic quant： - dynamic dispatcher 在 all-to-all 前显式执行 INT8 dynamic quant。 - static prepare 在 all-gather 前显式执行 INT8 dynamic quant。 - MLP 内部量化路径与外部预量化路径保持一致。 # Test Report 在 MindIE-SD 中更新 MoE 相关单元测试，覆盖 dispatcher 路由选择、W8A8 dynamic quant 参数传递和 MLP 预量化精度对齐等场景。 涉及测试文件： - tests/layers/moe/test_moe.py - tests/layers/moe/test_moe_mlp.py - tests/layers/moe/test_token_dispatcher.py See merge request: Ascend/MindIE-SD!382 | 10 小时前 | |
[Feature][moe]Support INT8 MoE inference Co-authored-by: betta18<jiangmengyu1@huawei.com> # message auto-generated for no-merge-commit merge: !329 merge support_fused_moe_int8 into dev [Feature][moe]Support INT8 MoE inference Created-by: betta18 Commit-by: betta18 Merged-by: ascend-robot Description: <!-- PR描述模板更新日期：20251224 --> # Which issue(s) this PR fixes or accomplishes Fix part of #ISSUE ID # Purpose 本 PR 在 MindIE-SD 的 fused_moe 阶段化 MoE 路径中新增 INT8 MoE 推理支持，并同步完善接口参数、运行时上下文、阶段间数据封装、MLP 计算、Token 分发和中文特性文档。 主要修改包括： - 新增 quant_type、w13_weight_scale、w2_weight_scale 参数，支持通过 fused_moe 入口传入 INT8 MoE 所需权重和 scale。 - 扩展 MoE 入参校验，覆盖 INT8 权重 dtype、scale 类型、scale shape、bias 限制和非量化路径参数约束。 - 新增 MoE quant context，用于在 MoE 主流程、dispatcher 和 grouped MLP 之间传递量化模式。 - 重构 MoE 阶段间数据结构，新增 MoEWeights、MoEPrepareOutput、MoETokenDispatchOutput，统一封装 prepare、dispatch 和 MLP 阶段输入输出。 - 新增 INT8 grouped MLP 路径，支持动态量化激活、复用 dispatcher 侧量化输出、INT8 权重 NZ 格式检查与转换。 - 扩展 static / dynamic dispatcher 的 INT8 支持： - static 路径支持 npu_moe_init_routing_v2 生成或复用 dynamic scale。 - dynamic 路径支持在 all-to-all 前量化 Token，并同步交换 dynamic scale。 - 更新 docs/zh/features/fused_moe.md，补充 INT8 参数说明、量化约束和使用示例。 # Test Plan 测试重点包括： - MoE 入参校验： - INT8 权重 dtype 校验。 - quantization scale 类型、shape 和 dtype 校验。 - INT8 路径不支持 bias 的校验。 - 非量化路径不允许传入 scale 的校验。 - MoE context 和阶段封装： - quant context 设置与查询。 - MoEWeights、MoEPrepareOutput、MoETokenDispatchOutput 构造。 - prepare、dispatch、MLP 阶段输入输出封装。 - Token dispatch： - static dispatcher INT8 dispatch。 - static dispatcher 复用 prepare 阶段 dynamic scale。 - static dispatcher 在 partial input 场景下先量化再 all-gather。 - dynamic dispatcher 在 all-to-all 前量化 Token，并同步传递 dynamic scale。 - dynamic dispatcher split copy event 同步逻辑。 - Grouped MLP： - 非量化 BF16 / FP16 grouped MLP 精度。 - INT8 grouped MLP 使用 dispatcher 侧量化输出。 - INT8 权重 NZ 格式检查与自动转换。 - INT8 内部动态量化路径与外部量化输入路径一致性。 - 端到端 MoE： - static MoE 非量化精度。 - INT8 MoE 输出 shape 和 dtype。 - dispatcher 自动选择和手动 override。 # Test Report 在 MindIE-SD 中新增和更新 MoE 相关单元测试，覆盖 INT8 MoE 的参数校验、上下文封装、Token 分发、grouped MLP 和主流程： - tests/layers/moe/test_moe_context.py - tests/layers/moe/test_token_dispatcher.py - tests/layers/moe/test_moe_mlp.py - tests/layers/moe/test_moe.py - tests/layers/moe/test_experts_selector.py 已覆盖： - INT8 参数校验和异常路径。 - static / dynamic dispatcher 的 INT8 dispatch 行为。 - dynamic scale 在 prepare、dispatch、MLP 阶段间的传递。 - INT8 权重 NZ 格式检查和转换。 - INT8 grouped MLP 内部动态量化与外部量化输入的一致性。 - BF16 / FP16 非量化 MoE 精度回归。 See merge request: Ascend/MindIE-SD!329 | 18 天前 | |
[Bugfix][moe]Fix MoE dispatcher routing and W8A8 precision alignment Co-authored-by: betta18<jiangmengyu1@huawei.com> # message auto-generated for no-merge-commit merge: !382 merge fix_dispatcher_default_routing into dev [Bugfix][moe]Fix MoE dispatcher routing and W8A8 precision alignment Created-by: betta18 Commit-by: betta18 Merged-by: ascend-robot Description: # Which issue(s) this PR fixes or accomplishes Fix part of #ISSUE ID # Purpose 本 PR 修复 MindIE-SD MoE 默认 dispatcher 选择和 W8A8 dynamic quant 路径中的精度问题。 主要修改包括： - 调整 MoE 默认 dispatcher 选择逻辑： - 原默认路由参考 vllm-ascend 的机型选择策略：A2 默认 static dispatcher，A3/A5 默认 dynamic dispatcher。 - 该策略主要适配大 EP 场景，通常满足 top_k < ep_size，dynamic dispatcher 更容易发挥通信优势。 - 同时，由于 A2 跨机 all-to-all 通信劣化较明显，因此 vllm-ascend 中 A2 默认使用 static dispatcher。 - MindIE-SD 作为通用 MoE 接口，不再直接按机型选择 dispatcher，而是根据 top_k 与 ep_size 的关系选择默认路径。 - 在 tokens_full=False 场景下，static dispatcher 需要先通过 all-gather 将各 rank 的 local tokens 拼成 full tokens，再在 finalize 阶段通过 reduce-scatter 返回 rank-local 结果。设全局 token 数为 T，hidden size 为 H，EP size 为 P，每个 token 选择 K 个 experts，则 static dispatcher 单 rank 通信量近似为 2 * T * H。 - dynamic dispatcher 不需要提前聚合 full tokens，而是在 dispatch/combine 两个阶段按 expert 所属 rank 交换被路由命中的 token。平均分布下，单 rank 通信量近似为 2 * T * K / P * H，约为 static dispatcher 的 K / P。 - 因此，当 top_k < ep_size 时，dynamic dispatcher 通常具有更低通信量；当 top_k >= ep_size 时，dynamic dispatcher 的通信优势下降，默认选择 static dispatcher 更稳妥。 - 非 EP 场景默认走 static dispatcher。 - 修复专家路由权重 dtype 导致的精度问题： - select_experts 输出的 topk_weights 转为 hidden_states.dtype。 - 避免 routing weight dtype 与后续 dispatch/combine 计算 dtype 不一致导致的 MoE 输出精度偏差。 - 对齐 W8A8 dynamic quant 行为： - W8A8 dynamic quant 显式指定 dst_type=torch.int8。 - 覆盖 prepare、dynamic dispatch 和 MLP 内部量化兜底路径，避免默认量化 dtype 带来的精度差异。 - 同步更新 MoE 相关测试： - 更新默认 dispatcher 选择测试，覆盖 top_k < ep_size 走 dynamic、top_k >= ep_size 走 static。 - 增加 W8A8 dynamic quant 显式 dst_type=torch.int8 的测试断言。 - 更新 W8A8 dynamic MLP 预量化路径精度对齐测试。 # Test Plan 测试重点包括： - MoE dispatcher 默认选择逻辑： - 非 EP 场景默认 static。 - EP 场景下 top_k < ep_size 默认 dynamic。 - EP 场景下 top_k >= ep_size 默认 static。 - 显式 dispatcher_type 可覆盖默认选择。 - MoE routing： - topk_weights dtype 与输入激活 dtype 对齐。 - 验证 routing weight dtype 对 MoE 输出精度的影响已修复。 - W8A8 dynamic quant： - dynamic dispatcher 在 all-to-all 前显式执行 INT8 dynamic quant。 - static prepare 在 all-gather 前显式执行 INT8 dynamic quant。 - MLP 内部量化路径与外部预量化路径保持一致。 # Test Report 在 MindIE-SD 中更新 MoE 相关单元测试，覆盖 dispatcher 路由选择、W8A8 dynamic quant 参数传递和 MLP 预量化精度对齐等场景。 涉及测试文件： - tests/layers/moe/test_moe.py - tests/layers/moe/test_moe_mlp.py - tests/layers/moe/test_token_dispatcher.py See merge request: Ascend/MindIE-SD!382 | 10 小时前 | |
[Bugfix][moe]Fix MoE dispatcher routing and W8A8 precision alignment Co-authored-by: betta18<jiangmengyu1@huawei.com> # message auto-generated for no-merge-commit merge: !382 merge fix_dispatcher_default_routing into dev [Bugfix][moe]Fix MoE dispatcher routing and W8A8 precision alignment Created-by: betta18 Commit-by: betta18 Merged-by: ascend-robot Description: # Which issue(s) this PR fixes or accomplishes Fix part of #ISSUE ID # Purpose 本 PR 修复 MindIE-SD MoE 默认 dispatcher 选择和 W8A8 dynamic quant 路径中的精度问题。 主要修改包括： - 调整 MoE 默认 dispatcher 选择逻辑： - 原默认路由参考 vllm-ascend 的机型选择策略：A2 默认 static dispatcher，A3/A5 默认 dynamic dispatcher。 - 该策略主要适配大 EP 场景，通常满足 top_k < ep_size，dynamic dispatcher 更容易发挥通信优势。 - 同时，由于 A2 跨机 all-to-all 通信劣化较明显，因此 vllm-ascend 中 A2 默认使用 static dispatcher。 - MindIE-SD 作为通用 MoE 接口，不再直接按机型选择 dispatcher，而是根据 top_k 与 ep_size 的关系选择默认路径。 - 在 tokens_full=False 场景下，static dispatcher 需要先通过 all-gather 将各 rank 的 local tokens 拼成 full tokens，再在 finalize 阶段通过 reduce-scatter 返回 rank-local 结果。设全局 token 数为 T，hidden size 为 H，EP size 为 P，每个 token 选择 K 个 experts，则 static dispatcher 单 rank 通信量近似为 2 * T * H。 - dynamic dispatcher 不需要提前聚合 full tokens，而是在 dispatch/combine 两个阶段按 expert 所属 rank 交换被路由命中的 token。平均分布下，单 rank 通信量近似为 2 * T * K / P * H，约为 static dispatcher 的 K / P。 - 因此，当 top_k < ep_size 时，dynamic dispatcher 通常具有更低通信量；当 top_k >= ep_size 时，dynamic dispatcher 的通信优势下降，默认选择 static dispatcher 更稳妥。 - 非 EP 场景默认走 static dispatcher。 - 修复专家路由权重 dtype 导致的精度问题： - select_experts 输出的 topk_weights 转为 hidden_states.dtype。 - 避免 routing weight dtype 与后续 dispatch/combine 计算 dtype 不一致导致的 MoE 输出精度偏差。 - 对齐 W8A8 dynamic quant 行为： - W8A8 dynamic quant 显式指定 dst_type=torch.int8。 - 覆盖 prepare、dynamic dispatch 和 MLP 内部量化兜底路径，避免默认量化 dtype 带来的精度差异。 - 同步更新 MoE 相关测试： - 更新默认 dispatcher 选择测试，覆盖 top_k < ep_size 走 dynamic、top_k >= ep_size 走 static。 - 增加 W8A8 dynamic quant 显式 dst_type=torch.int8 的测试断言。 - 更新 W8A8 dynamic MLP 预量化路径精度对齐测试。 # Test Plan 测试重点包括： - MoE dispatcher 默认选择逻辑： - 非 EP 场景默认 static。 - EP 场景下 top_k < ep_size 默认 dynamic。 - EP 场景下 top_k >= ep_size 默认 static。 - 显式 dispatcher_type 可覆盖默认选择。 - MoE routing： - topk_weights dtype 与输入激活 dtype 对齐。 - 验证 routing weight dtype 对 MoE 输出精度的影响已修复。 - W8A8 dynamic quant： - dynamic dispatcher 在 all-to-all 前显式执行 INT8 dynamic quant。 - static prepare 在 all-gather 前显式执行 INT8 dynamic quant。 - MLP 内部量化路径与外部预量化路径保持一致。 # Test Report 在 MindIE-SD 中更新 MoE 相关单元测试，覆盖 dispatcher 路由选择、W8A8 dynamic quant 参数传递和 MLP 预量化精度对齐等场景。 涉及测试文件： - tests/layers/moe/test_moe.py - tests/layers/moe/test_moe_mlp.py - tests/layers/moe/test_token_dispatcher.py See merge request: Ascend/MindIE-SD!382 | 10 小时前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 30 天前 | ||
| 30 天前 | ||
| 26 天前 | ||
| 10 小时前 | ||
| 10 小时前 | ||
| 18 天前 | ||
| 10 小时前 | ||
| 10 小时前 |