Saltar al contenido principal
Esencial•8–14 horas

Laboratorio de capacidad, coste y caos de IA

Prueba una carga de IA bajo estrés: concurrencia, presupuestos de tokens/tools, colas, backpressure, 429/5xx/timeouts, load shedding, modo degradado y coste por tarea verificada con éxito.

planificación de capacidadautoscalingcolasbackpressureinyección de falloseconomía unitaria de IA

Escenario

Tarea

Un endpoint de IA es estable con carga de demo, pero el tráfico de producción tiene llegadas en ráfagas, contextos largos, llamadas paralelas a tools y cuotas del proveedor. Escalar solo por CPU no resuelve throughput de tokens, retrasos de cola, 429, amplificación de reintentos ni explosiones de coste. Construye un modelo de capacidad que mida tareas verificadas con éxito y no solo pods en ejecución.

Ejecución paso a paso

1. Construye el modelo de carga

Resultado: La planificación de capacidad refleja demanda específica de IA y no el promedio de peticiones HTTP.

Tareas

  • →Medir tasa de llegada y ráfagas
  • →Recoger distribuciones de tokens de entrada/salida
  • →Registrar fan-out de tools y dependencia más lenta
  • →Separar cargas user-facing, batch y de alta prioridad

Comprobaciones

  • ✓La carga P95/P99 difiere del caso medio
  • ✓Cuotas o límites desconocidos se marcan como riesgo
  • ✓La política de prioridad no provoca starvation de tareas críticas

2. Define presupuestos y señales de escalado

Resultado: Autoscaling responde a saturación, colas y throughput de tokens, no solo a CPU.

Tareas

  • →Definir techo de concurrencia
  • →Establecer presupuestos de tokens/tools/tiempo
  • →Añadir señales de edad/profundidad de cola y saturación
  • →Calcular coste por tarea verificada con éxito

Comprobaciones

  • ✓Agotar un presupuesto termina o degrada la tarea de forma controlada
  • ✓La señal de escalado tiene relación causal con el cuello de botella
  • ✓Tareas fallidas o inseguras no cuentan como éxito

3. Ejecuta pruebas de caos y carga

Resultado: Los fallos conocidos de sobrecarga y dependencias producen respuestas previsibles.

Tareas

  • →Inyectar 429/5xx/timeouts
  • →Retrasar dependencia de tool/retrieval
  • →Crear ráfaga de requests con contexto largo
  • →Probar amplificación de reintentos y recuperación de cola

Comprobaciones

  • ✓No hay reintentos infinitos ni crecimiento ilimitado de cola
  • ✓La prueba no evita límites de tenant o riesgo
  • ✓La recuperación no crea un segundo pico por reintentos sincronizados

4. Verifica degradación elegante

Resultado: Cuando falta capacidad, el sistema reduce funcionalidad y no control.

Tareas

  • →Probar load shedding
  • →Usar modelo más barato/fallback solo en tareas elegibles
  • →Desactivar tools no esenciales
  • →Registrar criterios de recuperación y retorno al modo normal

Comprobaciones

  • ✓Fallback supera el contrato mínimo de evaluación
  • ✓El modo degradado no aumenta autonomía
  • ✓El modo normal no vuelve hasta estabilizar dependencias

Criterios de aceptación

  • El modelo de carga incluye ráfagas, tokens, tools, colas y cuotas de proveedor
  • La política de capacidad tiene presupuestos acotados de concurrencia/tokens/tools/tiempo y señales explícitas de autoscaling
  • La suite de caos cubre 429, 5xx, timeout, dependencia lenta, agotamiento de cuota y amplificación de reintentos
  • Existe load shedding/modo degradado con límites de autoridad y privacidad sin cambios
  • El coste se mide por tarea verificada con éxito, no por request