Annonce d'images indexées SOCI pour des tâches SageMaker AI plus rapides

Chaque minute que votre image de conteneur d'apprentissage profond passe à se télécharger est une minute que vous payez et une minute que votre équipe attend. Le téléchargement d'une image de conteneur est une pure surcharge : du temps de tâche facturable qui ne produit aucune progression du modèle. Pour les images modernes d'apprentissage profond, cette surcharge représente plusieurs minutes à chaque tâche. Aujourd'hui, nous sommes ravis d'annoncer l'indexation Seekable OCI (SOCI) pour Amazon SageMaker AI Training et les tâches de traitement Amazon SageMaker AI, qui retire le téléchargement complet de l'image de conteneur du chemin critique de chaque tâche.

Avec l'indexation SOCI, SageMaker AI charge votre image de conteneur en mode différé. Il ne récupère que les fichiers nécessaires au démarrage du conteneur et diffuse le reste en arrière-plan pendant l'exécution de votre code, de sorte que votre tâche démarre en quelques secondes au lieu de plusieurs minutes. Vous l'adoptez en pointant vers un conteneur AWS Deep Learning Container (DLC) pré-indexé ou en ajoutant un index à votre propre image. Aucune de ces approches ne nécessite de modification de votre définition de tâche, de votre point d'entrée ou de vos canaux de données. Le résultat est un démarrage plus rapide des tâches, un coût de tâche réduit et plus de temps consacré à la construction de modèles plutôt qu'à l'attente de l'infrastructure.

Les images indexées SOCI démarrent les conteneurs d'entraînement Amazon SageMaker AI en quelques secondes, sans impact sur les performances d'entraînement. Comme nous le montrons dans la section Ce que nous avons mesuré , cela a réduit le temps d'inactivité des GPU pendant le téléchargement des images jusqu'à 90 percent dans nos benchmarks.

Cet article montre comment adopter l'indexation SOCI : ce qu'elle est, les résultats que nous avons mesurés et comment l'activer pour vos propres tâches.

Le défi

Les tâches d'entraînement et de traitement SageMaker AI s'exécutent dans des images de conteneur stockées dans Amazon Elastic Container Registry (Amazon ECR). Avant qu'une tâche ne puisse exécuter votre code, le service télécharge l'intégralité de l'image sur l'instance. Il décompresse et écrit chaque couche sur le disque.

Pour les petites images, cela prend quelques secondes. Mais les images d'apprentissage profond dépassent régulièrement 10 GB ou plus. Ce téléchargement ajoute des minutes à chaque tâche, et vous le payez comme temps de tâche. L'impact est le plus important précisément là où la vitesse d'itération compte le plus : les balayages d'ajustement d'hyperparamètres pour des centaines de tâches, les expériences rapides et les tâches de traitement courtes, où le téléchargement de l'image peut dominer la durée totale d'exécution.

Fonctionnement de l'indexation SOCI

Seekable OCI (SOCI) est une technologie open source qui charge les images de conteneur en mode différé. Au lieu de télécharger l'image entière avant de démarrer, le runtime utilise un index SOCI pour récupérer uniquement les fichiers nécessaires au lancement immédiat du conteneur. Il diffuse ensuite le reste en arrière-plan au fur et à mesure que votre code y accède.

Un index SOCI est une métadonnée qui répertorie chaque fichier à l'intérieur de votre image. Vous le stockez dans Amazon ECR sous forme d'artefact conforme à OCI lié à votre image d'origine. Comme l'index est un artefact distinct, le digest de votre image et toutes les signatures existantes restent valides.

SageMaker AI vérifie automatiquement la présence d'un index

Lorsque vous créez une tâche d'entraînement ou de traitement, SageMaker AI vérifie si l'image que vous avez spécifiée possède un index SOCI et se comporte en conséquence :

Comme les tâches reviennent toujours à un téléchargement standard lorsque nécessaire, l'ajout d'un index SOCI n'empêche jamais votre tâche de s'exécuter. Vous ne bénéficiez que d'un démarrage plus rapide. Vous ne courez jamais le risque de casser un flux de travail existant.

Ce que nous avons mesuré

Nous avons téléchargé les mêmes images de conteneur de deux manières sur de véritables tâches d'entraînement SageMaker AI : téléchargement standard et chargement différé avec index SOCI. Nous avons ensuite exécuté des tâches d'entraînement complètes à partir des deux pour mesurer l'effet sur la vitesse d'entraînement.

Configuration

• Huit images, 1,8–35,4 Go compressées.
• Instances GPU et CPU ml.g4dn, ml.g5, ml.g6, ml.g6e, ml.g7, ml.g7e, ml.p4d, ml.p5 et ml.m7i, de xlarge à 48xlarge, dans la Région US West (Oregon) (us-west-2) et la Région US East (N. Virginia) (us-east-1).
• Temps de téléchargement mesuré depuis le début du pull de l'image jusqu'à ce que le conteneur soit prêt à s'exécuter. Toutes les figures sont des médianes d'exécutions répétées.

Résultat 1 : le temps de téléchargement passe de minutes à secondes pour chaque taille d'image

Le graphique suivant compare le temps de téléchargement des images de conteneurs pour un docker pull standard au chargement différé SOCI sur huit tailles d'images, de 1,8 Go à 35,4 Go.

Chaque taille d'image affiche deux barres. La barre du temps de téléchargement Docker (bleue) croît régulièrement avec la taille de l'image, de 48 secondes à 1,8 Go à 7 minutes 17 secondes à 35,4 Go.

Une étiquette d'accélération au-dessus de chaque paire indique le rapport entre le temps Docker et le temps SOCI. Les accélérations vont d'environ 10x pour la plus petite image à plus de 35x pour la plus grande.

Figure 1 : Temps de téléchargement des images de conteneurs, docker pull standard comparé au chargement différé SOCI, sur huit tailles d'images

Le temps de téléchargement standard augmente avec la taille de l'image parce que chaque fichier est décompressé et écrit. Le chargement différé est resté à 3–11 secondes quelle que soit la taille, soit une amélioration de 8x à 46x. Plus l'image est grande, plus vous gagnez de minutes.

Résultat 2 : L'économie se maintient sur tous les types et toutes les tailles d'instances

En exécutant l'image de 13,2 Go sur 13 combinaisons type/taille d'instances, le téléchargement standard a varié de 3 min 16 s à 4 min 20 s, tandis que le chargement différé est resté à 6-8 s. Cela représente environ 34x plus rapide sur chaque configuration. Vous n'avez pas besoin de changer de type ou de taille d'instance pour en bénéficier.

Figure 2 : Temps de téléchargement d'une image de 13,2 Go sur 13 combinaisons de types et de tailles d'instances

Résultat 3 : Les performances d'entraînement ne sont pas affectées au-delà d'une pénalité à la première époque

Nous avons exécuté deux types de tâches d'entraînement complètes, à partir de l'image obtenue par Docker pull et à partir de l'image indexée par SOCI, et comparé chaque époque :

• Classification d'images sur ResNet-50 sur Imagenette (9 469 images)
  • Images de conteneurs : PyTorch (DLC de 13,2 Go) et TensorFlow (DLC de 9,9 Go)
  • Instances : ml.p5.48xlarge, ml.p4d.24xlarge, ml.g7e.48xlarge, ml.g7.48xlarge, ml.g6e.12xlarge, ml.g6e.24xlarge et ml.g6e.48xlarge.
• Fine-tuning de grand modèle de langage (LLM) : fine-tuning supervisé complet de tous les paramètres (SFT) de Qwen2.5-0.5B sur alpaca-cleaned (51 760 exemples) avec le Hugging Face Trainer.
  • Image de conteneur : 9.4 Go, Hugging Face PyTorch DLC.
  • Instances : ml.p5.48xlarge, ml.p4d.24xlarge, ml.g6.48xlarge.

Le graphique suivant décompose le démarrage des tâches en temps de téléchargement de l'image et temps de la première époque d'entraînement, en comparant un Docker pull standard avec une image indexée SOCI sur des configurations GPU et CPU pour les deux charges de travail.

Figure 3 : Démarrage d'une tâche décomposé en temps de téléchargement de l'image et temps de la première époque d'entraînement, un docker pull standard comparé à une image indexée SOCI

• À partir de la deuxième époque, le temps par époque est le même (à la variation d'une exécution à l'autre près) sur chaque instance, pour les deux charges de travail.
• La première époque prend 3 à 16 s de plus à partir de l'image chargée en différé, pendant que les fichiers touchés pour la première fois par le framework sont récupérés. Ce coût de première époque est identique quelle que soit la taille de l'instance.
• Bilan : chaque tâche s'est terminée 1 à 6 min plus tôt. C'est l'économie de téléchargement moins le coût unique de première époque, soit une économie fixe par tâche.

Testez cela sur votre propre charge de travail

Ces chiffres proviennent des deux charges de travail décrites précédemment. Le coût de première époque dépend de votre image et de ce que votre code touche au démarrage :

• Le chargement en différé est gagnant lorsque la première étape d'entraînement n'a besoin que d'une fraction de l'image, le reste étant diffusé pendant l'entraînement.
• Si votre point d'entrée lit la majeure partie de l'image avant le début de l'entraînement (par exemple, numérisation, calcul de sommes de contrôle ou préchargement de son contenu), la première époque attendra à peu près les mêmes octets qu'un pull complet aurait récupérés. L'amélioration nette serait faible.
• Les démarrages à chargement anticipé sont malgré tout ressortis gagnants dans nos tests :
  • torch.compile et une extension CUDA construite à la volée (JIT) ont ajouté 7 à 15 s à la première époque (économie nette toujours de 3 min 25 s à 3 min 56 s)
  • Un modèle de 6 Go intégré à l'image a diffusé ses poids au chargement, ajoutant 2-3.5 min, mais la tâche globale s'est tout de même terminée 2-2.5 min plus tôt sur l'image indexée.

Premiers pas

Vous pouvez adopter l'indexation SOCI de deux façons : utiliser un conteneur AWS Deep Learning pré-indexé ou créer un index pour votre propre image personnalisée.

Option 1 : Utiliser un conteneur AWS Deep Learning pré-indexé

AWS publie des variantes indexées SOCI de plusieurs Deep Learning Containers populaires, identifiées par le suffixe -soci sur le tag de l'image :

763104351884.dkr.ecr.us-east-1.amazonaws.com/pytorch-training:2.9-gpu-py312-cu130-ubuntu22.04-sagemaker-v1-soci

Des variantes pré-indexées sont disponibles pour PyTorch Training, TensorFlow Training, vLLM et SGLang, y compris des variantes arm64 pour certains frameworks. Pour adopter le chargement en différé, mettez à jour le tag de l'image dans votre définition de tâche vers la variante -soci. Consultez la liste complète dans la Galerie des AWS Deep Learning Containers.

Remarque : Si vous construisez votre propre image FROM une image de base DLC, vous devez créer un index SOCI pour votre image finale. L'index de l'image de base n'est pas reporté sur les images dérivées.

Option 2 : Créer un index SOCI pour votre propre image

Pour indexer une image personnalisée, vous avez besoin d'un hôte Linux (par exemple, une instance Amazon Elastic Compute Cloud (Amazon EC2) exécutant Amazon Linux 2023) avec containerd, le SOCI snapshotter, et soit Finch soit nerdctl installés.

1. Définissez vos variables d'environnement.

   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. Installez les outils requis.

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

3. Authentifiez-vous auprès d'Amazon ECR.

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

4. Extrayez votre image d'origine.

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

5. Créez l'image indexée SOCI.

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

6. Poussez l'image indexée.

   sudo nerdctl push --platform linux/amd64 \
     "$REGISTRY/$REPOSITORY_NAME:$SOCI_IMAGE_TAG"

Cette opération crée deux artefacts dans votre référentiel : l'index SOCI et un manifeste d'index d'image compatible OCI reliant votre image à l'index. Votre image d'origine et son digest restent inchangés.

Automatisez la création d'index en CI/CD

Pour générer automatiquement des index à chaque push, déployez le CFN ECR SOCI Index Builder. Il utilise une règle Amazon EventBridge pour détecter les événements de poussée d'images Amazon ECR et construire l'index. Aucune modification de votre pipeline de build n'est nécessaire.

Utilisez l'image indexée dans votre tâche SageMaker AI

Référencez votre image indexée SOCI exactement comme n'importe quelle autre image. Aucune modification d'API n'est nécessaire. Seul le tag diffère.

Exemple d'entraînement (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()

Vérifiez que votre image inclut un index SOCI

Avant le lancement, confirmez que votre tag pointe vers une image indexée :

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}'

Recherchez un manifeste enfant dont artifactType commence par application/vnd.amazon.soci.index. à côté de votre manifeste de plateforme. S'il n'y est pas, le tag ne pointe pas vers une image indexée.

Points à garder à l'esprit

• Repositories privés Amazon ECR uniquement. Les images provenant d'autres registries, ou extraites via un registry Docker privé (TrainingRepositoryAccessMode défini sur Vpc), ne sont pas éligibles au chargement différé.
• L'amélioration augmente avec la taille de l'image. Les images de moins d'environ 4 GB voient des améliorations relativement faibles.
• Vérifiez les hypothèses spécifiques à Docker. Les images indexées SOCI s'exécutent sur un runtime basé sur containerd. Examinez les points d'entrée et les scripts de configuration pour détecter du code qui appelle la CLI Docker, lit /var/run/docker.sock ou dérive des identifiants à partir de chemins cgroup. SageMaker AI monte un marqueur /.dockerenv pour la rétrocompatibilité, mais évitez d'ajouter de nouvelles dépendances à celui-ci.
• L'indexation SOCI pour les jobs SageMaker AI est disponible dans toutes les Régions AWS.

Conclusion

Avec l'indexation SOCI, vous pouvez minimiser le temps de téléchargement des images de conteneurs pour vos jobs d'entraînement et de traitement SageMaker AI. Ajoutez un index SOCI à vos images, ou passez à un AWS Deep Learning Container pré-indexé. Dans les deux cas, vous réduisez le temps de démarrage de plusieurs minutes à quelques secondes, diminuez le coût total du job et accélérez votre cycle d'itération de machine learning (ML). Et vos définitions de jobs, appels d'API et pipelines de données existants restent exactement identiques.

Pour en savoir plus sur Amazon SageMaker AI et commencer à utiliser l'indexation SOCI, explorez les ressources suivantes :

1. Choisissez un Deep Learning Container indexé SOCI. Parcourez la galerie des Deep Learning Containers et ajoutez -soci au tag de votre image. Pour des conseils spécifiques au framework, consultez SOCI index for AWS Deep Learning Containers.
2. Indexez votre propre image personnalisée. Suivez la procédure pas à pas dans le SageMaker AI Developer Guide, ou reportez-vous au guide de démarrage du SOCI snapshotter pour les options avancées.
3. Automatisez l'indexation dans votre pipeline CI/CD. Déployez le CFN ECR SOCI Index Builder pour générer automatiquement des index à chaque push d'image. Aucune modification du pipeline n'est requise.
4. Testez localement avec Finch. Utilisez le Guide pas à pas du lazy-loading avec Finch pour valider votre image sur un runtime basé sur containerd avant de soumettre un job.
5. Approfondissez la technologie. Lisez Reducing container cold start times using SOCI index on DLAMI and DLC sur le blog AWS Machine Learning pour les benchmarks, ou explorez Sous le capot : chargement différé des images de conteneurs avec Seekable OCI et AWS Fargate sur le blog AWS Containers pour comprendre en détail le mécanisme de lazy-loading.

Un démarrage plus rapide des conteneurs ne se trouve qu'à un tag d'image de distance. Essayez-le sur votre prochain job SageMaker AI et constatez la différence.

À propos des auteurs