[CI] main2mainv0.24

[zhao-stack]

Summary

Upgrade the release lane to vLLM v0.24.0 while keeping the verified main lane and the Transformers version inherited from PR #11709 unchanged.

PR #11709 has landed on main as squash commit 5083d8844310831258f085ea6dfcac4a2f76ef58. This branch is rebased onto the latest vllm-ascend/main and contains the twelve v0.24-specific commits plus one focused follow-up that removes fixed-tag compatibility from Model Runner V2.

The previous full branch is backed up at zhao-stack:m2m-024-full-backup-20260714 (db5a50f46a9126280250fac31c3803d8e8d50f99).

Scope

This PR handles only the main2main v0.24 tag upgrade.

• The v0.23 compatibility-removal commit dc700d5cfb93900d374b89ba84afcb8de8420445 is not included.
• None of the post-dc700 EPLB, async-scheduling, 310P cleanup, or CPU-test-isolation commits are included.
• The temporary selected-test “continue after failure” changes were dropped.
• The hidden-states synchronization is inherited from merged PR [CI]main2main 0710 #11709 and is not duplicated.
• Deleting general v0.23 compatibility is deferred to a separate PR.
• Model Runner V2 is intentionally supported only on the verified vLLM main commit; fixed release tags use the V1 runner.

Baselines

• vllm-ascend main: 58bed4041347723c0a34ef239e847768c7df0dc8
• merged PR [CI]main2main 0710 #11709 squash: 5083d8844310831258f085ea6dfcac4a2f76ef58
• historical PR [CI]main2main 0710 #11709 head: ccc0a3f1c9c6cc36b5ac38274bebf8e82019be05
• verified vLLM main pin: e5588e49bc2642670116664a7fc4096e27adb179
• Transformers: 5.13.0 (unchanged from PR [CI]main2main 0710 #11709)

The 47-commit PR #11709 prefix and its merged squash commit have the same stable patch-id, so the rebase skips that already-merged prefix and replays only the twelve v0.24 commits.

For the exact vLLM comparison:

• merge base of e558 and v0.24.0: 6c427dd40141870b9076c9a9f128eec3a7ce86bc
• raw range count: 698 / 18
• patch-effective range count: 686 / 6

The prior v0.24 adaptation node ba22152096b2484faa3579624a253d54804d876d is an ancestor of e558, but the formal v0.24.0 tag is a divergent release line; this PR adapts the formal tag rather than treating it as a linear bump.

Tag compatibility changes

All maintained V1/shared tag-main API branches use vllm_version_is; no vLLM-version decision is based on symbol lookup, hasattr, getattr, find_spec, try-import, or signature inspection.

The v0.24-specific changes cover:

• version matching for installations such as 0.24.0+empty;
• DFlash model-mask interfaces;
• KV-cache admission and CPU-offload token-budget arguments;
• HunyuanVL bundled-processor compatibility;
• V1 DeepSeekV2 hidden-size, block-table, and cudagraph interfaces;
• speculative decoding / DSpark availability in maintained V1/shared paths;
• weight-transfer constructors and lifecycle methods;
• DeepSeekV4 parser selection;
• GPT-OSS and DSpark test boundaries that depend on post-tag upstream fixes.

Model Runner V2 boundary

Model Runner V2 is not yet maintained against fixed upstream release tags.

• vllm_ascend/worker/v2/** and vllm_ascend/patch/worker/patch_v2/** now match the verified-main implementation and contain no fixed-tag version branches.
• On vLLM v0.23.0 and v0.24.0, the worker patch registry does not import main-only MRV2 patches.
• If MRV2 is requested on those release tags, the worker falls back to V1.
• MRV2 E2E cases are skipped on the release-tag lane and remain enabled on the verified-main lane.

HunyuanVL audit

The v0.24.0 tag still contains the bundled HunyuanVL processor modules and does not contain vLLM #47872 or #47867. The e558 main pin has the native-processor migration but predates the complete #47867 cleanup boundary. Therefore the downstream compatibility patch remains required while Transformers stays at 5.13.0.

Validation

• remote head: 5a6fe595cd2da4a2641010e1eba1ae59fb27d2d6
• rebase base: 58bed4041347723c0a34ef239e847768c7df0dc8
• exact comparison against current main: 13 commits ahead, 0 behind
• final tree: 45ef2e813cb0394637c1d99beb586f685ed9cf2b
• original twelve rebased commits remain unchanged; 5a6fe595 is the isolated MRV2 scope correction
• final PR scope: 27 files, including 26 Python files
• Ruff check: passed for all 26 changed Python files
• Ruff format check: passed for all 26 changed Python files
• git diff --check: passed
• conflict-marker scan: passed
• all thirteen commits contain matching Signed-off-by trailers
• no .agents files are part of the PR
• fresh E2E run: https://github.com/vllm-project/vllm-ascend/actions/runs/29302425926

A local Python/vLLM/torch runtime is unavailable in this Windows workspace, so pytest and NPU E2E validation are delegated to CI.

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

[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 prepares the repository for the vLLM v0.24.0 release by updating the release tag and pinning dependencies. It introduces extensive version-specific logic to ensure compatibility across the codebase, as the v0.24.0 release line diverges from the previous v0.23.0 target. Additionally, it includes a new compatibility patch for HunyuanVL processors and temporary CI adjustments to facilitate debugging the transition.

Highlights

• vLLM Version Upgrade: Upgraded the verified vLLM release target from v0.23.0 to v0.24.0.
• Dependency Update: Pinned Transformers to version 5.13.0 across the project.
• Compatibility Infrastructure: Introduced version-aware logic to handle API differences between vLLM v0.23.0 and v0.24.0, including a new compatibility layer for HunyuanVL processors.
• CI Workflow: Temporarily adjusted CI to continue after failures to ensure a complete failure set is captured for the new v0.24.0 target.

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.

Ignored Files

• Ignored by pattern: .github/workflows/** (3)
  • .github/workflows/_selected_tests.yaml
  • .github/workflows/pr_test.yaml
  • .github/workflows/scripts/run_selected_tests.sh

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:

[Ops][Misc] Support Transformers 5.13.0 and vLLM v0.24.0 compatibility

Suggested PR Summary:

### What this PR does / why we need it?
This PR introduces compatibility updates to support Transformers 5.13.0 and vLLM v0.24.0 (upgraded from v0.23.0). Key changes include:
- Adding a compatibility patch for the Hunyuan VL processor (`hunyuan_vl_processor_compat.py`) and corresponding unit tests.
- Dynamically handling differences in KV cache configuration parameters (`max_num_batched_tokens` vs `max_in_flight_tokens`) across vLLM versions.
- Adapting the slot mapping kernel, NPU model runner, and input batch preparation to handle API changes between v0.23.0 and newer versions.
- Disabling the DFlash speculator on vLLM 0.23.0 and fixing Triton kernel padding values.

Feedback on the PR:
- **Critical Bug**: In `patch_kv_cache_coordinator.py`, positional argument binding in `get_kv_cache_coordinator` causes the third argument to bind to `max_in_flight_tokens` instead of `max_num_batched_tokens` on vLLM 0.23.0, resulting in an incorrect token budget. A fix is suggested to correctly select the budget.
- **Improvement**: In `hunyuan_vl_processor_compat.py`, an early return should be added to `_register_hunyuan_tokenizer_special_tokens` when the tokenizer is `None` to prevent misleading errors.

### Does this PR introduce _any_ user-facing change?
No, these are internal compatibility and platform patching updates.

### How was this patch tested?
Tested with new unit tests added in `tests/ut/patch/test_hunyuan_vl_processor_compat.py` and existing test suites.

[gemini-code-assist]

In vLLM 0.23.0, get_kv_cache_coordinator is called positionally with max_num_batched_tokens as the third argument. However, in the patched signature, the third argument is max_in_flight_tokens. This causes the passed value to be bound to max_in_flight_tokens while max_num_batched_tokens remains None. Because vllm_version_is("0.23.0") is True, _select_kv_token_budget currently selects max_num_batched_tokens (which is None), ignoring the actual passed value and falling back to max_model_len. This can lead to incorrect block allocation and admission control.

Suggested change

	def _select_kv_token_budget(
	max_model_len: int,
	max_in_flight_tokens: int | None,
	max_num_batched_tokens: int | None,
	) -> int:
	token_budget = max_num_batched_tokens if vllm_version_is("0.23.0") else max_in_flight_tokens
	return token_budget if token_budget is not None else max_model_len
	def _select_kv_token_budget(
	max_model_len: int,
	max_in_flight_tokens: int | None,
	max_num_batched_tokens: int | None,
	) -> int:
	if vllm_version_is("0.23.0"):
	token_budget = max_num_batched_tokens if max_num_batched_tokens is not None else max_in_flight_tokens
	else:
	token_budget = max_in_flight_tokens if max_in_flight_tokens is not None else max_num_batched_tokens
	return token_budget if token_budget is not None else max_model_len

[gemini-code-assist]

If tokenizer is None (which can happen if the processor is initialized without a tokenizer for image-only tasks or during certain serialization steps), _register_hunyuan_tokenizer_special_tokens will fail with a misleading ValueError stating that the special-token schema does not match the model vocabulary. Adding an early return when tokenizer is None ensures robust, defensive execution.

def _register_hunyuan_tokenizer_special_tokens(tokenizer: Any) -> None:
    """Restore the named-token schema required by Transformers 5.13."""
    if tokenizer is None:
        return
    missing_tokens = {

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