- Para superar la limitación de que los LLM, aunque resuelven problemas al nivel de una olimpiada de matemáticas, no pueden realizar con precisión ni sumas simples ni Sudoku sin herramientas externas, se propone un enfoque que construye una computadora real dentro del Transformer
- Convierte código C arbitrario en tokens para que el propio modelo genere directamente trazas de ejecución de millones de pasos, con streaming en CPU a más de 30 mil tokens por segundo
- La técnica clave consiste en restringir la dimensión de los heads de atención a 2D para transformarla en una búsqueda geométrica basada en convex hull, reemplazando el escaneo en tiempo lineal por tiempo logarítmico
- Implementa un intérprete de WebAssembly en los pesos del Transformer, de modo que la ejecución del programa ocurre de forma transparente dentro del bucle de decodificación del modelo, sin llamar herramientas externas
- A futuro, plantea la posibilidad de compilar programas directamente en los pesos y extender esto hacia sistemas de IA que integren representaciones aprendidas y algoritmos compilados sobre una sola base operativa
Límites operativos de los LLM
- Los LLM de última generación pueden resolver problemas al nivel de medalla de oro de la Olimpiada Internacional de Matemáticas o intentar abordar problemas abiertos de matemáticas y ciencia, pero siguen fallando en tareas puramente computacionales
- Incluso en sumas básicas cometen errores, y en benchmarks como Sudoku-Bench la tasa de éxito sin ayuda externa es muy baja
- Actualmente existen dos atajos para cerrar esa brecha
- Uso de herramientas (Tool use): el modelo escribe código, un intérprete externo lo ejecuta y devuelve el resultado
- Orquestación de agentes: un bucle externo guarda estados intermedios, descompone la tarea y vuelve a invocar al modelo repetidamente
- Estos enfoques son útiles, pero subrayan la limitación fundamental de que la capacidad real de cómputo existe fuera del modelo
- Es como decir que, porque los humanos construyeron aviones, entonces los humanos pueden volar
- El modelo puede razonar sobre el cómputo o coordinar herramientas, pero si no puede ejecutar por sí mismo, no es una verdadera computadora
Cómo convirtieron al Transformer en una computadora
- Diversos estudios ya demostraron la universalidad teórica de la arquitectura Transformer para simular una máquina de Turing, pero la capacidad expresiva teórica no garantiza eficiencia práctica de ejecución
- En lugar de un modelo de cómputo puramente teórico, implementan una computadora RAM moderna dentro del Transformer, donde cada instrucción se mapea como máximo a 5 tokens
- Sin embargo, el problema más profundo está en el propio proceso de decodificación
- La decodificación autoregresiva estándar interactúa en cada paso con todo el historial, que sigue creciendo
- El KV caching evita recalcular keys/values pasados, pero el costo de atención proporcional al tamaño del caché sigue presente
- Para resolver este límite, restringen la dimensión de los heads de atención a 2D e introducen una vía eficiente de decodificación para trazas de estilo ejecución
- Las operaciones principales de búsqueda/actualización pueden realizarse en tiempo logarítmico respecto de la longitud de la secuencia
- Esto permite ejecutar programas de millones de pasos dentro del Transformer
El significado del cómputo — uso de herramientas vs ejecución dentro del modelo
- En el enfoque tradicional de uso de herramientas, el modelo genera código como
python -c "print(3+5)" → un intérprete externo lo ejecuta → el resultado se inyecta en el flujo de tokens
- En este sistema, se implementa un intérprete de WebAssembly en los pesos del Transformer
- WebAssembly es un conjunto de instrucciones de bajo nivel para ejecución rápida y determinista, y un target de compilación de propósito general para C/C++
- Al calcular 3 + 5, el modelo emite instrucciones wasm (
i32.const, i32.add) y luego cambia a un modo de decodificación rápida para generar directamente la traza de ejecución paso a paso
- Diferencias clave
- El uso de herramientas es opaco (opaque): el modelo cede el control y recibe una respuesta de caja negra
- La ejecución dentro del modelo es transparente (transparent): todos los pasos intermedios aparecen en la traza y el modelo nunca sale de su propio bucle de decodificación
Demo de Sudoku — una prueba de estrés para cómputo preciso de largo plazo
- Los enfoques de redes neuronales entrenadas muestran buen desempeño en Sudoku fáciles, pero fallan por completo en problemas difíciles
- Suele decirse que los modelos autoregresivos son intrínsecamente inadecuados para problemas de satisfacción de restricciones, pero este sistema es completamente autoregresivo y aun así logra 100% de precisión
- El cuello de botella real no es el paradigma autoregresivo en sí, sino que los Sudoku difíciles requieren trazas de ejecución muy largas y la atención estándar vuelve impráctica la generación de contextos largos
- Ejecuta un solver completo de Sudoku compilado dentro del Transformer, realizando el algoritmo real paso a paso en lugar de una heurística aprendida
- Resuelve correctamente el "Sudoku más difícil del mundo" de Arto Inkala en menos de 3 minutos
- Si el solver compilado es correcto, ofrece una garantía universal de que la ejecución del Transformer también será correcta
Cómo se codifica el cómputo — una traza de solo append
- Se compara al Transformer autoregresivo con una máquina que vive dentro de su propio historial
- Una computadora tradicional actualiza memoria editable, pero el Transformer no tiene ese concepto
- Está compuesto por un prompt fijo (entrada/programa) y una traza que solo crece (tokens generados)
- La analogía es la de una libreta de solo append
- Las primeras líneas son la entrada (prompt), y cada línea posterior registra el siguiente paso del cómputo
- No se pueden modificar líneas anteriores y en cada paso solo se puede consultar un pequeño número de posiciones previas
- Muchos algoritmos pueden expresarse como una "traza de solo append que en cada paso consulta un número fijo y pequeño de posiciones previas"
- En este sistema, los tokens que genera el modelo representan el estado evolutivo de la máquina virtual: instruction pointer, operaciones de memoria/stack, aritmética, control de flujo y salida
- Los heads de atención funcionan como un arreglo unidimensional compartido, donde cada token escribe un valor en un índice y lee valores de otros índices, proporcionando primitivas de write-after-read
- La atención también puede calcular sumas acumuladas (cumulative sums), siguiendo instruction pointer, profundidad del stack, etc., como suma acumulada de incrementos delta
La clave que desbloquea todo: atención exponencialmente más rápida
- Una computadora real actualiza un estado pequeño con una cantidad de trabajo casi constante por instrucción, pero un Transformer estándar interactúa en el paso de decodificación t con un prefijo de longitud t, haciendo que el costo total crezca cuadráticamente
- La introducción de HullKVCache resuelve esta explosión cuadrática
- En benchmarks reales, HullKVCache alcanza 31,037 tokens por segundo (6,747 líneas/seg), mientras que un KVCache estándar llega a 272 tokens por segundo (59 líneas/seg), una diferencia de aproximadamente 114 veces
- En lugar de Θ(t) tiempo por paso, realiza la búsqueda de atención en O(log t) por paso
-
La vía rápida de la atención 2D
- No se busca acelerar Transformers en general ni introducir una arquitectura nueva, sino enfocarse en una parametrización manejable que restringe la dimensión del head a 2D en un Transformer vanilla
- Con
d_model = 36, n_heads = 18, se obtiene exactamente 2 dimensiones por head, usando 7 capas, nn.MultiheadAttention estándar y una red feedforward con compuertas
- Está construido en PyTorch vanilla puro, sin kernels de atención personalizados ni sparse masks
- El número de capas, heads y tamaño de embedding puede aumentarse arbitrariamente, por lo que el modelo completo no tiene que ser pequeño
- Se usan más heads con n_heads = d_model / 2
-
Perspectiva geométrica de la atención 2D
- Mecanismo de atención: los tokens pasados aportan key vectors 2D kⱼ y values vⱼ, el paso actual forma una query q y devuelve el value de la key con mayor producto interno (hardmax attention)
- Esto es exactamente equivalente a la clásica "consulta de punto de soporte (supporting point query)" en geometría computacional: dado una dirección q, encontrar el punto más lejano en esa dirección sobre el convex hull
- Manteniendo una estructura de datos de convex hull al mismo tiempo que se generan tokens, es posible hacer búsquedas en tiempo logarítmico sobre todos los puntos pasados
- Para operaciones de memoria/stack se necesita consultar "el valor almacenado más recientemente en el índice i", y esa es la razón de requerir keys 2D
- Si el índice j se almacena con la key 2D kⱼ = (2j, -j²) y se consulta con la dirección q = (i, 1), el término cuadrático -j² actúa como penalización para que solo gane una coincidencia exacta
- La atención 2D es suficiente para lograr completitud de Turing, y como muestra este blog, puede expresar una computadora RAM completa
Planes a futuro
-
Mecanismos de atención más ricos
- La implementación actual usa hardmax attention, pero eso no es una limitación fundamental
- Puede aproximarse con k-sparse softmax attention: se recuperan las top-k keys desde convex hulls anidados y luego se aplica softmax solo sobre ellas, con costo O(k + log n)
- La vía geométrica rápida no se limita solo a la estructura de ejecutores, sino que en principio puede acelerar el tiempo de decodificación de cualquier Transformer con heads 2D
- También puede extenderse naturalmente a heads 3D mediante convex hulls 3D, aunque en dimensiones más altas la eficiencia cae con rapidez
-
Entrenar modelos grandes con heads 2D
- La parametrización con heads 2D no es intrínsecamente pequeña: usando más heads y más capas se puede mantener un número total de parámetros similar al de un Transformer estándar
- Hay varios modos de uso posibles
- Una vía rápida dedicada combinada con un modelo más lento y generalista
- Una arquitectura híbrida rápida/lenta dentro de un solo sistema
- Speculative decoding, donde el modelo 2D propone tokens rápidamente y un modelo de atención general los verifica
- Como la traza de ejecución forma parte del forward pass, todo el proceso es diferenciable (differentiable), algo fundamentalmente distinto de las herramientas externas, y constituye una base de cómputo entrenable que puede integrarse directamente en modelos más grandes
-
Compilar programas en los pesos
- Actualmente el modelo aprende un intérprete codificado en los pesos, pero si se amplía la máquina compiladora generadora de pesos, sería posible compilar programas arbitrarios directamente en los pesos sin secuencias de tokens
- Los propios pesos se volverían el target de deployment del software, de modo que el modelo no aprendería a comportarse como software, sino que incluiría la lógica del programa compilado como parte de su circuito interno
- Si la lógica puede compilarse en los pesos, el descenso por gradiente deja de ser la única manera de modificar el modelo: aparece otra ruta para insertar directamente estructura, algoritmos y garantías en la red
- En última instancia, esto podría evolucionar hacia sistemas que no solo aprenden de la experiencia, sino que también modifican o amplían sus propios pesos para reescribir su máquina interna por sí mismos
-
Hacer crecer sistemas de IA como si fueran software
- Así como el ecosistema moderno de software evoluciona acumulando módulos, abstracciones y componentes reutilizables, dentro de los sistemas de IA también podría darse un proceso similar donde se agregan gradualmente nuevas capacidades computacionales
- Las nuevas funciones se conectarían a circuitos existentes sin reentrenar todo el sistema
- Los sistemas de IA del futuro no solo usarían software, sino que llevarían software en su interior, integrando representaciones aprendidas y algoritmos compilados sobre una sola base operativa
1 comentarios
Comentarios de Hacker News
Es un enfoque mucho más interesante que simplemente realizar cálculos
El modelo puede hacer un cambio dinámico de atención proporcional al logaritmo del número de tokens
Así puede rastrear registros y pila representados en texto e imitar la ejecución de programas
Si un LLM pudiera cambiar a un “modo de concentración” y generar tokens muy rápido, podría acelerar la fase de razonamiento en la que explora y depura muchas hipótesis
El paper propone que esto podría usarse en una arquitectura híbrida que combine rutas rápidas y lentas, o como un modelo de ejecución especulativa (speculative execution)
Al principio pensé “¿por qué habría que hacer esto?”, pero ahora lo veo desde la perspectiva del bootstrap de entrenamiento
Por ejemplo, se puede integrar al modelo un sistema experto con 80% de precisión y usar sus resultados como datos de entrenamiento para mejorar la exactitud
Cuanto más se reduzca el costo de entrenamiento para distintas tareas, más baja será la barrera de entrada en la competencia de IA
A diferencia de la atención softmax, la atención average-hard no es diferenciable con respecto a keys y queries
Incluso corrigiéndolo con una estimación straight-through, la velocidad de backpropagation no mejora
El cerebro humano no destaca por su capacidad de cálculo
Incluso multiplicar números de 10 dígitos toma mucho tiempo. Ese tipo de cálculo lo resuelven mucho mejor las compuertas lógicas
Entonces, quizá sería mejor que un LLM llamara a un módulo externo tipo ALU en vez de calcular directamente
La redacción parece escrita por IA, pero el mensaje central no está claro
No queda claro por qué sería mejor que el modelo ejecute programas internamente en lugar de usar sistemas externos, ni si la ventaja está en la velocidad, backpropagation o benchmarks
Algunas personas creen que la lógica simbólica (symbolic logic) es indispensable, pero este tipo de trabajo también puede verse simplemente como un experimento interesante
Eso es fundamentalmente distinto de llamar herramientas externas
Además, tiene un costo de decodificación de complejidad O(k + log n), y si pudiera resolver problemas como Sudoku con 100% de precisión, ya sería bastante significativo
También se podría combinar este método al estilo MoE o probar distintos intérpretes, como una VM embebida basada en WASM
La idea de integrar herramientas en la ruta de cálculo interna del modelo es muy interesante desde el punto de vista de la interpretabilidad
Sorprende que un Transformer simple pueda lograr esta eficiencia
Tiene potencial, pero en su estado actual su utilidad práctica es baja
Como no se publicaron los pesos ni las herramientas del “compilador”, es difícil experimentar
Aun así, la idea de integrar en un LLM primitivas de cálculo predefinidas podría seguir siendo útil
Esta frase es la clave:
“Como la traza de ejecución forma parte del forward pass, se pueden propagar gradientes a través del propio cálculo”
Es decir, a diferencia de las llamadas a herramientas externas, esto se vuelve una base de cálculo entrenable
Tampoco está claro cómo diseñaron los datos de entrenamiento ni la función de pérdida
Aun así, dado que las llamadas a herramientas rompen la eficiencia de batching, pasar por una subred de cálculo interna podría permitir grandes mejoras de eficiencia a escala
Aunque esa subred no tendría por qué ser necesariamente un Transformer; quizá bastaría con una capa no entrenable optimizada para GPU
El paper está ocultando lo importante
Si se limita la dimensión del attention head a 2, se pueden buscar y actualizar tokens con complejidad logarítmica
Pero no está claro por qué esta estrategia se aplica solo a los “tokens de código”
Elegir WASM como objetivo también resulta cuestionable en términos de eficiencia
Por ejemplo, describir self-attention como una “lookup table” no es preciso
En el ejemplo de código usan
d_model = 36, n_heads = 18para construir 2D por head, pero aun así sigue siendo ambiguoNo hay una explicación concreta de cómo compilaron el solver de Sudoku a pesos de Transformer
No queda claro si hicieron una compilación directa de código a pesos o si lo aprendieron mediante entrenamiento
Es interesante, pero sigue quedando la duda de “¿por qué habría que hacerlo así?”
El cerebro humano también puede simular una máquina de Turing, pero lo hace lentamente. Por eso usamos herramientas externas
Quizá con los modelos pase lo mismo y resulte más eficiente usar herramientas externas
También sería posible embebir un lenguaje como Elixir para ejecutar código más corto
La idea es que el modelo podría modificar código durante la ejecución o incluso tener capacidad de depuración