Avoid bytecode hook and simplify TorchCompileWrapperWithCustomDipatch

[laithsakka]

Two main changes:

1. Add an option to not use the bytecode hook! torch2.8 have a way to drop guard without the hack.
   We will switch totally to not use in a different PR after internal validation of perf post landing this.
   Since @zou3519 have concerns about the perf. which i highly doubt that there will be issues.

2. TorchCompileWrapperWithCustomDipatch has complexities that are not used in the code base.
   the current usage is to by pass guard evaluation so I am just introducing a much simpler TorchCompileWithNoGuardsWrapper.

Next PR I will add a debug mode option to keep DS gaurds and fail if get violated.

performance:

How does this effect run-time?
I ran the following benchmarks:

vllm bench latency
--model Qwen/Qwen2-1.5B-Instruct
--input-len 128
--output-len 256
--num-iters 50
--dtype float16

after:

10% percentile latency: 0.9403901444951771 seconds
25% percentile latency: 0.9434001832487411 seconds
50% percentile latency: 0.9502700129960431 seconds
75% percentile latency: 0.9560497467537061 seconds
90% percentile latency: 0.9588484280975536 seconds
99% percentile latency: 0.9626266451006813 seconds

before:

10% percentile latency: 0.9399352639040444 seconds
25% percentile latency: 0.9432627985042927 seconds
50% percentile latency: 0.9482277854986023 seconds
75% percentile latency: 0.9578490345011232 seconds
90% percentile latency: 0.9600405636985669 seconds
99% percentile latency: 0.9649963746999856 seconds

vllm bench throughput --model Qwen/Qwen2-1.5B-Instruct --input-len 512 --output-len 128 --num-prompts 1000

after

Throughput: 130.14 requests/s, 83113.04 total tokens/s, 16658.08 output tokens/s
Total num prompt tokens:  510637
Total num output tokens:  128000

before

Throughput: 129.54 requests/s, 82726.85 total tokens/s, 16580.68 output tokens/s
Total num prompt tokens:  510637
Total num output tokens:  128000

[gemini-code-assist]

Code Review

This pull request refactors the torch.compile wrapper to simplify its implementation. It removes the complex bytecode hooking mechanism in favor of the guard_filter_fn option available in newer PyTorch versions to drop guards. The new TorchCompileGuardsStripWrapper is much cleaner. The changes also include updating the support_torch_compile decorator and related tests to use the new wrapper. The overall change improves code clarity and maintainability. I've found one critical issue in the test suite that needs to be addressed.

[mergify]

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

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

[ProExpertProg]

@bigPYJ1151 is planning to fix the CPU torch issue in vLLM so once that's done, we can upgrade to torch==2.8 everywhere and merge this PR

[ProExpertProg]

Looks good, can you reformat?

[laithsakka]

rebase again

[laithsakka]

@ProExpertProg can you help me land it before another rebase is needed :)

[hmellor]

FYI the docs build in this PR was failing so now it's failing on main too.

We're working on a fix.

[ProExpertProg]

Sorry about that, I looked at the error message and it looked unrelated, I should have checked nightly.

[DarkLight1337]

Fixed by #28772

[hmellor]

It was an issue with mkdocstrings which I've reported to them.

For future reference, the docs are built for every commit on main. So if the docs are green on main, it's a real failure.