WASTE roda Kimi K3 de 2.78 trilhões em MacBook de 64 GB
Motor em C transmite pesos pelo SSD e mantém o modelo completo fora da RAM.
Quem tenta abrir o Kimi K3 em um computador comum esbarra em 1.42 TB de pesos. O projeto sqliteai/waste resolve esse gargalo ao transmitir os pesos ativados pelo NVMe, em vez de manter o modelo inteiro na RAM. Criado em 2026-07-28, o motor roda o modelo completo em um MacBook Pro de 64 GB a cerca de 0.6 tokens por segundo. Serve para quem aceita trocar velocidade por inferência local de um modelo de 2.78 trilhões de parâmetros.
O motor deixa os especialistas no SSD
O WASTE é um motor de inferência embutido, escrito em C e sem dependências de runtime de terceiros. Ele mantém na memória o tronco compartilhado do Kimi K3, lê do disco apenas os especialistas escolhidos e transforma a RAM restante em um cache limitado. O projeto não envia a inferência para um serviço externo.
O Kimi K3 usa uma arquitetura mixture-of-experts: só cerca de 4% dos parâmetros ficam ativos em cada token. O WASTE organiza o contêiner para que cada especialista exija uma leitura alinhada, sobrepõe essas leituras ao processamento e usa um roteador antecipado para buscar os especialistas da camada seguinte. O roteador real continua decidindo o resultado.
A quantização usa vetores residuais de 3 bits nos especialistas. Os pesos compartilhados, mais sensíveis, ficam em 4 ou 8 bits. Em contexto de 4K, o cache KV comprimido ocupa cerca de 0.21 GB, contra 11.25 GB no modelo sem esse desenho; abrir o Kimi K3 exige 29.06 GB, segundo o README.
A adoção começa pelo código-fonte: o usuário instala um compilador compatível com o projeto, clona o repositório, entra na pasta waste, executa make e depois make check. O primeiro comando cria o executável waste e a biblioteca libwaste.a; o segundo testa o motor com um modelo sintético e não baixa os pesos. O teste é pequeno.
Para usar o Kimi K3, o caminho mais curto baixa o contêiner já convertido por BitTorrent. O arquivo ocupa 982 GB, enquanto os pesos publicados ocupam 1.42 TB, e o cliente verifica as partes com os hashes do torrent. Quem converter os pesos precisa reservar o armazenamento temporário: a conversão leva 4.7 horas e, sem recuperar os fragmentos de origem, exige 1.42 TB de staging ao lado do contêiner.
A versão v0.6.5 adiciona tools/convert.py --reclaim {off,dry,on} para apagar cada fragmento depois do último uso. Com isso, o processo pode trabalhar com um contêiner e os fragmentos ainda pendentes, mas a opção vem desligada, não pode ser desfeita e obriga o usuário a baixar novamente os arquivos apagados. O projeto agora testa uma camada antes de converter o restante, porque a verificação contra a origem desaparece após a recuperação.
Projeto jovem, com custo alto de armazenamento
O repositório tinha 1.686 estrelas, 130 forks e 4 issues abertas na última medição, apenas 7 dias depois da criação. O último commit ocorreu em 2026-08-04, mesma data da versão v0.6.5. A tração é grande para um projeto tão novo, mas esses números ainda não mostram maturidade operacional.
A licença Apache-2.0 permite usar, modificar e redistribuir o código, inclusive em produtos, desde que os termos e avisos exigidos pela licença acompanhem a distribuição. A ferramenta não serve para quem precisa de respostas rápidas, tem pouco espaço em disco ou não aceita baixar um contêiner de 982 GB. Ela também não elimina o custo da máquina: o teste divulgado usa um MacBook Pro de 64 GB com M5 Pro e entrega cerca de 0.6 tokens por segundo.
Fontes
Como fazemos: nossa equipe monitora diariamente os repositórios de código aberto em maior alta e produz esta cobertura com apoio de modelos de linguagem, sempre a partir de dados verificados na fonte primária — repositório, documentação oficial e ranking público. Os números de estrelas e a posição no ranking refletem o momento da coleta. Entenda o método.