Como hospedar o Kimi K3 por conta própria

O que é necessário para hospedar o Kimi K3 por conta própria

Hospedar o Kimi K3 por conta própria significa encontrar espaço para 2.8 trilhões de parâmetros. A Moonshot publicou os pesos abertos em MXFP4, que ocupam cerca de meio byte por peso. Assim, só os pesos ocupam aproximadamente 1.4 TB, antes de reservar espaço para um único token da cache. Nenhum acelerador atualmente à venda comporta esse volume sozinho. O K3 é um modelo para vários nós. Num único servidor, a resposta é não.

Esse é o veredito. O restante apresenta os cálculos que o 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, e todos partiram 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.

A quantidade total de parâmetros e a quantidade de parâmetros ativos não são iguais

K3 é um modelo de mistura de especialistas. O MoE (mistura de especialistas) divide a rede em muitas sub-redes e permite que um roteador 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, a partir de 896 especialistas encaminhados, dos quais 16 são ativados para qualquer token, distribuídos por 93 camadas.

Essas duas quantidades de parâmetros respondem a perguntas diferentes, e trocá-las é o erro mais comum em qualquer discussão sobre "posso executar este modelo".

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

A quantidade total de parâmetros determina o custo de memória. O roteador pode selecionar qualquer especialista para qualquer token, portanto todos os especialistas têm de estar residentes antes de chegar o primeiro pedido. Não é possível manter 104B na VRAM e obter o restante sob demanda, porque essa transferência teria de terminar em microssegundos, enquanto uma ligação PCIe transfere dezenas de gigabytes por segundo. Há quem tente fazer isso. Transmitir os especialistas a partir de NVMe transforma um modelo que deveria gerar dezenas de tokens por segundo num modelo que gera 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

Número de parâmetros vezes bytes por peso. Para os pesos, essa é toda a fórmula.

[
  {
    "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, por isso a linha de 4 bits é a que corresponde à realidade. As linhas acima servem de escala: em bf16, o mesmo modelo precisaria de 5.6 TB. O MXFP4 também armazena uma escala partilhada de 8 bits para cada bloco de 32 pesos, o que acrescenta cerca de 6 por cento. Por isso, o repositório publicado fica mais perto de 1.5 TB do que de 1.4 TB exatos.

Isto elimina a habitual alternativa. "Basta quantizar" não ajuda neste caso, porque o checkpoint lançado já usa 4 bits. Passar para 2 bits reduziria os pesos para 0.7 TB e custaria precisão que ninguém mediu neste checkpoint. Mesmo assim, o valor continuaria muito acima da capacidade de qualquer placa única.

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 estes 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 inclui uma configuração com H100 composta por quatro nós de 8 GPUs: 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. Até a opção mais favorável, com 5 placas da classe GB300, descreve uma máquina que a maioria dos fornecedores não disponibiliza como um único SKU.

O cache KV é a parte que surpreende muitas pessoas

Os pesos têm um custo fixo. O cache KV (key value) não tem: cresce com o tamanho 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, multiplique pelo tamanho do contexto e pela simultaneidade.

Eis um exemplo calculado, que serve apenas como exemplo: 64 camadas, 8 cabeças KV, dimensão de cabeça 128 e fp8. Isso resulta em 2 64 8 128 1 = 131,072 bytes, ou 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 custa 16 GiB. Um utilizador com o milhão completo custa 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 valor explica porquê. As suas 93 camadas incluem 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 com cada token, e a MLA comprime a chave e o valor num único vetor latente de baixa ordem. 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 explicar o seu mecanismo de atenção, assuma que o cache é a limitação determinante até alguém demonstrar o contrário.

Tier 1: alugar o cluster à hora

Este é o único tier que executa o próprio K3. Não compra o hardware. Aluga-o durante as horas necessárias e para-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 estimativa, não uma cotação. Os preços sob demanda para aceleradores de datacenter ficaram 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 provedor e refaça a multiplicação: GPUs vezes horas vezes tarifa. O objetivo do gráfico é mostrar a proporção. Ativar um nó com 8 GPUs durante quatro horas por dia custa 2,400 USD por mês, enquanto manter a configuração SGLang dimensionada para 32 GPUs em execução custa 57,600 USD.

Os dois servidores principais publicam um comando de inicialização no cartão 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 dois comandos, sem alterações, é o que deve executar num cluster real. Adicione os flags de paralelismo correspondentes ao seu hardware: o SGLang usa --tp-size para paralelismo de tensor e --ep-size para paralelismo de especialistas, e o produto desses valores tem de ser igual ao número de GPUs disponíveis.

Confirme que o servidor iniciou 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 consulte o log do servidor antes de tentar novamente.

A falha mais comum no primeiro dia é usar um runtime mais antigo 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 a inicialização com uma linha no formato Model architectures [...] are not supported for now. Nenhuma alteração de configuração resolve o 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 no cartão do modelo ou aguarde pela versão que a inclua.

Há uma questão de custos que costuma passar despercebida. A cobrança começa quando a instância inicia, não quando o modelo fica pronto. Um download de 1.5 TB a 1 GB/s demora cerca de 25 minutos de tempo de cluster antes do primeiro token. Armazene os pesos num volume que sobreviva à instância, para que a segunda execução comece em minutos.

Tier 2: executar um modelo menor num único acelerador

Neste tier, não vai executar o K3. Diga isso explicitamente antes de começar, porque a maioria das discussões sobre “executar o K3 localmente” termina aqui sem o admitir.

A regra de dimensionamento é a mesma fórmula, em escala menor: os parâmetros multiplicados pelos bytes por peso, mais a KV cache e cerca de 2 GB de overhead do runtime, têm de caber na sua VRAM. Com 4-bit, isso corresponde aproximadamente a meio byte por parâmetro, o que permite combinações confortáveis:

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

Cada combinação acima pressupõe um pedido de cada vez. Quando uma segunda pessoa envia um prompt, cada slot concorrente precisa da sua própria KV cache. É esse o compromisso que as definições NUM_PARALLEL e MAX_QUEUE do Ollama fazem entre slots paralelos, pedidos em fila e a VRAM disponível.

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

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

ollama run descarrega o modelo na primeira utilização e apresenta um prompt. Uma tag inexistente 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 Ollama num 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 que todas as camadas sejam executadas na GPU. Consulte o log de carga: este indica quantas camadas foram descarregadas para a GPU. As camadas que passam para a RAM do sistema executam à largura de banda da RAM, e não à 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.

Tier 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 a 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 o preço de aluguer assumido acima. Um nó com 8 GPUs sempre ligado custa 14,400 USD por mês. Ao preço de 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, é necessário 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 taxa que as GPUs ocupadas. Cargas de trabalho de agentes com muitos prompts afastam ainda mais esse ponto: o contexto repetido é faturado à taxa de cache hit de 0.30 USD por milhão, e não à taxa de cache miss de 3.00 USD.

Neste nível, o que fica autogerido é tudo o que envolve o modelo: um gateway que mantém a chave da API para que nunca chegue a um cliente, logs de pedidos e respostas, novas tentativas, limites de taxa e orçamentos por utilizador. Isto funciona num VPS pequeno, sem qualquer GPU. A mesma separação aplica-se a pesos fechados, nos quais alojar o Claude por conta própria não é possível ao nível do modelo e a orquestração é a única parte sob o seu controlo.

Qual stack de serving pertence a cada camada

Os servidores da classe vLLM e SGLang pertencem à camada 1. Foram concebidos para servir muitos pedidos em simultâneo, com continuous batching e uma cache KV paginada, além de paralelismo de tensores e de especialistas distribuído 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 perceptíveis.

llama.cpp e Ollama pertencem à camada 2. Destinam-se a uma única máquina, quantização GGUF, offload para a CPU quando o modelo não cabe e baixa concorrência. O llama.cpp consegue carregar tecnicamente um MoE enorme mantendo a maioria das camadas na RAM do sistema, mas, para um modelo de 2.8T, esse caminho demora segundos por token. Isso prova 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 hardware.

Os quatro números que continuam relevantes depois deste marco

1. O número 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 significativamente quando a versão já usa 4-bit.
2. Os parâmetros ativos determinam a classe de throughput. 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 comprimento do contexto e pela concorrência, representa o custo que continua a crescer depois de a memória dos pesos já ter sido alocada.
4. Tokens por segundo por dólar é o único número que define o nível. Tudo o resto é um dado de entrada para esse cálculo.

Aplique estes quatro números a qualquer versão e obterá a resposta correta antes de consultar a documentação do fornecedor. Registe também a data de cada valor. Os preços e as listas de arquiteturas suportadas mudaram nas duas semanas após o lançamento do K3, e todos os números 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 por PCIe demora muito mais do que o orçamento de tempo por token permite. A menor implantação sensata do K3 é um nó com várias GPUs, e as receitas publicadas usam 32 aceleradores ou mais.

De quanta VRAM o Kimi K3 precisa?

Comece com 1.4 TB apenas para os pesos, o que corresponde a 18 placas H100 80GB ou a 5 placas da classe GB300. Depois, acrescente 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. Portanto, trate o valor dos pesos como um mínimo, não como um requisito suficiente.

A quantização faz o Kimi K3 caber num único nó?

Não de forma útil. O checkpoint distribuído já usa 4 bits e treino consciente 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 ainda é mais do dobro da capacidade da maior placa, e 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. Considerando um custo de 2.50 USD por hora de GPU, um nó com 8 GPUs sempre ligado custa 14,400 USD por mês. O mesmo valor compra cerca de 960 milhões de tokens de saída à tarifa publicada de 15.00 USD por milhão. Também paga as horas de inatividade, as transferências dos pesos e a pessoa responsável por manter o cluster operacional. Alugue por hora para picos de utilização 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 é o de um modelo 104B. Portanto, o débito fica nessa classe, e não na classe 2.8T. Isto não informa sobre a memória: todos os 2.8T parâmetros permanecem residentes, porque o router pode chamar qualquer especialista para qualquer token. Use a contagem de parâmetros ativos para prever tokens por segundo e a contagem total para dimensionar a VRAM.