AWS führt SOCI-Lazy-Loading ein: SageMaker-AI-Jobs starten statt nach Minuten nach Sekunden

Das Problem: Image-Downloads als kostenpflichtiger Overhead

Trainings- und Verarbeitungsjobs in SageMaker AI laufen in Container-Images, die in Amazon Elastic Container Registry (Amazon ECR) liegen. Bevor ein Job Nutzercode ausführen kann, lädt der Dienst das gesamte Image auf die Instanz, entpackt es und schreibt jede Schicht auf die Festplatte.

Bei kleinen Images dauert das nur Sekunden. AWS weist darauf hin, dass Deep-Learning-Images regelmäßig mehr als 10 GB groß sind und der Download dann jedem Job Minuten hinzufügt, die Kunden als Jobzeit bezahlen. Am stärksten spürbar ist das laut AWS bei Hyperparameter-Tuning mit Hunderten Jobs, bei schnellen Experimenten und kurzen Verarbeitungsjobs, wo der Image-Download die Gesamtlaufzeit dominieren kann.

So funktioniert die SOCI-Indexierung

SOCI ist eine Open-Source-Technologie zum Lazy Loading von Container-Images. Statt zuerst das ganze Image abzurufen, nutzt die Laufzeitumgebung einen SOCI-Index, um nur die Dateien zu holen, die zum Start des Containers nötig sind. Den Rest streamt sie im Hintergrund nach, sobald der Code darauf zugreift.

Der Index besteht aus Metadaten, die jede Datei im Image abbilden. Er wird in Amazon ECR als OCI-konformes Artefakt gespeichert und mit dem Original-Image verknüpft. Da es ein separates Artefakt ist, bleiben laut AWS der Image-Digest und bestehende Signaturen gültig.

SageMaker AI prüft automatisch, ob für das angegebene Image ein Index existiert:

• Index vorhanden: Das Image wird per Lazy Loading geladen, der Container startet, bevor der vollständige Download abgeschlossen ist.
• Kein Index: Standard-Download, am Verhalten ändert sich nichts.
• Index nicht lesbar oder Lazy Loading schlägt fehl: Der Job weicht auf einen Standard-Download aus und läuft weiter.

Laut AWS sorgt dieser Fallback dafür, dass ein hinzugefügter Index nie verhindert, dass ein Job läuft. Änderungen an Jobdefinition, Entry Point oder Datenkanälen seien nicht nötig.

Was AWS gemessen hat

AWS verglich Standard-Downloads mit SOCI-Lazy-Loading bei echten SageMaker-AI-Trainingsjobs. Der Aufbau umfasste acht Images zwischen 1,8 und 35,4 GB (komprimiert) auf GPU- und CPU-Instanzen, darunter ml.g4dn, ml.g5, ml.g6, ml.g6e, ml.g7, ml.g7e, ml.p4d, ml.p5 und ml.m7i, in US West (Oregon) und US East (N. Virginia). Alle Werte sind Mediane wiederholter Durchläufe.

• 1,8-GB-Image: 48 s im Standardverfahren, 3 bis 11 s mit Lazy Loading, etwa 8-mal schneller.
• 13,2-GB-Image: 3 min 42 s im Standardverfahren, rund 6 s mit Lazy Loading, etwa 34-mal schneller.
• 35,4-GB-Image: 7 min 17 s im Standardverfahren, 3 bis 11 s mit Lazy Loading, etwa 38-mal schneller.

Lazy Loading blieb unabhängig von der Größe bei 3 bis 11 Sekunden. Beim 13,2-GB-Image, das auf 13 Kombinationen aus Instanztyp und -größe getestet wurde, lag der Standard-Download zwischen 3 min 16 s und 4 min 20 s, während Lazy Loading konstant bei 6 bis 8 s blieb.

AWS ließ außerdem vollständige Trainingsjobs laufen: ResNet-50-Bildklassifikation auf Imagenette mit PyTorch- und TensorFlow-DLCs sowie vollständiges überwachtes Fine-Tuning von Qwen2.5-0.5B auf alpaca-cleaned. Ab der zweiten Epoche war die Zeit pro Epoche im Rahmen der Schwankungen zwischen den Läufen identisch. Die erste Epoche dauerte mit dem per Lazy Loading geladenen Image 3 bis 16 s länger, weil Dateien erstmals abgerufen wurden. Unterm Strich waren die Jobs laut AWS 1 bis 6 min früher fertig.

Wo der Vorteil schrumpft und wie der Einstieg gelingt

AWS weist darauf hin, dass die Ergebnisse vom Workload abhängen. Lazy Loading hilft am meisten, wenn der erste Trainingsschritt nur einen Bruchteil des Images benötigt. Liest ein Entry Point vor dem Training den Großteil des Images, etwa durch Scannen oder Vorladen von Inhalten, fällt die Netto-Verbesserung gering aus. In AWS-Tests kosteten torch.compile und eine per Just-in-Time gebaute CUDA-Erweiterung 7 bis 15 s in der ersten Epoche, die Netto-Ersparnis lag dennoch zwischen 3 min 25 s und 3 min 56 s. Ein im Image eingebettetes 6-GB-Modell verlängerte die Ladezeit um 2 bis 3,5 min, der Job war trotzdem 2 bis 2,5 min früher fertig.

Es gibt zwei Wege, die Funktion zu nutzen. AWS veröffentlicht SOCI-indexierte Varianten mehrerer Deep Learning Containers, erkennbar am Suffix -soci im Image-Tag. Sie sind für PyTorch Training, TensorFlow Training, vLLM und SGLang verfügbar, für einige Frameworks auch als arm64-Varianten. Nutzer passen dazu den Image-Tag in der Jobdefinition an. Alternativ können sie einen Index für ihr eigenes Custom-Image erstellen.

Eine Einschränkung: Ein Image, das per FROM auf einer DLC-Basis aufbaut, braucht einen eigenen Index, da der Index des Basis-Images nicht auf abgeleitete Images übergeht.

Was das für Teams bedeutet

Für Teams, die viele kurze Jobs ausführen, ist die Ersparnis ein fester Betrag pro Job und summiert sich daher bei Tuning-Sweeps und schnellen Experimenten. Da die Umstellung nur ein geänderter Tag oder ein zusätzlicher Index ist und Jobs bei Bedarf auf einen Standard-Download zurückfallen, positioniert AWS die Funktion als risikoarme Option. Teams sollten sie mit den eigenen Workloads testen, denn die Kosten in der ersten Epoche hängen davon ab, worauf ihr Code beim Start zugreift.