[Bugfix] Fix DeepSeek V3.2 OOM during CG memory profiling

[MatthewBonanni]

Purpose

The cudagraph memory profiler added in #30515 did not account for UniformTypeKVCacheSpecs in init_minimal_kv_cache_for_profiling, so the page_size was being improperly multiplied by the group_size, causing an allocation that was 61x too large. This PR fixes this and takes advantage of the existing num_blocks override mechanism instead of spoofing the available memory, so it should be more robust.

Test Plan

vllm serve deepseek-ai/DeepSeek-V3.2 -tp 8

Test Result

main: OOM during startup
PR: starts up successfully

---

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.

[robertgshaw2-redhat]

do we need a bugfix in 0.17 for this?

[MatthewBonanni]

@robertgshaw2-redhat no, it was introduced by #30515, which isn't in 0.17. Updated the PR description to clarify

[gemini-code-assist]

Code Review

This pull request addresses an out-of-memory issue during CUDA graph memory profiling for DeepSeek V3.2. The fix correctly initializes the minimal KV cache by using the num_gpu_blocks_override mechanism, which is a more robust approach than the previous memory calculation that was incorrect for UniformTypeKVCacheSpecs. The change is sound, but I've suggested an improvement to ensure the configuration is always restored to its original state, even in the case of an exception, by using a try...finally block.

_{Note: Security Review did not run due to the size of the PR.}

[njhill]

Thanks @MatthewBonanni , maybe just add a short comment?