SageMaker AI prend en charge les images indexées SOCI : conteneurs d’entraînement à chargement paresseux, jusqu’à 90 % d’inactivité GPU en moins pendant le téléchargement des images, selon AWS

Le 29 octobre 2026, AWS a annoncé que les tâches d’entraînement et de traitement d’Amazon SageMaker AI prennent désormais en charge les images de conteneur indexées SOCI (Seekable OCI). Selon AWS, cela démarre les conteneurs d’entraînement en quelques secondes et réduit jusqu’à 90 % le temps d’inactivité des GPU pendant le téléchargement de l’image, sans effet sur les performances d’entraînement hormis un coût ponctuel à la première époque. Les 90 % sont une valeur « jusqu’à » issue des propres tests d’AWS, pas une garantie pour chaque tâche.

Le problème se situe avant l’exécution. SageMaker AI télécharge d’abord toute l’image de conteneur sur l’instance, puis décompresse et écrit chaque couche. Les images d’apprentissage profond dépassent couramment 10 Go, ce qui ajoute des minutes à chaque tâche, et ce temps est facturé. L’impact est le plus fort pour les balayages d’hyperparamètres de centaines de tâches, les expériences rapides et les tâches de traitement courtes, où le téléchargement peut dominer la durée totale.

SOCI est une technologie open source de chargement paresseux. Un index SOCI est un ensemble de métadonnées qui cartographie chaque fichier de l’image. Il est stocké dans Amazon ECR comme un artefact conforme OCI lié à l’image d’origine, si bien que le condensat de l’image et les signatures existantes restent valides. Quand l’image d’une tâche a un index, SageMaker AI 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 du code. Le service vérifie automatiquement la présence d’un index : s’il existe, chargement paresseux ; sinon, téléchargement comme avant ; et si l’index est illisible ou si le chargement paresseux échoue, la tâche revient à un téléchargement standard et continue. Ajouter un index ne peut donc pas empêcher une tâche de démarrer.

Il y a deux façons de l’adopter. La première consiste à utiliser un Deep Learning Container d’AWS déjà indexé, en remplaçant l’étiquette de l’image par sa variante -soci ; le blog de lancement d’AWS cite PyTorch Training, TensorFlow Training, vLLM et SGLang, avec des variantes arm64 pour certains frameworks. La seconde consiste à ajouter un index à sa propre image, ce qui demande un hôte Linux avec containerd, le snapshotter SOCI et Finch ou nerdctl, sans reconstruire l’image. Les définitions de tâche, les points d’entrée et les canaux de données ne changent pas. Deux conditions comptent : une image construite FROM un Deep Learning Container a besoin de son propre index, car celui de l’image de base n’est pas transmis, et l’image doit se trouver dans un dépôt ECR privé. La fonction est disponible dans toutes les Régions où SageMaker AI l’est, via les API, les CLI, les SDK et la console.

Le blog de lancement rapporte les mesures d’AWS. Les tests ont porté sur huit images de 1,8 à 35,4 Go compressées, sur des types d’instance de ml.g4dn à ml.p5, dans les Régions USA Ouest (Oregon) et USA Est (Virginie du Nord), avec des médianes de séries répétées. Une image de 1,8 Go est passée de 48 secondes à 3 à 11 secondes, une image de 13,2 Go de 3 minutes 42 secondes à environ 6 secondes, et une image de 35,4 Go de 7 minutes 17 secondes à 3 à 11 secondes. La même image de 13,2 Go sur 13 types et tailles d’instance a demandé de 3 minutes 16 secondes à 4 minutes 20 secondes en téléchargement standard et de 6 à 8 secondes en chargement paresseux. Les résumés du blog expriment le gain de façon incohérente, environ 10 fois, 8 fois, et 8 à 46 fois, alors que son tableau va d’environ 8 à environ 38 fois : mieux vaut s’en tenir aux secondes.

L’entraînement lui-même a un coût ponctuel. AWS a comparé ResNet-50 sur Imagenette (9 469 images) et le réglage complet de Qwen2.5-0.5B sur 51 760 exemples. À partir de la deuxième époque, la durée d’une époque était la même, la première prenait 3 à 16 secondes de plus pendant la récupération des fichiers touchés pour la première fois, et chaque tâche se terminait environ 1 à 6 minutes plus tôt au total. Si le point d’entrée lit l’essentiel de l’image avant l’entraînement, par exemple pour analyser, calculer des sommes de contrôle ou précharger, le gain diminue. Dans les tests d’AWS, torch.compile et une extension CUDA compilée à la volée ont ajouté 7 à 15 secondes à la première époque, et un modèle de 6 Go intégré à l’image a ajouté 2 à 3,5 minutes lorsque ses poids étaient diffusés au chargement, mais la tâche se terminait quand même 2 à 2,5 minutes plus tôt.

Ce sont des mesures d’AWS sur deux types de charge. Le coût de la première époque dépend de l’image et de ce que le code touche au démarrage : il faut mesurer sur ses propres tâches.