BitRun roda LLM 1-bit a 100T/s na CPU

Rodar LLM na CPU sem sofrer parecia bom demais

LLM de 1-bit rodando direto na CPU a 100 tokens por segundo, sem GPU, sem compilar nada, sem Docker de 10 GB. Foi assim que o BitRun apareceu e prendeu a atenção de quem vive testando modelo local no notebook. A promessa é simples e provocadora: baixar um comando, puxar um modelo ternário e conversar no terminal como se fosse um Ollama turbinado para BitNet. Para quem já perdeu uma tarde brigando com CMake, submódulo recursivo, flag de AVX2, AVX-512 ou ARM NEON, isso soa como alívio imediato. Mas também acende o alerta de operador, porque velocidade em CPU quase nunca vem de graça. Ou o modelo é muito menor, ou a precisão caiu, ou o benchmark foi medido num cenário muito específico.

Eu olho para esse tipo de ferramenta com dois olhos ao mesmo tempo. Um olho gosta da fricção zero, do binário estático que só funciona. O outro quer saber latência real, qualidade de resposta, consumo de memória e o que quebra quando você coloca carga de verdade. O BitRun tenta resolver exatamente o pedaço mais chato do BitNet.cpp da Microsoft, que é a distribuição. O núcleo técnico continua sendo ternário, com pesos em menos um, zero e mais um, sem multiplicação em ponto flutuante no caminho crítico. O empacotamento em volta é que mudou, com CLI em Go, gerenciador de modelos e servidor REST compatível com OpenAI. Vale entender onde isso ajuda e onde ainda é experimento.

O fato

O BitRun é um runner standalone e gerenciador de modelos para LLMs ternários do tipo Microsoft BitNet b1.58 e modelos de 1.58-bit, focado em inferência local em CPU no macOS, Windows e Linux. A proposta é zero-compile, zero dependência externa. Nada de toolchain C++, Python ou imagem pesada. Você instala com um script, usa bitrun pull para baixar um modelo do Hugging Face, usa bitrun run para chat interativo no terminal e usa bitrun serve para subir uma API local compatível com OpenAI. A ideia é repetir a experiência que o Ollama popularizou, mas otimizada para o mundo 1-bit.

Na prática o fluxo é direto. No macOS com Apple Silicon e no Linux x86_64 a instalação é via script shell, no Windows via PowerShell. Depois disso os comandos cobrem o ciclo todo: bitrun hardware mostra topologia da CPU e suporte a instruções vetoriais, bitrun list mostra modelos e personas baixadas, bitrun pull falcon3-1b baixa com progresso e resume, bitrun run falcon3-1b abre o chat, bitrun run falcon3-1b com um prompt entre aspas simples executa em modo one-shot. Para personalizar comportamento ele usa Modelfile, com instrução de sistema e parâmetros como temperatura e tamanho de contexto. Você cria com bitrun create gopher -f Modelfile e depois conversa com aquela persona. O servidor sobe por padrão na porta 11435, justamente para não colidir com o 11434 do Ollama, e responde no caminho /v1/chat/completions, o que permite plugar Cursor, Continue.dev, Open WebUI, LangChain ou SDK Python sem adaptador.

Como funciona na visão de quem opera

Por baixo do capô o BitRun usa um desenho desacoplado de supervisor e engine. O supervisor é em Go e cuida de CLI multiplataforma, detecção de topologia de CPU, armazenamento de artefatos com endereço por conteúdo em algo como a pasta .bitrun e supervisão HTTP. A engine é um binário nativo em C++ compilado estaticamente, sem dependência de CGO, o que dá isolamento total contra crash. Essa separação importa porque inferência em C++ costuma quebrar o processo inteiro quando algo dá errado com memória ou instrução vetorial. Aqui, se a engine cair, o supervisor continua de pé e consegue reiniciar ou reportar sem levar a CLI junto.

O ganho de velocidade vem da matemática ternária. Em vez de multiplicações caras em FP16, os kernels do BitNet.cpp trabalham com adições e subtrações sobre pesos ternários, explorando instruções vetoriais como ARM NEON com dot-product em Apple Silicon e AVX-512 em x86. A Microsoft fala em 70 a 80 por cento menos energia nesse regime, o que faz sentido para notebook com bateria, mini PC, edge e laboratório doméstico. Minha inferência técnica aqui, sem tratar como verdade absoluta, é que o número de 100T por segundo precisa ser lido com cuidado. Em Apple Silicon, esse patamar é plausível para modelos muito pequenos, com contexto curto, batch um e kernels bem afinados para 2B ou menos. Para um 2B com contexto de 4k, o throughput sustentado tende a cair bastante por causa de largura de banda de memória e atenção. Ou seja, pico de benchmark não é sessão de chat real.

Na parte de distribuição, o acerto é eliminar a compilação local. O BitNet.cpp original exige clonar submódulos, ajustar compilador, CMake e flags de CPU, o que afasta muita gente. O BitRun entrega binário pronto e detecta o melhor kernel para aquele hardware. O pull com resume ajuda quem tem internet instável, o store com hash evita duplicar peso e a camada REST evita que cada ferramenta precise de integração própria. Em termos de latência, o que eu esperaria ver na prática é time to first token baixo em prompts curtos, streaming estável no terminal e overhead pequeno do servidor Go sobre a engine nativa. O custo operacional é quase zero em infra, porque roda no hardware que você já tem, mas o custo escondido pode ser qualidade. Modelo ternário pequeno responde rápido, porém tende a perder nuance, seguir instrução complexa pior e alucinar mais que um INT4 maior.

O que vem pronto para usar

• bitrun hardware para conferir CPU, núcleos e suporte vetorial antes de culpar o modelo por lentidão
• bitrun pull e bitrun list para gerenciar pesos localmente sem depender de Docker ou Python
• bitrun run interativo e one-shot para teste rápido de prompt e persona
• bitrun serve na porta 11435 com API compatível com OpenAI para plugar no seu stack atual
• Modelfile com FROM, SYSTEM e PARAMETER para versionar persona como código

O que isso muda na prática

Quem ganha primeiro é o desenvolvedor que quer prototipar local sem GPU e sem fricção. Dá para testar assistente embarcado, CLI inteligente, automação offline, demo em notebook fraco ou agente que precisa rodar no cliente por questão de privacidade. Quem constrói com Cursor, Continue.dev ou Open WebUI ganha um backend leve que não briga com o Ollama instalado, porque a porta é diferente e o protocolo é o mesmo. Para makers e times pequenos, isso reduz o ciclo de teste de horas para minutos. Baixou, rodou, mediu, ajustou temperatura e contexto, versionou a persona num Modelfile. Esse loop curto vale ouro quando você ainda está descobrindo o caso de uso.

Quem perde, por enquanto, é quem espera substituir um modelo grande em produção só porque é rápido. Um 1B ou 2B ternário não compete com um 7B ou 8B bem quantizado em tarefa de raciocínio, código complexo ou contexto longo. Ele compete em custo, energia e disponibilidade. A ação prática que eu recomendo é bem objetiva. Primeiro rode bitrun hardware e anote o que sua CPU suporta, porque sem NEON com dot-product ou sem AVX-512 o ganho cai. Depois suba o servidor com um modelo pequeno, aponte seu cliente OpenAI para localhost na porta 11435 e rode três testes fixos: pergunta factual curta, resumo de um texto de 2 mil tokens e geração de código com restrição clara. Meça tempo até o primeiro token, tokens por segundo sustentados e taxa de erro factual. Só depois decida se aquele modelo serve para completar rascunho, classificar, extrair campo ou atender offline. Não coloque para decidir sozinho em fluxo crítico sem avaliação.

A tensão real: velocidade, qualidade e escala

Aqui está o ponto que me deixa em dúvida. Velocidade de 100 tokens por segundo impressiona no vídeo, mas operador precisa perguntar em qual modelo, com qual prompt, com qual contexto e com qual amostragem. Throughput alto com qualidade mediana só move o gargalo de lugar. Você gera rápido, mas gasta mais tempo revisando, filtrando e retratando. Em alguns casos isso compensa, como autocomplete local, pré triagem, extração simples e chat offline para tarefa fechada. Em outros não compensa, como suporte que exige precisão, código de produção ou análise com contexto grande. O ternário resolve o problema de energia e acesso, mas não resolve magicamente memória para contexto longo nem raciocínio.

Tem também a questão de escala e manutenção. O projeto se apoia em dois gigantes, llama.cpp e BitNet.cpp, e cita contribuições de volta para o upstream da Microsoft, o que é bom sinal. Ainda assim, distribuir binário estático multiplataforma cobra um preço. Cada nova arquitetura, cada bug de kernel ARM64, cada ajuste de tokenizer como o do LLaMA-3, cada suporte a MSVC no Windows vira trabalho de release. Se a comunidade não acompanhar o ritmo do upstream, o runner rápido de hoje pode ficar preso a kernels antigos amanhã. Para uso individual isso é aceitável. Para frota de edge com dezenas de máquinas, eu pensaria duas vezes antes de padronizar sem travar versão, checksum e rollback.

Conclusão

O BitRun acerta onde mais doía: tirar a compilação do caminho e deixar o BitNet testável em minutos, com CLI familiar e API local pronta. A promessa de inferência 1-bit ultrarrápida na CPU é real no mecanismo, mas o número cheio só se sustenta em cenário favorável e com modelo pequeno. Se você constrói, vale instalar, medir latência e qualidade no seu hardware e decidir com dado na mão. Afinal, velocidade sem controle de qualidade é só jeito mais rápido de errar, ou é finalmente a IA local que cabe no notebook?