llm-d : orchestrer l'inférence LLM sur Kubernetes sans réécrire vLLM
Achieve state of the art inference performance with modern accelerators on Kubernetes
En bref
- De quoi s’agit-il ?
- llm-d est une pile d'orchestration CNCF placée au-dessus de vLLM et SGLang pour le routage, le KV-cache et la désagrégation prefill/decode sur Kubernetes. Le dépôt est en Shell et sous Apache-2.0, mais l'essentiel de la valeur se trouve dans les guides et les Helm charts, pas dans le code du dépôt lui-même.
- À qui s’adresse-t-il ?
- Adoptez llm-d si vous servez déjà vLLM ou SGLang sur Kubernetes avec plusieurs réplicas et un trafic multi-tours, et si vous acceptez de dépendre de Helm charts et de guides versionnés séparément du code. Évitez-le pour un seul pod de démonstration ou un déploiement hors Kubernetes.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Shell, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : vLLM sait servir un modèle, pas arbitrer un parc de GPU
Le README est explicite sur le partage des rôles. Les serveurs de modèles comme vLLM et SGLang s'occupent de faire tourner efficacement un grand modèle sur des accélérateurs. llm-d se place au-dessus et fournit ce que le README appelle une orchestration et des optimisations de niveau état de l'art. Concrètement, cela vise les équipes qui ont déjà un déploiement vLLM fonctionnel sur Kubernetes et qui butent sur trois choses : le choix du réplica qui reçoit la requête, la taille utile du cache KV entre les tours d'une conversation, et le coût du prefill quand celui-ci occupe les mêmes GPU que le decode. Le projet est un projet sandbox de la CNCF, fondé par Red Hat, Google Cloud, IBM Research, CoreWeave et NVIDIA. Cette liste de fondateurs indique le public visé : des plateformes d'inférence en production, pas des notebooks. Si vous servez un modèle sur un seul pod pour une démonstration interne, llm-d n'apporte rien que Kubernetes ne fasse déjà seul.
Quatre mécanismes distincts, pas une couche magique
Le README organise llm-d en thèmes, et cette séparation est utile parce que chacun se déploie indépendamment. Le routage intelligent combine un équilibrage conscient du prefix-cache et de la charge, avec une ordonnancement expérimental fondé sur la latence prédite. Le KV-cache management ajoute un déchargement hiérarchisé vers CPU ou disque, avec un index global de l'état du cache. Le service de grands modèles passe par la désagrégation prefill/decode et le parallélisme expert étendu sur interconnexions rapides. L'exploitation couvre le contrôle de flux multi-tenant et l'autoscaling guidé par SLO. Un cinquième thème, le traitement par lots, expose des API Batch compatibles OpenAI pour l'inférence hors ligne. Le point commun technique est que llm-d a besoin de savoir ce que contient le cache KV de chaque réplica pour router correctement. C'est ce qui distingue un routeur prefix-aware d'un Service Kubernetes classique : le second répartit en round-robin, le premier envoie une requête vers le réplica qui détient déjà le préfixe. Le README annonce 3x de débit de sortie et 2x de TTFT en moins avec le routage prefix-cache par rapport au round-robin, sur Llama 3.1 70B et 4 GPU AMD MI300X, dans un billet co-signé Tesla et Red Hat. Ces chiffres proviennent de benchmarks partenaires cités par le projet, pas d'une mesure indépendante.
La désagrégation prefill/decode : le gain dépend de l'interconnexion
Séparer le prefill du decode signifie que les deux phases tournent sur des groupes de GPU différents, et que le cache KV doit traverser le réseau entre les deux. Le README cite jusqu'à 70% de tokens par seconde en plus avec la désagrégation prefill/decode face à vLLM standard, sur GPT-OSS et NVIDIA B200, dans un billet AWS. Oracle rapporte de son côté 10 à 30% d'amélioration du débit sur infrastructure identique avec GPT-OSS-120B et Llama 3.3 70B sur MI300X. L'écart entre 70% et 10% n'est pas une contradiction : il reflète probablement des topologies et des modèles différents, et c'est précisément le genre de détail qui décide si la désagrégation vaut son coût. Si votre interconnexion entre nœuds est lente, déplacer le KV cache devient un goulot d'étranglement et la configuration désagrégée peut être plus lente que la configuration monolithique. Le README ne donne pas de seuil de bande passante en dessous duquel il faut s'abstenir. C'est une lacune réelle du matériel fourni, et elle compte.
Mise en route : des guides et des charts, pas un binaire
Le langage principal du dépôt est Shell, et le README ne présente aucune commande d'installation directe. Il renvoie vers un Quickstart Guide sur llm-d.ai, qui décrit la mise en place de la pile, la configuration du routeur intelligent et la validation par benchmarks. Le projet mentionne aussi des Helm charts accompagnant les recettes testées, et la note de version v0.7 signale une migration des guides vers une approche kustomize-first. Deux chemins coexistent donc : Helm et kustomize. Le README conseille de commencer par le guide Optimized Baseline, présenté comme une base haute performance pour une large gamme de cas d'usage. Aucune valeur de configuration n'est reproduite dans le README lui-même : les clés exactes du routeur, les paramètres de déchargement KV et les réglages de désagrégation vivent dans les guides et les charts externes. C'est un point à intégrer dans votre planification : la documentation est le produit, et elle est versionnée séparément du dépôt. Un lecteur qui cherche un fichier de configuration complet dans le dépôt ne le trouvera pas dans le matériel fourni.
Le coût de maintenance se mesure en versions de guides, pas en commits
Le rythme de publication est soutenu : v0.8.0 et v0.8.1 en juin 2026, v0.9.0 en août 2026. Les notes de version décrivent des changements structurels, comme la migration kustomize-first en v0.7 et la mise à disposition générale de l'ordonnancement par latence prédite dans la même version. Une fonctionnalité qui passe de l'expérimental au GA change de contrat, et une migration de Helm vers kustomize change vos fichiers de déploiement. Si vous épinglez une version, vous épinglez aussi la version correspondante des guides et des charts. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et d'état des modifications. Le README ne signale aucune clause additionnelle ni restriction de marque. Je ne donne pas d'avis juridique : faites lire le fichier LICENSE et les mentions de marque du projet par votre service compétent si vous redistribuez la pile.
Quand llm-d est le mauvais outil
Trois cas se dégagent du matériel. Premier cas : vous n'êtes pas sur Kubernetes. Le README présente llm-d comme optimisé pour des déploiements en production sur Kubernetes, et tous les mécanismes cités (routage, autoscaling, contrôle de flux) s'appuient sur les primitives de cette plateforme. Sur des machines nues ou dans un orchestrateur différent, la pile n'a pas de point d'ancrage. Deuxième cas : vous n'avez qu'un seul réplica. Le routage prefix-aware n'a de sens qu'avec plusieurs cibles, et l'index global du cache KV n'a rien à indexer. Troisième cas : votre trafic est majoritairement mono-tour et sans préfixe partagé. Le gain de cache disparaît, et il reste la complexité opérationnelle. Le README ne quantifie pas ces cas défavorables, mais la logique des mécanismes décrits les rend explicites. Un point supplémentaire mérite attention : plusieurs gains annoncés, comme les 50k tokens par seconde en wide expert-parallelism sur 16x16 B200, supposent une topologie matérielle précise. Reproduire ces chiffres sur un cluster plus modeste n'a rien d'automatique.
Face à une pile vLLM plus routeur maison
L'alternative la plus directe n'est pas un produit concurrent mais l'assemblage que beaucoup d'équipes font déjà : vLLM derrière un Service Kubernetes, plus un reverse proxy et éventuellement un cache de prompt côté application. La différence d'approche est nette. Un Service Kubernetes répartit les requêtes sans connaître l'état du cache KV ; llm-d construit un index global de cet état et route en conséquence. Un cache de prompt applicatif économise des tokens d'entrée mais ne réduit pas le travail de prefill sur le GPU de la même manière qu'un cache KV partagé entre réplicas. L'assemblage maison a l'avantage d'être entièrement sous votre contrôle et de ne dépendre que de composants que vous connaissez. llm-d apporte des recettes benchmarkées et des charts maintenus, au prix d'une dépendance à un projet sandbox CNCF dont les guides évoluent vite. Le choix se joue donc sur la tolérance à cette dépendance, pas sur une supériorité technique démontrée dans le matériel fourni.
Conclusion éditoriale
Adoptez llm-d si vous servez déjà vLLM ou SGLang sur Kubernetes avec plusieurs réplicas et un trafic multi-tours, et si vous acceptez de dépendre de Helm charts et de guides versionnés séparément du code. Évitez-le pour un seul pod de démonstration ou un déploiement hors Kubernetes. Avant de vous engager, vérifiez le contenu réel du répertoire de charts à la version v0.9.0 et les valeurs par défaut de la configuration du routeur dans le guide Optimized Baseline, car c'est là que se logent les hypothèses de topologie.
Notes de la communauté