Desplegar agentes de IA en Kubernetes: arquitectura, escalado y cuándo compensa K8s

Desplegar agentes de IA en Kubernetes significa ejecutar los componentes de un sistema de agentes (servicio del agente, servidores de herramientas o MCP, base de datos vectorial, motor de inferencia y cola de mensajes) como cargas de trabajo en contenedores sobre un clúster de K8s. Kubernetes aporta escalado, planificación de GPU, gestión del estado, gestión de secretos y observabilidad para operar agentes en producción de forma soberana en la UE. Es potente, pero no un fin en sí mismo. Este artículo muestra la arquitectura, la mecánica de escalado y, sobre todo, cuándo compensa realmente el esfuerzo.

• Arquitectura: divide el sistema de agentes en servicios desacoplados (orquestador, servidores de herramientas/MCP, motor de inferencia, base de datos vectorial, cola) y ejecuta cada uno como una carga de trabajo propia.
• Escalado: los pods de agente sin estado escalan de forma elástica con el Horizontal Pod Autoscaler; los pods de inferencia en GPU se asignan a nodos GPU dedicados y, por motivos de coste, se mantienen en caliente.
• Decisión: Kubernetes compensa con una carga continua alta o con requisitos estrictos de soberanía o latencia. Por debajo de ese umbral, las API gestionadas y el serverless se ponen en marcha antes y salen más baratos.

La arquitectura de contenedores de un sistema de agentes

Un agente de IA en producción no es un monolito, sino un conjunto de microservicios. Esta división no es un fin en sí mismo: responde a los distintos perfiles de escalado, estado y seguridad de cada componente.

Servicio del agente (orquestador)

El servicio del agente es el cerebro: ejecuta la lógica de orquestación, decide qué herramientas llamar y planifica los pasos. Normalmente se construye sobre un framework como LangGraph, CrewAI o AutoGen, o sobre una plataforma de proveedor como PhariaAI (Heidelberg) o Microsoft Foundry Agent Service (antes Azure AI Foundry Agent Service). Lo decisivo a nivel de arquitectura: este servicio tiene que ser sin estado para que Kubernetes pueda escalarlo, reiniciarlo y distribuirlo libremente entre varias réplicas. Todo el estado se traslada a almacenes externos.

Servidores de herramientas y MCP

El Model Context Protocol (MCP) se ha consolidado como la interfaz estándar mediante la cual los agentes acceden a herramientas y fuentes de datos externas. En un entorno empresarial de la región DACH (Alemania, Austria y Suiza), los servidores MCP suelen ejecutarse como servicios dentro de la VPC, ubicados junto al runtime del agente y conectados mediante mTLS. Es el patrón por defecto para integraciones con SAP, Salesforce, ServiceNow, M365 y bases de datos internas. En escenarios de fábrica o de sucursales, los servidores MCP se despliegan en el edge, cerca de los datos, y la orquestación central los llama a través de líneas dedicadas (ExpressRoute, Direct Connect). Para cargas de trabajo reguladas, la regla es: servidores MCP dedicados por unidad de negocio con pistas de auditoría separadas, en lugar de un servidor multi-tenant.

Motor de inferencia

Aquí se ejecuta el modelo de lenguaje. En 2026, las opciones están bien definidas:

• vLLM (originario de UC Berkeley) es el estándar de facto para el self-hosting en producción: PagedAttention, el soporte de hardware más amplio y endpoints compatibles con OpenAI.
• SGLang (LMSYS) ofrece, según los benchmarks de LMSYS, alrededor de un 29 % más de throughput en modelos de 7B–8B sobre H100 y una mejor latencia de cola; ideal para chat multiturno, cargas con mucho RAG y cargas estructuradas.
• NVIDIA NIM empaqueta vLLM/TensorRT-LLM/SGLang en contenedores preconfigurados y es la vía on-premise más pragmática en las pymes de la región DACH, aunque está ligado a la licencia NVIDIA AI Enterprise.
• TensorRT-LLM ofrece el máximo throughput en hardware de NVIDIA, pero solo funciona con NVIDIA y es exigente a nivel operativo.

Aviso importante para sistemas existentes: Hugging Face pasó TGI (Text Generation Inference) a modo de mantenimiento el 11 de diciembre de 2025 y remite los nuevos despliegues a vLLM o SGLang. Si hoy usas TGI, no hace falta migrar con prisas, pero no deberías basar nuevos desarrollos en él.

Base de datos vectorial y cola de mensajes

La base de datos vectorial (Qdrant, Weaviate o pgvector) almacena los embeddings para RAG. Es un candidato clásico para un StatefulSet con PersistentVolumes, porque los embeddings y los chunks originales alcanzan tamaños de terabytes y necesitan una identidad de pod estable y almacenamiento persistente. Una cola de mensajes (por ejemplo, RabbitMQ, NATS o Redis Streams) desacopla los trabajos asíncronos y de larga duración de los agentes (procesamiento de documentos, análisis por lotes) de la ruta síncrona de peticiones y permite pools de workers que escalan de forma independiente.

Mapeo de componentes: qué va en cada recurso de K8s

La siguiente tabla es la referencia central para desplegar agentes. Asigna a cada componente el recurso de Kubernetes adecuado e indica la clave de arquitectura decisiva.

Escalado: HPA, planificación de GPU y los dos ejes

Los stacks de agentes escalan en dos ejes completamente distintos, y ese es el escollo más habitual.

Eje sin estado (CPU): el servicio del agente, los servidores MCP y el AI Gateway son cargas de trabajo de CPU baratas. Escalan de forma elástica con el Horizontal Pod Autoscaler (HPA): en los picos de carga se añaden réplicas y en reposo se eliminan. Para los workers basados en colas encaja KEDA, que escala según la profundidad de la cola y no solo según la CPU.

Eje GPU (inferencia): aquí rige otra lógica. Los nodos GPU se registran en el clúster mediante el NVIDIA Device Plugin; los pods solicitan GPU mediante el límite de recursos nvidia.com/gpu. Con node selectors, taints y tolerations, los pods de inferencia acaban de forma específica en los costosos nodos GPU, mientras que las cargas sin estado se quedan en nodos CPU. La diferencia central: la capacidad de GPU suele mantenerse en caliente en lugar de elástica, porque las GPU ociosas son el capex más caro que existe. La elasticidad real mediante el Cluster Autoscaler solo funciona donde el proveedor cloud suministra nodos GPU con suficiente rapidez. Con capacidad Blackwell dedicada y sujeta a asignación (B200/GB200), no es el caso.

Las matemáticas de la memoria de GPU determinan cuántos modelos caben por nodo. Regla práctica para los pesos: parámetros por bytes por parámetro. Un modelo de 70B necesita unos 140 GB en BF16 (2 bytes), unos 70 GB en FP8 y unos 35 GB en AWQ-INT4; a eso se suma la caché KV, que crece con el tamaño del batch y la longitud de secuencia (del orden de 10–40 GB en producción). En la práctica, un modelo de 70B solo cabe en una única H200 (141 GB) si está cuantizado, por ejemplo en FP8 con unos 70 GB más la caché KV. En BF16, los pesos apenas dejan espacio para la caché KV. Entonces hace falta paralelismo tensorial entre varias GPU de un nodo vía NVLink. Sobre el papel, dos H100 (160 GB en total) no bastan para los pesos más la caché KV. Por eso, para tamaños de batch de producción hacen falta dos H200 (282 GB) o cuatro H100 (320 GB).

Estado, memoria y región de la UE

A diferencia de las aplicaciones web clásicas, los agentes tienen estado: la memoria de conversación, los planes de tareas y el historial de llamadas a herramientas tienen que sobrevivir aunque un pod se reinicie o se produzca un failover de región. A nivel de arquitectura, eso significa: estado de sesión en un Redis regional o en Cosmos DB con georreplicación, memoria a largo plazo y base de datos vectorial replicadas de forma síncrona o asíncrona, según el RPO exigido. La base de datos vectorial es aquí el reto de los datos masivos, porque los embeddings y los chunks representan los mayores volúmenes de datos.

En cuanto a la región de la UE y la soberanía, acecha la trampa más importante: la región de Fráncfort de un hiperescalador estadounidense ofrece residencia de datos, no soberanía resistente a la CLOUD Act, porque el operador sigue siendo una persona jurídica estadounidense. Para Kubernetes gestionado con soberanía real entran en juego las nubes soberanas: Infomaniak (Ginebra/Zúrich, control totalmente suizo, FADP más RGPD) y Exoscale (Suiza, basada en CloudStack con orquestadores propios, K8s gestionado) ofrecen Kubernetes gestionado sin exposición a hiperescaladores; Swisscom tiene un servicio de K8s soberano basado en Kubermatic; STACKIT (Schwarz Digits, con centro de datos en Austria) y Open Telekom Cloud apuestan por plataformas basadas en OpenStack con instancias GPU. Para cargas de trabajo sin requisitos estrictos de soberanía, el Kubernetes gestionado de los hiperescaladores (AKS/EKS/GKE) en una región de la UE sigue siendo la opción pragmática por defecto; así lo resuelve también la arquitectura de referencia para scale-ups lean.

Secretos, acceso a herramientas y observabilidad

Los agentes tienen un radio de impacto (blast radius) inusualmente grande: un agente comprometido puede llamar a muchas herramientas. Por eso, la buena práctica es una cuenta de servicio por cada par agente-herramienta en lugar de una cuenta compartida, elevación de privilegios just-in-time para operaciones sensibles y pistas de auditoría que, mediante una cadena de intercambio de tokens, se remontan hasta la identidad del usuario.

En concreto, en Kubernetes:

• Workload Identity en lugar de credenciales estáticas: Azure Managed Identity, AWS IRSA (IAM Roles for Service Accounts en EKS), GCP Workload Identity Federation y, en nubes soberanas, cuentas de servicio de Keystone o de K8s. El objetivo es el mismo: ninguna clave en el código, ninguna persona en la ruta de las credenciales.
• Base de secretos: HashiCorp Vault es la capa de secretos y PKI más extendida en los stacks de plataforma de la región DACH; en BFSI y sector público, con sellado mediante un HSM de Utimaco (Aquisgrán) o de Thales. El patrón External Secrets los sincroniza en secretos de K8s sin guardarlos en el repositorio.
• Control del egress: el patrón consolidado en el sector BFSI de la región DACH es deny-by-default con una allowlist explícita de los FQDN de las API de modelos, registrada en el gateway. Esto evita la exfiltración accidental de datos y obliga a que todo el tráfico de modelos pase por el AI Gateway (LiteLLM, Portkey, Kong), donde residen los rate limits, los filtros de PII y los presupuestos.

Para la salud y la observabilidad, Kubernetes aporta la base: las probes de liveness y readiness por pod garantizan que solo los pods de inferencia sanos reciban tráfico, algo crítico con tiempos de carga de modelo largos (la readiness probe no debe ponerse en verde hasta que el modelo esté cargado). Por encima va una capa de tracing con OpenTelemetry, con atribución de costes precisa por token y un backend residente en la UE como Langfuse (autoalojado).

Cuándo usar Kubernetes y cuándo no

Aquí va la advertencia honesta sobre la complejidad. Kubernetes con inferencia en GPU autoalojada no es un proyecto de fin de semana. Compensa si se cumple al menos uno de estos factores:

• Carga alta y constante: según una regla práctica que circula entre los equipos de plataforma de la región DACH, la inferencia autoalojada sale más barata por token que las API gestionadas a partir de unas 8–12 H100 equivalentes de carga continua, pero con 6–9 meses de preparación de ingeniería. Por debajo de ese umbral, las API gestionadas dominan el TCO.
• Latencia estricta: los presupuestos de latencia por debajo de 200–500 ms con varias rondas de llamadas a herramientas exigen inferencia co-ubicada; las llamadas transatlánticas a API (Fráncfort → US-East: unos 85–95 ms de ida y vuelta) quedan entonces descartadas.
• Soberanía contractual: cuando el departamento jurídico no acepta la exposición a la CLOUD Act o cuando BSI C5 Type 2 es vinculante.

En cambio, las API gestionadas y el serverless son la mejor opción cuando la carga tiene picos (las GPU ociosas son el peor capex), cuando se necesita una gran variedad de modelos (Microsoft Foundry, por sí solo, añadió en 2025 DeepSeek R1, GPT-4.1, Mistral Large 3, Claude Opus 4.5 y Llama 4) o cuando, sencillamente, no hay equipo de plataforma. Pocas pymes de la región DACH dominan internamente la operación de vLLM, la planificación de GPU y los patrones de error de NCCL en modo 24x7, y esa carencia, no la tecnología en sí, es el motivo más frecuente por el que fracasan los proyectos de self-hosting.

Ejemplo concreto: clúster lean para un agente B2B

Un stack típico de scale-up (basado en la arquitectura de referencia «Lean Cloud») tiene este aspecto:

```text
Kubernetes gestionado (AKS/EKS en región de la UE o Exoscale/Infomaniak soberano)
├── Deployment: agent-orchestrator (LangGraph, 3 réplicas, HPA 2-10, nodos CPU)
├── Deployment: mcp-tools-sap (mTLS, 1 cuenta de servicio por herramienta)
├── Deployment: ai-gateway-litellm (Failover: Azure OpenAI EU -> Mistral La Plateforme)
├── StatefulSet: qdrant (3 réplicas, PVC, base de datos vectorial)
├── StatefulSet: redis (estado de sesión, georreplicación)
└── Worker-Deployment: doc-processor (KEDA, escala según la profundidad de la cola de RabbitMQ)
Inferencia del modelo: API gestionada (sin nodo GPU propio) -> a través del gateway
```

Aquí no hay ninguna GPU propia. La inferencia corre a cargo de una API gestionada con ubicación en la UE, abstraída a través del gateway. Es intencionado: con una carga modesta, el pago por token sale más barato y está en marcha en semanas en lugar de meses. Solo cuando el gasto mensual en API supera el run rate de unas 10 H100 equivalentes en una nube soberana, o cuando una nueva exigencia del regulador pide un control que la API gestionada no puede acreditar, compensa migrar a nodos GPU propios con vLLM o NIM en el mismo clúster. Para eso precisamente Kubernetes es ideal: la arquitectura se mantiene igual y solo el componente de inferencia pasa de «API gestionada detrás del gateway» a «Deployment de GPU en el clúster».

Para agencias y responsables de decisión B2B

Kubernetes es la base adecuada para sistemas de agentes que van a crecer a largo plazo, deben mantener la soberanía en la UE o tienen que cumplir requisitos de latencia estrictos, pero casi siempre conviene empezar con API gestionadas y Kubernetes gestionado, con un disparador de migración claramente documentado para el paso a una inferencia en GPU propia. Si no defines bien ese umbral, acabarás construyendo un clúster de GPU caro demasiado pronto, o demasiado tarde, cuando la factura de API ya se haya disparado. Blck Alpaca acompaña a empresas en Europa y agencias de marketing justo en esta decisión de arquitectura: desde la evaluación make-buy-rent por componente hasta el diseño de un clúster soberano y preparado para la observabilidad. Habla con nosotros antes de pedir la primera GPU.