SageMaker téléchargeait l’image en entier, désormais il ne lit que le début
Sept minutes et dix-sept secondes. C’est le temps qu’Amazon SageMaker passait à tirer une image de conteneur de 35,4 Go avant que la première ligne de ton code s’exécute. Pas un epoch, pas un gradient, pas une seconde de calcul. Juste du téléchargement, facturé au tarif d’un job d’entraînement. AWS vient de décider que ça suffisait.
L’annonce, publiée sur le blog AWS le 27 octobre, tient dans une techno : le Seekable OCI, alias SOCI. Le principe est bête comme chou. Jusqu’ici, SageMaker téléchargeait l’intégralité de l’image depuis Amazon ECR, décompressait chaque couche et l’écrivait sur le disque avant de lancer quoi que ce soit. Avec un index SOCI, le service ne récupère que les fichiers nécessaires au démarrage et streame le reste en tâche de fond pendant que ton code tourne.
Les mesures maison donnent ceci. Le téléchargement classique grimpe de 48 secondes sur une image de 1,8 Go à 7 minutes 17 sur une image de 35,4 Go. Le chargement paresseux, lui, reste entre 3 et 11 secondes quelle que soit la taille. AWS annonce un facteur 8 à 46 selon les cas, avec un ratio qui passe d’environ 10x sur la plus petite image à plus de 35x sur la plus grosse.
Test sur 13 combinaisons d’instances avec une image de 13,2 Go : 3 minutes 16 à 4 minutes 20 en téléchargement standard, 6 à 8 secondes en lazy loading. Environ 34x, sans changer de type ni de taille d’instance. Voilà pour la brochure.
La ligne invisible sur la facture
Ce qui rend l’affaire intéressante, ce n’est pas le gain technique. C’est ce qu’il révèle. Pendant des années, chaque job SageMaker a payé plusieurs minutes de tuyauterie improductive. Sur un sweep d’hyperparamètres à plusieurs centaines de jobs, sur des expériences jetables, sur du processing qui dure moins longtemps que son propre démarrage, cette surcharge pesait plus lourd que le travail réel. Personne ne la mettait sur un slide.
AWS parle d’une réduction allant jusqu’à 90 % du temps où le GPU tournait à vide pendant le pull d’image. Dans ses propres benchmarks, hein. La mécanique rend le chiffre plausible, mais il sort de la maison qui vend le service : à prendre avec la pincée de sel d’usage.
Deuxième angle, moins reluisant : les conteneurs de deep learning empilent les frameworks, les CUDA, les bibliothèques, et rien n’incitait personne à les maigrir tant que le téléchargement était noyé dans le coût du job. La vraie correction, ce serait des images plus propres. Ce qu’AWS vend ici, c’est un cache-misère intelligent. Efficace, mais un cache-misère quand même.
Le petit caractère qui coince
L’adoption se fait par une étiquette. AWS publie des variantes pré-indexées de ses Deep Learning Containers, reconnaissables au suffixe -soci : PyTorch Training, TensorFlow Training, vLLM, SGLang, avec des déclinaisons arm64 pour certains frameworks. Tu changes le tag dans ta définition de job, tu ne touches ni à ton entry point ni à tes data channels, et c’est censé rouler.
Sauf que. Si tu construis ta propre image FROM une image de base DLC, l’index de la base ne suit pas. Il faut générer un index pour l’image finale, sur une machine Linux avec containerd, le snapshotter SOCI, et Finch ou nerdctl. Autrement dit, ceux qui ont les images les plus grasses et les plus custom, ceux pour qui le gain serait maximal, sont précisément ceux qui ont du boulot en plus. Les autres, ceux qui tapent dans les DLC officiels, n’ont qu’un tag à changer.
L’index lui-même est un artefact OCI séparé, stocké dans ECR et lié à l’image d’origine. Bon point : le digest de l’image et les signatures existantes restent valides. Ça évite le grand classique du « on optimise mais on casse ta chaîne de confiance ».
Le filet est là, le courant manque toujours
AWS précise que si l’image n’a pas d’index, ou si quelque chose coince, le job retombe sur le téléchargement standard. Aucun risque de casser un workflow existant, promet le billet. C’est la bonne manière de faire ce genre de bascule, on ne va pas cracher dessus.
Reste une question que le billet ne pose pas. Le temps que tu ne paies plus à télécharger part quelque part. Dans ta poche si tu enchaînes les jobs courts, dans les benchmarks d’AWS si c’est eux qui font les comptes. Et probablement dans le prochain cart de GPU, parce que la vraie contrainte du secteur n’a jamais été la vitesse de téléchargement d’une image. C’est le courant qui manque pour faire tourner la bécane une fois qu’elle a démarré.
Trois secondes de démarrage, c’est très bien. Ça ne branche pas un transformateur.
Sources :
Comments are closed