Quanto custa rodar o Kimi K3: a matemática do maior modelo open-source

O peso dos números

O Kimi K3, lançado em julho de 2026 pela chinesa Moonshot AI, é o maior modelo de código aberto já publicado: 2,8 trilhões de parâmetros totais. Mas graças à arquitetura Mixture of Experts (MoE), apenas ~104 bilhões de parâmetros são ativados por token — 3,7% do total. Essa eficiência é o que torna o modelo economicamente viável de servir.

Mas “viável” não significa “barato”. A conta de memória é implacável: carregar 2,8 trilhões de parâmetros em precisão nativa de 4 bits (MXFP4) exige 1,4 terabytes de RAM só para os pesos. Some mais 15 GB para o KV-cache, 30 GB para ativações e 30 GB de overhead de runtime — o total passa de 1,5 TB.

Por que a arquitetura reduz o custo

O Kimi K3 foi treinado com Quantization-Aware Training (QAT) em precisão nativa de 4 bits. Isso significa que o modelo aprendeu a operar em 4 bits durante o treinamento — ao contrário de modelos treinados em 16 bits e comprimidos depois, que perdem qualidade na quantização. O resultado é um modelo que roda eficientemente em MXFP4 sem degradação de inteligência.

Além disso, três inovações arquiteturais trabalham juntas para reduzir o custo computacional:

• Kimi Delta Attention (KDA): mantém um estado de atenção de tamanho fixo, reduzindo a memória do KV-cache em até 75% comparado à atenção padrão.
• Attention Residuals: cada camada da rede neural pode acessar saídas de camadas anteriores com pesos aprendidos, aumentando a eficiência do fluxo de informação.
• Stable LatentMoE: os especialistas do MoE operam em um espaço latente comprimido, mantendo o custo baixo por token.

O conjunto dessas otimizações entrega ~2,5× mais eficiência de escala comparado ao Kimi K2, o modelo anterior da Moonshot.

A decisão de hardware

Com 1,5 TB de RAM necessários, uma única GPU está fora de questão. A conta básica: seriam necessárias 19 H100s (80 GB cada) ou 11 H200s (141 GB cada). Mas há uma nuance importante: GPUs Hopper (H100/H200) conseguem carregar pesos em 4 bits, mas fazem dequantização em tempo de execução — ou seja, perdem os benefícios de velocidade da precisão nativa.

Para extrair o máximo do K3, o ideal são GPUs da geração Blackwell (B200/B300) da NVIDIA ou MI350X/MI400 da AMD, que executam MXFP4 nativamente. O vLLM, framework de inferência recomendado, sugere no mínimo 8× B300s para produção.

Traduzindo para a realidade brasileira: self-hosting do Kimi K3 não é viável com hardware local. A opção prática é alugar GPUs em nuvem — e aí a decisão é entre servidores dedicados (Bare Metal GPUs) ou usar a API serverless do provedor.

Self-host vs. API: quando vale a pena

Alugar 8× B300s em um provedor como DigitalOcean custa na faixa de US$ 30-50/hora. Se você processa centenas de milhares de tokens por dia, a API serverless pode sair mais barata. Mas para cargas de trabalho contínuas — como um chatbot interno que processa milhões de tokens diários — o self-hosting em GPUs dedicadas começa a fazer sentido financeiro, especialmente porque você elimina a margem do provedor de API.

A decisão também depende da latência: APIs serverless introduzem cold starts e filas em horários de pico. Para aplicações sensíveis à latência (como agentes autônomos que fazem dezenas de chamadas sequenciais), GPUs dedicadas oferecem previsibilidade.

O que isso significa para o ecossistema open-source

O Kimi K3 redefine o que significa “open-weight” em 2026. O código e os pesos estão disponíveis, mas o hardware necessário para executá-lo está uma geração à frente do que a maioria das empresas tem em seus data centers. Isso cria uma nova dinâmica: modelos abertos que são tecnicamente self-hostable, mas economicamente só fazem sentido em infraestrutura de ponta.

Para o ecossistema brasileiro de IA, a lição é clara: a fronteira da acessibilidade está se movendo dos modelos para a infraestrutura. Ter acesso ao código-fonte e aos pesos é necessário, mas não suficiente — sem GPUs de última geração, modelos como o K3 permanecem fora de alcance prático.