[Bugfix][NPU] Limit MiniMax H3 modulation grid size

[KrystalRay]

Purpose

MiniMax-H3 can launch 69,888 modulation rows on Ascend, exceeding CANN's 65,535 limit for a 1D coreDim and causing the kernel launch to fail.

This PR splits Ascend launches into chunks of at most 65,535 rows and passes a row offset to all four modulation kernels without changing their calculations. Other accelerator backends retain a single launch. It also adds boundary, launcher, and NPU numerical parity tests.

Fixes #6546.

Test Plan

vLLM Version: 0.28.0

python -m pytest -q \
  -m "core_model and cpu and diffusion" \
  tests/diffusion/models/minimax_h3/test_minimax_h3_modulation.py

ASCEND_RT_VISIBLE_DEVICES=0 python -m pytest -q \
  -m "core_model and npu and diffusion" \
  tests/diffusion/models/minimax_h3/test_minimax_h3_modulation.py::test_modulation_wrappers_match_reference_above_grid_limit

NPU regression environment:

• 4 × Ascend 910B3
• MiniMax-H3 from /tmp/MiniMax-H3/FL2VA
• Tensor parallel size: 4
• Requested resolution: 1280 × 720
• Inference steps: 2

Test Result

• CPU tests: 6 passed
• NPU numerical parity test: 1 passed
• All four public modulation wrappers passed with 69,888 rows.
• MiniMax-H3 4-card E2E generation completed with exit code 0.
• Generated 209 video frames and stereo 32 kHz audio.
• No coreDim, invalid-grid, or kernel-launch errors.
• Ruff and format checks passed.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

[vllm-omni-review-bot]

This PR appears to be related to model: MinimaxH3.

Model owners: @david6666666

@KrystalRay, 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]

[P3] The mooncake-transfer-engine-npu==0.3.13 pin is unrelated to the H3 grid fix and affects every NPU lane, not just this kernel path. The teardown-crash rationale is real, but it deserves its own PR with its own validation (and a note on what versions 0.28.0 images resolve today) so a pin regression can't be masked by this PR's test results. The chunking fix itself LGTM — boundary tests cover the exact 65,535 edge and the real 69,888-row case.

[KrystalRay]

[P3] The mooncake-transfer-engine-npu==0.3.13 pin is unrelated to the H3 grid fix and affects every NPU lane, not just this kernel path. The teardown-crash rationale is real, but it deserves its own PR with its own validation (and a note on what versions 0.28.0 images resolve today) so a pin regression can't be masked by this PR's test results. The chunking fix itself LGTM — boundary tests cover the exact 65,535 edge and the real 69,888-row case.

Thank you for pointing this out. I agree that the Mooncake version pin is outside the scope of this fix.

I have removed the dependency change and dropped the related commit. The PR is now limited to the MiniMax-H3 modulation grid fix and its regression coverage.

[congw729]

LGTM! The chunked launches keep each 1D grid within the Ascend CANN limit while preserving the row indexing across all four modulation kernels. The boundary coverage and reported NPU E2E validation look good. Thanks for the clean fix! 🚀

[hsliuustc0106]

[P2] This helper is called for every non-CPU tensor—the wrappers only bypass it on x.is_cpu / residual.is_cpu. That means CUDA also changes from one 69,888-row launch to two serialized launches per wrapper at the workload in this PR, adding launch overhead. Please either restrict chunking to the NPU path or add CUDA coverage/performance evidence and document the intentional cross-backend change.

[KrystalRay]

Thank you for pointing this out. I decided to follow the first suggested approach and restrict row chunking to the NPU path.

CUDA and other accelerator backends now retain the original single (rows,) launch with row_offset=0. I also extended the recording-kernel test to verify that NPU uses two launches for 69,888 rows while CUDA still uses one.
The CPU launcher tests and Ascend numerical parity test passed. I also validated the change with a 4-card MiniMax-H3 E2E run on Ascend 910B3.

Thank you again for the helpful suggestion. Please let me know if anything else should be adjusted.

[vllm-omni-review-bot]

Omni ReviewBot triage note

Automated triage of commit 2e1b4e0f53fe produced:

• Priority: high. Prompt maintainer attention is suggested.

These are automated triage suggestions only — the final decision belongs to the maintainers.

[KrystalRay]

All review feedback has been addressed. The required Buildkite status has not been reported for the latest commit yet. Could a maintainer please help trigger it when convenient? Thank you.

[KrystalRay]

The branch has now been rebased onto the latest main (HEAD: f5e41ea), which includes the ROCm test fix from #6830.

The previous AMD run used the pre-rebase commit and failed on the ROCm numerical tolerance issue fixed by #6830. The previous NPU run did not reach the tests due to a network timeout.

Could you please trigger fresh AMD and NPU Buildkite runs for the latest commit when convenient? Thank you!

[KrystalRay]

All checks pass, no conflicts. Could a maintainer merge when convenient? Thanks!

[KrystalRay]

This was caused by a merge interaction in the shared test file. The module-level pytestmark.cuda from main unintentionally marked the existing CPU/NPU tests as CUDA, and the appended imports also triggered E402.
I moved the imports to the top and scoped pytest.mark.cuda to the CUDA-only test. No runtime code or CUDA test logic was changed. Verified on Ascend 910B3: 7 passed, 1 CUDA-only test skipped as expected.
When you have time, could you please mark the PR as ready again and retry the merge?
@hsliuustc0106

[Gaohan123]

Please resolve conflicts. Thanks

[KrystalRay]

Please resolve conflicts. Thanks

Done. Conflicts resolved.