Le projet open source llm-d a livré sa version 1.0 le mardi 20 octobre 2026, la plus importante depuis son lancement selon ses mainteneurs. llm-d est une couche native de Kubernetes placée devant des serveurs de modèles comme vLLM et SGLang, qui décide où chaque requête d'inférence doit être exécutée. Lancé en 2025 par Red Hat, IBM, Google Cloud, CoreWeave et NVIDIA, il est aujourd'hui un projet Sandbox de la Cloud Native Computing Foundation et rassemble plus de 500 contributeurs issus de plus de 25 organisations.
Les versions précédentes misaient sur la performance : diriger les requêtes vers les répliques qui ont déjà le préfixe du prompt en cache, déporter le cache clé-valeur vers une mémoire moins chère, séparer la phase de prefill, gourmande en calcul, de la phase de decode, gourmande en mémoire, et répartir de grands modèles à mélange d'experts sur de nombreux accélérateurs. La version 1.0 vise ce que le projet appelle les opérations du jour 2, c'est-à-dire maintenir dans la durée un service d'inférence partagé et stable pour de nombreux clients.
Les nouveautés sont surtout opérationnelles. Un nouveau système de contrôle de flux classe le trafic par locataire et par priorité, protège les charges premium lors des pics pendant que les traitements par lots attendent, et réduit la charge progressivement au lieu d'échouer. Le routeur dispose désormais d'une instance de secours active, et un composant baptisé DisaggregatedSet gère les répliques de prefill et de decode comme un tout, afin de les mettre à jour sur place sans perdre de requêtes. L'API de configuration passe en v1 stable. Pour les agents, le routage par session garde une conversation à plusieurs tours sur la réplique qui détient son cache, et la prise en charge de l'état de la Responses API évite à l'agent de renvoyer tout son historique.
Google, qui a publié son propre billet le même jour, a ajouté un processeur asynchrone qui récupère des tâches peu sensibles à la latence dans des files comme Pub/Sub ou Redis, ainsi qu'un partage de temps sur TPU et GPU qui comble les temps morts pendant l'apprentissage par renforcement. Selon Google, le taux d'occupation des accélérateurs est passé d'environ 40 % à plus de 70 %. Le groupe affirme aussi que, sur une charge de programmation par agents sur TPU Ironwood, le routage tenant compte du cache, combiné au déport vers la mémoire de l'hôte, a réduit de plus de 85 % le délai médian avant le premier jeton et multiplié le débit par 2,4 par rapport à un simple Kubernetes Service, et que sa plateforme Gemini a doublé son taux de réussite du cache de préfixes, de 35 % à 70 %.
Le projet cite des utilisateurs en production chez plusieurs fournisseurs. D'après l'équipe de llm-d, AWS constate jusqu'à 70 % de jetons par seconde en plus sur SageMaker HyperPod, Tesla et Red Hat ont mesuré un débit de sortie triplé pour Llama 3.1 70B sur GPU AMD MI300X, et IBM Research fait tourner jusqu'à 3 000 agents de programmation simultanés sur 544 GPU NVIDIA H100. DigitalOcean, Oracle Cloud Infrastructure, Mistral AI et JetBrains figurent aussi dans la liste. La pile fonctionne sur les GPU NVIDIA, AMD et Intel ainsi que sur les TPU de Google, et Red Hat l'intègre à Red Hat AI.
Cette version compte parce que l'inférence, plus que l'entraînement, devient le premier poste de dépenses de calcul en IA, et que les agents réutilisent d'énormes volumes de contexte. Un ordonnanceur partagé et neutre pourrait limiter la dépendance à un seul fabricant de puces ou à une plateforme propriétaire.
Tous les chiffres de performance proviennent des fondateurs et utilisateurs de llm-d, mesurés sur leurs propres charges, et aucun n'a été vérifié de manière indépendante. L'étiquette 1.0 garantit la stabilité des API, mais les opérateurs devront juger de la maturité de chaque matériel, et la prise en charge de la future plateforme Vera Rubin de NVIDIA est encore en cours.