llm-d 1.0 debuta en la conferencia PyTorch con una pila de inferencia para producción

Los colaboradores del proyecto llm-d anunciaron llm-d 1.0, una pila de servicio de inferencia distribuida nativa de Kubernetes, el 20 de octubre de 2026, durante PyTorch Conference North America, según un anuncio de IBM Research. IBM afirmó que esta versión lleva llm-d más allá de la demostración de técnicas de rendimiento individuales y pretende ayudar a las organizaciones a gestionar internamente la implementación de modelos a medida que aumentan los costos de inferencia.

llm-d está diseñado para implementar pilas de inferencia para cualquier modelo, en cualquier acelerador y en cualquier nube. Red Hat, IBM y Google son los principales responsables del mantenimiento del proyecto y cofundaron llm-d junto con CoreWeave y NVIDIA; AMD, Cisco, Hugging Face, Intel, Lambda y Mistral AI se han incorporado como colaboradores. La Cloud Native Computing Foundation (CNCF) aloja llm-d como proyecto de tipo sandbox. IBM describe el resultado como una alternativa independiente de los proveedores para las organizaciones que buscan lo que denomina un rendimiento de inferencia de vanguardia, sin depender por completo de un único proveedor de modelos propietarios, nube o plataforma de hardware.

Carlos Costa, ingeniero distinguido de IBM Research y cofundador y responsable del mantenimiento de llm-d, afirmó que la versión 1.0 aporta la madurez necesaria para operar llm-d como cualquier otro servicio crítico. Señaló como ejemplos una API estable, la posibilidad de que varios clientes con prioridades contrapuestas compartan la misma infraestructura y las actualizaciones que no interrumpen las operaciones.

Qué añade la versión 1.0

Las notas de la versión v1.0.0 del proyecto, publicadas en GitHub el 20 de octubre de 2026 con etiquetas firmadas y verificadas, destacan la calidad de servicio multiusuario: control de flujo que tiene en cuenta las prioridades y la equidad, con descarte controlado de carga —incluido un mecanismo probabilístico de admisión—, equidad que tiene en cuenta los programas y puntuación de prioridad por turno. Así, las solicitudes sensibles a la latencia y las cargas de trabajo de agentes con picos de actividad pueden compartir una flota sin privarse mutuamente de recursos cuando hay sobrecarga. La configuración del control de flujo se centraliza en un único campo flowControl.

Para operar sin tiempo de inactividad, el enrutador incorpora alta disponibilidad con un nodo en espera activo y actualizaciones progresivas seguras, y un controlador DisaggregatedSet gestiona las réplicas de prefill y decode como una sola unidad lógica, con despliegues coordinados, actualizaciones sincronizadas, disponibilidad condicionada a una instantánea del Pod y enrutamiento nativo por revisión. La API de configuración del enrutador pasa a v1, la Responses API admite previous_response_id y se refuerza la ruta de solicitud del selector de endpoints para mejorar la fiabilidad, el rendimiento y la escalabilidad. Se incluye una guía de aceleradores que tiene en cuenta la topología para DRA y DRANET.

El servicio adaptado a agentes incorpora un complemento productor del estado de sesión y una afinidad de sesión dinámica para mantener las conversaciones de varios turnos cerca del contexto almacenado en caché, junto con una planificación que prioriza los turnos y el estado de Responses API para ayudar a los agentes a reutilizar el contexto entre turnos. La versión unifica los componentes del proyecto en v1.0.0, añade elementos al ecosistema —entre ellos, una integración con ai-dynamo/modelexpress para cargar pesos de modelos entre pares, el paquete llm-d-api-extensions y las herramientas de diagnóstico llm-d-pd-utils— y deja obsoletas las compilaciones de imágenes de contenedor llm-d-rocm del propio proyecto. Las imágenes de servidores de modelos incluyen compilaciones de vLLM y SGLang para distintos aceleradores, y la guía de desagregación de prefill y decode ahora requiere LeaderWorkerSet v0.11.1 o posterior con la API DisaggregatedSet habilitada.

Técnicas principales y control de flujo

Desde su lanzamiento, el proyecto se ha centrado en cinco métodos para mejorar la inferencia: enrutamiento consciente de la caché de prefijos, que dirige una solicitud a una infraestructura que quizá ya contenga el contexto compartido; descarga de la caché KV, que traslada la información almacenada en caché entre recursos de GPU, CPU y almacenamiento; optimización de la inferencia por lotes; desagregación de prefill y decode, que separa la lectura de una instrucción de la generación de una respuesta; y paralelismo amplio de expertos, que distribuye grandes modelos de mezcla de expertos entre numerosos aceleradores. Estas técnicas son anteriores a la versión 1.0; según IBM, la novedad es la integración y la madurez operativa que las acompañan: la disciplina de las operaciones del día 2, que consiste en mantener el rendimiento cuando cambia el tráfico, falla el hardware, se actualiza el software o distintos usuarios compiten por los mismos recursos.

En la versión 1.0, el control de flujo, la equidad y la priorización están diseñados para evitar que las cargas de trabajo con picos de actividad saturen los servicios sensibles a la latencia, tanto si comparten el mismo hardware como si utilizan una combinación de aceleradores. Además, las solicitudes pueden mantenerse asignadas a la infraestructura adecuada durante varios turnos para conservar activas las cachés de prefijos. llm-d funciona con motores de inferencia como vLLM o SGLang y añade capacidades de enrutamiento distribuido y operación. Stephen Watt, vicepresidente de la oficina del director de tecnología de Red Hat, afirmó que llm-d unifica los ecosistemas de PyTorch y CNCF al incorporar la orquestación nativa de Kubernetes directamente a vLLM y a los motores de inferencia modernos.

Resultados demostrados y costos indicados

En una publicación sobre el benchmark publicada el 22 de julio de 2026, el proyecto midió el servicio de cargas de trabajo agénticas de GLM-5.2, descrito allí como un modelo de mezcla de expertos con 744.000 millones de parámetros, 39.000 millones de parámetros activos y 78 capas. El análisis de la carga de trabajo se basó en 219 sesiones de producción de Claude Code, en las que la solicitud mediana del agente principal contenía 195.000 tokens de entrada y devolvía 317 tokens de salida, y en el 96 % de los turnos del agente principal se reutilizaba al menos el 90 % de la entrada. La publicación informa que el enrutamiento consciente de los prefijos capturó entre el 96 % y el 97 % de la reutilización de caché disponible en la carga de trabajo. Con una tarifa de alquiler supuesta para H200 de 2,71 USD por hora de GPU, calcula que el servicio autoalojado en dos configuraciones de 64 GPU cuesta entre 0,05 y 0,08 USD por millón de tokens de entrada y entre 1,92 y 3,55 USD por millón de tokens de salida; los autores señalan que estas cifras solo incluyen el alquiler de las GPU y suponen una carga sostenida.

En una demostración aparte, IBM y Red Hat desplegaron GLM-5.2 en 544 GPU NVIDIA H100. Según la publicación de IBM Research, se trata de un modelo de pesos abiertos con aproximadamente 753.000 millones de parámetros, de los cuales unos 39.000 millones están activos. IBM informa que, en el momento de mayor actividad, el despliegue procesó más de 6,6 millones de tokens de salida por minuto mientras atendía hasta 3.000 agentes de programación simultáneos sin preempciones, y que con 2.500 agentes se mantuvieron 7.612 solicitudes por minuto. IBM afirma que, con las tarifas actuales de alquiler en la nube, el autoalojamiento de GLM-5.2 en GPU H100 con llm-d cuesta entre 5 y 10 veces menos por token que los precios de API comerciales equivalentes. «Atender a miles de agentes simultáneos sin preempciones ofrece a los operadores una vía creíble para pasar de los resultados de un benchmark a un despliegue en producción», afirmó Maroon Ayoub, ingeniero sénior principal de aprendizaje automático del equipo de ingeniería de inferencia de Red Hat.

Según la misma publicación, el plano de datos desagregado completó 6,2 millones de transferencias de caché KV, con un promedio de 2,71 GiB por transferencia y sin fallos de transferencia; además, todos los benchmarks finalizaron sin errores de servicio.