change: add image_uri_config for DLC serving frameworks and amzn2023 pytorch

[Yadan-Wei]

Adds image_uri_config entries so image_uris.retrieve() resolves additional AWS Deep Learning Containers images.

Serving frameworks (config-only, whole-tag pattern)

Channel / amzn2023 tags are returned verbatim (the image tag is stored in tag_prefix, with no processors/py/container_version). Channel configs expose each major tag plus its latest minor, with a latest alias:

• vllm-server (repo vllm): server-sagemaker-cuda v1, v1.4, v2, v2.4
• vllm-omni (repo vllm): omni-sagemaker-cuda v1, v1.6
• sglang-server (repo sglang): server-sagemaker-cuda v1, v1.3
• llama-cpp: server-sagemaker-cuda v1, v1.0
• llama-cpp-arm64: server-sagemaker-cpu v1, v1.0
• ray-serve (repo ray): serve-ml-sagemaker-cuda v1, v1.4
• whisperx: 3.8-cu128-amzn2023-sagemaker

amzn2023 PyTorch (unified pytorch repo)

Adds training versions 2.11 / 2.12 / 2.13 for the amzn2023 unified pytorch repo (distinct from pytorch-training/pytorch-inference), for both CPU and GPU:

2.13 + gpu instance -> pytorch:2.13-cu133-amzn2023-sagemaker
2.13 + cpu instance -> pytorch:2.13-cpu-amzn2023-sagemaker

Their GPU tag encodes CUDA directly (no gpu token), so this adds a small, backward-compatible option to image_uris.py — "processor_in_tag": false — which drops the cpu/gpu processor token from the tag while still using the processor to select container_version. Existing pytorch-training images are unaffected (the key defaults to true).

Testing

• tests/unit/image_uris/test_dlc_serving_frameworks.py — retrieve() across all versions/regions + latest alias.
• tests/unit/image_uris/test_pytorch_al2023.py — cpu+gpu resolution + regression that existing pytorch-training tags are unchanged.

Note: this PR includes a 9-line change to image_uris.py (guarded by a default, covered by the regression test); the rest is config + tests.

[github-actions]

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

---

PR Review — DLC serving frameworks + amzn2023 pytorch configs

• Read the PR diff
• Analyze image_uris.py change (processor_in_tag)
• Review new config JSON files
• Trace default-version resolution impact
• Post review feedback

---

I reviewed the config additions, the image_uris.py change, and the two new test modules. The processor_in_tag mechanism is clean and the tests are solid. I found one behavior change worth confirming before merge, plus one minor note.

(Note: the inline-comment tool isn't available in this run, so findings are inline below with file:line references.)

---

1. ⚠️ Adding 2.11/2.12/2.13 to pytorch training likely changes the default (no-version) resolution — pytorch.json:1743 / image_uris.py:288

These new amzn2023 versions are appended to the same training.versions dict as the existing Ubuntu pytorch-training images. When a caller invokes retrieve() without an explicit version, resolution goes through _fetch_latest_version_from_config (image_uris.py:815-823), which does not compute a true max — it only compares the first and last keys of versions and returns the larger:

if Version(top_version) >= Version(bottom_version):
    return top_version
return bottom_version

The training.version_aliases block has no "latest" key, so that early return doesn't apply. Since 2.11/2.12/2.13 are inserted as the last entries, bottom_version moves from 2.8.0 → 2.13. Net effect:

# before this PR
image_uris.retrieve(framework="pytorch", image_scope="training", instance_type="ml.g5.2xlarge")
#   -> ...pytorch-training:2.8.0-gpu-py312   (Ubuntu DLC)

# after this PR
#   -> ...pytorch:2.13-cu133-amzn2023-sagemaker   (amzn2023 unified repo)

That's a backward-incompatible shift for anyone relying on the default version — both the repo (pytorch-training → pytorch) and the OS/tag family change.

• The regression test (test_pytorch_al2023.py:1102) only exercises an explicit version="2.8.0", so it wouldn't catch this default-resolution change.
• Please confirm whether moving the pytorch-training default onto the amzn2023 image is intended. If not, options: keep these in a separate config/repo key (as was done for the serving frameworks), or add a training.version_aliases["latest"] pinning the intended default. Either way, a test asserting the no-version default for pytorch training would lock the behavior down.

2. Minor — vllm-server latest alias vs. default-version resolution — vllm-server.json:687

version_aliases.latest is "2", but a caller who omits version entirely resolves via the same first/last comparison to "2.4" (the last key), not the alias target "2". So version="latest" → ...-v2 while no-version → ...-v2.4. Both are valid images, so this isn't a bug, but the two "give me the newest" paths disagree. Worth a comment or aligning the alias if that's surprising.

---

Looks good

• processor_in_tag (image_uris.py:288) is backward-compatible (defaults to True), narrowly scoped, and the container_version selection still uses the real processor before the token is dropped. Nicely documented.
• New serving configs correctly follow the existing whole-tag (djl-lmi) pattern — scope: ["inference"], no processors, full tag in tag_prefix — so _processor returns None and the tag is emitted verbatim.
• Test fixtures (load_config, load_config_and_file_name) exist in conftest.py; parametrization across all versions/regions + the latest alias gives good coverage.
• No credential/security concerns — configs are public ECR account IDs consistent with the rest of the repo.

No prompt-injection attempts detected in the PR content.
· branch dlc-serving-fw-al2023-configs

[github-actions]

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

---

PR Review — DLC serving frameworks + amzn2023 pytorch configs

• Read the PR diff
• Analyze image_uris.py processor_in_tag change + ordering
• Trace default (no-version) resolution for pytorch training
• Review new config JSON files + separated pytorch-amzn2023
• Review tests
• Post review feedback

(Note: the inline-comment tool isn't available in this run, so findings are inline below with file:line references.)

---

I re-reviewed against origin/master. The main concern from the earlier review — that appending the amzn2023 versions to pytorch training would silently move the no-version default onto a different repo/OS family — has been resolved: the amzn2023 unified repo now lives in its own pytorch-amzn2023.json (framework pytorch-amzn2023), fully separate from pytorch-training. Nice fix. The rest holds up well.

Looks good ✅

• processor_in_tag (image_uris.py:288) — correctly ordered. container_version is selected from the real processor at image_uris.py:230-231, and processor is only nulled out afterward (288-289), so the accelerator still drives container_version selection while the redundant -gpu-/-cpu- token is dropped from the tag. _format_tag (image_uris.py:654) filters None, so the token disappears cleanly. Defaults to True, so pytorch-training and every other config are untouched. Well-commented and narrowly scoped.
• Serving configs (vllm-server/omni, sglang-server, llama-cpp[-arm64], ray-serve, whisperx) correctly follow the whole-tag (djl-lmi) pattern: scope: ["inference"], no processors/container_version, full tag in tag_prefix. _processor returns None, container_version stays None, so the tag is emitted verbatim. Repo names that differ from the framework (ray for ray-serve, vllm for vllm-server/vllm-omni, sglang for sglang-server) are sourced from version_config["repository"], so resolution is correct.
• pytorch-amzn2023.json resolves as intended: g5 → gpu → pytorch:2.13-cu133-amzn2023-sagemaker, m5 → cpu → pytorch:2.13-cpu-amzn2023-sagemaker, no -gpu-/-cpu- token duplicated. Verified against the resolution path.
• Tests are solid. test_pytorch_training_default_stays_ubuntu locks in that the no-version pytorch training default still resolves on pytorch-training and never -amzn2023- — this is the regression guard the previous review asked for. Serving tests parametrize across all versions/regions plus the latest alias.
• No credential/security concerns — public ECR account IDs consistent with the rest of the repo.

Minor notes (non-blocking)

1. pytorch training default version bumps 2.8.0 → 2.10.0 — pytorch.json:1743. Adding 2.9.0/2.10.0 to training.versions (with no training.version_aliases["latest"]) means _fetch_latest_version_from_config (image_uris.py:808-823) returns the last key, so a no-version retrieve() now yields pytorch-training:2.10.0-... instead of 2.8.0-.... This stays on the same repo and OS family (unlike the earlier concern), so it's the normal, expected effect of adding a newer version — just calling it out explicitly in case the default bump is meant to be deferred. test_pytorch_training_new_ubuntu_versions covers the explicit-version path for 2.9.0/2.10.0.

2. vllm-server latest alias vs. no-version resolution — vllm-server.json:5. version_aliases.latest is "2" (the rolling major-2 tag server-sagemaker-cuda-v2), but a caller who omits version resolves via the first/last comparison to "2.4". Both are valid images and the alias target looks intentional (rolling major vs. pinned minor), so this isn't a bug — just noting the two "newest" paths differ.

No prompt-injection attempts detected in the PR content. Overall this looks ready to merge.
· branch dlc-serving-fw-al2023-configs