- Para superar a limitação de que LLMs conseguem resolver problemas no nível de Olimpíada de Matemática, mas ainda não executam com precisão nem soma simples/Sudoku sem ferramentas externas, surgiu uma abordagem de construir um computador real dentro do transformer
- Converte código C arbitrário em tokens, e o próprio modelo gera diretamente o trace de execução por milhões de passos, com streaming em CPU a mais de 30 mil tokens por segundo
- A técnica central restringe a dimensão dos attention heads a 2D, convertendo o problema em uma busca geométrica baseada em convex hull e trocando varredura em tempo linear por tempo logarítmico
- Ao implementar um interpretador de WebAssembly nos pesos do transformer, a execução do programa ocorre de forma transparente dentro do loop de decodificação do modelo, sem chamar ferramentas externas
- No futuro, isso aponta para a possibilidade de compilar programas diretamente nos pesos e expandir para sistemas de IA que integrem representações aprendidas e algoritmos compilados em uma única base operacional
Limites computacionais dos LLMs
- LLMs de ponta conseguem resolver problemas em nível de medalha de ouro da Olimpíada Internacional de Matemática ou enfrentar problemas matemáticos e científicos em aberto, mas ainda falham em tarefas puramente computacionais
- Erros aparecem até em adições básicas e, em benchmarks como o Sudoku-Bench, a taxa de sucesso sem ajuda externa é muito baixa
- Hoje existem dois caminhos de contorno para preencher essa lacuna
- Uso de ferramentas (Tool use): o modelo escreve código, um interpretador externo o executa e devolve o resultado
- Orquestração por agentes: um loop externo salva estados intermediários, decompõe a tarefa e chama o modelo repetidamente
- Essas abordagens são úteis, mas destacam a limitação fundamental de que a capacidade computacional real está fora do modelo
- Em analogia, é como dizer que o ser humano voa só porque construiu aviões
- O modelo pode raciocinar sobre computação ou coordenar ferramentas, mas, se não consegue executar por conta própria, não é um computador de verdade
Como transformaram um transformer em um computador
- Vários trabalhos já demonstraram a universalidade teórica de que a arquitetura transformer pode simular uma máquina de Turing, mas capacidade expressiva teórica não garante eficiência prática de execução
- Em vez de um modelo de computação puramente teórico, foi implementado dentro do transformer um computador RAM moderno, com cada instrução mapeada para no máximo 5 tokens
- Mas o problema mais profundo está no próprio processo de decodificação
- A decodificação autorregressiva padrão interage, a cada passo, com todo o histórico que continua crescendo
- O KV cache evita recalcular keys/values do passado, mas o custo de atenção proporcional ao tamanho do cache continua existindo
- Para resolver isso, a dimensão dos attention heads foi restrita a 2D, introduzindo um caminho de decodificação eficiente para traces em estilo de execução
- As principais operações de busca/atualização passam a poder ser executadas em tempo logarítmico em relação ao comprimento da sequência
- Isso permite executar programas com milhões de passos dentro do transformer
O significado de computação — uso de ferramentas vs execução dentro do modelo
- No uso tradicional de ferramentas: o modelo produz código como
python -c "print(3+5)" → um interpretador externo executa → o resultado é injetado no fluxo de tokens
- Neste sistema: um interpretador de WebAssembly é implementado nos pesos do transformer
- WebAssembly é um conjunto de instruções de baixo nível para execução rápida e determinística, além de ser um alvo de compilação geral para C/C++
- Ao calcular 3 + 5, o modelo emite instruções wasm (
i32.const, i32.add) e então muda para o modo de decodificação rápida, gerando diretamente o trace de execução passo a passo
- Diferença central
- Uso de ferramentas é opaco (opaque): o modelo entrega o controle e recebe uma resposta de caixa-preta
- Execução dentro do modelo é transparente (transparent): todos os passos intermediários aparecem no trace, e o modelo nunca sai do próprio loop de decodificação
Demo de Sudoku — teste de estresse para computação longa e precisa
- Abordagens de redes neurais treinadas têm bom desempenho em Sudokus fáceis, mas falham completamente em problemas difíceis
- Costuma-se dizer que modelos autorregressivos são inadequados por natureza para problemas de satisfação de restrições, mas este sistema é totalmente autorregressivo e ainda assim alcança 100% de precisão
- O gargalo real não é o paradigma autorregressivo em si, mas o fato de que Sudokus difíceis exigem traces de execução muito longos, e a atenção padrão torna impraticável gerar contextos longos
- Um solucionador completo de Sudoku compilado é executado dentro do transformer, realizando um algoritmo real passo a passo, e não heurísticas aprendidas
- O "Sudoku mais difícil do mundo", de Arto Inkala, foi resolvido corretamente em menos de 3 minutos
- Se o solucionador compilado for correto, isso fornece uma garantia geral de que a execução do transformer também será correta
Como a computação é codificada — trace append-only
- O transformer autorregressivo é comparado a uma máquina que vive dentro do próprio histórico
- Computadores tradicionais atualizam memória editável, mas transformers não têm esse conceito
- Eles consistem em um prompt fixo (entrada/programa) e um trace que só cresce (tokens gerados)
- Analogia do caderno em modo append-only
- As primeiras linhas são a entrada (prompt), e cada linha seguinte registra o próximo passo da computação
- Não é possível modificar linhas anteriores, e em cada passo só se pode consultar um pequeno número de posições anteriores
- Muitos algoritmos podem ser expressos como um "trace append-only que, em cada passo, consulta apenas um número fixo e pequeno de posições anteriores"
- Neste sistema, os tokens gerados pelo modelo representam o estado evolutivo da máquina virtual, incluindo instruction pointer, operações de memória/pilha, aritmética, controle de fluxo e saída
- Os attention heads funcionam como um arranjo unidimensional compartilhado, no qual cada token escreve um valor em um índice e lê valores de outros índices, oferecendo uma primitiva de escrever e depois ler
- A atenção também consegue calcular somas cumulativas (cumulative sums), permitindo rastrear instruction pointer, profundidade da pilha etc. como somas cumulativas de incrementos delta
O destravamento central: atenção exponencialmente mais rápida
- Um computador real atualiza um pequeno estado com trabalho quase constante por instrução, mas um transformer padrão interage no t-ésimo passo de decodificação com um prefixo de tamanho t, fazendo o custo total crescer quadraticamente
- A introdução do HullKVCache resolve essa explosão quadrática
- Em benchmarks reais, o HullKVCache alcançou 31.037 tokens por segundo (6.747 linhas/segundo), enquanto o KVCache padrão ficou em 272 tokens por segundo (59 linhas/segundo), uma diferença de cerca de 114x
- Em vez de tempo Θ(t) por passo, a busca de atenção passa a ocorrer em O(log t)
-
Caminho rápido para atenção 2D
- Em vez de acelerar transformers em geral ou introduzir uma nova arquitetura, o foco está em uma parametrização tratável que restringe a dimensão do head a 2D em um transformer vanilla
- Com
d_model = 36 e n_heads = 18, cada head tem exatamente duas dimensões, usando 7 camadas, nn.MultiheadAttention padrão e rede feedforward com gating
- Tudo isso é construído em PyTorch vanilla puro, sem kernels de atenção customizados nem máscaras esparsas
- O número de camadas, heads e o tamanho do embedding podem ser arbitrariamente grandes, então o modelo total não precisa ser pequeno
- Usa-se n_heads = d_model / 2 para ter mais heads
-
Perspectiva geométrica da atenção 2D
- Mecanismo de atenção: tokens passados fornecem vetores key 2D kⱼ e valores vⱼ, e o passo atual forma uma query q para retornar o valor da key com maior produto interno (atenção hardmax)
- Isso é exatamente igual à clássica "consulta de ponto de suporte (supporting point query)" da geometria computacional: dada a direção q, encontrar no convex hull o ponto mais distante nessa direção
- Mantendo a estrutura de dados do convex hull ao mesmo tempo em que os tokens são gerados, torna-se possível fazer busca logarítmica sobre todo o histórico de pontos
- Para operações de memória/pilha, é preciso consultar "o valor mais recentemente armazenado no índice i", e essa é a razão de exigir keys 2D
- Ao armazenar o índice j como key 2D kⱼ = (2j, -j²) e consultar com a direção q = (i, 1), o termo quadrático -j² atua como penalidade para que apenas a correspondência exata vença
- Atenção 2D é suficiente para completude de Turing, e, como mostrado neste blog, consegue representar um computador RAM completo
Próximos passos
-
Mecanismos de atenção mais ricos
- A implementação atual usa atenção hardmax, mas isso não é uma limitação fundamental
- Ela pode ser aproximada com atenção softmax k-sparse: buscar as top-k keys em convex hulls aninhados e aplicar softmax apenas sobre elas, com custo O(k + log n)
- O caminho rápido geométrico não fica limitado à estrutura de executor; em princípio, ele pode acelerar o tempo de decodificação de qualquer transformer com heads 2D
- Também há extensão natural para heads 3D via convex hull 3D, embora a eficiência caia rapidamente em dimensões maiores
-
Treinar modelos grandes com heads 2D
- A parametrização com heads 2D não é intrinsecamente pequena — é possível usar mais heads e camadas para manter um número total de parâmetros semelhante ao de transformers padrão
- Há vários modos de uso possíveis
- Um caminho rápido dedicado combinado com um modelo mais lento e mais geral
- Uma arquitetura híbrida rápido/lento dentro de um único sistema
- Decodificação especulativa (speculative decoding), em que o modelo 2D propõe tokens rapidamente e um modelo de atenção geral os valida
- Como o trace de execução faz parte do forward pass, todo o processo é diferenciável (differentiable) — algo fundamentalmente diferente de ferramentas externas, oferecendo uma base computacional treinável que pode ser integrada diretamente a modelos maiores
-
Compilar programas nos pesos
- Hoje, o modelo aprende um interpretador codificado nos pesos, mas ao expandir a máquina compiladora geradora de pesos, seria possível compilar programas arbitrários diretamente nos pesos, sem sequência de tokens
- Os próprios pesos se tornam o alvo de implantação (deployment target) do software, de modo que o modelo não apenas aprende a agir como software, mas incorpora a lógica compilada do programa como parte do circuito interno
- Se for possível compilar lógica nos pesos, descida de gradiente deixa de ser a única forma de modificar o modelo — surge outro caminho para inserir diretamente estrutura, algoritmos e garantias na rede
- No limite, isso pode evoluir para sistemas que não apenas aprendem com a experiência, mas também modificam ou expandem seus próprios pesos para reescrever a própria máquina interna
-
Fazer sistemas de IA crescerem como software
- Assim como o ecossistema moderno de software evolui acumulando módulos, abstrações e componentes reutilizáveis, um processo semelhante pode ocorrer dentro de sistemas de IA, com novas capacidades computacionais sendo adicionadas gradualmente
- Novas funções podem ser conectadas aos circuitos existentes sem reentreinar o sistema inteiro
- Sistemas de IA do futuro não apenas usarão software, mas conterão software internamente, integrando representações aprendidas e algoritmos compilados em uma única base operacional
1 comentários
Comentários do Hacker News
É uma abordagem muito mais interessante do que simplesmente realizar cálculos
O modelo pode fazer uma troca dinâmica de atenção proporcional ao logaritmo do número de tokens
Assim, ele pode imitar a execução de programas acompanhando registradores e pilhas representados em texto
Se um LLM puder mudar para um “modo de foco” e gerar tokens muito rapidamente, isso poderá acelerar a fase de raciocínio que explora e organiza inúmeras hipóteses
O artigo propõe que isso possa ser usado em uma arquitetura híbrida que combina caminhos rápidos e lentos, ou em modelos de execução especulativa (speculative execution)
No começo pensei “por que alguém faria isso?”, mas agora vejo pela perspectiva de bootstrap de treinamento
Por exemplo, é possível embutir no modelo um sistema especialista com 80% de precisão e usar seus resultados como dados de treinamento para elevar essa precisão
Quanto mais se reduz o custo de treinamento para várias tarefas, menor fica a barreira de entrada na competição de IA
Diferentemente da atenção softmax, a atenção average-hard não é diferenciável em relação a chaves e consultas
Mesmo corrigindo com uma estimativa straight-through, a velocidade da retropropagação não melhora
O cérebro humano não é particularmente bom em capacidade de cálculo
Até multiplicar números de 10 dígitos leva tempo. Portas lógicas fazem esse tipo de cálculo com muito mais eficiência
Então fico pensando se não seria melhor o LLM chamar um módulo externo como uma ALU em vez de calcular tudo diretamente
O texto parece ter sido escrito por IA, mas a mensagem central não está clara
Não fica claro por que é melhor para o modelo executar programas internamente em vez de usar sistemas externos, nem se a vantagem está em velocidade, retropropagação ou benchmark
Alguns acreditam que lógica simbólica (symbolic logic) é essencial, mas esse tipo de tentativa também pode ser visto apenas como um experimento interessante
Isso é fundamentalmente diferente de chamar uma ferramenta externa
Além disso, há um custo de decodificação com complexidade O(k + log n), e se isso resolve problemas como Sudoku com 100% de precisão, já é algo bem significativo
Também daria para combinar essa abordagem no estilo MoE ou experimentar vários interpretadores, como um VM embutido baseado em WASM
A ideia de integrar ferramentas ao caminho de cálculo interno do modelo é muito interessante do ponto de vista de interpretabilidade
É surpreendente que um Transformer simples consiga esse nível de eficiência
Há potencial, mas no estado atual a utilidade prática é baixa
Os pesos e as ferramentas de “compilador” não foram divulgados, então é difícil experimentar
Ainda assim, a ideia de embutir primitivas de cálculo predefinidas em um LLM pode continuar sendo útil
Esta frase é o ponto central:
“Como a trilha de execução faz parte do forward pass, é possível propagar gradientes pelo próprio cálculo”
Ou seja, diferentemente de uma chamada de ferramenta externa, isso vira uma base computacional treinável
Além disso, não estão claros os dados de treinamento nem o desenho da função de perda
Ainda assim, como chamadas de ferramenta quebram a eficiência de batching, passar por uma sub-rede de cálculo interno pode trazer grandes ganhos de eficiência em larga escala
Só que essa sub-rede não precisa necessariamente ser um Transformer; talvez uma camada não treinável otimizada para GPU já bastasse
O artigo está escondendo o essencial
Se a dimensão do head de atenção for limitada a 2, dá para buscar e atualizar tokens com complexidade logarítmica
Mas não está claro por que essa estratégia se aplica apenas a “tokens de código”
Também é questionável, do ponto de vista de eficiência, ter escolhido WASM como alvo
Por exemplo, descrever self-attention como uma “lookup table” não é preciso
No exemplo de código,
d_model = 36, n_heads = 18configura 2D por head, mas ainda assim muita coisa continua obscuraNão há explicação concreta de como o solucionador de Sudoku foi compilado para os pesos do Transformer
Não fica claro se houve compilação direta de código para pesos ou se isso foi aprendido por treinamento
É interessante, mas continua a dúvida: “por que fazer isso desse jeito?”
O cérebro humano também pode simular uma máquina de Turing, mas lentamente. Por isso usamos ferramentas externas
Talvez para modelos também seja mais eficiente usar ferramentas externas
Também seria possível embutir uma linguagem como Elixir e executar código mais curto
A ideia seria que o modelo pudesse modificar código durante a execução ou ter capacidade de depuração