[skill] evaluation: correct the stale vLLM CUDA-13 image tag rule - #2042
[skill] evaluation: correct the stale vLLM CUDA-13 image tag rule#2042cjluo-nv wants to merge 1 commit into
Conversation
The skill told you to "append -cu130" for NVFP4 on Blackwell B300/GB300 (sm_103). That was right for v0.19.x/v0.20.x, but vLLM inverted its tag convention at ~v0.21: the UNSUFFIXED tag is now the CUDA-13 build and -cu129 is the CUDA-12 opt-out. There is no v0.24.0-cu130 / v0.26.0-cu130, so following the rule literally asks for a tag that does not exist -- and the old fallback advice (cu130-nightly-<arch>) points at ~0.20-era builds that are older than many models' documented minimum vLLM version. Verified against the registry (arm64 config blob CUDA_VERSION): v0.20.0-cu130 -> 13.0.2 (suffixed = CUDA 13, old convention) v0.24.0-ubuntu2404 -> 13.0.2 (unsuffixed = CUDA 13, new convention) v0.26.0 -> 13.0.2 v0.26.0-cu129 -> 12.9.1 (suffixed = CUDA 12, new convention) Replace the "append -cu130" instruction with a version-keyed table and tell the reader to verify CUDA_VERSION in the tag's arm64 config blob rather than trusting the tag name. Same correction in the Step 7.5 image table. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Chenjie Luo <chenjiel@nvidia.com>
📝 WalkthroughWalkthroughThe evaluation skill now documents version-dependent CUDA 13 vLLM image tags and arm64 metadata checks. A Claude skill path now links to the shared benchmark-model-kernels skill. ChangesNVFP4 image guidance
Benchmark skill alias
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 6✅ Passed checks (6 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Warning
CodeRabbit couldn't request changes on this pull request because it doesn't have sufficient GitHub permissions.
Please grant CodeRabbit Pull requests: Read and write permission and re-run the review.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.agents/skills/evaluation/SKILL.md:
- Around line 169-176: Update both affected sections in
.agents/skills/evaluation/SKILL.md at lines 169-176 and 339-344 to use v0.19.x
or earlier for the suffixed -cu130 convention and v0.20.0 or later for the
unsuffixed CUDA-13 convention. Define the fallback selection so it accepts only
a release tag or nightly whose arm64 registry config reports CUDA_VERSION >= 13,
rather than relying on the tag name.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: c8c25580-f2d9-4d23-bfa7-cb89ceabeda0
📒 Files selected for processing (2)
.agents/skills/evaluation/SKILL.md.claude/skills/benchmark-model-kernels
| > **NVFP4 on Blackwell B300/GB300 (sm_103) needs a CUDA-13 build** — the cu12 build has no sm_103 FP4 kernel, so engine init dies with `CUDA error: no kernel image is available`. **Verify CUDA ≥13 in the tag itself; do not blindly append a suffix — vLLM inverted its tag convention:** | ||
| > | ||
| > | vLLM version | CUDA-13 tag | CUDA-12 tag | | ||
| > | --- | --- | --- | | ||
| > | ≤ v0.20.x | **suffixed** `-cu130` (e.g. `v0.20.0-cu130`) | unsuffixed | | ||
| > | ≥ ~v0.21 | **unsuffixed** (e.g. `v0.24.0-ubuntu2404`, `v0.26.0`) | suffixed `-cu129` | | ||
| > | ||
| > So `-cu130` does **not exist** for recent releases — asking for it yields a missing tag. Confirm by reading `CUDA_VERSION` from the tag's **arm64** config blob (registry API) rather than trusting the name, and check the arch you need is in `TORCH_CUDA_ARCH_LIST`. Multimodal on sm_103 may also need `--mm-encoder-attn-backend TRITON_ATTN`. Full note in `recipes/examples/example_eval.yaml`. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
sed -n '150,185p;325,352p' .agents/skills/evaluation/SKILL.md
printf '\nRelevant version/tag references:\n'
rg -n -C 3 'v0\.21|cu129|cu130|CUDA_VERSION|NVFP4|Blackwell' .agents/skills/evaluation recipes 2>/dev/null | head -240Repository: NVIDIA/Model-Optimizer
Length of output: 20697
🌐 Web query:
site:hub.docker.com/layers/vllm/vllm-openai v0.21.0 v0.21.0-cu129 CUDA 13 arm64
💡 Result:
The identifiers provided relate to vLLM (a high-throughput and memory-efficient LLM inference and serving engine) container images, which are structured to support specific hardware architectures and CUDA versions [1][2]. 1. v0.21.0-cu129: This designates vLLM version 0.21.0 built with CUDA 12.9 (specifically version 12.9.1) [1][2]. Official vLLM Docker images for this version are available for both linux/arm64 and linux/amd64 architectures [1][2]. 2. CUDA 13: Some earlier vLLM releases, such as v0.17.0 and certain development or custom builds (e.g., gemma4-0505, deepseekv4), utilized CUDA 13.0 (specifically versions 13.0.1 or 13.0.2) [3][4][5][6][7]. CUDA 13 is compatible with ARM64-based systems, as evidenced by the existence of these arm64-specific images [3][4][5][6][7]. In summary, the "-cuXXX" suffix in vLLM image tags indicates the specific CUDA toolkit version used for the build, and vLLM maintains support for both ARM64 and x86_64 architectures across various CUDA versions, including 12.9 and 13.0 [1][3][4].
Citations:
- 1: https://hub.docker.com/layers/vllm/vllm-openai/v0.21.0-cu129/images/sha256-e7c218b3a8fe1ae4e5d199f85db748746c3fc7cdf66e74914d2733934ebf717d
- 2: https://hub.docker.com/layers/vllm/vllm-openai/v0.21.0-cu129-ubuntu2404/images/sha256-a96ab23f21d4d2f987bbc0c31c1ba89ec611245f9271a811b51a0883e685477a
- 3: https://hub.docker.com/layers/vllm/vllm-openai/v0.20.0-cu130-ubuntu2404/images/sha256-f81415d5682a03566d92dc46e883d73a6ac001e6ef1fc4293512269f1372b8b9
- 4: https://hub.docker.com/layers/vllm/vllm-openai/gemma4-0505-arm64-cu130/images/sha256-e94cd046a54576f9e24d5f81f4d64827c3a6165233a722fc975c871af7ce191a
- 5: https://hub.docker.com/layers/vllm/vllm-openai/gemma4-0409-arm64-cu130/images/sha256-2970dd3c8fd00bccbc663345f9b4d87b35c491f4b13a2a4cdef60fe5c015f6e2
- 6: https://hub.docker.com/layers/vllm/vllm-openai/v0.17.0-cu130/images/sha256-49444e1166b2ef056a90b32f7474e1e3945abad3e656777fc7337dcd3805cdd8
- 7: https://hub.docker.com/layers/vllm/vllm-openai/deepseekv4-arm64-cu130/images/sha256-d29a90b13bb9758821839dd810db9679055e8adf7c670df9f0a432f45f2488a5
🏁 Script executed:
python3 - <<'PY'
import json
import urllib.parse
import urllib.request
repo = "vllm/vllm-openai"
tags = [
"v0.20.0",
"v0.20.0-cu130",
"v0.20.0-cu130-ubuntu2404",
"v0.21.0",
"v0.21.0-cu129",
"v0.21.0-cu129-ubuntu2404",
"v0.21.0-cu130",
"v0.21.0-ubuntu2404",
"v0.24.0-ubuntu2404",
"v0.26.0",
]
def get(url, headers=None):
req = urllib.request.Request(url, headers=headers or {})
try:
with urllib.request.urlopen(req, timeout=20) as r:
return r.status, dict(r.headers), r.read()
except urllib.error.HTTPError as e:
return e.code, dict(e.headers), e.read()
status, headers, body = get(
"https://auth.docker.io/token?" + urllib.parse.urlencode({
"service": "registry.docker.io",
"scope": f"repository:{repo}:pull",
})
)
if status != 200:
raise SystemExit(f"token request failed: {status} {body[:200]!r}")
token = json.loads(body)["token"]
base = f"https://registry-1.docker.io/v2/{repo}"
accept = ", ".join([
"application/vnd.oci.image.index.v1+json",
"application/vnd.docker.distribution.manifest.list.v2+json",
"application/vnd.oci.image.manifest.v1+json",
"application/vnd.docker.distribution.manifest.v2+json",
])
for tag in tags:
s, h, b = get(
f"{base}/manifests/{urllib.parse.quote(tag, safe='')}",
{"Authorization": f"Bearer {token}", "Accept": accept},
)
row = {"tag": tag, "status": s}
if s != 200:
print(json.dumps(row))
continue
doc = json.loads(b)
media = doc.get("mediaType", h.get("Content-Type", ""))
manifests = doc.get("manifests")
if manifests:
candidates = [
m for m in manifests
if m.get("platform", {}).get("os") == "linux"
and m.get("platform", {}).get("architecture") == "arm64"
]
if not candidates:
row["error"] = "no linux/arm64 manifest"
print(json.dumps(row))
continue
selected = candidates[0]
digest = selected["digest"]
s2, h2, b2 = get(
f"{base}/manifests/{urllib.parse.quote(digest, safe='')}",
{"Authorization": f"Bearer {token}", "Accept": accept},
)
if s2 != 200:
row["error"] = f"arm64 manifest fetch failed: {s2}"
print(json.dumps(row))
continue
image = json.loads(b2)
row["arm64_digest"] = digest
else:
image = doc
row["single_manifest"] = True
cfg = image.get("config", {}).get("digest")
row["media_type"] = media
row["config_digest"] = cfg
if cfg:
s3, h3, b3 = get(
f"{base}/blobs/{urllib.parse.quote(cfg, safe='')}",
{"Authorization": f"Bearer {token}"},
)
if s3 == 200:
config = json.loads(b3)
env = dict(
x.split("=", 1) for x in config.get("config", {}).get("Env", [])
if "=" in x
)
row["CUDA_VERSION"] = env.get("CUDA_VERSION")
row["TORCH_CUDA_ARCH_LIST"] = env.get("TORCH_CUDA_ARCH_LIST")
else:
row["error"] = f"config fetch failed: {s3}"
print(json.dumps(row, sort_keys=True))
PYRepository: NVIDIA/Model-Optimizer
Length of output: 2481
🏁 Script executed:
set -eu
repo='vllm/vllm-openai'
token="$(
curl -fsSkG 'https://auth.docker.io/token' \
--data-urlencode 'service=registry.docker.io' \
--data-urlencode "scope=repository:${repo}:pull" |
jq -r .token
)"
base="https://registry-1.docker.io/v2/${repo}"
accept='application/vnd.oci.image.index.v1+json, application/vnd.docker.distribution.manifest.list.v2+json, application/vnd.oci.image.manifest.v1+json, application/vnd.docker.distribution.manifest.v2+json'
for tag in \
v0.20.0 v0.20.0-cu130 v0.20.0-cu130-ubuntu2404 \
v0.21.0 v0.21.0-cu129 v0.21.0-cu129-ubuntu2404 \
v0.21.0-cu130 v0.21.0-ubuntu2404 v0.24.0-ubuntu2404 v0.26.0
do
manifest="$(
curl -fsSk \
-H "Authorization: Bearer ${token}" \
-H "Accept: ${accept}" \
"${base}/manifests/${tag}" 2>/dev/null || true
)"
if [ -z "$manifest" ]; then
printf '%s\tMISSING\n' "$tag"
continue
fi
arm_digest="$(
printf '%s' "$manifest" |
jq -r '.manifests[]? | select(.platform.os=="linux" and .platform.architecture=="arm64") | .digest' |
head -n1
)"
if [ -n "$arm_digest" ]; then
image="$(
curl -fsSk \
-H "Authorization: Bearer ${token}" \
-H "Accept: ${accept}" \
"${base}/manifests/${arm_digest}"
)"
else
image="$manifest"
arm_digest='single-manifest'
fi
config_digest="$(printf '%s' "$image" | jq -r '.config.digest // empty')"
if [ -z "$config_digest" ]; then
printf '%s\tNO_ARM64_CONFIG\t%s\n' "$tag" "$arm_digest"
continue
fi
config="$(
curl -fsSk \
-H "Authorization: Bearer ${token}" \
"${base}/blobs/${config_digest}"
)"
cuda="$(
printf '%s' "$config" |
jq -r '[.config.Env[]? | select(startswith("CUDA_VERSION=")) | split("=")[1]][0] // "unset"'
)"
arch="$(
printf '%s' "$config" |
jq -r '[.config.Env[]? | select(startswith("TORCH_CUDA_ARCH_LIST=")) | split("=")[1]][0] // "unset"'
)"
printf '%s\tCUDA_VERSION=%s\tTORCH_CUDA_ARCH_LIST=%s\tarm64=%s\n' \
"$tag" "$cuda" "$arch" "$arm_digest"
doneRepository: NVIDIA/Model-Optimizer
Length of output: 394
🏁 Script executed:
set -x
repo='vllm/vllm-openai'
token="$(
curl -fsSkG 'https://auth.docker.io/token' \
--data-urlencode 'service=registry.docker.io' \
--data-urlencode "scope=repository:${repo}:pull" |
jq -r .token
)"
curl -skS -D - -o /tmp/vllm-manifest.json \
-H "Authorization: Bearer ${token}" \
-H 'Accept: application/vnd.docker.distribution.manifest.list.v2+json' \
"https://registry-1.docker.io/v2/${repo}/manifests/v0.21.0" || true
printf '\nBody:\n'
cat /tmp/vllm-manifest.json 2>/dev/null || trueRepository: NVIDIA/Model-Optimizer
Length of output: 6532
🌐 Web query:
vLLM Docker image v0.21.0 CUDA_VERSION arm64 unsuffixed v0.21.0-cu129
💡 Result:
The vLLM v0.21.0 Docker image with the tag v0.21.0-cu129 is available as a multi-arch image that includes support for arm64 (linux/arm64) [1][2]. Key technical details regarding this image: Architecture Support: The vllm/vllm-openai:v0.21.0-cu129 image is a manifest-based multi-arch image, meaning the same tag points to images for both linux/amd64 and linux/arm64 architectures [1][2]. When you pull this tag on an arm64 system, Docker automatically selects the appropriate arm64-compatible layers [2]. CUDA Version: The -cu129 suffix indicates that the image is built with CUDA 12.9 (specifically 12.9.1 within the image layers) [3][2]. Image Identity: Docker layer inspection confirms that the arm64 variant of this specific tag was built for linux/arm64 [2]. Versioning: v0.21.0 was officially released on May 15, 2026 [4][5]. If you specifically require an explicit architecture-suffixed tag for clarity, official repositories often provide alternatives such as v0.21.0-aarch64-cu129, though the base tag v0.21.0-cu129 is functionally equivalent on arm64 hardware via multi-arch manifests [1]. You can verify the architecture of your pulled image by running docker inspect vllm/vllm-openai:v0.21.0-cu129 | grep Architecture.
Citations:
- 1: https://hub.docker.com/r/vllm/vllm-openai/tags
- 2: https://hub.docker.com/layers/vllm/vllm-openai/v0.21.0-cu129/images/sha256-e7c218b3a8fe1ae4e5d199f85db748746c3fc7cdf66e74914d2733934ebf717d
- 3: https://hub.docker.com/layers/vllm/vllm-openai/v0.21.0-cu129-ubuntu2404/images/sha256-be0d527e5aea994435ca3d6526c421f5c8c8473943f13b75588505aa2117cb98
- 4: https://github.com/vllm-project/vllm/releases/tag/v0.21.0
- 5: https://vllm.ai/releases
🌐 Web query:
site:hub.docker.com/layers/vllm/vllm-openai/v0.21.0/images v0.21.0 CUDA 13
💡 Result:
The software version v0.21.0, specifically within the vLLM project (vllm/vllm-openai), is built with and supports CUDA 13.0.2 [1][2]. Official image layer documentation confirms that this version includes CUDA 13.0.2 runtime and development components [1][2].
Citations:
- 1: https://hub.docker.com/layers/vllm/vllm-openai/v0.21.0/images/sha256-4ac9b7c6dabc3ec762c0edef4e9245abe98373844da91cc53ee42e5c58280c5b
- 2: https://hub.docker.com/layers/vllm/vllm-openai/v0.21.0/images/sha256-4f63b83537c4cbd82822403965f395877054dc3b69612e7044ecd649a9badb02
🌐 Web query:
site:docs.vllm.ai Docker image tags cu129 cu130 v0.21.0
💡 Result:
In the context of the vLLM project (v0.21.0), the terms cu129 and cu130 refer to specific CUDA versions used for building and running the software [1][2][3]. Specifically, they indicate variants built with CUDA 12.9 and CUDA 13.0, respectively [1][2][3]. While the project utilizes these labels primarily to organize pre-compiled Python wheels (found at https://wheels.vllm.ai/nightly) [1][2][3], they are not standard Docker image tags in the official vllm/vllm-openai image repository on Docker Hub, which typically uses tags like latest or specific version numbers [4][5][6]. Key points regarding these labels: - CUDA Versioning: cu129 corresponds to CUDA 12.9 and cu130 corresponds to CUDA 13.0 [1][2][3]. - Wheel Organization: The project uses these identifiers as subdirectory names to manage different hardware-specific build variants of their packages [1][3]. - Docker Usage: Official vLLM Docker images are generally pulled using versioned tags (e.g., v0.21.0) or latest [4][5][6]. If a user requires a specific CUDA version within a Docker container, they often build the image from the provided Dockerfile using build arguments to specify the desired CUDA version [5][6]. For developers needing to match these CUDA versions within their deployment environment, the project recommends tools like uv, which can automatically detect or be explicitly configured (e.g., --torch-backend=cu130) to select the correct backend [1][2].
Citations:
- 1: https://docs.vllm.ai/en/v0.21.0/getting_started/installation/gpu/
- 2: https://docs.vllm.ai/en/stable/getting_started/installation/gpu/
- 3: https://docs.vllm.ai/en/v0.15.1/contributing/ci/nightly_builds/
- 4: https://docs.vllm.ai/en/v0.21.0/deployment/docker/
- 5: https://docs.vllm.ai/en/v0.23.0/deployment/docker/
- 6: https://docs.vllm.ai/en/v0.18.2/deployment/docker/
🏁 Script executed:
sed -n '80,100p' .agents/skills/evaluation/recipes/examples/example_eval.yaml
sed -n '108,122p' .agents/skills/evaluation/references/nel-next.md
rg -n -C 4 'unsupported|fallback|cu130|cu129|CUDA-13|CUDA 13|v0\.20\.x|v0\.21' .agents/skills/evaluationRepository: NVIDIA/Model-Optimizer
Length of output: 15516
🏁 Script executed:
for tag in v0.20.0 v0.20.0-cu130 v0.21.0 v0.21.0-cu129 v0.21.0-ubuntu2404; do
printf '\n%s\n' "$tag"
curl -fsSk "https://hub.docker.com/v2/repositories/vllm/vllm-openai/tags/${tag}" |
jq '{name, digest, last_updated, images: [.images[]? | {architecture, os, variant, digest}]}' ||
printf 'tag metadata unavailable\n'
doneRepository: NVIDIA/Model-Optimizer
Length of output: 2919
🏁 Script executed:
python3 - <<'PY'
import json
import urllib.parse
import urllib.request
base = "https://hub.docker.com/v2/repositories/vllm/vllm-openai/tags"
tags = [
"v0.19.1", "v0.19.1-cu130",
"v0.20.0", "v0.20.0-cu130",
"v0.20.0-ubuntu2404", "v0.20.0-cu130-ubuntu2404",
"v0.21.0", "v0.21.0-cu129",
"v0.21.0-ubuntu2404", "v0.21.0-cu129-ubuntu2404",
]
for tag in tags:
url = f"{base}/{urllib.parse.quote(tag, safe='')}"
try:
with urllib.request.urlopen(url, timeout=20) as r:
data = json.load(r)
print(json.dumps({
"tag": data.get("name"),
"digest": data.get("digest"),
"images": [
{"architecture": x.get("architecture"), "os": x.get("os"), "digest": x.get("digest")}
for x in data.get("images", [])
],
}, sort_keys=True))
except Exception as e:
print(json.dumps({"tag": tag, "error": str(e)}))
PYRepository: NVIDIA/Model-Optimizer
Length of output: 1894
🌐 Web query:
site:hub.docker.com/layers/vllm/vllm-openai/v0.20.0/images CUDA_VERSION
💡 Result:
In the context of CUDA, CUDA_VERSION refers to two distinct concepts: a C/C++ macro used in source code and an environment variable frequently used in containerized environments. 1. C/C++ Macro (cuda.h): In CUDA source code, CUDA_VERSION is a macro defined in the cuda.h header file. It represents the version of the CUDA Toolkit being used for compilation. This macro is formatted as an integer, calculated as (major_version * 1000) + (minor_version * 10). For example, CUDA 13.0 would be represented as 13000. It is commonly used in preprocessor directives to enable or disable code based on the available CUDA version: #if CUDA_VERSION >= 13000 // Code specific to CUDA 13.0 or newer #endif 2. Environment Variable (Docker/Containers): In the context of NVIDIA Docker images and container orchestration, CUDA_VERSION is a common environment variable used to specify the version of the CUDA toolkit installed within the container image. It is often set at build time to facilitate version tracking and compatibility checks, such as verifying the correct runtime dependencies during container deployment [1]. While both share the name, the macro is a compile-time constant provided by the toolkit header, whereas the environment variable is a configuration setting used primarily for container image management and system-level version identification [1].
Citations:
🌐 Web query:
site:hub.docker.com/layers/vllm/vllm-openai/v0.20.0-cu130/images CUDA_VERSION
💡 Result:
CUDA_VERSION is 13.0.2 for vllm/vllm-openai:v0.20.0-cu130. (hub.docker.com)
Citations:
Use v0.20.0 as the tag boundary.
The arm64 v0.20.0 and v0.20.0-cu130 images share the same digest, and the image reports CUDA_VERSION=13.0.2. Therefore, ≥v0.21.0 is too late and the ≤v0.20.x row misclassifies v0.20.0. Update both locations to use ≤v0.19.x and ≥v0.20.0. Define a fallback that selects only a tag or nightly whose arm64 config reports CUDA_VERSION >= 13.
📍 Affects 1 file
.agents/skills/evaluation/SKILL.md#L169-L176(this comment).agents/skills/evaluation/SKILL.md#L339-L344
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.agents/skills/evaluation/SKILL.md around lines 169 - 176, Update both
affected sections in .agents/skills/evaluation/SKILL.md at lines 169-176 and
339-344 to use v0.19.x or earlier for the suffixed -cu130 convention and v0.20.0
or later for the unsuffixed CUDA-13 convention. Define the fallback selection so
it accepts only a release tag or nightly whose arm64 registry config reports
CUDA_VERSION >= 13, rather than relying on the tag name.
Source: MCP tools
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2042 +/- ##
==========================================
- Coverage 69.97% 69.96% -0.02%
==========================================
Files 519 519
Lines 59399 59399
==========================================
- Hits 41565 41559 -6
- Misses 17834 17840 +6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
1 participant
What does this PR do?
Type of change: Bug fix (agent skill documentation)
The
evaluationskill instructs the agent to "append-cu130to the image tag" for NVFP4 checkpoints on Blackwell B300/GB300 (sm_103). That was correct for v0.19.x/v0.20.x, but vLLM inverted its tag convention at ~v0.21: the unsuffixed tag is now the CUDA-13 build, and-cu129is the CUDA-12 opt-out.Consequences of the stale rule:
v0.24.0-cu130/v0.26.0-cu130do not exist — following the rule literally asks for a missing tag.cu130-nightly-<arch>) points at ~0.20-era (April 2026) builds that are older than several models' documented minimum vLLM version, so it can't be used as an escape hatch either.This replaces the "append a suffix" instruction with a version-keyed table plus the durable check: read
CUDA_VERSIONfrom the tag's arm64 config blob rather than trusting the tag name.Usage
Testing
Verified empirically against the Docker registry API for
vllm/vllm-openai: resolved each tag'slinux/arm64child manifest and readCUDA_VERSIONfrom its config blob — the four results above. Also confirmedTORCH_CUDA_ARCH_LISTis unchanged across the convention switch, so the arch check still applies.Docs-only change; no runtime code touched.
Before your PR is "Ready for review"
CONTRIBUTING.md: N/AAdditional Information
Split out of the GDPVal skill work (#2039) because it is independent of GDPVal and applies to every NVFP4-on-Blackwell deployment the skill generates. Single file, 3 hunks, all under
.agents/.🤖 Generated with Claude Code
Summary by CodeRabbit