SageMaker HyperPod réduit de 82 % la latence du premier token avec un routage d’inférence Kubernetes natif
La passerelle d’inférence SageMaker HyperPod remplace le round-robin par un routage piloté par six signaux en temps réel, réduisant la latence du premier token jusqu’à 82 % sans toucher au code applicatif. Déployez-la en add-on EKS si vous servez plusieurs modèles ou un parc GPU hétérogène derrière un seul endpoint.
24 septembre 2026. AWS publie Amazon SageMaker HyperPod Inference Gateway, une couche de routage d’inférence Kubernetes native, déployable en add-on EKS sur une infrastructure HyperPod existante. 24 septembre 2026. AWS annonce une réduction de la latence du premier token jusqu’à 82 %, et des gains de 97 à 98 % sur le p99 du TTFT en trafic hétérogène ou en rafale. 28 septembre 2026. La sortie figure en tête du récapitulatif hebdomadaire AWS. Pourquoi c’est important : le goulot d’étranglement de l’inférence LLM s’est déplacé du calcul vers l’aiguillage — savoir vers quel GPU envoyer quelle requête — et cette passerelle s’attaque précisément à ce point.
Le round-robin est un angle mort de l’inférence
Pendant des années, le routage d’inférence s’est résumé à un round-robin : chaque requête part vers le prochain pod disponible, dans l’ordre. Ce modèle est correct pour des charges sans état et homogènes — un serveur web, une API classique. Il devient structurellement sous-optimal dès qu’on parle de grands modèles de langage, pour une raison simple : un pod de serveur de modèle n’est pas une boîte vide qui traite tout à la même vitesse.
Trois phénomènes brisent l’hypothèse du round-robin. D’abord, le KV cache : un serveur qui a déjà en mémoire les paires clé-valeur d’une conversation répond bien plus vite qu’un pod qui doit tout recomputer. Ensuite, le prefix cache : si un préfixe de prompt a déjà été mis en cache sur un pod donné, y renvoyer la requête évite un recomput coûteux. Enfin, les adaptateurs LoRA : un modèle affiné chargé sur certains pods mais pas sur d’autres impose de router vers le bon résident. Le round-robin ignore ces trois états et envoie la requête au mauvais endroit une fois sur deux — ce qui se paie en latence, en mémoire gaspillée et en GPU sous-utilisés.
Trois composants, un seul endpoint
La passerelle repose sur trois briques qui se partagent le travail. Le Envoy Endpoint termine le trafic HTTPS et expose un unique endpoint privé par cluster — les clients n’ont qu’une URL à connaître. Le Body-Based Router lit le nom du modèle directement dans chaque requête entrante et l’aiguille vers le bon pool de GPU : une seule passerelle peut donc servir plusieurs modèles derrière une même URL, sans modification côté client.
La brique décisive est le Endpoint Picker. Il note en continu chaque pod de serveur de modèle selon six signaux : l’utilisation du KV cache, la profondeur de file d’attente, la résidence des adaptateurs LoRA, le taux de succès du prefix cache, la latence prédite et le nombre de requêtes en cours. Chaque requête est envoyée vers le pod le mieux placé à l’instant t, pas vers le suivant dans une liste.
L’intérêt est qu’aucun de ces signaux n’est visible par un équilibreur de charge générique. Un ALB ou un Ingress ne sait pas qu’un pod a déjà le préfixe en cache ; le Endpoint Picker, si. C’est la différence entre router du trafic et router de l’inférence.
Ce que ça change pour un parc GPU hétérogène
Le gain annoncé est le plus net dans deux configurations qui font justement souffrir le round-robin. La première est le matériel hétérogène : quand un cluster mélange plusieurs générations de GPU — ou des instances de tailles différentes —, un aiguillage aveugle envoie indifféremment des requêtes lourdes vers des cartes modestes et des requêtes légères vers les plus puissantes. Le Endpoint Picker, en intégrant la latence prédite, rééquilibre de lui-même la charge vers la bonne puissance.
La seconde est le trafic en rafale. Un pic de requêtes sature brutalement les files ; le round-robin continue d’empiler sur des pods déjà pleins pendant que d’autres tournent à vide. En scorant la profondeur de file et le nombre de requêtes en cours, la passerelle évite d’aggraver l’embouteillage. C’est dans ces deux cas qu’AWS revendique les 97 à 98 % de réduction du p99 du TTFT — le chiffre qui compte pour un utilisateur final, bien plus que la latence moyenne.
Déploiement et limites actuelles
Le déploiement est pensé pour être non invasif : un add-on EKS géré, sans changement de code applicatif, compatible avec tout serveur de modèle OpenAI-compatible, notamment vLLM et SGLang. Le routage intra-cluster est disponible aujourd’hui dans toutes les régions où l’add-on SageMaker HyperPod est pris en charge.
Deux limites restent à connaître avant de l’adopter. La première est le périmètre : la version actuelle route à l’échelle d’un cluster, pas entre clusters ni entre régions. AWS annonce pour bientôt un routage inter-cluster et inter-région, avec un fleet gateway centralisé, un rate limiting global et un traffic shaping par niveau de coût. La seconde est l’infrastructure requise : il faut déjà être sur SageMaker HyperPod, ce qui réserve la solution aux équipes ayant adopté cette plateforme — pas à celles qui autogèrent leur Kubernetes d’inférence sur EC2 brut.
Un levier de coût autant que de latence
Le bénéfice ne se lit pas que sur les millisecondes. Un GPU d’inférence se loue à l’heure ou à la seconde ; un pod qui attend, ou qui recompute un préfixe déjà calculé ailleurs, est un GPU facturé pour rien. Le round-robin dilue la charge sur l’ensemble du parc, ce qui contraint à surprovisionner pour absorber les pointes — on paie de la capacité qu’on n’utilise pas. Le Endpoint Picker inverse cette logique en remplissant d’abord les pods les mieux placés, ce qui rapproche l’utilisation réelle du parc de son optimum.
La conséquence est double. D’abord, à débit équivalent, il faut moins de GPU : la réduction de 82 % de la latence du premier token et les gains de 97 à 98 % sur le p99 se traduisent mécaniquement en moins d’instances pour tenir le même niveau de service. Ensuite, la décision d’échelle devient plus propre : quand le routage est optimal, un autoscaler qui ajoute un pod agit sur un vrai manque de capacité, pas sur un défaut d’aiguillage. C’est ce qui distingue un système qui route bien d’un système qui compense en ajoutant des cartes.
Pour les équipes qui facturent l’inférence à leurs clients internes, le point est décisif : la latence du premier token n’est plus seulement un ressenti utilisateur, c’est un coût direct de GPU — et la passerelle attaque les deux en même temps. La métrique à surveiller avant et après le déploiement reste le p99 du TTFT en rafale : c’est lui qui dira si le routage au signal a réellement remplacé le surprovisionnement.
Verdict
Si vous servez plusieurs modèles ou un parc GPU hétérogène sur SageMaker HyperPod, déployez la passerelle dès maintenant : la réduction de latence du premier token jusqu’à 82 % se récupère sans modifier votre code, et l’add-on EKS s’intègre à l’existant. Si vous êtes en inférence multi-modèles derrière un round-robin maison, mesurez d’abord votre p99 de TTFT en rafale : c’est l’indicateur qui révélera si vous perdez de l’argent en GPU sous-utilisés — et si le routage au signal mérite de remplacer votre équilibreur. Et si vous attendez le routage inter-région ou inter-cluster, patientez : la version actuelle est intra-cluster, et les fonctionnalités de fleet annoncées arrivent dans un second temps.