Por qué el rendimiento de un agente de IA depende de la infraestructura

Un agente no es un chatbot con más pasos. Un chatbot resuelve una llamada de inferencia por mensaje: recibe el prompt, genera texto y espera al usuario. Un agente ejecuta el flujo completo. Consulta documentación, mira una base de datos, llama a una API, ejecuta código, evalúa lo que le ha devuelto y repite antes de responder. Cada una de esas decisiones abre otra llamada de inferencia, y cada resultado se acumula en el contexto del modelo.

Ese es el argumento que sostiene Coreweave, que vende capacidad de GPU para inferencia, en un análisis sobre agentes en producción. Viene de parte interesada, pero el problema que describe lo reconoce cualquiera que haya puesto un agente delante de tráfico real.

La cadena va tan rápido como su eslabón más lento

Los flujos multi-turno son secuenciales. Cada paso de razonamiento espera a que termine el anterior. Si una consulta a la base de datos tarda dos segundos, el modelo no puede empezar el siguiente paso hasta que vuelva el resultado. Da igual lo rápido que genere tokens: el resto de la cadena marca el ritmo. Un pico de latencia en un sistema externo se convierte en un agente colgado a ojos del usuario, que no ve el hipo de orquestación, solo ve que la herramienta se ha quedado parada. La fiabilidad de extremo a extremo depende de que cada eslabón tenga recursos para ejecutar bajo carga, no de la calidad del modelo.

Consumo de GPU a golpes, no en meseta

El segundo punto es el patrón de demanda. La mayoría de servicios de inferencia y los precios construidos encima asumen tráfico más o menos regular: sube el número de peticiones, escala la capacidad. Los agentes no funcionan así. Cada flujo se para mientras espera a un sistema externo y arranca cuando llega la respuesta. Durante la pausa, la GPU que servía ese flujo no tiene trabajo y el contexto acumulado puede salir de memoria. Cuando vuelven los resultados, muchos flujos reanudan a la vez y reprocesan su contexto completo, así que la utilización se parece a un electrocardiograma: plano y de repente un pico.

Si se aprovisiona para la media y no para el pico, la latencia p99 se dispara y nadie entiende por qué, porque el consumo medio parecía razonable. Los servicios de inferencia diseñados para flujos predecibles lo llevan mal: acaban con GPU desaprovechada en los valles y con colas en los picos.

Para quien despliega agentes, la consecuencia práctica es que la instrumentación tiene que cambiar. Medir solo la latencia de la llamada al modelo cuenta poco si el tiempo se va en una consulta a la base de datos o en una API de terceros. Hay que trazar el flujo entero, paso a paso, y aprovisionar mirando el pico de reanudación en lugar de la media. El modelo, al final, es la parte fácil de cambiar.