---

Le KV cache est devenu le vrai goulot d’étranglement — et llm-d arrive pile à ce moment

Il y a encore dix-huit mois, la question qui occupait les équipes infra était simple : quel moteur sert le plus vite un modèle open weight sur un nœud ? vLLM a répondu avec son PagedAttention, SGLang avec son RadixAttention. Sur une seule machine, avec un seul modèle, la bataille du débit mono-nœud est essentiellement réglée. On sait faire tourner un 70B en production sans se brûler.

Le problème a changé de nature. Ce qui coince désormais, ce n’est plus le moteur : c’est l’orchestration autour. Concrètement, trois symptômes reviennent dans toutes les équipes qui servent des LLM open weight à l’échelle :

Le cache de préfixes gaspillé. Un chatbot multi-tenant envoie le même system prompt à chaque requête. Un pipeline RAG préfixe chaque appel avec les mêmes instructions et souvent les mêmes documents. Sans routage conscient du cache, le load balancer envoie la requête numéro 2 sur un GPU qui n’a jamais vu ce préfixe — et le moteur recalcule tout depuis zéro. Le KV cache, cette mémoire des tokens déjà traités, est la ressource la plus précieuse d’un serveur d’inférence, et un round-robin naïf la gaspille méthodiquement.

Le routage aveugle. Un load balancer qui répartit équitablement entre N réplicas ignore trois choses : quel réplica a le préfixe en cache, lequel est saturé, et lequel a une latence prévisible. Il en résulte des TTFT (time to first token) en dents de scie, des SLO de latence impossibles à tenir, et des GPU qui tournent à 40 % d’utilisation utile.

Le multi-nœuds artisanal. Dès qu’on dépasse un nœud — pour un modèle qui ne tient pas sur un GPU, pour absorber une charge en rafale, pour disagréger le prefill du decode — on bricole. Des scripts maison, des ConfigMaps, des health checks approximatifs. Chaque équipe réinvente sa couche d’orchestration, et la réinvente mal.

C’est précisément ce vide que llm-d 1.0 prétend combler. Pas en remplaçant vLLM ou SGLang, mais en devenant la couche Kubernetes-native qui décide où envoyer chaque requête et comment répartir la charge sur une flotte hétérogène de GPU et de TPU. La nuance est capitale : llm-d n’est pas un nouveau moteur d’inférence, c’est un orchestrateur. Et c’est probablement la brique qui manquait pour que le self-hosting passe du statut de science project à celui de plateforme sérieuse.

---

Ce que llm-d n’est pas : ni un moteur, ni un fork de vLLM

La confusion la plus fréquente, à la lecture des annonces, est de croire que llm-d concurrence vLLM. Il faut la dissiper d’emblée.

llm-d est un projet sandbox de la CNCF, fondé par Red Hat, Google Cloud, IBM Research, CoreWeave et NVIDIA. Il se positionne explicitement comme une couche d’orchestration au-dessus de vLLM et SGLang, sur Kubernetes. Autrement dit : vLLM et SGLang restent les moteurs qui exécutent réellement les multiplications matricielles ; llm-d est la couche qui décide quel moteur, sur quel nœud, reçoit quelle requête, et comment le travail est découpé entre prefill et decode.

La chronologie, telle qu’elle ressort des sources publiques, est la suivante : le projet a connu une série de versions 0.x (le site officiel affiche encore par endroits une référence à v0.8.1, incohérence de version non expliquée publiquement), puis la version 1.0 a été annoncée à la PyTorch Conference, avec une release datée du 20 octobre 2026 selon MarkTechPost. La gouvernance est CNCF sandbox — donc pas encore un projet graduated, avec tout ce que cela implique en termes de garanties de stabilité et de support à long terme.

La licence, la composition exacte du comité technique et le rythme de release post-1.0 ne sont pas documentés dans les sources accessibles au moment de la rédaction. C’est un point à surveiller : un projet sandbox CNCF peut très bien devenir un standard de fait (Kubernetes lui-même a commencé ainsi) ou rester un agrégateur de contributions hétérogènes sans direction claire.

Ce qu’il faut retenir : llm-d ne remplace rien, il assemble. Si vous cherchez un moteur plus rapide, regardez vLLM ou SGLang. Si vous cherchez à faire tourner ces moteurs proprement sur une flotte, llm-d entre en scène.

---

Anatomie du stack : gateway cache-aware, scheduler EPP, inference pool

L’architecture revendiquée par llm-d s’articule autour de trois composants principaux, adossés à la Gateway API Inference Extension de Kubernetes.

La gateway cache-aware. C’est le point d’entrée. Elle reçoit la requête HTTP du client et décide vers quel réplica l’envoyer. Sa particularité : elle est consciente du cache. Elle sait, pour chaque réplica, quels préfixes sont déjà en KV cache, et route en conséquence. Un system prompt récurrent, un document RAG partagé, une conversation multi-tour : tout ce qui a déjà été calculé quelque part est envoyé là où il a été calculé. C’est le cœur du gain de TTFT revendiqué.

Le scheduler EPP. EPP pour End-Point Picker, selon la terminologie Gateway API. Son rôle : scorer les réplicas candidats selon plusieurs critères — latence prédictive, charge actuelle, affinité de cache — et choisir le meilleur. C’est là que se joue le bin-packing : éviter d’envoyer une requête sur un GPU déjà à 95 % d’utilisation alors qu’un autre est à 40 %. Le scheduler revendique un « ordonnancement prédictif de latence » par opposition aux heuristiques classiques.

L’inference pool. C’est l’abstraction Kubernetes qui regroupe les réplicas d’un même modèle servi par vLLM ou SGLang. L’inference pool expose une API stable aux couches supérieures, ce qui permet à la gateway de ne pas avoir à connaître les détails de chaque déploiement.

Le flux d’une requête, de bout en bout, ressemble à ceci : un client HTTP envoie un prompt → la gateway l’intercepte, identifie le préfixe, interroge le scheduler → le scheduler score les réplicas de l’inference pool selon cache, charge et latence prédite → la requête est routée vers le réplica choisi → le moteur vLLM ou SGLang exécute le prefill (ou réutilise le cache) puis le decode → la réponse remonte.

Pour un praticien, les objets Kubernetes à maîtriser sont les CRDs de la Gateway API Inference Extension : InferencePool (le groupe de réplicas), InferenceModel (la définition du modèle servi), et les objets Gateway API standard (Gateway, HTTPRoute). Le nom exact et la stabilité de ces CRDs ne sont pas détaillés dans les sources publiques accessibles — c’est un point à vérifier dans la documentation officielle avant de s’engager. Mais l’idée générale est claire : llm-d s’inscrit dans l’écosystème Gateway API plutôt que d’inventer son propre modèle de configuration, ce qui est plutôt bon signe pour la pérennité.

---

Les chiffres du projet, passés au crible : 3x, 2x, 70%, 13,9x — que mesurent-ils vraiment ?

C’est ici qu’il faut redoubler de prudence. Les chiffres qui circulent proviennent tous de blogs partenaires (Red Hat, Google, AWS, Oracle, Tesla) relayés sur le GitHub officiel et sur llm-d.ai. Ce n’est pas une corroboration indépendante : c’est la même source dupliquée. Aucun benchmark tiers académique ou presse n’est identifié dans les extraits disponibles.

Voici l’inventaire critique :

Chiffre revendiqué	Ce qu’il mesure	Configuration	Partenaire	Reproductibilité
3x throughput, 2x TTFT	Routage prefix-cache-aware vs round-robin	Llama 3.1 70B sur 4× AMD MI300X	Tesla / Red Hat	Scripts non visibles dans les extraits
40% réduction TTFT et ITL	Ordonnancement prédictif vs heuristiques	GPU NVIDIA (modèle non précisé)	Google	Conditions de test absentes
Jusqu’à 70% tokens/s	Disagrégation prefill/decode vs vLLM standard	GPT-OSS sur NVIDIA B200 (p6-b200)	AWS	« Up to » = borne supérieure marketing
10–30% throughput	Serving disagrégé sur infra identique	GPT-OSS-120B et Llama 3.3 70B sur AMD MI300X	Oracle	Fourchette large, charge non détaillée
50k tokens/sec	Throughput cluster en Wide Expert-Parallelism	16×16 NVIDIA B200 (256 GPU, ~3,1k tok/s/GPU)	llm-d v0.5	Cohérent arithmétiquement, pas de source indépendante
13,9x throughput	Offloading KV hiérarchique vs GPU-only	4× NVIDIA (GPU tronqué), 250 utilisateurs concurrents	GitHub officiel	Extrait tronqué, modèle et matériel incomplets

Ce que ces chiffres disent vraiment : llm-d apporte un gain réel et mesurable dans des conditions précises — charge à préfixes partagés, flotte multi-nœuds, disagrégation prefill/decode. Ce qu’ils ne disent pas : le taux de hit du KV cache effectif (aucun chiffre public), le coût par token en dollars (absent), le scaling TPU détaillé (Google Cloud cité mais contenu non fourni), et les conditions de test reproductibles (longueur des prompts, longueur de génération, concurrence, SLO de latence, version de vLLM/SGLang).

Autrement dit : les chiffres sont plausibles, cohérents entre eux, mais non reproductibles en l’état à partir des seules sources publiques. Un praticien sérieux les traitera comme des ordres de grandeur à valider sur sa propre charge, pas comme des garanties contractuelles.

---

Face à vLLM seul, SGLang, Ray Serve, KServe et Dynamo : quand llm-d gagne, quand il ne sert à rien

La comparaison architecturale honnête demande de distinguer les cas.

vLLM seul. Excellent moteur, mais sans orchestration multi-nœuds native. Si vous servez un seul modèle sur un seul nœud avec une concurrence modérée, vLLM suffit et llm-d ajoute de la complexité sans bénéfice. Si vous avez plusieurs réplicas et des préfixes partagés, llm-d commence à gagner.

SGLang (RadixAttention). SGLang intègre nativement un cache de préfixes par arbre radix, très efficace sur un nœud. Mais SGLang reste un moteur : il ne résout pas le routage multi-nœuds. llm-d peut orchestrer SGLang comme vLLM — c’est d’ailleurs l’un de ses arguments. Sur mono-nœud, SGLang seul est souvent plus simple.

Ray Serve. Python-first, très flexible, mais pas Kubernetes-native au sens strict. Ray Serve excelle quand on veut écrire sa logique de serving en Python ; llm-d excelle quand on veut déclarer son infra en YAML Kubernetes. Les deux peuvent coexister, mais les équipes qui ont déjà investi dans Ray Serve n’ont pas de raison immédiate de migrer.

KServe. Le plus proche concurrent conceptuel : KServe est aussi une couche de serving sur Kubernetes. La différence est que llm-d est spécifiquement optimisé pour l’inférence LLM (cache-aware, disagrégation), là où KServe est plus générique. Sur des charges LLM pures, llm-d devrait avoir l’avantage ; sur des charges mixtes (LLM + modèles classiques), KServe reste pertinent.

NVIDIA Dynamo. C’est le concurrent le plus direct. Dynamo est l’offre NVIDIA pour l’inférence distribuée, avec un écosystème NVIDIA-first. llm-d se veut multi-vendeur (GPU AMD, NVIDIA, TPU Google). Si vous êtes 100 % NVIDIA et que vous voulez le support éditeur maximal, Dynamo est tentant. Si vous voulez éviter le verrouillage ou mixer les accélérateurs, llm-d a un argument.

Offres managées (Bedrock, Vertex AI). La question n’est pas technique mais économique. En dessous d’un certain volume, le self-hosting n’est jamais rentable face à une API managée. llm-d ne change pas cette équation : il rend le self-hosting plus efficace, pas gratuit.

Quand llm-d ne sert à rien : mono-nœud, faible concurrence, pas de préfixes partagés, équipe sans compétence Kubernetes/Gateway API. Dans ces cas, vLLM ou SGLang seuls, ou une API managée, sont de meilleurs choix.

---

Trois scénarios réalistes : PME, équipe infra internalisée, contrainte de souveraineté

PME — self-hosting d’un 8B–70B sur 2 à 4 GPU. llm-d est probablement surdimensionné. Avec 2 à 4 GPU et un seul modèle, vLLM ou SGLang seuls suffisent. Le gain de routage cache-aware n’apparaît que si vous avez plusieurs réplicas et des préfixes réellement partagés — ce qui est rare à cette échelle. Sauf si vous êtes multi-tenant avec un system prompt lourd, auquel cas llm-d peut valoir le détour. Ordre de grandeur : sur 4 GPU, le coût d’ingénierie pour opérer llm-d (formation, debugging distribué, monitoring) dépasse souvent le gain de throughput tant que la charge reste modérée.

Équipe infra avec flotte existante. C’est le cas de figure où llm-d gagne. Si vous avez déjà 8, 16, 32 GPU et plusieurs modèles, le routage cache-aware et la disagrégation prefill/decode peuvent produire des gains mesurables. Le point mort se calcule simplement : combien de GPU-heures économisées par le gain de throughput vs combien d’ingénieur-heures pour opérer llm-d. Avec un gain de 20–30 % de throughput sur une flotte de 16 GPU, l’économie est réelle ; sur 4 GPU, elle ne couvre pas la complexité.

Souveraineté / on-prem. C’est l’argument fort de llm-d. Une administration ou un industriel qui doit garder ses modèles et ses données sur site trouve dans llm-d une brique d’inférence contrôlée, open source, sans dépendance à un cloud. Les contrôles (multi-tenant, observabilité) et la gouvernance CNCF rassurent. Mais il faut accepter la jeunesse du projet : sandbox CNCF, benchmarks partenaires, écosystème en construction.

---

Les pièges d’adoption : ce que le communiqué ne dit pas

Complexité opérationnelle. llm-d dépend de la Gateway API Inference Extension, elle-même récente. La courbe d’apprentissage des CRDs (InferencePool, InferenceModel) est réelle, et le debugging distribué (pourquoi cette requête a-t-elle été routée là ? pourquoi ce cache n’a-t-il pas été hit ?) demande une observabilité fine que llm-d ne fournit pas clé en main.

Maturité. Projet sandbox CNCF, écosystème jeune, benchmarks non indépendants. L’incohérence de version (v0.8.1 affichée sur le site vs 1.0 annoncée) n’est pas expliquée publiquement — signe que la communication n’est pas encore parfaitement rodée.

Verrouillages. Dépendance à vLLM/SGLang en amont : si ces moteurs changent d’API, llm-d doit suivre. Support multi-vendeur GPU/TPU encore à prouver : les benchmarks publics sont majoritairement NVIDIA et AMD, le scaling TPU n’est pas détaillé.

Coûts cachés. Ingénierie (formation, run), monitoring du cache (hit rate, éviction), gestion multi-tenant (isolation, quotas). Ces coûts ne figurent dans aucun benchmark.

Checklist avant d’introduire llm-d en production :

1. Avez-vous plus d’un nœud GPU et plusieurs réplicas ? Si non, passez.
2. Vos charges partagent-elles des préfixes (system prompts, RAG) ? Si non, le gain cache-aware s’évapore.
3. Votre équipe maîtrise-t-elle Kubernetes et Gateway API ? Si non, prévoyez 3 à 6 mois de montée en compétence.
4. Avez-vous un plan de rollback vers vLLM/SGLang seuls ? llm-d doit rester une couche optionnelle.
5. Avez-vous mesuré votre coût par token actuel pour comparer ? Sans baseline, aucun benchmark ne sert.

---

Ce que llm-d 1.0 change vraiment pour l’écosystème open weight

Le signal est clair : l’inférence open source se professionnalise au niveau orchestration, pas seulement moteur. Pendant deux ans, la course était au moteur le plus rapide. Désormais, la bataille se déplace vers la couche qui fait tourner ces moteurs à l’échelle, sur une flotte, avec des SLO.

Effet sur la concurrence : NVIDIA Dynamo devra prouver son avantage multi-vendeur face à un llm-d CNCF ; KServe devra clarifier son positionnement LLM ; Ray Serve restera fort sur les équipes Python-first. La standardisation Gateway API Inference Extension comme socle commun est probablement la conséquence la plus durable : si llm-d, KServe et Dynamo convergent vers cette API, les équipes pourront changer d’orchestrateur sans réécrire leur infra.

Pour les équipes qui pariaient sur du bricolage maison, le message est moins réjouissant : votre couche d’orchestration custom a désormais un concurrent open source soutenu par Google, IBM, Red Hat, CoreWeave et NVIDIA. Il faudra justifier le maintien.

Questions ouvertes : gouvernance CNCF réelle (sandbox → incubating ?), benchmarks indépendants à venir, adoption TPU, roadmap post-1.0. Aucune de ces réponses n’est dans les sources publiques à ce jour.

---

Faut-il mettre llm-d dans son stack en 2026 ? Le guide de décision

Arbre de décision rapide :

• Mono-nœud, faible concurrence, pas de préfixes partagés → vLLM ou SGLang seuls. llm-d n’apporte rien.
• Multi-nœuds, préfixes partagés, équipe Kubernetes → tester llm-d en staging. Gain probable, complexité réelle.
• Souveraineté / on-prem, flotte existante → llm-d mérite une évaluation sérieuse comme brique d’inférence contrôlée.
• Équipe sans compétence K8s/Gateway API → attendre ou passer par une offre managée.

Recommandations par profil :

• PME : attendre. Le surcoût d’ingénierie dépasse le gain tant que la flotte reste petite.
• Équipe infra internalisée : tester en staging sur une charge représentative (mesurer hit rate du cache, TTFT, throughput avant/après). Décider sur données propres, pas sur les slides partenaires.
• Souveraineté : adopter progressivement, en gardant vLLM/SGLang comme plan B.

Indicateurs à surveiller dans les 6–12 prochains mois : benchmarks indépendants (académiques ou presse), publication du hit rate du KV cache, chiffrage du coût par token, passage CNCF sandbox → incubating, support TPU documenté, roadmap post-1.0.

Ouverture. La prochaine bataille ne se jouera pas sur les slides de benchmark, mais sur le coût par token mesuré de façon indépendante. Tant que llm-d, Dynamo et les offres managées ne publieront pas leurs chiffres en dollars par million de tokens sur des charges reproductibles, la décision restera largement affaire de contexte. Et c’est peut-être le plus grand service que llm-d 1.0 rend à l’écosystème : rendre la question du self-hosting sérieuse, au point qu’on ne puisse plus y répondre avec un simple « ça dépend ».

---

Sources

• Google Cloud Ships llm-d 1.0 With Cache-Aware Routing for TPU and GPU Fleets — MarkTechPost, 20 octobre 2026
• IBM-backed llm-d framework adds controls for running AI models in-house — SiliconANGLE, 20 octobre 2026
• llm-d — GitHub officiel
• llm-d 1.0 est sorti : la pile d’inférence ouverte franchit le cap de la production — ToolNavs
• Inception Releases Mercury 3, Its Flagship Diffusion LLM — Unite.AI (contexte écosystème)
• Inception Releases Mercury 3 Diffusion LLM at 1,068 Tokens per Second — MarkTechPost, 19 octobre 2026 (contexte écosystème)