Un agente de IA que funciona perfectamente en la demo con tres usuarios puede convertirse en un problema serio el primer lunes por la mañana con doscientos. No porque el modelo sea peor, sino porque nadie comprobó qué pasa cuando llegan cincuenta peticiones a la vez, cuando el proveedor devuelve un error de límite de tasa o cuando alguien pega un documento de ochenta páginas en el chat.
Las pruebas de estrés de cargas de trabajo de IA existen para responder a esas preguntas antes de que las responda un cliente enfadado. Y son distintas de las pruebas de carga de una aplicación web clásica, porque las variables que se rompen no son las mismas.
Por qué una carga de IA no se prueba como una API normal
En una aplicación tradicional, la respuesta a una petición tarda lo mismo hoy que ayer y su coste es prácticamente cero. En un sistema basado en modelos de lenguaje, tres cosas cambian:
- La latencia depende del contenido, no solo del tráfico. Una consulta que genera 100 palabras y otra que genera 2.000 tardan tiempos radicalmente distintos con la misma carga de servidor.
- Cada petición cuesta dinero. Una prueba de estrés mal planificada contra un proveedor de pago puede generar una factura considerable en una tarde. Hay que presupuestarla igual que se presupuesta el entorno.
- El límite lo pone un tercero. Con modelos alojados, el techo no es tu CPU: son las cuotas de peticiones por minuto y de tokens por minuto de tu cuenta. Saturar eso produce errores de límite de tasa, no lentitud progresiva.
A eso se suma que un sistema de agentes suele encadenar varias llamadas por cada petición del usuario, más consultas a bases vectoriales, más llamadas a herramientas internas. La latencia total es la suma de una cadena, y basta con que un eslabón se degrade para que todo el flujo se caiga.
¿Qué métricas hay que medir en una prueba de estrés de un sistema de IA?
Hay siete que no pueden faltar. Latencia hasta el primer token, porque determina la sensación de respuesta en interfaces conversacionales y es lo que percibe el usuario. Latencia total de la petición, medida en percentiles y no en media: el promedio esconde el 5 % de usuarios que espera treinta segundos, así que se reportan p50, p95 y p99. Rendimiento sostenido, en peticiones completadas por minuto y en tokens generados por segundo. Tasa de error desglosada por causa, separando límites de tasa, tiempos de espera agotados, errores del proveedor y errores propios, porque cada uno se arregla de forma distinta. Coste por petición y coste por hora de carga, para saber si el sistema es viable al volumen objetivo. Consumo de contexto, es decir, cuántos tokens de entrada gasta cada petición en el peor caso realista. Y la calidad de la respuesta bajo carga, que es la métrica que casi nadie mide y la más importante: comprobar que el sistema no empieza a devolver respuestas truncadas, incompletas o degradadas por un fallback automático a un modelo menor cuando el tráfico aprieta.
Los cuatro escenarios que hay que probar
Carga nominal sostenida
El tráfico esperado en un día normal, mantenido durante al menos una hora. Sirve para detectar fugas de memoria, crecimiento de colas y degradación lenta que en diez minutos de prueba no se ve.
Pico realista
El tráfico de la hora punta. En un agente de atención al cliente español eso suele ser el lunes entre las nueve y las once, y el primer día laborable tras un festivo. En un agente de facturación, el cierre de mes. Hay que probar con el patrón real del negocio, no con una curva teórica.
Ráfaga brusca
De cero a la carga máxima en pocos segundos, para ver cómo se comportan el arranque en frío, las colas y los reintentos. Es el escenario que descubre las tormentas de reintentos: cuando todo falla, todos los clientes reintentan a la vez y hunden el sistema definitivamente.
Prueba de rotura
Subir la carga hasta que el sistema falle, deliberadamente. No para desplegarlo así, sino para conocer el techo real y para observar cómo falla. Un sistema que se degrada con elegancia, encolando y avisando, es aceptable. Uno que devuelve respuestas incorrectas sin avisar, no.
A estos cuatro conviene añadir pruebas de entrada adversa: documentos enormes, texto con caracteres extraños, peticiones que provocan cadenas de razonamiento muy largas y usuarios que envían quince mensajes seguidos sin esperar respuesta.
Qué se rompe casi siempre
En los proyectos que revisamos, los puntos de fallo se repiten con una regularidad notable:
- Cuotas del proveedor. El sistema estaba dimensionado para el tráfico, pero la cuenta tenía un límite de peticiones por minuto que nadie había mirado.
- Ausencia de tiempo de espera máximo. Una llamada que se queda colgada bloquea un hilo, y cien llamadas colgadas bloquean el servicio entero.
- Reintentos sin control. Reintentar es correcto; reintentar tres veces de inmediato multiplica por tres la carga justo cuando el sistema ya está saturado. Hace falta espera exponencial con variación aleatoria y un cortacircuitos que deje de intentarlo.
- La base de datos vectorial. Con pocos usuarios responde en milisegundos; con carga y sin índice bien configurado, se convierte en el cuello de botella del flujo entero.
- Ausencia de límites por usuario. Un único cliente automatizando llamadas puede consumir la cuota de todos los demás.
- Sin degradación planificada. Cuando no se puede atender, hay que decidir de antemano qué se hace: encolar, responder con una versión reducida, derivar a una persona o rechazar con un mensaje claro. Improvisarlo en caliente sale mal.
¿Cómo se hacen pruebas de estrés en cargas de trabajo de IA sin arruinar el presupuesto?
Con tres decisiones previas. La primera, fijar un presupuesto máximo para la campaña de pruebas y una alerta de gasto que corte la ejecución automáticamente al alcanzarlo. La segunda, usar un entorno de pruebas con un simulador del proveedor para las fases de validación funcional y de infraestructura, reservando las llamadas reales de pago solo para las pruebas de latencia y calidad, que son las que de verdad necesitan el modelo. Un simulador que devuelve respuestas con la distribución de tiempos real permite estresar tus colas, tus tiempos de espera y tus reintentos por céntimos. Y la tercera, dimensionar la prueba con una muestra representativa en lugar de con volumen bruto: quinientas peticiones bien elegidas, que cubran los casos cortos, los largos y los adversos, informan más que cincuenta mil peticiones idénticas. Con esas tres reglas, una campaña completa cuesta una fracción de lo que la gente teme y evita el gasto mucho mayor de descubrir el problema en producción.
Del resultado a la decisión
Una prueba de estrés no termina con un informe de números. Termina con cuatro decisiones escritas:
- El compromiso de servicio que puedes prometer. Por ejemplo, respuesta en menos de cuatro segundos en el percentil 95 hasta cuarenta usuarios concurrentes. Si el comercial promete más que eso, hay un problema de expectativas antes de empezar.
- El punto de alarma. El nivel de carga a partir del cual hay que ampliar cuota o escalar infraestructura, con margen suficiente para reaccionar.
- El plan de degradación. Qué se apaga primero cuando falta capacidad y qué se protege siempre.
- El presupuesto de operación. Coste esperado al volumen objetivo, con el escenario pesimista incluido.
Cuándo repetirlas
Las pruebas caducan. Hay que repetirlas cuando se cambia de modelo o de versión, porque la latencia y el consumo de tokens cambian; cuando se modifican las instrucciones del sistema, porque un prompt más largo encarece cada petición; cuando se añade una herramienta nueva al agente, porque alarga la cadena; y antes de cualquier campaña o evento que multiplique el tráfico previsto. En sistemas críticos, una ejecución mensual automatizada del escenario de pico es una inversión pequeña frente al coste de una caída en hora punta.
En MG Solutions dimensionamos, probamos y monitorizamos las cargas de trabajo de IA que implantamos, con límites de coste, planes de degradación y compromisos de servicio que se pueden sostener. Si tienes un agente en producción y no sabes cuál es su techo real, medirlo es el primer paso.