Un 85 % menos de tiempo hasta el primer token y 2,4 veces más throughput que un Service de Kubernetes normal: es lo que Google mide con llm-d en una carga de agentes de código sobre TPU Ironwood. El 20 de octubre de 2026, en la PyTorch Conference, el proyecto publicó su versión 1.0, con APIs v1 y la promesa de estabilidad que faltaba para llevarlo a producción sin miedo a cada actualización.
Qué es llm-d y por qué un balanceador normal no basta
llm-d es una capa de orquestación que se pone por encima de los servidores de modelos (vLLM, SGLang) y convierte un grupo de réplicas en un único pool coordinado. Es un proyecto Sandbox de la CNCF, con licencia Apache 2.0, fundado por Red Hat, Google Cloud, IBM Research, CoreWeave y NVIDIA, y con más de 500 contribuidores de 25 organizaciones según Google.
El problema que resuelve es muy de SRE. Un balanceo round-robin asume peticiones rápidas, uniformes y baratas, y las de un LLM no son nada de eso: los agentes reenvían una y otra vez el mismo prefijo creciente, una respuesta puede tardar más de un minuto y el tamaño va de mil tokens a más de cien mil. Si cada paso de un agente cae en una réplica distinta, cada réplica recalcula el mismo prompt, la memoria del acelerador se llena de estado duplicado y un bucle de agente con ráfagas deja sin servicio a los usuarios interactivos.
El router de llm-d se apoya en Gateway API Inference Extension: sabe qué réplica tiene en caché cada prefijo y pondera también la carga y la latencia prevista antes de elegir destino.
Lo que trae la 1.0
La mayoría de piezas ya existían en versiones 0.x (enrutado por prefijo y carga, descarga de la caché KV, separación de prefill y decode, wide expert parallelism). Lo nuevo es lo que hace falta para operarlo:
- Calidad de servicio multi-tenant: el flow control aplica prioridades y reparto justo para que el tráfico sensible a latencia y las ráfagas de agentes compartan flota sin pisarse los SLO.
- APIs v1 y un camino de petición endurecido, validado en varias nubes y tipos de acelerador.
- Actualizaciones sin corte: alta disponibilidad del router y
DisaggregatedSet, construido sobre LeaderWorkerSet, que despliega prefill y decode como una unidad con versiones emparejadas sin perder el contexto de las sesiones activas. - Servicio pensado para agentes: enrutado por sesión, prioridad por turno y estado nativo de la Responses API.
- Procesado asíncrono con
llm-d-async-processor, que saca peticiones de colas como Pub/Sub o Redis y las ejecuta en la capacidad libre, con carriles de prioridad y cuotas.
La caché KV por niveles es lo que más se nota en conversaciones largas: cuando la memoria del acelerador se llena, llm-d mueve la caché a la RAM del host y de ahí a SSD o a Managed Lustre (con el OffloadingConnector de vLLM, Mooncake o HiCache de SGLang) en lugar de descartarla.
Las cifras y de dónde salen
Casi todos los números del anuncio son de Google sobre su propia infraestructura, así que hay que leerlos como lo que son: el techo en un entorno muy optimizado.
| Escenario | Resultado |
|---|---|
| Agentes de código en TPU Ironwood, enrutado por prefijo + caché en host | TTFT mediano −85 %, throughput ×2,4 frente a un Service |
| Plataforma Gemini en producción vía GKE Inference Gateway | Acierto de caché de prefijos del 35 % al 70 % |
| 17.000 nodos GKE en tres clústeres (EE. UU. y Europa) | Throughput ×2,9 con un 99,9 % de éxito |
| Llama 3.1 70B en 4 AMD MI300X (Red Hat) | Throughput de salida ×3 y TTFT ×2 frente a round-robin |
La última fila es la que más me interesa: es hardware de AMD, sin TPU ni servicios gestionados de Google, y la mejora sigue siendo de un factor tres. El efecto viene sobre todo de no recalcular prefijos, y eso es independiente de la nube.
Cómo desplegar la configuración base
La guía Optimized Baseline es el punto de partida que recomienda el proyecto: dos réplicas de Qwen/Qwen3-32B con vLLM en GPU NVIDIA (referencia: H100 de 80 GB, TP=2, 4 GPU en total) y el router en modo standalone, con Envoy incluido. Hacen falta kubectl, helm y un token de Hugging Face en el secreto llm-d-hf-token.
git clone https://github.com/llm-d/llm-d.git && cd llm-d
export REPO_ROOT=$(realpath $(git rev-parse --show-toplevel))
source ${REPO_ROOT}/guides/env.sh
export GUIDE_NAME="quickstart" NAMESPACE=llm-d-quickstart
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/${GAIE_URL}/v1-manifests.yaml
kubectl create namespace ${NAMESPACE} --dry-run=client -o yaml | kubectl apply -f -
helm install ${GUIDE_NAME} ${ROUTER_STANDALONE_CHART} \
-f guides/recipes/router/base.values.yaml \
-f guides/optimized-baseline/router/optimized-baseline.values.yaml \
-n ${NAMESPACE} --version ${ROUTER_CHART_VERSION}
kubectl apply -n ${NAMESPACE} -k guides/optimized-baseline/modelserver/gpu/vllm/base/guides/env.sh resuelve por defecto las versiones a latest; para un entorno serio, fija las variables *_VERSION que el propio script expone y así no te cambia el chart entre dos despliegues. En GKE no hace falta el modo standalone: GKE Inference Gateway ejecuta el router de llm-d como servicio gestionado y añade failover entre regiones.
Checklist antes de producción
- Mide tu
peakPrefillThroughputcon la receta de calibración del repo y ajústalo en el filtro de afinidad: el valor por defecto está pensado para Qwen3-32B en H100 y es lo que decide cuándo repartir carga en vez de mantener la afinidad. - Compara contra tu balanceador actual con la misma carga multi-turno; llm-d-benchmark e inference-perf tienen recetas reproducibles, y Prism permite subir tus resultados junto a los publicados.
- Prueba una actualización con
DisaggregatedSetcon tráfico real antes de confiar en el zero-downtime. - Revisa el autoescalado: KEDA o HPA sobre profundidad de cola y saturación, no sobre CPU.
Si hoy sirves modelos propios detrás de un Service y tus usuarios son agentes, la 1.0 es la primera versión en la que tiene sentido planteárselo como pieza estable del clúster y no como experimento.
Fuentes
- Announcing llm-d 1.0 — Google Cloud Blog, 20 de octubre de 2026.
- Repositorio llm-d — README, licencia y cifras de rendimiento.
- Quickstart de llm-d — comandos de instalación.
- Guía Optimized Baseline — modelo, hardware de referencia y calibración.