[HMA] [KVEvent] Enable GPU-side KV events for HMA

[hickeyma]

Purpose

Evicted group information is important for routing Hybrid Model Architecture (HMA) aware prefix-cache in distributed serving frameworks as vLLM can evict Sliding Window Attention (SWA) blocks while retaining the full-attention blocks. Without this information it would assume complete eviction and miss valid routing paths.

This PR enables KV events for HMA on GPU-side.

Test Plan

Run bench marking with KV events enabled:

VLLM_LOG_STATS_INTERVAL=0.01 vllm bench throughput --model openai/gpt-oss-20b --num-prompts 1000 --kv-events-config '{"enable_kv_cache_events": "True", "publisher": "zmq", "topic": "kv-events"}' OR

VLLM_LOG_STATS_INTERVAL=0.01 vllm bench throughput --model Qwen/Qwen3-14B --kv-offloading-size 10 --disable-hybrid-kv-cache-manager --num-prompts 1000 --kv-events-config '{"enable_kv_cache_events": "True", "publisher": "zmq", "topic": "kv-events"}'

Use the updated example client to receive the events:
https://github.com/hickeyma/vllm/blob/9ff97922c104117e1577cf9554902a73d2658391/examples/online_serving/kv_events_subscriber.py

Test Result

Receive stored and removed events in the client with the new group fields.

---

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 introduces an evicted_groups field to the BlockRemoved KV cache event to support Hybrid Model Architecture (HMA) aware prefix-cache routing. The implementation correctly populates this field for GPU-side block evictions. However, for blocks evicted via offloading managers (ARCOffloadingManager and LRUOffloadingManager), the group information is not populated, which significantly limits the feature's effectiveness in scenarios involving KV cache offloading. I've added high-severity comments to highlight this functional gap.

[mergify]

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

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

[hickeyma]

Moving to draft for now as need to update this PR further.

[mergify]

Documentation preview: https://vllm--37688.org.readthedocs.build/en/37688/

[hickeyma]

This doesn't look like an error caused by the PR in https://buildkite.com/vllm/ci/builds/59637/steps/canvas?sid=019d5333-4316-40e3-85e8-ff134f99245d but more like an issue on the system:

[...]
[2026-04-03T12:13:55Z] [rank1]:   File "/usr/local/lib/python3.12/dist-packages/vllm/v1/core/kv_cache_utils.py", line 644, in _check_enough_kv_cache_memory
[2026-04-03T12:13:55Z] [rank1]:     raise ValueError(
[2026-04-03T12:13:55Z] [rank1]: ValueError: To serve at least one request with the models's max seq len (4096), (0.5 GiB KV cache is needed, which is larger than the available KV cache memory (0.48 GiB). Based on the available memory, the estimated maximum model length is 3888. Try increasing `gpu_memory_utilization` or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.