Le routage sensible aux préfixes d’Amazon SageMaker réduit la latence, mais le contexte répété est déterminant

Le routage sensible aux préfixes d’Amazon SageMaker a réduit de jusqu’à 77 % le délai médian jusqu’au premier token dans les tests d’AWS, en modifiant la destination des prompts répétés. Au lieu de distribuer chaque requête sans tenir compte de son contenu, SageMaker peut désormais conserver les requêtes dont le début correspond sur la même instance de modèle. Les contextes déjà calculés ont ainsi davantage de chances de rester disponibles.

Le résultat remet en question une hypothèse fondamentale concernant la mise à l’échelle des points de terminaison de grands modèles de langage. Ajouter des instances ne produit pas automatiquement une inférence efficace lorsque l’équilibrage de charge classique sépare les requêtes des données utiles mises en cache. Une flotte peut disposer d’une capacité d’accélération abondante tout en retraitant à répétition les mêmes instructions, documents ou historiques de conversation.

AWS positionne donc le routage comme un élément de la pile d’optimisation de l’inférence, aux côtés des moteurs de modèles, des accélérateurs et des logiciels de mise en cache. L’adversaire immédiat est l’équilibrage de charge aveugle au cache, qui répartit uniformément le travail mais ignore ce que chaque instance connaît déjà. AWS fait état de gains substantiels, bien que ses chiffres les plus élevés proviennent d’un benchmark contrôlé à long contexte plutôt que de tests de production indépendants.

Le routage sensible aux préfixes d’Amazon SageMaker modifie le compromis par défaut

AWS a fait passer la localité des prompts d’une solution de contournement au niveau de l’application à la couche de routage des points de terminaison gérés.

AWS a annoncé cette fonctionnalité le 10 septembre 2026 pour les points de terminaison d’inférence en temps réel d’Amazon SageMaker. La nouvelle stratégie examine le début d’une requête entrante et oriente systématiquement les débuts correspondants vers la même instance.

L’idée sous-jacente est simple. De nombreuses requêtes LLM contiennent une grande section fixe suivie d’une section variable bien plus petite. Un assistant de service client peut recevoir le même document de politique et les mêmes consignes opérationnelles avant chaque nouvelle question client.

Une application de génération augmentée par récupération suit souvent le même schéma. Elle place un document récupéré avant la requête d’un utilisateur, de sorte que plusieurs questions sur ce document commencent par un texte identique. Les assistants de programmation renvoient également des fichiers, des imports, des instructions et le contexte des modifications récentes.

Les serveurs de modèles disposent déjà d’un mécanisme pour exploiter cette répétition. Un cache clé-valeur, couramment appelé cache KV, stocke les états d’attention calculés lorsque le modèle traite les tokens précédents. La mise en cache des préfixes conserve des états réutilisables entre des requêtes liées dont le début des prompts correspond.

Le problème apparaît lorsqu’un point de terminaison s’étend sur plusieurs instances. Un routage aléatoire peut envoyer des requêtes consécutives ayant le même préfixe vers des machines différentes. Chaque machine traite alors à nouveau ce contexte partagé, car l’entrée de cache utile se trouve ailleurs.

Le routage sensible aux préfixes d’Amazon SageMaker tente de préserver cette localité. Dix requêtes partageant un préfixe devraient normalement atteindre la même machine, permettant à son serveur de modèles de réutiliser le calcul mis en cache. Les requêtes présentant d’autres préfixes peuvent toujours être réparties dans la flotte.

Cette fonctionnalité ne remplace pas la mise en cache des préfixes au sein du moteur de service. Le conteneur doit toujours exécuter un logiciel capable de conserver et de réutiliser les états KV. AWS a testé cette stratégie avec vLLM et indique que les versions récentes de vLLM activent la mise en cache des préfixes par défaut.

Ce lancement ajoute un troisième choix de routage aux points de terminaison en temps réel de SageMaker. Le routage aléatoire reste la valeur par défaut et distribue le trafic sans tenir compte des relations entre les requêtes. Le routage selon le moins de requêtes en cours privilégie l’instance disposant de la plus grande capacité de traitement disponible.

Le routage sensible aux préfixes fait un pari différent. Il accepte une certaine affinité entre le contenu et les instances, car le calcul de prompt économisé peut l’emporter sur la valeur d’un trafic parfaitement interchangeable.

AWS a ajouté une protection contre la surcharge pour limiter ce risque. Lorsque l’instance privilégiée atteint un seuil de concurrence configuré, SageMaker envoie la requête vers une instance moins occupée. Cette requête peut perdre un hit de cache, mais elle devrait éviter de rejoindre une file d’attente surchargée.

Le service vise également à préserver la majeure partie du placement des requêtes lorsque la flotte change d’échelle. Selon AWS, l’ajout ou le retrait d’instances ne déplace qu’une partie du trafic. Ce comportement réduit la perturbation du cache qu’entraînerait une redistribution complète.

La configuration de routage officielle confirme ce comportement en cas de surcharge. Elle liste les stratégies aléatoire, selon le moins de requêtes en cours et sensible aux préfixes parmi les choix pris en charge.

Il s’agit de plus qu’un simple paramètre pratique, car cela modifie l’entité qui prend en charge un problème persistant de systèmes. Les équipes devaient auparavant créer une affinité de session, déployer des routeurs spécialisés ou accepter une réutilisation moindre du cache. SageMaker propose désormais un placement sensible au contenu au sein de sa couche de points de terminaison gérés.

Cette distinction sépare également cette fonctionnalité du routage de modèles. Elle ne choisit pas entre différents modèles de fondation selon le prix, la qualité ou le type de tâche. Elle choisit quelle instance de la même charge de travail déployée doit recevoir une requête.

Cette portée plus limitée est importante. AWS ne prétend pas qu’un seul interrupteur optimise chaque aspect du service LLM. L’entreprise s’attaque au travail de préremplissage répété, qui devient particulièrement coûteux lorsque les applications ajoutent un long contexte récurrent à chaque requête.

Le résultat de 77 % de latence provient de longs prompts partagés

AWS a enregistré sa plus forte amélioration lorsque chaque requête réutilisait un préfixe de 8 000 tokens, ce qui rendait le benchmark favorable à la localité du cache.

L’entreprise a comparé le routage sensible aux préfixes à la stratégie aléatoire par défaut de SageMaker. Son test utilisait Llama 3.1 70B Instruct, sept instances ml.p5.48xlarge et vLLM avec la mise en cache des préfixes activée.

AWS a exécuté 16 configurations sur des points de terminaison à modèle unique, des points de terminaison de composants d’inférence, l’API Invoke native et une API compatible OpenAI. L’entreprise a indiqué que chaque test s’était achevé avec succès.

Les résultats les plus marquants provenaient de charges de travail à long contexte maintenues pendant une heure. Chaque requête partageait un préfixe de 8 000 tokens, créant un important bloc de calcul répété que le cache pouvait éliminer.

Dans ces conditions, AWS indique que le délai P50 jusqu’au premier token a diminué de 71 % à 77 %. P50 correspond au résultat médian, ce qui signifie que la moitié des requêtes mesurées ont répondu plus vite et l’autre moitié plus lentement.

Le délai P90 jusqu’au premier token a diminué de 33 % à 37 %. Ce percentile représente une partie plus lente de la distribution des requêtes ; il compte donc souvent davantage pour les objectifs de niveau de service. L’amélioration plus faible du P90 suggère que le routage ne peut pas éliminer toutes les sources de latence de queue.

AWS a indiqué que les taux de hit du cache KV sont passés d’environ 25 % à jusqu’à 82 %. Le débit a augmenté de 15 % à 16 %, montrant que le travail de préremplissage évité a également libéré de la capacité de traitement.

Ces chiffres constituent l’argument central en faveur du routage sensible aux préfixes d’Amazon SageMaker. Le gain de latence médiane est frappant, mais l’évolution du taux de hit du cache explique pourquoi il s’est produit. Le routeur a rendu les calculs mis en cache existants plus souvent accessibles.

Les résultats ont été plus modestes avec des conversations de type ShareGPT plus courtes et de longueur variable. Sur des exécutions de 30 minutes, le délai médian jusqu’au premier token s’est amélioré de 13 % à 16 %. Le débit n’a augmenté que de 1,7 % à 2 %.

La latence P90 s’est néanmoins améliorée de 24 % à 37 % dans ces tests plus courts. Selon AWS, les taux de hit du cache sont passés d’environ 30 % à 80 %. Toutefois, chaque hit réussi évitait moins de travail, car les préfixes réutilisables étaient plus courts.

Ce contraste est le détail le plus utile du benchmark AWS. Le placement sensible aux préfixes n’est pas un multiplicateur fixe pour chaque application LLM. Sa valeur dépend de la quantité de contexte répétée et du coût de traitement de ce contexte.

La surcharge de routage rapportée se situait entre 1,3 et 1,9 milliseconde par requête. AWS a mesuré un délai du modèle jusqu’au premier token compris entre 63 et 280 millisecondes durant les tests. Dans cette plage, le calcul de routage représentait une part relativement faible du temps de réponse.

Le trafic est également resté équilibré dans les scénarios testés. Chacune des sept instances a reçu entre 13,3 % et 15,4 % des requêtes. Une répartition idéale attribuerait environ 14,3 % à chaque instance.

Ce résultat répond à l’objection la plus évidente concernant l’affinité de préfixe. Regrouper les requêtes correspondantes peut créer des points chauds si un préfixe devient disproportionnellement populaire. AWS indique que son seuil de surcharge a évité ce problème dans le benchmark.

Les chiffres nécessitent néanmoins une mise en perspective prudente. AWS a produit et publié les tests, et aucune organisation indépendante n’a vérifié les gains rapportés. L’entreprise n’a pas non plus présenté un vaste ensemble de traces de production provenant de clients sans lien entre eux.

Le test à long contexte crée intentionnellement une réutilisation substantielle. Cela convient à la mesure de l’effet visé par la fonctionnalité, mais ne représente pas tous les points de terminaison. Un service traitant des prompts courts et non liés offrirait bien moins de travail réutilisable.

Le benchmark compare également la nouvelle stratégie au routage aléatoire. Les équipes qui utilisent déjà un routeur personnalisé conscient du cache, une affinité de session ou un cache KV distribué pourraient constater un bénéfice incrémental moindre. Leur référence pertinente n’est pas nécessairement celle par défaut de SageMaker.

La conclusion la plus claire est donc conditionnelle. La fonctionnalité peut réduire fortement la latence lorsque les requêtes partagent de longs préfixes et que le moteur de service conserve leurs états KV. Elle ne fait pas la même promesse pour un trafic diversifié et résistant au cache.

Ce résultat conditionnel reflète des recherches plus larges sur la mise en cache des préfixes. Un article NeurIPS de 2025 a constaté qu’une rétention de cache plus intelligente améliorait l’efficacité, mais a également documenté les défis liés à la capacité limitée du cache et aux évictions.

Le routage résout une partie de ce système. Il accroît la probabilité qu’une requête atteigne une instance contenant un état pertinent. Il ne peut pas garantir que cet état reste en mémoire lorsque la requête arrive.

Le routage conscient du cache met les équilibreurs de charge classiques sous pression

Ce lancement révèle une incompatibilité entre l’équilibrage conventionnel des requêtes et le comportement avec état de l’inférence LLM moderne.

Les services web traditionnels considèrent souvent les répliques interchangeables comme une conception souhaitable. Un équilibreur de charge peut envoyer chaque requête vers n’importe quel serveur sain, en utilisant l’aléatoire ou la profondeur de file d’attente pour répartir le travail. L’application doit produire le même résultat quel que soit le placement.

Les répliques LLM peuvent produire des réponses équivalentes tout en présentant des coûts de préparation très différents. Un GPU peut déjà contenir les états d’attention d’un long contrat, d’un fichier de code ou d’une conversation. Un autre GPU peut devoir reconstruire ces états avant de générer son premier token.

Le routage aveugle au cache ignore cette différence. Il peut sélectionner la file la moins remplie tout en choisissant la machine ayant le plus de travail de préremplissage dupliqué. Une machine localement plus occupée peut répondre plus tôt parce qu’elle contient déjà le préfixe correspondant.

Cette tension n’est pas propre à AWS. Les systèmes d’inférence open source traitent également l’ordonnancement des requêtes et l’emplacement du cache comme des problèmes liés. Ce mouvement inclut des piles basées sur vLLM, des passerelles Kubernetes spécialisées, des caches distribués et des architectures de préremplissage-décodage.

AWS a évoqué une version plus élaborée au sein de SageMaker HyperPod. Son routage intelligent prend en charge des stratégies sensibles aux préfixes, conscientes du KV et round-robin, parallèlement à une mise en cache par niveaux.

La conception HyperPod peut suivre les préfixes mis en cache et étendre le stockage au-delà de la mémoire GPU. Elle utilise la mémoire CPU locale comme niveau de cache et peut fournir un second niveau distribué. Cette approche répond aux besoins d’infrastructures plus vastes, gérées par Kubernetes, avec un contrôle opérationnel plus poussé.

La nouvelle fonctionnalité de point de terminaison en temps réel joue un rôle plus simple. Elle maintient les requêtes à proximité des emplacements de cache probables sans obliger les utilisateurs à exploiter un cluster d’inférence ou un cache distribué. Elle rend ainsi cette technique accessible aux équipes qui utilisent des points de terminaison managés standard.

L’environnement managé exerce aussi une pression particulière sur les projets de routage personnalisés. AWS ne propose pas nécessairement tous les signaux de placement ou toutes les politiques de gestion de cache pris en charge par ces projets. L’entreprise réduit l’effort nécessaire pour obtenir une part significative des bénéfices.

Pour les équipes plateforme, cela peut modifier le calcul entre développement interne et achat. Un routeur personnalisé exige déploiement, mises à niveau, télémétrie, gestion des défaillances et coordination avec l’autoscaling. Une configuration de production est plus facile à adopter lorsque ses contraintes correspondent à la charge de travail.

La pression concurrentielle atteint également les autres fournisseurs d’inférence managée. Les clients peuvent de plus en plus évaluer une plateforme LLM selon sa capacité à coordonner routage, mise en cache et montée en charge, et non seulement selon les modèles ou les types d’accélérateurs disponibles.

C’est important, car l’efficacité de l’inférence dépend de plus en plus de l’ensemble du chemin de serving. La quantification des modèles peut réduire l’utilisation de mémoire. Le batching continu peut combiner les requêtes actives. Le décodage spéculatif peut accélérer la génération de tokens dans des conditions adaptées.

Le placement tenant compte du cache s’attaque à une autre source de gaspillage. Il évite de répéter un traitement de prompt que le système a déjà effectué. Ces méthodes peuvent coexister, ce qui incite les fournisseurs d’infrastructure à les proposer sous la forme d’une pile intégrée.

Le travail d’AWS sur l’inférence désagrégée illustre cette orientation. L’architecture sépare le préremplissage, intensif en calcul, du décodage, intensif en bande passante mémoire, et coordonne les transferts KV entre les workers.

Cette conception plus avancée traite l’inférence comme un problème de systèmes distribués. Les décisions de routage tiennent compte de la pression sur les files d’attente, de l’emplacement du cache et des rôles spécialisés des workers. Un répartiteur de charge réseau générique ne dispose pas de ces signaux au niveau de l’application.

Le routage classique conserve néanmoins des usages valides. Un placement aléatoire reste adapté lorsque les requêtes sont indépendantes ou lorsque le modèle ne dispose pas d’un cache de préfixes efficace. La politique de moindre nombre de requêtes en cours peut aider lorsque les temps de traitement varient et que le contexte partagé offre peu de localité.

Le routage tenant compte des préfixes n’est donc pas un remplacement universel. C’est une stratégie spécifique à la charge de travail, qui privilégie le contexte réutilisable plutôt qu’une distribution parfaitement uniforme des requêtes. Le contrôle de surcharge d’AWS tente de concilier ces deux objectifs.

Cette fonctionnalité devrait intéresser les équipes qui développent des assistants documentaires et des systèmes de recherche internes. Ces applications présentent à plusieurs reprises les mêmes manuels, politiques, spécifications ou dossiers de projet avant de modifier la question.

Les équipes qui créent une base de connaissances interrogeable devraient reconnaître ce schéma. La qualité de la recherche détermine le contexte introduit dans le prompt, tandis que le routage détermine si le traitement de ce contexte peut être réutilisé.

Les agents multi-tours constituent un autre bon candidat. Chaque nouveau tour inclut souvent les messages précédents, les instructions d’outils et l’état accumulé de la tâche. Ce début commun croissant rend la phase de préremplissage plus coûteuse tout en créant une possibilité de réutilisation du cache.

Les assistants de programmation présentent également une localité marquée. Plusieurs requêtes peuvent partager les instructions du dépôt, un fichier ouvert, des symboles voisins et l’historique de la conversation. La requête de complétion finale change, mais une grande partie du contexte qui la précède reste stable.

Ces schémas expliquent pourquoi le routage est devenu aujourd’hui une fonctionnalité concurrentielle. Les fenêtres de contexte plus longues ont encouragé les applications à envoyer davantage de documents de référence à chaque appel. Les flux de travail d’agents répètent aussi des instructions et des historiques importants sur de nombreuses étapes.

Le nouveau goulot d’étranglement ne réside pas seulement dans le nombre de tokens générés. Il consiste à préparer de façon répétée de grandes entrées familières avant le début de la génération. Le délai avant le premier token devient ainsi un enjeu produit distinct de la vitesse de génération des tokens.

Ce que le benchmark ne garantit pas

Le routage tenant compte des préfixes améliore les chances de réutilisation du cache, mais la sérialisation, l’éviction, l’isolation des tenants et la répartition asymétrique du trafic peuvent annuler l’avantage attendu.

La première incertitude concerne l’adéquation avec la charge de travail. Un point de terminaison servant des prompts sans lien entre eux peut produire peu de correspondances de préfixes utiles. Dans cet environnement, le routeur ajoute un faible coût de décision sans éviter beaucoup de calculs du modèle.

Même des prompts apparemment similaires peuvent ne pas correspondre. L’API Invoke native de SageMaker fonde son préfixe de routage sur les octets du corps de la requête. Des différences dans les espaces JSON, l’ordre des champs ou le formatage peuvent modifier ces octets.

Les applications doivent donc sérialiser les requêtes de manière cohérente. Un prompt système stable ne suffit pas si les bibliothèques clientes l’encapsulent différemment. Les équipes utilisant plusieurs services ou langages de programmation devraient vérifier que des requêtes équivalentes produisent des entrées de routage identiques.

L’API compatible OpenAI utilise à la place des caractères extraits du texte des messages. Cela élimine une partie de la sensibilité au JSON brut, même si les changements dans la séquence de messages affectent toujours le préfixe. Des métadonnées dynamiques placées tôt dans un prompt peuvent disperser des requêtes connexes.

La longueur du préfixe ajoute un autre problème de réglage. SageMaker accepte une plage configurée de 1 024 à 65 536. Pour l’API native, cette valeur représente des octets ; pour l’API compatible OpenAI, elle représente des caractères.

Une sélection courte peut regrouper trop de requêtes autour d’un début générique. Cela accroît le risque de diriger un trafic excessif vers une seule instance. Le seuil de concurrence déclenche alors un débordement, sacrifiant l’affinité de cache afin de préserver la capacité.

Une sélection longue crée le problème inverse. De petites différences apparaissant dans la région sélectionnée peuvent séparer des requêtes qui partagent autrement un contexte coûteux. La flotte reste équilibrée, mais l’amélioration du taux de cache touché diminue.

La valeur correcte dépend de la structure réelle des prompts. Les équipes doivent savoir où se terminent les instructions partagées et où commence le contenu unique. Elles ont également besoin de suffisamment de contenu distinctif pour empêcher qu’un modèle largement utilisé ne devienne un seul compartiment de routage.

L’éviction du cache reste hors du contrôle direct du routeur. La mémoire GPU est limitée, et les serveurs de modèles doivent récupérer des blocs KV à mesure que de nouvelles requêtes arrivent. Une requête peut atteindre l’instance attendue après que l’entrée pertinente a déjà disparu.

La recherche sur le cache de préfixes citée plus haut a montré que la politique d’éviction affecte sensiblement les taux de succès. Cela suggère que placement et rétention doivent être évalués conjointement.

L’autoscaling crée une autre source de perturbation du cache. AWS indique que la majeure partie du trafic reste mappée lors des changements de flotte, mais les nouvelles instances démarrent sans préfixes locaux utiles. Les événements d’extension peuvent temporairement réduire les taux de succès jusqu’à ce que les contextes populaires réchauffent ces machines.

Les événements de réduction peuvent supprimer des machines détenant des entrées précieuses. Un remappage stable limite la perturbation, mais ne peut pas préserver le contenu du cache sur une instance qui disparaît. Des changements soudains de trafic pourraient donc affaiblir le résultat du benchmark en régime établi.

Les préfixes populaires créent également un conflit fondamental. Maintenir chaque requête correspondante sur une seule machine maximise la localité jusqu’à saturation de cette machine. Répartir le trafic protège la latence sous charge, mais duplique les calculs mis en cache sur davantage d’instances.

Le ConcurrencyThreshold de SageMaker expose directement ce compromis. La valeur autorisée va de 1 à 1 024 requêtes en cours. Un seuil prudent favorise la distribution de charge, tandis qu’un réglage plus élevé préserve plus longtemps l’affinité.

Il n’existe pas de seuil unique correct pour chaque modèle. Les prompts volumineux, les sorties longues, les réglages de quantification, le parallélisme tensoriel et le comportement de batching influencent tous le niveau de concurrence sûr. Les opérateurs doivent régler cette valeur en fonction de leurs propres objectifs de niveau de service.

La séparation des tenants exige une attention similaire. Deux organisations peuvent utiliser des instructions système identiques tout en nécessitant une gestion opérationnelle indépendante. SageMaker prend en charge un identifiant optionnel tenant compte des préfixes afin de séparer leurs groupes de routage.

Les utilisateurs de l’API native peuvent fournir X-Amzn-SageMaker-Prefix-Aware-Id, avec jusqu’à 64 caractères ASCII. Les requêtes compatibles OpenAI peuvent utiliser le champ prompt_cache_key. AWS combine l’identifiant avec le préfixe lors de la sélection d’une instance.

Cette fonctionnalité fournit une isolation de routage, mais l’annonce d’AWS ne doit pas être interprétée comme une affirmation générale sur l’isolation des données dans tous les frameworks de serving. Les équipes doivent toujours évaluer le comportement des conteneurs, la gestion de la mémoire, la journalisation et l’ensemble de leur modèle de sécurité.

La fonctionnalité exige également au moins deux instances pour produire une différence de routage significative. Avec une seule instance, chaque requête atteint déjà le même endroit. Les petits déploiements ne tirent donc aucun bénéfice de l’affinité de placement elle-même.

AWS indique qu’aucune modification du conteneur de modèle n’est nécessaire au niveau du routage du point de terminaison. Toutefois, le framework de serving doit toujours disposer d’un cache de préfixes fonctionnel. Un moteur incompatible ou incorrectement configuré recevra un trafic localisé sans réutiliser les calculs sous-jacents.

La combinaison Llama 3.1 70B et vLLM du benchmark vérifie une configuration importante. Elle n’établit pas des améliorations identiques pour chaque architecture, runtime, méthode de quantification, configuration d’adaptateur ou distribution de prompts.

Les adaptateurs dynamiques Low-Rank Adaptation ajoutent une autre couche de placement. AWS indique que la sélection tenant compte des préfixes s’effectue parmi les instances qui détiennent déjà l’adaptateur demandé. Cet ensemble éligible plus restreint peut limiter les options d’équilibrage du routeur.

Enfin, la métrique la plus visible ne couvre pas l’ensemble de l’expérience utilisateur. Le délai avant le premier token affecte la réactivité perçue, notamment dans les produits interactifs. Il ne décrit pas directement la qualité de sortie, le temps total de génération ni la fiabilité de complétion.

Les améliorations de débit étaient également bien plus modestes que les gains de latence médiane. Le débit en contexte long a augmenté jusqu’à 16 %, tandis que le débit en contexte court n’a pas dépassé 2 % dans les tests d’AWS. La planification de capacité devrait utiliser la métrique pertinente plutôt que la seule latence mise en avant.

Pour ces raisons, le chiffre de 77 % doit être considéré comme un résultat maximal issu du benchmark d’AWS. Il démontre que la localité peut compter considérablement, mais ne constitue pas une garantie de performance pour chaque point de terminaison SageMaker.

Trois signaux indiqueront si les gains se maintiennent en production

Le prochain test consiste à déterminer si les clients peuvent reproduire les gains de cache d’AWS sans créer de points chauds instables ni fournir un travail important d’ingénierie des prompts.

Le premier signal est la télémétrie de cache en production. Les équipes devraient comparer le routage aléatoire et le routage tenant compte des préfixes à l’aide de la même trace de trafic, de la même taille de flotte, du même moteur de serving et de la même politique d’autoscaling. La latence médiane seule n’expliquera pas le résultat.

Le taux de succès du cache KV devrait augmenter parallèlement à une baisse de la latence de préremplissage. Les opérateurs devraient également suivre les délais P90 et P99 avant le premier token, la profondeur des files d’attente, la fréquence de débordement et la distribution du trafic au niveau des instances.

Si les succès du cache progressent tandis que la latence de queue reste stable, l’argument central d’AWS devient plus solide. Si la latence médiane diminue mais que les débordements ou la latence P99 se dégradent, le bénéfice exigera des critères de déploiement plus restreints.

La comparaison devrait inclure les démarrages à froid et les périodes de montée en charge. Un benchmark d’une heure en régime établi peut masquer le coût de préchauffage qui apparaît après les déploiements, le remplacement d’instances ou une extension soudaine. Les services réels connaissent régulièrement ces transitions.

Le deuxième signal concerne des éléments plus larges liés à l’exécution et aux modèles. AWS a testé un important modèle ouvert avec vLLM, mais les clients exploitent des architectures et des conteneurs variés. Les résultats sur des modèles plus petits, des mélanges d’experts, des modèles quantifiés et des charges de travail à sorties longues préciseront la portée de cette fonctionnalité.

Les charges de travail à contexte court méritent une attention particulière, car AWS y a déjà constaté des gains de débit plus faibles. Si des tests indépendants ne reproduisent que des améliorations modestes, le routage tenant compte des préfixes restera surtout utile pour les applications riches en documents et agentiques.

Si des bénéfices comparables apparaissent avec des modèles et des schémas de prompts variés, la localité du routage s’imposera comme une exigence standard de l’inférence gérée. Les autres fournisseurs subiront une pression pour proposer une configuration et une observabilité similaires.

Le troisième signal est le passage d’une affinité heuristique des préfixes à un routage explicite fondé sur l’état du cache. La similarité des préfixes estime où un état utile devrait se trouver. Les systèmes conscients du KV peuvent suivre les blocs réels, les événements d’éviction ou les transferts dans l’ensemble de la flotte.

AWS propose déjà des options plus avancées tenant compte du cache via SageMaker HyperPod. Ses endpoints temps réel pourraient à terme exposer des signaux de cache plus riches, la prise en charge de caches distribués ou des politiques plus adaptatives. Les concurrents et les projets open source suivent des orientations similaires.

Si les endpoints gérés acquièrent une perception précise de l’état du cache, la version actuelle apparaîtra comme une première couche accessible d’une transition plus vaste. Si la complexité maintient ces fonctionnalités dans des clusters spécialisés, le routage tenant compte des préfixes pourrait rester le compromis pratique.

Pour les développeurs, l’action immédiate consiste à mesurer plutôt qu’à migrer sur la base d’hypothèses. Identifiez les sections de prompts répétées, normalisez la sérialisation, activez la mise en cache des préfixes au niveau du moteur et testez plusieurs longueurs de préfixe. Comparez les distributions de latence, et pas seulement les moyennes.

Les acheteurs en entreprise devraient demander aux fournisseurs où réside l’intelligence de routage et quelles métriques ils exposent. Une plateforme qui annonce la mise en cache des préfixes sans préserver la localité entre les réplicas pourrait offrir des taux de succès décevants à grande échelle.

Les travailleurs du savoir en ressentiront les effets indirectement. Les assistants documentaires, les outils de programmation et les agents de longue durée devraient commencer à répondre plus vite lorsqu’ils réutilisent à plusieurs reprises le même contexte. Le gain devrait se manifester avant le premier token généré, pas nécessairement pendant toute la réponse.

Le routage tenant compte des préfixes d’Amazon SageMaker défend de manière convaincante l’idée que l’équilibrage de charge doit comprendre le contexte LLM réutilisable. Les résultats d’AWS montrent à quel point un placement aveugle au cache peut devenir coûteux avec un préfixe partagé de 8 000 tokens.

La question ouverte est de savoir à quelle fréquence le trafic réel présente cette configuration favorable. Les équipes devraient tester leurs propres traces, y compris les événements de mise à l’échelle et les préfixes très sollicités, avant de considérer le chiffre mis en avant comme une prévision opérationnelle.

Surveillez le taux de réussite du cache, les requêtes les plus lentes et la fréquence du routage de débordement. Ensemble, ces mesures indiqueront si SageMaker préserve un contexte utile ou se contente de réorganiser le trafic.