El próximo recorte en el coste de inferencia de IA puede venir de debajo del modelo. llm-d 1.0 muestra dónde

Un agente que trabaja en un cambio de código puede llamar al modelo cuarenta veces en una tarea. Cada llamada lleva casi el mismo contexto que la anterior: los mismos archivos del repositorio, las mismas instrucciones, las mismas definiciones de herramientas y unas pocas líneas nuevas. Si la capa de serving envía la llamada 23 a una GPU distinta de la llamada 22, el trabajo de leer ese contexto se hace otra vez desde cero. Multiplíquelo por miles de agentes y la partida más grande de la factura de inferencia no es el modelo. Es el recálculo.

Ese es el argumento económico que hay detrás de llm-d 1.0, publicado el 20 de octubre. llm-d es un proyecto de inferencia distribuida de código abierto fundado en 2025 por Red Hat, IBM, Google Cloud, CoreWeave y NVIDIA, ahora gobernado por la Cloud Native Computing Foundation, con más de 500 contribuidores de más de 25 organizaciones. Se ejecuta sobre Kubernetes, por encima de motores de inferencia como vLLM y SGLang.

Qué añade la 1.0

Las versiones anteriores ya ofrecían enrutamiento consciente de la caché de prefijos y de la carga, descarga de la caché KV, separación de las fases de prefill y decode en réplicas distintas, y soporte para hardware mixto. La versión 1.0 añade lo que necesita una flota de producción compartida:

• Calidad de servicio multitenant. Control de flujo con prioridad y equidad, para que las solicitudes sensibles a la latencia y el tráfico de agentes a ráfagas compartan una misma flota. Ingenieros de Mistral describen el uso de bandas de prioridad para proteger el tráfico de pago bajo carga.
• Operaciones sin tiempo de inactividad. Un router de alta disponibilidad con standby en caliente, actualizaciones progresivas y réplicas de prefill y decode gestionadas y actualizadas como una sola unidad.
• Serving consciente de agentes. Enrutamiento consciente de la sesión, planificación que prioriza los turnos dentro de una conversación y soporte nativo del estado de la API Responses, para que se recalcule menos entre los turnos de un agente.
• Una base estable: una API de configuración v1 y una ruta de solicitud reforzada, validada en distintas nubes y aceleradores.

1. La solicitud llega con tenant y prioridad
2. Control de flujo: qué banda y qué proporción
3. Enrutamiento consciente de la sesión hacia la réplica que tiene el contexto
4. Prefill: solo tokens nuevos si hay acierto en la caché
5. Decodificación y streaming de la respuesta

• Se decide antes de que el modelo haga ningún trabajo: Control de flujo: qué banda y qué proporción · Enrutamiento consciente de la sesión hacia la réplica que tiene el contexto · Prefill: solo tokens nuevos si hay acierto en la caché

Solicitud del agenteDecisiones de serving que toma llm-d

Cómo leer las afirmaciones de coste

IBM cita un coste entre 5 y 10 veces menor para cargas agénticas con mucho contexto. El ejemplo mejor documentado es una demostración con GLM 5.2, un modelo de pesos abiertos de unos 753 mil millones de parámetros, en GPUs NVIDIA ampliamente desplegadas: más de 6,6 millones de tokens de salida por minuto en pico, hasta 3.000 agentes de programación concurrentes sin preempciones y, con las tarifas actuales de alquiler en la nube, aproximadamente entre 5 y 10 veces menos por token que los precios de API comerciales equivalentes, con los mayores ahorros en tráfico con mucho peso de entrada. Un estudio de IBM Research informa de una tasa de acierto de la caché de prefijos de aproximadamente el 98% y un coste combinado de unos 0,11 dólares por millón de tokens.

Estos son resultados específicos de una carga de trabajo. Una tasa de acierto de caché del 98% es una propiedad de una carga en la que la mayor parte de cada solicitud se repite, algo que los bucles de agentes suelen cumplir y muchas otras cargas no. La comparación es contra precios de lista de API, y deja fuera a los ingenieros que operan la flota. La cita de JetBrains de que ejecuta llm-d en producción detrás de su plan Junie Lite es la evidencia más útil del lanzamiento, porque es una afirmación de producción y no un benchmark.

Qué cambia para una empresa

La palanca de coste baja en la pila. Para los equipos que autoalojan modelos de pesos abiertos, como muchos empezaron a considerar cuando Reflection liberó los pesos de Beam, la arquitectura de serving ahora determina el coste tanto como la elección del modelo. Las preguntas que hay que plantear a un equipo de plataforma son nuevas: ¿cuál es nuestra tasa de acierto de la caché de prefijos por carga de trabajo, y las sesiones de agentes se mantienen en las réplicas que guardan su contexto?

La prioridad se convierte en política. La QoS multitenant significa que alguien decide qué solicitudes esperan cuando la flota está llena. Es una decisión de negocio, cercana a las decisiones de presupuesto que los agentes ya exigen, y debería tener un responsable en lugar de un valor por defecto.

Las actualizaciones se vuelven rutina en lugar de incidentes. Las actualizaciones coordinadas de las réplicas de prefill y decode abordan un riesgo operativo real: una flota con la mitad en una versión del motor y la otra mitad en otra.

Sigue siendo infraestructura que usted ejecuta. llm-d es código abierto, no un servicio gestionado disponible en todas partes. Google Cloud dice que está integrando llm-d 1.0 en GKE, y los clientes de CoreWeave pueden ejecutarlo en su servicio de Kubernetes, pero un despliegue autogestionado necesita habilidades de Kubernetes y de serving de inferencia que la mayoría de las empresas no tiene en profundidad. Como con ejecutar pesos abiertos por su cuenta, el ahorro es real solo para organizaciones que pueden asumir la carga operativa. Un serving más rápido tampoco dice nada sobre si las respuestas son correctas; esa medición sigue donde estaba.