Guia de Implantação do Kimi K3: Configurações de Cluster e Ajustes de Inferência para o Modelo Aberto de 2,8T

Em 27 de julho, a Moonshot AI liberou os pesos completos do Kimi K3 no Hugging Face como prometido: 2,8 trilhões de parâmetros, arquitetura MoE, 896 especialistas, contexto nativo de um milhão de tokens — o maior modelo open-weight do mundo, sem discussão.

Três números importam mais para os desenvolvedores: quantização MXFP4 nativa, um footprint mínimo de memória de 1,4TB e suporte Day-0 no vLLM/SGLang. O K3 não é um modelo para admirar o paper — é um sistema de inferência que você pode colocar em produção. Este guia dispensa os benchmarks e vai direto ao ponto: colocá-lo para rodar.

Arquitetura do K3 em Resumo: Por Que a Lógica de Implantação é Diferente

Três fatos sobre o K3 determinam a configuração do seu cluster:

1. Parâmetros totais vs parâmetros ativos

O total é 2,8T, mas cada token ativa apenas 16 dos 896 especialistas — cerca de 104B de parâmetros ativos. O detalhe: os pesos de todos os 896 especialistas precisam estar na memória, porque você nunca sabe quais o router vai escolher.

2. MXFP4 é nativo, não aplicado depois

O K3 passou por treinamento com conscientização de quantização a partir da etapa de SFT. MXFP4 não é um artefato pós-quantização — é a configuração de fábrica. Não é necessária uma etapa separada de calibração.

Precisão	Bytes/param	Memória de pesos
BF16/FP16	2	~5,6 TB
MXFP8	1	~2,8 TB
MXFP4 (recomendado)	0,5	~1,4 TB

3. Atenção: KDA + AttnRes

O KDA (Kimi Delta Attention) é uma atenção linear híbrida; combinada com Attention Residuals para recuperação entre camadas, o custo de contextos de um milhão de tokens deixa de escalar quadraticamente com o comprimento da sequência. O vLLM e o SGLang concluíram suas adaptações antes de 27 de julho.

Juntando os três fatos, o perfil de implantação do K3 se lê de forma bem diferente de um modelo denso de capacidade semelhante. Um modelo denso de 104B seria trivial de hospedar; um modelo denso de 2,8T seria impossível. O K3 fica no meio complicado — seu custo de atendimento acompanha os 104B de parâmetros ativos, enquanto sua exigência de memória acompanha o total de 2,8T, e é por isso que toda questão de configuração abaixo é, na verdade, uma questão de capacidade de memória e interconexão, e não de computação. Planeje primeiro pelos pesos, depois pelo tráfego.

Três Configurações de Cluster

Todos os três planos assumem MXFP4 (a precisão recomendada).

Plano A: 8× B300 (mínimo viável)

# Single node, 8x B300 (192GB VRAM per card)
# Theoretical capacity: 8 x 192 = 1536 GB > 1400 GB needed
# Leave headroom for KV cache and activation memory

# vLLM launch example
python -m vllm.entrypoints.openai.api_server \
  --model moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --expert-parallel-size 8 \
  --max-model-len 131072 \
  --dtype auto \
  --gpu-memory-utilization 0.95 \
  --trust-remote-code

Plano B: 16× B200 (recomendado para produção)

# Two nodes, 8x B200 each (144GB VRAM per card)
# Theoretical capacity: 16 x 144 = 2304 GB — comfortable headroom
# Supports larger batch sizes and longer context windows

# SGLang launch example
python -m sglang.launch_server \
  --model-path moonshotai/Kimi-K3 \
  --tp 16 \
  --ep 16 \
  --context-length 524288 \
  --quantization mxfp4 \
  --trust-remote-code \
  --host 0.0.0.0 \
  --port 8000

Plano C: 1× GB200 NVL72 (potência máxima)

# One rack, 72 cards; BF16-equivalent compute ~2.5x per H100
# Can run BF16 directly, no quantization downgrade
# Handles 1M context plus heavy production batch traffic

# Three-tier parallelism: expert + pipeline + tensor
python -m vllm.entrypoints.openai.api_server \
  --model moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 3 \
  --expert-parallel-size 72 \
  --max-model-len 1048576 \
  --dtype bfloat16 \
  --enable-chunked-prefill \
  --gpu-memory-utilization 0.9

Qual plano se adequa depende de quão honesto você é quanto ao tráfego. O Plano A comprova que o pipeline funciona e atende uso interno leve. O Plano B é onde a maioria das implantações de produção vai parar — dois nós são um investimento consideravelmente mais simples que um rack, e contextos de 512K cobrem a grande maioria das cargas de trabalho reais. O Plano C é para o caso específico em que contextos de um milhão de tokens ou altíssima concorrência são o produto, não uma opção. O salto entre os níveis é um salto em disciplina de custos, não apenas em capacidade.

Três Componentes de Infraestrutura Open Source

O K3 foi lançado com três peças de infraestrutura de treinamento/inferência abertas:

MoonEP

Uma biblioteca de comunicação de alto desempenho para MoE fino em escala hipergigante. Sob paralelismo de especialistas, mantém eficiência de comunicação máxima mesmo com cargas desbalanceadas — e pode ser portada diretamente para suas próprias implantações MoE.

git clone https://github.com/MoonshotAI/MoonEP
# Integrate as a custom expert-parallel backend in vLLM

FlashKDA

Kernels CUDA de alto desempenho para o KDA: no H20, o prefill roda de 1,72× a 2,22× mais rápido que o baseline flash-linear-attention. Encaixa como backend substituto.

AgentEnv

Um sistema de sandbox construído com a KVCache.ai que oferece isolamento de alta fidelidade para treinamento de agentes em larga escala — snapshots, restore e fork para fluxos de trabalho paralelos de agentes.

# AgentEnv sandbox example
# Isolated Python runtimes with fast snapshotting
pip install agent-env
agent-env run --snapshot --max-concurrency 128

Chamando a API

Depois de implantado, o K3 expõe uma API compatível com o padrão OpenAI:

# Text inference
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Kimi-K3",
    "messages": [{"role": "user", "content": "Write a Python function implementing quicksort"}],
    "max_tokens": 1024,
    "temperature": 0.7
  }'

# Multimodal (image understanding)
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Kimi-K3",
    "messages": [
      {"role": "user", "content": [
        {"type": "text", "text": "What is in this image?"},
        {"type": "image_url", "image_url": {"url": "https://example.com/photo.jpg"}}
      ]}
    ],
    "max_tokens": 512
  }'

Dicas Práticas

Não rode em BF16. Uma exigência de 5,6TB de memória significa no mínimo 30 H100s — péssimo custo-benefício. O MXFP4 é a recomendação oficial, com QAT embutido, então a perda de precisão é mínima.
Usuários de H20: o stack CANN da Ascend (Huawei) lançou suporte nativo Day-0 ao MXFP4 em 27 de julho — veja a documentação de implantação das Ascend 950PR/DT.
Ajuste o comprimento de contexto conforme a necessidade. Se você não precisa de 1M de contexto, defina max-model-len como 131072 e a memória do KV cache cai para um oitavo.
MoonEP + FlashKDA merecem atenção à parte: nenhum dos dois é exclusivo do K3 — ambos podem ser portados para o pipeline de implantação de qualquer modelo MoE.