[Refactor][Device][7/N] Migrate MoE compilation and sampling to hardware profiles

[Tflowers-0129]

What

• add the final MoE/compilation/sampling hardware capabilities and a MoECommPolicy
• migrate MoE communication selection, graph fusion gates, routing, shared experts, token dispatch, SwiGLU-OAI MX quant, and top-k/top-p sampling away from direct device identity checks
• preserve the latest upstream Situ, hierarchical communication, SFA, DSV4, sampler, and CANN MegaMoe paths
• model the new A3-only CANN MegaMoe consumer with HardwareCapability.CANN_MEGAMOE and update the exact capability matrix

Why

Shared business logic should consume hardware capabilities and implementation policies instead of branching on Ascend device identities. This keeps hardware detection/profile registration as the single identity boundary and makes the final consumers explicit.

This is a refactor only; there is no user-visible behavior change.

Series

Device HAL / Hardware Profile refactor 7/N.

Depends on merged #15407 (d4ebe8a0e0fdf56135507259f90f80a45f736cab) and is rebased onto current main (30f54b5c341f015bcc124022e62156d3e5ef5919). This base includes the GLM5.3 documentation-link fix from #15508 and the MegaMoe prefill update from #14439.

Testing

• ruff check on all 14 changed Python files
• ruff format --check on all 14 changed Python files
• python3 -m compileall -q on all 14 changed Python files
• git diff --check upstream/main..HEAD
• production-code scan for newly introduced direct device-identity branches
• E2E run https://github.com/vllm-project/vllm-ascend/actions/runs/33579196584: 23 successful jobs, 4 skipped, zero failures; CPU, all selected NPU jobs, 310P, upstream, pre-commit, DCO, Read the Docs, and ci-gate succeeded

The local static checks above passed. The development server does not provide the complete pytest/mypy/vLLM environment, so targeted unit tests and Python 3.10/3.11/3.12 mypy comparison are covered by the successful CI run and are not claimed as local results.

[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.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request serves as the final installment (7/7) of the Device HAL refactor series. It completes the decoupling of shared business logic from specific Ascend device identities by transitioning MoE compilation, routing, and sampling to a hardware capability and policy-based architecture. This change improves maintainability and simplifies the integration of future hardware targets by ensuring that consumers of shared logic rely on explicit capability checks rather than branching on device identity.

Highlights

• MoE Communication Policy: Introduced the MoECommPolicy enum to define and select communication strategies based on hardware profiles rather than hardcoded device types.
• Hardware Capabilities: Added new HardwareCapability flags for MoE dispatch, sampling, and graph fusion features to support more granular hardware feature detection.
• Logic Migration: Migrated core MoE compilation, routing, and sampling logic away from direct Ascend device identity checks to a capability-based system.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

Suggested PR Title:

[Ops][Misc] Refactor hardware capability and MoE communication policy checks

Suggested PR Summary:

### What this PR does / why we need it?
This PR refactors the hardware capability and MoE communication policy checks across the codebase. Instead of directly checking `AscendDeviceType` (e.g., `A2`, `A3`, `A5`, `310P`), the code now queries the active `HardwareProfile` for specific `HardwareCapability` flags and `MoECommPolicy` configurations. This decouples device-specific logic from operator and communication implementations, making the codebase more maintainable and extensible for future hardware generations.

Additionally, a review comment suggests optimizing the hot path in `select_moe_comm_method` by moving the `selector_by_policy` dictionary to the module level as a constant to avoid recreation overhead on every forward pass.

### Does this PR introduce _any_ user-facing change?
No. This is an internal refactoring of hardware profile and capability checks.

### How was this patch tested?
Existing unit tests in `tests/ut/device/test_hardware_profile.py`, `tests/ut/ops/a2/test_token_dispatcher.py`, `tests/ut/ops/test_moe_mlp.py`, and `tests/ut/test_ascend_forward_context.py` were updated to mock the hardware profile and passed successfully.

[github-actions]

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