En pocas palabras: El desarrollador mvakde entrenó un transformer chico (8 capas) desde cero por apenas 67 centavos de dólar en una RTX 5090 de vast.ai, y logró 44% en ARC-AGI-1 y 7% en ARC-2, superando a varios LLMs grandes en el benchmark de razonamiento de François Chollet.
Sí, leíste bien el número: 67 centavos. No 67 dólares, no 67 mil. Y con eso le gana a un montón de LLMs grandes en un benchmark que estuvo seis años abierto, con un premio de un millón de dólares colgando. La pregunta obvia es cómo. La menos obvia, y más interesante, es por qué nadie lo había hecho antes.
ARC-AGI es un benchmark creado por François Chollet para medir inteligencia fluida: la capacidad de resolver problemas nuevos sin haberlos visto antes. Cada puzzle usa una regla distinta y hay apenas 1000 en total, así que no alcanza con memorizar. El trabajo de mvakde es un transformer entrenado desde cero en cada corrida, sin datos sintéticos masivos ni sesgos humanos metidos a mano.
En resumen
- 44% en ARC-AGI-1 y 7% en ARC-2, empatando a TRM y HRM, dos modelos diseñados justo para este benchmark.
- 67 centavos de dólar de costo total (entrenamiento + inferencia), alquilando una RTX 5090 por dos horas en vast.ai.
- 8 capas, arquitectura moderna (SwiGlu, RMSnorm) y embeddings 3D RoPE más un embedding por tarea: sacá cualquiera de los dos y el puntaje se desploma a 24-25%.
- Pasar de no supervisado a supervisado subió el score de 40% a 44%, aunque la pérdida en test empeoró (una paradoja que ni el autor termina de explicar).
- El código es abierto y el autor cree que llegar a 65% es alcanzable sin ideas revolucionarias, solo puliendo el mismo transformer.
¿Qué es ARC-AGI y por qué importa medir la eficiencia de muestras?
ARC-AGI es un test de inteligencia fluida donde cada puzzle presenta unos pocos ejemplos de entrada y salida (grillas de colores), y el modelo tiene que deducir la regla y aplicarla a una entrada nueva. Lo diseñó Chollet para medir algo que los LLMs hacen mal: razonar sobre problemas que no estaban en el entrenamiento. Tiene 1000 puzzles, seis años de antigüedad y tuvo un premio de un millón de dólares.
¿Por qué obsesionarse con esto? Porque mvakde considera que la eficiencia de muestras es el problema más importante de la IA hoy. La idea es simple: en vez de tirar millones de ejemplos y GPUs infinitas al problema, ver cuánto podés aprender con poquísimos datos.
ARC encaja perfecto para eso. Pocas muestras en un espacio enorme de posibilidades, cada puzzle con su propia regla, y algo clave: todos los conceptos que aparecen en el set de evaluación ya están presentes en el de entrenamiento. Un chico lo resuelve mirándolo. Una máquina, no tanto.
Ojo con una distinción que confunde a todos: ARC-1 y ARC-2 no son lo mismo. ARC-2 contiene 773 puzzles repetidos de ARC-1 más 347 nuevos. Si entrenás sobre ARC-2 sin filtrar, sacás 100% por pura filtración de datos. mvakde sacó esos 773 repetidos a mano para que no hubiera leakage.
¿Cuánto costó y qué puntaje sacó el transformer pequeño entrenado barato?
El transformer pequeño entrenado barato sacó 44% en la evaluación pública de ARC-AGI-1 y 7% en ARC-2, con un costo total de 67 centavos de dólar. Ese número incluye el ciclo de vida completo: entrenar el modelo desde cero y ejecutar toda la inferencia. Nada de esconder el pre-entrenamiento como hacen los LLMs cuando reportan sus costos.
El detalle del costo es honesto y por eso pega tan fuerte. Una RTX 5090 en vast.ai, dos horas, listo. Comparalo con lo que sale entrenar un modelo grande de frontera y la diferencia es de varios órdenes de magnitud. Relacionado: consideraciones de seguridad.
Este es el tercer trabajo de una serie. El resultado anterior ya había estado en 40% y se volvió viral en X, con investigadores debatiéndolo a favor y en contra. La versión de 44% es más rápida, más barata y sigue siendo de código abierto (que no es poco).
¿Cómo funciona la arquitectura del transformer?
La arquitectura convierte cada par entrada-salida en una secuencia de tokens, y un transformer chico de 8 capas la entrena de forma autoregresiva, desde cero, en el momento del test. Cada puzzle recibe un embedding aditivo propio (aprendido) para permitir aprendizaje entre tareas, y las posiciones se codifican con embeddings 3D RoPE porque cada secuencia tiene dos grillas 2D.
Las mejoras respecto a la versión anterior vienen por dos lados. Para subir el puntaje: arquitectura moderna (SwiGlu en vez de GELU, RMSnorm en lugar de LayerNorm), más diversidad de datos con mejor mezclado, y el salto de 4 a 8 capas.
Para bajar el costo: muchas menos augmentaciones (más eficiente en muestras), Flash Attention con entrenamiento varlen y kernels de flex attention para la inferencia.
¿Cuánto pesan esos embeddings? Muchísimo. Si sacás el 3D RoPE, el puntaje cae a 24%. Si sacás el embedding por tarea, también baja a 24%. El propio autor dice que la mayor contribución al rendimiento son las buenas representaciones. La arquitectura fina importa, pero cómo le mostrás los datos al modelo importa más.
Un detalle sobre el optimizador. Antes de llegar a NorMuon, mvakde probó Muon vanilla: entrenaba más rápido que AdamW pero la pérdida se quedaba dando vueltas al final sin converger. Con NorMuon el problema desapareció solo, sin toquetear el learning rate a mano.
¿Por qué pasar de no supervisado a supervisado mejoró el resultado?
Al dejar de entrenar sobre los tokens de entrada, la función de pérdida quedó solo con los tokens de salida, convirtiendo el enfoque en supervisado, y eso subió el puntaje de 40% a 44%. Lo raro, y esto lo admite el autor, es que la pérdida en test empeoró mientras el score en ARC mejoró. Ya lo cubrimos antes en la comparación con ChatGPT.
Pensalo un segundo. Entrená peor según la métrica de pérdida, pero resuelve más puzzles. Y encima es más estable: menos varianza entre corridas.
¿Por qué? mvakde no lo sabe con certeza. Su hipótesis es que la capacidad finita del modelo tiene algo que ver. Lo interesante es la conclusión práctica: mucha gente en investigación persigue la menor pérdida de validación posible en datasets chicos como proxy de eficiencia. Este resultado sugiere que esa métrica y el rendimiento real pueden ir por caminos distintos.
¿Es “training on test”? Las críticas y las respuestas
No, no es “training on test”. Ese término significa entrenar sobre las etiquetas de los datos de test, y acá las etiquetas (la grilla de salida del par de test) nunca se tocan: están ocultas y se pueden borrar de antemano. Lo que sí se usa son los inputs de los puzzles de evaluación, algo llamado razonamiento transductivo, estudiado desde la época de Vapnik y permitido en un benchmark de metalearning.
La cosa se puso picante cuando el resultado anterior se hizo viral. Estas fueron las principales críticas y cómo las respondió el autor:
- “Entrenar sobre los inputs de eval filtra información”. Es transducción, un enfoque legítimo. Ignorar los inputs de evaluación además no tiene sentido en un mundo que intenta resolver aprendizaje continuo.
- “Va contra la política del test”. La política dice que quien diseña el sistema no debe conocer el test de antemano, no que la IA no pueda entrenar en el momento. El test time training siempre estuvo permitido y alentado en la comunidad ARC.
- “No incluís el costo de entrenamiento”. Los 67 centavos son el cómputo de vida completa: entrenar más inferencia. Encima es más generoso que los LLMs, que excluyen su pre-entrenamiento.
Sobre el ARC-AGI en sí, mucha gente preguntó qué mide (inteligencia fluida) y si resolverlo implica AGI (nadie lo afirmó). Chollet ya respondió todo eso: el benchmark señala qué preguntas de investigación importan, no anuncia que se llegó a la AGI.
¿Qué mejoras dieron el mayor salto? La tabla de ablaciones
Las ablaciones muestran con números crudos qué sostiene el rendimiento. Sacar componentes de a uno revela cuánto aporta cada pieza, y el patrón es contundente: las representaciones posicionales y por tarea son el corazón de todo.
| Configuración | Puntaje en ARC-1 |
|---|---|
| Modelo completo (supervisado, 3D RoPE, per-task) | 44% |
| Entrenando también sobre inputs (no supervisado) | ~39% |
| Solo ARC-1 + ConceptARC como datos | ~40% |
| 1D RoPE en vez de 3D RoPE | ~24% |
| Sin embedding por tarea | ~24% |
| Estilo CompressARC (desde cero por tarea, no supervisado) | ~18% |
| CompressARC pero supervisado | ~15% |
Fijate el salto: de 44% a 24% con solo cambiar el 3D RoPE por 1D. Es la mitad del rendimiento por un detalle de cómo se codifican las posiciones. El autor sospecha que RoPE mezcla información posicional con la de contenido, y que un esquema alternativo (menciona PoPE) podría rendir igual o mejor. Para más detalles técnicos, mirá fundamentos de modelos de lenguaje.
¿Qué ventaja tiene sobre otros métodos de eficiencia de muestras?
La ventaja es que llega a un rendimiento real alto con presupuesto ridículamente bajo, en vez de optimizar una métrica proxy. Buena parte de la comunidad busca la menor pérdida de validación en datasets pequeños; este trabajo muestra que representaciones bien elegidas alcanzan sin necesidad de datos sintéticos masivos ni sesgos humanos metidos a mano.
Hay un punto de acceso que vale la pena remarcar. Todo esto corre en una GPU de consumo alquilada por monedas. Cualquiera con ganas y una tarjeta de crédito puede reproducirlo, modificar el código y probar sus propias ideas. Si estás armando infraestructura para experimentar con modelos, tenés opciones de cloud y VPS en donweb.com para las partes que no necesiten una GPU de última generación.
El autor lo dice sin vueltas y con algo de bronca: “No entiendo por qué otros no se dieron cuenta de esto. Es solo un transformer con la representación más obvia”. Su teoría es que los investigadores subestiman el deep learning, o que el costo de experimentar era tan alto que no podían correr ablaciones bien, o que quedaron encandilados por los LLMs.
¿Se puede llegar a 65% con este mismo enfoque?
Sí, mvakde cree que 65% es alcanzable sin ideas revolucionarias, solo puliendo el transformer actual. La evidencia: tomó la unión de todos los puzzles resueltos en varias corridas y llegó a 55%, con un montón de tareas “casi” resueltas. La capacidad ya está ahí, falta consolidarla.
Las ideas que propone para quien quiera contribuir:
- Cambiar el esquema posicional: probar PoPE en lugar de RoPE, o inventar uno nuevo que no mezcle posición y contenido.
- Modernizar más la arquitectura: según el autor, todavía hay margen claro.
- Código GPU hecho a mano: podría bajar el costo unas 10 veces.
- Eliminar las augmentaciones: el autor las odia (sus palabras) y quiere sacarlas manteniendo el costo bajo.
Un pedido explícito a la comunidad: no aumentar los datos de entrenamiento. La gracia es la eficiencia de muestras, no tirarle más data al problema.
Errores comunes al interpretar este resultado
Creer que un transformer chico ya “le gana” a Claude o Llama en todo
No. Le gana en ARC-AGI, un benchmark específico de razonamiento abstracto donde se hace test time training. Un modelo de 8 capas entrenado para resolver grillas de colores no te va a escribir código, resumir un PDF ni mantener una conversación. Son cosas distintas.
Confundir “usar los inputs de test” con “hacer trampa”
El error clásico. En un benchmark de metalearning, aprender de los puzzles de evaluación es parte del juego. Lo prohibido es entrenar sobre las etiquetas de salida del test, y eso acá no pasa. El código abierto permite verificarlo.
Pensar que menor pérdida de validación siempre significa mejor modelo
Este trabajo es un contraejemplo directo. La versión supervisada tiene peor pérdida en test y mejor puntaje real. Si estás optimizando solo la val loss en un dataset chico, tomalo con pinzas: puede no correlacionar con lo que te importa. Lo explicamos a fondo en servicios IA de Google.
Preguntas Frecuentes
¿Cuántos parámetros tiene el transformer?
El autor no publicó un conteo exacto de parámetros, pero describe un transformer de 8 capas, chico para los estándares actuales. La clave no es el tamaño sino la arquitectura moderna (SwiGlu, RMSnorm) y las representaciones (3D RoPE más embedding por tarea). Es intencionalmente pequeño para maximizar la eficiencia de muestras.
¿Cuánto tarda y cuánto cuesta entrenar este transformer?
Alrededor de 1,5 horas de entrenamiento sobre una RTX 5090, con un costo total de 67 centavos de dólar contando entrenamiento más inferencia. El precio sale de alquilar la GPU por dos horas en vast.ai. Es el cómputo de vida completa, no un número parcial.
¿Se puede reproducir el resultado?
Sí. El código es abierto y está en GitHub. El autor invita a modificarlo para mejorar el puntaje o bajar el costo, con un solo pedido: no aumentar los datos de entrenamiento, porque eso rompe el objetivo de medir eficiencia de muestras.
¿Qué diferencia hay entre ARC-1 y ARC-2?
ARC-2 contiene 773 puzzles repetidos de ARC-1 más 347 nuevos. Entrenar sobre ARC-2 sin filtrar produce filtración de datos y un falso 100%. El transformer sacó 44% en ARC-1 y 7% en ARC-2, mostrando que el segundo es bastante más difícil.
¿Este resultado significa que estamos cerca de la AGI?
No, y ni el autor ni Chollet lo afirman. ARC-AGI mide inteligencia fluida, que Chollet considera necesaria pero no suficiente para AGI. Resolver el benchmark señala progreso en una capacidad concreta, no la llegada a una inteligencia general.
Conclusión
Lo que cambió acá no es que un modelo chico le gane a los grandes en una tarea puntual. Es la demostración de que un transformer común, con la representación más obvia y 67 centavos de cómputo, alcanza lo que muchos creían que necesitaba ideas nuevas o datos sintéticos por toneladas.
La lección práctica para cualquiera que trabaje con modelos: las representaciones (cómo le mostrás los datos al modelo) pesan más que la arquitectura fina, la val loss no siempre te dice la verdad, y el costo de experimentar bajó tanto que ya no hay excusa para no correr ablaciones bien hechas.
Si te interesa el tema, cloná el repo, corré una ablación y probá tu idea. El autor cree que 65% está a la vuelta de la esquina, y con este presupuesto, la barrera de entrada quedó al alcance de cualquiera.
Fuentes
- 44% on ARC-AGI-1 in 67 cents – blog original de mvakde con los datos y ablaciones
- arc-agi-transformer – código abierto del proyecto en GitHub
- Discusión en X – debate del autor con investigadores sobre el enfoque