Résumé

  • AWS a lancé le 11 septembre deux caches indépendants pour HyperPod : les poids des modèles et les images de conteneurs. Ils sont désactivés par défaut.
  • Les poids restent locaux à chaque nœud. Le placement favorise les nœuds préchauffés sans les imposer ; un nouveau nœud peut toujours devoir revenir à la source distante.

Ajouter de la puissance de calcul ne suffit pas à rendre une réplique d'inférence immédiatement utile. Il faut aussi préparer son image de conteneur et ses poids de modèle. La nouvelle fonction de cache d'Amazon SageMaker HyperPod cherche à éviter que cette préparation soit payée à nouveau, en temps de transfert, sur un nœud qui l'a déjà effectuée.

L'annonce du 11 septembre sépare deux mécanismes. Le cache des poids prépositionne les fichiers sur le stockage NVMe local du nœud, au lieu de les récupérer à répétition depuis Amazon S3 ou Amazon FSx. Le cache d'images précharge le conteneur d'inférence pour éviter un téléchargement à froid lors d'un démarrage ultérieur. L'opérateur d'inférence permet d'activer l'un, l'autre ou les deux ; la documentation les laisse tous deux désactivés par défaut.

AWS fait état d'une montée en charge environ 60 % plus rapide dans des essais portant sur des modèles de 57 à 145 Go. L'entreprise indique séparément que le cache d'images supprime plus de deux minutes de téléchargement, soit une réduction de 97 % de cette étape. Ces chiffres n'ont pas le même périmètre. Ils ne s'additionnent pas et ne prouvent ni une réduction générale de la latence ressentie par l'utilisateur ni une économie client mesurée ici.

La documentation précise les conditions du cache de poids : un stockage NVMe local au chemin configuré et une capacité disponible suffisante. Les instances reposant uniquement sur EBS ne sont pas prises en charge pour ce mécanisme. Si la configuration locale ne convient pas, les poids peuvent continuer à être chargés à distance. Une image préchargée ne garantit donc pas que les fichiers du modèle le soient aussi.

Le choix du nœud fait partie du résultat. L'opérateur prépare les nœuds correspondant aux contraintes du déploiement et les étiquette lorsqu'ils sont prêts. Le déploiement utilise une affinité préférentielle pour les favoriser, mais peut être placé ailleurs. Kubernetes explique qu'une telle préférence s'ajoute aux autres exigences d'ordonnancement, sans interdire tous les placements alternatifs. Cette référence décrit le principe général, pas la version précise de Kubernetes utilisée par HyperPod.

Un déploiement doté du cache peut ainsi suivre deux parcours. Sur un nœud prêt, il réutilise les fichiers locaux. Sinon, il charge les poids depuis leur source d'origine. Ce repli évite de faire d'un cache chaud un préalable absolu ; il ne supprime pas la dépendance au téléchargement. Les indications de dépannage d'AWS mentionnent expressément les erreurs de transfert et les sources S3 ou FSx inaccessibles.

Le remplacement d'un nœud modifie également le stock de préparation disponible. Le nouveau nœud doit être préchauffé, tandis que les nœuds déjà prêts continuent à servir dans le scénario documenté. Des fichiers présents sur disque ne signifient toutefois pas que le modèle est chargé dans la mémoire du GPU ou qu'une capacité d'inférence supplémentaire attend une pointe de demande.

Enfin, l'isolation des répertoires n'isole pas la capacité physique. Chaque déploiement possède son propre répertoire de cache et consomme de l'espace NVMe sur le nœud. En cas de pression disque, AWS recommande notamment des groupes d'instances distincts ou moins de déploiements mis en cache simultanément. Il s'agit d'une condition d'exploitation documentée, pas d'un incident client constaté par cet article.

Selon AWS, la fonction est disponible dans toutes les régions où HyperPod l'est. Sa valeur dépendra surtout de la fréquence de réutilisation de nœuds éligibles et préparés, plutôt que de la seule activation du paramètre.

Sources