[ashwinsreedhar28]

The vLLM version guard from #335 compares vllm.__version__ to VLLM_VERSION with the v stripped. That only works for plain release tags. Any other base tag fails the build: nightly, latest, and vLLM's model-named day-0 images (step-5-preview, muse-spark-open, gemma4, ...), which carry dev versions like 0.1.dev22912+g8224bb82f. That includes the nightly path the README documents ("point VLLM_VERSION at a nightly tag or use latest").

This records the base image's vLLM before any pip install and checks afterwards that it didn't change, so the vllm-bnb-plugin replacement from #335 is caught for every base tag, not just releases. Plain release tags keep the exact version check. Release tags with a build suffix (v0.32.0-cu130) are now recognised as release 0.32.0; before, they were compared against 0.32.0-cu130 and always failed.

Why it matters: vLLM publishes a model-named image by release day for many big open-weight launches. In a hand-picked sample of 25 new-architecture releases this year, 18 had one, and 16 of those were available on or before the recorded release date. The worker can't currently be built from those images. Among the 23 of those 25 that have a vLLM final release, the median time to a published worker image whose vLLM lists the architecture was 24 days (that's a registry proxy and can overstate the real serving delay; method and caveats in the link below).

Evidence:

check	result
python -m pytest tests	156 pass (142 on main + 14 new cases in tests/test_check_vllm_version.py)
build FROM vllm/vllm-openai:step-5-preview (day-0 tag)	guard passes: vLLM 0.1.dev22912+g8224bb82f OK for base tag step-5-preview (run)
that image on Serverless, Qwen/Qwen3-8B, MAX_MODEL_LEN=4096, 24 GB class	first request COMPLETED 6.1 min after endpoint creation (result)
build FROM vllm/vllm-openai:v0.32.0 (default release tag)	exact check still applies: base image vLLM: 0.32.0, vLLM 0.32.0 OK for base tag v0.32.0 (run)
same day-0 tag, plus a step that replaces vLLM after the base image (pip install --no-deps vllm==0.31.0, test branch only)	build fails at the guard: ERROR: vLLM changed during the build: base image had 0.1.dev22912+g8224bb82f, now 0.31.0 (run)

The image-build and Serverless jobs need upstream secrets to complete on a fork PR; happy for them to be mirrored the way #352 was for #351.

Study, build logs and results: https://github.com/ashwinsreedhar28/day0-ready

[velaraptor-runpod]

Just thinking about this. But since this template has only been used for major/minor release tags. Not sure if we should have this implemented.

Use case I see is someone building the repo themselves.

[ashwinsreedhar28]

Just thinking about this. But since this template has only been used for major/minor release tags. Not sure if we should have this implemented.

Use case I see is someone building the repo themselves.

Fair point, release builds don't need this, and nothing changes for them: a vX.Y.Z tag still gets the exact version check.

The use case is people building it themselves, which the README already suggests ("To run a nightly vLLM build, point VLLM_VERSION at a nightly tag or use latest at your own risk."). That currently fails at the guard, so either the guard or that line should change.

For me it's mostly about new models. vLLM pushed vllm/vllm-openai:flint the day flint came out, and building the worker from it had flint answering on a Serverless B200 the same day.

Happy to make the non-release path opt-in with a build arg if you'd rather keep the default strict.