Repository navigation
Bump vLLM to v0.30.0 - #345
Merged
Merged
Conversation
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 <noreply@anthropic.com>
colin99d
approved these changes
Sep 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
v2.27.1 rolled the engine back to v0.28.0 over two v0.29.0 regressions. The blockers are now resolved upstream, and the warehouse data has been re-checked:
1. Cross-repo revision-pin leak ("Revision Not Found") — fixed in v0.30.0. v0.29.0 floors
huggingface_hub >= 1.28.0, whoseResolvedRevisionwas not repo-scoped: a hash resolved for the model repo gets applied to e.g. the tokenizer/weights repo → guaranteed 404. The fix ishuggingface_hub1.30.0 (huggingface/huggingface_hub#4767: "ResolvedRevision now pins the repo it was resolved for"), and v0.30.0 (released 2026-09-22) requireshuggingface_hub >= 1.31.0via #56460. The vLLM-side #56092 (explicit resolve-once-per-repo incl. themodel_weights/runai path) is approved but still open; with hf_hub ≥ 1.30 the library itself re-resolves a pin handed to a foreign repo, which covers the leak class this worker hit. v0.29.x is skipped entirely.2. Memory regression — NOT root-fixed in v0.30.0, called out deliberately. The KV pool is still budgeted as
requested − non-KV − cudagraph_memory_estimate, and the proper fix (vllm#51590) is still open. Since the rollback notes said "re-bump once a release carries vllm#56092 with hf_hub ≥ 1.30": v0.30.0 satisfies the hf_hub half via the dependency floor, not via #56092.What
One-line engine pin
v0.28.0 → v0.30.0plus the README version strings. No wrapper changes.Tests
pytest tests/— 79 passed.vllm-flag-driftcheck run locally against a real vllm 0.30.0+cpu install (parser dump +check --snapshot): exit 0, no drift — every flag the worker can emit exists in v0.30.0's parser with the same behavior, and noREMOVED_FLAGSentry resurrected. v0.30.0 breaking changes (scale-out opt-in flag, removedVLLM_PREFIX_CACHE_RETENTION_INTERVAL/VLLM_MM_HASHER_ALGORITHMenv vars) touch no flag this worker emits. Resolvedhuggingface_hubin the install: 1.32.0.serverless-model-testsshould see this before it ships.