Le load balancer ignore l’information la plus chère
Un agent de codage envoie un premier prompt, reçoit une réponse, lance un outil, puis renvoie l’historique enrichi. À chaque tour, le contexte grandit. Le moteur calcule un KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire pour ne pas retraiter tous les tokens passés pendant la génération. Tant que la requête suivante revient sur le même worker, une partie de ce calcul peut être réutilisée.
Un load balancer HTTP ne voit pas ce cache. Il connaît le nombre de connexions ou le temps de réponse des serveurs, pas les blocs de tokens conservés sur chaque GPU. Le trentième tour peut donc partir vers un worker moins chargé qui ne possède aucun des vingt-neuf tours précédents. Ce worker recommence le prefill, alloue un nouveau cache, puis produit la réponse. Le cluster paraît équilibré au niveau réseau alors qu’il duplique le travail au niveau GPU.
Le routeur d’inférence doit répondre à une question plus riche : quel worker peut traiter cette requête au coût marginal le plus faible ? La réponse dépend de la charge, mais aussi du préfixe déjà présent en cache, de l’espace HBM disponible, de la phase d’exécution et du coût d’un éventuel transfert entre nœuds.
Notre analyse du KV cache détaillait le stockage et le transfert des blocs. Le sujet change ici : nous regardons la couche qui décide où une requête doit s’exécuter. Infera, Dynamo et llm-d proposent tous un routage conscient du cache, mais le mot « orchestrateur » masque trois architectures différentes.
Trois projets, trois frontières
AMD a publié Infera le 23 juillet 2026 comme une distributed inference reference solution pour les accélérateurs Instinct. La version 0.1 coordonne vLLM, SGLang ou ATOM. Elle expose une API compatible OpenAI, traduit aussi les requêtes Anthropic, enregistre les workers dans etcd et propose un routeur Python ou Rust.
NVIDIA Dynamo existe à une autre échelle de produit. Sa version stable 1.3.0, publiée le 22 juillet 2026, sépare la pile en trois plans : les requêtes, le contrôle du déploiement, puis le stockage et les événements KV. Le projet inclut le routeur, un Planner pour dimensionner les pools, un opérateur Kubernetes, KVBM pour la mémoire du cache et NIXL pour les transferts.
llm-d part de Kubernetes. Sa version 0.8.1, publiée le 26 juin 2026, associe un proxy, par exemple Envoy, à un Endpoint Picker qui choisit le pod. Le modèle tourne dans vLLM ou SGLang. Les fonctions avancées arrivent sous forme de briques : routage KV-aware, séparation prefill/decode, prédiction de latence, déport du cache et autoscaling. Le projet est entré dans la CNCF au niveau Sandbox le 12 mars 2026, un statut de gouvernance et d’incubation, pas une certification de production.
Cette différence de frontière change la comparaison. Infera 0.1 cherche d’abord à rendre plusieurs moteurs exploitables sur MI355X. Dynamo livre une plateforme liée à l’écosystème CUDA, avec davantage de fonctions intégrées. llm-d privilégie les interfaces Kubernetes et la composition de composants remplaçables.
| Projet | Infera 0.1.x | Dynamo 1.3.0 | llm-d 0.8.1 |
|---|---|---|---|
| Périmètre | Référence distribuée AMD | Plateforme intégrée | Composition Kubernetes |
| Moteurs documentés | vLLM, SGLang, ATOM | vLLM, SGLang, TensorRT-LLM | vLLM, SGLang |
| Matériel couvert | MI355X validé | Images officielles CUDA 13 | CUDA, ROCm, XPU, CPU, tests TPU |
| Routage KV-aware | Oui | Oui | Oui, approximatif ou précis |
| Prefill / decode séparés | Oui | Oui | Oui |
| Cache hiérarchique | vLLM livré, autres moteurs en cours | KVBM intégré | Connecteurs natifs ou externes |
| Autoscaling | Prévu | Planner, limites connues en 1.3.0 | KEDA ou WVA, SLO de latence encore expérimental |
| Multimodal | Prévu | Livré, activation explicite | Promu en production dans le cycle 0.8 |
Infera : rendre visible le cache d’un cluster AMD
Le routeur Infera reçoit les événements du moteur lorsqu’un bloc KV est créé ou évincé. Il peut ainsi estimer la part du préfixe déjà présente sur chaque worker. Le score combine cette réutilisation avec le travail en cours. Envoyer la requête vers le GPU qui détient le plus de blocs n’est pas toujours optimal : si sa file est saturée, le coût d’attente peut dépasser celui d’un prefill partiel sur un autre worker. Le routeur arbitre entre ces deux coûts.
La disaggregation Séparation du pipeline d'inférence en phases distinctes (prefill, decode) exécutées sur des nœuds spécialisés. Permet d'affecter du matériel compute-bound au prefill et du matériel memory-bound au decode, au lieu de faire tourner les deux sur le même GPU sous-utilisé sur l'une des deux phases. ajoute une seconde décision. Infera choisit un pool prefill pour absorber le prompt, puis transfère le cache vers un pool decode. Mooncake et MoRI-IO assurent les chemins RDMA documentés. La topologie peut réserver quatre GPU en parallélisme tensoriel au prefill et répartir les decode sur plusieurs répliques à deux GPU, comme dans le benchmark agentique d’AMD.
Le troisième mécanisme est le déport du cache. Le composant kvd maintient les métadonnées, tandis que les données peuvent descendre de la HBM vers la RAM hôte, le NVMe local ou un système de fichiers partagé. Le chemin AIC documenté peut transférer de la HBM vers le NVMe ou le NFS sans étape intermédiaire dans la DRAM du CPU. Cette fonction n’a cependant pas la même couverture selon le moteur : la matrice Infera 0.1 marque le cache hiérarchique comme pris en charge avec vLLM, mais encore en cours pour SGLang et ATOM.
La compatibilité est tout aussi étroite. La matrice officielle valide MI355X avec ROCm 7.2 et des combinaisons précises de vLLM, SGLang et ATOM. La feuille de route indique que le multimodal, l’autoscaling dynamique, les objectifs de service configurables et le parallélisme d’experts sur 32 GPU ou plus ne sont pas encore livrés.
Dynamo : le routeur n’est qu’un plan parmi trois
La documentation d’architecture de Dynamo distingue le plan des requêtes, le plan de contrôle et le plan de stockage. Cette séparation rend possible une décision locale au routeur tout en laissant le Planner modifier le nombre de workers.
Le score de routage illustre ce niveau de détail. Pour le prefill, Dynamo additionne les tokens déjà actifs et le prompt entrant, puis soustrait un crédit correspondant aux blocs retrouvés sur le GPU, dans la RAM hôte, sur disque ou dans un cache partagé. Chaque niveau reçoit un poids différent. Pour le decode, le coût inclut le KV actif et les nouveaux blocs attendus. Le worker admissible au coût le plus faible reçoit la requête. Un préfixe présent sur SSD vaut donc moins qu’un préfixe déjà en HBM, mais plus qu’un cache absent.
La version 1.3 ajoute un service de sélection autonome, un index KV réparti par branches et un routage conscient de la topologie. Elle fournit aussi des chemins multimodaux et des parseurs d’appels d’outils. Son périmètre est plus large qu’Infera 0.1, au prix d’une matrice de versions imposée : les images vLLM, SGLang et TensorRT-LLM de cette release passent à CUDA 13, sans variante CUDA 12 publiée.
La maturité ne signifie pas que chaque mode est stabilisé. Les notes de version 1.3.0 signalent que l’autoscaling piloté par la latence ou la charge ne déclenche pas correctement plusieurs scénarios avec TensorRT-LLM, SGLang et le Global Planner. NVIDIA recommande le mode basé sur le débit en attendant la version 1.4. La même section indique que l’estimation AIC n’est pas disponible avec la version 0.9.0 du composant embarqué. Ce sont des limites documentées, pas des cas déduits d’un ticket isolé.
llm-d : choisir entre une carte exacte et une estimation
llm-d sépare le chemin réseau du choix du worker. Le proxy reçoit la requête ; l’Endpoint Picker évalue les pods d’un InferencePool ; le moteur exécute le modèle. Cette division suit l’Inference Extension de Kubernetes Gateway API et permet de remplacer le proxy sans réécrire la logique de sélection.
Son routage KV-aware propose deux niveaux de précision. Le mode approximatif découpe le texte en blocs, calcule des empreintes et maintient un cache LRU local au routeur. Il coûte peu, mais sa carte peut diverger de l’état réel lorsque le moteur évince un bloc. Le mode précis récupère les identifiants de tokens exacts et consomme les événements KV publiés par les serveurs. Il construit une vue globale plus fidèle, au prix d’un tokenizer supplémentaire, d’un bus d’événements et d’un index distribué.
Le stockage reste composable. llm-d sait utiliser le déport natif de vLLM vers le CPU ou un système de fichiers, ainsi que des connecteurs externes comme LMCache, Mooncake ou KVBM. La documentation prévient que les chemins natifs vLLM ne forment pas encore une hiérarchie unifiée et que le connecteur fichier ne supprime pas lui-même les entrées obsolètes. Un évicteur séparé doit nettoyer le volume persistant.
L’autoscaling suit la même philosophie. KEDA peut réagir aux métriques exportées par le routeur ; le Workload Variant Autoscaler arbitre entre variantes et matériels hétérogènes. La documentation classe encore les objectifs stricts de latence parmi les usages expérimentaux. llm-d couvre davantage de plateformes que les deux autres projets, mais demande aussi d’assembler davantage de pièces.
Le « 2,6× » d’AMD ne mesure pas un moteur plus rapide
Le benchmark Infera le plus mis en avant simule un agent multi-tour sur Kimi K2.6 MXFP4. Chaque conversation partage un préfixe de 20 000 tokens, ajoute jusqu’à 30 tours d’environ 2 000 tokens d’entrée et 900 tokens de sortie, puis atteint 75 000 tokens de contexte au percentile 50 et 115 000 au maximum. Cette charge concentre précisément les cas où le cache partagé et la séparation des phases ont de la valeur.
AMD compare deux topologies sur MI355X. Le baseline utilise huit GPU en parallélisme tensoriel TP8 avec vLLM. Infera en emploie douze : quatre GPU TP4 pour le prefill, puis huit GPU organisés en quatre répliques TP2 pour le decode. Le projet mesure le goodput, c’est-à-dire le débit qui respecte encore une vitesse minimale par utilisateur, puis le divise par le nombre de GPU.
À l’objectif de 30 tokens/s par utilisateur, le script de tracé publié fournit les valeurs nécessaires. Le baseline atteint son dernier point conforme à 16 conversations concurrentes, normalisé à 1,00. Infera reste conforme à 96 conversations et atteint 2,51 de débit total relatif. La normalisation par GPU donne :
(2,51 / 12 GPU) / (1,00 / 8 GPU) = 1,67× par GPU.
Ce calcul arrondi à 1,7× correspond au chiffre du billet AMD. Les mêmes valeurs montrent six fois plus de conversations conformes au seuil testé, de 16 à 96, avec une flotte 50 % plus grande.
Le seuil de 50 tokens/s est moins solide. Le billet AMD annonce jusqu’à 2,6× de goodput par GPU. Le README détaillé du benchmark reprend 2,6× dans son résumé, puis indique 2,4× dans son paragraphe de résultats. Le script publié ne contient que la série complète du graphique à 30 tokens/s, pas les résultats bruts permettant de départager 2,4× et 2,6×.
Ce benchmark ne compare pas Infera à Dynamo ou llm-d. Il compare une topologie Infera à un serveur vLLM agrégé, sur une charge conçue autour d’un long préfixe partagé. Il démontre qu’une meilleure architecture de service peut augmenter le débit utile sur ce cas. Il ne permet pas d’établir un classement entre les trois orchestrateurs.
Le choix dépend de la frontière que vous voulez posséder
Sur un cluster MI355X, Infera fournit le chemin le plus direct pour tester vLLM, SGLang et ATOM derrière une API commune, avec transfert et indexation du cache. Sa contrepartie est explicite : matériel validé unique, autoscaling et multimodal encore à la feuille de route, installation de certains composants depuis les sources. C’est une base d’intégration crédible, pas encore une plateforme indifférente au matériel.
Sur une flotte NVIDIA, Dynamo 1.3 couvre la chaîne la plus longue. Le routeur, le Planner, l’opérateur Kubernetes, le stockage KV et le transport sont conçus ensemble. Cette intégration réduit le nombre d’interfaces à assembler, mais lie la release officielle à CUDA 13 et n’efface pas les défauts documentés de ses modes d’autoscaling avancés.
llm-d convient lorsque Kubernetes et la portabilité des composants constituent la frontière principale. Le projet accepte les images vLLM CUDA, ROCm et XPU, expose ses décisions par les primitives de Gateway API et permet de choisir entre carte KV approximative ou précise. Cette liberté reporte une partie du travail sur l’exploitant : déploiement des événements, nettoyage du stockage, choix des connecteurs et validation de l’autoscaling.
Le bon test ne consiste donc pas à rejouer un débit synthétique unique. Il doit conserver le même modèle, la même qualité de sortie, le même nombre de GPU et la même interconnexion, puis injecter les traces réelles du service. Il faut publier séparément le temps jusqu’au premier token, l’intervalle entre tokens aux percentiles 50 et 99, le taux de cache touché par niveau, le débit conforme au SLO et le coût des transferts. Sans ces dimensions, un routeur peut gagner en débit moyen tout en dégradant les conversations froides.
Le prochain verrou sera l’état, pas le calcul
Infera ferme un manque visible de l’écosystème AMD : les MI355X disposaient de moteurs performants, mais pas d’une couche de référence réunissant routage KV-aware, séparation prefill/decode et cache hiérarchique. Sa version 0.1 ne rattrape pas encore toute la surface de Dynamo ou de llm-d. Elle confirme pourtant le changement d’échelle.
Le routeur n’est plus un répartiteur HTTP placé devant des GPU interchangeables. Il devient un ordonnanceur de mémoire distribuée. Le prochain enjeu sera de faire circuler les événements et les blocs KV entre moteurs, stockages et accélérateurs sans enfermer le cluster dans une seule pile. Celui qui standardisera cet état partagé contrôlera davantage le coût du prochain token que celui qui ajoutera un nouveau flag au kernel.
Sources et méthode
- AMD, « Infera: Distributed Inference for AMD Instinct GPUs », 23 juillet 2026. Source constructeur pour l’architecture, les topologies et les résultats annoncés. Les gains sont des mesures internes AMD, non reproduites indépendamment.
- AMD-AGI, dépôt Infera, matrice fonctionnelle, matrice de compatibilité et feuille de route, consultés le 27 juillet 2026. Sources primaires pour les fonctions livrées, le matériel validé et les fonctions prévues.
- AMD-AGI, benchmark agentique Kimi et script de tracé, consultés le 27 juillet 2026. Le ratio de 1,67× est notre calcul direct à partir des valeurs publiées :
(2,51 / 12) / (1 / 8). Les longueurs de contexte et les moyennes sur trois essais viennent du protocole AMD. L’écart 2,4×/2,6× est présent dans le dépôt au jour de consultation. - NVIDIA Dynamo 1.3.0, notes de version, 22 juillet 2026, architecture et concepts du routeur. Sources primaires pour les trois plans, le calcul de coût, la matrice CUDA 13 et les problèmes connus.
- llm-d 0.8.1, notes de version, 26 juin 2026, architecture, routage KV-aware, déport KV et autoscaling. Sources primaires pour les composants, plateformes, modes de routage et limites de stockage.
- CNCF, fiche projet llm-d et annonce d’admission, 24 mars 2026. Le statut Sandbox est traité comme un fait de gouvernance, sans en déduire un niveau de stabilité.
