Implementa inferencia LLM confiable: una arquitectura de producción para batching, reutilización de KV-Cache, autoscaling, enrutamiento y observabilidad de SLO

El compromiso en el serving de LLM es entre latencia y costo: cada solicitud es una cola de tokens, y la factura es solicitudes por tokens por precio por token en dólares. Si aumentas el tamaño del batch, puedes reducir el costo por token, pero puedes aumentar la latencia de cola; si agregas GPUs, puedes reducir la latencia, pero puedes aumentar el costo de inactividad. La arquitectura debe hacer visible esa aritmética antes de hacer que el modelo parezca inteligente.

La capacidad no es un control. Un modelo puede responder bien y aun así incumplir un SLO visible para el usuario porque la ruta de serving oculta esperas en cola, fallos de caché, errores de enrutamiento y brechas de capacidad. La inferencia de producción es un problema de control de ingeniería: necesitas batching, reutilización de caché, autoscaling, enrutamiento, limitación de tasa y observabilidad para convertir la salida del modelo en un servicio con un techo de costo.

Costos

Comienza con el modelo de costos, no con la ficha del modelo. Para cada solicitud, estima tokens de prompt, tokens de finalización, tasa de acierto de caché, ocupación del batch y tiempo de inactividad de GPU. La unidad que te importa es dólares por solicitud aceptada, no dólares por hora de GPU de forma aislada. Si una solicitud puede atenderse desde un modelo más pequeño, un prefijo en caché o una cola por lotes, el costo debe bajar antes de que el usuario lo note.

Las afirmaciones de los proveedores pueden ayudar a acotar la oportunidad. Nutanix Enterprise AI 2.8 añade un Agent Gateway basado en MCP y una Private Inference mejorada con paralelismo de tensor multi-GPU, decodificación especulativa y fine-tuning LoRA para modelos de menos de 8B parámetros. La cifra de aceleración de inferencia reportada es de hasta 2.5x. Trátalo como un techo, no como una promesa: la mezcla de cargas de trabajo, la longitud de contexto y la concurrencia decidirán si la aceleración se refleja en la cola o solo en la mediana.

Usa el número para definir una prueba: si el mismo conjunto de solicitudes pasa de una configuración de serving a otra, mide tokens por segundo, espera en cola y dólares por solicitud. Si la aceleración no reduce el costo por solicitud aceptada, es una característica de latencia, no un control de costo.

Modelos

El enrutamiento de modelos es la forma más barata de mantener alta la calidad y acotado el costo. Enruta por tarea, no por costumbre: las tareas de clasificación corta, extracción y resumen a menudo pueden usar modelos más pequeños; las tareas de contexto largo, intensivas en herramientas o de alto riesgo pueden usar modelos más grandes. La decisión de enrutamiento debe ser explícita, registrada y reversible.

El fine-tuning de bajo rango es útil cuando una tarea estrecha necesita un comportamiento estable sin pagar por un modelo base más grande. Nutanix afirma que NAI 2.8 está disponible de forma general para inferencia LLM de baja latencia multi-GPU y fine-tuning LoRA en modelos de menos de 8B parámetros. Ese es un patrón útil para inferencia privada: mantener un modelo pequeño ajustado en la ruta crítica y un modelo más grande para escalar.

No enroutes por intuición. Define una taxonomía de tareas, establece un umbral de calidad para cada clase y registra el modelo elegido. Si un modelo más pequeño supera el umbral, úsalo. Si falla, escala. El objetivo no es ocultar el modelo detrás de una fachada; es convertir la elección del modelo en un control medible.

Serving

El stack de serving es donde nacen o se rompen los SLOs. Una arquitectura confiable de API de LLM necesita seis controles: batching de solicitudes, reutilización de KV-cache, autoscaling de GPU, enrutamiento de modelos, limitación de tasa y observabilidad. Cada uno cambia la aritmética.

1. Batching de solicitudes. El batching continuo permite que nuevas solicitudes se unan a un batch activo sin esperar a que todo el batch termine. Mejora la utilización de GPU, pero puede aumentar la latencia de cola. Establece una edad máxima del batch y una longitud máxima de cola, y mide ambas.
2. Reutilización de KV-cache. Reutilizar prefijos en caché evita recalcular el estado de atención para prompts de sistema repetidos, esquemas de herramientas o fragmentos de documentos. Sigue la tasa de acierto de caché y la tasa de expulsión de caché. Si la tasa de acierto es baja, tus prompts no están diseñados para reutilización.
3. Autoscaling de GPU. Escala según profundidad de cola, rendimiento de tokens y latencia de cola, no solo según utilización de GPU. Una GPU puede parecer ocupada mientras los usuarios esperan. Añade reglas de escala hacia arriba para picos y reglas de escala hacia abajo para el costo de inactividad.
4. Enrutamiento de modelos. Coloca el enrutamiento delante del modelo, no dentro del prompt. Registra la ruta, el modelo, el recuento de tokens y el resultado. Una ruta que no puede auditarse es un centro de costos oculto.
5. Limitación de tasa. Limita por usuario, inquilino, función y clase de modelo. La limitación de tasa no es solo control de abuso; es protección de capacidad. Si un inquilino puede agotar la cola de batch, el SLO no es real.
6. Observabilidad. Expón latencia de solicitud, espera en cola, tamaño del batch, tasa de acierto de caché, rendimiento de tokens, tasa de error y costo por solicitud. Los SLOs necesitan un presupuesto, una tasa de consumo y una alerta que se dispare antes de que los usuarios lo noten.

Las decisiones de infraestructura importan, pero no son el producto. Se espera que Nutanix Kubernetes Platform 2.19 añada Kubernetes bare-metal, NKP Full Stack on AHV, un catálogo de aplicaciones de IA, soporte expandido de GPU y conformidad Kubernetes AI certificada por CNCF. Nutanix Unified Storage alcanzó la validación de NVIDIA-Certified Storage, descrita como una ruta de datos de baja latencia y alto rendimiento hacia GPUs para cargas de trabajo de IA de producción a gran escala. Estas son útiles cuando tu cuello de botella es el movimiento de datos o la colocación de GPU, pero no reemplazan los controles de serving anteriores.

Las cargas de trabajo agénticas hacen que el plano de control sea más importante, no menos. NAI 2.8 proporciona control centralizado para inferencia de IA y IA agéntica a través de una gateway de Model Context Protocol disponible de forma general. Si los agentes pueden llamar herramientas, recuperar datos y emitir solicitudes de modelo, la gateway es donde pertenecen la política, la identidad y la auditoría. Sin ella, cada agente es una nueva fuente de carga sin límites.

El final es simple: la capacidad del modelo es la entrada, no el servicio. Implementa primero los controles. Agrupa las solicitudes, reutiliza la caché, enruta el modelo, limita la carga, escala las GPUs y observa el costo. Cuando la aritmética es visible, el producto es confiable; cuando no lo es, la demostración es solo una demostración.