update image_uri_configs for RUH

[Yadan-Wei]

Issue #, if available:

Description of changes:

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

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

---

Claude Code Review — PR #6303 (update image_uri_configs for RUH)

• Read the PR diff (/tmp/pr.diff, full 3223 lines)
• Verify the tag_prefix + container_version refactor is behavior-preserving
• Check region/partition consistency across new & moved versions
• Post review

---

This is a data-only change to image_uri_config/*.json (new framework versions, the new me-west-1 registry, and additional partition registries). No Python changed. Overall it looks consistent, and I verified the structural refactors are safe. One item is worth confirming before merge.

⚠️ Potential backward-compat regression — sglang 0.5 alias now resolves to a narrower region set

sagemaker-core/.../image_uri_config/sglang.json:7

"version_aliases": { "0.5": "0.5.20" }   // was "0.5": "0.5.18"

The 0.5 alias was moved from 0.5.18 to 0.5.20, but the two versions do not cover the same regions:

• 0.5.18 registries include cn-north-1/cn-northwest-1, us-gov-east-1/us-gov-west-1, us-iso-east-1, us-isob-east-1, us-isof-east-1, us-isof-south-1, eu-isoe-west-1, and eusc-de-east-1.
• 0.5.20 (and 0.5.13–0.5.19) only list commercial regions.

So a caller in a GovCloud/ISO/China/EUSC partition that previously resolved version="0.5" → 0.5.18 will now resolve to 0.5.20 and hit an "unsupported region" error. If the newer 0.5.x images genuinely aren't published to those partitions yet, consider keeping the 0.5 alias pointed at a version that still covers them (or add the partition registries to 0.5.20). Please confirm this narrowing is intentional.

Note — newest versions cover fewer partitions than older ones

Same pattern in a couple of other files, e.g. vllm.json 0.29.0 omits the us-gov-* / us-iso* / eusc-de-east-1 / eu-isoe-west-1 registries that 0.28.0 and 0.27.1 include; vllm-omni.json 1.7 and vllm-server.json 2.1/2.2 similarly. This is fine if it reflects staged image publishing (brand-new versions not yet in every partition), and unlike the sglang case above no existing alias is being repointed. Flagging only so it's a deliberate choice rather than an accidental copy omission.

Minor — missing trailing newline at EOF

Several files now end without a trailing newline (\ No newline at end of file in the diff): llama-cpp-arm64.json, llama-cpp.json, pytorch-amzn2023.json, ray-serve.json, sglang-server.json, sglang.json, vllm-omni.json, vllm-server.json, vllm.json, whisperx.json. If the repo runs a pre-commit end-of-file-fixer/lint hook this may fail CI — worth restoring the newline.

Verified OK

• llama-cpp-arm64.json refactor is behavior-preserving. The old "1" used tag_prefix: "server-sagemaker-cpu-v1" with no container_version; the new form uses tag_prefix: "server-sagemaker" + container_version.cpu: "cpu-v1" + processor_in_tag: false. Per image_uris.py:288 / _format_tag (image_uris.py:650), with processor_in_tag: false the tag becomes tag_prefix-container_version = server-sagemaker-cpu-v1, identical to before. Same holds for "1.0". llama-cpp.json, ray-serve.json, sglang-server.json, vllm-*.json, whisperx.json apply the same equivalent restructuring.
• huggingface-llm.json changes are cosmetic reordering (moving container_version/tag_prefix fields) plus the me-west-1 registry — no semantic change; the version_aliases reorder of 3.1/3.2 is also cosmetic.
• me-west-1 (124382933778) is added consistently across all affected version blocks.

Tests

Config-only change, so no new unit tests are strictly required. If there's a test that enumerates versions × regions and asserts resolvability, double-check it still passes given the alias move above.
· branch master-rba-v3