La IA agéntica desató una tormenta en el mundo de las CPU durante los últimos seis meses, y aun así es un área de rendimiento que no tiene benchmarks sólidos y repetibles para ubicar el hardware más reciente. Tom's Hardware publicó el 29 de octubre cómo está armando una batería interna de pruebas que mide de punta a punta al menos un aspecto de los bucles agénticos, aislando el rendimiento de la CPU y la memoria del acelerador.

El medio aclara que es un trabajo en curso. Ya tiene un prototipo y el diseño central está decidido, pero falta trabajo antes de que los números que entrega resistan un examen. La prueba mira cómo escala el rendimiento agéntico en la CPU a medida que aumentan las sesiones, y entrega para cada chip un rendimiento ideal, el que permite correr la mayor cantidad posible de sesiones de agentes sin perder la interactividad.

Según el propio medio, al ser un área tan nueva y cambiante es seguro que tiene puntos ciegos. Las pruebas no reemplazan los otros ensayos de IA local que hace, los complementan.

¿Qué es un bucle agéntico?

Hablar de "agentes de IA" sugiere pequeños trabajadores que, armados con un LLM, resuelven cualquier tarea que se les entregue. Para medir rendimiento hace falta una definición más técnica, y hay dos partes que importan.

La primera son las funciones. En la IA agéntica el LLM recibe acceso a herramientas, que en frameworks populares como LangGraph son funciones de Python. Una herramienta puede leer o escribir un archivo, consultar una base de datos, correr pruebas sobre código o casi cualquier cosa que se pueda definir en una función. Este es un ejemplo básico.

Python
@tool
def run_command(command: str) -> str:
    """Run a build or test command in the repository root. Allowed: make [targets], python -m pytest [args]."""
    return traced("run_command", {"command": command}, lambda: ws.run_command(command))

Así se escribe una herramienta con LangGraph en Python, y es una de las que el equipo le dio al LLM a través de su perfil de LangGraph. El decorador @tool marca la función como una herramienta que el LLM puede llamar, y luego se define como cualquier función de Python con def run_command, que recibe el comando como argumento. El -> str del final indica que la función devuelve un texto.

Después viene una descripción de la herramienta que el LLM puede leer (las comillas triples solo permiten repartirla en varias líneas). En este caso se le indica que puede correr comandos de compilación o de prueba con make o pytest. La función va envuelta en una lambda y se entrega a una función de trazas general, un detalle que no importa por ahora. El objetivo es mostrar cómo se ve una llamada a herramienta.

Esa es solo una de las herramientas del agente de programación. También puede leer, escribir y editar archivos, y buscar en el código con expresiones regulares, todo definido de la misma forma. A la IA agéntica se le dice "bucle" porque una tarea suele exigir llamar varias veces a una herramienta, o a varias distintas.

Si se le pide al LLM "depura este script de Python", primero puede llamar a la herramienta que lista archivos para saber de qué script se trata. Después llama a la que lee archivos para entenderlo, o a la que busca en el código para encontrar por dónde empezar. Luego puede editar el archivo y correr un comando, y si el problema sigue, vuelve sobre esas herramientas varias veces.

Ese es el bucle agéntico. Se le da una instrucción al LLM, este evalúa y empieza a llamar las herramientas que necesita. Recibe la información de vuelta, reevalúa y puede llamar a más.

Por qué la prueba parte por la concurrencia

El equipo desarrolló la prueba en una Nvidia DGX Spark (GB10), con 128 GB de memoria unificada, una GPU Blackwell y la CPU Grace basada en Arm, relativamente débil. Corrió los bucles con el modelo gemma4-26b-a4b. El modelo no es lo importante mientras sepa llamar herramientas, y las pruebas se pueden volver a grabar con otros modelos a medida que salgan.

Lo que importa es la proporción del tiempo. Cada resultado es una lista de tareas secuenciales que el agente ejecuta contra el modelo, y casi todo el tiempo se va en la GPU. Incluso tareas exigentes para la CPU, como las del agente de programación, representan una fracción mínima del cómputo. Correr uno o unos pocos agentes no es problema para la CPU cuando hay una GPU grande con un modelo suficientemente capaz.

Al mirar de cerca un conjunto de tareas se ve que la CPU tiene mucho que ejecutar durante la ventana, pero lo hace tan rápido que casi no pesa en el tiempo total.

Esas tareas tampoco están repartidas de forma pareja. Según cuándo el agente necesite herramientas, la forma de la carga cambia mucho. El agente de documentos, que revisa un conjunto de archivos PDF y extrae información, concentra casi todo su trabajo de CPU al principio de la tarea. Después es inferencia pura en la GPU.

Una GPU más rápida terminaría antes la inferencia, pero habría que crear un desequilibrio enorme entre CPU y GPU para que la parte de CPU de un solo bucle agéntico se volviera un cuello de botella, al menos con estas herramientas comunes. Los agentes, sin embargo, no se limitan a una lista secuencial de tareas. Lanzan subagentes, y si varias sesiones corren en el mismo sistema en entornos aislados, la competencia por recursos limitados pasa a ser un problema real.

En vez de armar una plataforma desequilibrada a propósito, el equipo optó por la concurrencia. La idea es barrer el chip con sesiones simultáneas que corren una lista de tareas en bucle, cada una en su propio proceso. A medida que sube el barrido aparece la contención en la CPU, y se suman las pequeñas diferencias entre llamadas a herramientas, ejecución y compilación de código, navegación web y las demás tareas de los agentes.

¿Cómo funciona el benchmark?

El diseño general es simple. Agentes propios construidos con LangGraph tienen una lista de 30 tareas que ejecutan en orden contra un servidor llama.cpp que corre gemma4-26b-a4b. Los agentes no le hablan directo al servidor, sino a través de un proxy que graba una traza.

Durante la grabación en vivo, el agente se comunica con el proxy, que pasa la llamada al servidor llama.cpp. Mientras tanto, el proxy escribe cada petición al LLM y su respuesta en un JSON general. Las llamadas a herramientas no pasan por esa cadena y se registran en sus propios archivos JSON. Para cada tarea se genera además una respuesta correcta, que se guarda con su hash en otro JSON.

Grabar todo permite sacar el modelo en vivo de la ecuación. Los agentes corren igual que siempre, pero contra el proxy, que reproduce las trazas grabadas. Las peticiones y las llamadas a herramientas ocurren en vivo, pero el agente recibe de inmediato la respuesta que quedó registrada en la captura.

Cada petición del agente se compara por etiqueta de sesión y por hash antes de buscar la respuesta en el JSON general. Si no coincide, la corrida se detiene y queda marcada como inválida. Si todo calza, la respuesta vuelve y las sesiones llaman a las herramientas que necesitan. Esas llamadas se comparan con los JSON generados al grabar y se devuelve el resultado grabado, que es la clave del método.

La prueba compara la llamada en vivo con el resultado grabado, pero siempre devuelve el grabado para que la prueba no se desvíe, aunque la llamada sea correcta. Los desajustes reales de herramientas quedan registrados. La prueba sigue, pero se marca como inválida en cada nivel donde los hubo.

Ese esquema hace fácil rediseñar y ampliar la prueba. Se puede escribir un perfil nuevo en Python con LangGraph o pasar a otros frameworks como CrewAI. También se pueden volver a grabar trazas con otros modelos. Mientras la comunicación sea a través de un punto de acceso compatible con la API de OpenAI, las piezas se pueden combinar para representar más tipos de carga.

La prueba empieza con un solo proceso trabajador y sube hasta el máximo de hilos de la CPU, con tres repeticiones por nivel. Cada proceso trabaja sobre la lista de 30 tareas, y cada proceso nuevo arranca en el siguiente punto de la lista. La sesión uno parte en la tarea uno, la dos en la tarea dos, y así. Como las tareas no duran lo mismo, ese desfase crea una contención desigual cuando se superponen.

¿Qué mide en realidad?

La métrica es sesiones por segundo. Una sesión es una tarea completada de punta a punta, y se mide cuántas se completan por segundo en cada nivel. En los niveles bajos se completan menos de una por segundo, porque cada tarea tarda más de un segundo y se ejecutan en orden. Lo que se busca es cómo se separan los chips a medida que suben las sesiones.

Del barrido salen dos puntajes principales. El primero es el rendimiento máximo, la cifra más alta de sesiones por segundo registrada y el nivel de concurrencia en que se alcanzó. El segundo es el rendimiento ideal, el punto en que el 5% más lento de las sesiones no tarda más de 1,5 veces lo que toma una sola sesión en el nivel base. Que las tareas se alarguen al sumar sesiones es esperable, pero pasado ese umbral de 1,5 veces el tiempo crece bastante y, según la topología del procesador, el rendimiento puede empezar a caer.

El medio insiste en que en este barrido no hay espera de GPU. La GPU se quitó por completo para cargar a la CPU con todo el trabajo concurrente posible.