Un piloto con cuarenta usuarios recibe una arquitectura preparada para cien mil. Se añaden Kubernetes, varias regiones, cuatro modelos y una plataforma de features. Seis meses después, la mayor carga sigue siendo la reunión de demostración del jueves.
Escalar bien no consiste en construir para el número más grande que alguien pueda imaginar. Consiste en saber qué se rompe primero y ampliar cuando la demanda lo justifica.
La demanda de IA no se parece a una página web
Dos peticiones pueden consumir recursos muy distintos. Una clasifica un correo en un segundo; otra investiga durante quince minutos, consulta seis fuentes y genera un informe. Contar usuarios o solicitudes oculta esa diferencia.
Registre por flujo: tokens, llamadas a herramientas, duración, reintentos, tamaño de contexto, prioridad y tasa de éxito. Añada concurrencia y patrón temporal. Con ese perfil puede estimarse capacidad y coste.
Primero, una arquitectura que pueda esperar
La separación más útil suele ser sencilla:
La petición recibe un identificador y puede continuar en segundo plano. Los workers aumentan según cola, edad y prioridad, no solo CPU. Kubernetes permite escalar horizontalmente con métricas de recursos o personalizadas y configurar ventanas de estabilización para evitar oscilaciones (Kubernetes). Eso no significa que Kubernetes sea obligatorio: una cola gestionada y funciones pueden bastar durante mucho tiempo.
Capacidad antes que componentes
Empiece por presupuestos operativos:
- máximo de trabajos simultáneos;
- tiempo objetivo por clase;
- coste permitido por resultado;
- tamaño máximo de entrada y salida;
- reintentos y condición de cancelación;
- degradación cuando falla un proveedor.
Con límites explícitos, una implementación simple es segura. Sin ellos, una plataforma sofisticada puede escalar el error y la factura.
Cinco palancas antes de añadir servidores
Reducir trabajo innecesario
Elimine contexto repetido, consultas duplicadas y reintentos sin información nueva. Cachee artefactos estables con clave que incluya versión y permisos.
Enrutar por dificultad
Use reglas o modelos pequeños para pasos acotados y reserve capacidad cara para casos difíciles. Evalúe el router: ahorrar no compensa enviar preguntas complejas al camino débil.
Agrupar cuando la latencia lo permita
Procesos nocturnos, enriquecimientos y evaluaciones pueden ejecutarse en lote. La demanda deja de competir con el tráfico interactivo.
Controlar herramientas
Una API lenta domina la latencia aunque el modelo responda rápido. Añada timeouts, circuit breakers, idempotencia y límites por destino.
Recortar salida
Pedir una estructura breve reduce coste, revisión y variabilidad. Un informe largo debería responder a una necesidad, no ser el valor por defecto.
Señales para añadir complejidad
| Señal observada | Cambio razonable | Todavía no implica |
|---|---|---|
| cola supera el objetivo de forma sostenida | más workers o prioridad | rediseño completo |
| un proveedor limita capacidad | routing o contrato alternativo | multi-cloud total |
| despliegues se bloquean entre equipos | separación de servicios | plataforma interna universal |
| datos exigen residencia distinta | aislamiento regional | replicar todo en todas partes |
| incidentes no pueden atribuirse | observabilidad y ownership | más modelos |
Una previsión comercial puede justificar preparar interfaces y límites. No justifica pagar permanentemente capacidad o duplicar sistemas antes de validar uso.
Escalar calidad junto con tráfico
Al crecer, cambia la distribución: más idiomas, archivos peores, preguntas nuevas y usuarios que exploran límites. Muestree producción por segmento y mantenga evaluaciones con errores reales.
Despliegue versiones gradualmente. Compare calidad, latencia y coste; permita volver atrás. Una mejora media puede esconder una regresión en el caso que genera más riesgo.
Preguntas frecuentes
¿Cuándo hace falta Kubernetes?
Cuando necesita control de múltiples servicios, aislamiento, despliegues y escalado que su plataforma actual no ofrece. No por usar un LLM.
¿Cómo se estima capacidad de un agente?
Con distribución de duración, herramientas, concurrencia y reintentos por tipo de trabajo. Use percentiles y picos observados, no solo medias.
¿Conviene tener varios proveedores desde el principio?
Diseñe una frontera que facilite cambiar, pero implemente el segundo cuando exista riesgo o beneficio concreto. La equivalencia de comportamiento requiere evaluaciones.
¿Qué métrica debe activar el escalado?
La que represente presión: trabajos pendientes y antigüedad suelen ser mejores para tareas asíncronas; CPU puede no reflejar espera de modelos externos.
La capacidad ociosa también es una decisión de producto
Pagar margen puede ser correcto cuando la espera cuesta mucho. Debe ser consciente y medido. Sobredimensionar por inseguridad oculta qué demanda existe y convierte una hipótesis comercial en gasto fijo.
Fuentes y lecturas recomendadas
- Horizontal Pod Autoscaling — Kubernetes
- A practical guide to building agents — OpenAI
- AI RMF Core — NIST
Fuentes y vigencia revisadas el 18 de agosto de 2026.