Artículo
llm-d: operar inferencia
IBM publicó el 20 de octubre de 2026 el anuncio de llm-d 1.0, infraestructura abierta para servir modelos de lenguaje. Es una versión de infraestructura de inferencia, no un modelo nuevo.
Según IBM, añade prioridad y equidad entre cargas, router de relevo, actualizaciones graduales, API de configuración v1 y enrutamiento por sesión.
Inferencia, cola y concurrencia
La inferencia consiste en utilizar un modelo para producir una salida a partir de una entrada. Una aplicación puede pedirle que resuma un documento o prepare una respuesta. Al operar ese servicio aparece otra pregunta: qué ocurre cuando llegan varias solicitudes y los recursos disponibles están ocupados.
Una cola reúne solicitudes pendientes. La concurrencia indica cuántas se atienden a la vez dentro de la frontera que estás midiendo. No equivale al número de usuarios registrados ni al volumen de trabajo completado durante una hora. Dos personas pueden enviar varias peticiones; una única tarea puede necesitar varios pasos.
La latencia es el tiempo que tarda una solicitud en alcanzar un resultado definido. Conviene aclarar si mides hasta la primera parte de la respuesta o hasta que termina. La espera en cola, el procesamiento y el traslado de datos contribuyen a esa experiencia. La lectura sobre velocidad y criterio al evaluar respuestas ayuda a formular esa distinción.
Una cola ficticia con dos carriles
Imaginemos un equipo que comparte un servicio entre atención interactiva y preparación de documentos. Este es un ejercicio original completamente ficticio: no reproduce una instalación, configuración ni prueba del producto anunciado. Sus carriles representan capacidad lógica inventada, no GPU ni concurrencia recomendada.
Al comenzar hay seis solicitudes: dos interactivas, I1 e I2, y cuatro de documentos, D1 a D4. Para simplificar, todas duran exactamente un turno y existen dos carriles. El equipo propone reservar uno para las interactivas mientras haya alguna pendiente; el otro sigue atendiendo documentos. Después libera ambos para el trabajo restante.
| Turno | Carril A | Carril B | Criterio propuesto |
|---|---|---|---|
| Primero | I1 | D1 | Atender ambas clases. |
| Segundo | I2 | D2 | Mantener espacio para documentos. |
| Tercero | D3 | D4 | Usar ambos carriles al vaciarse la clase interactiva. |
La tabla define una política del ejercicio. No describe el algoritmo del software ni promete que solicitudes reales tengan duraciones iguales.
Prioridad y equidad cambian quién espera
Comparemos esa política con una cola que coloca primero D1, D2, D3 y D4, y después I1 e I2. En ese orden, ambos carriles atenderían documentos durante los dos primeros turnos. Las interactivas comenzarían en el tercero: cada una habría esperado dos turnos.
Con la política propuesta, I1 comienza inmediatamente e I2 espera un turno. Su espera media baja de dos turnos a medio turno. El intercambio importa: D3 y D4 esperan dos turnos, mientras que en el orden anterior habrían esperado uno. La prioridad redistribuye la espera; no crea capacidad adicional.
El promedio de espera de las seis solicitudes es un turno en ambos escenarios. Mirar solamente ese agregado ocultaría el cambio entre clases. Para discutir equidad, pregunta si un flujo conserva oportunidades de avanzar cuando el otro recibe trabajo continuo. Una prioridad sin límite podría dejar pendientes otras tareas indefinidamente.
En una evaluación propia, explica qué necesidad justifica la prioridad y qué espera resulta aceptable para las demás. No hace falta atribuir mal funcionamiento al sistema para reconocer que dos equipos tienen objetivos distintos.
Continuidad durante un mantenimiento
Continuemos con la misma cola. Si retiras el carril B durante el tercer turno, D3 puede ocupar A y D4 deberá esperar otro turno. El servicio aún dispone de un carril, pero la experiencia cambió. Mantener una vía de atención y mantener idéntica espera son objetivos diferentes. La disponibilidad pregunta si puedes atender; la latencia, cuánto tarda esa atención.
Ejercicio: dibuja ese cuarto turno y anota qué solicitud se retrasa, quién debe enterarse y qué condición permite devolver el carril B. Como propuesta operativa, puedes dejar terminar el trabajo ya iniciado, suspender nuevas asignaciones al recurso que vas a intervenir y verificarlo antes de reincorporarlo. No es un procedimiento validado para este producto.
Un router o encaminador decide a qué recurso enviar una solicitud. Contar con un relevo exige revisar qué tráfico recibe y cómo se comprueba la recuperación. La posibilidad de actualizar por etapas merece una prueba propia con límites de espera y recuperación acordados; una etiqueta de disponibilidad no sustituye esa observación.
También hay continuidad de contexto. Una caché conserva información reutilizable; no garantiza que cualquier solicitud resulte más rápida. En nuestro caso, dos documentos podrían compartir una preparación repetida. Antes de contar un beneficio, habría que comprobar qué se reutiliza, para quién es válido y si la respuesta final sigue cumpliendo el criterio esperado.
Qué medir antes de ampliar
Un registro útil puede separar tiempo de llegada, comienzo, primera salida y finalización. Añade clase de trabajo, resultado aceptado o rechazado y motivo de una interrupción. Así distingues espera, duración del procesamiento y tareas que consumieron recursos sin producir una salida utilizable. Distingue un rechazo por plazo vencido de una salida revisada y considerada incorrecta.
Conserva la mezcla de solicitudes al comparar dos políticas. Si una prueba contiene documentos cortos y otra conversaciones extensas, una diferencia no identifica por sí sola qué aportó el cambio de organización. Repite el mismo ejercicio con una llegada tardía o una tarea más larga y observa qué deja de cumplirse.
Para el coste, define primero qué contarás como tarea aceptada y qué gastos incluirás. El importe por unidad generada y el coste por trabajo útil responden preguntas diferentes. Si consumes recursos como servicio, puedes conectar esa revisión con Claude en Bedrock y datos, manteniendo separados el acceso al proveedor y la operación de tu aplicación.
Preguntas frecuentes
¿Necesito conocer toda la arquitectura para evaluar una cola?
Puedes comenzar definiendo clases de trabajo y tiempos observables. Para trasladar el ejercicio a una implementación sí necesitarás conocer sus restricciones. El dibujo permite formular preguntas; no reemplaza esa revisión técnica.
¿Qué significa que una API de configuración tenga versión?
Ofrece una referencia para expresar ajustes e integraciones. Antes de cambiarla, contrasta los parámetros que utilizas y sus efectos esperados. Una etiqueta de versión por sí sola no demuestra compatibilidad con tu entorno.
¿Cómo distingo una mejora de un cambio de prioridad?
Mira los resultados de cada clase, además del promedio. En nuestro ejemplo las interactivas avanzan antes sin reducir la espera media total. Reconocer ese intercambio evita presentar una redistribución como capacidad nueva.
¿Qué justificaría ampliar la prueba?
Que las solicitudes relevantes cumplan criterios acordados, las demás sigan avanzando y la recuperación sea observable. Si desconoces qué ocurrió con trabajos interrumpidos, resuelve esa incertidumbre antes de aumentar la carga.
Fuente: IBM.
Para practicar estos criterios con ejemplos y decisiones de implementación, visita la Comunidad IA.
