Skip to content

[Dont merge]Enale FusedMoe kernel V2#448

Open
yihuaxu wants to merge 2 commits into
vllm-project:mainfrom
yihuaxu:dev/yihuaxu/qwen3.5/fused_moe_v2
Open

[Dont merge]Enale FusedMoe kernel V2#448
yihuaxu wants to merge 2 commits into
vllm-project:mainfrom
yihuaxu:dev/yihuaxu/qwen3.5/fused_moe_v2

Conversation

@yihuaxu

@yihuaxu yihuaxu commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

To optimize the performance for fused_moe

Purpose

Try to improve the performance based on current split moe kernels to save the io cost.

Test Plan

Test Result

UT:
Decode:
image

image

Prefill:
image

(Optional) Documentation Update

Copilot AI review requested due to automatic review settings July 3, 2026 02:40

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds a new “single-pass” SYCL implementation of the fused MoE path, exposes it as a new _moe_C.fused_moe custom op, and wires a Python-side dispatch switch (env-gated) to use it under specific constraints.

Changes:

  • Add a new env-gated dispatch path in XpuFusedMoe.apply() to call a new _moe_C.fused_moe op (intended for bf16/fp16, non-EP, non-quantized).
  • Introduce and register a new XPU custom op fused_moe(...) -> Tensor and its C++/SYCL implementation (fused_moe.cpp + fused_moe_impl.hpp).
  • Update the _moe_C extension build to compile with CUTLASS/Cute flags and include directories needed by the new kernel.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file
File Description
vllm_xpu_kernels/fused_moe_interface.py Adds env-controlled routing to the new fused MoE kernel path.
csrc/moe/torch_bindings.cpp Registers the new fused_moe custom op schema and XPU implementation binding.
csrc/moe/moe_ops.h Declares the new fused_moe entry point.
csrc/moe/fused_moe.cpp Implements the new fused MoE op and supporting top-k sorting on XPU/SYCL.
csrc/moe/fused_moe_impl.hpp Contains the SYCL kernel implementation (tiling, GEMMs, and reduction).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.


def _use_sycl_kernel_v2(self) -> bool:
"""Return True when the new single-pass SYCL kernel should be used."""
if not _is_env_enabled(FUSED_MOE_KERNEL_V2_ENV, "1"):
Comment on lines +290 to +292
elif self._use_sycl_kernel_v2():
self._apply_sycl_kernel(output, hidden_states,
topk_weights, topk_ids)
Comment thread csrc/moe/fused_moe.cpp
Comment on lines +93 to +95
static constexpr int COUNT_WG = 256;
static constexpr int WARP_SIZE = 16;
static constexpr int MAX_LOCAL = 32;
Comment thread csrc/moe/fused_moe.cpp
Comment on lines +198 to +202
const int H = (int)hidden_size;
const int I = (int)inter_size;
const int E = (int)num_experts;
const int NT = (int)input_tokens.size(0);
const int K = (int)topk_ids.size(1);
Comment thread csrc/moe/fused_moe.cpp
Comment on lines +222 to +227
torch::Tensor out;
if (output_opt.has_value())
out = output_opt.value();
else
out = torch::zeros_like(input_tokens);

@rogerxfeng8
rogerxfeng8 requested a review from mayuyuace July 12, 2026 04:53
@mayuyuace

Copy link
Copy Markdown
Collaborator

What's your motivation?

@mayuyuace

Copy link
Copy Markdown
Collaborator

The sole benefit of this PR is the reduction of intermediate variable movement.
For the prefill phase, performance is primarily compute-bound, so the bandwidth consumed by moving intermediate variables does not impact overall performance.
For the decoding phase, performance is primarily bound by MoE weight transfers, making the overhead of moving intermediate variables virtually negligible.
I don't think this PR will lead to a significant overall improvement in the model.

@yihuaxu
yihuaxu force-pushed the dev/yihuaxu/qwen3.5/fused_moe_v2 branch 2 times, most recently from d0bf749 to f377efc Compare July 14, 2026 04:34
yihuaxu added 2 commits July 14, 2026 12:43
Signed-off-by: Yihua Xu <yihua.xu@intel.com>
@yihuaxu yihuaxu changed the title [Dont merge]Enale FusedMoe kernel V2 (For testing) [Dont merge]Enale FusedMoe kernel V2 Jul 14, 2026
@yihuaxu

yihuaxu commented Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

What's your motivation?

To optimize the performance based on current MOE implementation.

@yihuaxu

yihuaxu commented Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

The sole benefit of this PR is the reduction of intermediate variable movement. For the prefill phase, performance is primarily compute-bound, so the bandwidth consumed by moving intermediate variables does not impact overall performance. For the decoding phase, performance is primarily bound by MoE weight transfers, making the overhead of moving intermediate variables virtually negligible. I don't think this PR will lead to a significant overall improvement in the model.

Please refer to the test result.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants