vllm-project/vllm
View on GitHub[torch.compile] config hashing refactor follow-ups
Open
#39479 opened on Apr 10, 2026
feature requestgood first issuehelp wanted
Description
🚀 The feature, motivation and pitch
MOTIVATION.
PR #26468 moved vLLM config hashing toward an opt-out model so new compilation-relevant config fields are less likely to be accidentally omitted from torch.compile cache keys.
This issue tracks the follow-ups and to-dos.
TODOs
- Refactor all locations of
compute_hashtocompile_factors.compute_hashisn’t the right name because real computation of the hash is actually done byutils.hash_factors. - before calling
normalize valueinget_compile_factors, it needs to check if .compile_factors exists on the subobject. This allows us to avoid handlingPassConfigspecially as in the case for compilation.py - Uniform use of
normalize_value&hash_factorsacross configs with a compute_hash function. - address this comment: comment here
- Create a shared helper instead of inlining both
_compute_code_hashandcompilation_config_hash_factors - Refactor all locations of
compute_hashtocompile_factors - Follow up on docstrings not being up-to date in the opt-out configs
- typing cleanups (e.g., return {} where configs don’t affect graphs; use Path for traced files; consistent DP hash validation.
always print hashed configs into cache_key_factors.json
CC List.
@ProExpertProg @zou3519 @hmellor
Alternatives
No response
Additional context
No response
Before submitting a new issue...
- Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.