Os pesos abertos do Kimi K3 chegaram: 1,56 TB e quem consegue rodá-lo

A Moonshot liberou os pesos abertos do Kimi K3 em 27 de julho de 2026, onze dias depois de o modelo estrear via API. O download é público e está disponível de verdade. Mas, com 1,56 TB distribuídos em 96 shards safetensors, ele também deixa claro para a maioria das pessoas que “aberto” e “executável” não são sinônimos. Veja o que foi lançado, o que a licença permite e o que é necessário para servi-lo.

O que veio no lançamento da Moonshot

O checkpoint completo está no Hugging Face, em moonshotai/Kimi-K3, com um espelho no ModelScope para usuários na China. O repositório ocupa 1,56 TB: são 96 shards safetensors, além de config.json, do código de modelagem e tokenização (modeling_kimi_k3.py, encoding_k3.py e um modelo tiktoken com vocabulário de 160K), pré-processamento de visão e o arquivo LICENSE. O relatório técnico foi publicado junto, no repositório MoonshotAI no GitHub.

Há três pontos no model card mais relevantes do que a contagem de parâmetros exibida na manchete:

• O model card confirma 104B de parâmetros ativos de um total de 2,8T: 16 dos 896 experts roteados por token, mais 2 experts compartilhados, ao longo de 93 camadas. Essa contagem ativa não era pública antes da liberação dos pesos.
• Os pesos já nascem em MXFP4. A Moonshot aplicou treinamento consciente de quantização desde a etapa de SFT, com ativações MXFP8. Não se trata de uma quantização posterior de um checkpoint BF16: os pesos de 4 bits são o lançamento.
• A atenção é dividida em 69/24 entre camadas Kimi Delta Attention e Gated MLA, com uma janela de contexto de 1.048.576 tokens.

Os sinais de adoção apareceram rapidamente. Em 28 de julho de 2026, um dia após o commit inicial entrar no histórico de commits, o repositório já tinha 6,6 mil curtidas e as conversões da comunidade já estavam surgindo: unsloth/Kimi-K3-GGUF foi criado naquela mesma noite, enquanto GrEarl/Kimi-K3-GGUF recebeu uma conversão Q2_K completa na manhã seguinte.

A Licença Kimi K3 não é MIT

Os principais modelos Kimi anteriores foram disponibilizados sob uma licença MIT modificada. O K3 não. Ele usa um documento chamado Kimi K3 License. Embora seu texto derive da MIT — permitindo usar, copiar, modificar, mesclar, publicar, distribuir, sublicenciar, vender, fazer fine-tuning e criar derivados —, há duas condições que merecem atenção antes de construir algo sobre ele.

A cláusula de Model-as-a-Service. O trecho central diz: "If the Licensee or any of its affiliates operates a Model as a Service business, and the aggregate revenue of the Licensee and its affiliates exceeds 20 million US dollars ... in total over any consecutive 12 months, the Licensee must enter into a separate agreement with Moonshot AI before using the Software or its derivative works for any commercial purpose." A licença define MaaS como disponibilizar a terceiros acesso de inferência ou fine-tuning de forma que eles possam controlar entradas, parâmetros ou dados de treinamento. Ela exclui explicitamente duas situações que não são MaaS: produtos voltados ao usuário final nos quais a capacidade do modelo está incorporada a recursos específicos e o simples encaminhamento de solicitações para modelos hospedados por outra empresa.

A cláusula de atribuição. Se um produto comercial construído com o K3 ultrapassar 100 milhões de usuários ativos mensais ou US$ 20 milhões de receita mensal, o nome "Kimi K3" deverá aparecer em destaque na interface desse produto.

As duas cláusulas são dispensadas para uso exclusivamente interno — isto é, qualquer uso que não exponha o modelo, suas saídas ou suas capacidades a terceiros — e para acesso pelos produtos oficiais da Moonshot ou por parceiros certificados de inferência. Lendo as exceções literalmente: o fine-tuning do K3 com dados internos é coberto pela exceção de uso interno na Seção 4(a), e incorporá-lo como recurso de um produto é citado na Seção 2 como algo que não constitui MaaS. Revender inferência do K3 como serviço é o cenário para o qual as cláusulas adicionais foram escritas, e o limite de US$ 20 milhões é o ponto em que deixa de ser uma questão de licença e passa a ser uma negociação contratual. Leia a LICENSE antes de comprometer seu roadmap com ela; este resumo é uma interpretação do texto, não aconselhamento jurídico.

A realidade de hardware por trás de 1,56 TB

Qualquer pessoa pode baixar os pesos abertos do Kimi K3. Servi-los é outra história.

A receita oficial do K3 no vLLM deixa o requisito claro: ao menos 8× GB300, com múltiplos nós para tráfego de produção de verdade. No lado da AMD, ela lista ao menos 8× MI355X ou MI350X usando a imagem ROCm. O SGLang também publica um guia do K3 voltado à mesma classe de hardware.

Para quem realmente vai provisionar essa infraestrutura, as notas operacionais da receita merecem leitura redobrada. O serving usa a imagem dedicada vllm/vllm-openai:kimi-k3 — ou vllm/vllm-openai_rocm:kimi-k3 na AMD —, não o vLLM padrão. O tráfego entre nós pede --all2all-backend deepep_v2 sobre RDMA ou flashinfer_nvlink_one_sided sobre NVLink, com UCX_TLS="rc,cuda_copy" definido para manter a transferência do cache KV no RDMA. A recomendação de backend MoE muda conforme a topologia: deep_gemm_mega_moe em implantações com paralelismo de experts e flashinfer_trtllm para TP>1. A receita também alerta que o K3 ocasionalmente gera um formato de chamada de ferramenta que seu próprio parser rejeita. Por isso, validação de schema e retentativas devem fazer parte da camada de serving desde o primeiro dia.

A saída mais comum seria quantizar ainda mais o modelo, mas isso quase não ajuda neste caso: o MXFP4 já equivale a aproximadamente 4,25 bits por parâmetro. A margem de compressão que tornou modelos da classe de 1T viáveis em uma workstation já foi consumida antes mesmo do download. A primeira conversão comunitária GGUF de 2 bits que apareceu ocupa 928 GB em 94 shards, uma economia de 40% sobre um número que nunca foi o gargalo principal.

Some o cache KV para qualquer coisa próxima ao contexto de 1 milhão de tokens, e o conjunto de trabalho cresce ainda mais. O relato mais chamativo de self-hosting no primeiro dia veio de uma equipe que afirmou rodar os pesos MXFP4 oficiais em 80× RTX 5090, usando Ethernet comum, sem HBM e sem re-quantização, a aproximadamente 20 tokens por segundo em fluxo único, sem otimização. É uma alegação não auditada, feita no primeiro dia e em uma única publicação — não um benchmark —, e uma configuração não define um mínimo. Ela só vale como indicativo de direção: o caminho relatado mais barato para executar o K3 em silício de consumo envolveu oitenta GPUs topo de linha e entregou uma velocidade que a maioria consideraria lenta.

Vale mencionar o Ollama especificamente, porque é a primeira opção que muita gente tenta. A entrada existe na biblioteca, mas aponta para kimi-k3:cloud, o roteamento hospedado do Ollama, e não para um pull local. Hoje não há caminho para rodar esse modelo em laptop ou em uma única workstation. Como MXFP4 é o formato nativo, e não uma quantização de conveniência, a rota habitual da comunidade — re-quantização agressiva — tem menos espaço para atuar do que tinha na linha K2. O suporte no llama.cpp ainda está em evolução; confira o status atual em vez de assumir qualquer um dos lados.

Onde rodar o Kimi K3 hoje

Para quase todo mundo, a resposta prática é usar um endpoint hospedado. E o lançamento dos pesos abertos fez o que lançamentos desse tipo costumam fazer: provedores terceiros ficaram disponíveis em um dia. Os preços abaixo são por milhão de tokens, entrada/saída, conforme listados em 28 de julho de 2026.

Antes de escolher, vale checar dois pontos. Primeiro, a janela de contexto varia muito. A Nebius cobra o mesmo preço de tabela, mas entrega uma janela de 8K, o que elimina o principal motivo para usar o K3. Segundo, a quantização também varia: a Moonshot serve MXFP4 nativo, a Baseten roda FP8 e vários provedores nem informam a precisão. Para trabalho agêntico de longo prazo, corresponder à precisão de referência e à janela completa de 1M geralmente importa mais do que a diferença de preço; para prompts curtos em alto volume, latência e disponibilidade regional podem ser mais importantes que ambos.

Além dos endpoints diretos, o OpenRouter os agrega sob uma única chave, e gateways multimodelo roteiam o K3 ao lado de outros modelos chineses de fronteira com pesos abertos. O AIReiter disponibiliza essa mesma classe de modelos por uma API compatível com Anthropic, caso suas ferramentas já usem esse protocolo. O endpoint da própria Moonshot oferece interfaces compatíveis tanto com OpenAI quanto com Anthropic. Todos os detalhes de limites e faixas estão no detalhamento de preços do Kimi K3.

Hospedar por conta própria ou usar um endpoint?

Faça as contas primeiro. A US$ 3/US$ 15 por milhão de tokens, um bilhão de tokens de saída custa US$ 15.000, e um bilhão de tokens de entrada custa US$ 3.000. Compare isso ao mínimo viável para self-hosting: um nó da classe 8× GB300, uma compra de capital para data center ou um aluguel cobrado por hora de acelerador, além de interconexão, energia, refrigeração e um engenheiro que conheça --all2all-backend de cor. Nem a NVIDIA nem os grandes provedores de nuvem publicam preço de tabela para essa configuração. Portanto, baseie a comparação em uma cotação atual, não em uma regra de bolso, e lembre-se de que o custo do hardware é fixo, enquanto o custo da API cresce conforme o uso real.

Hospedar os pesos abertos do Kimi K3 por conta própria faz sentido em três situações — e elas são mais restritas do que parecem:

1. Exigências de ambiente isolado ou residência de dados que nenhum endpoint de terceiros consegue atender. Este é o caso mais forte, e custo não é o fator decisivo.
2. Fine-tuning com dados proprietários. A licença permite isso de forma direta, e nenhum endpoint hospedado oferece o mesmo. O custo de treinamento é separado e maior que o custo de serving.
3. Volume sustentado em saturação. Se você mantém um cluster multinó ocupado sem parar, hardware próprio pode custar menos do que a cobrança por token. Picos ocasionais não se enquadram aqui.

Se nenhum desses cenários descreve seu caso, use um endpoint e trate os pesos como uma opção, não como um plano. Para a maior parte das equipes, o valor de um modelo de fronteira com pesos abertos não está em executá-lo. Está no fato de que o preço da versão hospedada agora precisa competir com a possibilidade de elas poderem executá-lo.

Perguntas frequentes

O Kimi K3 é open source?

Ele tem pesos abertos. O checkpoint completo de 2,8T pode ser baixado, e a Licença Kimi K3 permite uso, modificação, distribuição e fine-tuning. Os dados de treinamento e o pipeline completo de treinamento não foram lançados, e a licença acrescenta uma cláusula acionada por receita para operadores de Model-as-a-Service. Portanto, não é open source no sentido da OSI.

Posso rodar o Kimi K3 localmente no Ollama?

Não. A entrada kimi-k3 do Ollama é kimi-k3:cloud, que encaminha para um endpoint hospedado. Os pesos MXFP4 nativos ocupam 1,56 TB, e um GGUF comunitário de 2 bits ainda ocupa 928 GB. Portanto, não há caminho local em hardware de consumo.

Sob qual licença estão os pesos do Kimi K3?

Sob a Licença Kimi K3: derivada da MIT, mas exigindo um acordo separado com a Moonshot caso você opere um negócio de Model-as-a-Service que ultrapasse US$ 20 milhões de receita em qualquer período de 12 meses, além de atribuição na interface acima de 100 milhões de MAU ou US$ 20 milhões de receita mensal. O uso interno é isento das duas exigências.

Onde posso usar o Kimi K3 sem baixá-lo?

Na API da própria Moonshot e no app Kimi, além de Baseten, Fireworks e Nebius. Em 28 de julho de 2026, os quatro listavam US$ 3/US$ 15 por milhão de tokens como tarifa-base, mas a comparação tem ressalvas: a Fireworks também oferece uma faixa de US$ 4,50/US$ 22,50, e a Nebius entrega a tarifa-base com janela de contexto de 8K em vez de 1M. Para saber o que é o modelo e como ele se sai em benchmarks, veja a visão geral do Kimi K3.