Kimi K3 em casa: a verdade sobre o hardware necessário (2.8T parâmetros)

#Kimi K3 local: o que Moonshot realmente publicou

A ficha do Hugging Face da Moonshot descreve Kimi K3 como um modelo multimodal de pesos abertos com 2,8 trilhões de parâmetros, com uma janela de contexto de um milhão de tokens. É um Mixture-of-Experts: 896 especialistas, dos quais 16 são selecionados para cada token, resultando em 104 bilhões de parâmetros ativados. Os pesos são distribuídos em MXFP4 (pesos) com ativações MXFP8, tendo sido aplicado um treinamento consciente da quantização desde a fase de fine-tuning supervisionado. O código e os pesos estão sujeitos à « Kimi K3 License »: leia esse texto antes de qualquer uso comercial, pois não é uma licença MIT ou Apache padrão. O modelo chegou ao Hugging Face por volta de 27 de julho de 2026, segundo a imprensa especializada.

Parâmetros totais / ativos

2,8 T ao todo, 104 Md ativos por token (ficha Moonshot).

Especialistas

896 especialistas, 16 selecionados por token, mais 2 especialistas compartilhados

Formato publicado

MXFP4 para os pesos, MXFP8 para as ativações. Isso não é um GGUF.

Contexto

1.048.576 tokens, com um cache KV que ocupa memória adicional à dos pesos.

Motores recomendados

vLLM, SGLang e TokenSpeed. O llama.cpp passa pelos GGUF da comunidade.

#Quanto os pesos realmente pesam

Dois valores circulam, e é preciso distingui-los. Alguns artigos estimam « cerca de 1,4 TB » multiplicando 2,8 T de parâmetros por meio byte. O tamanho medido dos arquivos é maior: Unsloth e Runpod indicam 1,56 TB para a versão nativa, porque as camadas fora dos especialistas (atenção, roteadores, especialistas compartilhados) permanecem em precisão superior. O BF16 não quantizado atingiria cerca de 5,6 TB, segundo o Runpod. A versão deste guia que anunciava 1,4 TB subestimava, portanto, o tamanho em cerca de 10%.

A tabela refuta uma ideia equivocada da versão anterior: um Q2 não é “sempre da ordem de um terabyte”. O Unsloth oferece, sim, arquivos GGUF com menos de 900 GB. Mas 594 GB ainda equivalem a quase quinze vezes a memória de uma RTX 5090 de 32 GB, e a diferença de qualidade é real: a quantização dinâmica de 1 bit só reproduz a escolha do modelo original em 78,9% dos casos no conjunto de avaliação do Unsloth. Para entender como os bits afetam a qualidade, veja nosso guia de quantização.

#O hardware: o que é recomendado, o que é possível

Moonshot não divulga uma configuração mínima na página do modelo: redireciona para as receitas vLLM, SGLang e TokenSpeed e para sua API. A referência documentada para auto-hospedagem nativa vem do Runpod: um nó com oito GPUs B300 de 288 GB cada, ou seja, cerca de 2,3 TB, ou dezesseis B200 distribuídas em dois nós. O número de «64 aceleradores ou mais» que essa página citava não está presente em nenhuma fonte primária consultada: foi removido.

Com um GGUF Unsloth, a regra apresentada na documentação deles é simples: a soma da RAM com a VRAM deve ser aproximadamente igual ao tamanho da quantização; caso contrário, o modelo funciona, mas passa a usar o disco, com execução muito mais lenta. O Unsloth também cita cerca de 20 tokens por segundo na geração quando o modelo cabe na memória das B200. É uma taxa de geração informada por um fornecedor em hardware de datacenter, não uma medida aplicável a uma máquina doméstica.

#E em um Mac? O cálculo, não a especulação

Não foi encontrada nenhuma fonte verificável para o valor de « 16 segundos por token em um MacBook Pro M1 Max » que esta página mencionava: não o apresentamos como fato. O que as fontes estabelecem é mais claro. O Kingy AI observa que o ponto de partida (checkpoint de 1,56 TB) já excedia a capacidade de memória de um Mac Studio de 512 GB, e que mesmo o arquivo de 553,2 GiB da versão de 1 bit excede a capacidade dessa máquina antes de considerar o consumo adicional de memória. Um Mac de 128 GB tem cerca de um quinto dos 610 GB recomendados.

Por outro lado, você pode estimar por si mesmo a ordem de grandeza. Se a memória não for suficiente, cada token lê novamente do SSD os especialistas que ativa: 104 bilhões de parâmetros a cerca de 4 bits, o que equivale a cerca de 50 GB lidos por token. Com um SSD que entrega 3 GB/s, obtém-se cerca de 17 segundos por token; a 7 GB/s, cerca de 7 segundos. Trata-se de um cálculo teórico de limite superior, não de uma medição, mas explica por que os relatos de execução “em disco” se expressam em segundos por token e não em tokens por segundo.

#Ollama, LM Studio, llama.cpp: o que cada ferramenta permite

Ollama

A biblioteca oficial lista uma única variante, kimi-k3:cloud: o modelo é executado nos servidores do Ollama, não na sua máquina. O comando ollama run kimi-k3:cloud serve para testar o modelo com a interface habitual, com as limitações de confidencialidade e faturamento de um serviço remoto.

LM Studio

Carrega GGUF locais. Para K3, isso exige baixar várias centenas de GB de arquivos Unsloth e dispor da memória correspondente. Em uma máquina comum, a resposta é não.

llama.cpp

É o motor para o qual os GGUF da Unsloth foram preparados, que se baseiam em uma versão derivada do llama.cpp com suporte à visão. Ele gerencia o offload dos especialistas para a CPU e os arquivos divididos em várias partes: é a opção realista para uma estação com várias centenas de GB de RAM.

vLLM e SGLang

Os dois motores recomendados pela Moonshot para um serviço multi-GPU com o formato nativo.

#As opções realistas para testar Kimi K3

1. 01
   1. A API oficial da Moonshot

   O modelo se chama kimi-k3 no platform.kimi.ai, com API compatível com OpenAI e Anthropic. É a forma mais rápida de avaliar a qualidade, com um parâmetro reasoning_effort ajustável em low, high ou max.
2. 02
   2. Ollama cloud

   ollama run kimi-k3:cloud usa seus hábitos do Ollama com inferência remota. A página da biblioteca exibe os preços por milhão de tokens: verifique-os antes de automatizar. Nosso guia sobre o Ollama Cloud detalha os limites.
3. 03
   3. Uma locação de GPU

   Alugar um nó multi-GPU por hora durante um teste, com vLLM. Faça primeiro o cálculo de rentabilidade (custo por hora dividido pela taxa sustentada de tokens por segundo), que o Runpod apresenta em sua FAQ.
4. 04
   4. Uma estação com grande quantidade de RAM

   Apenas se você já tiver 700 GB de memória: GGUF UD-IQ1_S e llama.cpp, aceitando uma qualidade reduzida e uma baixa taxa de geração.

#Ter pesos abertos não significa poder executar o modelo em casa

Pesos abertos garantem o direito de baixar, auditar, fazer ajuste fino e, conforme a licença, redistribuir. Eles não garantem que alguém possa executá-los. Um modelo de 30 bilhões de parâmetros em uma placa de 24 GB é realmente seu; um modelo de 2,8 T que só pode ser carregado por um cluster permanece, na prática, um serviço. Kimi K3 é uma boa notícia para a auditabilidade e para organizações que já possuem um cluster, sem alterar o que uma pessoa pode fazer em casa.

#Alternativas que seu hardware realmente consegue carregar

O catálogo QuelLLM estima as necessidades de memória em Q4, sem incluir o contexto: DeepSeek V4 Flash 284B aproximadamente 170 GB, GLM 5.2 753B-A40B aproximadamente 437 GB, Kimi K3 aproximadamente 1.624 GB. Para uso diário, um modelo de 30 a 70 bilhões em Q4 continua oferecendo a melhor relação entre qualidade e viabilidade.

DeepSeek V4 Flash 284B

Aproximadamente 170 GB em Q4, segundo o catálogo: possível em um Mac Studio com bastante memória ou em uma estação de trabalho. Consultar o guia dedicado.

GLM 5.2 753B-A40B

Aproximadamente 437 GB em Q4: é o porte mais próximo do K3 acessível a uma estação de trabalho bem equipada.

Kimi K2.5 e K2.7

Aproximadamente 600 GB em Q4: menores que o K3, mas ainda exigem infraestrutura de estação de trabalho.

Modelos de 30 a 70 bilhões

Em uma placa de 24 a 32 GB ou em um Mac de 64 GB: a escolha razoável para uso real. O calculador de VRAM fornece o valor exato.

#Veredito: Kimi K3 localmente, quase nunca

Pesos nativos de 1,56 TB, quantizações de 594 a 861 GB, 610 GB de memória para a menor: Kimi K3 é um modelo de servidor. Para avaliá-lo, use a API ou kimi-k3:cloud. Para um uso real em casa, escolha um modelo que caiba na sua memória com uma margem para o contexto.

#Para se aprofundar

• DeepSeek V4 Flash 284B: o primeiro modelo de ponta no Mac Studio
• GLM-5.2 local: Ollama e LM Studio
• Escolher sua quantização (Q4, Q5, Q8, FP16)
• MoE explicado: por que um 30B-A3B roda como um modelo pequeno
• Ollama Cloud: preços, avaliações e limitações
• Calculadora de VRAM

• Fonte: ficha Hugging Face do Kimi K3
• Fonte: Unsloth, Kimi K3 local
• Fonte: Perguntas e respostas técnicas do Runpod
• Fonte: biblioteca Ollama, kimi-k3