O que é preciso para hospedar o Kimi K3 localmente

O que é necessário para alojar o Kimi K3 localmente

Alojar o Kimi K3 localmente significa encontrar espaço para 2.8 triliões de parâmetros. A Moonshot publicou os pesos abertos em MXFP4, que ocupa cerca de meio byte por peso. Por isso, só os pesos correspondem a aproximadamente 1.4 TB, antes de reservar espaço para um único token de cache. Atualmente, nenhum acelerador disponível no mercado consegue armazenar esse volume sozinho. O K3 é um modelo para vários nós. Num único servidor, a resposta é não.

Essa é a conclusão. O restante conteúdo apresenta os cálculos que a sustentam, porque esses cálculos podem ser reutilizados na próxima versão. Vários fornecedores de infraestrutura publicaram guias de implementação do K3 nas semanas seguintes ao anúncio de 17 July 2026. Todos partiam do princípio de que já tinha um cluster. Esta página começa pelo outro lado: quanto custa, o que pode executar em alternativa e como determinar em qual dessas duas situações se encontra.

O número total de parâmetros e o número de parâmetros ativos não são iguais

K3 é um modelo de mistura de especialistas. A MoE (mistura de especialistas) divide a rede em muitas sub-redes e permite que um router selecione algumas delas para cada token. O cartão do modelo indica 2.8T de parâmetros totais e 104B de parâmetros ativados por token, entre 896 especialistas encaminhados, dos quais 16 são ativados para qualquer token, distribuídos por 93 camadas.

Essas duas contagens de parâmetros respondem a perguntas diferentes, e trocá-las é o erro mais comum em qualquer discussão sobre se é possível executar este modelo.

Os parâmetros ativos determinam o custo computacional. Um token é processado por cerca de 104B de parâmetros. Por isso, o throughput esperado é semelhante ao de um modelo denso de 104B, não ao de um modelo de 2.8T. Essa é a razão principal para usar uma MoE.

O número total de parâmetros determina o custo de memória. O router pode selecionar qualquer especialista para qualquer token. Por isso, todos os especialistas têm de estar residentes antes de chegar o primeiro pedido. Não é possível manter 104B na VRAM e carregar o restante sob demanda. A transferência teria de terminar em microssegundos, mas uma ligação PCIe move dezenas de gigabytes por segundo. Algumas pessoas tentam fazer isso. Transmitir especialistas a partir de NVMe transforma um modelo que deveria emitir dezenas de tokens por segundo num modelo que emite um token a cada poucos segundos.

Portanto, o custo computacional é baixo, mas o custo de armazenamento é elevado. Dimensione o hardware com base em 2.8T. Dimensione as expectativas de velocidade com base em 104B.

Bytes por peso e de onde vêm os terabytes

Contagem de parâmetros multiplicada pelos bytes por peso. Para os pesos, essa é a fórmula completa.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

O K3 foi treinado com consciência de quantização e lançado com pesos MXFP4 e ativações MXFP8, portanto a linha de 4 bits é a relevante. As linhas acima servem de referência: em bf16, o mesmo modelo precisaria de 5.6 TB. O MXFP4 também armazena uma escala partilhada de 8 bits por cada bloco de 32 pesos, o que acrescenta cerca de 6 por cento. Por isso, o repositório publicado ocupa mais perto de 1.5 TB do que de 1.4 TB.

Isto elimina a escapatória habitual. "Basta quantizá-lo" não ajuda neste caso, porque o checkpoint lançado já usa 4 bits. Reduzir para 2 bits faria os pesos ocuparem 0.7 TB e causaria uma perda de precisão que ninguém mediu neste checkpoint. Mesmo assim, continuaria muito acima da capacidade de qualquer placa única.

De quantas GPUs o Kimi K3 precisa

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

Considere esses valores como um mínimo, não como uma meta. Eles contabilizam apenas os pesos: não incluem a cache KV, os buffers de ativações, a fragmentação do alocador nem espaço para um segundo pedido simultâneo. Também pressupõem uma divisão paralela uniforme, o que nem sempre é possível com 93 camadas e 896 especialistas.

As recomendações publicadas ficam bem acima desse mínimo. Em agosto de 2026, a Moonshot recomenda um supernó com 64 ou mais aceleradores, e o cookbook do SGLang fornece uma configuração para H100 composta por quatro nós com 8 GPUs, totalizando 32 GPUs e 2,560 GB de memória agregada, em comparação com um mínimo de 18 placas. Essa diferença não representa desperdício. Ela cobre a cache KV, a memória das ativações e a margem necessária para o servidor processar muitos pedidos em lote ao mesmo tempo. Mesmo a opção mais favorável, com placas da classe GB300 de 5 GB, descreve uma máquina que a maioria dos provedores não disponibiliza como um SKU único.

O cache KV é a parte que surpreende as pessoas

Os pesos têm um custo fixo. O cache KV (key value) não: cresce com o comprimento do contexto e novamente com cada utilizador simultâneo. Para a atenção normal, a fórmula é bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element. Depois, multiplica-se pelo comprimento do contexto e pela simultaneidade.

Eis um exemplo calculado, apenas como exemplo: 64 camadas, 8 cabeças KV, dimensão de cabeça 128, fp8. Isso dá 2 64 8 128 1 = 131,072 bytes, ou seja, 128 KiB por token.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

Um utilizador com um contexto de 128k consome 16 GiB. Um utilizador com o milhão completo consome 128 GiB, o que é mais do que qualquer placa individual consegue armazenar, para uma única conversa.

O K3 não usa atenção normal, e esse último número explica porquê. As suas 93 camadas são compostas por 69 camadas KDA (Kimi Delta Attention) e 24 camadas Gated MLA (multi-head latent attention). A KDA mantém um estado recorrente de tamanho fixo, em vez de um cache que cresce a cada token, e a MLA comprime a chave e o valor num único vetor latente de baixo rank. Por isso, o custo real por token fica muito abaixo do exemplo calculado. A Moonshot não publicou as dimensões latentes, por isso não vou indicar um valor por utilizador para o próprio K3. Meça o seu: inicie o servidor com um --max-model-len pequeno, monitorize a memória com nvidia-smi e aumente o limite até a alocação falhar.

A lógica mantém-se na próxima versão. Se um modelo anunciar um contexto de um milhão de tokens e não disser nada sobre o seu desenho de atenção, assuma que o cache é a limitação principal até alguém provar o contrário.

Tier 1: alugar o cluster à hora

Este é o único nível que executa o próprio K3. Não compra o hardware. Aluga-o durante as horas necessárias e encerra-o depois.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

A tarifa é uma suposição, não uma cotação. Os preços públicos sob demanda para aceleradores de datacenter situaram-se aproximadamente entre 2 e 5 USD por hora de GPU ao longo de 2026, e a capacidade reservada é mais barata. Use o valor real do seu fornecedor e refaça a multiplicação: GPUs vezes horas vezes tarifa. O objetivo do gráfico é mostrar a proporção. Disponibilizar um nó com 8 GPUs durante quatro horas por dia custa 2,400 USD por mês, enquanto manter em execução a configuração de 32 GPUs dimensionada para SGLang custa 57,600 USD.

Os dois servidores mais utilizados publicam um comando de arranque na página do modelo.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

Nenhum dos comandos, tal como está, é adequado para executar num cluster real. Adicione as flags de paralelismo correspondentes ao seu hardware: o SGLang usa --tp-size para o paralelismo de tensores e --ep-size para o paralelismo de especialistas, e o produto desses valores tem de ser igual ao número real de GPUs disponíveis.

Confirme que o servidor arrancou antes de enviar tráfego real:

curl http://127.0.0.1:30000/v1/models

Um servidor saudável responde com um objeto JSON que lista o ID do modelo. Connection refused significa que o processo ainda está a carregar os pesos ou já terminou, por isso leia o log do servidor antes de tentar novamente.

A falha mais comum no primeiro dia é usar um runtime mais antigo do que o modelo. O K3 foi lançado com KDA e uma nova camada MoE que as versões estáveis do vLLM e do SGLang não incluíam no lançamento, e o sintoma é o servidor terminar durante o arranque com uma linha do tipo Model architectures [...] are not supported for now. Nenhuma alteração de configuração corrige este problema, porque o código necessário para executar essas camadas não está presente na sua compilação. Instale a versão nightly indicada na página do modelo ou aguarde pela versão que a inclua.

Há um detalhe de custos que causa problemas. A contagem começa quando a instância arranca, não quando o modelo fica pronto. Um download de 1.5 TB a 1 GB/s demora cerca de 25 minutos de tempo do cluster antes do primeiro token. Prepare os pesos num volume que permaneça disponível depois de a instância ser encerrada, para que a segunda execução comece em minutos.

Nível 2: executar um modelo menor num acelerador

Neste nível, não está a executar o K3. Diga isso explicitamente antes de começar, porque a maioria dos tópicos sobre "executar o K3 localmente" termina aqui sem o admitir.

A regra de dimensionamento usa a mesma fórmula, numa escala menor: parâmetros vezes bytes por peso, mais a cache KV, mais cerca de 2 GB de sobrecarga de execução, têm de caber na sua VRAM. Com 4-bit, são aproximadamente meio byte por parâmetro, o que permite combinações confortáveis:

• Placa de 16 GB: um modelo 7B em 4-bit, com espaço para um contexto longo
• Placa de 24 GB: um modelo 14B em 4-bit
• Placa de 48 GB: um modelo 32B em 4-bit
• Placa de 80 GB: um modelo 70B em 4-bit ou um MoE da classe 30B em 8-bit

Ollama é o caminho mais curto para ter um servidor funcional numa VPS com uma GPU ligada:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run descarrega o modelo na primeira utilização e apresenta uma linha de comandos. Uma tag que não exista devolve Error: model "..." not found, por isso copie as tags da página da biblioteca em vez de as escrever de memória. O guia completo, incluindo a unidade systemd e o acesso remoto, está em executar o Ollama numa VPS.

llama.cpp oferece mais controlo sobre a quantização e o offload:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 solicita todas as camadas na GPU. Leia o log de carga: ele indica quantas camadas foram transferidas. As camadas que passam para a RAM do sistema executam à largura de banda da RAM, em vez da largura de banda da HBM, por isso a velocidade de geração diminui uma ordem de grandeza assim que o modelo deixa de caber. Os compromissos entre as duas ferramentas são explicados em Ollama e llama.cpp lado a lado.

Camada 3: API alojada, orquestração autogerida

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

O endpoint é compatível com OpenAI, por isso um cliente existente funciona depois de alterar o URL base.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

Uma chave válida devolve um objeto JSON com um array choices. Um 401 significa que a chave está errada ou que falta o prefixo Bearer. Um erro de modelo não encontrado normalmente significa que o ID foi alterado, porque os fornecedores retiram IDs entre checkpoints.

Agora, o ponto de equilíbrio, usando a tarifa de aluguer assumida acima. Um nó com 8 GPUs sempre ligado custa 14,400 USD por mês. A 15.00 USD por milhão de tokens de saída, o mesmo valor compra cerca de 960 milhões de tokens de saída através da API. Para obter uma vantagem de custo, teria de gerar perto de mil milhões de tokens de saída por mês, aproximadamente 30 milhões por dia, e manter o cluster ocupado durante todo esse período. As GPUs inativas são faturadas à mesma tarifa que as GPUs ocupadas. As cargas de trabalho de agentes com muitos prompts afastam ainda mais esse ponto: o contexto repetido é faturado à tarifa de cache hit de 0.30 USD por milhão, e não à tarifa de cache miss de 3.00 USD.

O que autogera nesta camada é tudo o que envolve o modelo: um gateway que mantém a chave da API para que esta nunca chegue ao cliente, logs de pedidos e respostas, novas tentativas, limites de taxa e orçamentos por utilizador. Isto é executado numa VPS pequena, sem qualquer GPU. A mesma divisão aplica-se a pesos fechados. Nesse caso, autogerir o Claude não é possível ao nível do modelo, e a orquestração é a única parte que controla.

Que stack de serving pertence a cada nível

Os servidores da classe vLLM e SGLang pertencem ao nível 1. Foram concebidos para servir muitos pedidos em simultâneo, com continuous batching e uma cache KV paginada, além de tensor parallelism e expert parallelism distribuídos por vários nós. Pressupõem aceleradores de datacenter e uma interligação rápida entre eles. Numa única placa de consumo, são mais pesados de instalar e oferecem poucas vantagens percetíveis.

llama.cpp e Ollama pertencem ao nível 2. Destinam-se a uma única máquina, à quantização GGUF, ao CPU offload quando o modelo não cabe na memória disponível e a uma baixa concorrência. O llama.cpp consegue carregar tecnicamente um MoE enorme mantendo a maioria das camadas na RAM do sistema, mas, num modelo de 2.8T, esse processo demora vários segundos por token. Isto apenas demonstra que o ficheiro pode ser analisado. Não é um serviço adequado para disponibilizar a utilizadores. A comparação completa está em Ollama contra vLLM e não muda com o modelo: a questão é sempre saber se está a servir muitos utilizadores num hardware partilhado ou um único utilizador no seu próprio equipamento.

Os quatro números que continuam válidos depois deste marco

1. O total de parâmetros multiplicado pelos bytes por peso dá o limite mínimo de memória. Nada funciona abaixo desse valor, e nenhuma técnica de quantização o altera muito quando a versão já é de 4 bits.
2. Os parâmetros ativos determinam a classe de desempenho. Um MoE de 2.8T com 104B de parâmetros ativos calcula como um modelo de 104B.
3. A cache KV por token, multiplicada pelo tamanho do contexto e pela concorrência, representa o custo que continua a crescer depois de a memória dos pesos já estar alocada.
4. Tokens por segundo por dólar é o único número que determina o escalão. Tudo o que vem acima serve de entrada para esse cálculo.

Aplique estes quatro critérios a qualquer versão e obterá a resposta correta antes de consultar um guia do fornecedor. Depois, indique a data de cada valor registado. Os preços e as listas de arquiteturas suportadas mudaram nas duas semanas seguintes ao lançamento do K3, e todos os valores desta página foram publicados em julho de 2026.

FAQ

Posso executar o Kimi K3 numa única GPU?

Não. Os pesos ocupam cerca de 1.4 TB na precisão MXFP4 distribuída pela Moonshot, e o maior acelerador individual disponível tem 288 GB. Um modelo MoE não consegue carregar os especialistas inativos a partir do disco a uma velocidade utilizável, porque o router pode selecionar qualquer especialista para qualquer token e uma leitura através de PCIe demora muito mais do que o orçamento de tempo por token permite. A menor implantação sensata do Kimi K3 requer um nó com várias GPUs, e as receitas publicadas usam 32 aceleradores ou mais.

De quanta VRAM precisa o Kimi K3?

Comece com 1.4 TB apenas para os pesos. Isso corresponde a 18 placas H100 de 80GB ou a 5 placas da classe GB300. Depois, adicione a cache KV e a memória das ativações. Em agosto de 2026, a Moonshot recomenda 64 aceleradores ou mais, e o cookbook do SGLang publica uma configuração com 32 GPUs H100 e 2,560 GB no total. Por isso, trate o valor dos pesos como um mínimo, não como um requisito suficiente.

A quantização permite executar o Kimi K3 num único nó?

Não de forma útil. O checkpoint distribuído já é de 4 bits e foi treinado com consciência da quantização, portanto a poupança mais simples já foi obtida. Reduzir novamente para 2 bits baixa os pesos para 0.7 TB, o que continua a ser mais do dobro da capacidade da maior placa. Além disso, o custo de precisão de 2 bits ainda não foi medido neste modelo.

Alugar GPUs é mais barato do que usar a API do Kimi K3?

Apenas com um volume elevado e constante. Com um custo assumido de 2.50 USD por hora de GPU, um nó com 8 GPUs sempre ligado custa 14,400 USD por mês. Pelo mesmo valor, é possível comprar cerca de 960 milhões de tokens de saída à tarifa publicada de 15.00 USD por milhão. Também paga as horas sem utilização, as transferências dos pesos e a pessoa responsável por manter o cluster em funcionamento. Alugue por hora para cargas pontuais e compare com o seu volume de tokens medido, não com uma estimativa.

O que significa ter 104B parâmetros ativos para a velocidade?

Significa que o cálculo por token é equivalente ao de um modelo de 104B. Por isso, o débito fica nessa classe, e não na classe de 2.8T. Isto não diz nada sobre a memória: os 2.8T parâmetros permanecem residentes, porque o router pode chamar qualquer especialista para qualquer token. Use a quantidade de parâmetros ativos para estimar os tokens por segundo e a quantidade total para dimensionar a VRAM.