[compile] Add enable_prompt_embeds to compile hash.

[zhxchen17]

Summary:

Fixing issue #27283

enable_prompt_embeds will make input_ids argument to be None instead of tensor type, which will invalidate the compile cache at vllm level. Previously this wasn't an issue because inductor has its own caching validation that serves as the last line of defence.

Now that we enabled AOT compilation, the dynamo bytecode is also cached and therefore we need to guard it against input type changes (e.g. Tensor -> None here)

Therefore 2 ways to do this:

1. Use dynamo guards, so this is guarded at torch.compile level.
2. Add enable_prompt_embeds to compute_hash, so this is guarded at vllm level.

In the short term, 2. seems to be the better approach because vllm already throws away all the guards from dynamo and enabling the guards is a non trivial change to the existing code.

Test Plan:
(with torch 2.10.dev)
pytest tests/basic_correctness/test_basic_correctness.py

Reviewers:

Subscribers:

Tasks:

Tags:

Purpose

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 correctly addresses a potential cache invalidation issue by including enable_prompt_embeds in the compilation hash. This ensures that changes to this flag, which can alter the input types to the model, will properly trigger a re-compilation. I've added one suggestion to also include runner_type and convert_type in the hash, as they also seem to have a significant impact on the computation graph and could lead to similar caching problems if not included. Overall, this is a good fix.

[gemini-code-assist]

Good catch adding enable_prompt_embeds to the compilation hash.

While reviewing this, I noticed that runner_type and convert_type also seem to affect the computation graph but are not currently included in the hash. These fields can determine which model implementation is used (e.g., for generation vs. pooling) or whether a model adapter is applied, both of which are significant changes to the graph.

To prevent potential cache collisions when switching between runners or converters for the same base model, it would be safer to include them in the hash factors. What do you think about adding them here?

Suggested change

	factors.append(self.enable_prompt_embeds)
	factors.append(self.enable_prompt_embeds)
	factors.append(self.runner_type)
	factors.append(self.convert_type)