Arquitectura de un Clúster LLM en Producción: Kubernetes, GPUs e Inferencia IA a Escala en 2026

Desplegar un modelo de lenguaje no consiste únicamente en levantar un contenedor con pesos preentrenados y exponer un puerto HTTP. Cuando el objetivo es dar servicio a miles de usuarios concurrentes con requisitos estrictos de latencia, la ingeniería detrás de la plataforma se convierte en el factor crítico de éxito.

Hemos visto evolucionar la IA Generativa desde prototipos en notebooks hasta sistemas distribuidos que mueven terabytes de datos por segundo a través de buses de memoria GPU. La diferencia entre un entorno de laboratorio y uno de producción radica en cómo gestionamos la contención de recursos, la degradación del rendimiento bajo carga y la resiliencia ante fallos.

Qué implica ejecutar un LLM en producción

Un ingeniero de software puede conseguir que un modelo de 8 mil millones de parámetros responda en 50 milisegundos en su máquina local. Sin embargo, cuando ese mismo modelo recibe 500 peticiones simultáneas, la memoria VRAM se satura, los tokens por segundo se desploman y las colas de inferencia colapsan.

El paso a producción exige asumir que los recursos de cómputo, específicamente las GPUs, son finitos, caros y volátiles. Una arquitectura LLM para entornos reales debe abordar la gestión de la memoria KV (Key-Value Cache), el enrutamiento inteligente de tráfico, la alta disponibilidad y la observabilidad extrema. No tratamos con microservicios stateless tradicionales; la inferencia LLM es un proceso con estado interno intensivo, donde el contexto de la conversación y la memoria ocupan un espacio físico en la VRAM de la GPU durante toda la generación.

Componentes de una arquitectura moderna para inferencia

Para construir un Clúster LLM robusto, debemos segmentar la plataforma en planos de responsabilidad bien definidos. Aislar el plano de datos del plano de control nos permite escalar y actualizar componentes sin afectar a los usuarios activos.

El flujo de una petición atraviesa varias capas. Comienza en un API Gateway, que se encarga de la autenticación, autorización y limitación de tasa (rate limiting). Desde ahí, el tráfico pasa a un balanceador de carga capaz de entender el estado de las réplicas de inferencia. Si el sistema está saturado, la petición se redirige a un broker de colas asíncrono. Finalmente, un worker toma la petición, carga el contexto desde una caché semántica y ejecuta la inferencia en la GPU, devolviendo el flujo de tokens al cliente mediante Server-Sent Events (SSE) o WebSockets.

Kubernetes como plano de control

Kubernetes se ha consolidado como el estándar de facto para la orquestación de contenedores, y en el ámbito de MLOps no es diferente. Sin embargo, orquestar cargas de IA Generativa obliga a extender sus capacidades nativas.

El desafío principal en Kubernetes es la programación de GPUs. Históricamente, el soporte para dispositivos aceleradores requería la instalación de device plugins propietarios. En 2026, el ecosistema ha madurado hacia el uso del NVIDIA GPU Operator (o sus equivalentes de AMD e Intel), que automatiza la instalación de drivers, el plugin de dispositivo y el DCGM (Data Center GPU Manager) para la exportación de métricas.

Programar un Pod en un nodo con GPUs no es trivial. Kubernetes no entiende de forma nativa la fragmentación de VRAM. Si tenemos una GPU de 80GB y desplegamos un modelo que consume 20GB, el planificador por defecto bloqueará el nodo, asumiendo que el recurso completo está ocupado. Para solventar esto, recurrimos a tecnologías como el Multi-Instance GPU (MIG) en hardware moderno, o a proyectos open source como GPU Sharing mediante tiempo compartido (time-slicing) y la integración con runtimes extendidos.

La decisión entre aislar físicamente la GPU (MIG) o compartir su tiempo de ejecución depende del modelo de negocio. MIG garantiza aislamiento de fallos y ancho de banda de memoria, ideal para modelos multi-tenant críticos. El time-slicing es más eficiente en costes para cargas de trabajo que toleran picos de latencia, ya que permite apilar varios modelos en una sola GPU físicamente indivisible.

El papel de Docker en el ciclo de vida del modelo

Docker sigue siendo la herramienta fundamental para el empaquetado, pero el diseño de las imágenes cambia drásticamente cuando trabajamos con modelos de lenguaje.

Una práctica habitual y errónea consiste en empaquetar los pesos del modelo dentro de la imagen Docker. Esto genera imágenes de 15 a 50 gigabytes, lo que hace que el arranque en frío de los pods sea inaceptablemente lento y satura el ancho de banda del registro de contenedores durante los despliegues.

La arquitectura recomendada separa el motor de ejecución de los pesos del modelo. La imagen Docker debe contener únicamente el binario de inferencia, las librerías de CUDA y las dependencias de Python o C++. Al arrancar el contenedor, un init-container o un sidecar se encarga de descargar los pesos desde un almacenamiento de objetos (como S3 o MinIO) a un volumen local vacío.

Esta separación acelera los despliegues de MLOps. Si actualizamos el motor de inferencia para aplicar un parche de seguridad, la imagen pesa pocos megabytes. Si lanzamos una nueva versión del modelo, no necesitamos reconstruir imágenes, simplemente actualizamos el tag en la configuración del volumen.

Motores de inferencia para cargas de producción

El motor de inferencia es el corazón de la plataforma. La elección de esta pieza dictará el rendimiento, la compatibilidad con arquitecturas de hardware y la facilidad de operación. No existe una solución universal; cada motor optimiza para un escenario distinto.

Motor	Puntos Fuertes	Casos de Uso Recomendados	Limitaciones
vLLM	PagedAttention, gran throughput, amplio soporte de modelos	API de propósito general, altos picos de tráfico	Consumo de VRAM elevado en configuraciones iniciales
SGLang	RadixAttention, caché de prefijos extrema, óptimo para RAG	Agentes complejos, prompts con system prompts largos	Ecosistema en crecimiento, menos arquitecturas soportadas
TensorRT-LLM	Rendimiento puro, compilación de grafos, FP8 nativo	Entornos NVIDIA cerrados, latencia ultrabaja	Curva de aprendizaje alta, tiempo de compilación
llama.cpp / Ollama	Versatilidad, soporte CPU y GPU, bajo consumo	Edge computing, prototipos, despliegues on-premise pobres en GPU	Throughput limitado, no diseñado para alta concurrencia

vLLM se ha posicionado como el estándar de la industria para servidores OpenAI compatibles. Su magia reside en PagedAttention, que gestiona la memoria KV Cache como un sistema operativo gestiona la memoria virtual, eliminando la fragmentación y permitiendo procesar lotes (batches) mucho más grandes.

SGLang ha ganado tracción en arquitecturas que dependen fuertemente de prompts complejos. Utiliza RadixAttention para almacenar en caché los cálculos intermedios de los prefijos de manera altamente eficiente. Si miles de usuarios consultan un documento de RAG de 10.000 tokens, SGLang procesa ese contexto una sola vez y lo cachea en un árbol radix, respondiendo a las consultas subsiguientes en milisegundos.

TensorRT-LLM es la opción a elegir cuando la latencia es el rey y el proveedor de hardware es exclusivamente NVIDIA. Requiere compilar el modelo a un grafo optimizado, lo que penaliza la flexibilidad, pero recompensa con una velocidad de inferencia inigualable mediante fusiones de kernels y soporte nativo para precisión reducida.

Para entornos de desarrollo o despliegues en el borde, donde no hay presupuesto para GPUs de centro de datos, llama.cpp y Ollama permiten ejecutar modelos cuantizados en hardware de consumo o CPUs. Son herramientas excelentes para probar en local, pero quedan cortas para un clúster de producción que debe soportar alta concurrencia.

Optimización del rendimiento en Inferencia LLM

Servir un LLM a escala exige exprimir hasta el último ciclo de cómputo de la GPU. Las optimizaciones a nivel arquitectónico son tan importantes como la elección del motor.

El concepto de Continuous Batching revolucionó la inferencia LLM. En el batching estático, el servidor espera a tener N peticiones, las procesa en lote y devuelve todas las respuestas. Si una petición genera 500 tokens y otra genera 2, la GPU permanece inactiva esperando a que terminen ambas. El batching continuo inyecta y expulsa peticiones del lote en cada paso de generación. En cuanto un usuario recibe su respuesta, su slot se libera y una nueva petición entra en el lote. Esto multiplica el throughput por ordenes de magnitud.

La memoria KV Cache es el principal cuello de botella. Almacenar el contexto de una conversación consume VRAM rápidamente. Optimizar este espacio implica aplicar Prefix Caching. Si todas las peticiones comparten un system prompt (por ejemplo, instrucciones de formato o documentos de contexto), el motor calcula los tensores KV una vez y los reutiliza para todos los usuarios.

La cuantización (Quantization) es otra palanca crítica. Ejecutar modelos en FP16 requiere el doble de memoria que en INT8 o FP8. Hoy en día, formatos como AWQ, GPTQ o el estándar FP8 de NVIDIA permiten ejecutar modelos de 70 mil millones de parámetros en una sola GPU de 80GB sin una degradación perceptible de la calidad. Reducir el tamaño en memoria permite aumentar el batch size y, por consiguiente, el número de usuarios concurrentes por nodo.

API Gateway y Balanceador de carga para modelos de lenguaje

El tráfico de IA Generativa tiene características únicas. Las conexiones son de larga duración (streaming de tokens) y el tamaño del payload puede ser masivo. Un balanceador de carga L4 tradicional, como los basados en TCP puro, no es suficiente.

Necesitamos un API Gateway que entienda el protocolo HTTP/2 y sea capaz de manejar SSE o WebSockets sin cortar las conexiones por timeout. Herramientas como Envoy, Kong o el propio NGINX en configuraciones modernas son el estándar.

El balanceo de carga para inferencia LLM no puede basarse en un algoritmo Round Robin simple. Si enviamos la misma cantidad de tráfico a una réplica que está generando una respuesta de 2.000 tokens que a una réplica que acaba de iniciar una respuesta de 10 tokens, la primera réplica saturará su VRAM.

La estrategia correcta es el Least Connections o, mejor aún, el enrutamiento basado en la longitud de la cola interna de cada motor. Algunos motores modernos exponen métricas en tiempo real sobre el número de peticiones en espera. Un balanceador inteligente, como Envoy configurado con lógica externa de control de admisión, puede consultar estas métricas y enviar el tráfico a la réplica menos cargada.

El API Gateway también es responsable de aplicar cuotas por usuario, enmascarar datos sensibles (PII) antes de que lleguen al modelo, y traducir protocolos. Por ejemplo, las aplicaciones internas pueden hablar gRPC para minimizar la sobrecarga de red, mientras que el Gateway expone una API REST compatible con OpenAI hacia el exterior.

Gestión de colas y control de backpressure

El fenómeno del backpressure es inevitable en un Clúster LLM. Cuando el tráfico entrante supera la capacidad de generación de tokens de las GPUs, el sistema debe decidir si degrada la latencia de todos los usuarios o si rechaza peticiones nuevas.

Una arquitectura profesional implementa sistemas de colas desacoplados. En lugar de que el cliente espere una conexión HTTP abierta durante minutos, el API Gateway acepta la petición, la deposita en un broker de mensajes y devuelve un identificador de trabajo asíncrono.

Tecnología	Modelo de Mensajería	Idoneidad para Inferencia LLM
Redis Streams	En memoria, baja latencia	Ideal para colas de corta duración y caché de respuestas
NATS	Pub/Sub ligero, súper rápido	Excelente para enrutamiento dinámico de réplicas
Kafka	Log distribuido, persistente	Útil si se necesita auditoría o reproducibilidad de peticiones
RabbitMQ	Colas clásicas, enrutamiento complejo	Funcional, pero excesivamente pesado para tráfico de streaming puro

Redis Streams o NATS suelen ser las opciones preferidas. Ofrecen la latencia de un dígito de milisegundo y manejan la presión de retroalimentación de forma nativa. Los workers de inferencia consumen de estas colas a su propio ritmo. Si la cola crece más allá de un umbral configurado, el API Gateway puede empezar a devolver errores HTTP 429 (Too Many Requests) o redirigir a los usuarios a un modelo más pequeño y rápido, aplicando una degradación graceful.

Para flujos de trabajo puramente síncronos donde el usuario exige ver los tokens generarse en tiempo real, la cola se gestiona dentro del propio balanceador o motor de inferencia, pero es imperativo configurar límites estrictos de max queue size. Superado ese límite, se debe cortar la conexión por el bien de la estabilidad del clúster.

Escalabilidad horizontal de un clúster LLM

Escalar microservicios tradicionales en Kubernetes se basa en la métrica de uso de CPU. Si la CPU sube del 70%, el Horizontal Pod Autoscaler (HPA) lanza una nueva réplica. En el mundo de la IA, la CPU casi nunca es el cuello de botella; la VRAM y los ciclos de cómputo de la GPU lo son.

Para escalar un Clúster LLM necesitamos métricas custom. El HPA de Kubernetes debe configurarse para leer métricas externas desde Prometheus, como el número de peticiones activas por GPU, el tiempo de espera en cola o la utilización de la memoria KV Cache.

El problema más complejo de la escalabilidad horizontal en inferencia es el cold start. Descargar los pesos de un modelo de 70B a un nodo nuevo, cargarlos en VRAM e inicializar el motor de inferencia puede tardar varios minutos. Si dependemos de la escalabilidad reactiva, cuando la nueva réplica esté lista, el pico de tráfico ya habrá pasado, dejándonos con infraestructura ociosa cara.

La solución arquitectónica pasa por dos estrategias combinadas:

1. Sobreaprovisionamiento controlado (Overprovisioning): Mantener réplicas inactivas pre-calentadas usando Kubernetes PriorityClasses. Se despliegan pods de baja prioridad que ocupan espacio en los nodos GPU. Cuando llega un pico de tráfico, los pods de inferencia de alta prioridad expulsan a los pods basura, tomando su sitio inmediatamente sin esperar a la provisión de nuevas máquinas.
2. Escalabilidad predictiva: Analizar los patrones de uso histórico para escalar el clúster antes de que se produzcan los picos predecibles (por ejemplo, a las 9:00 AM cuando los usuarios inician su jornada laboral).

Para la escalabilidad a nivel de nodos físicos, el Cluster Autoscaler de Kubernetes debe configurarse con grupos de nodos específicos para GPU, utilizando instancias spot o reservadas dependiendo del balance coste-disponibilidad de la plataforma.

Cachés de prompts y embeddings

La caché es el arma secreta para reducir costes y mejorar la latencia. La implementación de una arquitectura LLM completa requiere múltiples capas de caché.

La primera capa es la caché de prefijos a nivel de motor, descrita anteriormente. La segunda capa es la caché semántica a nivel de API. ¿Por qué pasar por la GPU si la pregunta ya ha sido respondida?

Herramientas como Redis o bases de datos vectoriales ligeras pueden almacenar respuestas a prompts anteriores. Cuando llega una nueva petición, se calcula el embedding del prompt y se busca en la base de datos vectorial. Si existe una coincidencia con un grado de similitud alto (por ejemplo, 0.99), se devuelve la respuesta cacheada directamente, evitando el paso por la GPU. Esta técnica es extremadamente efectiva en sistemas de atención al cliente o bots internos donde se repiten muchas consultas.

Además, los modelos de embedding (necesarios para RAG y para la propia caché semántica) también deben servirse de forma eficiente. Desplegar un clúster separado de modelos de embedding, más pequeños y rápidos, optimizados para batching masivo en CPU o GPUs de bajo perfil, ahorra recursos costosos en el clúster principal de LLMs.

Observabilidad de la plataforma

No se puede optimizar lo que no se puede medir. La observabilidad en un clúster LLM trasciende el típico dashboard de CPU y RAM. Debes instrumentar la plataforma para capturar métricas específicas del dominio de inferencia.

La pila estándar de observabilidad cloud-native se compone de Prometheus para la captura de métricas, Grafana para la visualización, Loki para los logs y Tempo o Jaeger para el tracing distribuido. OpenTelemetry actúa como pegamento estandarizando la instrumentación.

Las métricas críticas a monitorizar se dividen en dos categorías:

• Métricas de rendimiento del sistema: Uso de VRAM, ocupación de los SMs (Streaming Multiprocessors), temperatura de la GPU y ancho de banda del bus PCIe.
• Métricas de negocio e inferencia: Time To First Token (TTFT), Time Per Output Token (TPOT), latencia de cola y tasa de errores OOM (Out of Memory).

El tracing distribuido es vital para entender dónde se pierde el tiempo. Un trace de OpenTelemetry para una petición de inferencia debería span desde el API Gateway, pasando por la caché semántica, el tiempo de espera en la cola, y finalmente desglosar el tiempo dentro del motor de inferencia entre la fase de prefill (cálculo del prompt) y la fase de decode (generación de tokens).

Los logs estructurados en Loki permiten correlacionar fallos. Si una GPU comienza a devolver errores de ECC memory, Loki permite cruzar ese log con las peticiones que estaban en ejecución en ese momento exacto, facilitando el diagnóstico post-mortem.

Gestión del almacenamiento y ciclo de vida del modelo

El almacenamiento en un clúster de IA Generativa debe satisfacer necesidades contrapuestas: por un lado, alojar pesos de modelos de decenas de gigabytes; por otro, soportar alta concurrencia de lectura para acelerar el arranque en frío.

El flujo de gestión del ciclo de vida de los modelos (MLOps) exige un registro centralizado. Modelos como MLflow o el Hugging Face Hub auto-alojado actúan como fuente de la verdad. Cuando un nuevo modelo es validado y promovido a producción, se publica en este registro.

Desde el punto de vista de la infraestructura de almacenamiento de Kubernetes, la mejor práctica es utilizar volúmenes persistentes basados en almacenamiento de objetos (S3) para el registro file, y discos SSD locales (Local Persistent Volumes) montados en los nodos GPU para la carga de los pesos.

Si todos los pods intentan descargar un modelo de 30GB desde S3 al mismo tiempo durante un evento de escalado, saturaremos la red del clúster. Para mitigar esto, se despliegan nodos con discos locales de gran capacidad y se utiliza un daemon o un init-container que descarga el modelo al SSD local una sola vez por nodo. Los pods de inferencia que se programen en ese nodo posteriormente montarán el volumen local vacío ya pre-poblado, reduciendo el tiempo de carga de minutos a segundos.

Seguridad de extremo a extremo

La seguridad en una arquitectura LLM abarca la infraestructura tradicional y los nuevos vectores de ataque propios de la IA Generativa.

A nivel de red, los nodos GPU deben estar aislados en subredes privadas sin acceso directo a internet. Solo el API Gateway y los servicios de enrutamiento están expuestos. El tráfico entre el Gateway y los motores de inferencia debe ir cifrado con mTLS (Mutual TLS), idealmente gestionado por un service mesh como Istio o Cilium.

El control de acceso basado en roles (RBAC) de Kubernetes debe restringir qué ingenieros pueden ejecutar pods en nodos GPU, ya que el acceso a la GPU implica la capacidad de ejecutar código arbitrario en el hardware, lo que podría ser aprovechado para extracción de datos o ataques de canal lateral.

A nivel de aplicación, el API Gateway debe implementar cortafuegos de aplicaciones web (WAF) capaces de detectar intentos de Prompt Injection o fuga de datos (PII). Si el modelo está conectado a herramientas externas (function calling), la seguridad del sandbox es crítica. Las herramientas deben ejecutarse en contenedores aislados con permisos mínimos, evitando que un prompt malicioso consiga ejecutar comandos en la infraestructura subyacente.

Costes de infraestructura y FinOps en IA

Las GPUs representan el mayor coste operativo de un clúster LLM, a menudo superior al 80% de la factura cloud. La disciplina de FinOps aplicada a MLOps busca alinear el gasto con el valor de negocio real generado.

La primera estrategia de optimización de costes es la consolidación. En lugar de tener nodos pequeños con una GPU, es más rentable financieramente (aunque más complejo operativamente) utilizar nodos multi-GPU. Esto permite compartir el almacenamiento local, la red de alta velocidad y la CPU/RAM del host entre varios aceleradores.

El uso de instancias interrumpibles (Spot Instances) para cargas de trabajo asíncronas es otra palanca fundamental. Si el clúster procesa documentos en background para RAG, los pods de inferencia pueden correr en nodos Spot. Si la nube reclama el nodo, el trabajo vuelve a la cola y se reintentará en otro nodo. Para tráfico síncrono interactivo, debemos ceñirnos a instancias bajo demanda (On-Demand) o reservadas.

La elección del modelo impacta directamente en el coste. Utilizar un modelo de 70B para resumir correos electrónicos es un despilfarro de recursos. Una buena arquitectura implementa enrutamiento basado en complejidad: un modelo pequeño de 8B en clusters de GPU baratas maneja el 90% del tráfico, y solo las consultas complejas se enrutan a un clúster de modelos de 70B alojados en hardware de gama alta.

Arquitecturas recomendadas según el volumen de usuarios

No todo el mundo necesita un despliegue multi-región de miles de GPUs. El diseño debe adaptarse al contexto operativo.

Escenario 1: Carga baja e interna (Hasta 50 usuarios concurrentes)

Para departamentos internos o prototipos avanzados, la complejidad debe minimizarse. Un único servidor con una o dos GPUs de gama de consumo (como RTX 4090) o una GPU de centro de datos de entrada (L4 o A10), ejecutando vLLM directamente sobre Docker Compose o un clúster Kubernetes de un solo nodo (k3s) es suficiente. Un NGINX invertido como proxy y un script básico de Prometheus cubren las necesidades de observabilidad. El énfasis aquí está en la simplicidad y el bajo coste.

Escenario 2: Pyme o SaaS de nicho (100 – 1.000 usuarios concurrentes)

Aquí necesitamos alta disponibilidad y control de tráfico. El clúster Kubernetes se compone de 3 a 5 nodos GPU. Desplegamos vLLM o SGLang con réplicas distribuidas para tolerancia a fallos. Un API Gateway (Kong o Envoy) gestiona la autenticación y enrutamiento. Redis se introduce para la caché semántica y colas de backpressure. El escalado horizontal es reactivo basado en métricas de VRAM y tamaño de cola. Es vital el uso de modelos cuantizados a 8 bits para maximizar el número de usuarios concurrentes por GPU.

Escenario 3: Plataforma Enterprise y Multi-Tenant (+10.000 usuarios concurrentes)

El escenario extremo requiere un despliegue distribuido a nivel mundial. Se utilizan clústeres de Kubernetes regionales con enrutamiento geográfico (GeoDNS). Los modelos se sirven mediante TensorRT-LLM para exprimir el hardware, con pods dedicados por cliente principal para garantizar aislamiento y rendimiento (QoS).

La arquitectura incluye una capa compleja de enrutamiento inteligente que decide en tiempo real qué modelo y qué región atiende la petición en función de la latencia de red del cliente y la carga global. Kafka se utiliza para la persistencia de auditoría de cada inferencia. El autoscaling es predictivo, orquestado por sistemas de Machine Learning que analizan patrones de uso horarios. Los nodos físicos aprovechan MIG para dividir las grandes GPUs (H100 o B200) en instancias lógicas, aislando a los inquilinos y optimizando la densidad de cómputo. El FinOps actúa como un componente arquitectónico más, rotando tráfico hacia regiones cloud más baratas durante horas valle.

El diseño de infraestructuras para IA Generativa es un campo en evolución constante. Las herramientas específicas cambiarán, pero los principios de gestión de memoria, aislamiento de fallos y control de tráfico permanecerán como pilares para construir sistemas capaces de sostener la próxima generación de aplicaciones inteligentes.