Em 16 de julho de 2026, a Moonshot AI lançou o Kimi K3: 2,8 trilhões de parâmetros, arquitetura Mixture-of-Experts com ~32B ativos por token, 1 milhão de tokens de contexto e — o detalhe que muda a conversa — pesos abertos. É o maior modelo open-weight já lançado.

A pergunta que interessa não é "o open-source chegou?", que é marketing. É a versão chata e útil: em quais tarefas o K3 já ganha do melhor modelo fechado, e em quais ainda perde? Vamos comparar com o Claude Fable 5, da Anthropic, benchmark a benchmark — e depois falar da parte que benchmark nenhum mede.

⚡ Resumo honesto

O K3 ganha em código de frontend e em automação de tarefas reais. O Fable 5 ainda lidera em trabalho de conhecimento de longo horizonte. A diferença que mais importa na prática não está nos benchmarks: um é aberto e hospedável, o outro é fechado, cobrado por token e roda só na nuvem do fornecedor. Nenhum dos dois é a resposta certa para todo mundo.

Os dois competidores, em uma linha cada

Kimi K3 (Moonshot AI): 2,8T de parâmetros totais, MoE com 896 experts (16 ativos por token), ~32B ativos, 1M de contexto, multimodal nativo (texto, imagem e vídeo). Treinado com QAT — quantization-aware training — desde a fase de SFT, com pesos em MXFP4 e ativações em MXFP8. Isso importa: um modelo treinado consciente da quantização degrada menos do que um modelo quantizado depois do treino.

Claude Fable 5 (Anthropic): modelo fechado, o mais capaz da linha para raciocínio pesado e trabalho agêntico de longo horizonte. 1 milhão de tokens de contexto, até 128K de saída por requisição. Raciocínio sempre ligado, com cinco níveis de esforço configuráveis (de low a max). Os pesos não saem da nuvem da Anthropic.

Benchmark a benchmark

Os números abaixo vêm de avaliações da Artificial Analysis e da Arena.AI publicadas em julho de 2026.

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

Onde o K3 ganha

O resultado mais forte é o Frontend Code Arena: 1.679, primeiro lugar, à frente do Fable 5 e do GPT-5.6 Sol. Isso não é ruído estatístico nem um benchmark de nicho — é avaliação humana comparativa em geração de interface, uma das tarefas mais pedidas em produção.

Em automação de tarefas reais, o K3 fica em primeiro em 4 dos 8 benchmarks da bateria, incluindo Automation Bench, SpreadsheetBench 2 e BrowseComp. Traduzindo: preencher planilha, navegar em página, executar sequência de passos operacionais — o tipo de trabalho que a maioria das empresas quer automatizar primeiro.

Vale notar também o AA-Briefcase: o K3 marca 1.527 e fica em segundo, acima do GPT-5.6 Sol Max (1.495). Um modelo de pesos abertos passando na frente de um flagship fechado em benchmark agêntico é uma primeira vez.

Onde o Fable 5 ainda lidera

Agora a outra metade, que costuma sumir dos anúncios de lançamento.

No GDPval-AA v2 — tarefas de 44 profissões em 9 setores da economia — o Fable 5 Max marca 1.815 contra 1.687 do K3. São 128 pontos, e o K3 nem fica em segundo: o GPT-5.6 Sol Max (1.747,8) também está na frente. É a diferença mais larga da tabela, justamente no benchmark que mais se parece com "trabalho de escritório de verdade".

No AA-Briefcase, o Fable 5 Max lidera por 1.587 a 1.527. A distância é menor, mas o padrão se repete: quanto mais longo o horizonte da tarefa e mais ela depende de julgamento acumulado ao longo de muitos passos, mais o modelo fechado se descola.

A leitura razoável é que o K3 encostou, mas não empatou. Já ganha em tarefas de execução — escreva este componente, preencha esta planilha, navegue até este dado. Ainda perde quando é preciso manter coerência e critério ao longo de horas de trabalho de conhecimento.

A diferença estrutural que os benchmarks não capturam

Este é o ponto que muda a decisão mais do que qualquer linha da tabela acima.

O Fable 5 é fechado: você paga por token, roda na nuvem do fornecedor e não controla os pesos, a versão nem a política de retenção. Um detalhe concreto: ele exige retenção de dados de 30 dias e não está disponível sob retenção zero. Para quem tem restrição contratual ou regulatória sobre onde o prompt fica armazenado, isso é conversa com o jurídico, não uma flag de configuração.

O K3 é open-weight — e vale a precisão: open-weight não é open source. Os pesos serão publicados (licença esperada: uma MIT modificada, não confirmada até 18 de julho), mas o código de treino e o dataset não. Ainda assim, ter os pesos muda três coisas de verdade:

O trade-off é real e não é pequeno. Modelo fechado é conveniência operacional: uma chave de API e acabou. Self-host de um modelo de 2,8T é infraestrutura séria — e a seção seguinte mostra o tamanho do problema.

Custo: a tabela e a realidade

API contra API

Preço por milhão de tokens Kimi K3 Claude Fable 5
Entrada (cache miss) US$ 3,00 US$ 10,00
Entrada (cache hit) US$ 0,30 —
Saída US$ 15,00 US$ 50,00

Na tabela, o K3 é cerca de 3,3× mais barato nas duas pontas. Mas essa conta engana, e é aqui que entra a maior desvantagem prática do K3.

O problema do nível único de esforço

O K3 tem um único nível de esforço de raciocínio: "max". Não existe modo econômico. Toda requisição — da classificação trivial à análise complexa — passa pelo mesmo raciocínio profundo e gera muitos tokens de saída.

O Fable 5 expõe cinco níveis (low, medium, high, xhigh, max). Numa carga realista, boa parte das chamadas não precisa do topo. Se metade do seu tráfego roda bem em esforço baixo, você corta tokens de saída pela metade nesse pedaço — e a vantagem de 3,3× do K3 encolhe em custo por tarefa concluída, que é a métrica que importa.

Não estamos dizendo que o Fable 5 sai mais barato — na maioria dos cenários não sai. Estamos dizendo que a diferença real é menor que a de tabela, e que quem orçar pela tabela vai errar para menos.

E o custo real de self-host?

Aqui vale ser direto, porque é onde mais se promete besteira.

💡 Realidade de VRAM (verificada em 18 de julho de 2026)

Os pesos do K3 ainda não são públicos — a previsão é sair até 27 de julho de 2026. Pelos tamanhos anunciados: MXFP4 ≈ 1,4 TB, FP16 ≈ 5,6 TB, quantização de ~2 bits ≈ 1 TB e uma quantização agressiva de ~1,8 bits ainda na faixa de 650 a 700 GB. Um nó de 8 GPUs de 80 GB entrega 640 GB. Ou seja: o K3 completo não cabe hoje em um único nó, e nem o MXFP4 nativo cabe em 1.128 GB.

Some a isso que juntar várias máquinas num único job de inferência exige interconexão dedicada entre nós — não se resolve alugando duas VMs separadas. Em decisão prática: self-hostar o K3 completo não é opção realista para a grande maioria das equipes em julho de 2026, mesmo depois que os pesos saírem. Quem tentar vai começar pelas quantizações agressivas que a comunidade publicar, e vai precisar medir quanta qualidade sobra. Vamos publicar aqui o teste real assim que os pesos e as primeiras quantizações aparecerem — com VRAM medida, não estimada.

Então, o que faz sentido escolher hoje?

Sem torcida para nenhum lado:

A conclusão que sobra é menos empolgante e mais útil do que "o aberto ganhou": o open-weight chegou na fronteira em uma categoria e encostou em outra. E o que dá para self-hostar hoje — GLM-5.2 (753B), Kimi K2, DeepSeek-R1, Qwen3, Llama — já resolve a maior parte dos casos reais, por hora e em reais.

Rode um open-weight de ponta hoje, por hora e em reais

Instância dedicada só sua, com os modelos que realmente cabem em uma máquina: GLM-5.2, Kimi K2, DeepSeek-R1, Qwen3 e Llama. Cobrança em reais, suporte em português, sem custo por token.

Começar Grátis →

Perguntas frequentes

O Kimi K3 é melhor que o Claude Fable 5?

Depende da tarefa. O K3 é 1º no Frontend Code Arena (1.679), à frente do Fable 5 e do GPT-5.6 Sol, e lidera em 4 de 8 benchmarks de automação de tarefas reais. O Fable 5 continua na frente em trabalho de conhecimento de longo horizonte: 1.815 contra 1.687 no GDPval-AA v2, e 1.587 contra 1.527 no AA-Briefcase. Não há vencedor único.

Quanto custa a API do Kimi K3 comparada a um modelo fechado?

O K3 cobra US$ 3,00 por milhão de tokens de entrada (US$ 0,30 em cache hit) e US$ 15,00 de saída. O Fable 5 cobra US$ 10,00 e US$ 50,00 — cerca de 3,3× mais nas duas pontas. Mas o K3 só tem o nível de esforço "max", que consome muitos tokens de saída, então a economia real por tarefa concluída é menor que a diferença de tabela.

Dá para hospedar o Kimi K3 no meu próprio hardware?

Em teoria sim, já que os pesos serão abertos — mas é caro e difícil. Em MXFP4 são cerca de 1,4 TB, e mesmo uma quantização agressiva de ~1,8 bits fica em 650 a 700 GB, acima dos 640 GB de um nó de 8 GPUs de 80 GB. Modelos open-weight menores cabem em uma máquina e resolvem a maior parte dos casos hoje.

Open-weight é a mesma coisa que open source?

Não. O K3 é open-weight: os pesos são publicados, mas o código de treino e o dataset não. A licença esperada é uma MIT modificada, ainda não confirmada até 18 de julho de 2026. Na prática você pode baixar, rodar e fazer fine-tuning — só não pode reproduzir o treinamento do zero.

Conclusão

O Kimi K3 é a primeira vez que um modelo de pesos abertos aparece em primeiro lugar em um benchmark de ponta contra os melhores modelos fechados — e, no mesmo lançamento, fica claramente atrás em outro. As duas coisas são verdade ao mesmo tempo, e quem contar só metade está vendendo alguma coisa.

Para quem decide hoje: escolha pela tarefa, não pela ideologia. E, se o critério for controle de dados ou custo em volume, lembre que o modelo mais capaz raramente é o mais prático — um open-weight que cabe numa máquina e roda amanhã vale mais do que um de 2,8 trilhões de parâmetros que você não consegue ligar.

Leia também: Comparativo de LLMs open-source 2026 · Self-hosting de LLM: quando compensa alugar GPU · Rodar open-source sai mais barato que API?