From b38bce8cb7d62a78543b4b573b4cd74766a305f9 Mon Sep 17 00:00:00 2001 From: velaraptor-runpod Date: Wed, 23 Sep 2026 17:47:35 +0000 Subject: [PATCH] Bump vLLM to v0.30.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit v0.30.0 (2026-09-22) is the first vLLM release that requires huggingface_hub >= 1.31.0 (vllm#56460), which includes the repo-aware ResolvedRevision pinning shipped in huggingface_hub 1.30.0 (huggingface/huggingface_hub#4767): a pin resolved for one repo is no longer applied to another repo, closing the 'Revision Not Found' class seen on v2.27.0 (vLLM v0.29.0, hf_hub >= 1.28.0). Warehouse re-check of the Sep 11-17 window puts that class at ~14% of failed v2.27.0 first-request endpoints (the v2.27.1 release notes' 88%/58% figures appear transposed: measured shares were ~86% CUDA OOM / ~14% revision). vLLM-side vllm#56092 (explicit resolve-once-per-repo, incl. the model_weights/runai path) is still open upstream; with hf_hub >= 1.30 the library itself re-resolves a pin handed to a foreign repo, which covers the leak this worker hit. v0.29.x is skipped entirely. The dominant v0.29 regression is memory, and it is NOT root-fixed upstream: the KV pool is still budgeted as requested - non-KV - cudagraph_memory_estimate, and the proper fix (vllm#51590, full capture footprint for KV budgeting) is still open. Marginal models that OOM'd at init on v0.29 can OOM on v0.30 too; the worker-side knobs (lower MAX_NUM_BATCHED_TOKENS / GPU_MEMORY_UTILIZATION, KV_CACHE_DTYPE=auto, ENFORCE_EAGER) remain the mitigation, and startup_errors.py already points at them. Watch the first-request failure rate after this ships against the measured cohorts: v2.27.0 = 28.8% (Sep 11-17), v2.26.0 baseline = 11.0% (Sep 4-10) — source queries in /workspace/dev/vllm_227_verify/. vllm-flag-drift CI was run locally against a real vllm 0.30.0+cpu install (parser dump + check): exit 0, no drift — the v0.30.0 breaking changes (scale-out opt-in flag, removed VLLM_PREFIX_CACHE_RETENTION_INTERVAL / VLLM_MM_HASHER_ALGORITHM env vars) touch no flag this worker can emit. Co-Authored-By: Claude Fable 5 --- .runpod/README.md | 2 +- Dockerfile | 2 +- README.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.runpod/README.md b/.runpod/README.md index 460a7e51..dceb3275 100644 --- a/.runpod/README.md +++ b/.runpod/README.md @@ -6,7 +6,7 @@ Run LLMs using [vLLM](https://docs.vllm.ai) with an OpenAI-compatible API [![RunPod](https://api.runpod.io/badge/runpod-workers/worker-vllm)](https://www.runpod.io/console/hub/runpod-workers/worker-vllm) -Current vLLM version: [0.28.0](https://github.com/vllm-project/vllm/releases/tag/v0.28.0) +Current vLLM version: [0.30.0](https://github.com/vllm-project/vllm/releases/tag/v0.30.0) --- diff --git a/Dockerfile b/Dockerfile index a7b916a1..e07acc9a 100644 --- a/Dockerfile +++ b/Dockerfile @@ -1,7 +1,7 @@ # Worker image = official vLLM OpenAI server image + RunPod serverless wrapper. # vLLM upgrades are now a single build ARG: # docker buildx build --build-arg VLLM_VERSION=v0.23.0 ... -ARG VLLM_VERSION=v0.28.0 +ARG VLLM_VERSION=v0.30.0 FROM vllm/vllm-openai:${VLLM_VERSION} # Re-declare so the stage can reference it in RUN steps below. ARG VLLM_VERSION diff --git a/README.md b/README.md index 50dc0800..d10c7e66 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ Deploy OpenAI-Compatible Blazing-Fast LLM Endpoints powered by the [vLLM](https: ![vLLM worker banner](https://image.runpod.ai/preview/vllm/vllm-banner.png) -Current vLLM version: [0.28.0](https://github.com/vllm-project/vllm/releases/tag/v0.28.0) +Current vLLM version: [0.30.0](https://github.com/vllm-project/vllm/releases/tag/v0.30.0) > Want a **load balancing** endpoint (direct HTTP, no job queue)? You don't need this worker — deploy the official vLLM image as-is. See [Option 3: Load Balancing with the vLLM Image](#option-3-load-balancing-with-the-vllm-image).