L'équipe de Google a publié llm-d 1.0, la première version stable de sa pile d'inférence distribuée. Cette couche open source native de Kubernetes transforme les serveurs de modèles vLLM ou SGLang en un pool unique et coordonné. Ils l'ont publiée lors de la PyTorch Conference North America. Elle cible les charges de travail d'agents auto-hébergés et de RL, où l'équilibrage de charge round-robin atteint ses limites.
TL;DR
- Une pile de service: Google rapporte un benchmark publié sur un déploiement GKE multi-régions de 17,000 nœuds.
- Fonctionne sur : Kubernetes avec des GPU NVIDIA, AMD ou Intel ou des TPU de Google, sur vLLM ou SGLang.
- Performance : les gains rapportés par les fournisseurs proviennent du routage conscient du cache, du déchargement hiérarchisé du KV cache et de la désagrégation prefill/decode.
- Points forts : TTFT médian réduit de plus de 85 %, avec un débit multiplié par 2.4, sur une charge de travail de codage sur TPU Ironwood.
- Points faibles : le time-slicing RL ne fait passer le taux d'activité des accélérateurs qu'à plus de 70 %, si bien qu'il reste environ 30 % de temps d'inactivité.
Qu'est-ce que llm-d 1.0 ?
llm-d a été fondé en 2025 par Red Hat, IBM, Google Cloud, CoreWeave et NVIDIA. Red Hat, IBM et Google en sont les principaux mainteneurs. Le projet compte plus de 500 contributeurs issus de plus de 25 organisations. C'est un projet CNCF Sandbox, accepté le 12 mars 2026, et sous licence Apache 2.0.
Le routage conscient des préfixes, le déchargement du KV cache, la désagrégation prefill/decode, le parallélisme large d'experts et l'inférence par lots sont déjà livrés. La version 1.0 consiste à les faire fonctionner de manière fiable en production, ce qu'IBM appelle les opérations du jour 2.
Quoi de neuf dans llm-d 1.0 ?
- Qualité de service multi-tenant: le contrôle de flux conscient des priorités et de l'équité empêche les agents rafalistes d'affamer les requêtes sensibles à la latence.
- Fondation stable: API en v1 et un chemin de requêtes durci, validé sur plusieurs clouds et accélérateurs.
- Mises à niveau sans interruption de service: haute disponibilité du routeur avec standby à chaud, plus DisaggregatedSet, qui regroupe les pools de préfill et de décodage.
- Service adapté aux agents: routage sensible aux sessions, ordonnancement prioritaire par tour et état natif de l'API Responses.
- Inférence asynchrone: llm-d-async-processor récupère les tâches depuis Google Cloud Pub/Sub ou Redis vers la capacité disponible.
- Support TPU élargi: TorchTPU exécute nativement les modèles PyTorch dans vLLM et SGLang amont.
Comment llm-d route-t-il les requêtes ?
Le routeur llm-d s'appuie sur l'extension d'inférence de l'API Gateway de Kubernetes. Il suit quelles répliques détiennent chaque préfixe en cache. Il pondère ensuite la charge et la latence prévue avant de choisir une réplique. Les agents appellent un seul point de terminaison, et chaque étape atterrit là où réside déjà son contexte.
Lorsque la mémoire de l'accélérateur se remplit, le cache KV est déplacé vers la mémoire de l'hôte, puis vers SSD ou Managed Lustre. Il utilise pour cela le OffloadingConnector de vLLM, Mooncake ou le HiCache de SGLang. Le préfill et le décodage s'exécutent dans des pools séparés, car le préfill est gourmand en calcul et le décodage est limité par la mémoire.
</span><b>Requête d'agent</b><small>1 endpoint</small></div> <div class="node"><span class="ic"></span><b>routeur llm-d</b><small>préfixe + équilibrage de charge</small></div> <div class="node"><span class="ic"></span><b>Prefill / decode</b><small>pools séparés</small></div> <div class="node"><span class="ic"></span><b>Cache KV hiérarchisé</b><small>de HBM à Lustre</small></div> </div> <div class="pkt"><span></span></div> <div class="exp" id="mtp-exp"></div> <div class="tiers" id="mtp-tiers"> <div style="background:rgba(66,133,244,.15)">HBM de l'accélérateur</div> <div style="background:rgba(52,168,83,.15)">RAM CPU de l'hôte</div> <div style="background:rgba(251,188,4,.15)">SSD local</div> <div style="background:rgba(234,67,53,.15)">Lustre managé</div> </div> <div class="ctl"> <button class="btn gh" id="mtp-prev">Retour</button> <button class="btn" id="mtp-next">Étape suivante</button> <button class="btn gh" id="mtp-play">Lecture automatique</button> <span class="st" id="mtp-st">Étape 1 sur 4</span> </div> </div> <div class="pn"> <div class="seg"> <button class="btn" data-g="lat">Latence et cache</button> <button class="btn gh" data-g="thr">Débit</button> </div> <div class="bars" id="mtp-bars"></div> <div class="note">Toutes les chiffres sont auto-déclarés par Google, Snap et Zenteiq. Source : blog Google Cloud, 20 octobre 2026.</div> </div> <div class="pn"> <div class="grid"> <div class="card"><span class="k">QoS multi-locataires</span><b>Contrôle de flux</b><p>Un routage sensible aux priorités et à l'équité empêche les boucles d'agents irrégulières d'affamer les utilisateurs interactifs.</p></div> <div class="card"><span class="k">Mises à niveau</span><b>DisaggregatedSet</b><p>Construit sur LeaderWorkerSet. Déploie ensemble les pools de prefill et de decode sur des versions correspondantes sans interrompre les sessions.</p></div> <div class="card"><span class="k">Fiabilité</span><b>HA du routeur</b><p>Le standby à chaud et les mises à jour déroulantes maintiennent le trafic pendant les mises à niveau et la maintenance.</p></div> <div class="card"><span class="k">Agents</span><b>Routage sensible aux sessions</b><p>L'ordonnancement par priorité de tour et l'état natif de l'API Responses aident les agents à réutiliser le contexte entre les tours.</p></div> <div class="card"><span class="k">Tâches en arrière-plan</span><b>Processeur asynchrone</b><p>Récupère les requêtes depuis Google Cloud Pub/Sub ou Redis et les exécute dans la capacité disponible.</p></div> <div class="card"><span class="k">TPU</span><b>Time-slicing TorchTPU</b><p>Entrelace l'inférence dans les cycles RL inactifs. Le taux d'occupation passe d'environ 40% à plus de 70%.</p></div> </div> <div class="note">Cliquez sur une carte pour révéler les détails. Des API stables en v1 sont disponibles pour tous les composants.</div> </div> <div class="pn"><div class="tw"> <table> <tr><th></th><th class="us">llm-d 1.0</th><th>NVIDIA Dynamo</th><th>AIBrix</th></tr> <tr><td>Version</td><td>1.0 (oct. 2026)</td><td>v1.5.1 (oct. 2026)</td><td>v0.7.0 (juin 2026)</td></tr> <tr><td>Gouvernance</td><td>CNCF Sandbox</td><td>Dirigé par NVIDIA</td><td>Organisation du projet vLLM</td></tr> <tr><td>Moteurs</td><td>vLLM, SGLang</td><td>SGLang, TRT-LLM, vLLM</td><td>vLLM, SGLang, TRT-LLM</td></tr> <tr><td>Accélérateurs</td><td>NVIDIA, AMD, Intel, TPU</td><td>GPU NVIDIA</td><td>GPU mixtes</td></tr> <tr><td>Niveaux KV</td><td>HBM, CPU, SSD, Lustre</td><td>GPU, CPU, SSD, distant</td><td>Cache KV distribué</td></tr> <tr><td>Licence</td><td>Apache 2.0</td><td>Apache 2.0</td><td>Apache 2.0</td></tr> <tr><td>Étoiles GitHub</td><td>4.8k</td><td>8.3k</td><td>5.1k</td></tr> </table></div> <div class="note">Étoiles au 20 octobre 2026. Sources : dépôt GitHub et documentation de chaque projet.</div> </div> <div class="ft"><span>Sources : Google Cloud, IBM Research, Red Hat, GitHub</span><a href="https://www.marktechpost.com" target="_blank" rel="noopener">© Marktechpost</a></div> </div> <script> (function(){ var R=document.getElementById('mtp-llmd1'); var tabs=R.querySelectorAll('.tabs button'),pns=R.querySelectorAll('.pn'); tabs.forEach(function(b){b.onclick=function(){tabs.forEach(function(x){x.classList.remove('on')});pns.forEach(function(x){x.classList.remove('on')});b.classList.add('on');pns[+b.dataset.t].classList.add('on');if(+b.dataset.t===1)draw(cur);rs();};}); var steps=[ 'Un agent envoie une étape d\'une tâche multi-tours à un endpoint llm-d unique. Des pools de TPU et de GPU se trouvent derrière lui, exécutant vLLM ou SGLang.', 'Le routeur suit quelles répliques détiennent déjà chaque préfixe en cache. Il pondère la charge et la latence prédite, puis envoie l\'étape là où réside son contexte.', 'Le prefill (gourmand en calcul) et le decode (limité par la mémoire) s\'exécutent dans des pools séparés. DisaggregatedSet met à niveau les deux ensemble sans interrompre les sessions.', 'Lorsque la mémoire de l\'accélérateur se remplit, le cache KV passe dans la RAM de l\'hôte, puis sur SSD ou Google Cloud Managed Lustre au lieu d'être évincé.']; var s=0,nodes=R.querySelectorAll('.node'),pk=R.querySelector('.pkt span'),ex=document.getElementById('mtp-exp'),st=document.getElementById('mtp-st'),ti=R.querySelectorAll('#mtp-tiers div'),timer=null; function show(){nodes.forEach(function(n,i){n.classList.toggle('act',i===s)});pk.style.left=(s*25)+'%';ex.textContent=steps[s];st.textContent='Étape '+(s+1)+' sur 4'; ti.forEach(function(t,i){t.classList.remove('lit');if(s===3)setTimeout(function(){t.classList.add('lit')},i*350);else if(i===0)t.classList.add('lit')});} document.getElementById('mtp-next').onclick=function(){s=(s+1)%4;show()}; document.getElementById('mtp-prev').onclick=function(){s=(s+3)%4;show()}; document.getElementById('mtp-play').onclick=function(){var b=this;if(timer){clearInterval(timer);timer=null;b.textContent='Lecture automatique';return}b.textContent='Pause';timer=setInterval(function(){s=(s+1)%4;show()},2600)}; show(); var data={lat:[ ['Ironwood TPU : réduction médiane du TTFT','>85%',85,'#4285F4','codage agentique vs K8s Service simple'], ['Gemini : réduction du P95 TTFT (chat par rafales)','>50%',50,'#34A853','GKE Inference Gateway'], ['A3 Mega 70B : amélioration du TTFT','~40%',40,'#FBBC04','Lustre + déchargement CPU, invites de 50k tokens'], ['Gemini : réduction du TTFT (agents de codage)','>35%',35,'#EA4335','trafic de production'], ['Gemini : taux de réussite du cache de préfixes','35% à 70%',70,'#4285F4','doublé']], thr:[ ['Zenteiq : débit global','>4x',4,'#34A853','de 1.47B à 5.97B tokens/jour par 1,000 TPU v6e'], ['GKE à 17,000 nœuds : débit','2.9x',2.9,'#4285F4','3 clusters, 99.9% de réussite'], ['Ironwood TPU : débit total','2.4x',2.4,'#FBBC04','vs K8s Service simple']]}; var cur='lat'; function draw(g){cur=g;var box=document.getElementById('mtp-bars'),mx=g==='thr'?4:100;box.innerHTML=''; data[g].forEach(function(d){var r=document.createElement('div');r.className='row';r.innerHTML='<div class="lb"><span>'+d[0]+' <em>'+d[4]+'</em></span><b>'+d[1]+'</b></div><div class="tr"><div class="fl" style="background:'+d[3]+'"></div></div>';box.appendChild(r); var f=r.querySelector('.fl');setTimeout(function(){f.style.width=(d[2]/mx*100)+'%'},60);});rs();} R.querySelectorAll('[data-g]').forEach(function(b){b.onclick=function(){R.querySelectorAll('[data-g]').forEach(function(x){x.classList.add('gh')});b.classList.remove('gh');draw(b.dataset.g)}}); R.querySelectorAll('.card').forEach(function(c){c.onclick=function(){c.classList.toggle('open');setTimeout(rs,380)}}); function rs(){try{parent.postMessage({mtpH:R.offsetHeight+40,id:'mtp-llmd1'},'*')}catch(e){}} window.addEventListener('load',rs);window.addEventListener('resize',rs);setTimeout(rs,300); })(); </script> </body></html> " style="width:100%;max-width:880px;height:600px;border:0;display:block;margin:0 auto;" loading="lazy">Que montrent les benchmarks de llm-d 1.0 ?
Tous les chiffres ci-dessous sont déclarés par Google lui-même et par les adoptants de llm-d.
- Ironwood TPU (TPU 7x) : le routage tenant compte des préfixes plus le déchargement vers la mémoire hôte ont réduit le TTFT médian de plus de 85 %. Le débit a augmenté de 2,4x par rapport à un Service Kubernetes simple.
- Plateforme Gemini : le taux de réussite du cache de préfixes a doublé, passant de 35 % à 70 %. Le TTFT a baissé de plus de 35 % pour les agents de codage. Le TTFT P95 a baissé de plus de 50 % sous un chat en rafales.
- Benchmark GKE à 17,000 nœuds : le débit a été multiplié par 2.9 sur 3 clusters, avec 99.9% de réussite et moins de 1% de surcoût.
- A3 Mega, modèle 70B : Lustre plus le déchargement vers la RAM CPU ont amélioré le TTFT d'environ 40 % sur des prompts de 50k tokens. La latence de bout en bout a baissé de 30 % et les GPU-heures de près de 60 %.
- Découpage temporel RL : le taux d'activité des accélérateurs est passé d'environ 40 % à plus de 70 %.
Les utilisateurs rapportent des schémas similaires. Snap signale des taux de réussite du cache de préfixes allant jusqu'à 75 à 80%. Zenteiq rapporte un débit supérieur à 4x, passant de 1.47 milliard à 5.97 milliards de tokens quotidiens par 1,000 puces TPU v6e. Une démonstration d'IBM a servi 3,000 agents de codage simultanés à des prix 5 à 10 fois inférieurs à ceux des API.
Comment llm-d se compare-t-il à NVIDIA Dynamo et AIBrix ?
| Fonctionnalité | llm-d 1.0 | NVIDIA Dynamo | AIBrix |
|---|---|---|---|
| Dernière version | 1.0 (20 oct. 2026) | v1.5.1 (6 oct. 2026) | v0.7.0 (16 juin 2026) |
| Licence | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| Gouvernance | CNCF Sandbox | Piloté par NVIDIA (organisation ai-dynamo) | Organisation du projet vLLM, origine ByteDance |
| Moteurs | vLLM, SGLang | SGLang, TensorRT-LLM, vLLM | vLLM, SGLang, TensorRT-LLM |
| Accélérateurs | GPU NVIDIA, AMD, Intel, TPU Google | GPU NVIDIA (Blackwell, Hopper, Ada, Ampere) | GPU mixtes (service hétérogène) |
| Routage sensible au cache | Oui, sensible au préfixe et à la charge | Oui, sensible au KV | Oui, routage par passerelle |
| Niveaux de cache KV | HBM, CPU, SSD, Lustre managé | GPU, CPU, SSD, stockage distant (KVBM) | Cache KV distribué |
| Désagrégation P/D | Oui, DisaggregatedSet | Oui | Oui |
| Résultat phare | Débit 2.9x supérieur, 17,000 nœuds (auto-déclaré) | TTFT 2x plus rapide, Qwen3-Coder 480B (Baseten) | Non divulgué |
Ce ne sont pas des concurrents directs. CoreWeave exécute llm-d aux côtés de Dynamo, et NVIDIA contribue des composants Dynamo à llm-d.
Comment déployer llm-d 1.0 ?
Sur Google Cloud, GKE Inference Gateway exécute le routeur llm-d en tant que service managé. Il peut également s'étendre sur plusieurs clusters et régions avec basculement global. KEDA et HPA dimensionnent les pools selon la profondeur des files d'attente et la latence prédite. Kueue applique des quotas par modèle. Des charts Helm vérifiés déploient des pools TPU et GPU derrière un seul point de terminaison.
L'équipe Google suggère un parcours par étapes. Commencer par le routage sensible au préfixe devant un déploiement vLLM existant. Puis ajouter le contrôle de flux, le déchargement KV par niveaux et la désagrégation. Les exécutions publiées peuvent être comparées sur Prism.
Points clés à retenir
- llm-d 1.0 est la première version stable, avec les API v1.
- Nouveautés : contrôle de flux, haute disponibilité du routeur, DisaggregatedSet et routage conscient des agents.
- Gemini a doublé le taux de succès du cache de préfixe, de 35 % à 70 %.
- Un benchmark GKE sur 17,000 nœuds a multiplié le débit par 2.9.
Découvrez l'annonce de Google Cloud, le poste d'IBM Research, le dépôt GitHub et les docs GKE. Tout le mérite revient au chercheur de ce projet. Par ailleurs, n'hésitez pas à nous suivre sur Twitter et n'oubliez pas de rejoindre notre SubReddit 150k+ML et de vous abonner à notre Newsletter. Attention ! êtes-vous sur telegram ? vous pouvez désormais nous rejoindre également sur telegram.
Le billet Google Cloud Ships llm-d 1.0 With Cache-Aware Routing for TPU and GPU Fleets est apparu en premier sur MarkTechPost.