OpenTPU: um acelerador de IA open source feito por IA

Uma IA ajudou a desenhar o chip que roda IA. É basicamente isso que o OpenTPU promete: um acelerador de IA open source, inspirado na TPU do Google, com o design de hardware desenvolvido por modelos de linguagem. O repositório chegou ao topo de discussões de dev esta semana, e não à toa. A frase tem cara de piada recursiva, mas o projeto é real e o código está lá para quem quiser abrir.

Eu não sou engenheiro de hardware. Escrevo TypeScript, React e SQL o dia todo. Justamente por isso achei o projeto interessante: ele mostra até onde a IA consegue ir fora da zona confortável do CRUD, e onde ela ainda precisa de alguém olhando por cima.

O que é o OpenTPU, afinal?

TPU é a sigla de Tensor Processing Unit. É o chip que o Google criou para acelerar redes neurais. A primeira geração, descrita num paper de 2017, tinha uma matriz de 256 por 256 unidades de multiplicação e soma trabalhando com inteiros de 8 bits. Ela não faz nada além disso, só que faz isso muito rápido.

O truque se chama systolic array. Imagine uma grade de células pequenas. Cada uma multiplica dois números, soma com o que recebeu do vizinho e passa o resultado adiante. Os dados "pulsam" pela grade como sangue num coração, daí o nome. No fim, sai uma multiplicação de matrizes inteira, que é o que uma rede neural faz quase o tempo todo.

O OpenTPU segue essa ideia. É um design de hardware descrito em código (HDL), pensado para ser simulado e, em teoria, sintetizado num FPGA. Não é um chip que você compra. É uma planta baixa aberta.

Um detalhe para não confundir: já existia um OpenTPU acadêmico, da UC Santa Barbara, de 2017, escrito em PyRTL. O projeto desta semana é outro, do usuário FeSens no GitHub. Mesmo nome, mesma inspiração, origem diferente.

Como uma IA escreve hardware?

Do mesmo jeito que escreve o seu componente React: gerando texto. A diferença é que esse texto descreve fios, registradores e ciclos de clock, e não divs.

Para você ter uma ideia do formato, uma célula de multiplicar e acumular em Verilog fica mais ou menos assim (exemplo meu, simplificado, não é o código do repositório):

module mac_cell (
  input  wire        clk,
  input  wire [7:0]  a_in, b_in,
  output reg  [7:0]  a_out, b_out,
  output reg  [31:0] acc
);
  always @(posedge clk) begin
    acc   <= acc + a_in * b_in;
    a_out <= a_in;  // passa pro vizinho da direita
    b_out <= b_in;  // passa pro vizinho de baixo
  end
endmodule

São poucas linhas. Um modelo de linguagem escreve isso sem suar. O desafio não é a célula. É colocar milhares delas lado a lado, sincronizar a entrada dos dados com o atraso certo, gerenciar memória, controlar o fluxo de instruções e garantir que nada saia um ciclo atrasado.

Em software, um erro de um ciclo é um bug que você corrige no próximo deploy. Em hardware, depois que vira silício, é um bug que você grava na pedra.

Por que isso importa para quem não mexe com chip?

Porque o gargalo mudou de lugar, e isso vale para o seu código também.

Escrever HDL sempre foi um nicho caro. Pouca gente sabe, as ferramentas são hostis e o ciclo de feedback é lento. Se um modelo consegue tirar do papel um acelerador funcional, nem que seja simples, a barreira de entrada cai muito. Estudante, hobbista e startup pequena passam a ter um ponto de partida que antes custava meses de especialista.

Mas repare no que sobra para o humano. A IA gera o design. Alguém precisa provar que ele funciona.

Gerar código ficou barato. Provar que ele está certo continua caro.

Em hardware isso é levado a sério há décadas. Equipes de chip costumam gastar mais esforço em verificação do que em design. Testbench, simulação ciclo a ciclo, comparação com um modelo de referência em software. É exatamente o tipo de disciplina que a gente, no mundo web, trata como opcional.

O que muda no seu fluxo de trabalho

O OpenTPU é um ótimo espelho para o jeito como a gente usa IA no dia a dia. O padrão que funciona em hardware é o mesmo que funciona em qualquer stack:

• Tenha um modelo de referência. Em hardware, você compara a saída do chip com uma multiplicação de matrizes feita em NumPy. No seu projeto, isso é o teste que diz o que "certo" significa antes da IA escrever qualquer coisa.
• Teste o comportamento, não a aparência. Código gerado por IA costuma parecer correto. Parecer não conta.
• Diminua o raio de explosão. Uma célula de cada vez, um módulo de cada vez. Pedir o sistema inteiro num prompt só é pedir para depurar o sistema inteiro depois.

Na prática, o teste de referência é algo tão simples quanto isto:

import { expect, test } from 'bun:test'

test('saída do acelerador bate com a referência', () => {
  const a = randomMatrix(4, 4)
  const b = randomMatrix(4, 4)
  expect(simulate(a, b)).toEqual(matmul(a, b))
})

O simulate pode ter sido escrito por você, por um modelo ou por um estagiário às três da manhã. O teste não liga. É por isso que ele vale mais que o código.

Dá para usar o OpenTPU de verdade?

Depende do que você chama de "usar". Para rodar o seu LLM em produção, não. Uma GPU de prateleira ou uma instância na nuvem vai continuar ganhando por uma distância enorme, e isso não é demérito do projeto. Chips comerciais têm anos de otimização, processos de fabricação de ponta e times inteiros por trás.

Para aprender, sim, e muito. Se você sempre quis entender por que multiplicação de matrizes domina o custo de IA, ler um design pequeno e aberto ensina mais do que dez threads explicando "como funciona a TPU". Você vê o dado entrando, andando pela grade e saindo.

Se quiser explorar, meu roteiro seria este:

1. Clonar o repositório e ler o README com calma.
2. Encontrar a célula básica do systolic array e entender os sinais de entrada e saída.
3. Rodar a simulação ou os testes que o projeto oferecer e olhar as formas de onda.
4. Quebrar algo de propósito, tipo atrasar um sinal, e ver o resultado sair errado.

O passo 4 é o mais valioso. Você só entende um sistema de verdade depois de vê-lo falhar.

Um aviso honesto: não auditei o design linha por linha, e projetos escritos com IA merecem uma dose extra de ceticismo. Leia os testes antes de confiar no que o README diz. Isso vale para este e para qualquer outro.

A parte que ninguém gosta de ouvir

Tem uma tentação de ler "acelerador de IA open source feito por IA" e concluir que engenheiro de hardware virou profissão em extinção. Eu acho o contrário.

O projeto só faz sentido porque existe um jeito objetivo de dizer se ele está certo. Hardware tem simulação, tem modelo de referência, tem métricas duras. A IA brilha exatamente onde o feedback é rápido e binário: passou ou não passou. Onde falta esse chão, ela gera coisas bonitas e erradas com muita confiança. Igual a um dev júnior empolgado, só que digitando bem mais rápido.

Então a habilidade que fica mais valiosa não é escrever Verilog nem escrever TypeScript. É saber especificar o que "certo" significa e construir a rede de testes que segura o resto.

Minha opinião: o OpenTPU não vai mudar o mercado de chips. Vai mudar a quantidade de gente que se arrisca a entender um. E é por isso que open source continua sendo o melhor laboratório que a gente tem para testar até onde a IA vai. Se você curte ver experimento virar coisa funcionando, dá uma olhada no que ando construindo nos meus projetos.

Uma IA ajudou a desenhar o chip que roda IA. E o código está aberto no GitHub.

O OpenTPU é um acelerador inspirado na TPU do Google, com o design de hardware escrito por modelos de linguagem.

Não sou engenheiro de hardware, mas o projeto me ensinou uma coisa que vale para qualquer stack: gerar código ficou barato, provar que ele está certo continua caro.

A IA brilha onde o feedback é objetivo, quando o teste passa ou não passa. Sem esse chão, ela entrega coisas bonitas e erradas com muita confiança.

A habilidade que mais vale agora não é escrever Verilog nem TypeScript. É definir o que "certo" significa e montar os testes que seguram o resto.

Escrevi mais sobre isso no blog. Se o assunto te interessa, o link está nos comentários.

#InteligenciaArtificial #OpenSource #Hardware #DesenvolvimentoDeSoftware #Testes