[Feature]Use DispatchGmmCombineDecode operator to replace MC2(Optional)

[wangqiankun13]

What this PR does / why we need it?

This PR adds model-side integration for the previously introduced experimental AscendC fused operator DispatchGmmCombineDecode, used in MoE decoding.

The operator implementation itself was added in a prior PR#4139 .
This change only adapts the model execution path to optionally use the fused operator.

When the environment variable VLLM_ASCEND_ENABLE_FUSED_MC2=2 is set, the original MC2 path composed of multiple operators (A8W8 dispatch → GMM → SwiGLU → GMM → combine) might be replaced by the single fused operator DispatchGmmCombineDecode.

By default, the existing multi-operator MC2 implementation is preserved.

Does this PR introduce any user-facing change?

How was this patch tested?

• vLLM version: v0.12.0
• vLLM main: vllm-project/vllm@ad32e3e

[gemini-code-assist]

Code Review

This pull request introduces the DispatchGmmCombineDecode operator as a new fused MoE communication method (FUSED_MC2) to replace the existing MC2 implementation for w8a8_dynamic quantization on Ascend hardware. The changes include adding the necessary enum, environment variable, and implementation logic. My review focuses on improving code clarity and fixing a potential bug related to handling shared experts. I've identified a misleading docstring, hardcoded values that should be parameterized, and a complex conditional that could be simplified for better maintainability.

[gemini-code-assist]

The parameters shared_expert_num and shared_expert_rank_num are hardcoded. This implementation ignores the shared_experts parameter passed to the function, which likely contains the necessary information for handling shared experts. This will lead to incorrect behavior when shared experts are used. The values should be derived from the function arguments to correctly support shared experts.

[wangqiankun13]

Done

[gemini-code-assist]

The docstring for FusedMC2CommImpl appears to be copied from MC2CommImpl and is misleading. It mentions npu_moe_distribute_dispatch and npu_moe_distribute_combine, but this implementation uses the dispatch_gmm_combine_decode operator. The docstring should be updated to reflect the actual implementation and its requirements, such as being specific to w8a8_dynamic quantization, to improve maintainability.

Suggested change

	"""This implementation is for the scenarios listed below:
	1. `enable_expert_parallel=True`.
	2. `npu_moe_distribute_dispatch` and `npu_moe_distribute_combine` are available.
	3. `enable_expert_parallel=False` is not supported.
	This implementation uses the FusedMC2 communication method, which is optimized for
	Communication and Computation parallelism on Ascend devices.
	"""
	"""This implementation is for the scenarios listed below:
	1. `enable_expert_parallel=True`.
	2. `VLLM_ASCEND_ENABLE_FUSED_MC2` is enabled.
	3. `w8a8_dynamic` quantization is used.
	This implementation uses the `dispatch_gmm_combine_decode` operator, which is a fused
	operator for MoE decoding that combines communication and computation for optimization
	on Ascend devices.
	"""

[wangqiankun13]

Done

[gemini-code-assist]

This nested ternary expression is difficult to read and maintain. Consider refactoring it into a more explicit if/else structure to improve clarity.

Suggested change

	moe_comm_type = (
	MoECommType.MC2 if num_tokens <= mc2_tokens_capacity else
	MoECommType.FUSED_ALLTOALL if quant_type == "w8a8_dynamic"
	and get_ep_group().world_size <= 16 else MoECommType.ALLTOALL)
	(MoECommType.FUSED_MC2 if envs_ascend.VLLM_ASCEND_ENABLE_FUSED_MC2 and quant_type == "w8a8_dynamic"
	else MoECommType.MC2) if num_tokens <= mc2_tokens_capacity
	else MoECommType.FUSED_ALLTOALL if quant_type == "w8a8_dynamic" and get_ep_group().world_size <= 16
	else MoECommType.ALLTOALL)
	if num_tokens <= mc2_tokens_capacity:
	if envs_ascend.VLLM_ASCEND_ENABLE_FUSED_MC2 and quant_type == "w8a8_dynamic":
	moe_comm_type = MoECommType.FUSED_MC2
	else:
	moe_comm_type = MoECommType.MC2
	elif quant_type == "w8a8_dynamic" and get_ep_group().world_size <= 16:
	moe_comm_type = MoECommType.FUSED_ALLTOALL
	else:
	moe_comm_type = MoECommType.ALLTOALL

[wangqiankun13]

Done

[github-actions]

👋 Hi! Thank you for contributing to the vLLM Ascend project. The following points will speed up your PR merge:‌‌

• A PR should do only one thing, smaller PRs enable faster reviews.
• Every PR should include unit tests and end-to-end tests ‌to ensure it works and is not broken by other future PRs.
• Write the commit message by fulfilling the PR description to help reviewer and future developers understand.

If CI fails, you can run linting and testing checks locally according Contributing and Testing.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[weijinqian0]

remove this envs variables

[wangqiankun13]

As new conclusion, we use the same one env variable with dispatch_fnn_combine operator.

[linfeng-yuan]

Since the operator currently only supports w8a8_dynamic. It is necessary to disblae ths usage of fused_mc2 in mtp_proposer.py in case the dtype of mtp is bfloat16 (notice both _dummy_run and propose should be changed):
Option 1 (Recommended):
Recognize the quant_type of mtp layer (e.g., through the instance class of FusedMoE) to decide the moe_comm_method of this layer.
Option 2:
Refer to #4751 and #4947, use hard_code to disable fused_op paths in mtp_proposer. But please add a note here and future plan.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[wangqiankun13]

Since the operator currently only supports w8a8_dynamic. It is necessary to disblae ths usage of fused_mc2 in mtp_proposer.py in case the dtype of mtp is bfloat16 (notice both _dummy_run and propose should be changed): Option 1 (Recommended): Recognize the quant_type of mtp layer (e.g., through the instance class of FusedMoE) to decide the moe_comm_method of this layer. Option 2: Refer to #4751 and #4947, use hard_code to disable fused_op paths in mtp_proposer. But please add a note here and future plan.

Since FUESD_MC2 must be enabled by env variable now, my operator will not incur issues in default. I will add mtp guard later and has add a note and future here.

[kiscad]

LGTM