SageMaker Serving Image Selection

Serving Image Selection

The serving container is the single thing most likely to break a SageMaker deployment that "looked correct on paper". Wrong container, stale tag, or the wrong AMI — all produce the same opaque Failed to pass health check error.

Rule zero: HuggingFace images always win

When both a HuggingFace-curated family (huggingface-vllm, huggingface-vllm-omni, huggingface-sglang, tei, huggingface-pytorch-inference) and a generic family (vllm, vllm-omni, sglang, djl-inference) can serve the model, the HuggingFace one is mandatory, not preferred. The only valid reasons to use a generic image:

1. Verified incompatibility — the model needs an architecture/modality/feature no available HuggingFace tag supports, confirmed against the catalog (not assumed).
2. No HuggingFace tag exists in the target region and mirroring is not an option.
3. The HuggingFace image is in "Known-broken images" below.

A newer version number on the generic repo is not a reason. The AWS vllm repo often publishes a higher vLLM version than huggingface-vllm; an older-but-compatible huggingface-vllm tag still wins. "Latest vLLM" is not a requirement anyone stated — compatibility with the model is. If you fall back, record in the deployment log which of the three reasons applied.

Where image URIs come from

Primary source: AWS's official Deep Learning Containers catalog.

URL: https://aws.github.io/deep-learning-containers/reference/available_images/

This page is AWS-maintained and lists every image family with example URIs, tags, CUDA versions, Python versions, and platform (SageMaker vs EC2/ECS/EKS). When picking a URI for a deployment, read it from this page directly — copy the example URL, substitute <region> with the user's region, and pass it to deploy.py --image-uri.

The example URLs use 763104351884 as the account ID for most regions. A few regions use different accounts (e.g. eu-south-1 uses 692866216735). Check the Region Availability page when in doubt.

Exception: none currently. Every image family used by this workflow is now on the AWS catalog page (TEI was added in late 2026). If you encounter a new family that isn't there, mirror it via mirror_image.py and pass the resulting URI directly.

Quick decision

HuggingFace-curated DLCs are mandatory when one is compatible (see "Rule zero"). huggingface-vllm is layered directly on the AWS vLLM DLC — identical SM_VLLM_* env contract and the same cu130 AMI rule — and adds current transformers, current huggingface_hub + hf_xet (avoids the XET-CDN 403 download failures older images hit), and HF performance defaults. It is also what SageMaker SDK v3 auto-routes to. The AWS vllm image is a compatibility escape hatch only; it usually shows a higher vLLM version than huggingface-vllm, and that is not a reason to pick it.

Do not use TGI. Text Generation Inference is archived. Models released after the archive (Qwen3 most famously) fail ping health checks on TGI. Use vLLM instead. (The SageMaker SDK v3 agrees: since PR #5960, June 2026, its ModelBuilder auto-routes text-generation to the HuggingFace vLLM DLC and multimodal tasks to HuggingFace vLLM-Omni.)

Full reasoning for each family in references/model-to-image.md.

Rerankers: TEI or vLLM?

"Reranker" covers two very different architectures, and picking wrong wastes a full endpoint-creation cycle (~20 min) before TEI rejects the model:

• Encoder cross-encoders (BAAI/bge-reranker-*, mixedbread, most sentence-transformers rerankers) — BERT-family models with a classification head. config.json has architectures: [..ForSequenceClassification] on a TEI-supported encoder type. → TEI.
• Generative rerankers (Qwen/Qwen3-Reranker-*, and similar causal-LM judges) — decoder LLMs that score relevance via the logprob of a yes/no token. config.json has architectures: [..ForCausalLM]. → HuggingFace vLLM, deployed exactly like a text-generation LLM. TEI will load the architecture then reject the classifier model type (Qwen3 support in TEI is embeddings-only). Invocation pattern (raw completions API, max_tokens=1, logprobs scoring) is in hf-cloud-sagemaker-production-defaults.

Preflight before creating any resources — one HTTP GET settles it:

curl -s https://huggingface.co/<model-id>/raw/main/config.json
# "architectures": ["Qwen3ForCausalLM"]              → vLLM
# "architectures": ["XLMRobertaForSequenceClassification"] → TEI

For TEI also confirm the (architecture, task) pair: an architecture appearing in TEI's supported list means embeddings support, not necessarily classification/reranking support.

Heads-up: SageMaker SDK v3 (PR #5960) routes the text-ranking task to TEI unconditionally — correct for cross-encoders, wrong for generative rerankers. Don't treat the SDK's routing as evidence that TEI can serve a given reranker.

Workflow

For every family: read the URI from the AWS catalog page.

1. Open https://aws.github.io/deep-learning-containers/reference/available_images/
2. Find the section for the right family (e.g. "HuggingFace vLLM Inference" for HuggingFace LLMs, "HuggingFace Text Embeddings Inference" for embeddings)
3. Pick the newest row marked SageMaker for the platform column — newest within that family. Do not switch to another family's section because it lists a higher engine version (see "Rule zero")
4. Substitute <region> with the user's region (from hf-cloud-aws-context-discovery)
5. For vLLM: also check the AMI requirement (see "vLLM AMI requirement" below)
6. Pass the URI to deploy.py --image-uri (real-time) or deploy_async.py --image-uri (async)

TEI: pick the right variant

The TEI catalog row lists two URIs — GPU (tei repo) and CPU (tei-cpu repo). Pick based on the instance type:

• ml.g*, ml.p*, ml.inf* → GPU variant
• ml.c*, ml.m*, ml.t* → CPU variant

Mixing them fails: CPU image on a GPU instance wastes hardware, GPU image on a CPU instance fails to start.

Note on the TEI account ID: the catalog page shows 683313688378 as the example account, but TEI is published from a different account namespace than the main AWS DLCs and the per-region account IDs vary. If 683313688378.dkr.ecr.<region>.amazonaws.com/tei:... returns an ECR pull error for a region other than us-east-1, check the Region Availability page for the correct account ID for that region.

vLLM AMI requirement

vLLM DLC images with CUDA 13 or higher (current default: cu130) require setting InferenceAmiVersion=al2-ami-sagemaker-inference-gpu-3-1 on the ProductionVariant. This applies equally to huggingface-vllm and huggingface-vllm-omni (layered on the same cu130 base) and to the AWS vllm repo. Without it the container dies on startup with no CloudWatch logs ever created. The failure looks identical to many other things (account-level issues, quota, networking) and routinely sends people down wrong diagnostic paths.

Lookup table:

Rule of thumb: if the vLLM tag you picked contains cu130 or later, pass --inference-ami-version al2-ami-sagemaker-inference-gpu-3-1 to deploy.py. If a future CUDA version (cu140+) needs a different AMI, add a row to the table when AWS publishes the new image.

This is a vLLM-specific concern. TEI and HF Inference Toolkit images don't need an AMI override.

Configuring the vLLM DLCs (HuggingFace vLLM and AWS vLLM)

Both images share the same contract: configuration as environment variables on the SageMaker model definition, SM_VLLM_* mapped to vLLM CLI flags. The huggingface-vllm entrypoint additionally auto-detects the model when SM_VLLM_MODEL is unset — from /opt/ml/model if S3 artifacts are mounted, else from HF_MODEL_ID. For production, point SM_VLLM_MODEL at /opt/ml/model; loading directly from the Hub at runtime is the exception.