Los agentes obligan a elegir entre modelos rápidos y modelos precisos

Un agente que resuelve una tarea en veinte llamadas al modelo no tarda veinte veces lo que una llamada suelta: tarda la suma de todas las esperas, y esa suma es la que decide si la herramienta se siente como un colaborador o como un trámite. Con casi todos los modelos frontera resolviendo bien los benchmarks de siempre, la pregunta útil ha dejado de ser cuál es más listo.

Los tests que durante años ordenaron la lista se han quedado sin recorrido. GSM8K, MMLU y HumanEval se apiñan cerca del techo para los modelos de primera línea, y los investigadores ya hablan de saturación de benchmarks como un problema de medición: cuando la distancia entre dos modelos cae por debajo del ruido del test, el ranking dice menos de lo que aparenta. Artificial Analysis ha respondido publicando varias curvas en lugar de una: inteligencia frente a velocidad de salida, frente a tiempo por tarea y frente a coste por tarea. La capacidad pasa a ser una propiedad entre varias.

La cuenta de la latencia

Un chat envuelve una sola llamada al modelo. Un agente encapsula decenas, y cada una depende del resultado de la anterior: no hay siguiente paso hasta que vuelve la respuesta de la herramienta o del modelo. En una tarea de veinte llamadas, un backend lento de unos 2 segundos por llamada se va a unos 45 segundos de reloj; uno rápido, por debajo del segundo, deja la misma tarea en unos 13. Ese factor es la razón por la que la iteración rápida ha pasado de deseable a requisito de diseño.

Andrej Karpathy lo planteo en 2025 en términos parecidos: según los modelos ganan capacidad, el trabajo humano se desplaza a orquestar y revisar lo que hacen los agentes, de modo que un agente lento o parado convierte a la persona en el cuello de botella.

El precio de la inteligencia

Epoch AI midió precisión y tiempo de ejecución en modelos de los principales proveedores y encontró un patrón incómodo: reducir a la mitad la tasa de error de un modelo tiende a ralentizarlo entre 2 y 6 veces, según la tarea. En GPQA Diamond el factor era de unos 6; en un benchmark de matemáticas de competición, de unos 2. Los modelos situados en la frontera de eficiencia eran casi siempre variantes destiladas y más pequeñas, las que llevan flash, mini o nano en el nombre.

La forma se repite en los modelos actuales. Kimi K3 se sienta cerca de la cima del índice de inteligencia pero genera unos 40 tokens por segundo, lo que Artificial Analysis marca como lento. Qwen3.8 Max está en una zona parecida, con unos 47. En el otro extremo, Nemotron 3.5 Lightning cambia algo de inteligencia por velocidad y apunta a una capa de ejecución rápida antes que a razonamiento de pico. Gemini 3.7 Flash y el Step 3.7 Flash de StepFun logran colocarse en la frontera entre ambas, rápidos sin hundirse en las pruebas.

El argumento contrario también tiene números. Los errores se acumulan igual que la latencia: un modelo que acierta el 90% de las veces en una llamada suelta parece mucho menos fiable cuando se mide si completa la misma tarea repetidamente. Los benchmarks que prueban esto, como tau-bench, muestran cómo la consistencia cae según sube el número de intentos.

La regla que se deduce no es elegir siempre el rápido. Es asignar el modelo al papel y no al leaderboard: el rápido y competente para los pasos frecuentes y de bajo riesgo que ocupan la mayor parte del trabajo de un agente, es decir leer, enrutar, redactar y llamadas simples a herramientas; el lento y más capaz para una decisión crítica al principio de una cadena larga, donde un fallo se propaga. Y a menudo la solución para un paso sensible a la precisión no es un modelo más grande, sino mejor arquitectura alrededor: validación de esquema antes de ejecutar una herramienta, puntos de control y un paso revisor que corte la salida mala antes de que se extienda.