# llm-d, software libre para inferencia distribuida > llm-d 1.0 reparte la inferencia entre clústeres con vLLM y SGLang y convierte el coste por token en la nueva línea de competición de la IA abierta. > Por José Maldonado · Inteligencia Artificial · 2026-10-22 Repartir una IA entre decenas de servidores parece fontanería hasta que llega la factura de la nube. La pila llm-d alcanzó el 20 de octubre de 2026 su versión 1.0, una entrega que convierte réplicas sueltas en una flota capaz de decidir en qué máquina corre cada petición, según el [anuncio de Google Cloud](https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference). El proyecto nació en 2025 con Red Hat, IBM, Google Cloud, CoreWeave y NVIDIA como fundadores, y desde el 24 de marzo de 2026 es un proyecto sandbox de la [Cloud Native Computing Foundation](https://www.cncf.io/blog/2026/03/24/welcome-llm-d-to-the-cncf-evolving-kubernetes-into-sota-ai-infrastructure), la fundación que cobija Kubernetes. Esa gobernanza importa, porque no es el producto de una nube que quiere vender su cuota, sino una pieza que varias empresas rivales mantienen en común. Hoy firma el código más de 500 personas de 25 organizaciones. La versión 1.0 se mide en dos magnitudes que hasta ahora iban por separado: latencia y dinero. IBM Research sirve modelos abiertos con esta pila a unos 0,11 dólares por millón de tokens y calcula un coste 11,5 veces menor que una configuración propietaria equivalente, según la [nota de prensa de Red Hat](https://www.redhat.com/en/about/press-releases/llm-d-1-advances-open-cost-efficient-ai-inference-production-scale). Con esos números, llm-d ha convertido la inferencia distribuida en una línea de competición y ha dado a quien sirve modelos propios una vara de medir que no depende del folleto comercial de su proveedor. ## De servir un modelo a operar una flota Las versiones 0.x resolvieron el alcance: enrutado que atiende a la caché de prefijos, descarga de la memoria de contexto a RAM o disco, separación del cálculo del contexto y de la generación, y paralelismo para modelos de expertos. La 1.0 añade lo que aparece cuando el sistema ya está en producción: varios inquilinos sobre la misma flota, prioridades que compiten y actualizaciones que no pueden tirar el servicio. El enrutador es la pieza que decide. Guarda memoria de qué réplica tiene cada contexto, pesa la carga y la latencia prevista, y elige destino para cada paso de un agente. Su oficio consiste en no repetir cómputo. Construido sobre Gateway API Inference, cuando la memoria de la aceleradora se llena mueve esa caché a RAM, a SSD o a almacenamiento Lustre en lugar de tirarla, y evita las tormentas de desalojo que aparecen con contextos largos. En la demostración de la PyTorch Conference, 1.000 agentes aislados atacaron un único punto de entrada servido por vLLM y SGLang sobre una mezcla de TPU y GPU de Google Cloud. ![Esquema de funcionamiento de llm-d y su plataforma](https://content.observatorioblockchain.com/wp-content/uploads/2026/10/lld-funcionamiento-scaled.webp) *Esquema de funcionamiento de llm-d y su plataforma* Las cifras del lanzamiento apuntan a ese mismo cuello de botella. En un despliegue de 17.000 nodos repartido en tres clústeres, el enrutador multiplicó por 2,9 el caudal con un 99,9% de peticiones correctas y menos del 1% de sobrecarga, según las mediciones que publica Google Cloud. En una prueba de código agéntico sobre TPU Ironwood, el enrutado por prefijos recortó más de un 85% la latencia mediana hasta el primer token y elevó el caudal 2,4 veces frente a un servicio de Kubernetes convencional. Nada de eso obliga a cambiar de motor. La pila se apoya en vLLM y SGLang, los dos servidores de modelos abiertos con más recorrido, y acepta otros a través de sus conectores. Quien ya tiene un despliegue de vLLM puede poner el enrutado delante y añadir después el control de flujo. ## El coste por token entra en el marcador Durante dos años la conversación sobre IA abierta se dirimió en pruebas de calidad. La versión 1.0 mueve la discusión a la tabla del dinero por token servido, donde los números se comprueban mejor porque salen de la factura y no del banco de pruebas. Prueba Qué se cambió Dato publicado Tres clústeres, 17.000 nodos Enrutado multiclúster 2,9 veces más caudal con 99,9% de éxito Modelo de 70.000 millones en A3 Mega Descarga de caché a Lustre Casi 60% menos horas de GPU con prompts de 50.000 tokens GLM 5.2 en 544 H100 Caché, separación de fases y paralelismo de expertos 6,6 millones de tokens por minuto y hasta 3.000 agentes a la vez Corrección de errores cuánticos en IBM Modelos abiertos sobre llm-d 0,11 dólares por millón de tokens, 11,5 veces menos que una pila propietaria La palanca principal es la caché de prefijos. Buena parte del tráfico agéntico no produce tokens nuevos, sino que relee el mismo contexto una y otra vez, y cada relectura que acierta en caché es cómputo que no se paga. Gemini, la plataforma que antes se llamaba Vertex AI, dobló su tasa de acierto del 35% al 70% al pasar por el gateway de GKE construido sobre llm-d, y recortó más de un 35% la latencia del primer token en agentes de código. Hay una segunda vía, menos elegante y muy rentable. Durante el entrenamiento por refuerzo las aceleradoras pasan entre un 40% y un 60% del tiempo paradas, esperando turno entre la generación de trayectorias y la actualización de pesos. La 1.0 intercala inferencia asíncrona en esos huecos y sube el uso agregado del 40% a más del 70%. ## ¿Qué gana quien autohospeda su propio modelo? Para un equipo que sirve sus propios pesos, el cambio de fondo no es una función nueva, sino la posibilidad de mezclar hardware sin tocar la aplicación que consume el modelo. La promesa fundacional del proyecto se sostiene justo en esa separación, porque el mismo plano de control sirve para cualquier modelo en cualquier acelerador. La versión 1.0 valida el mismo plano de control sobre GPU de AMD, Intel y NVIDIA, sobre TPU de Google y sobre aceleradores minoritarios como los NPU de Rebellions, con guías para cada plataforma. DigitalOcean sirve el modelo Kimi K3, de un billón de parámetros, entre tarjetas AMD y NVIDIA con la misma capa, y Roblox reparte modelos entre nube y GPU propias. El segundo cambio es que Kubernetes deja de ser obligatorio. Desde mayo de 2026 el enrutador puede descubrir servidores mediante un fichero, sin servidor de API, sin objetos propios y sin permisos de clúster, de modo que la misma lógica corre en Slurm, dentro de un trabajo de Ray o en un rack desnudo. Para un centro de cálculo universitario, esa es la diferencia entre [adoptar la pila](https://llm-d.ai/blog/running-llm-d-without-kubernetes) y reescribirla para cada framework. Queda un precio que no aparece en los benchmarks, porque alguien tiene que operar todo esto: métricas en Prometheus, trazas con OpenTelemetry, gráficas de Helm sin cortes y guardias que responden cuando la cola crece. Los datos de producción que acompañan al lanzamiento vienen de equipos con ese músculo. JetBrains sirve su plan Junie Lite sobre llm-d, y Tesla y Red Hat reportan el triple de tokens por segundo con Llama 3.1 70B sobre MI300X. Son cifras de proveedor, aunque coinciden en la dirección: el cuello de botella se mueve de la tarjeta al software que la reparte. ## Las letras pequeñas de los benchmarks Todos los porcentajes anteriores los publica quien vende la pila o quien la usa, no un laboratorio independiente. La comparación de IBM con una configuración propietaria es suya, con su modelo y su carga de trabajo. El ahorro de 11,5 veces describe ese caso concreto y no una regla general. La ganancia depende de la reutilización de contexto. Un acierto de caché del 98% exige tráfico con prefijos largos y repetidos, como los agentes de código o las trayectorias de entrenamiento; un chatbot de una pregunta y una respuesta apenas repite nada y se queda con la parte pequeña. Snap reporta aciertos del 75% al 80%, y ese rango, más que el 98%, es lo razonable para una carga conversacional. También hay un umbral de tamaño. El control de flujo, la alta disponibilidad del enrutador y las actualizaciones escalonadas solo se amortizan con varias decenas de réplicas y varios inquilinos. Con dos tarjetas en un armario, esa maquinaria añade superficie de fallo sin devolver gran cosa. La factura del cambio llega igual: el modelo de objetos de Kubernetes, sus gráficas y su ciclo de versiones, además del motor que hay por debajo. La 1.0 estabiliza la API de configuración y reduce el riesgo en cada actualización, aunque no elimina el trabajo de plataforma. ## ¿Quién pone el listón de la inferencia abierta? El siguiente tramo ya está en el roadmap de la comunidad: enrutadores activo-activo, migración de peticiones en vuelo cuando una réplica falla y más cobertura multimodal. Ninguna de esas piezas cambiará la pregunta que la 1.0 deja instalada, que ya no es si el código abierto puede servir un modelo grande, sino a qué precio por token lo hace frente a una API cerrada. Ese es el terreno donde llm-d se juega algo más que adopción. Si los dólares por millón de tokens se vuelven comparables y auditables, la discusión sobre autohospedar deja de ser una cuestión de soberanía o de gusto y pasa a ser aritmética. La aritmética que publica el proveedor siempre pide una revisión ajena.