[Core] Use standalone autograd_cache_key for compilation dedup optimization

[frgossen]

Purpose

Use the new torch.compile standalone_compile.autograd_cache_key API
(torch >= 2.12) to compute cache keys up front, avoiding the legacy
monkey-patching of autograd_cache.autograd_cache_key during compilation.
This enables deduplication without compiling duplicate subgraphs.

A new VLLM_DEBUG_COMPILE_CACHE_KEY env var cross-checks the standalone
API against the legacy path. This uses a dedicated env var rather than
a log-level guard because the check changes the compilation codepath
(forces legacy compile + extra key computation), not just verbosity.
This follows the established VLLM_DEBUG_* convention (VLLM_DEBUG_WORKSPACE,
VLLM_DEBUG_MFU_METRICS, etc.).

Test Plan

• Run meta-llama/Meta-Llama-3-70B-Instruct with TP=4. We expect no
  functional changes.

Test Result

Cold-compile benchmark (Llama 3 70B, TP=4, 16 runs each):
Before (1e688fa): mean 34.2s ± 0.8s, median 34.3s
After (eecf384): mean 34.4s ± 0.6s, median 34.7s
No significant difference (within noise)

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

Just a reminder: PRs would not trigger full CI run by default.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

🚀

[gemini-code-assist]

Code Review

This pull request refactors the compilation deduplication logic to use the new autograd_cache_key API in torch >= 2.11, which is a great improvement. The code is well-structured, separating the new path and the legacy monkey-patching path. However, I've found a critical issue where the new caching logic assumes an Inductor backend, which could cause failures when other backends like 'eager' are used. My review includes a suggestion to make the caching logic conditional on the backend type.

[mergify]

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

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

[frgossen]

I tested this locally with meta-llama/Meta-Llama-3-70B-Instruct. I don't think the CI will cover this because it is hidden behind a debug var and it will only kick in with a newer Pytorch version. I will run the tests locally before landing this.

	has_standalone_key_api =False	has_standalone_key_api = is_torch_equal_or_newer("2.12.0.dev")
VLLM_DEBUG_COMPILE_CACHE_KEY=0	PASS	PASS
VLLM_DEBUG_COMPILE_CACHE_KEY=1	PASS	PASS

[mergify]

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

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

[frgossen]

duplicate creation