[XPU][MoE Refactor] Refactor xpu mxfp4 support into oracle

[jikunshang]

Purpose

follow up of #37128, move xpu mxfp4 support into oracle as well.

Test Plan

Test Result

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[jikunshang]

@zyongye @mgoin @robertgshaw2-redhat PTAL, thanks!

[gemini-code-assist]

Code Review

This pull request refactors the XPU MXFP4 support for Mixture-of-Experts layers to integrate it into the MoE oracle system. This is achieved by removing the specialized XpuMxfp4MoEMethod and introducing a new XPUExpertsMXFp4 class that can be selected by the oracle. While this is a good refactoring for modularity, I've identified a potential performance regression. The previous implementation used XPU-specific custom operators for routing, but the new implementation appears to fall back to a generic PyTorch-based router. My review includes a comment highlighting this issue and asking for clarification.

I am having trouble creating individual review comments. Click here to see my feedback.

vllm/model_executor/layers/quantization/mxfp4.py (416-506)

By removing XpuMxfp4MoEMethod, the routing logic for XPU MXFP4 MoE layers is now handled by the generic Router class. The previous implementation used XPU-specific custom ops (torch.ops._moe_C.fused_grouped_topk and torch.ops._moe_C.topk_softmax) for routing, which are likely more performant on XPU hardware.

The new implementation uses a pure PyTorch-based router, which might cause a performance regression, especially for models that use grouped top-k routing. Was this change in routing implementation intentional? If the custom routing ops are still desired, the logic from XpuMxfp4MoEMethod.apply_monolithic might need to be preserved, perhaps by creating a monolithic XPU expert class (FusedMoEExpertsMonolithic) that can be selected by the oracle and can perform the specialized routing.