Cluster de 7 ESP32-S3 roda modelo de linguagem com quantização ternária de 1,58 bit

Um repositório publicado no GitHub por Low-Zi-Hong e destacado no Hacker News mostra um cluster de sete placas ESP32-S3 rodando, de forma distribuída, um modelo de linguagem↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → quantizado na técnica ternária BitNet (1,58 bit por peso). O projeto, batizado ESP32s3-LLM-Cluster, já soma 168 estrelas e 7 forks no GitHub e está licenciado sob MIT.

O ESP32-S3 é um microcontrolador de poucos dólares, com CPU dual-core Xtensa e, nas variantes usadas para esse tipo de projeto, alguns megabytes de PSRAM e flash. Rodar um modelo de linguagem inteiro nele, sem quantização agressiva, é inviável: os pesos simplesmente não cabem na memória. O projeto contorna isso em duas frentes: comprime cada peso a um de três valores possíveis (a técnica BitNet) e distribui as camadas do modelo entre várias placas físicas, cada uma processando um pedaço da rede.

Como o modelo é fatiado entre as placas

A arquitetura descrita no README separa o cluster em um nó mestre e seis nós de computação, ligados em cadeia (daisy-chain) por SPI de dois canais. O nó mestre não faz inferência das camadas do transformer: ele roda o tokenizador BPE, faz a busca na tabela de embeddings (empacotada em INT4, ocupando cerca de 14 MB na flash) e, ao final, o LM Head mais a amostragem greedy que decide o próximo token.

O trabalho pesado do transformer fica com os seis nós de computação, cada um responsável por um bloco de quatro camadas (o README lista Node 1 processando as camadas 0 a 3 e Node 6 fechando com as camadas 20 a 23, totalizando 24 camadas). Cada nó executa, em sequência:

• RMSNorm (calculado em FP16, escalado para FP32);
• atenção em 1,58 bit (projeções Q, K, V e O) com RoPE;
• cache de chave-valor (KV Cache) mantido em PSRAM;
• MLP em 1,58 bit (projeções Gate, Up e Down).

O estado oculto (hidden state) trafega em FP32 de um nó para o próximo pelo canal A do SPI, enquanto o canal B recebe do nó anterior. Depois que o sinal passa pelo último nó, ele retorna ao mestre, que aplica a normalização final (guardada em uma partição de 64 KB chamada fnorm) e produz o token de saída.

O que é a quantização de 1,58 bit

BitNet é a técnica de quantização ternária descrita pela Microsoft Research, que reduz cada peso da rede a apenas três valores possíveis: -1, 0 ou +1. Isso troca a multiplicação de ponto flutuante, cara em hardware limitado, por somas e subtrações simples, além de cortar drasticamente o espaço de armazenamento. O código do projeto implementa essa camada em bitlinear.cpp, com uma versão otimizada em assembly (bitlinear_forward.S) para acelerar as operações de multiplicação-acumulação (MAC) ternárias, apoiada em tabelas de consulta pré-computadas (lut_table.cpp).

O modelo em si é derivado de uma arquitetura Qwen: o arquivo que trata da atenção nos nós de computação se chama qwen_attention.cpp, e o README descreve o processo de preparação como fine-tuning por Quantization-Aware Training (QAT), no script qat_158.py. Ou seja, o autor não inventou uma arquitetura do zero: pegou um modelo Qwen já existente, na casa de 0,4 a 0,5 bilhão de parâmetros conforme as diferentes descrições do próprio repositório, e o retreinou para operar em precisão ternária antes de fatiá-lo entre as placas.

O pipeline de preparação, do lado do PC

A pasta python_tools/ do repositório concentra o trabalho que acontece antes de qualquer coisa chegar ao ESP32-S3:

1. crop_token.py reduz o vocabulário do tokenizador para 32 mil tokens, cortando o que não é necessário para caber na flash das placas;
2. crop_model_weight.py fatia a matriz de embeddings de acordo com esse vocabulário reduzido;
3. qat_158.py faz o fine-tuning com Quantization-Aware Training para adaptar os pesos à precisão ternária;
4. bit4_embedding.py empacota os embeddings em INT4;
5. pack_tokenizer_bin.py e pack_model_bin.py serializam tokenizador e camadas em arquivos .bin alinhados fisicamente às partições de cada placa.

O firmware de cada lado (mestre e nós) é construído sobre o framework ESP-IDF, com tabelas de partição (partitions.csv) próprias definindo onde ficam tokenizador, modelo e normalização final na flash de cada placa. Scripts de flash em lote (flash_*.bat) tratam da gravação simultânea nas sete unidades.

O que o material não mostra

O README não traz números de desempenho: não há tokens por segundo, latência por token ou consumo de energia medido. Também não há uma data de publicação explícita no material disponível, nem detalhes sobre qual checkpoint específico do Qwen foi usado como base antes do QAT. Para quem quiser reproduzir o projeto, o arquivo workflow.md do repositório promete o passo a passo de flashing, preparação do modelo e ligação física entre as placas, mas fica de fora do material analisado aqui.

O próprio autor cita como referência dois projetos anteriores, chamados de inspiração no README: um sobre deployment de LLM quantizado em nó único de ESP32-S3, e outro sobre arquitetura de IA distribuída em múltiplos microcontroladores. Isso indica que o ESP32s3-LLM-Cluster é parte de uma linha de experimentação que já vinha rodando na comunidade maker antes deste projeto específico consolidar tokenizador, embeddings e pipeline de sete nós num único repositório.

Por que isso importa para quem constrói

Para quem trabalha com IoT e edge computing, o interesse não está em substituir GPU por microcontrolador em produção, mas em mostrar o piso técnico do que já é possível sem nuvem, sem placa aceleradora e com hardware de poucos dólares por unidade. A combinação de quantização ternária com pipeline paralelo entre múltiplas placas baratas é uma arquitetura replicável: qualquer time que já lida com ESP32 em produtos embarcados pode ler o código de bitlinear.cpp e spi_bus.cpp como referência de como estruturar comunicação síncrona em cadeia entre microcontroladores para uma tarefa que, isoladamente, nenhum deles resolveria sozinho.

Fica em aberto, e caberia a quem for reproduzir o projeto medir, qual a latência real de ponta a ponta em uma cadeia de sete placas conectadas por SPI, e o quanto isso é viável para aplicações que exigem resposta em tempo real, versus casos de uso que toleram alguns segundos por token gerado.

Fonte: Hacker News