SQLiteAI põe Kimi K3 de 2.78 trilhões em Mac de 64 GB
Motor em C transmite os pesos do SSD e roda o modelo completo localmente, a até 0.62 tok/s.
O WASTE é um motor de inferência em C que transmite do NVMe os pesos do Kimi K3, em vez de exigir que os 2.78 trilhões de parâmetros caibam na RAM. A SQLiteAI criou o projeto em 2026-07-28, sem dependências de runtime de terceiros. Em um MacBook Pro de 64 GB, o modelo completo roda a 0.45–0.62 tok/s. A ferramenta interessa a quem aceita baixa velocidade para executar localmente um modelo que normalmente excede a memória disponível.
O motor busca no disco apenas os especialistas usados
O Kimi K3 usa uma arquitetura mixture-of-experts. Embora tenha 2.78 trilhões de parâmetros, apenas cerca de 4% entram no cálculo de cada token. O WASTE mantém o tronco compartilhado na RAM e busca diretamente no disco os especialistas selecionados.
O contêiner organiza cada especialista em uma leitura alinhada. O motor sobrepõe essa leitura ao cálculo e usa a RAM restante como cache limitado. Um roteador de antecipação prevê quais especialistas a próxima camada precisará e inicia a leitura antes da decisão final. O roteador real ainda decide o resultado.
Os especialistas usam quantização residual vetorial de 3 bits. Os pesos compartilhados ficam em 4 ou 8 bits, porque são mais sensíveis. O Kimi K3 também usa atenção linear e um cache KV comprimido; em contexto de 4K, esse cache ocupa cerca de 0.21 GB, contra 11.25 GB na comparação apresentada pelo projeto.
O WASTE precisa de 29.06 GB para abrir o K3. No computador usado pelo README, o orçamento padrão chega a 46.25 GB e inclui um cache de especialistas de 17.56 GB. Mais cache não garante mais velocidade: 17.32 GB entregaram 0.63 tok/s, enquanto 23.32 GB derrubaram o resultado para 0.07–0.09 tok/s, porque a máquina passou a paginar.
O teste depende de NVMe rápido e recompilação
A adoção começa pelo repositório sqliteai/waste e pelo contêiner convertido do modelo, que ocupa 982 GB. O código não depende de runtime externo, e a inferência acontece na própria máquina. Na primeira execução, o usuário precisa reservar ao menos 29.06 GB de RAM e preparar-se para leituras intensas do armazenamento: um token frio do K3 busca cerca de 17 GB de especialistas.
O SSD interno usado no teste sustentou 12.78 GB/s. Um gabinete USB chegou a 0.94 GB/s. A diferença muda o resultado. O projeto recomenda guardar o contêiner no NVMe interno.
A v0.6.6, publicada em 2026-08-05, adicionou --cpus LIST na linha de comando e no servidor, além de waste_cfg.cpu_list na API e WASTE_CPUS no ambiente. Linux e Windows aceitam listas como 0-5 e 0-2,6-8; no macOS, o recurso retorna WASTE_E_UNSUPPORTED, porque o sistema não oferece a chamada usada para prender uma thread a um núcleo.
Essa versão exige recompilação contra o novo cabeçalho. O campo cpu_list entrou entre n_threads e cache_policy, então um chamador compilado com a estrutura da v0.6.5 pode ler os campos seguintes no deslocamento errado. O mesmo vale para bindings externos em ctypes ou FFI.
O projeto tinha 1.932 estrelas, 143 forks e 8 issues abertas, com último commit em 2026-08-07. A idade registrada era de 11 dias. A tração é alta para um código tão recente, mas a série 0.6.x ainda não promete ABI estável.
A licença Apache-2.0 permite usar, modificar e redistribuir o código sob seus termos. O WASTE não serve para quem precisa de respostas rápidas, tem apenas 32 GB de RAM ou usa armazenamento lento: o K3 pode abrir em uma máquina de 32 GB, mas paginará intensamente.
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.