El equipo de ARC-AGI-3 aceleró su agente de 500 a 3.400 tokens por segundo

En la competición ARC-AGI-3, un participante terminó en sexto lugar y extrajo una lección útil mucho más allá de los agentes que juegan. Cuando el presupuesto de cómputo está limitado a nueve horas, no siempre gana el prompt más ingenioso. A veces, el factor decisivo es cuántos intentos completos puede realizar el agente y cuánta calidad se pierde para alcanzar esa velocidad.

El autor empezó con unas diez trayectorias de juego en paralelo y una velocidad cercana a 500 tokens por segundo. Tras un mes de trabajo, el servidor producía alrededor de 3.400 tokens por segundo y atendía simultáneamente 110 trayectorias en una GPU con 96 GB de memoria. Sin embargo, acelerar el sistema no garantizaba por sí solo una mejora: algunas optimizaciones deterioraban de forma casi imperceptible las respuestas del modelo y, después de varias horas de juego, aparecía una meseta.

Por qué los prompts apenas ayudaron

Al principio, el participante probó el repertorio habitual de ideas: dos agentes con un juez, distintas formas de representar el tablero, un "fotógrafo" dedicado a las mecánicas del juego, un modelo programático del mundo, un enjambre de asesores y un agente con una mirada nueva. Casi todas las variantes ofrecieron resultados dentro del margen de ruido o los empeoraron.

El agente base ya podía recibir tanto una imagen como una representación ASCII del tablero, ejecutar Python para analizarla y elegir una acción. Los roles adicionales aumentaban el consumo de tokens, pero no eliminaban la principal limitación: el agente necesitaba más intentos independientes para completar 110 partidas. En las condiciones de la competición, otra elegante capa de razonamiento resultaba menos útil que varias trayectorias adicionales terminadas.

Es una buena prueba para cualquier sistema agéntico. Si un nuevo esquema parece más inteligente, pero no eleva la proporción de tareas completadas con éxito en un conjunto repetible, todavía no es una mejora, sino una hipótesis cara.

Cómo alojar 110 trayectorias en una sola tarjeta

La mayor parte de la memoria de la GPU estaba ocupada por los pesos del modelo y sus 512 expertos. Por ello, el estado de las trayectorias de juego se trasladó a la RAM, la caché KV se comprimió a un formato de 4 bits y el número de expertos disponibles se redujo inicialmente a 400. Esto permitió aumentar drásticamente el paralelismo.

El procesamiento por lotes de los mensajes entrantes aportó otra mejora. Cuando varias partidas devuelven nuevas observaciones al modelo al mismo tiempo, es más eficiente procesarlas juntas: la lectura del contexto de entrada se paraleliza bien, mientras que la generación de la respuesta sigue avanzando token a token. Un planificador agrupaba varias solicitudes para este procesamiento y reducía el número de ejecuciones costosas.

También hubo aceleraciones menores: el ajuste fino del modelo de borrador para el contexto del agente, la eliminación del recálculo innecesario del estado después de recortar el contexto y el traslado de determinadas operaciones de Triton a CUDA. Cada medida solo aportó unos pocos puntos porcentuales, pero juntas multiplicaron varias veces el rendimiento.

El coste apareció más tarde. La versión de 3.400 tokens por segundo obtenía a veces menos puntos que la más lenta. El conjunto reducido de expertos y otras aproximaciones rara vez cambiaban el token siguiente, pero las pequeñas divergencias se acumulaban a lo largo de una trayectoria de juego extensa.

La velocidad es útil hasta el punto de saturación

El hallazgo más práctico fue el cambio de modo en caliente. Durante las primeras seis horas, el agente trabajaba rápidamente con 400 expertos y lanzaba el máximo número de trayectorias. Cuando las partidas sencillas habían terminado y quedaban unas 70 difíciles, el sistema activaba los 512 expertos y pasaba a una generación de mayor calidad. Este modo elevó el resultado de aproximadamente 50 a 54 puntos.

A partir de cierto momento, más tokens apenas ayudaban. El agente superaba rápidamente los niveles sencillos y después se atascaba en los difíciles: la diferencia entre 600.000 y 900.000 tokens por partida era pequeña. Ese es el límite práctico de escalar los intentos sin mejorar el propio solucionador.

La conclusión para los desarrolladores es sencilla: no midan únicamente los tokens por segundo. Se necesitan al menos tres gráficos: rendimiento, calidad de la solución y resultado en función del tiempo. Primero hay que optimizar el número de intentos útiles, después encontrar el punto de saturación y recuperar la calidad en el tramo final. Además, es imprescindible comprobar cada aceleración en trayectorias largas: un error microscópico, imperceptible en una sola respuesta, puede costar toda la tarea.