Desde o lançamento do Kimi K3 pela Moonshot AI, em 16 de julho de 2026, você vai ler muita coisa do tipo "rode o maior modelo open-weight do mundo no seu servidor". Quase toda essa gente não fez a conta.

Vamos fazer. O K3 tem 2,8 trilhões de parâmetros — é o primeiro modelo da classe 3T e o maior open-weight já lançado. A pergunta "quanta VRAM ele precisa?" tem resposta aritmética, e a resposta é desconfortável.

⚡ Resposta curta

Só os pesos do K3 ocupam cerca de 1,4 TB no formato nativo MXFP4. Some KV cache e overhead de runtime e você passa de 10 GPUs de 141 GB — mais do que um nó padrão de 8 GPUs entrega. Nem a quantização comunitária mais agressiva (650–700 GB) cabe em um nó de 8× 80 GB. Este artigo mostra a conta inteira, sem arredondar a favor de ninguém.

Passo 1: a conta de memória dos pesos

A regra é simples: memória dos pesos = número de parâmetros × bytes por parâmetro. Com 2,8 trilhões de parâmetros, cada bit por parâmetro custa 350 GB. É isso que torna esse modelo uma categoria diferente de tudo que veio antes.

O K3 foi treinado com QAT (quantization-aware training) desde a fase de SFT — os pesos são nativamente MXFP4 e as ativações, MXFP8. Isso é uma boa notícia de qualidade (o modelo degrada muito menos que um equivalente quantizado depois do treino), mas não muda a aritmética de memória:

Formato Tamanho aproximado dos pesos Observação
FP16 (upcast) ~5,6 TB 2,8T × 2 bytes. Não faz sentido prático: quadruplica a memória sem ganhar qualidade sobre o QAT.
MXFP4 (nativo) ~1,4 TB 2,8T × 0,5 byte. É o formato de referência, o que a Moonshot treinou.
Quantização ~2 bits ~1 TB Perda de qualidade real, ainda não medida publicamente.
Quantização agressiva ~1,8 bits ~650–700 GB O piso prático. Degradação provavelmente significativa.

As duas primeiras linhas são aritmética pura: FP16 são 16 bits por parâmetro, MXFP4 são 4, e a conta fecha exatamente. Já as duas últimas vêm acima do que a conta ingênua sugere — 2 bits dariam 700 GB, 1,8 bits dariam 630 GB. Isso é esperado, porque quantizações agressivas reais são mistas: ninguém comprime embeddings, camadas de atenção e o roteador de experts no mesmo nível dos experts, porque esmagar a atenção destrói o modelo. Os experts (a esmagadora maioria dos parâmetros) vão para o formato mais agressivo e o resto fica em 8 ou 16 bits — então o arquivo final sempre pesa mais que o piso teórico.

Passo 2: o KV cache, que ninguém soma

Pesos são só metade do problema. Todo token que entra no contexto deixa um rastro na memória: o KV cache, que guarda as chaves e valores de atenção para não recalcular tudo a cada passo. A fórmula:

KV cache = 2 × n_camadas × n_kv_heads × head_dim × bytes_por_elemento × n_tokens × batch

# "2" = uma matriz K e uma matriz V
# n_tokens = tamanho do contexto ocupado
# batch = número de sequências simultâneas

Com 1 milhão de tokens de contexto, esse termo deixa de ser um detalhe. Em modelos grandes de contexto longo, o KV cache de uma única sequência longa entra na casa das dezenas a centenas de gigabytes — e ele escala linearmente com o número de usuários simultâneos. Um servidor que atende dez pessoas ao mesmo tempo, cada uma com um contexto grande, precisa de dez vezes esse espaço.

A configuração de atenção exata do K3 só será conhecida quando os pesos e o config.json forem publicados. O que já dá para afirmar: você precisa de folga substancial acima do tamanho dos pesos — e some ainda o overhead do runtime (buffers de ativação, workspace de CUDA graph, fragmentação do alocador), tipicamente de 5% a 15% da VRAM total.

Passo 3: traduzindo para GPUs de verdade

Pegue o formato nativo (1,4 TB) e divida pelas capacidades reais de placa:

GPU VRAM por placa GPUs só para os pesos MXFP4 Um nó de 8 basta?
H100 (SXM) 80 GB ≈ 18 GPUs (1.400 ÷ 80) Não — falta mais que o dobro
H200 (SXM) 141 GB ≈ 10 GPUs (1.400 ÷ 141) Não — 8× H200 = 1.128 GB
B200 192 GB ≈ 8 GPUs (1.400 ÷ 192) No limite — sobra pouco para KV

Leia a linha do meio de novo: dez GPUs H200 só para os pesos. Um nó padrão tem oito. Ou seja, o formato nativo do K3 não cabe em um único nó de 8× H200 — e nós vêm em oito porque é isso que o NVLink de uma bandeja interliga. Passar de oito significa múltiplos nós conectados por InfiniBand, com tensor/pipeline parallel atravessando a rede. É outro patamar de engenharia e de custo.

A única configuração de nó único que chega perto é 8× B200 = 1.536 GB. Os pesos entram com cerca de 136 GB de folga — o que, para um modelo de 1M de contexto servindo mais de um usuário, é pouco. Funciona, mas apertado, e com contexto útil bem abaixo do máximo anunciado.

E note que isso tudo é no formato mais enxuto que existe. Se alguém insistir em servir o K3 em FP16, os 5,6 TB pedem 70 GPUs H100, 40 H200 ou 29 B200 — de quatro a nove nós inteiros, para um resultado que o QAT já entrega em MXFP4 com um quarto da memória. É por isso que a discussão prática sobre o K3 começa no MXFP4 e desce dali para as quantizações; o FP16 serve apenas para dimensionar o quanto o QAT nativo economiza.

Passo 4: por que "32B ativos" não te salva

Aqui está o mal-entendido mais comum sobre o K3, e vale desmontá-lo com cuidado.

O K3 é um Mixture-of-Experts: tem 896 experts e ativa apenas 16 por token, resultando em cerca de 32 bilhões de parâmetros ativos. Muita gente lê "32B ativos" e conclui: "então é do tamanho de um modelo 32B, cabe numa GPU só".

Não cabe. Parâmetros ativos medem computação, não armazenamento.

O roteador escolhe quais 16 experts usar a cada token e a cada camada. A escolha depende do conteúdo — a próxima palavra pode acionar um conjunto completamente diferente. Não há como prever, não há como pré-carregar: os 896 experts precisam estar residentes em memória, prontos para serem chamados a qualquer momento.

O que os 32B ativos realmente te dão:

É uma arquitetura desenhada para quem tem a memória e quer aproveitá-la bem — não para caber em pouco hardware.

Passo 5: o caminho do offload — e o preço dele

Existe uma saída técnica: manter só a atenção na GPU e deixar os experts na RAM do sistema ou em NVMe, carregando sob demanda. É o que o llama.cpp permite com flags de offload seletivo de camadas MoE:

# Padrão de offload MoE: atenção na GPU, tensores de experts na RAM
llama-server \
  -m modelo-quantizado.gguf \
  --n-gpu-layers 99 \
  --override-tensor "\.ffn_.*_exps\.=CPU" \
  --ctx-size 32768

Funciona. O problema é a física. A cada token gerado, os experts selecionados precisam viajar do lugar onde estão até a GPU. Compare as bandas típicas:

Onde o peso está Banda típica Ordem de grandeza
HBM da GPU ~3 a 8 TB/s Referência
RAM do sistema (via PCIe) ~30 a 60 GB/s ~100× mais lento
SSD NVMe ~3 a 14 GB/s ~1.000× mais lento

Geração autorregressiva é limitada por banda de memória, não por FLOPs. Quando os pesos que você precisa ler a cada token estão do outro lado do PCIe, é o PCIe que define sua velocidade. O resultado prático de rodar um modelo dessa classe com offload pesado é poucos tokens por segundo — às vezes menos de um.

💡 Quando o offload faz sentido

Para experimentar, avaliar qualidade em um conjunto pequeno de prompts ou rodar um lote noturno sem pressa, tudo bem — é infinitamente melhor que não rodar. Para chat interativo, agentes ou qualquer coisa em produção, não é viável. E lembre: com 1 milhão de contexto e esforço de raciocínio apenas no nível "max", o K3 consome muitos tokens por resposta. A poucos tokens por segundo, uma única resposta pode levar horas.

Sendo honestos sobre a nossa plataforma

É aqui que a maioria dos textos comerciais viraria um CTA. Não vamos fazer isso, porque seria mentira.

Situação verificada no nosso catálogo ao vivo em 18 de julho de 2026:

Compare com a conta acima e a conclusão é direta: o Kimi K3 completo não roda na nossa plataforma hoje. Não cabe o MXFP4 nativo (1,4 TB contra 640 GB disponíveis), não cabe a quantização de 2 bits (~1 TB), e nem mesmo a quantização mais agressiva que a comunidade deve produzir — 650 a 700 GB — entra em 640 GB. Falta memória em todos os cenários.

Vale registrar também que os pesos do K3 ainda não são públicos: a Moonshot indicou publicação até 27 de julho de 2026. Qualquer um que hoje afirme ter testado o modelo self-hosted, ou que prometa deploy de um clique, está vendendo algo que ainda não existe.

O que nos comprometemos a fazer: quando os pesos saírem e as primeiras quantizações da comunidade aparecerem, publicamos aqui o teste real — com os tamanhos de arquivo medidos, o que coube onde, os tokens por segundo observados e o que degradou. Números nossos, em hardware nosso. Se não couber, o artigo vai dizer que não coube.

O que a maioria das empresas deveria fazer

Aqui está a parte prática. O K3 é uma prova de que o open-weight chegou na fronteira — mas a fronteira raramente é o que resolve seu problema. Os modelos abaixo rodam de verdade, hoje, em 1 a 8 GPUs:

Modelo Parâmetros VRAM aproximada GPUs de 80 GB
Qwen3 32B 32B denso ~65 GB (FP16) · ~20 GB (4 bits) 1
Llama 70B 70B denso ~140 GB (FP16) · ~40 GB (4 bits) 1 a 2
Qwen3 235B (MoE) 235B / ~22B ativos ~240 GB (FP8) · ~130 GB (4 bits) 2 a 4
DeepSeek-R1 671B MoE ~700 GB (FP8) · ~400 GB (4 bits) 4 a 8 (quantizado)
GLM-5.2 753B MoE / ~40B ativos ~750 GB (FP8) · ~400 GB (4 bits) 4 a 8 (quantizado)
Kimi K2 ~1T MoE / ~32B ativos ~1 TB (FP8) · ~550 GB (4 bits) 8 (quantizado, apertado)
Kimi K3 2,8T MoE / ~32B ativos ~1,4 TB (MXFP4) · 650–700 GB (~1,8 bits) 18 (nativo) — não cabe em um nó

Os valores são aproximados e variam com a quantização, o contexto configurado e o runtime — use-os para dimensionar, não como garantia, e sempre reserve folga para KV cache. Para escolher entre eles, veja o comparativo de LLMs open-source de 2026 e o guia de escolha de GPU.

E vale o lembrete: a diferença entre um 235B e um 2,8T é muito menor, no seu caso de uso real, do que os benchmarks sugerem. Extração estruturada, RAG sobre base interna, suporte, código de rotina — quase tudo isso é resolvido por modelos que cabem em uma ou duas GPUs. O que separa um bom sistema de um ruim costuma ser a engenharia em volta do modelo.

Se você realmente precisa do K3 agora

Use a API oficial da Moonshot. É a resposta honesta.

Os preços publicados são US$ 3,00 por milhão de tokens de entrada (cache miss), US$ 0,30 em cache hit e US$ 15,00 por milhão de tokens de saída. Para o volume da maioria das empresas, isso é uma fração do custo de tentar montar a infraestrutura necessária para hospedar o modelo — e você não precisa de dez GPUs H200.

Se sua carga é de alguns milhões de tokens por mês, a API ganha com folga. O self-hosting só passa a compensar com volume grande, constante e previsível — ou quando o requisito é controle: instância dedicada só sua, você manda no modelo, nos pesos e nos logs, sem enviar prompt para a API de terceiro. O cálculo está detalhado em quando o self-hosting compensa.

Rode hoje o que realmente cabe

GLM-5.2, Kimi K2, DeepSeek-R1 e Qwen3 sobem em GPU dedicada por hora, cobrada em reais, com suporte em português. Ganhe R$ 25 para testar.

Começar Grátis →

Perguntas frequentes

Quanta VRAM o Kimi K3 precisa?

Só para os pesos: cerca de 1,4 TB no formato nativo MXFP4 (2,8T × 0,5 byte), ~5,6 TB se convertido para FP16, ~1 TB numa quantização de 2 bits e 650 a 700 GB numa quantização agressiva de ~1,8 bits. Some o KV cache — que com 1 milhão de tokens de contexto não é desprezível — e o overhead do runtime. Na prática, nem a versão mais comprimida cabe num nó de 8 GPUs de 80 GB.

Se o K3 ativa só 32B de parâmetros por token, por que preciso de tanta VRAM?

Porque parâmetros ativos medem computação, não armazenamento. O K3 tem 896 experts e escolhe 16 por token, mas a escolha muda a cada token e a cada camada — todos precisam estar residentes em memória, ou sofrer offload lentíssimo. Os 32B ativos deixam a geração rápida; eles não reduzem em nada a memória necessária.

Dá para rodar o K3 com offload para RAM ou NVMe?

Tecnicamente sim, com llama.cpp mantendo os experts fora da GPU. Mas geração é limitada por banda de memória, e RAM via PCIe é ~100× mais lenta que a HBM da GPU (NVMe, ~1.000×). O resultado é poucos tokens por segundo: aceitável para experimentar, inviável para chat ou produção.

Vocês vão oferecer o Kimi K3?

Hoje não conseguimos: o maior nó com estoque é 8× H100 = 640 GB, não há multi-nó, e nenhum formato do K3 cabe nisso. Os pesos, aliás, ainda nem são públicos (previsão até 27 de julho de 2026). Quando saírem e a comunidade publicar as primeiras quantizações, vamos testar de verdade e publicar aqui o resultado — inclusive se ele for negativo.

Conclusão

O Kimi K3 é um marco: 2,8 trilhões de parâmetros com pesos abertos não existia há um mês. Mas "pesos abertos" e "você consegue rodar" são coisas diferentes — e a distância entre elas, aqui, é de mais de um terabyte de VRAM.

A conta não é opinião. Cada bit por parâmetro custa 350 GB. O formato nativo pede dez GPUs de 141 GB só para os pesos, antes de qualquer contexto. "32B ativos" acelera a inferência sem economizar um byte de memória. O offload troca VRAM por uma lentidão que inviabiliza produção. Nada disso muda porque alguém escreveu um tutorial otimista.

O que muda com o tempo é o hardware disponível e a criatividade da comunidade em quantização — e quando os pesos saírem, vamos medir e contar. Até lá, a recomendação honesta é dupla: API oficial da Moonshot se você precisa do K3 especificamente, e um open-weight que cabe em 1 a 8 GPUs se você precisa resolver um problema. Na esmagadora maioria dos casos, é o segundo.

Leia também: Kimi K2: agentes e código open-source · Como rodar o GLM-5.2 em GPU econômica · DeepSeek e Qwen: o open-source em 2026