Announcing SOCI-indexed images for faster SageMaker AI jobs
Seekable OCI (SOCI) indexing for Amazon SageMaker AI training and processing jobs takes full container image download off the critical path. SageMaker AI lazy-loads your image to start containers in seconds instead of minutes, with no changes to your job definition. See the benchmarks and how to ado
Jede Minute, die Ihr Deep-Learning-Container-Image mit dem Herunterladen verbringt, ist eine Minute, für die Sie zahlen, und eine Minute, in der Ihr Team wartet. Der Download von Container-Images ist reiner Overhead: abrechenbare Jobzeit, die keinen Fortschritt beim Modelltraining bringt. Bei modernen Deep-Learning-Images beläuft sich dieser Overhead auf mehrere Minuten bei jedem einzelnen Job. Heute freuen wir uns, die Seekable-OCI-Indexierung (SOCI) für Amazon SageMaker AI Training und Amazon SageMaker AI Processing Jobs ankündigen zu können, die den vollständigen Container-Image-Download aus dem kritischen Pfad jedes Jobs nimmt.
Mit der SOCI-Indexierung lädt SageMaker AI Ihr Container-Image lazy. Es ruft nur die Dateien ab, die zum Starten des Containers benötigt werden, und streamt den Rest im Hintergrund, während Ihr Code ausgeführt wird, sodass Ihr Job in Sekunden statt in Minuten beginnt. Die Einführung erfolgt, indem Sie auf einen vorindizierten AWS Deep Learning Container (DLC) verweisen oder Ihrem eigenen Image einen Index hinzufügen. Keiner der beiden Ansätze erfordert Änderungen an Ihrer Job-Definition, Ihrem Entry Point oder Ihren Datenkanälen. Das Ergebnis sind schnellere Jobstarts, niedrigere Jobkosten und mehr Zeit für den Aufbau von Modellen statt für das Warten auf die Infrastruktur.
Mit SOCI indizierte Images starten Amazon SageMaker AI Training Container in Sekunden, ohne Auswirkungen auf die Trainingsleistung. Wie wir im Abschnitt „Was wir gemessen haben“ zeigen, wurde die GPU-Leerlaufzeit beim Image-Pull in unseren Benchmarks um bis zu 90 Prozent reduziert.
Dieser Beitrag zeigt, wie Sie die SOCI-Indexierung übernehmen können: was sie ist, welche Ergebnisse wir gemessen haben und wie Sie sie für Ihre eigenen Jobs aktivieren.
SageMaker AI Training- und Processing-Jobs werden in Container-Images ausgeführt, die in Amazon Elastic Container Registry (Amazon ECR) gespeichert sind. Bevor ein Job Ihren Code ausführen kann, lädt der Service das gesamte Image auf die Instanz herunter. Dabei wird jede Ebene dekomprimiert und auf die Festplatte geschrieben.
Bei kleinen Images dauert dies nur Sekunden. Deep-Learning-Images übersteigen jedoch regelmäßig 10 GB oder mehr. Dieser Download fügt jedem Job Minuten hinzu, und Sie zahlen dafür als Jobzeit. Die Auswirkung ist genau dort am größten, wo die Iterationsgeschwindigkeit am wichtigsten ist: bei Hyperparameter-Tuning-Sweeps mit hunderten von Jobs, schnellen Experimenten und kurzen Processing-Jobs, bei denen der Image-Download die gesamte Laufzeit dominieren kann.
Seekable OCI (SOCI) ist eine Open-Source-Technologie, die Container-Images lazy lädt. Statt das gesamte Image vor dem Start herunterzuladen, verwendet die Laufzeitumgebung einen SOCI-Index, um nur die Dateien abzurufen, die zum sofortigen Starten des Containers benötigt werden. Anschließend streamt sie den Rest im Hintergrund, während Ihr Code darauf zugreift.
Ein SOCI-Index ist Metadaten, die jede Datei in Ihrem Image abbilden. Sie speichern ihn in Amazon ECR als OCI-konformes Artefakt, das mit Ihrem ursprünglichen Image verknüpft ist. Da der Index ein separates Artefakt ist, bleiben Ihr Image-Digest und vorhandene Signaturen gültig.
Wenn Sie einen Trainings- oder Processing-Job erstellen, prüft SageMaker AI, ob das von Ihnen angegebene Image einen SOCI-Index hat, und verhält sich entsprechend:
Da Jobs bei Bedarf stets auf einen Standard-Download zurückfallen, verhindert das Hinzufügen eines SOCI-Index niemals die Ausführung Ihres Jobs. Sie profitieren nur von einem schnelleren Start. Sie riskieren niemals, einen bestehenden Workflow zu beschädigen.
Wir haben dieselben Container-Images auf zwei Arten bei echten SageMaker AI Trainingsjobs heruntergeladen: mit Standard-Download und mit SOCI-indiziertem Lazy Loading. Anschließend führten wir vollständige Trainingsjobs mit beiden Varianten durch, um die Auswirkung auf die Trainingsgeschwindigkeit zu messen.
Das folgende Diagramm vergleicht die Container-Image-Downloadzeit eines standardmäßigen Docker-Pulls mit SOCI Lazy Loading über acht Image-Größen hinweg, von 1,8 GB bis 35,4 GB.
Bei jeder Image-Größe werden zwei Balken angezeigt. Der Balken für die Docker-Downloadzeit (blau) wächst stetig mit der Image-Größe, von 48 Sekunden bei 1,8 GB bis zu 7 Minuten und 17 Sekunden bei 35,4 GB.
Ein Beschleunigungs-Label über jedem Balkenpaar zeigt das Verhältnis von Docker-Zeit zu SOCI-Zeit. Die Beschleunigungen reichen von etwa 10x beim kleinsten Image bis zu über 35x beim größten.
Abbildung 1: Container-Image-Downloadzeit, standardmäßiger Docker-Pull im Vergleich zu SOCI Lazy Loading, über acht Image-Größen
Die Standard-Downloadzeit wächst mit der Image-Größe, weil jede Datei dekomprimiert und geschrieben wird. Lazy Loading blieb unabhängig von der Größe bei 3 bis 11 Sekunden, eine Verbesserung um das 8- bis 46-fache. Je größer das Image, desto mehr Minuten sparen Sie.
Beim Ausführen des 13,2-GB-Images über 13 Instanztyp- und Instanzgrößen-Kombinationen hinweg lag der Standard-Download zwischen 3 Minuten 16 Sekunden und 4 Minuten 20 Sekunden, während Lazy Loading bei 6 bis 8 Sekunden blieb. Das ist auf jeder Konfiguration etwa 34x schneller. Sie müssen weder Instanztyp noch Instanzgröße ändern, um davon zu profitieren.
Abbildung 2: Downloadzeit eines 13,2-GB-Images über 13 Instanztyp- und Instanzgrößen-Kombinationen
Wir haben zwei Arten vollständiger Trainingsjobs ausgeführt, jeweils mit dem per Docker-Pull geladenen und mit dem SOCI-indizierten Image, und jede Epoche verglichen:
Das folgende Diagramm zerlegt den Jobstart in Image-Downloadzeit und erste Trainings-Epoche und vergleicht einen standardmäßigen Docker-Pull mit einem SOCI-indizierten Image über GPU- und CPU-Konfigurationen für beide Workloads hinweg.
Abbildung 3: Jobstart aufgeteilt in Image-Downloadzeit und erste Trainings-Epoche, standardmäßiger Docker-Pull im Vergleich zu einem SOCI-indizierten Image
Diese Zahlen stammen aus den zuvor beschriebenen beiden Workloads. Die Kosten der ersten Epoche hängen von Ihrem Image und davon ab, worauf Ihr Code beim Start zugreift:
Sie können die SOCI-Indexierung auf zwei Arten übernehmen: einen vorindizierten AWS Deep Learning Container verwenden oder einen Index für Ihr eigenes benutzerdefiniertes Image erstellen.
AWS veröffentlicht SOCI-indizierte Varianten mehrerer beliebter Deep Learning Containers, erkennbar am Suffix -soci im Image-Tag:
763104351884.dkr.ecr.us-east-1.amazonaws.com/pytorch-training:2.9-gpu-py312-cu130-ubuntu22.04-sagemaker-v1-soci Vorindizierte Varianten sind für PyTorch Training, TensorFlow Training, vLLM und SGLang verfügbar, darunter arm64-Varianten für einige Frameworks. Um Lazy Loading zu übernehmen, aktualisieren Sie das Image-Tag in Ihrer Job-Definition auf die -soci-Variante. Die vollständige Liste finden Sie in der AWS Deep Learning Containers Gallery.
Hinweis: Wenn Sie Ihr eigenes Image auf Basis eines DLC-Images erstellen, müssen Sie einen SOCI-Index für Ihr finales Image erstellen. Der Index des Basis-Images wird nicht auf abgeleitete Images übertragen.
Um ein benutzerdefiniertes Image zu indizieren, benötigen Sie einen Linux-Host (z. B. eine Amazon Elastic Compute Cloud (Amazon EC2) Instanz mit Amazon Linux 2023) mit containerd, dem SOCI Snapshotter sowie Finch oder nerdctl.
ACCOUNT_ID="111122223333" REGION="us-east-1" REPOSITORY_NAME="my-training-image" ORIGINAL_IMAGE_TAG="v1.0" SOCI_IMAGE_TAG="v1.0-soci" REGISTRY="$ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com" Installieren Sie die erforderlichen Tools. sudo dnf install -y containerd fuse soci-snapshotter runfinch-finch sudo systemctl start soci-snapshotter sudo systemctl restart containerd Authentifizieren Sie sich bei Amazon ECR. aws ecr get-login-password --region "$REGION" \ | sudo nerdctl login -u AWS --password-stdin "$REGISTRY" Laden Sie Ihr ursprüngliches Image herunter. sudo nerdctl pull "$REGISTRY/$REPOSITORY_NAME:$ORIGINAL_IMAGE_TAG" Erstellen Sie das SOCI-indizierte Image. sudo nerdctl image convert --soci \ "$REGISTRY/$REPOSITORY_NAME:$ORIGINAL_IMAGE_TAG" \ "$REGISTRY/$REPOSITORY_NAME:$SOCI_IMAGE_TAG" Laden Sie das indizierte Image hoch. sudo nerdctl push --platform linux/amd64 \ "$REGISTRY/$REPOSITORY_NAME:$SOCI_IMAGE_TAG" Dies erzeugt zwei Artefakte in Ihrem Repository: den SOCI-Index und ein OCI-konformes Image-Index-Manifest, das Ihr Image mit dem Index verknüpft. Ihr ursprüngliches Image und sein Digest bleiben unverändert.
Um Indizes automatisch bei jedem Push zu generieren, setzen Sie den CFN ECR SOCI Index Builder ein. Er verwendet eine Amazon EventBridge Regel, um Push-Ereignisse von Amazon ECR Images zu erkennen und den Index zu erstellen. Es sind keine Änderungen an Ihrer Build-Pipeline erforderlich.
Verweisen Sie auf Ihr SOCI-indiziertes Image genau so, wie Sie es bei jedem anderen Image tun würden. Es sind keine API-Änderungen erforderlich. Nur das Tag ist anders.
from sagemaker.train import ModelTrainer from sagemaker.train.configs import Compute trainer = ModelTrainer( training_image="111122223333.dkr.ecr.us-east-1.amazonaws.com/my-training-image:v1.0-soci", role="arn:aws:iam::111122223333:role/SageMakerExecutionRole", compute=Compute( instance_type="ml.g5.12xlarge", instance_count=2, ), ) trainer.train() Prüfen Sie, ob Ihr Image einen SOCI-Index enthält Bestätigen Sie vor dem Start, dass Ihr Tag zu einem indizierten Image auflöst:
aws ecr batch-get-image \ --repository-name "$REPOSITORY_NAME" \ --image-ids imageTag="$SOCI_IMAGE_TAG" \ --accepted-media-types \ "application/vnd.oci.image.index.v1+json" \ --query 'images.imageManifest' --output text \ | jq '.manifests[] | {mediaType, artifactType}' Suchen Sie nach einem Child-Manifest, dessen artifactType mit application/vnd.amazon.soci.index beginnt, neben Ihrem Plattform-Manifest. Wenn es nicht vorhanden ist, verweist das Tag nicht auf ein indiziertes Image.
Mit der SOCI-Indexierung können Sie die Container-Image-Downloadzeit Ihrer SageMaker AI Trainings- und Processing-Jobs minimieren. Fügen Sie Ihren Images einen SOCI-Index hinzu oder wechseln Sie zu einem vorindizierten AWS Deep Learning Container. In beiden Fällen verkürzen Sie die Startzeit von Minuten auf Sekunden, senken die Gesamtkosten des Jobs und beschleunigen Ihren Machine-Learning-Iterationszyklus. Ihre bestehenden Job-Definitionen, API-Aufrufe und Datenpipelines bleiben dabei genau unverändert.
Um mehr über Amazon SageMaker AI zu erfahren und die SOCI-Indexierung zu nutzen, erkunden Sie die folgenden Ressourcen:
Ein schnellerer Container-Start ist nur ein Image-Tag entfernt. Probieren Sie es bei Ihrem nächsten SageMaker AI Job aus und sehen Sie den Unterschied.
Kanwaljit ist Senior Manager für Solutions Architecture und Data Science bei Amazon Web Services mit dem Schwerpunkt KI und ML. Er arbeitet mit AWS-Produktteams, Engineering und Kunden zusammen und bietet Beratung und technische Unterstützung an, um den Mehrwert ihrer hybriden GenAI-Lösungen auf AWS maximal auszuschöpfen. Kanwaljit ist spezialisiert auf die Unterstützung von Kunden bei containerisierten Anwendungen sowie bei Data-Science- und Machine-Learning-Projekten.
Mona arbeitet derzeit als Senior AI/ML Specialist Solutions Architect bei Amazon. Sie ist Autorin von drei veröffentlichten Büchern, ihr jüngstes Buch trägt den Titel AI Agents on AWS. Sie hat mehr als 20 Blogs zu AI/ML und Cloud-Technologie verfasst und ist Co-Autorin einer Forschungsarbeit zu CORD19 Neural Search, die auf der renommierten AAAI-Konferenz (Association for the Advancement of Artificial Intelligence) mit dem Preis für die beste Forschungsarbeit ausgezeichnet wurde.
Michael ist Product Manager für Amazon SageMaker AI. Er wird von der Anwendung von Technologie und KI zur Lösung realer Probleme angetrieben. Bei AWS hilft er Kunden aus verschiedenen Branchen, AI/ML-Modelle im großen Maßstab zu entwickeln, zu trainieren und bereitzustellen. Vor seiner Zeit bei AWS entwarf und betrieb Michael Offshore-Bohranlagen und -Einrichtungen für Öl und Gas. In seiner Freizeit beschäftigt er sich gerne über Bücher und Podcasts mit Verhaltensforschung und Psychologie.
Deep ist Software Development Engineer im Amazon-SageMaker-Team, wo er an der Infrastruktur arbeitet, die das Modelltraining auf AWS ermöglicht. Wenn er gerade keine Trainingssysteme skaliert, genießt er Sim Racing, Lesen und Reisen.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Every minute your deep learning container image spends downloading is a minute you pay for and a minute your team waits. Container image download is pure overhead: billable job time that produces no model progress. For modern deep learning images, that overhead is several minutes on every single job. Today, we’re excited to announce Seekable OCI (SOCI) indexing for Amazon SageMaker AI Training and Amazon SageMaker AI processing jobs, which takes full container image download off the critical path of every job.
With SOCI indexing, SageMaker AI lazy-loads your container image. It fetches only the files needed to start the container and streams the rest in the background as your code runs, so your job begins in seconds instead of minutes. You adopt it by pointing to a pre-indexed AWS Deep Learning Container (DLC) or adding an index to your own image. Neither approach requires changes to your job definition, entry point, or data channels. The result is faster job starts, lower job cost, and more time spent building models rather than waiting on infrastructure.
SOCI-indexed images start Amazon SageMaker AI training containers in seconds, with no impact on training performance. As we show in the What we measured section, this reduced GPU idle time during image pulls by up to 90 percent in our benchmarks.
This post shows how to adopt SOCI indexing: what it is, the results we measured, and how to turn it on for your own jobs.
SageMaker AI training and processing jobs run inside container images stored in Amazon Elastic Container Registry (Amazon ECR). Before a job can execute your code, the service downloads the entire image to the instance. It decompresses and writes every layer to disk.
For small images this takes seconds. But deep learning images routinely exceed 10 GB or more. That download adds minutes to every job, and you pay for it as job time. The impact is largest exactly where iteration speed matters most: hyperparameter tuning sweeps for hundreds of jobs, quick experiments, and short processing jobs, where image download can dominate total runtime.
Seekable OCI (SOCI) is an open source technology that lazy loads container images. Instead of downloading the whole image before starting, the runtime uses a SOCI index to fetch only the files needed to launch the container immediately. It then streams the rest in the background as your code accesses it.
A SOCI index is metadata that maps every file inside your image. You store it in Amazon ECR as an OCI-compliant artifact linked to your original image. Because the index is a separate artifact, your image digest and any existing signatures remain valid.
When you create a training or processing job, SageMaker AI checks whether the image you specified has a SOCI index and behaves accordingly:
Because jobs always fall back to a standard download when needed, adding a SOCI index never prevents your job from running. You only gain faster startup. You never risk breaking an existing workflow.
We pulled the same container images two ways on real SageMaker AI training jobs: standard download and SOCI-indexed lazy loading. We then ran full training jobs from both to measure the effect on training speed.
The following chart compares container image download time for a standard Docker pull against SOCI lazy loading across eight image sizes, from 1.8 GB to 35.4 GB.
Each image size shows two bars. The Docker download time bar (blue) grows steadily with image size, from 48 seconds at 1.8 GB to 7 minutes 17 seconds at 35.4 GB.
A speedup label above each pair shows the ratio of Docker time to SOCI time. Speedups range from approximately 10x for the smallest image to over 35x for the largest.
Figure 1: Container image download time, standard Docker pull compared to SOCI lazy loading, across eight image sizes
Standard download time grows with image size because every file is decompressed and written. Lazy loading stayed at 3–11 seconds regardless of size, an 8x–46x improvement. The bigger the image, the more minutes you save.
Running the 13.2 GB image across 13 instance type/size combinations, standard download ranged from 3 min 16 s to 4 min 20 s, while lazy loading held at 6-8 s. That is about 34x faster on every configuration. You don’t need to change instance type or size to benefit.
Figure 2: Download time for a 13.2 GB image across 13 instance type and size combinations
We ran two kinds of full training jobs from the Docker-pulled and from the SOCI-indexed image and compared every epoch:
The following chart breaks job startup into image download time and first training epoch time, comparing a standard Docker pull with a SOCI-indexed image across GPU and CPU configurations for both workloads.
Figure 3: Job startup split into image download time and first training epoch time, standard Docker pull compared to a SOCI-indexed image
These numbers are from the two workloads described earlier. The first-epoch cost depends on your image and what your code touches at startup:
You can adopt SOCI indexing two ways: use a pre-indexed AWS Deep Learning Container or create an index for your own custom image.
AWS publishes SOCI-indexed variants of several popular Deep Learning Containers, identified by the -soci suffix on the image tag:
763104351884.dkr.ecr.us-east-1.amazonaws.com/pytorch-training:2.9-gpu-py312-cu130-ubuntu22.04-sagemaker-v1-soci Pre-indexed variants are available for PyTorch Training, TensorFlow Training, vLLM, and SGLang, including arm64 variants for some frameworks. To adopt lazy loading, update the image tag in your job definition to the -soci variant. Browse the full list in the AWS Deep Learning Containers Gallery.
Note: If you build your own image FROM a DLC base image, you must create a SOCI index for your final image. The index from the base image does not carry forward to derived images.
To index a custom image, you need a Linux host (such as an Amazon Elastic Compute Cloud (Amazon EC2) instance running Amazon Linux 2023) with containerd, the SOCI snapshotter, and either Finch or nerdctl installed.
ACCOUNT_ID="111122223333" REGION="us-east-1" REPOSITORY_NAME="my-training-image" ORIGINAL_IMAGE_TAG="v1.0" SOCI_IMAGE_TAG="v1.0-soci" REGISTRY="$ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com" Install the required tools. sudo dnf install -y containerd fuse soci-snapshotter runfinch-finch sudo systemctl start soci-snapshotter sudo systemctl restart containerd Authenticate to Amazon ECR. aws ecr get-login-password --region "$REGION" \ | sudo nerdctl login -u AWS --password-stdin "$REGISTRY" Pull your original image. sudo nerdctl pull "$REGISTRY/$REPOSITORY_NAME:$ORIGINAL_IMAGE_TAG" Create the SOCI-indexed image. sudo nerdctl image convert --soci \ "$REGISTRY/$REPOSITORY_NAME:$ORIGINAL_IMAGE_TAG" \ "$REGISTRY/$REPOSITORY_NAME:$SOCI_IMAGE_TAG" Push the indexed image. sudo nerdctl push --platform linux/amd64 \ "$REGISTRY/$REPOSITORY_NAME:$SOCI_IMAGE_TAG" This creates two artifacts in your repository: the SOCI index and an OCI-compliant image index manifest linking your image to the index. Your original image and its digest remain unchanged.
To generate indexes automatically on every push, deploy the CFN ECR SOCI Index Builder. It uses an Amazon EventBridge rule to detect Amazon ECR image push events and build the index. No changes to your build pipeline are required.
Reference your SOCI-indexed image exactly as you would any other image. No API changes are needed. Only the tag differs.
from sagemaker.train import ModelTrainer from sagemaker.train.configs import Compute trainer = ModelTrainer( training_image="111122223333.dkr.ecr.us-east-1.amazonaws.com/my-training-image:v1.0-soci", role="arn:aws:iam::111122223333:role/SageMakerExecutionRole", compute=Compute( instance_type="ml.g5.12xlarge", instance_count=2, ), ) trainer.train() Verify that your image includes a SOCI index Before launching, confirm your tag resolves to an indexed image:
aws ecr batch-get-image \ --repository-name "$REPOSITORY_NAME" \ --image-ids imageTag="$SOCI_IMAGE_TAG" \ --accepted-media-types \ "application/vnd.oci.image.index.v1+json" \ --query 'images.imageManifest' --output text \ | jq '.manifests[] | {mediaType, artifactType}' Look for a child manifest whose artifactType begins with application/vnd.amazon.soci.index. alongside your platform manifest. If it isn’t there, the tag does not point to an indexed image.
With SOCI indexing, you can minimize container image download time from your SageMaker AI training and processing jobs. Add a SOCI index to your images, or switch to a pre-indexed AWS Deep Learning Container. Either way, you cut startup time from minutes to seconds, reduce total job cost, and accelerate your machine learning (ML) iteration cycle. And your existing job definitions, API calls, and data pipelines stay exactly the same.
To learn more about Amazon SageMaker AI and start using SOCI indexing, explore the following resources:
Faster container startup is only one image tag away. Try it on your next SageMaker AI job and see the difference.
Kanwaljit is a Senior Manager of Solutions Architecture and Data Scientists at Amazon Web Services, specializing in AI and ML. He collaborates with AWS product teams, engineering, and customers to provide guidance and technical assistance for maximizing the value of their hybrid GenAI solutions on AWS. Kanwaljit specializes in helping customers with containerized, data science, and machine learning applications.
Mona currently works as Sr AI/ML specialist Solutions Architect at Amazon. She is a published author of three books and her latest book is AI Agents on AWS. She has authored 20+ blogs on AI/ML and cloud technology and a co-author on a research paper on CORD19 Neural Search which won an award for Best Research Paper at the prestigious AAAI (Association for the Advancement of Artificial Intelligence) conference.
Michael is a Product Manager for Amazon SageMaker AI. He is driven by the application of technology and AI to solve real-world problems. At AWS, he helps customers across industries build, train, and deploy AI/ML models at scale. Before AWS, Michael designed and operated offshore oil and gas wells and facilities. Outside of work he enjoys exploring behavioral science and psychology through books and podcast.
Deep is a Software Development Engineer on the Amazon SageMaker team, where he works on the infrastructure that powers model training on AWS. When he’s not scaling training systems, he enjoys sim racing, reading, and traveling.