El equipo de Google ha lanzado llm-d 1.0, la primera versión estable de su pila de inferencia distribuida. Esta capa de código abierto nativa de Kubernetes convierte los servidores de modelos vLLM o SGLang en un único grupo coordinado. Lo lanzaron en la PyTorch Conference North America. Está dirigida a cargas de trabajo de agentes autohospedados y de RL, donde el equilibrio de carga round-robin falla.
TL;DR
- Una pila de servicio: Google informa de un benchmark publicado en un despliegue GKE multirregión de 17,000 nodos.
- Se ejecuta en: Kubernetes con GPUs de NVIDIA, AMD o Intel o TPUs de Google, sobre vLLM o SGLang.
- Rendimiento: Las mejoras reportadas por el proveedor provienen del enrutamiento consciente de caché, la descarga de caché KV por niveles y la disagregación de prefill/decode.
- Lo mejor: Reducción de la TTFT mediana en más del 85%, con 2.4 veces el rendimiento, en una carga de trabajo de codificación en TPU Ironwood.
- Lo peor: El time-slicing de RL solo eleva el ciclo de trabajo de los aceleradores a más del 70%, por lo que queda aproximadamente un 30% de tiempo inactivo.
¿Qué es llm-d 1.0?
llm-d fue fundado en 2025 por Red Hat, IBM, Google Cloud, CoreWeave y NVIDIA. Red Hat, IBM y Google son los mantenedores principales. El proyecto cuenta con más de 500 contribuyentes de más de 25 organizaciones. Es un proyecto CNCF Sandbox, aceptado el 12 de marzo de 2026, y está bajo licencia Apache 2.0.
El enrutamiento consciente de prefijos, la descarga de caché KV, la disagregación de prefill/decode, el paralelismo de expertos amplio y la inferencia por lotes ya se habían lanzado. La versión 1.0 se trata de ejecutarlos de forma fiable en producción, lo que IBM llama operaciones de día 2.
¿Qué hay de nuevo en llm-d 1.0?
- Calidad de servicio multiusuario: El control de flujo consciente de prioridad y equidad evita que los agentes con ráfagas de tráfico dejen sin recursos a las solicitudes sensibles a la latencia.
- Base estable: APIs v1 y una ruta de solicitudes reforzada, validada en múltiples nubes y aceleradores.
- Actualizaciones sin tiempo de inactividad: alta disponibilidad del Router con hot standby, además de DisaggregatedSet, que agrupa los pools de prefill y decode.
- Servido consciente de agentes: enrutamiento consciente de sesión, programación con prioridad por turno y estado nativo de la API de Responses.
- Inferencia asíncrona: llm-d-async-processor extrae trabajos de Google Cloud Pub/Sub o Redis hacia la capacidad libre.
- Soporte ampliado de TPU: TorchTPU ejecuta modelos de PyTorch de forma nativa dentro del vLLM y SGLang upstream.
¿Cómo enruta llm-d las solicitudes?
El router de llm-d se basa en la Kubernetes Gateway API Inference Extension. Rastrea qué réplicas contienen cada prefijo en caché. Luego pondera la carga y la latencia prevista antes de elegir una réplica. Los agentes llaman a un único endpoint, y cada paso aterriza donde su contexto ya reside.
Cuando la memoria del acelerador se llena, la caché KV se mueve a la memoria del host, luego a SSD o Managed Lustre. Utiliza vLLM’s OffloadingConnector, Mooncake o el HiCache de SGLang para esto. El prefill y el decode se ejecutan como pools separados, porque el prefill intensivo en cómputo y el decode está limitado por memoria.
</span><b>Solicitud del agente</b><small>1 endpoint</small></div> <div class="node"><span class="ic"></span><b>router de llm-d</b><small>consciente de prefijo y carga</small></div> <div class="node"><span class="ic"></span><b>Prefill / decode</b><small>grupos separados</small></div> <div class="node"><span class="ic"></span><b>KV cache por niveles</b><small>de HBM a 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 del acelerador</div> <div style="background:rgba(52,168,83,.15)">RAM de CPU del host</div> <div style="background:rgba(251,188,4,.15)">SSD local</div> <div style="background:rgba(234,67,53,.15)">Lustre gestionado</div> </div> <div class="ctl"> <button class="btn gh" id="mtp-prev">Atrás</button> <button class="btn" id="mtp-next">Siguiente paso</button> <button class="btn gh" id="mtp-play">Reproducción automática</button> <span class="st" id="mtp-st">Paso 1 de 4</span> </div> </div> <div class="pn"> <div class="seg"> <button class="btn" data-g="lat">Latencia y caché</button> <button class="btn gh" data-g="thr">Rendimiento</button> </div> <div class="bars" id="mtp-bars"></div> <div class="note">Todas las cifras son autorreportadas por Google, Snap y Zenteiq. Fuente: blog de Google Cloud, 20 de octubre de 2026.</div> </div> <div class="pn"> <div class="grid"> <div class="card"><span class="k">QoS multiusuario</span><b>Control de flujo</b><p>El enrutamiento con conciencia de prioridad y equidad evita que los bucles de agentes con ráfagas dejen a los usuarios interactivos sin servicio.</p></div> <div class="card"><span class="k">Actualizaciones</span><b>DisaggregatedSet</b><p>Construido sobre LeaderWorkerSet. Actualiza los grupos de prefill y decode juntos en versiones coincidentes sin abandonar sesiones.</p></div> <div class="card"><span class="k">Fiabilidad</span><b>Router HA</b><p>El standby activo y las actualizaciones continuas mantienen el tráfico fluyendo durante actualizaciones y mantenimiento.</p></div> <div class="card"><span class="k">Agentes</span><b>Enrutamiento consciente de sesión</b><p>La programación con prioridad por turno y el estado nativo de la API de Responses ayudan a los agentes a reutilizar el contexto entre turnos.</p></div> <div class="card"><span class="k">Trabajos en segundo plano</span><b>Procesador asíncrono</b><p>Extrae solicitudes de Google Cloud Pub/Sub o Redis y las ejecuta en la capacidad disponible.</p></div> <div class="card"><span class="k">TPU</span><b>Time-slicing de TorchTPU</b><p>Intercala la inferencia en los ciclos de RL inactivos. El ciclo de trabajo sube de aproximadamente 40% a más de 70%.</p></div> </div> <div class="note">Haz clic en una tarjeta para ver los detalles. Las API estables de la v1 están disponibles en todos los componentes.</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>Versión</td><td>1.0 (oct de 2026)</td><td>v1.5.1 (oct de 2026)</td><td>v0.7.0 (jun de 2026)</td></tr> <tr><td>Gobernanza</td><td>CNCF Sandbox</td><td>Liderado por NVIDIA</td><td>Organización del proyecto vLLM</td></tr> <tr><td>Motores</td><td>vLLM, SGLang</td><td>SGLang, TRT-LLM, vLLM</td><td>vLLM, SGLang, TRT-LLM</td></tr> <tr><td>Aceleradores</td><td>NVIDIA, AMD, Intel, TPU</td><td>GPU de NVIDIA</td><td>GPU mixtas</td></tr> <tr><td>Niveles de KV</td><td>HBM, CPU, SSD, Lustre</td><td>GPU, CPU, SSD, remoto</td><td>KV cache distribuida</td></tr> <tr><td>Licencia</td><td>Apache 2.0</td><td>Apache 2.0</td><td>Apache 2.0</td></tr> <tr><td>Estrellas en GitHub</td><td>4.8k</td><td>8.3k</td><td>5.1k</td></tr> </table></div> <div class="note">Estrellas al 20 de octubre de 2026. Fuentes: el repositorio de GitHub y la documentación de cada proyecto.</div> </div> <div class="ft"><span>Fuentes: 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 agente envía un paso de una tarea multirutorno a un único endpoint de llm-d. Los grupos de TPU y GPU están detrás, ejecutando vLLM o SGLang.', 'El router rastrea qué réplicas ya contienen cada prefijo en caché. Pesa la carga y la latencia prevista, y envía el paso a donde vive su contexto.', 'Prefill (intensivo en cómputo) y decode (limitado por memoria) se ejecutan en grupos separados. DisaggregatedSet actualiza ambos juntos sin abandonar sesiones.', 'Cuando la memoria del acelerador se llena, la KV cache se mueve a la RAM del host, luego a SSD o Google Cloud Managed Lustre en lugar de ser desalojado.']; 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='Step '+(s+1)+' of 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='Auto-play';return}b.textContent='Pause';timer=setInterval(function(){s=(s+1)%4;show()},2600)}; show(); var data={lat:[ ['Ironwood TPU: median TTFT cut','>85%',85,'#4285F4','agentic coding vs plain K8s Service'], ['Gemini: P95 TTFT cut (bursty chat)','>50%',50,'#34A853','GKE Inference Gateway'], ['A3 Mega 70B: TTFT improvement','~40%',40,'#FBBC04','Lustre + CPU offload, 50k-token prompts'], ['Gemini: TTFT cut (coding agents)','>35%',35,'#EA4335','production traffic'], ['Gemini: prefix cache hit rate','35% to 70%',70,'#4285F4','doubled']], thr:[ ['Zenteiq: aggregate throughput','>4x',4,'#34A853','1.47B to 5.97B tokens/day per 1,000 TPU v6e'], ['17,000-node GKE: throughput','2.9x',2.9,'#4285F4','3 clusters, 99.9% success'], ['Ironwood TPU: total throughput','2.4x',2.4,'#FBBC04','vs plain K8s Service']]}; 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">¿Qué muestran los benchmarks de llm-d 1.0?
Todas las cifras siguientes son autodeclaradas por Google y los usuarios de llm-d.
- Ironwood TPU (TPU 7x): el enrutamiento consciente de prefijos más la descarga a memoria del host redujo la TTFT mediana en más del 85%. El rendimiento aumentó 2.4x en comparación con un Kubernetes Service simple.
- Plataforma Gemini: la tasa de aciertos de la caché de prefijos se duplicó del 35% al 70%. La TTFT cayó más del 35% para agentes de codificación. La TTFT P95 cayó más del 50% bajo chat con ráfagas.
- Benchmark de GKE con 17,000 nodos: el rendimiento escaló 2.9x en 3 clústeres, con 99.9% de éxito y menos del 1% de sobrecarga.
- A3 Mega, modelo de 70B: Lustre más la descarga a RAM de CPU mejoró la TTFT en aproximadamente 40% en prompts de 50k tokens. La latencia de extremo a extremo cayó 30% y las horas de GPU cayeron casi 60%.
- Time-slicing para RL: el ciclo de trabajo del acelerador subió de aproximadamente 40% a más del 70%.
Los usuarios reportan patrones similares. Snap reporta tasas de aciertos de caché de prefijos de hasta 75 a 80%. Zenteiq reporta más de 4x de rendimiento, de 1.47 mil millones a 5.97 mil millones de tokens diarios por 1,000 chips TPU v6e. Una demostración de IBM sirvió 3,000 agentes de codificación concurrentes a entre 5 y 10 veces por debajo del precio de API.
¿Cómo se compara llm-d con NVIDIA Dynamo y AIBrix?
| Característica | llm-d 1.0 | NVIDIA Dynamo | AIBrix |
|---|---|---|---|
| Última versión | 1.0 (20 de oct de 2026) | v1.5.1 (6 de oct de 2026) | v0.7.0 (16 de jun de 2026) |
| Licencia | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| Gobernanza | CNCF Sandbox | Liderado por NVIDIA (organización ai-dynamo) | Organización del proyecto vLLM, origen ByteDance |
| Motores | vLLM, SGLang | SGLang, TensorRT-LLM, vLLM | vLLM, SGLang, TensorRT-LLM |
| Aceleradores | GPUs NVIDIA, AMD, Intel, Google TPU | GPUs NVIDIA (Blackwell, Hopper, Ada, Ampere) | GPUs mixtas (servicio heterogéneo) |
| Enrutamiento consciente de caché | Sí, consciente de prefijo y de carga | Sí, consciente de KV | Sí, enrutamiento de pasarela |
| Niveles de caché KV | HBM, CPU, SSD, Managed Lustre | GPU, CPU, SSD, almacenamiento remoto (KVBM) | Caché KV distribuida |
| Desagregación P/D | Sí, DisaggregatedSet | Sí | Sí |
| Resultado destacado | Rendimiento 2.9 veces mayor, 17,000 nodos (autocomunicado) | TTFT 2 veces más rápido, Qwen3-Coder 480B (Baseten) | No divulgado |
No son rivales estrictos. CoreWeave ejecuta llm-d junto con Dynamo, y NVIDIA contribuye componentes de Dynamo a llm-d.
¿Cómo se despliega llm-d 1.0?
En Google Cloud, GKE Inference Gateway ejecuta el enrutador de llm-d como servicio administrado. También puede abarcar clústeres y regiones con conmutación por error global. KEDA y HPA escalan los pools según la profundidad de la cola y la latencia prevista. Kueue aplica cuotas por modelo. Charts de Helm verificados despliegan pools de TPU y GPU detrás de un único endpoint.
El equipo de Google sugiere una ruta por etapas. Comience con el enrutamiento consciente de prefijos frente a un despliegue existente de vLLM. Luego añada control de flujo, descarga de KV por niveles y desagregación. Las ejecuciones publicadas pueden compararse en Prism.
Conclusiones clave
- llm-d 1.0 es la primera versión estable, con las APIs v1.
- Novedades: control de flujo, alta disponibilidad del router, DisaggregatedSet y enrutamiento consciente de agentes.
- Gemini duplicó los aciertos de caché de prefijos del 35% al 70%.
- Un benchmark de 17,000 nodos en GKE escaló el rendimiento 2.9x.
Echa un vistazo a la anuncio de Google Cloud, el artículo de IBM Research, el repositorio de GitHub y los documentos de GKE. Todo el mérito es del investigador de este proyecto. Además, no dudes en seguirnos en Twitter y no olvides unirte a nuestro 150k+ML SubReddit y suscribirte a nuestro Newsletter. ¡Espera! ¿estás en telegram? ahora también puedes unirte a nosotros en telegram.
La entrada Google Cloud Ships llm-d 1.0 With Cache-Aware Routing for TPU and GPU Fleets apareció primero en MarkTechPost.