La IA agéntica chocará contra un muro de infraestructura antes que contra uno de inteligencia

Los modelos mejoran más rápido de lo que podemos atender lo que se les pide.

La mayoría de los debates sobre el rumbo de los agentes de IA gira en torno a sus capacidades. ¿Puede el modelo planificar de forma fiable? ¿Puede corregir sus propios errores? ¿Se le puede confiar una acción con consecuencias?

Son preguntas legítimas. Pero no serán las que determinen si los agentes se implementarán a gran escala en los próximos años, porque hay una limitación más inmediata que se está haciendo presente con mayor rapidez. Prestar servicio a los agentes resulta económicamente complicado, y esa dificultad aumenta precisamente con las capacidades que todos quieren añadir.

Un chatbot y un agente generan cargas de trabajo distintas

Una solicitud conversacional consiste en un solo intercambio: se envía una instrucción, se reciben tokens y se cierra la conexión. Se pueden agrupar solicitudes, almacenar en caché el prefijo y analizar el rendimiento con una sola cifra.

Una solicitud a un agente es una sesión. El agente llama a una herramienta, espera, lee el resultado, decide qué hacer a continuación, llama a otra herramienta y, finalmente, responde. Una tarea moderada puede implicar seis u ocho llamadas al modelo, con periodos de espera entre ellas.

Esa diferencia importa por un motivo que no tiene nada que ver con la inteligencia. Entre un paso y otro, el agente mantiene un estado: la conversación, los resultados de las herramientas y el razonamiento acumulado. En el sistema que presta el servicio, ese estado reside en la memoria de la GPU como caché KV y ocupa memoria durante toda la sesión, incluidos los segundos que el agente pasa esperando una respuesta de una API externa.

Por eso, la unidad de capacidad deja de ser «solicitudes por segundo» y pasa a ser «sesiones simultáneas residentes en memoria». Un sistema que podía atender cómodamente mil solicitudes conversacionales por segundo quizá solo admita unas pocas decenas de sesiones simultáneas de agentes con el mismo hardware.

La espera es lo que más cuesta

Esta es la incómoda realidad: durante una llamada a una herramienta, el agente no hace nada. No genera tokens ni consume capacidad de cómputo. Sin embargo, la memoria de la GPU sigue ocupada, porque desalojar ese contexto y volver a calcularlo costaría más que mantenerlo.

El hardware más caro queda reservado para una solicitud que, en ese momento, está esperando una consulta a una base de datos.

En los sistemas distribuidos convencionales, hace mucho que resolvimos este problema: se libera el recurso y se retoma el trabajo cuando llega la respuesta. Hacer lo mismo al servir modelos implica desalojar la caché KV a la memoria del host o al disco y restaurarla después; el coste de transferencia es tan alto que la mayoría de los sistemas no se molestan en hacerlo. La investigación sobre este tema está en curso, precisamente porque el problema es costoso.

La ejecución secuencial empeora la situación sin necesidad

Casi todos los marcos de trabajo para agentes ejecutan las llamadas a herramientas una tras otra. El modelo solicita una consulta meteorológica y recibe el resultado; después, pide comprobar el calendario y recibe la respuesta; luego, solicita una búsqueda de vuelos y obtiene el resultado.

A menudo, esas tres llamadas no dependen unas de otras. Podrían ejecutarse al mismo tiempo. Si se ejecutan en secuencia, la latencia es la suma de las tres; si se ejecutan en paralelo, equivale a la de la más larga.

No es una observación novedosa sobre los agentes: es el mismo principio estructural que se aplica a cualquier sistema que ejecuta varios modelos o servicios dentro de un mismo presupuesto de latencia. La latencia total debería corresponder al camino más largo del grafo de dependencias, no a la suma de todas las etapas. Esto importa aún más en el caso de los agentes porque la sesión permanece en la memoria de la GPU durante todo el proceso. Por eso, reducir el tiempo total no solo mejora la experiencia del usuario: aumenta directamente el número de sesiones que caben en el hardware.

Reducir a la mitad la duración de una sesión casi duplica la capacidad simultánea con las mismas GPU y sin cambiar el modelo.

Los reintentos se acumulan de una forma que nadie diseñó

Los marcos de trabajo para agentes heredan los valores predeterminados de reintento de las bibliotecas HTTP que utilizan. Por lo general, son tres intentos.

El modelo también reintenta, a su manera. Cuando una herramienta devuelve algo poco útil, un modelo de razonamiento suele probar otro método: eso también es un reintento, solo que nadie lo configuró.

Al combinar ambos mecanismos, una política de tres intentos aplicada a un modelo que, por su cuenta, razona hasta probar otros tres métodos se convierte en una política de nueve intentos que nadie documentó. Cada intento implica una llamada completa al modelo, con sus propios tokens y segundos de uso de la GPU.

Cuando una dependencia se ralentiza, esta amplificación convierte la degradación en una interrupción del servicio, y lo hace con un coste por intento varios órdenes de magnitud superior al de una llamada REST repetida.

Cómo se manifiesta realmente el límite

No es un techo de capacidad. Es algo más mundano: un problema de economía unitaria que frena los proyectos al pasar de la fase piloto a la producción.

El piloto funciona. Hay diez usuarios, la latencia es aceptable y la factura representa un coste insignificante. Luego alguien hace una proyección para diez mil usuarios y los requisitos de GPU resultan poco realistas, no porque el modelo sea lento, sino porque cada sesión simultánea ocupa memoria durante toda su duración, y esa duración incluye el tiempo de espera.

En esta etapa, muchas demostraciones internas prometedoras dejan discretamente de avanzar.

Qué hace retroceder el muro

Nada extraordinario, y todo tiene que ver con la infraestructura, no con el modelado:

Ejecutar en paralelo llamadas independientes a herramientas. Es la mayor mejora individual que se puede lograr hoy y no requiere hardware nuevo.

Usar la duración de las sesiones como métrica de capacidad. No los tokens por segundo. Ni la utilización de la GPU. Lo importante es cuánto tiempo permanece el estado en memoria y cuántas sesiones caben.

Distribuir los reintentos entre todo el sistema, en lugar de asignar un límite a cada llamada. Un tope global —con los reintentos limitados a un pequeño porcentaje del tráfico total— evita el efecto acumulativo descrito anteriormente. Tanto las prácticas de SRE de Google para gestionar la sobrecarga como los presupuestos de reintentos de Envoy implementan esta idea fuera de la pila de IA.

Separar el razonamiento de la ejecución. Un modelo grande para planificar y otro mucho más pequeño para los pasos mecánicos. La mayoría de las tareas de un agente no requieren un modelo de vanguardia.

Hacer que la expulsión de contexto sea poco costosa. Una caché KV cuantizada, atención paginada y mecanismos para descargar las sesiones inactivas. Aquí es donde se está desarrollando ahora mismo el trabajo más interesante sobre sistemas de inferencia.

Los modelos seguirán mejorando. Eso parece seguro. Que los agentes se conviertan en infraestructura o sigan siendo demostraciones depende de algo menos vistoso: si podemos atender una carga de trabajo que mantiene memoria costosa ocupada mientras espera, y si dejamos de pagar el costo total de una secuencia cuando podríamos pagar solo el de su ruta más larga.

Publiqué el modelo de ejecución que sustenta este último punto —la ejecución concurrente de llamadas dependientes a modelos dentro de un único presupuesto de latencia— en «Ejecución asíncrona de grafos de inferencia para el enrutamiento de modelos en sistemas de aprendizaje automático», International Journal of Computer Trends and Technology 72(10), octubre de 2024. Sobre la integración de modelos generativos en sistemas de toma de decisiones sujetos a restricciones de latencia, en particular, véase «Plataformas de negociación y toma de decisiones aumentadas con LLM: conectar la inteligencia generativa con los sistemas de decisión financiera», Journal of Information Systems Engineering and Management 11(1s), 2026.