fix(xpu): Re-compute compile ranges after platform-specific config updates

[Liangyx2]

Summary

Fix compile range computation order to respect platform-specific scheduler config updates.
This ensures torch.compile warmup uses sizes that are valid for the actual max_num_batched_tokens,
particularly on XPU backend where MLA models have constraints that reduce this value.

Issue

When using torch.compile mode on XPU backend with MLA-enabled models:

1. Initial _set_compile_ranges() computes endpoints based on default max_num_batched_tokens (e.g., 8192)
2. check_and_update_config() for XPU detects MLA and lowers max_num_batched_tokens (e.g., to 4096)
3. During warmup, compile attempts to execute with size 8192 but max_num_tokens is now 4096
4. Assertion fails in _dummy_run(): assert num_tokens <= self.max_num_tokens

This is a configuration order bug - compile ranges should be finalized AFTER platform
config updates, not before.

Root Cause

In VllmConfig.__post_init__():

• Line 989: _set_compile_ranges() called (uses original max_num_batched_tokens)
• Line 1023: check_and_update_config() called (XPU may lower max_num_batched_tokens)
• Compile ranges never updated to reflect the new limit

Fix

Move the second _set_compile_ranges() call to execute immediately after
check_and_update_config() to ensure compile ranges reflect all platform-specific
scheduler config updates.

Testing

• Tested with Pinaster/GLM-5_4layer model (MLA enabled) on XPU
• Compile mode now successfully initializes without AssertionError

Changes

• vllm/config/vllm.py: Re-invoke _set_compile_ranges() after check_and_update_config()

Notes

This is a root-cause fix addressing the configuration order issue rather than
working around it in the warmup phase. It applies universally and prevents similar
issues on other platforms with custom scheduler config logic.

[gemini-code-assist]

Code Review

This pull request correctly addresses an AssertionError during model compilation warmup by filtering out warmup sizes that exceed the model runner's token capacity. The change ensures that _dummy_run is only called with valid sizes, preventing the crash. My feedback includes a suggestion to optimize the code by partitioning the warmup sizes in a single pass, which improves efficiency and readability.

[jikunshang]

what's your invalid warmup sizes and max_num_tokens? I think this should never happen.

[Liangyx2]

The XPU compile warmup runs one or more forward passes using a set of “preset/enumerated” token counts to trigger graph compilation; however, under certain configurations, these token counts may exceed the actual token capacity allowed by the current ModelRunner, making them “invalid warmup sizes.”

Skipping invalid compile warmup sizes [8192] because they exceed max_num_tokens=4096.

[jikunshang]

The XPU compile warmup runs one or more forward passes using a set of “preset/enumerated” token counts to trigger graph compilation; however, under certain configurations, these token counts may exceed the actual token capacity allowed by the current ModelRunner, making them “invalid warmup sizes.”

Skipping invalid compile warmup sizes [8192] because they exceed max_num_tokens=4096.

does cuda have same behavior? if not, there may be some xpu config setting error. we should fix that instead.

[mergify]

Hi @Liangyx2, the pre-commit checks have failed. Please run:

uv pip install pre-commit>=4.5.1
pre-commit install
pre-commit run --all-files

Then, commit the changes and push to your branch.

For future commits, pre-commit will run automatically on changed files before each commit.

Tip

Is mypy failing?

mypy is run differently in CI. If the failure is related to this check, please use the following command to run it locally:

# For mypy (substitute "3.10" with the failing version if needed)
pre-commit run --hook-stage manual mypy-3.10

[jikunshang]

actually I am thinking we should remove this https://github.com/vllm-project/vllm/blob/main/vllm/platforms/xpu.py#L212-L221

[jikunshang]

and I plan to land this for MLA #37143 recently.

[ProExpertProg]

Looks good, please remove the old call though

[mergify]

Hi @Liangyx2, the pre-commit checks have failed. Please run:

uv pip install pre-commit>=4.5.1
pre-commit install
pre-commit run --all-files

Then, commit the changes and push to your branch.

For future commits, pre-commit will run automatically on changed files before each commit.

Tip

Is mypy failing?

mypy is run differently in CI. If the failure is related to this check, please use the following command to run it locally:

# For mypy (substitute "3.10" with the failing version if needed)
pre-commit run --hook-stage manual mypy-3.10

[yewentao256]

LGTM, thanks for the work! Please fix the pre-commit issue so that we can land this