[CI] vllm drop v0.23.0 and upgrade v0.24.0

[MrZ20]

What this PR does / why we need it?

This PR is a follow-up to #11875.

PR #11875 introduced the vLLM v0.24.0 support. Those adaptation changes are treated as the baseline and are intentionally not repeated in this description.

This PR removes the remaining vLLM v0.23.0 compatibility paths from main.

Most changes only remove v0.23.0 branches and keep the existing v0.24/main implementation. Those mechanical removals are not listed individually below.

Release defaults and documentation

Update the default VLLM_TAG in all maintained Dockerfiles from v0.23.0 to v0.24.0.

The main-branch support matrix, slash-command examples, and balance-scheduler design documents are updated accordingly. This prevents source-built images and contributor documentation from continuing to select the unsupported v0.23 release.

Fused MoE weight layout boundary

Keep an explicit vllm_version_is("0.24.0") branch in both the standard and 310P unquantized Fused MoE implementations.

Upstream vLLM PR vllm-project/vllm#44589 was merged as 5051698e, 26 commits after the v0.24.0 cut point, and is present in the verified-main revision. Therefore v0.24.0 and verified main do not share the same post-load weight-layout behavior:

• v0.24.0 explicitly materializes the transposed weights as contiguous tensors before the NPU layout conversion;
• verified main follows the post-PR #44589 path without forcing the same intermediate contiguous layout.

The standard and 310P unit tests cover both version-specific layouts, the current MoE runner contract, shared-expert handling, and the 310P-specific communication method.

Qwen3.5/Qwen3Next output contract

Change the version boundary in the GDN and Qwen3.5/Qwen3Next patches from v0.23.0 to v0.24.0.

Upstream vLLM PR vllm-project/vllm#46998 was merged as 300e3379, after the v0.24.0 cut point and before the current verified-main revision. It changed the attention contract from writing into a caller-provided output buffer to returning the output tensor.

Balance scheduler alignment

BalanceScheduler.schedule() is a downstream copy of the upstream scheduler body because the balance admission logic cannot be implemented through a small wrapper.

The copied body is therefore updated from the v0.23.0 implementation to the v0.24.0 implementation while preserving only the existing balance-scheduling deltas.

Both supported upstream references now expose:

schedule(self, throttle_prefills: bool = False)

The old signature-introspection compatibility code is removed and the disabled path delegates directly to super().schedule(throttle_prefills).

The v0.24 scheduler alignment also preserves the corresponding upstream behavior for:

• DP prefill throttling;
• speculative-token and maximum-length accounting;
• hybrid Mamba KV-cache hit handling;
• resumed-request bookkeeping;
• dynamic speculative decoding;
• deferred KV-block freeing;
• MRV1-only previous-step request tracking.

The balance scheduler unit tests and English/Chinese design documents are updated to use v0.24.0 as the release reference. The drift test continues to verify that the copied scheduler body differs from the pinned upstream release only by the intended balance deltas.

Deferred removal of owner-maintained patches

The following compatibility patches and their unit tests are intentionally retained in this PR:

• GLM47 zero-argument tool-call streaming parser;
• MiniMax-M2 incremental tool-call parser;
• MiniMax usage accounting;
• tool_choice=none empty-tool_calls response cleanup.

The first three remain behind the existing vllm_version_is("0.23.0") condition, with a TODO explaining that their owners will remove them in a follow-up. The patch_tool_choice_none_content registration is also left unchanged for the same ownership reason.

These files are not required by the newly supported v0.24/main lanes, but deleting owner-maintained patches is intentionally outside the scope of this compatibility cleanup.

Test boundaries

The two Qwen3 MoE/EPLB E2E files previously ran only on v0.23.0 and were skipped on main. Since v0.23.0 is removed and the cases remain broken on both v0.24.0 and verified main, they are now explicitly skipped on both supported lanes instead of being unintentionally re-enabled.

The newly rebased MRV2 data-parallel test is skipped on v0.24.0 rather than v0.23.0. MRV2 remains supported only by the verified-main lane, as established by PR #11875.

The HunyuanVL release helper names are updated from _v023_* to _v024_* because the bundled-processor compatibility path now targets v0.24.0. This is a naming correction only; the HunyuanVL adaptation itself belongs to PR #11875.

Does this PR introduce any user-facing change?

Yes.

The vLLM Ascend main branch no longer supports vLLM v0.23.0. Docker builds that do not override VLLM_TAG now use vLLM v0.24.0 by default.

There is no additional API change for the supported v0.24.0 and verified-main lanes.

How was this patch tested?

• vLLM version: v0.23.0
• vLLM main: vllm-project/vllm@85c09e9

[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 upgrades the vLLM dependency to v0.24.0. The changes include updating all relevant configuration files, Docker images, and documentation to reflect the new version. Additionally, the PR performs a significant cleanup by removing legacy compatibility code and test files that were no longer needed after the transition from v0.23.0.

Highlights

• Version Upgrade: Bumped the vLLM dependency from v0.23.0 to v0.24.0 across all Dockerfiles, documentation, and configuration files.
• Legacy Code Cleanup: Removed numerous compatibility patches, legacy test files, and conditional branching logic that were specific to v0.23.0.
• Refactoring: Simplified version-specific logic in core components and test suites to align with the new v0.24.0 baseline.

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

[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

Suggested PR Title:

[CI][Misc] Drop vLLM v0.23.0 support and upgrade to v0.24.0

Suggested PR Summary:

### What this PR does / why we need it?
This pull request drops support for vLLM v0.23.0 and upgrades the codebase to support vLLM v0.24.0. It removes various legacy compatibility patches (such as GLM-4.7 and MiniMax-M2 tool parsers, and legacy FusedMoE implementations), updates Dockerfiles, and aligns the scheduler and model runner signatures with the v0.24.0 release.

An issue was identified in `vllm_ascend/patch/platform/patch_balance_schedule.py` where calling `max(per_group_hits)` on an empty sequence can cause a `ValueError` at runtime.

### Does this PR introduce _any_ user-facing change?
No. This is an internal dependency upgrade and compatibility alignment.

### How was this patch tested?
Tested via existing E2E and unit tests, with updates to signature and compatibility tests to match v0.24.0.

[gemini-code-assist]

If per_group_hits is empty, calling max(per_group_hits) will raise a ValueError: max() arg is an empty sequence. To prevent potential runtime crashes, use max(per_group_hits, default=0) to safely handle empty sequences.

Suggested change

	num_new_local_computed_tokens = max(per_group_hits)
	num_new_local_computed_tokens = max(per_group_hits, default=0)

[github-actions]

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

[github-actions]

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

[github-actions]

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

[realliujiaxu]

LGTM