Avançado 18 minllama.cpp

Kimi K2 local: 1 trilhão de parâmetros MoE em soi

Executar o Kimi K2 localmente com llama.cpp significa executar um modelo MoE com um trilhão de parâmetros em uma estação de trabalho pessoal. Essa façanha se deve a dois fatores: apenas 32 bilhões de parâmetros estão ativos por token (o restante fica inativo), e o llama.cpp consegue deixar os pesos inativos no SSD via mmap. Este guia detalha a configuração de hardware, a quantização Q2_K_S, o offload em disco e os números reais que se pode esperar.

Por Mohamed Meguedmi·Atualização 2026-06-05·Testado no Windows, macOS e Linux

#Por que considerar rodar o Kimi K2 localmente

Kimi K2 é o modelo principal da Moonshot AI, publicado com pesos abertos (Modified MIT) com uma arquitetura MoE (Mixture of Experts) de 1 trilhão de parâmetros totais e cerca de 32B ativos por token. Nos benchmarks de raciocínio e código, ele compete na mesma liga dos modelos de fronteira fechados, e seu longo contexto (128k tokens anunciados) o torna um candidato sério para análise documental em massa.

Executar um modelo desse tamanho localmente era, há 18 meses, um sonho. Três evoluções mudaram a realidade: a generalização de memória DDR5 de grande capacidade (192-384 GB por algumas centenas de euros), os SSD NVMe Gen 4 capazes de entregar 7 GB/s em leitura sequencial, e o trabalho da equipe llama.cpp com quantizações muito agressivas do tipo Q2_K_S e IQ1_M.

i
Não é em tempo real, mas é utilizável
Vamos ser claros: a 2–6 tokens/s, o Kimi K2 executado localmente não é um chatbot interativo. É um modelo que consultamos em lote, deixamos processar um contexto longo e usamos quando a qualidade da resposta importa mais do que a latência.

#Entender o MoE 1T / 32B ativos

O kit IA Local

Seu ChatGPT privado e gratuito na sua máquina em 1 hora — LM Studio, Ollama, Open WebUI, seus documentos, sem nuvem.

  • Espaço online vitalício
  • PDF + arquivos
  • Atualizações vitalícias
O kit IA Local →ou todos os kits vitalícios — 49 € →

A arquitetura MoE substitui os blocos FFN densos por uma camada de especialistas (geralmente 256+) entre os quais um roteador seleciona 8 a 12 por token. No cálculo, apenas os parâmetros dos especialistas escolhidos são tratados — por isso os ~32B «ativos». No entanto, na memória, todos os especialistas devem ser acessíveis, caso contrário o roteador perde acesso a 95% do modelo.

Parâmetros totais
≈ 1 000 bilhões (1T). É o que fica armazenado na RAM ou em disco.
Parâmetros ativos por token
≈ 32 bilhões. É isso que determina o cálculo e a velocidade.
Especialistas por camada
Várias centenas, das quais um número fixo de especialistas é roteado por token (top-k routing).
Camadas compartilhadas (atenção)
Sempre ativas. Elas representam a maior parte do consumo de memória quando o contexto é curto.
Cache KV
Cresce linearmente com o contexto. Em 128k, o KV pode ultrapassar 30 GB mesmo quantizado.
→
Por que o MoE cabe onde um modelo denso de 1T nunca caberia
Um modelo denso com 1T de parâmetros exigiria aproximadamente 2 TB em FP16 e aproximadamente 250 GB mesmo em Q2. Com qualidade equivalente, um MoE 1T / 32B ativos pode rodar com 200–250 GB de memória usando quantização agressiva, e a maior parte dessa memória é lida, não escrita — daí a viabilidade do mmap em SSD.

#Estimativa de memória necessária

O cálculo de memória para um MoE 1T se divide em três componentes distintos. Entender essa divisão é essencial antes de investir na RAM ou no SSD.

Pesos do modelo (quantizados)
Q2_K_S ≈ 245 GB, Q3_K_S ≈ 320 GB, Q4_K_M ≈ 480 GB, Q8_0 ≈ 1 TB. É o componente que mais ocupa memória e o mais compressível.
Cache KV (contexto)
Considerar ~0,25 MB por token em FP16, ~0,12 MB em Q8. Ou seja, 32 GB para 128k tokens em Q8. Configurável via --cache-type-k/-v.
Buffers de ativações
Alguns GB por GPU para cálculos intermediários. Marginal, mas não esquecer em GPUs de 24 GB.
!
RAM ≠ armazenamento do modelo
Com mmap, o llama.cpp consegue endereçar pesos que não cabem na RAM: o kernel carregará páginas do SSD sob demanda. Mas cada página não residente exige uma leitura de disco durante a inferência — por isso, a importância de um NVMe rápido. RAM = velocidade, SSD = capacidade.

#Pré-requisitos de hardware

Três perfis de máquinas permitem rodar o Kimi K2 localmente, com concessões muito diferentes em termos de velocidade.

Perfil A — memória DDR5 potente (192-384 GB RAM)
Workstation Threadripper/Xeon W ou plataforma EPYC. 256 GB de DDR5 ECC, sem necessidade de GPU. O modelo cabe inteiramente na RAM em Q2_K_S. Velocidade esperada: 4-8 tok/s usando apenas a CPU.
Perfil B — DDR5 + 1 GPU de 24 GB
96-128 GB de RAM + RTX 4090/3090. As camadas compartilhadas são transferidas para a GPU, os especialistas permanecem na RAM. Velocidade esperada: 6-12 tok/s, dependendo do número de especialistas que cabem na VRAM.
Perfil C — RAM modesta + SSD NVMe
64-96 GB de RAM + NVMe Gen 4 (7 GB/s de leitura, ≥ 1 TB livre). Fazemos mmap dos pesos a partir do SSD. Velocidade esperada: 1-3 tok/s, fortemente dependente da taxa de transferência real do SSD.
→
O SSD é o novo fator limitante
Se você pretende usar offload em disco, verifique a latência de acesso aleatório do SSD, não apenas a taxa de transferência sequencial anunciada pelo marketing. Um Samsung 990 Pro ou um WD SN850X dá conta do trabalho. Um SSD QLC de entrada cai para 200 MB/s em leitura aleatória — inviável para esse uso.

#1. Compilar o llama.cpp com o backend correto

Kimi K2 exige uma versão recente do llama.cpp (build recente após dezembro de 2025) que suporte sua arquitetura MoE e as quantizações IQ. Compila-se a partir do repositório oficial.

Clonar e compilar (CUDA + mmap)
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DGGML_CUDA_FA_ALL_QUANTS=ON
cmake --build build --config Release -j

Em um Mac com Apple Silicon, substituir GGML_CUDA por GGML_METAL. Em hardware AMD com ROCm, usar GGML_HIP. A opção GGML_CUDA_FA_ALL_QUANTS ativa o Flash Attention para todas as quantizações — essencial para comportar 128k de contexto sem exceder a capacidade da VRAM.

i
Binários pré-compilados
Se você quiser evitar a compilação, as releases do GitHub fornecem binários para Linux/Windows/macOS. Verifique se a versão oferece suporte à arquitetura deepseek2 ou kimi, conforme o reempacotamento GGUF utilizado.

#2. Escolher a quantização GGUF

Para um modelo desse tamanho, esqueça Q4_K_M e acima, a menos que você tenha 512 GB de RAM. A quantização extrema — Q2_K_S, IQ2_XXS, até IQ1_M — é o que torna o uso local viável, com perda de qualidade mensurável, mas geralmente aceitável em um MoE.

Q2_K_S (~245 GB)
O ponto ideal. ~5% de degradação nos benchmarks de código, ~3% em raciocínio. Recomendado se você tiver 256 GB de RAM ou um SSD rápido.
IQ2_XXS (~210 GB)
Ainda mais agressivo com uma matriz de importância. Cabe em 192 GB de RAM com um pouco de offload. Qualidade um nível abaixo.
IQ1_M (~155 GB)
Quantização 1-bit híbrida. Para configurações muito restritas. Degradação visível, mas o modelo permanece coerente.
Q3_K_S (~320 GB)
Qualidade quase-Q4, mas exige 384 GB de RAM. Para workstations EPYC bem equipadas.
Baixar um GGUF Q2_K_S do Hugging Face
pip install -U "huggingface_hub[cli]"
huggingface-cli download \
  unsloth/Kimi-K2-Instruct-GGUF \
  --include "*Q2_K_S*" \
  --local-dir ./models/kimi-k2-q2ks

Os arquivos GGUF desse tamanho são divididos em vários arquivos (split-00001-of-00007.gguf etc). O llama.cpp detecta automaticamente os splits se você apontar para o primeiro arquivo.

!
Hash e origem
Baixe seus GGUF de um repositório de confiança (unsloth, bartowski e mradermacher são os mais seguidos). Verifique as somas de verificação SHA fornecidas. Um GGUF mal quantizado ou corrompido produzirá texto coerente no primeiro prompt e depois perderá a coerência — um problema difícil de diagnosticar.

#3. Iniciar Kimi K2 com mmap e offload

O comando básico utiliza o llama-server, o servidor HTTP fornecido pelo llama.cpp. Ele expõe um endpoint compatível com a OpenAI na porta 8080 por padrão.

Lançamento com CPU + offload em SSD via mmap
./build/bin/llama-server \
  --model ./models/kimi-k2-q2ks/kimi-k2-Q2_K_S-00001-of-00007.gguf \
  --ctx-size 32768 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --threads 16 \
  --no-mmap=false \
  --host 0.0.0.0 --port 8080

Com uma GPU de 24 GB, as camadas compartilhadas (atenção) são transferidas para a GPU, enquanto os especialistas MoE ficam na RAM ou em um SSD. O parâmetro -ot permite definir com precisão o que vai para a GPU e o que vai para a CPU.

Híbrido CPU + GPU 24 GB
./build/bin/llama-server \
  --model ./models/kimi-k2-q2ks/kimi-k2-Q2_K_S-00001-of-00007.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --n-gpu-layers 999 \
  -ot "\.ffn_.*_exps\.=CPU" \
  --threads 12 \
  --host 0.0.0.0 --port 8080

A expressão regular passada para -ot significa: “todas as camadas FFN dos especialistas (a maior parte do modelo MoE) permanecem na CPU/RAM, e o restante vai para a GPU”. É esse truque que torna a execução híbrida viável: aproveitamos a GPU para a atenção sem precisar carregar tudo nela.

→
mmap está ativo por padrão
O llama.cpp utiliza mmap automaticamente. Se a RAM física for insuficiente, o kernel paginará a partir do arquivo GGUF no disco — então coloque o GGUF em seu NVMe mais rápido, nunca em um HDD. Evite --no-mmap a menos que haja uma razão específica.

#4. Tokens/s reais medidos

Aqui estão algumas referências de taxa de geração observadas na prática. Os números variam conforme o prompt (o prefill é lento, a geração é mais estável) e o estado do cache de páginas do sistema operacional.

EPYC 9354P, 384 GB DDR5, Q2_K_S, tudo em RAM
Prefill ~80 tok/s, geração ~6-8 tok/s. Configuração de referência para raciocínio em lote.
Threadripper 7960X, 256 GB DDR5, Q2_K_S
Prefill ~50 tok/s, geração ~4-6 tok/s. A latência da memória DDR5 domina.
Ryzen 9 7950X, 128 GB DDR5 + SSD NVMe Gen 4
Prefill ~15 tok/s, geração ~1,5-3 tok/s. O SSD se torna o fator limitante a partir do momento em que ultrapassamos a RAM residente.
Mac Studio M2 Ultra 192 GB
Geração ~4-7 tok/s em IQ2_XXS. A largura de banda da memória unificada (800 GB/s) ajuda muito nos modelos MoE.
Workstation 256 GB + RTX 4090 (híbrida)
Prefill ~60 tok/s, geração ~7-10 tok/s. O GPU na atenção divide por 2 o tempo de prefill.
i
Prefill versus geração
Em um MoE desse tamanho, o prefill (leitura do prompt) se beneficia do paralelismo em lote e mantém um desempenho razoável. A geração token a token é mais lenta porque cada novo token relê os especialistas selecionados pelo roteamento. Isso é intrínseco à arquitetura, não um defeito do llama.cpp.

#5. Casos de uso com contexto de 128k

O grande diferencial do Kimi K2 em relação aos modelos locais de 7B a 70B é a janela de 128k tokens. Na prática, você pode fornecer a ele um relatório anual completo, uma base de código de tamanho médio ou cerca de cem páginas de PDF e pedir uma síntese global que considere o conjunto inteiro — em vez de RAG por chunks.

Síntese de documentos longos
Um relatório de 300 páginas ocupa menos de 120k tokens. O Kimi K2 gera uma síntese estruturada em uma única passagem, enquanto um RAG montaria um mosaico de trechos.
Refatoração da base de código
Carregar 50 arquivos Python (~80k tokens), solicitar uma revisão de arquitetura coerente. Muito útil para uma dívida técnica transversal.
Análise de logs correlacionada
Colar 50 MB de logs (após a filtragem) e pedir uma linha do tempo de um incidente. O modelo vê todas as correlações, não apenas as janelas deslizantes.
Tradução de grandes documentos
Mantém a coerência terminológica ao longo de um livro inteiro, enquanto uma tradução por blocos perde o fio.
→
Quantizar o cache KV para suportar 128k
Com --cache-type-k q8_0 --cache-type-v q8_0, o cache KV de 128k passa de cerca de 60 GB para ~30 GB. A perda de qualidade é imperceptível na prática, e você ganha a margem necessária para não saturar a RAM.

#Solução de problemas

« failed to load model » ou erro de número mágico
O seu llama.cpp é muito antigo para esse GGUF. Atualize para uma build posterior a dezembro de 2025 e verifique a versão da arquitetura informada por quem reempacotou o GGUF.
Geração a 0,2 tok/s, embora a RAM fosse suficiente
O kernel continuará paginando a partir do GGUF enquanto não tiver acessado todas as páginas. Uma primeira « execução de aquecimento » com um prompt curto pré-carrega as páginas mais acessadas. Caso contrário, aumente --threads para saturar mais cedo a largura de banda.
OOM brusco em prompt longo
O cache KV explodiu. Reduza --ctx-size para 32768 ou ative a quantização Q8 do cache. O KV cresce linearmente com o contexto, não com o tamanho do modelo.
Saída incoerente ou linguagem malformada
Muitas vezes, a causa é um template de chat incorreto. Verifique --chat-template ou se o GGUF realmente inclui o template oficial da Moonshot (jinja). Um token de fim incorreto faz a geração se descontrolar em loop.
SSD a 80 °C, com queda acentuada na taxa de transferência
Os SSDs NVMe topo de linha reduzem o desempenho por aquecimento sem dissipador. Em uma sessão longa, instale um dissipador de calor ou reduza a carga usando uma versão quantizada menor que caiba na RAM.

#Para se aprofundar

O Kimi K2 rodando localmente é um campo de experimentação para modelos muito grandes. Três caminhos para ir além:

Dominar a compilação do llama.cpp
O guia "Compilar llama.cpp com CUDA" detalha flags menos evidentes (offload de tensores, MMQ, Flash Attention) que alteram o desempenho nesse tipo de modelo.
Compreender as quantizações
O guia "Escolher a quantização" apresenta as bases conceituais úteis antes de explorar IQ2_XXS ou Q3_K_S e esclarece o que realmente se degrada.
Aumentar ainda mais a compressão
O guia TurboQuant detalha um método mais recente que os K-quants para fazer modelos de fronteira caberem em hardware de uso doméstico, com diferentes concessões.
Este guia ajudou você?

Um comentário, um erro ou uma observação? Avise-nos; isso ajuda a melhorar o guia para todos.