[CI/Build][Router] Enable lmcache 0.5.4 for the kvaware router stack

[tyler2cr]

Enables the current lmcache release (0.5.4) across the kvaware router stack, as a standalone diff (3 files, +18/−5). Independent of the chat-tokenization fix in #1045 — mergeable in either order.

What it changes

pin	before	after
[lmcache] extra: lmcache	0.3.11	0.5.4 (current stable)
[lmcache] / [test] extras: vllm	0.13.0	0.22.0
docker/Dockerfile.kvaware base	lmcache/vllm-openai:2025-05-27-v1	lmcache/vllm-openai:v0.5.4
tutorial-17 engine image	v0.3.9post2	v0.5.4

Each pin site now carries a comment documenting why the versions must move in lockstep — two silent failure modes observed on real hardware while validating #1045:

1. lmcache's controller↔worker ZMQ messages are not a stable protocol across versions: a 0.3.x controller rejects a 0.4+/0.5+ worker's RegisterMsg as "unknown message type," and the worker never registers — every KV lookup misses, routing degrades to session/QPS with no error.
2. kv-aware chunk hashes are rooted in vLLM's NONE_HASH — a router whose vllm differs from the engines' derives a different hash chain, and again every lookup silently misses.

Verification

• Router's full lmcache API surface probed against 0.5.4: LMCacheControllerManager constructor (unchanged signature + two new optional params), handle_orchestration_message, start_all, LookupMsg, QueryInstMsg — all construct and behave.
• Full router test suite: 220/220 at this branch.
• The 0.4.5 pairing of the same wiring was validated end-to-end on hardware (2×H200 + 1×H100 runs — see [Router][Bugfix] KV-aware routing: tokenize chat-completions bodies through the chat template #1045's validation section).

Engine-side pairing caveat (scope of this PR's verification)

This PR's 0.5.4 verification covers the router path (controller manager, orchestration messages, lookup/query types — probed directly against 0.5.4). The engine-side LMCacheConnectorV1 integration is a separate axis: lmcache 0.5.x's vllm adapter tracks recent/nightly vLLM APIs, and a downstream deployment reports that pip lmcache 0.5.4 does not communicate correctly through the v1 connector against a vLLM v0.22-class engine build — while pip lmcache 0.4.5 + vLLM v0.22.0 through the same connector is validated end-to-end on hardware. Practical guidance:

• The bundled lmcache/vllm-openai:v0.5.4 image (what this PR pins for the tutorial and the kvaware router image) is internally matched — lmcache built against the vLLM it ships with.
• Bring-your-own-vLLM engine builds should pair pip lmcache to their vLLM generation (0.4.5 for v0.22-class is the validated pairing) rather than assuming the newest lmcache works — and the router's lmcache pin must then follow the engines (the lockstep rule above).

One heads-up for 0.5.4 adopters

lmcache 0.5.4 still defaults lmcache_worker_heartbeat_time: None — workers never send heartbeats by default, while the controller reaps silent workers after ~30s, emptying the KV index shortly after startup ("misses that shouldn't be occurring"). The helm chart already maps lmcacheConfig.workerHeartbeatTime → LMCACHE_LMCACHE_WORKER_HEARTBEAT_TIME and tutorial-17's values set it to "30", so chart-driven deployments are safe — but any hand-rolled engine config must set it explicitly.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates the versions of lmcache (to 0.5.4) and vllm (to 0.22.0) in the Dockerfile, pyproject.toml, and tutorial configuration files. It also adds detailed comments explaining the importance of keeping these versions synchronized to prevent ZMQ protocol mismatches and silent KV lookup failures. There are no review comments, and I have no feedback to provide.

[tyler2cr]

Body updated with an engine-side pairing caveat: this PR's 0.5.4 verification is router-path; a downstream deployment reports pip lmcache 0.5.4 failing across LMCacheConnectorV1 against a vLLM v0.22-class engine (0.4.5 + v0.22.0 through the same connector is hardware-validated). The bundled v0.5.4 image is internally matched; bring-your-own-vLLM builds should pair pip lmcache to their vLLM generation, with the router pin following the engines.