vLLM v0.33.0 and llama.cpp b12033: Tag, Release and Image Do Not Arrive Together

vLLM set the tag v0.33.0 on 1 November at 09:21 UTC. The Docker image followed on 2 November at 03:06 UTC, and the release notes at 10:10 UTC, 25 hours after the tag. llama.cpp shows a different pattern over the same days: build b12033 exists only as a git tag, while its predecessor b12032 has a full release with download files. All times are UTC and come from the GitHub API and the Docker Hub API, measured on 5 November 2026.

In brief: For inference software, a release channel consists of three separate artifacts: the git tag that fixes the source state, the GitHub release with change notes and files, and the container image in a registry. Each appears at its own time and any of them can be missing. An upgrade needs all three, plus a statement from the maintainer on how long the version is supported.

Correction to the first version of 2 November. It said v0.33.0 had no release notes. That was true on the morning of 2 November and has been out of date since 10:10 UTC. Two further statements are replaced because they could not be backed up: a support window of three minor branches for vLLM (not found in the documentation) and the claim that llama.cpp has no official images (the project's Docker doc lists them).

vLLM v0.33.0: three artifacts, three points in time

Unit: timestamps in UTC. Measurement date 5 November 2026, from the public GitHub and Docker Hub APIs, queried from an office PC. The times are vendor data, not our own measurement of the software.

The tag v0.33.0 and the release object belong to the same commit but carry different names: the release is called "v0.33.0" and hangs on the tag v0.33.0rc3. Opening releases/tag/v0.33.0 still lands on the notes. The project's release-process doc describes it differently: RC tags trigger the builds, and the final tag does not trigger a build and is "used for Release notes and assets". The observable fact is that the notes hang on the rc3 tag; the project gives no explanation.

For the cadence: the doc states the goal "a regular release every 2 weeks". v0.26.0 was published on 27 July 2026 and v0.32.0 on 18 October, six minor steps in 83 days, 13.8 days on average. v0.33.0 followed on 2 November, 15 days after v0.32.0. The basis is the publication dates of the release objects (GitHub API, 5 November 2026).

We did not find a statement in the vLLM docs on how long a minor version is maintained. The deprecation policy ties deprecations to minor versions, and the release doc says backward compatibility is guaranteed only for "a limited number of minor releases", without a number. With a two-week rhythm, the practical question is how long you want to run a version without fixes.

llama.cpp: builds without a release are the norm

Build b12033 goes back to a commit of 1 November, 17:23 UTC. Its predecessor b12032 has a release, published at 09:00 UTC, with 38 files: binaries for CUDA 12.8 and 13.4, Vulkan, ROCm 10.0, SYCL, OpenVINO and others, plus a link to attestations. b12034 followed on 2 November at 08:02 UTC, again with a release.

That is not a mishap at llama.cpp. Counted in the release list on 5 November 2026, build numbers b12066 to b12125 (60 numbers, 3 to 5 November): 39 have a release, 21 do not. In those good 45 hours the project produced about 31 builds a day. Anyone who reads only the release page misses part of the builds.

The container images are a channel of their own. The llama.cpp Docker doc lists images on ghcr.io/ggml-org/llama.cpp in the variants full, light and server, plus CUDA 12 and 13, ROCm, Vulkan, SYCL and OpenVINO. There is no support commitment for individual builds: versions move on daily, and the project names no long-term line.

What this means for our operation

We have run vLLM 0.32.0 since 18 October on the inference host with four RTX 5090 cards, as the hybrid image vllm-flashnext-hybrid:v032-nvfp4port (the vLLM 0.32.0 image plus our own patch for NVFP4 KV cache and MTP; state of 18 October, details in the post on 0.32 with MTP and NVFP4). Every new minor version therefore means: check the patch, run the replay test. This post covers only the publication path. What is in 0.33.0 and why the CUDA 12.9 images are gone is covered in vLLM 0.33.0 drops CUDA 12.9.

For llama.cpp built from source, our state is b10684 plus our own patches (our own measurement, source tree on the inference host, end of August). The realtime endpoint /v1/realtime arrived with pull request #31269, merged on 28 October; builds from b11960 carry it according to our LFM3-Audio post. That is a good 1,200 builds past our state. The gap is a finding: a pinned tree misses features that the daily build has long had.

Three rules we draw from this:

1. Before an upgrade, check which of the three artifacts exists. For vLLM v0.33.0 the image came seven hours before the notes.
2. For llama.cpp, pin the source state and write down the build number instead of waiting for the release page.
3. Set the update rhythm yourself, because neither project commits to a support period. How we plan that for customers is on the page running language models in-house; more posts of this kind are collected under the topic AI in production.

Open points

We did not check whether the notes were edited afterwards: the 37,794 characters are the state of 5 November. The source-tree state b10684 comes from our measurement at the end of August and was not read again for this update.

Further sources

• vLLM: release v0.33.0 - GitHub release with the notes, published on 2 November 2026
• vLLM: release process - cadence goal and role of the tags
• vLLM image tags on Docker Hub - tag v0.33.0 of 2 November 2026
• llama.cpp: releases - release list with the gaps
• llama.cpp: Docker doc - official images on ghcr.io
• llama.cpp: pull request #31269 - /v1/realtime, merged on 28 October 2026