AWS lance SageMaker HyperPod Inference Gateway pour le routage conscient du GPU

Amazon Web Services a annoncé Amazon SageMaker HyperPod Inference Gateway le 18 septembre 2026, un système de routage natif Kubernetes et sensible au GPU pour l’inférence de grands modèles de langage qui se déploie comme un module géré unique pour Amazon EKS sur l’infrastructure HyperPod existante. AWS a déclaré que la passerelle peut réduire la latence du premier jeton jusqu’à 82 %.

Le problème de routage derrière la passerelle

Selon AWS, les algorithmes d’équilibrage de charge par défaut de Kubernetes, tels que le round-robin et le least-connections, n’ont aucune visibilité sur l’état du GPU : quels pods ont saturé les caches KV, quels sont à mi‑parcours de générations à long contexte, et quels possèdent déjà l’adaptateur LoRA dont une requête a besoin chargé en mémoire. L’entreprise a indiqué que les requêtes s’accumulent derrière les pods occupés tandis que la capacité inoccupée reste inutilisée, que la latence du premier jeton dépasse quatre secondes lors de pics de trafic, que l’utilisation devient inégale et imprévisible, et que les opérateurs sur‑provisionnent pour compenser. AWS a décrit un scénario dans lequel un utilisateur de chatbot attendant 4,4 secondes pour un premier jeton le voit finalement en moins de 800 millisecondes.

Architecture à deux niveaux

La passerelle utilise une conception à deux niveaux basée sur des primitives natives de Kubernetes. AWS a indiqué qu’elle utilise des signaux GPU en temps réel pour affecter chaque requête d’inférence au pod le mieux adapté. Le niveau 1 s’installe directement sur chaque HyperPod ou cluster EKS en tant que module complémentaire amazon-sagemaker-hyperpod-inference et comprend trois composants, tous construits sur l’extension open‑source Gateway API Inference. Envoy Gateway, un proxy de couche 7, termine le trafic HTTPS entrant et expose un point de terminaison privé unique par cluster. Le routeur basé sur le corps (Body‑Based Router) examine chaque corps de requête compatible OpenAI, extrait le champ modèle et dirige la requête vers le pool de modèles approprié, de sorte qu’une seule passerelle puisse servir plusieurs modèles.

Le sélecteur d’endpoints (Endpoint Picker) consomme les métriques Prometheus en temps réel de chaque pod de service de modèle et applique un algorithme de notation pondérée à travers des évaluateurs couvrant l’utilisation du cache KV, la profondeur de la file d’attente, la résidence de l’adaptateur LoRA, le taux de succès du cache de préfixes et les requêtes en cours. Chaque évaluateur possède un poids configurable, permettant d’ajuster le comportement de routage pour une charge de travail spécifique, comme le chat sensible à la latence versus le traitement par lots optimisé pour le débit.

Le niveau 2, le Global Inference Router, est annoncé comme prochainement disponible. AWS a déclaré qu’il ajoutera une coordination à l’échelle de la flotte entre plusieurs clusters et régions, avec basculement inter‑clusters, limitation de débit globale et mise en forme du trafic consciente des coûts. Le niveau 2 s’appuie sur le niveau 1, tandis que la passerelle de chaque cluster continue de gérer le routage local.

Déploiement, gestion des pannes et observabilité

Le déploiement consiste en une seule commande aws eks create-addon et une ressource personnalisée déclarative InferenceGatewayConfig qui définit les modèles et le comportement de routage, les déploiements de serveurs de modèles existants étant découverts via les étiquettes des pods. AWS a indiqué que l’installation ne nécessite ni sidecars, ni maillage de services, ni modifications du code applicatif. La passerelle expose un point de terminaison standard compatible OpenAI via HTTP ; selon AWS, le code client existant fonctionne sans modification, sans changements de SDK et sans signature SigV4 pour le trafic d’inférence.

Pour les charges de travail servant des adaptateurs LoRA finement ajustés sur un modèle de base partagé, le LoRA Affinity Scorer du Endpoint Picker dirige les requêtes d’adaptateur vers les pods qui ont déjà l’adaptateur demandé résident dans mémoire GPU ; si aucun pod ne le possède chargé, la requête est envoyée au pod disposant de la plus grande capacité disponible. AWS a indiqué que cela élimine la latence liée à l’échange d’adaptateur.

Les comportements de défaillance documentés couvrent la défaillance de pod, l’épuisement du pool, la défaillance de cluster et la défaillance régionale. En cas de défaillance de pod, le Endpoint Picker exclut les pods avec des métriques obsolètes et redirige vers des pods sains, se rétablissant automatiquement lorsque les métriques reprennent. En cas d’épuisement du pool, la passerelle renvoie HTTP 429 avec un en‑tête Retry‑After tandis que l’autoscaling ajoute de la capacité. En cas de défaillance de cluster, le Global Inference Router détecte un battement de cœur obsolète et redirige le trafic en moins de 35 secondes, avec une montée en puissance progressive lorsque le cluster est réintroduit. En cas de défaillance régionale, le routage inter‑régional s’active automatiquement, ce que AWS indique entraîner une latence plus élevée mais aucun impact sur la disponibilité.

La passerelle émet des métriques aux niveaux du pod, du pool, du cluster et de la flotte : utilisation du cache KV, profondeur de la file d’attente, requêtes en cours et résidence des adaptateurs via Prometheus au niveau du pod ; totaux de requêtes, histogrammes de durée et comptages de jetons via Prometheus et Grafana au niveau du pool ; moyenne du cache KV, taux d’erreur et latence P99 via Amazon CloudWatch au niveau du cluster ; ainsi que décisions de routage, événements de basculement et dépassements de limites via CloudWatch au niveau de la flotte.

Résultats de benchmark rapportés par AWS

AWS a indiqué avoir évalué quatre modèles allant de 8 milliards à 235 milliards de paramètres sur des instances p5.48xlarge équipées de GPU H100 et des instances g5 avec GPU A10G. Tout le trafic a été routé via des Application Load Balancers internes, reproduisant le chemin suivi par une requête de production, avec un groupe de nœuds client dédié générant une charge contrôlée et des serveurs de modèles isolés sur un groupe de nœuds serveur distinct. Chaque résultat utilise la configuration de routage par défaut de la passerelle sans réglage et est mesuré par rapport à une référence round‑robin Kubernetes sur les mêmes réplicas de modèle, selon AWS.

Dans les résultats rapportés, une flotte GPU à générations mixtes a réduit la latence time‑to‑first‑token P95 et P99 de 97 % chacune pour Llama‑3.1‑8B, avec une augmentation du débit de 8 %, et de 98 % et 97 % pour Qwen3‑32B, avec une hausse du débit de 50 %. Sous un trafic bursty, Llama‑3.1‑70B a affiché des réductions P95 et P99 de 94 % et 98 % avec un débit 12 % plus élevé, tandis que Qwen3‑235B a présenté une latence P95 comparable et un P99 inférieur de 89 %. Avec des préfixes de requête partagés, la latence P95 et P99 de Llama‑3.1‑8B a chuté de 26 % et 43 %.

AWS a indiqué que, sur une flotte entièrement homogène en trafic stable, la passerelle offre des performances comparables à celles du round‑robin, et elle a défini les résultats comparables comme des différences se situant dans la variance d’une exécution à l’autre. L’entreprise a précisé que les améliorations sont les plus importantes là où le round‑robin rencontre le plus de difficultés : matériel mixte, demande bursty et préfixes de requête partagés.

Disponibilité et feuille de route

AWS décrit la passerelle comme conforme à l’API Kubernetes Gateway et à son extension Inference, configurée via une unique définition de ressource personnalisée, et compatible avec tout serveur de modèles compatible OpenAI, y compris vLLM, SGLang et TGI. La gestion s’effectue via kubectl, GitOps, Helm et ArgoCD, l’installation, les mises à jour et les retours en arrière étant pris en charge par le cycle de vie du module complémentaire EKS.

Le routage de niveau 1 par cluster est disponible à compter du 18 septembre 2026, dans les régions où le module d’inférence est proposé. Au‑delà du Global Inference Router, les éléments de feuille de route nommés par AWS comprennent le fractionnement de trafic canari, qui dirigera un pourcentage du trafic vers de nouvelles versions de modèles à l’aide de ressources personnalisées InferenceModelRewrite, ainsi que le contrôle de flux qui classe les requêtes comme Critiques, Standard ou Déchargeables avec un contrôle d’admission par bande.