Ankündigung: SOCI-indexierte Images für schnellere SageMaker-AI-Jobs

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 Container-Image-Download ist reiner Overhead: abrechenbare Job-Zeit, die keinen Fortschritt beim Modell erzeugt. Bei modernen Deep-Learning-Images beträgt dieser Overhead mehrere Minuten bei jedem einzelnen Job. Heute freuen wir uns, bekannt geben zu können Seekable OCI (SOCI) indexing für Amazon SageMaker AI Training und Amazon SageMaker AI processing jobs, das den vollständigen Container-Image-Download vom kritischen Pfad jedes Jobs nimmt.

Mit SOCI indexing lädt SageMaker AI Ihr Container-Image lazy. Es ruft nur die Dateien ab, die zum Starten des Containers nötig sind, und streamt den Rest im Hintergrund, während Ihr Code läuft, sodass Ihr Job in Sekunden statt Minuten beginnt. Sie übernehmen es, indem Sie auf einen vorindexierten AWS Deep Learning Container (DLC) verweisen oder Ihrem eigenen Image einen Index hinzufügen. Kein Ansatz erfordert Änderungen an Ihrer Job-Definition, Ihrem Einstiegspunkt oder Ihren Datenkanälen. Das Ergebnis sind schnellere Job-Starts, geringere Job-Kosten und mehr Zeit für den Aufbau von Modellen statt für das Warten auf die Infrastruktur.

SOCI-indexierte Images starten Amazon SageMaker AI Training-Container in Sekunden, ohne Auswirkungen auf die Trainingsleistung. Wie wir im Abschnitt What we measured zeigen, reduzierte dies die GPU-Leerlaufzeit bei Image-Pulls in unseren Benchmarks um bis zu 90 Prozent.

Dieser Beitrag zeigt, wie Sie SOCI indexing übernehmen: was es ist, die Ergebnisse, die wir gemessen haben, und wie Sie es für Ihre eigenen Jobs aktivieren.

Die Herausforderung

SageMaker AI Training- und Processing-Jobs laufen in Container-Images, 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. Er dekomprimiert und schreibt jede Schicht auf die Festplatte.

Bei kleinen Images dauert dies Sekunden. Aber Deep-Learning-Images übersteigen regelmäßig 10 GB oder mehr. Dieser Download fügt jedem Job Minuten hinzu, und Sie zahlen dafür als Job-Zeit. Die Auswirkung ist am größten genau dort, wo die Iterationsgeschwindigkeit am wichtigsten ist: Hyperparameter-Tuning-Sweeps mit Hunderten von Jobs, schnelle Experimente und kurze Processing-Jobs, bei denen der Image-Download die Gesamtdauer dominieren kann.

Wie SOCI indexing funktioniert

Seekable OCI (SOCI) ist eine Open-Source-Technologie, die Container-Images lazy lädt. Statt das gesamte Image vor dem Start herunterzuladen, verwendet die Runtime 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 sind Metadaten, die jede Datei in Ihrem Image zuordnen. 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 alle vorhandenen Signaturen gültig.

SageMaker AI prüft automatisch auf einen Index

Wenn Sie einen Training- 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 immer auf einen Standard-Download zurückfallen, verhindert das Hinzufügen eines SOCI index niemals die Ausführung Ihres Jobs. Sie gewinnen nur einen schnelleren Start. Sie riskieren nie, einen bestehenden Workflow zu brechen.

What we measured

Wir haben dieselben Container-Images bei echten SageMaker AI Training-Jobs auf zwei Arten abgerufen: Standard-Download und SOCI-indexiertes lazy loading. Anschließend haben wir aus beiden vollständige Trainingsjobs ausgeführt, um die Auswirkung auf die Trainingsgeschwindigkeit zu messen.

Setup

• Acht Images, 1,8–35,4 GB komprimiert.
• GPU- und CPU-Instances ml.g4dn, ml.g5, ml.g6, ml.g6e, ml.g7, ml.g7e, ml.p4d, ml.p5 und ml.m7i, von xlarge bis 48xlarge, in der Region USA West (Oregon) (us-west-2) und der Region USA Ost (N. Virginia) (us-east-1).
• Downloadzeit gemessen vom Beginn des Image-Pulls bis der Container ausführungsbereit ist. Alle Angaben sind Mediane aus wiederholten Durchläufen.

Ergebnis 1: Die Downloadzeit sinkt bei jeder Imagegröße von Minuten auf Sekunden

Die folgende Grafik vergleicht die Downloadzeit von Container-Images bei einem Standard-Docker-Pull mit SOCI-Lazy-Loading über acht Image-Größen hinweg, von 1,8 GB bis 35,4 GB.

Für jede 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 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: Downloadzeit von Container-Images, Standard-Docker-Pull im Vergleich zu SOCI-Lazy-Loading, über acht Image-Größen hinweg

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–11 Sekunden, eine Verbesserung um den Faktor 8x–46x. Je größer das Image, desto mehr Minuten sparen Sie.

Ergebnis 2: Die Ersparnis gilt auf jedem Instance-Typ und in jeder Größe

Beim Ausführen des 13,2-GB-Images über 13 Instance-Typ-/Größen-Kombinationen hinweg lag der Standard-Download zwischen 3 min 16 s und 4 min 20 s, während Lazy Loading bei 6-8 s blieb. Das ist auf jeder Konfiguration etwa 34x schneller. Sie müssen den Instance-Typ oder die Größe nicht ändern, um davon zu profitieren.

Abbildung 2: Downloadzeit eines 13,2-GB-Images über 13 Instance-Typ- und Größen-Kombinationen hinweg

Ergebnis 3: Die Trainingsleistung ist über eine Strafe in der ersten Epoche hinaus nicht beeinträchtigt

Wir führten zwei Arten vollständiger Trainingsjobs durch – aus dem per Docker gepullten und aus dem SOCI-indizierten Image – und verglichen jede Epoche:

• Bildklassifikation mit ResNet-50 auf Imagenette (9,469 Bilder)
  • Container-Images: PyTorch (13,2-GB-DLC) und TensorFlow (9,9-GB-DLC)
  • Instances: ml.p5.48xlarge, ml.p4d.24xlarge, ml.g7e.48xlarge, ml.g7.48xlarge, ml.g6e.12xlarge, ml.g6e.24xlarge und ml.g6e.48xlarge.
• Fine-Tuning großer Sprachmodelle (LLMs): Full-Parameter-Supervised-Fine-Tuning (SFT) von Qwen2.5-0.5B mit alpaca-cleaned (51,760 Beispiele) mit dem Hugging Face Trainer.
  • Container-Image: 9,4 GB Hugging Face PyTorch DLC.
  • Instanzen: ml.p5.48xlarge, ml.p4d.24xlarge, ml.g6.48xlarge.

Das folgende Diagramm unterteilt den Job-Start in die Zeit für das Image-Download und die Zeit für die erste Trainingsepoche und vergleicht einen Standard-Docker-Pull mit einem SOCI-indizierten Image über GPU- und CPU-Konfigurationen hinweg für beide Workloads.

Abbildung 3: Aufteilung des Job-Starts in Image-Download-Zeit und Zeit für die erste Trainingsepoche, standardmäßiger Docker Pull verglichen mit einem SOCI-indizierten Image

• Ab der zweiten Epoche ist die Zeit pro Epoche auf jeder Instance gleich (innerhalb der Schwankungen zwischen den Durchläufen), bei beiden Workloads.
• Die erste Epoche dauert 3–16 s länger bei dem lazy geladenen Image, während Dateien, die das Framework zum ersten Mal berührt, abgerufen werden. Diese Kosten der ersten Epoche sind auf jeder Instance-Größe gleich.
• Ergebnis: Jeder Job wurde 1-6 min früher abgeschlossen. Das ist die Download-Ersparnis minus den einmaligen Kosten der ersten Epoche, eine feste Ersparnis pro Job.

Testen Sie dies mit Ihrer eigenen Workload

Diese Zahlen stammen aus den beiden zuvor beschriebenen Workloads. Die Kosten der ersten Epoche hängen von Ihrem Image und davon ab, was Ihr Code beim Start berührt:

• Lazy Loading gewinnt, wenn der erste Trainingsschritt nur einen Bruchteil des Images benötigt, während der Rest während des Trainings hereingestreamt wird.
• Wenn Ihr Einstiegspunkt vor dem Trainingsbeginn den Großteil des Images liest (zum Beispiel durch Scannen, Prüfsummenbildung oder Vorladen des Inhalts), wartet die erste Epoche auf ungefähr dieselben Bytes, die ein vollständiger Pull abgerufen hätte. Die Nettoverschönerung wäre gering.
• Front-geladene Starts schnitten in unseren Tests trotzdem besser ab:
  • torch.compile und eine just-in-time (JIT) kompilierte CUDA-Erweiterung verlängerten die erste Epoche um 7-15 s (Nettoersparnis weiterhin 3 min 25 s–3 min 56 s)
  • Ein 6 GB Modell, das in das Image eingebacken war, streamte seine Gewichte zur Ladezeit, was 2-3.5 min hinzufügte, aber der gesamte Job wurde auf dem indizierten Image dennoch 2-2.5 mins früher abgeschlossen.

Erste Schritte

Sie können die SOCI-Indizierung auf zwei Weisen übernehmen: Verwenden Sie einen vorindizierten AWS Deep Learning Container oder erstellen Sie einen Index für Ihr eigenes benutzerdefiniertes Image.

Option 1: Verwenden Sie einen vorindizierten AWS Deep Learning Container

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, einschließlich arm64-Varianten für einige Frameworks. Um Lazy Loading zu übernehmen, aktualisieren Sie das Image-Tag in Ihrer Job-Definition auf die -soci-Variante. Sehen Sie sich die vollständige Liste in der AWS Deep Learning Containers Gallery.

Hinweis: Wenn Sie Ihr eigenes Image FROM einer DLC-Basis-Image erstellen, müssen Sie einen SOCI-Index für Ihr finales Image erstellen. Der Index aus dem Basis-Image wird nicht auf abgeleitete Images übertragen.

Option 2: Erstellen Sie einen SOCI-Index für Ihr eigenes Image

Um ein benutzerdefiniertes Image zu indizieren, benötigen Sie einen Linux-Host (z. B. eine Amazon Elastic Compute Cloud (Amazon EC2)-Instance mit Amazon Linux 2023) mit containerd, dem SOCI snapshotter, und entweder Finch oder nerdctl installiert.

1. Legen Sie Ihre Umgebungsvariablen fest.

   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"

2. Installieren Sie die erforderlichen Tools.

   sudo dnf install -y containerd fuse soci-snapshotter runfinch-finch
   sudo systemctl start soci-snapshotter
   sudo systemctl restart containerd

3. Authentifizieren Sie sich bei Amazon ECR.

   aws ecr get-login-password --region "$REGION" \
     | sudo nerdctl login -u AWS --password-stdin "$REGISTRY"

4. Pullen Sie Ihr ursprüngliches Image.

   sudo nerdctl pull "$REGISTRY/$REPOSITORY_NAME:$ORIGINAL_IMAGE_TAG"

5. Erstellen Sie das SOCI-indexierte Image.

   sudo nerdctl image convert --soci \
     "$REGISTRY/$REPOSITORY_NAME:$ORIGINAL_IMAGE_TAG" \
     "$REGISTRY/$REPOSITORY_NAME:$SOCI_IMAGE_TAG"

6. Pushen Sie das indexierte Image.

   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.

Automatisieren Sie die Indexerstellung in CI/CD

Um Indizes bei jedem Push automatisch zu generieren, deployen Sie den CFN ECR SOCI Index Builder. Er verwendet eine Amazon EventBridge -Regel, um Amazon ECR Image-Push-Ereignisse zu erkennen und den Index zu erstellen. Es sind keine Änderungen an Ihrer Build-Pipeline erforderlich.

Verwenden Sie das indexierte Image in Ihrem SageMaker AI Job

Referenzieren Sie Ihr SOCI-indexiertes Image genau so, wie Sie jedes andere Image referenzieren würden. Es sind keine API-Änderungen erforderlich. Nur das Tag ist anders.

Trainingsbeispiel (SageMaker Python SDK)

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()

Stellen Sie sicher, dass Ihr Image einen SOCI-Index enthält

Bevor Sie den Tag pushen, bestätigen Sie, dass der Tag auf ein indiziertes Image verweist:

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[0].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 der Tag nicht auf ein indiziertes Image.

Zu beachtende Punkte

• Nur Amazon ECR private repositories. Images in anderen Registries oder Images, die über eine private Docker-Registry bezogen werden (TrainingRepositoryAccessMode auf Vpc gesetzt), sind für Lazy Loading nicht geeignet.
• Die Verbesserung skaliert mit der Imagegröße. Images, die kleiner als etwa 4 GB sind, sehen relativ geringe Verbesserungen.
• Prüfen Sie auf Docker-spezifische Annahmen. SOCI-indizierte Images laufen auf einer containerd-basierten Runtime. Überprüfen Sie Entry Points und Setup-Skripte auf Code, der die Docker-CLI aufruft, /var/run/docker.sock liest oder Bezeichner aus cgroup-Pfaden ableitet. SageMaker AI mountet einen /.dockerenv-Marker für Abwärtskompatibilität, vermeiden Sie jedoch neue Abhängigkeiten davon.
• SOCI-Indizierung für SageMaker AI Jobs ist in allen AWS-Regionen verfügbar.

Fazit

Mit SOCI-Indizierung können Sie die Downloadzeit von Container-Images für Ihre SageMaker AI Training- 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-(ML)-Iterationszyklus. Und Ihre bestehenden Job-Definitionen, API-Aufrufe und Datenpipelines bleiben genau gleich.

Um mehr zu erfahren über Amazon SageMaker AI und die SOCI-Indizierung zu nutzen, erkunden Sie die folgenden Ressourcen:

1. Wählen Sie einen SOCI-indizierten Deep Learning Container. Durchsuchen Sie die Deep Learning Containers Gallery und hängen Sie -soci an Ihren Image-Tag an. Für frameworkspezifische Anleitungen siehe SOCI index for AWS Deep Learning Containers.
2. Indizieren Sie Ihr eigenes benutzerdefiniertes Image. Folgen Sie der Schritt-für-Schritt-Anleitung im SageMaker AI Developer Guideoder lesen Sie die SOCI snapshotter getting-started guide für erweiterte Optionen.
3. Automatisieren Sie die Indizierung in Ihrer CI/CD-Pipeline. Deployen Sie den CFN ECR SOCI Index Builder um bei jedem Image-Push automatisch Indizes zu generieren. Es sind keine Pipeline-Änderungen erforderlich.
4. Testen Sie lokal mit Finch. Verwenden Sie den Schritt-für-Schritt-Anleitung zum Lazy-Loading mit Finch um Ihr Image auf einer containerd-basierten Runtime zu validieren, bevor Sie einen Job einreichen.
5. Tauchen Sie tiefer in die Technologie ein. Lesen Sie Reducing container cold start times using SOCI index on DLAMI and DLC im AWS Machine Learning Blog für Benchmarks, oder erkunden Sie Unter der Haube: Lazy Loading von Container-Images mit Seekable OCI und AWS Fargate im AWS Containers Blog, um den Lazy-Loading-Mechanismus im Detail zu verstehen.

Schnellere Container-Starts sind nur einen Image-Tag entfernt. Probieren Sie es bei Ihrem nächsten SageMaker-AI-Job aus und sehen Sie den Unterschied.

Über die Autoren