[Bugfix] Fix Triton operator usage for multimodal models based on the mrope_interleaved parameter

[zhangxinyuehfad]

What this PR does / why we need it?

When running the Qwen2.5-Omni-7B model on Ascend NPU, the engine fails during the profiling/warmup stage with the following error: AclNN_Runtime_Error(EZ9903): rtKernelLaunchWithHandleV2 failed: 507035. The vector core execution is abnormal.

error log: https://github.com/vllm-project/vllm-ascend/actions/runs/21144534911/job/60806765393#step:17:6412

This error is specifically triggered by the triton_mrope kernel when handling the unique mrope_section configurations of the Omni model. Other multimodal models with standard sections (e.g., [16, 24, 24]) or standard LLMs work correctly with Triton.

Modified vllm_ascend/ops/rotary_embedding.py to add a conditional check before calling forward_triton.

1. For standard LLMs (mrope_interleaved = True ), it continues to use Triton for acceleration.

2. For complex configurations (like Qwen2.5-Omni mrope_interleaved = False ), it now falls back to the native super().forward_oot() path, which uses the stable torch_npu or PyTorch implementation.

Does this PR introduce any user-facing change?

How was this patch tested?

• vLLM version: v0.13.0
• vLLM main: vllm-project/vllm@d682094

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

Code Review

This pull request addresses a critical bug causing NPU vector core errors when running models with complex mrope_section configurations, such as Qwen2.5-Omni. The fix involves modifying AscendMRotaryEmbedding.forward_oot to bypass the triton_mrope kernel and fall back to more stable torch_npu or native PyTorch implementations.

The change correctly prevents the failing Triton kernel from being called. However, the implementation is confusing and logically flawed. The condition self.mrope_section is None is always false for AscendMRotaryEmbedding, making the if block dead code. I've provided a suggestion to make the intent of disabling the Triton path explicit and improve code clarity and maintainability.