Kimi K3 é o modelo lançado pela Moonshot AI em 16 de julho de 2026. Tem 2,8 trilhões de parâmetros em arquitetura Mixture-of-Experts, com 896 experts dos quais 16 são ativados por token (cerca de 32 bilhões de parâmetros ativos), contexto de 1 milhão de tokens e multimodalidade nativa para texto, imagem e vídeo. É o maior modelo open-weight já lançado e o primeiro da classe de 3 trilhões de parâmetros.

Kimi K3: o Maior Modelo Open-Weight do Mundo (2,8 Trilhões de Parâmetros)

Q: Um MoE de 2,8T com 32B ativos é barato de rodar?

Só metade da conta fica barata. O custo de compute por token é o de um modelo de aproximadamente 32 bilhões de parâmetros, porque apenas 16 dos 896 experts são executados a cada token. Mas a memória exigida é a dos 2,8 trilhões de parâmetros inteiros: como o roteamento é decidido token a token e camada a camada, qualquer expert pode ser necessário a qualquer momento e todos precisam estar residentes. Em pesos MXFP4 isso é da ordem de 1,4 TB, antes do cache de atenção.

Q: O Kimi K3 é open source?

Não pela definição da OSI. O K3 é open-weight: a Moonshot AI anunciou a publicação dos pesos até 27 de julho de 2026, mas não do código de treinamento nem do dataset. A expectativa é de uma licença MIT modificada, o que até 18 de julho de 2026 ainda não estava confirmado. Você pode baixar, inspecionar, servir e ajustar o modelo, mas não reproduzi-lo do zero.

Q: Por que treinar o modelo já quantizado (QAT) faz diferença?

O K3 foi treinado com quantization-aware training desde a fase de SFT, com pesos em MXFP4 e ativações em MXFP8. Isso significa que o formato de baixa precisão não é uma compressão aplicada depois do treino, e sim o formato nativo em que o modelo aprendeu a operar. Na prática degrada bem menos que a quantização post-hoc, e o tamanho publicado dos pesos já é o tamanho otimizado, e não um ponto de partida a ser comprimido.

Em 16 de julho de 2026, a Moonshot AI anunciou o Kimi K3. São 2,8 trilhões de parâmetros em arquitetura Mixture-of-Experts, 896 experts com 16 ativados por token, ~32 bilhões de parâmetros ativos a cada passo, 1 milhão de tokens de contexto e multimodalidade nativa para texto, imagem e vídeo. É o maior modelo open-weight já lançado e o primeiro da classe de 3 trilhões de parâmetros.

O número que chama atenção é o 2,8T. O número que importa é outro — e é sobre ele que a maior parte da cobertura escorrega.

⚡ Resumo

O K3 é o primeiro modelo de pesos abertos a disputar o topo absoluto com a fronteira fechada: 1º lugar no Frontend Code Arena, 3º no GDPval-AA v2, 2º no AA-Briefcase. Mas ele é barato em compute e caríssimo em memória: você paga inferência de um modelo de 32B e aluga VRAM de um modelo de 2,8T. Entender essa assimetria é o que separa uma decisão de arquitetura de um susto na fatura.

O que a Moonshot lançou

A ficha técnica, sem adjetivos:

2,8 trilhões de parâmetros totais, arquitetura Mixture-of-Experts.
896 experts, dos quais 16 são ativados por token — cerca de 32B de parâmetros ativos.
1 milhão de tokens de contexto.
Multimodal nativo: texto, imagem e vídeo no mesmo modelo, não em adaptadores acoplados depois.
Treinado com QAT (quantization-aware training) desde a fase de SFT: pesos em MXFP4, ativações em MXFP8.
Um único nível de esforço de raciocínio: "max". Não há modo econômico — ele pensa muito, sempre, e consome tokens de acordo.
API oficial: US$ 3,00 por milhão de tokens de entrada (cache miss), US$ 0,30 com cache hit e US$ 15,00 por milhão de tokens de saída.

O nível de esforço único é uma escolha de produto com consequência direta na conta: sem um modo "low" ou "high", toda requisição paga o custo de raciocínio máximo. Em cargas onde metade das chamadas é trivial, isso pesa.

O ponto que quase todo mundo erra: compute barato, memória cara

Quando se lê "2,8 trilhões de parâmetros, mas só 32B ativos por token", a conclusão intuitiva é que o modelo custa como um 32B. Isso é verdade para metade da conta e falso para a outra metade.

O que fica barato: os FLOPs

A cada token gerado, o roteador escolhe 16 experts entre 896 e só esses 16 são executados. A multiplicação de matrizes acontece sobre ~32B de parâmetros, não sobre 2,8T. Logo, o custo aritmético por token — e, com um servidor bem configurado, a latência — é o de um modelo de ~32B. É por isso que a MoE existe: ela desacopla capacidade de compute.

O que continua caro: a VRAM

O roteamento é decidido token a token e camada a camada, em tempo de execução, e não é previsível. O expert 734 pode ser necessário no próximo token da camada 12. Consequência: todos os 2,8 trilhões de parâmetros precisam estar residentes em memória, mesmo que 96% deles fiquem ociosos em qualquer passo individual.

Em MXFP4, o formato nativo do K3, os pesos ocupam algo da ordem de 1,4 TB. Quantizações comunitárias mais agressivas devem reduzir isso — perto de 1 TB em torno de 2 bits, e algo como 650 a 700 GB em quantizações de ~1,8 bit, com perda de qualidade crescente. E tudo isso é antes do cache de atenção, que num contexto de 1 milhão de tokens é um orçamento separado e nada desprezível.

🧠 A armadilha do batching

Em inferência de um usuário só, dá para contornar parte do problema com offload de experts para RAM ou NVMe — funciona, com throughput baixo. Mas quando você serve vários pedidos em paralelo, os tokens de usuários diferentes ativam experts diferentes, e a união dos experts requisitados pelo lote se aproxima rapidamente de todos eles. Em escala de produção, a economia de memória some e a economia de compute encolhe. MoE grande é uma arquitetura que premia quem tem VRAM, não quem tem paciência.

A regra prática

Recurso	Escala com	No caso do K3
FLOPs por token / latência	Parâmetros ativos	~32B — barato
Memória para os pesos	Parâmetros totais	2,8T — caro
Cache de atenção (KV)	Contexto × lote	1M de tokens — significativo, e por sessão
Banda de memória	Experts tocados por lote	Cresce com o batch, não com o token

Essa tabela vale para qualquer MoE, não só para o K3: sempre que alguém comparar um MoE gigante a um modelo denso pequeno "porque os ativos são parecidos", a comparação só é honesta na linha de cima.

Os benchmarks, e o que eles significam

Números medidos por Artificial Analysis e Arena.AI em julho de 2026:

Benchmark	Kimi K3	Posição
Arena.AI Frontend Code Arena	1.679	1º — à frente de Claude Fable 5 e GPT-5.6 Sol
GDPval-AA v2 (44 profissões, 9 setores)	1.687	3º — atrás de Fable 5 Max (1.815) e GPT-5.6 Sol Max (1.747,8)
AA-Briefcase (agêntico, longo horizonte)	1.527	2º — à frente do GPT-5.6 Sol Max (1.495), atrás do Fable 5 Max (1.587)
Automação de tarefas reais	—	1º em 4 de 8 (Automation Bench, SpreadsheetBench 2, BrowseComp)

A leitura prática:

Em geração de front-end, o K3 é o melhor modelo do mercado hoje — aberto ou fechado. Não é empate técnico, é primeiro lugar.
Em trabalho profissional amplo (GDPval), ele ainda não alcançou o topo. A distância para o Fable 5 Max é real e mensurável. Quem precisa do teto absoluto de qualidade em tarefas de conhecimento continua olhando para os fechados.
Em tarefas agênticas de longo horizonte, ele já passou o GPT-5.6 Sol Max. Esse é o resultado mais consequente da lista: agente de longo horizonte era exatamente onde os modelos abertos costumavam desmanchar.

O quadro geral é o que interessa: um modelo cujos pesos você pode baixar está empatando ou vencendo a fronteira fechada em três de quatro eixos. Há um ano isso não acontecia.

Open-weight não é open source

Vale insistir na distinção, porque ela é rotineiramente atropelada.

A Moonshot anunciou a publicação dos pesos até 27 de julho de 2026. Não do código de treinamento e não do dataset. A licença esperada é uma MIT modificada, o que até 18 de julho de 2026 ainda não estava confirmado — e o adjetivo "modificada" costuma carregar restrições de uso que merecem leitura atenta antes de qualquer compromisso comercial.

Pela definição da Open Source Initiative, isso não é open source. É open-weight: você pode baixar, inspecionar, servir, avaliar e ajustar o modelo. Não pode reproduzi-lo do zero nem auditar em que dados ele foi treinado.

Ainda assim, é uma diferença enorme em relação a uma API fechada. Open-weight te dá o que importa na prática: o modelo não some, não muda sem aviso e não aumenta de preço no meio do seu contrato — o mesmo argumento que exploramos em o que fazer quando o modelo que você usa é descontinuado.

QAT e MXFP4: por que treinar já quantizado é decisão inteligente

O caminho convencional é treinar em alta precisão e comprimir depois. Funciona, mas cobra: a quantização post-hoc sempre perde alguma coisa, e a perda não se distribui uniformemente pelas capacidades do modelo — às vezes derruba justamente o raciocínio longo que você queria preservar.

O K3 inverte isso. Com quantization-aware training desde a fase de SFT, o modelo aprende a operar dentro das restrições numéricas do MXFP4. A baixa precisão deixa de ser um dano aplicado depois e passa a ser o ambiente nativo em que os pesos se acomodaram. As consequências práticas são três:

Degradação menor na precisão de publicação do que um post-hoc equivalente.
O tamanho publicado já é o tamanho otimizado. Os ~1,4 TB do MXFP4 não são um ponto de partida a comprimir — são o modelo como ele foi treinado. Quem esperar "a versão quantizada oficial que cabe em meio nó" vai esperar sentado.
Coerência de hardware. MXFP4 e MXFP8 são formatos de bloco com suporte nativo nas GPUs de geração recente. A escolha alinha o modelo com o silício que existe, em vez de exigir emulação.

Para um modelo de 2,8T, isso não é detalhe de implementação. É provavelmente a decisão que tornou o lançamento viável.

Realidade de hardware: o K3 completo não cabe em um nó hoje

Aqui vamos ser diretos, porque a alternativa seria vender fumaça.

Os pesos ainda não são públicos — saem até 27 de julho de 2026. Quando saírem, o K3 completo vai exigir mais VRAM do que um único nó de 8 GPUs entrega hoje. O maior nó com estoque no nosso catálogo neste momento é de 8× H100 de 80 GB, ou seja, 640 GB de VRAM agregada. Os pesos em MXFP4 estão na casa de 1,4 TB. Nem com folga, nem com aperto: não cabe. E não existe multi-nó com interconexão de alta velocidade para somar máquinas num único job — cada deploy é uma VM.

Quantizações comunitárias mais agressivas, na faixa de 650 a 700 GB, chegariam perto de um nó de 8× 80 GB — mas ainda por cima da linha, e com perda de qualidade que ninguém mediu, porque os pesos não existem publicamente.

📌 Nosso compromisso, sem promessa

Vamos publicar aqui o teste real assim que os pesos e as primeiras quantizações da comunidade aparecerem — com números de VRAM, throughput e custo por hora medidos por nós, não estimados. Até lá, não vamos anunciar deploy de um clique para um modelo que ninguém rodou.

O que muda para quem constrói produto no Brasil

O K3 não é, hoje, um modelo que você vai colocar em produção. Ele é um marco — e marcos mudam decisões de arquitetura mesmo quando você não usa o artefato em si.

1. A aposta em open-weight ficou mais segura

Quem escolheu construir sobre pesos abertos apostava numa curva. A curva se confirmou: um modelo aberto agora lidera um benchmark de fronteira e supera um flagship fechado em tarefa agêntica.

2. O teto sobe, o piso sobe junto

Cada geração de fronteira aberta puxa as classes menores. As técnicas do K3 — QAT nativo, roteamento esparso, multimodalidade integrada — aparecem em modelos de 30B a 700B nos meses seguintes. É aí que está o seu produto.

3. O que já roda hoje resolve a maior parte dos casos

Esta é a parte pragmática. GLM-5.2 (753B, MIT, 1M de contexto), Kimi K2, DeepSeek-R1, Qwen3 e Llama rodam agora, em instância dedicada, com custo por hora previsível. Para RAG corporativo, agentes de suporte, geração de código, extração de documentos e classificação, a diferença entre esses modelos e a fronteira absoluta raramente é o que decide o sucesso do produto — a qualidade dos seus dados e do seu retrieval decide muito mais.

4. Instância dedicada é controle real

Rodando o modelo você mesmo, os pesos, os logs e os prompts ficam sob seu controle — nada é enviado para a API de um terceiro que pode treinar em cima, mudar de política ou depreciar o endpoint. Somos uma empresa brasileira: cobrança em reais, sem exposição cambial nem IOF surpresa no fim do mês, e suporte em português. Se a conta fecha ou não, discutimos em detalhe em quando self-hosting compensa.

# O que dá para subir hoje: endpoint OpenAI-compatible com vLLM
from openai import OpenAI

client = OpenAI(
    base_url="https://sua-instancia.gpubrasil.com.br/v1",
    api_key="sua-chave-local",
)

resp = client.chat.completions.create(
    model="zai-org/GLM-5.2",   # ou Kimi K2, DeepSeek-R1, Qwen3, Llama
    messages=[{"role": "user", "content": "Resuma este contrato e liste os riscos."}],
)
print(resp.choices[0].message.content)

O open-weight chegou na fronteira. O que roda hoje já resolve o seu caso.

Suba GLM-5.2, Kimi K2, DeepSeek-R1, Qwen3 ou Llama em instância dedicada — por hora, em reais, com suporte em português. Ganhe R$ 25 grátis para testar.

Começar Grátis →

Perguntas frequentes

O que é o Kimi K3?

É o modelo lançado pela Moonshot AI em 16 de julho de 2026: 2,8 trilhões de parâmetros em arquitetura Mixture-of-Experts, com 896 experts dos quais 16 são ativados por token (~32B ativos), 1 milhão de tokens de contexto e multimodalidade nativa para texto, imagem e vídeo. É o maior modelo open-weight já lançado e o primeiro da classe de 3 trilhões de parâmetros.

Um MoE de 2,8T com 32B ativos é barato de rodar?

Só metade da conta fica barata. O compute por token é o de um modelo de ~32B, porque apenas 16 dos 896 experts rodam a cada token. Mas a memória exigida é a dos 2,8T inteiros: o roteamento é decidido token a token e camada a camada, então qualquer expert pode ser necessário a qualquer momento e todos precisam estar residentes. Em MXFP4 isso fica na casa de 1,4 TB, antes do cache de atenção do contexto de 1M.

O Kimi K3 é open source?

Não pela definição da OSI. É open-weight: a Moonshot anunciou a publicação dos pesos até 27 de julho de 2026, mas não do código de treino nem do dataset. A licença esperada é uma MIT modificada, ainda não confirmada até 18 de julho de 2026. Você pode baixar, servir e ajustar o modelo — não reproduzi-lo do zero.

Por que treinar o modelo já quantizado (QAT) faz diferença?

Porque a baixa precisão deixa de ser um dano aplicado depois do treino. Com quantization-aware training desde a fase de SFT, o K3 aprendeu a operar dentro das restrições do MXFP4 (ativações em MXFP8). Degrada menos que a quantização post-hoc, alinha o modelo com o suporte nativo do silício recente e faz com que o tamanho publicado já seja o tamanho otimizado, e não um ponto de partida a comprimir.

Conclusão

O Kimi K3 é a prova de que a fronteira deixou de ser território exclusivo dos modelos fechados. Um modelo cujos pesos qualquer um poderá baixar em poucos dias lidera o Frontend Code Arena e passa um flagship proprietário em tarefa agêntica de longo horizonte. Isso muda o cálculo de risco de quem constrói.

Mas ele também é um lembrete de que capacidade e acessibilidade não andam juntas automaticamente. Pesos abertos que exigem mais de um terabyte de VRAM são abertos no papel e restritos na prática — pelo menos até o hardware alcançar, ou até a comunidade encontrar quantizações que caibam sem destruir o modelo. Vamos medir e publicar quando isso acontecer.

Enquanto isso, o trabalho continua com o que roda: uma classe de modelos abertos que, doze meses atrás, seria descrita como fronteira — e que hoje sobe numa instância dedicada, paga por hora e em reais, sem mandar um único prompt para a API de ninguém.