Modelo de desenho RP2040 executa programas com precisão, mas a IA permanece no host

O modelo de desenho RP2040 gerou programas compactos para 12.670 testes de hardware, mas seu transformer de 825.344 parâmetros nunca foi executado no microcontrolador. Em vez disso, um computador host produziu bytecode de desenho e o enviou a um Raspberry Pi Pico para execução determinística.

Essa distinção define tanto o valor quanto os limites do projeto. Não se trata de mais uma alegação de que um dispositivo minúsculo pode executar localmente um modelo generativo útil. É um experimento que separa a geração neural incerta da execução exata e restrita.

O sistema desafia a rota habitual de geração de pixels. Ele pergunta se um pequeno transformer pode escrever uma descrição executável e, em seguida, entregar essa descrição a uma máquina mínima com comportamento previsível. Os resultados no hardware parecem incomumente limpos, enquanto a capacidade do modelo de compor estruturas desconhecidas permanece muito menos certa.

O modelo de desenho RP2040 separa geração e execução

O resultado central é uma divisão de trabalho, não inferência neural no dispositivo.

Segundo o repositório público do projeto, um transformer autorregressivo com 825.344 parâmetros é executado em um computador host. Ele gera cerca de 100 bytes de bytecode de desenho para cada exemplo.

Bytecode é um formato compacto de instruções interpretado por outro programa. Neste caso, ele descreve operações como mover uma caneta virtual, desenhar linhas, avaliar curvas, aplicar transformações inteiras e repetir sequências limitadas.

O host transfere esse programa para um Raspberry Pi Pico. Uma pequena máquina virtual, ou VM, executa as instruções no microcontrolador RP2040 do Pico. Em seguida, ela transmite coordenadas geométricas de volta via UART, uma interface padrão de comunicação serial.

A imagem final vem dessas coordenadas retornadas. O Pico não armazena pesos do transformer, não executa inferência neural intensiva em matrizes nem requer um runtime de tensores. Ele apenas interpreta o programa gerado.

Esse limite importa porque a expressão "modelo em um RP2040" sugeriria uma realização técnica diferente. Um modelo com 825.344 parâmetros poderia exigir vários megabytes em formatos numéricos convencionais, antes mesmo de considerar a memória de execução.

O autor do projeto evita explicitamente essa alegação. A discussão original afirma que o transformer permanece no host, enquanto o Pico armazena e executa sua saída.

O modelo de demonstração disponibilizado abrange cinco categorias: gatos, ônibus, flores, veleiros e bicicletas. Ele não é apresentado como um sistema aberto de texto para imagem.

Esse escopo restrito torna os resultados mais fáceis de interpretar. O experimento estuda representação, geração de programas e execução restrita sem alegar conhecimento visual amplo.

O modelo produz instruções em vez de uma grade de pixels coloridos. Isso cria uma interface útil entre IA probabilística e software embarcado determinístico.

Um gerador de pixels se compromete diretamente com o resultado visível. Já um gerador de programas propõe uma sequência que outro sistema pode validar, limitar, executar ou rejeitar.

Essa diferença cria a principal tensão do artigo. A execução no hardware parece exata e econômica, mas uma execução exata não garante que o programa gerado represente o desenho pretendido.

O Pico pode executar perfeitamente um programa ruim de bicicleta. Ele também pode rejeitar de forma confiável uma sequência malformada ou excessivamente longa caso a VM imponha limites adequados.

Em outras palavras, correção de execução e correção generativa são propriedades distintas. O projeto mede ambas, e seus resultados apontam em direções diferentes.

A execução exata é o resultado mais forte

O Pico correspondeu de forma consistente ao interpretador de referência, embora as medições venham dos próprios artefatos de teste do projeto.

O autor informa que 12.670 programas gerados foram executados durante uma varredura de hardware. Cada traço retornado correspondeu exatamente à VM de referência em Python.

Um traço é a geometria ordenada produzida por um programa. A correspondência exata significa que o dispositivo e a referência retornaram coordenadas idênticas, em vez de apenas produzirem imagens visualmente semelhantes.

O registro de experimentos do projeto informa igualdade com tolerância zero em todos os 12.670 traços. Ele também lista 120 de 120 programas de conformidade aprovados em comparação com uma base de referência QEMU.

Esses são resultados de primeira parte, não uma replicação independente. Ainda assim, o repositório inclui o interpretador, a estrutura de testes, os traços capturados e a documentação necessários para inspeção técnica.

O interpretador em C supostamente ocupa 1.862 bytes de flash. Esse número cobre apenas a VM, excluindo o armazenamento de bytecode e o mecanismo de transporte ao redor.

A implementação não usa RAM alocada estaticamente para o estado da VM. O uso máximo de pilha chegou a 492 bytes na configuração medida.

Com o clock do RP2040 deliberadamente reduzido para 12 MHz, a média informada foi de 7.334 ciclos por desenho. Isso corresponde a cerca de 0,611 milissegundo para os programas QuickDraw medidos.

O autor também informa 1,959 ciclos por instrução executada. Essas medições se referem ao trabalho do interpretador, não ao tempo necessário para gerar um programa no host.

Elas também excluem o tempo de transferência do host para o dispositivo e o trabalho de exibição. Os leitores não devem tratar 0,611 milissegundo como latência generativa de ponta a ponta.

O RP2040 é um microcontrolador Arm Cortex-M0+ de núcleo duplo com 264 kB de SRAM integrada. A Raspberry Pi lista uma velocidade máxima de clock de 133 MHz em sua documentação do RP2040.

O chip não possui uma unidade de ponto flutuante por hardware. Essa limitação frequentemente complica código gráfico porque curvas e transformações costumam usar coordenadas fracionárias.

Esta VM evita aritmética de ponto flutuante por meio de uma representação de ponto fixo. Ponto fixo armazena valores fracionários como inteiros escalados, produzindo resultados previsíveis entre implementações.

O avaliador de curvas aproveita contagens de passos que são potências de dois. Sob essa restrição, os coeficientes cúbicos de Bézier relevantes podem ser representados como frações binárias com um denominador conhecido.

A implementação seleciona bits fracionários suficientes para preservar esses valores durante o cálculo inteiro. Esse projeto elimina diferenças de arredondamento entre plataformas do caminho geométrico medido.

A aritmética determinística também torna a comparação incomumente rigorosa. O teste não precisa de uma pontuação de similaridade de imagem nem de uma tolerância em torno de cada vértice.

A referência e o dispositivo emitem o mesmo traço ou não. Esse resultado binário é mais fácil de auditar do que uma avaliação subjetiva de similaridade visual.

Testes físicos revelaram pelo menos uma classe de problema que a simulação no host não detectou. A documentação do projeto descreve condições de corrida na inicialização dos clocks de periféricos durante a partida bare-metal.

Essa observação sustenta a decisão de testar no silício. Um interpretador pode estar matematicamente correto enquanto sua sequência de transporte ou inicialização permanece pouco confiável em uma placa real.

As evidências atuais, ainda assim, têm limites claros. O autor não mediu energia por desenho porque a bancada de testes não possuía equipamento adequado para medição de corrente.

O repositório também não inclui o checkpoint treinado. Usuários podem executar a VM e reproduzir capturas registradas, mas a geração ao vivo pelo modelo requer um checkpoint obtido separadamente.

Essas limitações não anulam o resultado da execução. Elas definem o que avaliadores externos podem reproduzir imediatamente e o que ainda depende dos materiais do autor.

Programas oferecem controle que pixels não podem oferecer

Uma saída executável transforma o comportamento do modelo em algo que um runtime restrito pode inspecionar e controlar.

Um programa de desenho expõe operações, fluxo de controle e estrutura geométrica. Uma imagem raster expõe apenas a disposição final dos pixels.

Essa diferença importa em dispositivos pequenos. Um runtime pode impor um limite de combustível, que é um número máximo de instruções permitido antes da interrupção.

Ele também pode limitar o aninhamento de loops, a profundidade de chamadas, a profundidade de transformações, os intervalos de coordenadas e o volume de saída. Essas restrições tornam o comportamento gerado finito mesmo quando o modelo produz uma sequência defeituosa.

A VM do projeto transmite vértices em vez de armazenar um desenho completo. Isso reduz a pressão sobre a memória de trabalho e se adequa ao comportamento de um dispositivo projetado para controle em tempo real.

A abordagem se assemelha a outros sistemas que separam planejamento de execução. Uma máquina maior realiza inferência custosa, enquanto um controlador menor segue uma representação intermediária compacta.

Esse padrão já aparece em robótica, controle numérico computadorizado, plotters e interfaces embarcadas. O elemento incomum aqui é usar um transformer com menos de um milhão de parâmetros para produzir o programa intermediário.

O bytecode de desenho é especialmente adequado para o experimento. Linhas, curvas e motivos repetidos têm resultados visíveis, mas sua execução permanece mais simples do que a de uma linguagem de programação de uso geral.

Uma previsão de imagem malformada produz uma imagem pouco atraente. Um programa malformado traz questões adicionais sobre término, validade e segurança de execução.

A VM responde a algumas dessas questões com um conjunto de instruções deliberadamente restrito. Ela não oferece acesso arbitrário à memória nem serviços gerais de sistema operacional.

Isso torna o sistema mais próximo de uma linguagem específica de domínio do que de código comum gerado. Uma linguagem específica de domínio atende a uma tarefa restrita com menos operações perigosas ou ambíguas.

O resultado é um contrato restrito. O modelo propõe um desenho, enquanto o interpretador decide o que esses bytes significam sob regras fixas.

Esse contrato cria oportunidades além de esboços. Um arranjo semelhante poderia representar trajetórias de ferramentas, comandos para plotters de caneta, padrões de LEDs, animações simples ou layouts de interface limitados.

No entanto, essas aplicações exigiriam sua própria validação. Geometria exata em um Pico não comprova movimento seguro de motores nem controle confiável de máquinas físicas.

O domínio de destino também determinaria quais erros importam. Uma flor levemente malformada é inofensiva, enquanto uma trajetória malformada de atuador pode danificar equipamentos.

A ideia mais transferível do projeto é, portanto, arquitetural. A geração probabilística pode ficar fora do limite de execução confiável.

O componente embarcado pode permanecer pequeno, testável e determinístico. Ele não precisa herdar a complexidade do modelo que propôs o programa.

Essa separação também muda a forma como desenvolvedores podem depurar falhas. Eles podem inspecionar os bytes gerados, reproduzi-los em Python, comparar traços e isolar comportamentos específicos do dispositivo.

Um pipeline de pixels frequentemente oculta a estrutura dentro de ativações neurais. Um pipeline de programas deixa um artefato com significado operacional explícito.

Esse artefato pode ser registrado e versionado. Também pode ser verificado em relação a regras conhecidas antes que um dispositivo o receba.

Para equipes de engenharia, isso se assemelha mais a um pipeline de compilação do que a um gerador de imagens. O modelo atua como uma interface inicial incerta, enquanto a VM atua como uma interface final de execução rigorosa.

A analogia não deve ser levada longe demais. Compiladores tradicionais traduzem texto-fonte bem definido, enquanto este transformer amostra programas a partir de uma distribuição aprendida.

Ainda assim, esse limite é valioso. Ele dá a um componente convencional de software autoridade sobre o que a saída gerada pode fazer.

A geração de programas por modelos pequenos ainda falha na composição

O interpretador executa com exatidão, mas o transformer não gera de forma confiável relações exatas e desconhecidas.

Os experimentos do projeto mostram que uma baixa perda de predição não produz automaticamente programas amostrados confiáveis. Essa lacuna é o principal motivo para tratar o trabalho como pesquisa, e não como um sistema concluído.

O modelo autorregressivo plano de referência relata uma perda de teste convergida de 489,2 bits por desenho. A perda de teste mede a incerteza preditiva, não se um desenho amostrado satisfaz uma relação geométrica desejada.

O autor testou várias representações sob o mesmo orçamento geral de parâmetros. Elas incluíam bytes, bits individuais, tokens tipados e deltas relativos de coordenadas.

Em um corpus de programas sintéticos, a representação em bits teve desempenho aproximadamente igual ao de bytes. A diferença relatada foi de menos 0,67 bits por desenho, com incerteza de mais ou menos 0,77 bits.

O resultado mudou em esboços humanos extraídos dos dados Quick, Draw do Google. Nesse caso, a modelagem em nível de bits incorreu em uma penalidade relatada de 11,58 bits por desenho, com incerteza de mais ou menos 0,60 bits.

Os bits também ampliaram as sequências de avaliação por um fator de oito. O experimento processou 254 milhões de tokens de bits, em comparação com 32 milhões de tokens de bytes.

O tempo de avaliação relatado passou de quatro minutos para bytes a 48 minutos para bits. Isso representa uma desaceleração superior a oito vezes na configuração documentada.

O contraste enfraquece qualquer alegação simples de que um vocabulário menor sempre ajuda um modelo pequeno. Um alfabeto de dois símbolos reduz os custos de embedding, mas obriga a rede a recuperar limites de bytes e a estrutura dos campos.

Aparentemente, padrões sintéticos tornaram essa recuperação administrável. Esboços humanos mais variados não produziram o mesmo resultado.

Tokens tipados introduziram outra troca. Eles vinculam opcodes e papéis de operandos de forma mais explícita, mas seu vocabulário maior consome uma parcela substancial de um orçamento pequeno de parâmetros.

Em um modelo amplo, a tabela de embeddings ocupava 22 por cento de todos os parâmetros. Essa configuração teve desempenho 4,87 bits por desenho pior do que o braço de comparação.

Um modelo profundo e estreito absorveu o custo do vocabulário de forma mais eficaz. Isso sugere que representação e arquitetura interagem fortemente em escala inferior a um milhão de parâmetros.

As falhas mais reveladoras envolveram geometria repetida. O modelo aprendeu repetições previsíveis dentro do intervalo presente durante o treinamento.

Sua surpresa caiu 74 por cento ao encontrar a segunda cópia de um motivo conhecido. Uma métrica de recuperação alcançou 0,807 em uma configuração relatada.

Ainda assim, o desempenho colapsou na quinta cópia, exatamente uma repetição além da contagem máxima de treinamento. O modelo pareceu aprender uma distribuição de contagens, e não uma regra abstrata de loop.

O projeto também testou compatibilidade geométrica sob teacher forcing. O teacher forcing avalia o próximo elemento correto após fornecer a sequência anterior verdadeira.

Nessa configuração, continuações compatíveis receberam uma forte vantagem de 4,28 bits por byte-alvo. O nível de significância corrigido relatado foi de 0,001.

A amostragem livre produziu um resultado muito diferente. A conclusão exata teve sucesso em apenas cerca de um por cento das formas compostas testadas.

O sucesso em casos mais simples de etapas planas variou de sete a 13 por cento. O modelo conseguia reconhecer uma continuação compatível quando recebia o contexto, mas raramente construía sozinho toda a continuação.

Essa desconexão é central na modelagem generativa contemporânea. A preferência em nível de token pode parecer convincente enquanto pequenos erros locais se acumulam durante a amostragem autônoma.

Cada saída amostrada se torna parte do contexto da próxima predição. Uma coordenada, opcode ou decisão de comprimento incorreta pode afastar a sequência das condições encontradas durante o treinamento.

O RP2040 não consegue corrigir essa falha semântica. Ele pode executar o programa resultante com exatidão, mas a execução exata preserva o erro.

O planejamento hierárquico corrige melhor o comprimento do que a verossimilhança

Adicionar estrutura explícita melhorou a terminação, mas tornou os desenhos menos prováveis segundo a métrica principal de perda do projeto.

O autor comparou o transformer plano com designs hierárquicos sob o mesmo orçamento de 825.344 parâmetros. Esses sistemas primeiro previam resumos dos traços e, depois, geravam bytecode detalhado para cada traço.

Um planejador usava autorregressão. Outro usava difusão, que converte gradualmente ruído em uma predição estruturada por meio de etapas repetidas de remoção de ruído.

Ambas as variantes hierárquicas perderam por aproximadamente 40 a 55 bits por desenho em relação ao modelo plano. A penalidade exata variou conforme o tipo de planejador e o orçamento computacional.

Portanto, o experimento rejeitou a hipótese de que o planejamento hierárquico melhoraria a verossimilhança em escala equivalente. Uma estrutura mais explícita trouxe um custo de modelagem mensurável.

Ainda assim, os planejadores controlaram o comprimento da saída com mais precisão. Seu erro de distribuição de comprimento variou de 1,8 a 3,5 bytes, dependendo da configuração.

A diferença correspondente do modelo plano variou de 7,0 a 13,6 bytes. Era mais provável que ele parasse prematuramente ou continuasse até o comprimento máximo permitido.

Isso não é um detalhe menor de implementação. Programas gerados precisam terminar em limites sensatos antes de poderem se tornar comandos úteis.

Um modelo com melhor verossimilhança média ainda pode produzir amostras inconvenientes se atribuir probabilidade excessiva à terminação antecipada. Também pode gerar caudas longas e repetitivas.

A hierarquia separou a contagem de traços da construção local de cada traço. Essa decisão explícita melhorou a distribuição dos comprimentos gerados, mesmo com a queda na verossimilhança total.

A difusão não ofereceu uma vantagem clara sobre um planejador autorregressivo na representação de resumo compartilhada. O ganho de terminação veio da hierarquia, e não da remoção de ruído.

Experimentos posteriores com o conjunto de instruções produziram um padrão semelhante. Operações explícitas de repetição e transformação proporcionaram compressão direta limitada porque o modelo já previa geometria repetida com baixa surpresa.

No entanto, sequências mais curtas melhoraram o uso do contexto e a terminação. Os erros relatados de comprimento gerado caíram para uma faixa de nove a 11 por cento.

Modelos planos comparáveis apresentaram erros entre 41 e 112 por cento. Essas são medições experimentais de primeira parte, mas ilustram uma tensão de design relevante.

Uma representação pode ajudar a geração sem vencer na perda de teste convencional. Da mesma forma, uma perda menor não garante programas bem-formados durante a amostragem.

Essa tensão deve orientar avaliações futuras. Pesquisadores precisam de métricas para validade, conclusão relacional exata, terminação, novidade e comportamento de execução.

A qualidade visual continua relevante, mas não pode existir isoladamente. Dois desenhos podem parecer semelhantes enquanto seus programas diferem substancialmente em comprimento, estrutura ou reutilização.

A memorização é outra questão não resolvida. Um modelo pequeno pode reproduzir motivos conhecidos sem aprender as transformações que os geram.

O repositório documenta controles para posição, proximidade, frequência e conjuntos de coordenadas. Essas verificações fortalecem o experimento relacional, mas não resolvem a novidade em todo o corpus de treinamento.

Uma versão mais robusta incluiria checkpoints, manifestos de treinamento, amostras geradas, análises de vizinhos mais próximos e scripts repetíveis de ponta a ponta.

Múltiplas seeds independentes de treinamento também esclareceriam quais comportamentos sobrevivem a mudanças de inicialização. Alguns resultados de repetição fora de distribuição já divergiram de modo perceptível entre as seeds.

O projeto atual relata resultados negativos em vez de ocultá-los. Isso é útil porque as falhas identificam onde modelos compactos deixam de se comportar como raciocinadores simbólicos.

O que deve ser verificado a seguir

O próximo marco não é uma galeria maior; é evidência de que relações explícitas melhoram a geração de programas desconhecidos.

A direção atual do projeto adiciona uma ação de copiar ou emitir. O modelo pode produzir bytes comuns ou referir-se a um trecho-fonte anterior com uma transformação afim.

Uma transformação afim pode transladar, rotacionar, refletir ou redimensionar a geometria, preservando linhas retas. Nesse sistema, as operações suportadas continuariam baseadas em inteiros e executáveis pelo estilo existente de VM.

Essa proposta mira diretamente a lacuna do teacher forcing. O modelo já parece sensível a contexto relacional compatível, mas a amostragem livre raramente conclui essa relação com exatidão.

Uma ação explícita pode reduzir o número de decisões separadas necessárias para reproduzir um motivo transformado. Uma relação correta poderia substituir muitas predições frágeis de coordenadas.

O primeiro sinal a observar é o desempenho em combinações desconhecidas. O modelo deve gerar relações exatas que foram excluídas do treinamento, e não apenas comprimir formas repetidas conhecidas.

A avaliação deve comparar emissão plana com o comportamento de copiar ou emitir sob orçamentos equivalentes de parâmetros e treinamento. O sucesso exato em geração livre importa mais do que apenas a preferência sob teacher forcing.

Se a conclusão relacional desconhecida subir de forma material acima do nível relatado de um por cento, o mecanismo ganha credibilidade. Se apenas a verossimilhança melhorar, o problema central de geração continuará.

O segundo sinal é a reprodução independente da varredura de hardware. O projeto fornece código-fonte e artefatos capturados, mas atualmente não inclui o checkpoint do modelo.

Um desenvolvedor externo deve ser capaz de reconstruir o interpretador, executar a suíte de conformidade, enviar programas gerados a um Pico e reproduzir rastros idênticos em bits.

Esse processo deve informar configurações do compilador, configuração de clock, overhead de transporte e contabilidade completa de memória. Deve distinguir o flash do interpretador do tamanho total do firmware.

Uma reprodução bem-sucedida fortaleceria a alegação de execução. Uma divergência ajudaria a identificar se o resultado depende da toolchain, da revisão da placa ou de detalhes de configuração não documentados.

O terceiro sinal é uma medição de recursos de ponta a ponta. O valor atual de 0,611 milissegundo cobre a execução da VM a 12 MHz, não a inferência no host ou a transferência serial.

Uma demonstração prática deve separar tempo de geração, tempo de validação, tempo de transferência, tempo de execução e tempo de renderização. Medições de energia também esclareceriam o custo da etapa embarcada.

Essas medições não transformariam o projeto em IA no dispositivo. Elas mostrariam se a arquitetura dividida oferece uma troca útil em termos de sistemas.

A lição maior já parece crível, mesmo antes desses testes. Modelos generativos pequenos podem produzir representações intermediárias executáveis, enquanto runtimes determinísticos minúsculos impõem regras operacionais restritas.

O que permanece incerto é se o modelo consegue gerar a estrutura correta fora de combinações conhecidas. A exatidão do hardware resolve apenas a última etapa desse problema.

Portanto, desenvolvedores que avaliam o modelo de desenho para RP2040 devem fazer duas perguntas separadas. O Pico executa cada instrução válida com exatidão, e o transformer escreve de forma confiável o programa pretendido?

As evidências disponíveis dão uma forte resposta de primeira parte à primeira pergunta. Elas oferecem uma resposta muito mais cautelosa à segunda.

Acompanhe o experimento de copiar ou emitir, o lançamento de checkpoints reproduzíveis e uma execução independente no Pico. Esses três testes determinarão se isso se torna um padrão de design reutilizável ou permanece um protótipo de pesquisa instrutivo.