SageMaker AI unterstützt SOCI-indizierte Images: verzögert geladene Trainingscontainer, laut AWS bis zu 90 Prozent weniger GPU-Leerlauf beim Image-Laden

Published 2026-10-29 · AI Daily — AI-assisted deep research, methodology & disclosure

Am 29. Oktober 2026 hat AWS angekündigt, dass Trainings- und Verarbeitungsjobs von Amazon SageMaker AI nun SOCI-indizierte (Seekable OCI) Container-Images unterstützen. Nach Angaben von AWS starten Trainingscontainer damit in Sekunden, und die GPU-Leerlaufzeit beim Laden des Images sinkt um bis zu 90 Prozent, ohne die Trainingsleistung zu beeinträchtigen, abgesehen von einem einmaligen Aufwand in der ersten Epoche. Die 90 Prozent sind ein „bis zu“-Wert aus AWS’ eigenen Benchmarks, keine Zusage für jeden Job.

Das Problem liegt vor dem Job. SageMaker AI lädt zuerst das gesamte Container-Image auf die Instanz, entpackt es und schreibt jede Schicht. Deep-Learning-Images überschreiten häufig 10 GB, das kostet bei jedem Job Minuten, und diese Zeit wird berechnet. Am stärksten trifft es Hyperparameter-Suchen mit Hunderten Jobs, schnelle Experimente und kurze Verarbeitungsjobs, bei denen der Download die Gesamtlaufzeit dominieren kann.

SOCI ist eine quelloffene Technik für verzögertes Laden. Ein SOCI-Index sind Metadaten, die jede Datei im Image abbilden. Er liegt in Amazon ECR als OCI-konformes Artefakt, das mit dem ursprünglichen Image verknüpft ist, sodass der Image-Digest und vorhandene Signaturen gültig bleiben. Hat das Image eines Jobs einen Index, holt SageMaker AI nur die zum Start des Containers nötigen Dateien und streamt den Rest im Hintergrund, während der Code läuft. Der Dienst prüft automatisch, ob ein Index vorhanden ist: Mit Index wird verzögert geladen, ohne Index wie bisher heruntergeladen, und lässt sich der Index nicht lesen oder scheitert das verzögerte Laden, fällt der Job auf einen normalen Download zurück und läuft weiter. Ein Index kann einen Job also nicht am Start hindern.

Es gibt zwei Wege zur Einführung. Der erste nutzt einen bereits indizierten AWS Deep Learning Container, indem man das Image-Tag auf die -soci-Variante ändert; der Launch-Blog von AWS nennt PyTorch Training, TensorFlow Training, vLLM und SGLang, für einige Frameworks mit arm64-Varianten. Der zweite fügt dem eigenen Image einen Index hinzu, wofür ein Linux-Host mit containerd, dem SOCI-Snapshotter und Finch oder nerdctl nötig ist, ohne das Image neu zu bauen. Jobdefinitionen, Einstiegspunkte und Datenkanäle bleiben unverändert. Zwei Bedingungen zählen: Ein Image, das FROM einem Deep Learning Container gebaut wird, braucht einen eigenen Index, weil der Index des Basis-Images nicht übernommen wird, und das Image muss in einem privaten ECR-Repository liegen. Die Funktion ist in allen Regionen verfügbar, in denen SageMaker AI verfügbar ist, über die APIs, CLIs, SDKs und die Konsole.

Der Launch-Blog berichtet AWS’ eigene Messungen. Die Tests nutzten acht Images von 1,8 bis 35,4 GB komprimiert, auf Instanztypen von ml.g4dn bis ml.p5, in den Regionen USA West (Oregon) und USA Ost (Nord-Virginia), mit Medianwerten wiederholter Läufe. Ein 1,8-GB-Image sank von 48 Sekunden auf 3 bis 11 Sekunden, ein 13,2-GB-Image von 3 Minuten 42 Sekunden auf etwa 6 Sekunden, ein 35,4-GB-Image von 7 Minuten 17 Sekunden auf 3 bis 11 Sekunden. Dasselbe 13,2-GB-Image brauchte über 13 Instanztypen und -größen mit normalem Download 3 Minuten 16 Sekunden bis 4 Minuten 20 Sekunden und mit verzögertem Laden 6 bis 8 Sekunden. Die Zusammenfassungen des Blogs nennen den Beschleunigungsfaktor uneinheitlich, etwa 10-fach, 8-fach und 8- bis 46-fach, während die Tabelle von etwa 8-fach bis etwa 38-fach reicht; man sollte sich an die Sekunden halten.

Das Training selbst hat einmalige Kosten. AWS verglich ResNet-50 auf Imagenette (9.469 Bilder) und das vollständige Feintuning von Qwen2.5-0.5B mit 51.760 Beispielen. Ab der zweiten Epoche war die Epochendauer gleich, die erste dauerte 3 bis 16 Sekunden länger, während erstmals berührte Dateien geholt wurden, und jeder Job war insgesamt etwa 1 bis 6 Minuten früher fertig. Liest der Einstiegspunkt vor dem Training den Großteil des Images, etwa zum Scannen, Prüfsummenbilden oder Vorladen, schrumpft der Gewinn. In AWS’ Tests verlängerten torch.compile und eine just-in-time gebaute CUDA-Erweiterung die erste Epoche um 7 bis 15 Sekunden, und ein ins Image eingebautes 6-GB-Modell kostete 2 bis 3,5 Minuten, wenn seine Gewichte beim Laden gestreamt wurden, der Job war dennoch 2 bis 2,5 Minuten früher fertig.

Das sind AWS-Messungen an zwei Arten von Workloads. Die Kosten der ersten Epoche hängen vom Image und davon ab, was der Code beim Start berührt, also sollte man an den eigenen Jobs messen.

Sources

FAQ

Was ändert ein SOCI-indiziertes Image, und was bedeutet „bis zu 90 Prozent“?

Ein Job wartet nicht mehr auf den Download des ganzen Images. Er holt nur die zum Start des Containers nötigen Dateien und streamt den Rest im Hintergrund. Die 90 Prozent sind ein „bis zu“-Rückgang der GPU-Leerlaufzeit beim Image-Laden in AWS’ Benchmarks, kein Versprechen für jeden Job, und die Trainingsleistung bleibt bis auf einen einmaligen Aufwand in der ersten Epoche gleich.

Wie führt man es ein, Schritt für Schritt?

Erstens das Image in einem privaten ECR-Repository halten. Zweitens entweder auf ein AWS-Deep-Learning-Container-Tag mit Endung -soci wechseln oder das eigene Image auf einem Linux-Host mit containerd, SOCI-Snapshotter und Finch oder nerdctl indizieren. Drittens das Image im Job referenzieren, ohne die Jobdefinition zu ändern.

Welche Kosten und Grenzen hat es?

In AWS’ Tests dauerte die erste Epoche 3 bis 16 Sekunden länger, und jeder Job war insgesamt trotzdem etwa 1 bis 6 Minuten früher fertig. Der Gewinn schrumpft, wenn der Einstiegspunkt vor dem Training den Großteil des Images liest, und ein auf einem Deep Learning Container aufbauendes Image braucht einen eigenen Index. Es sind nur zwei Workloads, also an eigenen Jobs messen.