Llm-D 1.0 fait ses débuts à la conférence PyTorch avec une pile d’inférence destinée à la production

Les contributeurs au projet llm-d ont annoncé llm-d 1.0 le 20 octobre 2026, à la conférence PyTorch d’Amérique du Nord, selon une annonce d’IBM Research. IBM a indiqué que cette version fait évoluer llm-d au-delà de la démonstration de techniques de performance individuelles et vise à aider les organisations à rapatrier le déploiement des modèles en interne, alors que les coûts d’inférence augmentent.

llm-d est conçu pour déployer des piles d’inférence pour n’importe quel modèle, sur n’importe quel accélérateur et dans n’importe quel nuage. Red Hat, IBM et Google sont les principaux responsables de la maintenance du projet et ont cofondé llm-d avec CoreWeave et NVIDIA ; AMD, Cisco, Hugging Face, Intel, Lambda et Mistral AI y ont contribué. La Cloud Native Computing Foundation (CNCF) héberge llm-d en tant que projet en bac à sable. IBM présente cette solution comme une option indépendante des fournisseurs pour les organisations qui souhaitent bénéficier de ce qu’elle appelle des performances d’inférence de pointe sans dépendre entièrement d’un seul fournisseur de modèles propriétaires, d’un seul nuage ou d’une seule plateforme matérielle.

Carlos Costa, ingénieur émérite chez IBM Research, cofondateur de llm-d et responsable principal de sa maintenance, a déclaré que la version 1.0 apporte la maturité nécessaire pour exploiter llm-d comme n’importe quel autre service essentiel. Il a notamment cité une API stable, la possibilité pour plusieurs locataires aux priorités concurrentes de partager la même infrastructure et des mises à niveau qui n’interrompent pas les opérations.

Les nouveautés de la version 1.0

Les notes de version v1.0.0 du projet, publiées sur GitHub le 20 octobre 2026 avec des balises signées et vérifiées, mettent en avant la qualité de service en environnement multilocataire : un contrôle des flux tenant compte des priorités et de l’équité, avec une réduction contrôlée de la charge, qui comprend un mécanisme d’admission probabiliste, une équité tenant compte des programmes et une notation des priorités par tour. Ainsi, les requêtes sensibles à la latence et les charges de travail agentiques à forte activité peuvent partager une flotte sans se priver mutuellement de ressources en cas de surcharge. La configuration du contrôle des flux est regroupée dans un seul champ flowControl.

Pour assurer les opérations sans interruption, le routeur gagne en haute disponibilité grâce à un serveur de secours à chaud et à des mises à jour progressives sécurisées. Un contrôleur DisaggregatedSet gère les répliques de préremplissage et de décodage comme une seule unité logique, avec des déploiements coordonnés, des mises à niveau synchronisées, une disponibilité conditionnée à la prise d’un instantané du pod et un routage natif par révision. L’API de configuration du routeur passe à la version v1, l’API Responses prend en charge previous_response_id et le chemin de requête du sélecteur de points de terminaison est renforcé pour gagner en fiabilité, en performance et en évolutivité. Le guide des accélérateurs tenant compte de la topologie pour DRA et DRANET est également inclus.

La prise en charge des agents ajoute un module d’extension de production de l’état de session et une affinité de session évolutive afin de maintenir les conversations à plusieurs tours à proximité de leur contexte mis en cache. Elle comprend également la planification selon la priorité des tours et l’état de l’API Responses, pour aider les agents à réutiliser le contexte d’un tour à l’autre. Cette version harmonise les composants du projet en v1.0.0 et ajoute des éléments à l’écosystème, notamment une intégration avec ai-dynamo/modelexpress pour le chargement pair-à-pair des poids des modèles, le paquet llm-d-api-extensions et l’outil de diagnostic llm-d-pd-utils. Elle rend par ailleurs obsolètes les versions d’image conteneur llm-d-rocm produites par le projet lui-même. Les images de serveurs de modèles comprennent des versions de vLLM et de SGLang pour différentes cibles d’accélérateurs. Le guide sur la dissociation du préremplissage et du décodage exige désormais LeaderWorkerSet v0.11.1 ou une version ultérieure, avec l’API DisaggregatedSet activée.

Techniques de base et contrôle des flux

Depuis son lancement, le projet se concentre sur cinq approches visant à améliorer l’inférence : le routage tenant compte du cache de préfixes, qui dirige une requête vers une infrastructure susceptible de déjà contenir le contexte partagé ; le déchargement du cache KV, qui déplace les informations mises en cache entre les ressources GPU, CPU et de stockage ; l’optimisation de l’inférence par lots ; la dissociation du préremplissage et du décodage, qui sépare la lecture d’une invite de la génération d’une réponse ; et le parallélisme étendu des experts, qui répartit les grands modèles à mélange d’experts sur de nombreux accélérateurs. Ces techniques existaient avant la version 1.0. Selon IBM, la nouveauté réside dans leur intégration et dans la maturité opérationnelle qui les accompagne, ainsi que dans la discipline d’exploitation de deuxième jour, qui consiste à maintenir les performances lorsque le trafic évolue, que le matériel tombe en panne, que les logiciels sont mis à jour ou que différents utilisateurs se disputent les mêmes ressources.

Dans la version 1.0, le contrôle des flux, l’équité et la hiérarchisation des priorités doivent empêcher les charges de travail à forte activité de submerger les services sensibles à la latence, que ces charges partagent le même matériel ou mobilisent un mélange d’accélérateurs. Les requêtes peuvent également rester affectées à l’infrastructure adaptée pendant plusieurs tours afin de préserver la chaleur des caches de préfixes. llm-d fonctionne avec des moteurs d’inférence tels que vLLM ou SGLang, auxquels il ajoute des capacités de routage distribué et d’exploitation. Stephen Watt, vice-président au bureau du directeur technique de Red Hat, a déclaré que llm-d unifie les écosystèmes PyTorch et CNCF en apportant directement aux moteurs vLLM et aux moteurs d’inférence modernes une orchestration native de Kubernetes.

Résultats présentés et coûts annoncés

Dans un article présentant les résultats d’un test de performance, publié le 22 juillet 2026, le projet a mesuré le service d’inférence agentique de GLM-5.2, décrit dans l’article comme un modèle à mélange d’experts de 744 milliards de paramètres, avec 39 milliards de paramètres actifs et 78 couches. L’analyse de la charge de travail s’appuyait sur 219 sessions de production de Claude Code, dans lesquelles la requête médiane de l’agent principal contenait 195 000 jetons en entrée et produisait 317 jetons en sortie ; 96 % des tours de l’agent principal réutilisaient au moins 90 % de leurs données d’entrée. L’article indique que le routage tenant compte des préfixes a permis de capter 96 à 97 % de la réutilisation du cache offerte par la charge de travail. Sur la base d’un tarif de location supposé de H200 de 2,71 $ par heure-GPU, il estime le coût du service auto-hébergé, sur deux configurations de 64 GPU, entre 0,05 $ et 0,08 $ par million de jetons en entrée et entre 1,92 $ et 3,55 $ par million de jetons en sortie. Selon les auteurs, ces chiffres couvrent uniquement la location des GPU et supposent une charge soutenue.

Dans le cadre d’une démonstration distincte, IBM et Red Hat ont déployé GLM-5.2 sur 544 GPU NVIDIA H100. Le modèle est présenté dans le compte rendu d’IBM Research comme un modèle à poids ouverts d’environ 753 milliards de paramètres, dont quelque 39 milliards sont actifs. IBM indique que le déploiement a atteint un débit de pointe supérieur à 6,6 millions de jetons en sortie par minute, tout en servant jusqu’à 3 000 agents de programmation simultanés sans aucune préemption ; avec 2 500 agents, il a maintenu un débit de 7 612 requêtes par minute. IBM affirme qu’aux tarifs actuels de location dans le cloud, l’auto-hébergement de GLM-5.2 sur des GPU H100 avec llm-d coûte de 5 à 10 fois moins par jeton qu’une tarification équivalente pour les API commerciales. « Servir des milliers d’agents simultanément sans préemption offre aux opérateurs une voie crédible pour passer des résultats d’un test de performance à un déploiement en production », a déclaré Maroon Ayoub, ingénieur principal senior en apprentissage automatique au sein de l’équipe d’ingénierie de l’inférence de Red Hat.

Selon le même compte rendu, ces résultats reposent sur un plan de données désagrégé qui a effectué 6,2 millions de transferts de cache KV, d’une taille moyenne de 2,71 Gio chacun, sans aucun échec de transfert ; tous les tests de performance se sont achevés sans erreur de service.