[XPU] decrease IGC_ForceOCLSIMDWidth for speculative decoding triton-xpu kernel compilation

[yma11]

Purpose

decrease triton kernel compilation scratch space for speculative decoding, work around for error:

L0 build module failed. Log:
warning: [RetryManager] Start recompilation of the kernel
in kernel: 'sample_recovered_tokens_kernel'

error: total scratch space exceeds HW supported limit for kernel sample_recovered_tokens_kernel: 1164736 bytes (max permitted PTSS 262144 bytes)
error: backend compiler failed build.

Error during Intel loadBinary: ZE_RESULT_ERROR_MODULE_BUILD_FAILURE

Test Plan

Test Result

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[gemini-code-assist]

Code Review

This pull request introduces a workaround for a Triton kernel compilation error on XPU devices during speculative decoding by setting the IGC_ForceOCLSIMDWidth environment variable to 16 in the XPU Dockerfile. While this resolves the compilation failure, setting this globally may have unintended performance consequences. My review includes a suggestion for a more targeted approach to apply this workaround only when necessary.

[gemini-code-assist]

Setting IGC_ForceOCLSIMDWidth as a global environment variable in the Docker image is a broad change that will affect all Triton kernels compiled at runtime, not just those for speculative decoding. This could lead to performance degradation for workloads that do not use speculative decoding, or for other kernels that could benefit from a wider SIMD width.

A more targeted approach would be to set this environment variable dynamically within the vLLM Python code, only when speculative decoding is enabled on an XPU device. A suitable location for this logic could be within vllm.platforms.xpu.XPUPlatform.check_and_update_config, checking if vllm_config.speculative_config is present.

This would scope the workaround to only when it's needed, avoiding potential performance impacts on other use cases. While I cannot suggest code for an un-modified file, please consider this alternative for a more robust solution.

[rogerxfeng8]

valid comment

[yma11]

yes. updated.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @yma11.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[mergify]

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

uv pip install pre-commit
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 or markdownlint failing?

mypy and markdownlint are run differently in CI. If the failure is related to either of these checks, please use the following commands to run them locally:

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

[mergify]

Documentation preview: https://vllm--30538.org.readthedocs.build/en/30538/

[jikunshang]

LGTM, thanks for fixing