feat: upgrade vllm from 0.29.0 to 0.30.0 for CUDA and ROCm backends

[axsapronov]

Upgrade vLLM from 0.29.0 to 0.30.0 across the CUDA 13.0, CUDA 12.9, and ROCm 7.2 backends, and pull in the matching torch 2.14.0 (CUDA 13.0), vllm-omni v0.30.0rc1, lmcache 0.5.5 (vLLM and SGLang), and fastokens 0.3.2.

Follows the same pattern as #251 and #261.

Why these move together

• vllm / omni / torch are one resolved dependency set per image. omni v0.30.0rc1 is rebased onto vLLM 0.30.0, so it cannot pair with a 0.29.0 base; the 0.30.0 base's prebuilt wheels (vllm, flashinfer, fa3-fwd) are compiled against torch 2.13.0, and taking torch 2.14.0 on top of them is deliberate — it rides torch's stable ABI within the major version, enforced by the lmcache ABI check in the build and the CI smoke tests.
• lmcache moves in lockstep across the CUDA/ROCm vLLM and both SGLang images: the MP wire protocol has no version handshake, so 0.5.5 on one side and 0.5.4 on the other is an unsupported pairing. 0.5.5 also generates its gRPC stubs at build time, hence the pinned grpcio/grpcio-tools 1.84.0 in every lmcache build stage.

What moves

Backend	Changes
CUDA 13.0	vllm 0.30.0, CUDA 13.0.3, torch 2.13.0 → 2.14.0+cu130 (new self-conditional "Upgrade Torch" step), torchvision 0.29.0, omni v0.30.0rc1, lmcache 0.5.5, fastokens 0.3.2, lmcache C++ built with C++20 (see below)
CUDA 12.9	vllm 0.30.0 (the v0.30.0-cu129 base exists); stays on the base's torch 2.13.0 — 2.14.0 is published for cu130 only
ROCm 7.2	vllm 0.30.0, omni v0.30.0rc1; keeps the base's torch 2.12.x (the 0.30.0 ROCm base is built from the ROCm pytorch release/2.12 branch)
SGLang (CUDA + ROCm)	lmcache 0.5.5 lockstep

CANN and the SGLang engine version are untouched. README: 0.30.0 added to the CUDA 13.0/12.9 and ROCm 7.2 supported version tables.

Build fix: lmcache C++20 on CUDA 13.0

torch 2.14's headers require a C++20 compiler (#error C++20 or later compatible compiler is required to use PyTorch in torch/all.h), but lmcache 0.5.5 hardcodes -std=c++17 for its g++ sources (setup_extensions/common_cpp.py, setup_extensions/build_profiles/cuda.py). Under the torch 2.14.0 base, the pybind.cpp translation unit fails to compile against the torch headers. The CUDA 13.0 Dockerfile now rewrites that flag to -std=c++20 before building lmcache; nvcc already defaults to C++20 under CUDA 13, so only the g++ path needed the bump. The cu129 base (torch 2.13.0) and the SGLang/ROCm bases (torch 2.13.0 / 2.12.x) are unaffected by C++20 and keep building as before.

Upstream references

• vLLM v0.30.0 — https://github.com/vllm-project/vllm/releases/tag/v0.30.0 (762 commits: new models incl. DeepSeek-V4.1-Flash and GLM-5.3-Flash, Fast Start weight cache, HiSparse, Model Runner V2 improvements, ROCm support for DeepSeek-V4-Flash-Vision-Exp)
• vllm-omni v0.30.0rc1, rebased onto vLLM 0.30.0 — https://github.com/vllm-project/vllm-omni/releases/tag/v0.30.0rc1
• lmcache v0.5.5 — https://github.com/lmcache/lmcache/releases/tag/v0.5.5 (isolated IPC now the default for MP mode, durable coordinator, CacheBlend V3, vLLM multi-connector fix #4781, SGLang MLA support in MP mode, CUDA 13.4 compatibility)
• PyTorch 2.14.0 — https://github.com/pytorch/pytorch/releases/tag/v2.14.0
• fasttokens 0.3.2 — https://pypi.org/project/fasttokens/0.3.2/

Patch changes

None. The cuda and rocm patch trees are unchanged — v0.30.0 keeps the refactored get_open_port() and the upstream shm-broadcast port fix, so 001_wrong_dp_ray.patch applies as before. runner.py.json and test fixtures are left for the GHA pack workflow's merge-runner job to regenerate.

[gemini-code-assist]

Code Review

This pull request updates vLLM to v0.30.0, SGLang's LMCache to v0.5.5, and upgrades associated dependencies like PyTorch, torchvision, and fastokens across CUDA and ROCm Dockerfiles and the build matrix. To support LMCache's build-time gRPC stub generation, the installation of grpcio and grpcio-tools was added. However, the reviewer identified a critical issue where the specified version 1.78.0 for these gRPC packages does not exist on PyPI, which will cause the image builds to fail. It is recommended to correct this version to a valid release, such as 1.68.0.