[Bugfix][Ascend] fix npu 310/a5 bugs

[zyz111222]

Purpose

This PR aims to fix the bugs in running Qwen3-TTS on the Atlas A5 machine and 310.
The changes strive to minimize alterations to the mainline logic, adding A5-specific patches only where necessary. The primary adjustments include reverting torch.stft to CPU execution and rolling back the format conversion of conv.

Test Results

seed-tts-eval zh results:

Performance benchmarking:
A5:

310:

[vllm-omni-review-bot]

This PR appears to belong to: docs/design/module/execution_platforms.md.

Module owners: @gcanlin @tjtanaa @xuechendi

@zyz111222, please review your own changes and leave a short self-review comment describing what you checked. PRs without author self-review may not be assigned a reviewer.

Please take a look when you have a chance. If you would like an automated review, mention @vllm-omni-review-bot in a comment.

[hsliuustc0106]

@zyz111222 Good platform-specific bugfix for NPU A5 compatibility! This PR addresses critical issues preventing Qwen3-TTS from running on Atlas A5 machines. The fix includes reverting torch.stft to CPU execution and rolling back FRACTAL_Z format conversion, with comprehensive test coverage. Minimal, targeted changes that don't impact other platforms.

[tzhouam]

@vllm-omni-review-bot please review

[vllm-omni-review-bot]

Omni ReviewBot review

PR description

This PR adds Ascend 950 detection to the NPU Qwen3-TTS patches. On A5, prompt mel/STFT processing runs on CPU before the speaker encoder receives the result on NPU, and decoder convolution weights avoid the FRACTAL_Z cast; other NPUs retain the existing path.

Change flow

flowchart LR
A[NPU platform startup] --> B[Apply Qwen3-TTS patches]
B --> C{Ascend 950?}
C -- yes --> D[CPU mel/STFT; NPU encoder; ND conv weights]
C -- no --> E[Existing builder and conv format path]

Loading

See inline comments below.

[vllm-omni-review-bot]

[P2] Do not treat hardware-probe failures as non-A5

The catch-all handler converts any runtime failure from is_950() into False. That result is then used to skip the CPU prompt-builder replacement and to permit the FRACTAL_Z convolution cast. If probing temporarily fails on an A5, the code silently selects both unsupported operations and can reproduce the original failures; the platform startup call also does not retry the builder patch. Restrict the compatibility fallback to a genuinely missing API and surface other probe failures, or use an explicit unknown state that cannot select the incompatible path.

[FayeSpica]

This duplicates the extract_speaker_embedding implementation in the 310P patch. Could we extract the shared CPU mel frontend into a common helper and reuse it in both paths?

[zyz111222]

The extract_speaker_embedding has been extracted to the public script.

[FayeSpica]

_apply_a5_prompt_embeds_builder_patch is outside the scope implied by qwen3_tts_code2wav.py. Could we rename this module to qwen3_tts.py now that it contains patches for both Code2Wav and the prompt-embeds builder?

[zyz111222]

This module has been renamed qwen3_tts.

[FayeSpica]

Non-blocking: is_a5 and is_310p serve the same hardware-detection responsibility but currently live at different abstraction levels. Would it be cleaner to put them together in a shared module.

platforms/npu/__init__.py
platforms/npu/_310p/__init__.py

[zyz111222]

Currently, the differences between a5 and the mainline are minor, with only one unadapted operator. Therefore, this is essentially a workaround solution. As such, it is still expected not to be too tightly coupled with the 310. Hence, I suggest keeping this in place.

[FayeSpica]

I’ve finished my review. Comments have been addressed, no blocking concerns from my side.

@gcanlin @tzhouam PTAL when you have time. Thanks!

[tzhouam]

LGTM