O silício que a IA desenhou para rodar a si mesma

openTPU é o primeiro caso sério em que agentes de IA não apenas geraram um bloco Verilog isolado, mas entregaram um acelerador de inferência completo, funcional e medido em hardware real. Eu já testei muita promessa de RTL gerado por LLM, quase sempre um contador, um UART, um exemplo de brinquedo que passa no lint e quebra no place and route. Aqui a conversa é outra. Estamos falando de um monorepo enxuto que vai do matmul em Python até os fios, com bit-exact simulator, compilador próprio, ISA documentada e uma placa PCIe Inspur YPCB-00338 com Kintex-7 xc7k480t cuspindo tokens iguais aos da simulação, bit por bit.

A tensão técnica é imediata. Se um agente consegue fechar um datapath sistólico, calibrar DDR3, orquestrar streaming e ainda rodar dez modelos modernos com pesos reais, onde fica o gargalo do design de chips? Não é mais saber escrever SystemVerilog, é saber validar, fechar timing e extrair banda de memória sem desperdiçar área. E isso muda a forma como penso sobre custo de experimentação em hardware.

PublicidadeAnuncie aqui336x280 / responsivo

O fato

O projeto openTPU nasceu de uma pergunta dupla, herdada do auto-arch-tournament: até onde agentes de IA vão em design de hardware, e eles conseguem construir o chip que roda a própria inferência? A resposta veio em forma de repositório aberto, legível de ponta a ponta. Tem o hardware em SystemVerilog, a definição do conjunto de instruções, um simulador bit-exact, uma linguagem de kernels com compilador e o software host que dirige a placa real via PCIe. É também um projeto de aprendizado, feito para quem quer entender um acelerador de IA sem se perder em 40 repositórios e 2 milhões de linhas.

Na placa, com DDR3-1066 e pico teórico de 17,1 GB por segundo em dois canais, a equipe colocou para rodar LFM2.5-230M, LFM2-2.6B, SmolLM3-3B, Phi-4-mini, Qwen3, Qwen3.5-2B e 4B, além de variantes Gemma 4 E2B e E4B. A imagem principal e698dcd roda a 133,33 MHz, com um único bitstream para todos os modelos. A build B mais recente, deploy_fused133c_79c5707a, decodifica LFM2-2.6B, SmolLM3 e Phi-4-mini de 8 a 9 por cento mais rápido, e Gemma 4 E2B cerca de 10 por cento mais rápido, operando a 91 a 94 por cento do pico de DRAM contra 82 a 87 por cento antes. Em números de parede, com streaming de logits enquanto a placa roda, o decode em 4-bit chega a 89,5 tok por segundo no dispositivo para LFM2, 24,6 para Qwen3.5, 11,07 para LFM2-2.6B e 6,69 para Phi-4-mini.

Como funciona na visão de operador

Arquitetura é onde dá para sentir a mão, humana ou artificial, no design. O coração é uma unidade matricial sistólica de quatro colunas, alimentada por um stream engine descrito em docs de forma bem direta. Nada de tensor core gigante. É um array pequeno, provavelmente escolhido para caber no Kintex-7 sem estourar roteamento, com reuso de dados pensado para prefill e com decode claramente limitado por banda de memória. Os controladores são LiteDRAM, calibrados por uma pequena CPU dentro do próprio núcleo de memória em 12 segundos no boot, sem ajuda do host. Isso elimina o MIG da Xilinx usado na imagem anterior se-cand3, simplifica o fluxo e, pelos números, mantém 82 a 85 por cento do pico DDR3 em leitura.

O stack de software é o que torna o projeto crível. Não adianta ter RTL se você não tem como programar. O openTPU tem ISA própria, simulador que bate ciclo a ciclo com a placa, linguagem de kernel e compilador que baixa o grafo para instruções da máquina, além do otpu-smi que mostra utilização e banda em tempo real. Pelo que dá para inferir do fluxo, o host faz o argmax no loop de decode padrão e o prefill dos 512 tokens de prompt é medido só no dispositivo, enquanto o decode de 64 tokens greedy soma host mais dispositivo no número wall. Quando a placa escolhe cada token sozinha, sem round-trip, Gemma 4 E2B chega a 12,73 tok por segundo, o que mostra quanto o PCIe e o host pesam mesmo em FPGA modesta.

Dois detalhes mostram maturidade de operador. Primeiro, modelos mixture-of-experts maiores que os 4 GiB da placa rodam com experts em streaming do armazenamento do host. A placa roteia cada token, calcula todos os experts e mantém slots por camada na DRAM, enquanto o host só copia os experts faltantes de um pool file. É paginação explícita de pesos, simples e eficaz para não estourar memória. Segundo, Gemma 4 expõe o tradeoff de embeddings. A E2B mantém tabelas por camada na placa, com imagens de 3,5 a 3,6 GiB, mas não cabe em int8. A E4B deixa a tabela de 2,95 GB no host e copia uma linha de 11 KB por token, com imagem de 3,96 GiB. Funciona, bate com os tokens greedy do Hugging Face em três prompts, mas o custo por token sobe. É física, não mágica.

O que isso muda na prática

Quem ganha primeiro é quem constrói. Estudante, pesquisador de arquitetura e time pequeno de silício agora tem um mapa completo para estudar, do Python ao fio, sem NDA. Dá para ler o RTL, rodar o simulador, entender por que prefill melhorou de 1,3x a 2,0x contra a imagem antiga enquanto o decode ficou dentro de 2,3 por cento, porque decode é bound por DRAM e prefill é bound por computação e orquestração. Quem perde, por enquanto, é a ideia de que design de acelerador é caixa-preta intocável. A barreira de entrada para prototipar caiu muito.

Para quem opera inferência, a lição é menos sobre trocar GPU por FPGA velha e mais sobre eficiência de banda. O openTPU prova que dá para chegar a mais de 90 por cento do pico DDR3 com controle simples e medição com contadores próprios. Se você roda LLM em edge, em cloud privada ou em hardware alternativo, esse é o número que importa. Latência de decode não vai melhorar com mais MACs, vai melhorar com menos bytes por token, melhor layout, melhor prefetch, quantização que caiba.

A ação prática que eu recomendo é direta. Clone o monorepo, rode o simulador bit-exact com um dos modelos pequenos como LFM2.5-230M, gere os tokens e compare com a referência. Depois olhe tools de qual e perf para entender a metodologia de medição e replique o teste de 64 tokens após prompt de 512. Se você tem uma Kintex-7 disponível, suba a imagem e meça device contra wall. Você vai aprender mais sobre roofline de memória em uma tarde do que em um mês lendo papers.

A tensão que fica

Aqui vem a dúvida real que não dá para ignorar. Isso escala ou só move o gargalo? Em FPGA DDR3 de 2013, 11 tok por segundo para um 2.6B e menos de 4 tok por segundo para Gemma E4B não compete com GPU, nem tenta. O feito não é performance absoluta, é autonomia de design com correção funcional. Mas autonomia sem verificação formal robusta e sem fechamento de timing em nó moderno ainda é demo cara. Agentes são bons em gerar datapath parametrizável e cola de controle, mas timing closure em 5nm, integridade de sinal, testabilidade e yield são outro jogo, com custo de tapeout que não perdoa erro.

Tem também o custo de generalização. O openTPU brilha porque o escopo foi bem contido, uma matriz pequena, um stream engine, foco em banda. Levar isso para HBM, chiplet, interconexão de alta velocidade e compilador que extrai performance de qualquer modelo é um salto de complexidade. Resolve o problema ou só prova que dá para automatizar a parte mais didática? Minha leitura de operador é que resolve metade: prova que o loop agente para RTL para bitstream para tokens funciona, mas ainda precisa de humano para arquitetura de sistema, floorplan e validação exaustiva. E tudo bem, metade já é enorme.

Conclusão

openTPU é menos sobre tok por segundo e mais sobre fechar o loop, IA que desenha o silício que roda IA, com código aberto que qualquer um pode auditar. Se agentes já entregam 94 por cento do pico de DRAM em FPGA antiga, o que acontece quando apontarmos esse mesmo loop para um alvo moderno com HBM? Será que o próximo gargalo vai ser criatividade arquitetural ou só acesso a PDK e a tapeout?