Um LLM que não chuta conta, ele executa

Qwenputer parte de um problema que todo operador conhece bem: modelo de linguagem erra conta grande. Você pede para multiplicar 123456789 por 987654321 e recebe um número bonito, confiante e errado. A saída padrão é chamar Python fora do modelo, com tool use, sandbox e latência de rede. O projeto Qwenputer inverte essa lógica. Em vez de dar uma calculadora para o modelo chamar, os autores compilaram uma CPU RISC-V de 32 bits diretamente dentro dos pesos do Qwen3.5-4B. Não é metáfora. São 11 camadas de transformer na frente do Qwen que funcionam como processador real, com registradores, program counter, RAM e firmware, tudo rodando dentro do forward pass.

Isso incomoda porque quebra a separação que a gente assumiu como definitiva entre software e modelo. Até agora, peso era estatística e CPU era silício. Aqui peso vira circuito. Nenhum peso dessas 11 camadas foi aprendido. Cada valor foi calculado por um compilador. O comportamento de texto do Qwen continua quase idêntico, com KL de 6e-4 contra um piso de ruído de 5e-4, mas por baixo do texto existe uma máquina executando C e MicroPython de verdade e passando na suíte oficial riscv-tests.

PublicidadeAnuncie aqui336x280 / responsivo

O fato

O que foi construído é direto: um Qwen3.5-4B com uma CPU RV32IM com extensão Zba e um coprocessador de bignum acoplado aos pesos. A CPU não é plugin, não é tool externa e não é sandbox. Ela vive no próprio grafo do modelo e usa o estado Gated DeltaNet do Qwen3.5 como RAM. Código, dados, pilha de chamadas e registradores ficam guardados nesse estado recorrente. Quando o Qwen escreve um bloco de tool_call para uma função chamada calc, exatamente no formato que ele já aprendeu no treino, nada executa fora. As camadas do computador leem aquela chamada, rodam na CPU interna e o próprio modelo escreve o tool_response dígito por dígito.

O driver de demonstração, chamado RvChat, inicia a CPU carregando o firmware no estado DeltaNet logo depois do prompt e mantém os tokens de trace fora das camadas de linguagem durante o decoding. Cada token ainda sai dos pesos. Em uma L4, com um executor em Triton, o relato é de cerca de 3.200 tokens de trace por segundo. Para validar, os autores repetiram cerca de 230 mil posições de saída do computador em um modelo de referência da máquina e encontraram zero divergências. No comparativo de aritmética, com decoding ganancioso em 40 problemas por conjunto, o Qwenputer resolve com determinismo enquanto o Qwen base sem ferramentas precisa de uma instrução de sistema para fazer cada passo exato e ainda assim falha.

Como funciona: RAM no estado e CPU nos pesos

Para quem opera modelo, o truque mais interessante está na memória. O Qwen3.5 mistura atenção plena com camadas Gated DeltaNet, e cada head DeltaNet mantém uma matriz de estado atualizada a cada token pela regra delta com gate. Nas heads usadas pelo computador, o gate é travado em aberto com alfa igual a 1, então nada decai, e a força de escrita beta é 1. Cada chave é um vetor one-hot que escolhe uma única linha. Cada update substitui exatamente aquela linha pelo valor e deixa o resto intacto. Isso é um write de RAM. Um read é a query da mesma head: uma query one-hot retorna exatamente aquela linha. O resto é layout. Os bits baixos do endereço escolhem a head e os bits restantes escolhem a linha, e cada linha guarda um byte como bits. A memória fica espalhada por algumas dezenas de heads, com heads dedicadas para registradores, program counter e pilha.

Cada head de chave alimenta duas heads de valor, o que dobra a capacidade. O gate também é usado como primitiva: alfa igual a zero por um token limpa uma head inteira, que é como a tela do CHIP-8 é apagada na demo, e alfa igual a meio faz a head decair pela metade a cada passo, o que o circuito usa como contador. As escritas chegam pelo stream de tokens, então o trace é o log de execução. Um token ADDR nomeia a linha, o VAL seguinte carrega o valor e o STEP fecha a instrução. Nada disso exigiu um tipo novo de camada. É a mesma recorrência que o Qwen já usa para linguagem, reaproveitada como hardware.

Custo, latência e arquitetura na visão de quem opera

Pensa em termos de inferência. Você tem um modelo de 4B que já custa caro para servir, e agora adiciona 11 camadas que não geram linguagem, geram ciclos de CPU. Cada instrução RISC-V vira vários tokens de trace. Mesmo a 3.200 tokens por segundo, uma multiplicação com bignum ou um loop em C custa centenas ou milhares de tokens antes do primeiro dígito útil aparecer no tool_response. Comparado com uma chamada a Python no host, que responde em milissegundos e custa quase zero, o overhead é brutal. A vantagem é outra: determinismo interno, sem processo externo, sem sandbox para gerenciar, sem serialização, sem risco de escape de executor. O modelo carrega como um Qwen3_5ForCausalLM normal. O preço é pago em throughput e em contexto, porque o firmware mora no estado e o trace precisa ser isolado para não poluir a atenção de linguagem.

O que isso muda na prática

Quem ganha hoje não é quem serve chatbot. É quem pesquisa e quem avalia. Para interpretabilidade mecanicista, é a primeira prova forte de que dá para compilar lógica exata e auditável para dentro de pesos e verificar com replay total. Para evals de matemática, código e agentes, muda o jogo porque elimina a desculpa do erro de conta. Se o modelo tem uma ALU interna, sobra apenas erro de raciocínio, que fica muito mais fácil de medir. Quem perde, no curto prazo, é a ideia de que tool use resolve tudo. Tool use continua mais barato e mais rápido, mas agora ficou claro que ele era um remendo para uma deficiência arquitetural, não uma solução elegante.

  • Ação prática para esta semana: separe no seu pipeline o que é raciocínio do que é cálculo exato. Teste um fluxo onde o LLM só escreve a expressão em um formato rígido como calc com dois inteiros e um operador, e um executor mínimo fora valida e computa. Meça taxa de erro de formato, latência por chamada e custo por mil operações, e compare com a alternativa de pedir a conta direto no texto. Esse exercício mostra onde uma ALU interna faria diferença e onde tool externo continua vencendo por goleada.

Para builders de agentes, o recado é revisar prompts que pedem para o modelo fazer aritmética passo a passo no texto. Isso gasta contexto, aumenta alucinação e ainda exige parser frágil depois. Mesmo sem adotar o Qwenputer, que é experimental e pesado, vale trocar esses trechos por chamadas deterministicas estreitas, com esquema fixo e validação de tipos. O projeto só deixa explícito o que já era verdade: texto é péssimo como barramento de dados.

Mas escala ou só prova um ponto?

Aqui entra a tensão real. Uma CPU RV32IM simples já custou 11 camadas e algumas dezenas de heads só para ter kilobytes de RAM útil. O que acontece quando você quer mais memória, interrupções, ponto flutuante completo ou um sistema operacional mínimo. A conta não fecha com arquitetura atual. Cada byte custa estado DeltaNet, cada ciclo custa tokens, e tokens custam tempo e dinheiro. É engenharia brilhante, mas com economia frágil. Resolver 40 problemas de multiplicação com perfeição é ótimo em paper, mas em produção eu chamo um interpretador em 2 ms sem queimar GPU.

Tem outro ponto que me incomoda. Isso resolve a alucinação numérica ou só move o gargalo. Antes o problema era o modelo errar conta. Agora o problema vira compilar, verificar e debugar circuitos dentro de pesos, gerenciar firmware no estado, isolar trace sem vazar contexto e garantir que o modelo realmente chame a CPU em vez de alucinar o tool_response. Os autores fizeram replay de 230 mil posições com zero mismatch, o que é excelente, mas isso foi em ambiente controlado. Em conversa longa, com múltiplas chamadas, estado sujo e firmware maior, a robustez ainda precisa ser provada. E tem a questão de segurança: se peso pode ser CPU, qualquer fine-tuning ou merge pode corromper a ALU sem mudar muito o KL de texto. Como você monitora isso em CI.

Conclusão

Qwenputer prova que peso de LLM pode ser hardware compilado, com execução exata dentro do forward e sem executor externo. É caro, lento e limitado, mas muda a forma de pensar sobre o que um modelo pode garantir. Será que o futuro é menos tool use e mais silício compilado nos pesos para as operações que não podem falhar.