AWS cible les retards d’inférence SageMaker avec la mise en cache des modèles HyperPod et le routage par préfixe

AWS ajoute deux fonctions d’infrastructure visant deux goulets d’étranglement distincts mais liés dans le service de grands modèles de langage : la mise en cache des modèles pour Amazon SageMaker HyperPod et le routage sensible au préfixe pour SageMaker Inference. La première est conçue pour réduire le temps nécessaire à la mise en ligne de nouveaux pods d’inférence ; la seconde vise à réduire la latence de réponse en conservant sur la même instance le calcul de prompt fréquemment réutilisé.

Ces changements comptent surtout pour les équipes qui exploitent de grands modèles avec un trafic variable. Sans mise en cache, un événement de scale-out peut obliger de nouveaux nœuds à télécharger des images de conteneurs de plusieurs gigaoctets et des poids de modèle avant de pouvoir servir des requêtes. Sans routage tenant compte du contenu du prompt, le cache de préfixe d’un framework de service peut rester sous-utilisé, car des sections de prompt identiques sont réparties sur toute une flotte.

Les deux annonces proviennent du AWS Machine Learning Blog ; les chiffres de performance et les affirmations opérationnelles sont donc rapportés par AWS et non vérifiés indépendamment. Ensemble, elles dessinent une approche plus coordonnée pour réduire à la fois les démarrages à froid de l’inférence et le temps jusqu’au premier token en régime stable.

La mise en cache HyperPod comble l’écart de scale-out

AWS indique que le déploiement de modèles sur SageMaker HyperPod peut être retardé par deux téléchargements successifs. Kubernetes récupère d’abord une image du serveur d’inférence depuis Amazon Elastic Container Registry, puis le serveur télécharge les poids du modèle depuis une source telle qu’Amazon S3, Amazon FSx for Lustre, Hugging Face Hub ou JumpStart.

Pour des modèles plus petits, ce processus peut prendre quelques minutes. AWS donne l’exemple d’un modèle de 145 Go dont le téléchargement des poids peut prendre plus de 20 minutes depuis Amazon S3, selon les conditions réseau. Pour un modèle comme DeepSeek-R1, qu’AWS décrit comme pesant plus de 600 Go dans le scénario cité, le processus peut durer 30 minutes ou plus. Le simple pull de l’image de conteneur est estimé par AWS à cinq à sept minutes pour des images d’inférence typiques de plusieurs gigaoctets.

Ce délai crée un décalage entre l’autoscaling et la capacité réelle. Un HorizontalPodAutoscaler peut demander rapidement des pods supplémentaires, mais ces pods ne peuvent pas accepter de trafic tant que leurs images et leurs poids ne sont pas disponibles. Un pic soudain de requêtes peut donc déclencher une réponse opérationnelle qui arrive des dizaines de minutes trop tard.

La nouvelle capacité de mise en cache des modèles précharge les poids sur le stockage NVMe local des nœuds cibles. AWS explique que le HyperPod Inference Operator télécharge les poids à l’avance, marque les nœuds comme prêts pour le cache et attend que les nœuds cibles terminent le processus avant de créer le déploiement d’inférence. Une fois qu’un pod démarre sur un nœud préparé, il peut lire localement à environ 7 Go par seconde au lieu de télécharger le modèle sur le réseau.

AWS propose aussi un cache d’images indépendant. Un DaemonSet précharge l’image du conteneur d’inférence sur les nœuds, permettant aux pods ultérieurs d’éviter le téléchargement depuis Amazon Elastic Container Registry. Plusieurs déploiements utilisant la même image peuvent partager ce cache, tandis que l’opérateur gère les références et le nettoyage.

Comportement des deux systèmes de cache en production

La mise en cache des poids et celle des images n’ont pas la même sémantique de déploiement. AWS indique que la mise en cache des poids peut retarder la création du déploiement d’inférence jusqu’à ce que tous les nœuds cibles soient prêts, alors que la mise en cache des images ne bloque pas la création du déploiement. Un pod peut donc démarrer avant qu’un cache d’image soit terminé sur un nœud particulier et retomber sur un pull d’image normal.

Les deux mécanismes utilisent une planification préférentielle plutôt qu’obligatoire. Les pods sont orientés vers les nœuds disposant de données chaudes lorsque c’est possible, mais ils ne sont pas empêchés de s’exécuter ailleurs. Si un scale-out rapide dépasse le nombre de nœuds préparés, un pod peut utiliser la source modèle d’origine et télécharger son image normalement. Le compromis est un démarrage plus lent, pas un déploiement échoué.

L’opérateur gère deux ressources personnalisées sous-jacentes : ModelDataCacheConfig pour les poids du modèle et ModelImageCache pour les images de conteneur. Les utilisateurs activent la mise en cache via modelCacheConfig dans une ressource InferenceEndpointConfig ou JumpStartModel plutôt que de gérer directement ces objets de cycle de vie.

AWS indique également que les mises à jour du cache sont prises en charge lorsqu’une source de modèle ou une image change. L’opérateur crée un nouveau cache, déploie la version mise à jour, puis supprime l’ancien cache. L’objectif est d’éviter des poids obsolètes tout en prenant en charge des transitions sans interruption, même si le résultat pratique dépendra toujours de l’espace de stockage disponible sur les nœuds et du temps nécessaire pour remplir le cache de remplacement.

Le routage sensible au préfixe maintient l’utilité des caches de prompts LLM

Le deuxième changement de SageMaker cible une autre couche de la pile de service. De nombreuses requêtes LLM contiennent un préfixe long et répété — comme des instructions système, des documents récupérés, l’historique de conversation ou du code source — suivi d’un suffixe court propre à l’utilisateur. Des frameworks tels que vLLM et TensorRT-LLM peuvent réutiliser le cache key-value, ou KV, calculé pour ce préfixe répété.

Une distribution aléatoire des requêtes affaiblit cet avantage dans un endpoint multi-instances. Si des requêtes successives avec le même préfixe arrivent sur différentes machines, chaque instance peut devoir recalculer le contexte partagé. La nouvelle stratégie de routage sensible au préfixe de SageMaker Inference examine le début d’une requête et envoie de manière cohérente les préfixes correspondants à la même instance.

AWS indique que cette fonctionnalité peut aussi protéger la flotte d’un préfixe trop populaire. Si l’instance préférée atteint sa limite de concurrence configurée, la requête peut être redirigée vers une instance moins occupée. Cela peut sacrifier un cache hit pour une requête, mais évite de concentrer le trafic sur une seule machine. AWS ajoute également que l’ajout ou la suppression d’instances ne devrait déplacer qu’une portion limitée du trafic, contribuant à préserver la localité du cache pendant le scale-out.

La stratégie se configure par variante de production et peut être modifiée via la configuration de l’endpoint sans redéployer le modèle. AWS continue de proposer le routage aléatoire par défaut, ainsi que le routage au plus faible nombre de requêtes en attente pour les workloads dont la durée des requêtes varie. Le routage sensible au préfixe vise spécifiquement les workloads LLM avec contexte de début partagé et cache de préfixe activé.

Preuves, benchmarks et limites

AWS a comparé le routage sensible au préfixe au routage aléatoire en utilisant Llama 3.1 70B Instruct sur sept instances ml.p5.48xlarge avec vLLM et le cache de préfixe activés. Sur 16 configurations de test couvrant différents agencements d’endpoint et d’API, AWS rapporte jusqu’à 77 % de réduction du temps médian jusqu’au premier token, des gains de débit allant jusqu’à 16 % et une hausse du taux de cache hit KV d’environ 25 % à plus de 80 %.

Il s’agit de résultats de benchmark rapportés par le fournisseur, et non d’une évaluation indépendante. AWS indique que le trafic est resté équilibré pendant les tests, chaque instance recevant entre 13,3 % et 15,4 % des requêtes. AWS rapporte également un coût de routage supplémentaire de 1,3 à 1,9 milliseconde par requête, en comparaison de résultats de temps jusqu’au premier token du modèle allant de 63 à 280 millisecondes dans les configurations testées.

L’ampleur du bénéfice dépend fortement de la forme de la charge de travail. AWS indique que des préfixes partagés plus longs génèrent des gains plus importants, car davantage de calcul peut être évité. Parmi les cas d’usage identifiés par AWS figurent les systèmes RAG qui interrogent à plusieurs reprises le même document, les conversations multi-tours, les assistants à base de modèles et la complétion de code. Les workloads avec des prompts courts ou majoritairement uniques devraient en retirer moins de valeur.

Les affirmations concernant HyperPod dépendent aussi de conditions qui ne sont pas entièrement précisées dans la source, notamment la disponibilité des nœuds, le temps de remplissage du cache, la capacité de stockage, le format du modèle et les performances réseau lors du préchargement initial. La transition annoncée de dizaines de minutes à quelques secondes s’applique lorsqu’un pod arrive sur un nœud où les données pertinentes sont déjà mises en cache ; un nœud non préparé suit le chemin normal de téléchargement.

Ce que ces changements signifient pour les équipes d’infrastructure IA

Pour les constructeurs et les équipes de plateforme d’entreprise, ces annonces séparent deux décisions souvent traitées comme un seul problème de latence. La mise en cache des modèles améliore l’élasticité : elle peut rendre plus rapidement utile une nouvelle capacité lorsque le trafic augmente. Le routage sensible au préfixe améliore l’efficacité des requêtes : il peut réduire le travail de préremplissage répété une fois la capacité déjà en ligne.

La combinaison pourrait être utile aux applications RAG et aux assistants qui ont à la fois un trafic en rafales et de grands contextes répétés. Une équipe pourrait utiliser la mise en cache HyperPod pour préparer des nœuds à la montée en charge tout en utilisant le routage sensible au préfixe pour garder chauds les préfixes de documents ou de conversation sur la flotte active. Cela ne supprime pas le besoin de dimensionner la capacité NVMe locale, de configurer les limites de concurrence ou de mesurer les taux de cache hit en trafic réel.

Il y a aussi des questions de coût et de fiabilité que les acheteurs doivent tester. Conserver les poids sur chaque nœud cible consomme du stockage local et peut augmenter le temps de préparation avant qu’un déploiement soit prêt. L’affinité au préfixe peut améliorer la latence, mais elle introduit un comportement de routage dépendant du contenu que les équipes devraient observer en parallèle de la profondeur de file d’attente, de l’utilisation des instances, de l’occupation du cache et de la latence en queue de distribution. Les revues de confidentialité et de gouvernance des données peuvent également compter, car les décisions de routage inspectent le début des charges utiles des requêtes, même si AWS gère automatiquement le routage.

Ce qu’il faut surveiller ensuite

Les équipes qui évaluent ces fonctionnalités devraient rechercher des résultats reproduits indépendamment sur des modèles, du matériel et des distributions de prompts au-delà du test AWS sur Llama 3.1 70B. Les mesures les plus utiles incluront les p95 et p99 du temps jusqu’au premier token, les taux de cache hit pendant le scale-out et le pourcentage de requêtes arrivant sur des nœuds non préparés.

Des indications opérationnelles sur le dimensionnement du NVMe local, l’orchestration du warm-up du cache et les clusters multi-modèles seront également importantes. Les acheteurs devraient vérifier comment la préparation du cache affecte les déploiements, le remplacement de nœuds, les scénarios spot ou d’interruption et la montée en charge rapide au-delà de la flotte préchargée.

Enfin, les contrôles de routage au niveau de l’endpoint d’AWS pourraient devenir plus importants à mesure que les plateformes de service hébergées rivalisent davantage sur la latence prévisible que sur le seul accès au modèle. Le signal à surveiller sera de savoir si les clients peuvent utiliser ces contrôles sans ajouter une complexité de planification importante ni sacrifier un équilibrage GPU correct.

Point de vue de Creati.ai

AWS s’attaque à deux faiblesses pratiques dans les opérations LLM plutôt que d’introduire une nouvelle capacité du modèle. La mise en cache des modèles HyperPod réduit la pénalité liée à l’ajout de capacité, tandis que le routage sensible au préfixe rend plus fiable, sur plusieurs instances, une optimisation de service existante — la réutilisation du cache KV.

Le cas le plus convaincant concerne les workloads prévisibles, à contexte répété, avec suffisamment de trafic pour justifier le préchargement de grands modèles. Pour les équipes ayant surtout des prompts uniques ou des déploiements peu fréquents, la surcharge de stockage et de préparation peut l’emporter sur les gains. Les chiffres de benchmark d’AWS sont encourageants, mais les acheteurs d’infrastructure devraient les valider par rapport à leur propre chevauchement de prompts, leurs schémas de montée en charge et leurs objectifs de latence avant de considérer la mise en cache comme une amélioration garantie.