Executar o Kimi K3 usando 29 GB de RAM a 0,50 tok/s

Um novo mecanismo open source afirma executar localmente o modelo Kimi K3 completo, com 2,78T de parâmetros, em um laptop usando cerca de 29 GB de RAM ao transmitir a maior parte dos pesos a partir de SSD, alcançando aproximadamente 0,5 tokens por segundo. Os comentaristas se dividem sobre sua praticidade nessa velocidade e custo energético, mas o veem como uma prova interessante do que é tecnicamente possível para inferência local de LLMs de alto nível. Grande parte do debate gira em torno do uso intenso de código e documentação gerados por IA, das compensações de quantização em relação a modelos “puros” e de se projetos assim priorizam artesanato, clareza e usabilidade de longo prazo.

Conceito do projeto e desempenho

  • A ferramenta executa o Kimi K3 completo, com 2,78T de parâmetros, em hardware comum ao transmitir a maior parte dos pesos a partir de SSD, usando apenas ~29 GB de RAM para contexto de 4k.
  • A taxa de transferência é de cerca de 0,5 tokens/segundo; alguns veem isso principalmente como uma prova de conceito, e não algo prático hoje.
  • No macOS, relatou-se que ARM NEON foi mais rápido que Metal para este projeto.

Usos práticos de um K3 a 0,5 tok/s

  • Muitos consideram 0,5 tok/s inutilizável para trabalho interativo, até mesmo para fluxos de trabalho no nível de e-mail.
  • Outros sugerem tarefas em lote durante a noite ou ao longo de várias horas: revisão de código, análise de projetos, resumos de reuniões ou de semanas de trabalho.
  • Há debate sobre quanto “pensamento” um modelo pode fazer nessa taxa; um comentarista observa que os modelos podem usar dezenas de milhares de tokens internos para produzir respostas curtas.

Armazenamento, memória e design do sistema

  • A discussão contrasta um mecanismo personalizado de streaming com abordagens baseadas em mmap, como o llama.cpp.
  • Alguns afirmam que prefetching manual e cache podem superar significativamente o paging genérico do sistema operacional.
  • Há preocupações com swap: vários argumentam para desativá-lo totalmente a fim de evitar desgaste do SSD e desempenho ruim; outros esclarecem que mmap somente de leitura dos pesos não prejudica a durabilidade do SSD.

Quantização e fidelidade do modelo

  • Este mecanismo usa uma variante residual re-quantizada de 3 bits, e não o K3 “puro”.
  • Outro projeto (deltafin) é citado como executando o K3 inalterado, mas com largura de banda por token maior (≈25,8 GB vs ≈17 GB).
  • Um comentarista chama o README de confuso ou autocontraditório sobre se o modelo é realmente de “precisão nativa”; de modo geral, o impacto na precisão e na qualidade é considerado incerto.

Custo e eficiência energética

  • Estimativa aproximada de custo: ~$5 por milhão de tokens a 42W e $0,20/kWh.
  • Alguns comparam isso desfavoravelmente com clusters modernos de GPU (ordens de grandeza mais tokens por Wh), mas observam que GPUs têm alto custo inicial.
  • A discussão sobre solar/PV gira em torno de se a energia autoconsumida ainda deve ser tratada como um custo de oportunidade real.

Qualidade da documentação e autoria por LLM

  • Um grande subthread critica o README gerado por LLM como verboso, opaco e excessivamente voltado para o próprio interior.
  • Outros defendem documentação assistida por LLM como melhor do que nenhuma documentação, mas concordam que ela deve ser editada para maior clareza.
  • Há um debate mais amplo sobre usar LLMs para código, commits e docs: alguns veem isso como “lazy slop”, outros como colaboração eficiente se o código for revisado.

Licenciamento, branding e confiança

  • Alguns desconfiam da empresa devido a licenças não open source no passado e à confusão percebida com o SQLite.
  • A empresa responde que tem os direitos sobre o nome e que este projeto permanecerá sob uma licença permissiva.

Esforços relacionados e perspectiva

  • O thread cataloga múltiplos esforços quase simultâneos de self-hosting do Kimi K3: streaming apenas em CPU, GPUs de consumo e variantes GGUF comprimidas.
  • Muitos veem este projeto como um passo inicial e impraticável rumo a uma execução local eventualmente viável de modelos muito grandes.