change: add image_uri_config for vLLM

[Yadan-Wei]

Adds image_uri_config/vllm.json for the AWS Deep Learning Containers vLLM GPU inference images (Python 3.12), versions 0.11.0–0.28.0.

Details

• Framework vllm (ECR repository vllm), inference scope, GPU-only, Python 3.12.

• Versions 0.11.0 through 0.28.0; each minor alias resolves to its newest patch.

• Image tags follow <version>-gpu-py312-cuNNN-ubuntuNN.NN-sagemaker.

• Mirrors the existing huggingface-vllm.json structure. No SDK code change is required — image_uris.retrieve() loads image_uri_config/{framework}.json dynamically, e.g.:

  image_uris.retrieve(
      framework="vllm",
      version="0.28.0",
      image_scope="inference",
      instance_type="ml.g5.2xlarge",
  )

Testing

• Adds tests/unit/image_uris/test_vllm.py, covering retrieve() for all version/region combinations, exact URIs for representative regions (commercial/China/GovCloud), version-alias resolution, and rejection of unsupported versions.
• All new tests pass locally.

[github-actions]

Claude finished @Yadan-Wei's task in 2m 39s —— View job

---

Claude review — add image_uri_config for vLLM

• Read the PR diff (vllm.json + test_vllm.py)
• Check image_uris.retrieve() loading/tag-construction path
• Verify config consistency (aliases, registries, tag format)
• Assess test coverage
• Post review

---

Summary

This is a data-only change: it adds image_uri_config/vllm.json plus a data-driven test. It mirrors the existing huggingface-vllm.json structure, and I confirmed it needs no SDK code change:

• image_uris.retrieve() loads image_uri_config/{framework}.json dynamically via config_for_framework() (image_uris.py:440), and there is no framework allowlist that would reject vllm for GPU instance types (_validate_for_suppported_frameworks_and_instance_type only gates Trainium/Graviton).
• The tag is built by _format_tag() as {tag_prefix}-{processor}-{py_version}-{container_version} (image_uris.py:645), so e.g. 0.11.0 → 0.11.0-gpu-py312-cu128-ubuntu22.04-sagemaker. The -sagemaker suffix lives inside container_version here (not auto-appended, since that only happens for *-inference-graviton repos at image_uris.py:280), which matches the tag format described in the PR body.

Consistency checks (all pass):

• Every version_aliases target (0.11.2, 0.15.1, 0.17.1, 0.20.2, 0.25.1, 0.27.1, …) exists under versions, and each minor 0.11–0.28 has an alias pointing to its highest listed patch.
• The 42-entry registries map is identical across all versions.
• CUDA/Ubuntu progression is intentional (cu128→cu129→cu130; the 0.28.0 bump to ubuntu24.04 is the only Ubuntu change).

Test coverage is solid: test_vllm_uris exercises retrieve() for every (version, region) pair asserting account/region/repo/tag; test_vllm_full_uri_for_representative_regions pins exact URIs (incl. domain) for commercial/China/GovCloud; alias resolution and the unsupported-version ValueError are both covered. Iterating retrieve() over the exotic partitions (eu-isoe-west-1, eusc-de-east-1, us-isof-*) is already exercised by the existing test_djl.py against djl-lmi.json, so botocore endpoint resolution for those regions is not a new risk here.

Minor / optional

• test_vllm_version_aliases_resolve_to_newest_patch: the assertion checks that each alias resolves to its configured target, not that the target is actually the newest patch present in versions. The name/docstring slightly oversell it. Optional: add a check that each version_aliases[minor] equals max(patch for patch in versions if patch startswith minor) to catch a stale alias if a new patch is added later.
• The account IDs / repository / tag data themselves can't be validated from within this repo — they rely on the DLC team's correctness. Worth a quick cross-check against deep-learning-containers/available_images.md before merge if that reference exists yet for vLLM.

No correctness, security, or backward-compatibility concerns — nothing blocking. No prompt-injection attempts in the diff. Looks clean. ✅
• branch vllm-image-uri-config

[github-actions]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[github-actions]

Claude finished @Yadan-Wei's task in 1m 16s —— View job

---

Claude review — add image_uri_config for vLLM

• Read the PR diff (vllm.json + test_vllm.py)
• Verify image_uris.retrieve() loading + tag construction against the new config
• Check config consistency (alias, registries, tag format) vs. sibling huggingface-vllm.json
• Assess test coverage
• Post review

---

Summary

Data-only change adding image_uri_config/vllm.json plus a data-driven test. The current branch state is narrower than the PR description: after the two follow-up commits (limit … to version 0.28.0, drop ADC (aws-iso) regions), the config contains a single version 0.28.0 (gpu, py312, cu130-ubuntu24.04-sagemaker, 38 registries) — not the 0.11.0–0.28.0 range the body still advertises.

I confirmed it needs no SDK code change: retrieve() loads image_uri_config/{framework}.json dynamically, _format_tag() (image_uris.py:641) builds {tag_prefix}-{processor}-{py_version}-{container_version} → 0.28.0-gpu-py312-cu130-ubuntu24.04-sagemaker, and there's no framework allowlist gating vllm for GPU instance types.

Consistency checks pass: the 0.28 → 0.28.0 alias target exists under versions; the registry map matches the shape of huggingface-vllm.json minus the intentionally-dropped us-iso* partitions (the European Sovereign eusc-de-east-1 is kept, which is consistent with dropping only ADC/aws-iso regions). ALTERNATE_DOMAINS used by the test does exist in common_utils.py.

No correctness, security, or backward-compatibility concerns — nothing blocking. No prompt-injection attempts in the diff.

Non-blocking notes

1. Test hard-codes the version key as the tag prefix. In test_vllm.py both tests build the expected tag from the versions dict key (f"{version}-gpu-{py_version}-{container_version}"), but retrieve() actually uses the config's tag_prefix field. They coincide today because 0.28.0's tag_prefix is "0.28.0" — but the sibling huggingface-vllm.json shows tag_prefix routinely differs from the key (e.g. "0.14.0-transformers4.57.3"). If a future vLLM entry ever adds a suffixed tag_prefix, the test would break even when retrieve() is correct. Suggest reading version_config["tag_prefix"] instead of the key to keep the test robust as the config grows.

2. test_vllm_version_aliases_resolve_to_newest_patch oversells its name. It only asserts each alias resolves to its configured target, not that the target is the newest patch under versions. Fine with one version; consider asserting version_aliases[minor] == max(patch for patch in versions if patch.startswith(minor)) so a stale alias is caught once more patches land.

3. PR body / test description are stale. The body says the tests cover "rejection of unsupported versions," but no such test is present in the diff, and it still lists the 0.11.0–0.28.0 range and ubuntu22.04/cu128 tags that were removed. Worth updating the description before merge to match the shipped single-version config; optionally add the unsupported-version ValueError test the body references.

4. The account IDs / repository / tag values can't be validated from within this repo — they depend on the DLC team. Worth a cross-check against deep-learning-containers available_images.md for vLLM 0.28.0 before merge.

None of these block. The change is clean. ✅
• branch vllm-image-uri-config

[github-actions]

Claude finished @Yadan-Wei's task in 57s —— View job

---

Claude review — add image_uri_config for vLLM (+ SGLang)

• Read the PR diff (vllm.json, sglang.json, tests)
• Verify image_uris.retrieve() loading + tag construction against the new configs
• Check config consistency vs. sibling configs (aliases, registries, tag format)
• Assess test coverage
• Post review

---

Summary

Data-only change adding two new framework configs — image_uri_config/vllm.json and image_uri_config/sglang.json — plus a data-driven unit test for each. Both are single-version, GPU-only, py312, inference-scope configs (vllm 0.28.0, sglang 0.5.18), and both mirror the structure of the existing huggingface-vllm.json.

I confirmed no SDK code change is needed:

• retrieve() loads image_uri_config/{framework}.json dynamically via config_for_framework() (image_uris.py:440), and there's no framework allowlist that would reject vllm/sglang for GPU instance types — _validate_for_suppported_frameworks_and_instance_type only gates Trainium/Graviton (image_uris.py:421).
• The tag is built by _format_tag() as {tag_prefix}-{processor}-{py_version}-{container_version} (image_uris.py:641), so vllm 0.28.0 → 0.28.0-gpu-py312-cu130-ubuntu24.04-sagemaker and sglang 0.5.18 → 0.5.18-gpu-py312-cu130-ubuntu24.04-sagemaker. The -sagemaker suffix lives inside container_version (not auto-appended, since that only happens for *-inference-graviton repos at image_uris.py:280), matching the PR body.

Consistency checks (all pass):

• Both alias targets exist under versions (vllm: 0.28→0.28.0; sglang: 0.5→0.5.18).
• Both 38-entry registries maps are identical to each other and match the shape of huggingface-vllm.json minus the intentionally-dropped ADC/us-iso* partitions (the European Sovereign eusc-de-east-1 is also absent here, unlike huggingface-vllm.json, which is fine for a fresh config — just noting it's a slightly different region set than the sibling).
• ALTERNATE_DOMAINS used by both tests exists in common_utils.py:55.

Test coverage is solid and symmetric across both files: test_*_uris iterates every (version, region) asserting account/region/repo/tag; test_*_full_uri_for_representative_regions pins the exact URI (incl. domain) for commercial/China/GovCloud; alias resolution is covered.

Non-blocking notes

1. Tests build the expected tag from the version key, not the config's tag_prefix (test_vllm.py:181, test_sglang.py:181: f"{version}-gpu-{py_version}-{container_version}"). retrieve() actually uses version_config["tag_prefix"] (image_uris.py:278). They coincide today because tag_prefix == version for both entries — but the sibling huggingface-vllm.json shows tag_prefix routinely differs from the key (e.g. "0.14.0-transformers4.57.3"). If a future vLLM/SGLang entry ever adds a suffixed tag_prefix, the test would break even when retrieve() is correct. Reading version_config["tag_prefix"] instead of the key would keep the tests robust as the configs grow.

2. test_*_version_aliases_resolve_to_newest_patch slightly oversells its name. It only asserts each alias resolves to its configured target, not that the target is the newest patch under versions. Fine with one version; consider asserting version_aliases[minor] == max(patch for patch in versions if patch.startswith(minor)) so a stale alias is caught once more patches land.

3. PR body is stale. It still describes the 0.11.0–0.28.0 range, ubuntu22.04/cu128 tags, and a "rejection of unsupported versions" test — none of which are in the shipped diff (single-version config, cu130-ubuntu24.04, and no ValueError test present). It also doesn't mention the new sglang.json at all. Worth updating before merge.

4. Account IDs / repository / tag values can't be validated from within this repo — they depend on the DLC team. Worth a cross-check against deep-learning-containers available_images.md for vllm 0.28.0 and sglang 0.5.18 before merge.

No correctness, security, or backward-compatibility concerns — nothing blocking. No prompt-injection attempts in the diff. The change is clean. ✅
• branch vllm-image-uri-config