Kimi 3.1 Pro: open weights de 2,8T bate Fable 5.1

Kimi 3.1 Pro encostou na fronteira fechada

Kimi 3.1 Pro é o primeiro modelo open weights que realmente me fez parar o que eu estava fazendo para testar. Não porque tem 2,8 trilhões de parâmetros no papel, mas porque ele bateu o Fable 5.1 em benchmarks independentes e colocou a diferença entre aberto e fechado em cerca de um mês. Para quem opera agentes de código longo, automação financeira ou pipelines com contexto gigante, isso muda a conta de infraestrutura já nesta semana, mesmo com os pesos prometidos só para 4 de novembro de 2026.

A previsão mais citada do mercado era que só veríamos um modelo aberto de nível Fable no fim do ano. A Meta chegou perto há duas semanas, mas em modelo fechado. A Moonshot furou a fila com um bump que parece pequeno no número da versão, de K3 para K3.1 Pro, mas que esconde um salto brutal de pós-treinamento. É o mesmo tipo de movimento que a Z.ai fez da versão 5.2 para 5.3, muito mais computação de RL em centenas de domínios, e não uma arquitetura totalmente nova.

O fato sem hype

A Moonshot lançou o Kimi K3.1 Pro como modelo multimodal da classe 3T, com mistura de especialistas, 2,8 trilhões de parâmetros totais, 104 bilhões ativos por token e janela de 1 milhão de tokens. O foco declarado é trabalho pesado de verdade, como codar projetos inteiros, mexer com Blender e CAD, modelagem financeira e agentes que rodam por horas. Ele já está disponível no site e app da Kimi, no Kimi Work, no Kimi Code e via API em duas variantes, Standard e Highspeed.

Nos testes de terceiros, o resultado é forte e específico. A Artificial Analysis colocou o K3.1 Pro em quarto no Intelligence Index com 55 pontos, atrás do Opus 5.5 com 58 e do Sonnet 5.5 e do Muse Wonder Full com 56. O ganho veio mais da parte agêntica do que de conhecimento geral e ciência. No Code Arena WebDev ele ficou em oitavo com 1.692 pontos, nove posições acima do K3. No Cyber Index ele fez 64 por cento, o maior resultado publicamente acessível, atrás apenas do GPT-6 Sol Daybreak Blue com 69 por cento, que tem acesso restrito. É curioso porque a Moonshot diz que reduziu dados de cyber no treino.

Ponto importante para operador, os pesos ainda não saíram. A API está no ar, mas o download aberto está prometido para 4 de novembro de 2026. Até agora não há licença final, nem definição clara de redistribuição, uso comercial, precisão dos checkpoints ou VRAM mínima para inferência. Então o termo mais honesto hoje é em breve open weights, e não open source. Quem planeja self-host precisa esperar o cartão de modelo completo antes de cravar custo de GPU.

Como funciona na visão de quem opera

Em arquitetura, pense em um MoE gigante e esparso. Dos 2,8 trilhões, só 104 bilhões ativam por token. Isso é bom e ruim ao mesmo tempo. Bom porque o custo por token não explode na mesma proporção do total, ruim porque servir 2,8 trilhões, mesmo em precisão quantizada, exige um cluster com muita memória agregada e atenção especial a balanceamento de especialistas, paralelismo e cache de KV para 1 milhão de tokens. Não é modelo para rodar em uma máquina com duas GPUs. É modelo para provedor, para API ou para empresa com inferência dedicada.

O diferencial técnico que a Moonshot cita é a pilha de RL em escala. Eles dizem que otimizaram cada camada, framework de RL, inferência de contexto longo, eficiência de treino, sandbox, agendamento de rollouts e checagem de qualidade de ambiente, para que cada incremento de computação de RL gere ganho estável em centenas de domínios. Na prática, isso explica o perfil dos benchmarks, melhora agêntica consistente em vez de pico em prova acadêmica. Para quem constrói agentes, esse tipo de pós-treino vale mais do que mais um ponto em MMLU, porque reduz quebra de ferramenta, loop infinito e alucinação em tarefa de várias etapas.

Sobre API e latência, há duas ofertas. A Standard é o endpoint normal. A Highspeed promete mesma inteligência com saída de 2 a 3 vezes mais rápida, custando cerca de duas vezes mais segundo os relatos do lançamento. Minha inferência plausível é que se trata da mesma base de pesos com estratégia diferente de serving, mais paralelismo, speculative decoding mais agressivo ou alocação prioritária de GPUs, e não um modelo destilado menor. Se for isso mesmo, faz sentido pagar o dobro quando time to first token e tokens por segundo travam o seu agente, e ficar na Standard para batch, avaliação offline e tarefas noturnas.

Tem ainda o Kimi Hosted Agents, um ambiente gerenciado 24 por 7 para trabalho longo e colaboração multiagente. Isso importa porque contexto de 1 milhão e agente que roda por horas quebram fácil sem sandbox persistente, checkpoint de estado e retry bem feito. Se você já operou agente de codificação que morre no meio de um refactor grande, sabe que o gargalo quase nunca é só o modelo, é a correia inteira em volta dele.

O que isso muda na prática

Quem ganha agora são times que vivem de agente codificador e automação pesada e estavam presos em preço de fronteira fechada. Se os pesos realmente vierem com licença permissiva para uso comercial, provedores de inferência vão brigar para servir o K3.1 Pro e o preço por milhão de tokens tende a cair rápido. Quem perde margem são os labs fechados que cobravam premium só por serem os únicos no nível Fable 5.1. A vantagem deles cai para produto, distribuição e confiabilidade, e não mais para inteligência bruta.

• Ação prática para esta semana: rode o mesmo eval agêntico nos dois endpoints da Kimi, Standard e Highspeed, com suas ferramentas reais, meça custo por tarefa concluída e não por token, e só então decida. Para a maioria, o caminho é prototipar na Highspeed para validar latência e depois mover carga estável para a Standard ou para self-host quando os pesos saírem.

Se você mantém pipeline com Claude ou GPT como padrão, crie uma rota de fallback para o Kimi em tarefas de código longo, extração de documentos grandes e pesquisa financeira. Não precisa migrar tudo. Comece com 10 a 20 por cento do tráfego, com logs de ferramenta e taxa de sucesso ponta a ponta. E prepare seu harness para 1 milhão de tokens com paginação e compactação de contexto, porque jogar um repositório inteiro no prompt sem estratégia vai estourar seu orçamento mesmo com preço menor por token.

A tensão que ninguém quer admitir

Aqui vai a dúvida real, esse modelo escala fora do data center da Moonshot. Servir 104 bilhões ativos com qualidade exige throughput alto e especialistas bem balanceados, e histórico de MoE aberto mostra que throughput cai e custo sobe quando todo mundo resolve usar ao mesmo tempo. A versão Highspeed 2 a 3 vezes mais rápida cobrando o dobro parece ótima no slide, mas se o seu agente gera 200 mil tokens para concluir uma tarefa, você só trocou o problema de latência pelo problema de conta no fim do mês.

Tem outro ponto sensível, os resultados interativos mais fracos em algumas tarefas e as críticas sobre apresentação de benchmarks e suposta promoção paga não confirmada. Uma coisa não anula a outra. Benchmark bom não prova economia viável, e ruído de marketing não prova que o modelo é ruim. O que prova é rodar sua carga, com suas ferramentas, e medir taxa de conclusão, retrabalho e custo. Minha aposta é que o K3.1 Pro resolve parte do gap de inteligência aberta, mas move o gargalo para serving, engenharia de contexto e avaliação. Que é exatamente onde a maioria dos times mais sofre hoje.

Conclusão

Kimi 3.1 Pro é o sinal mais claro até agora de que open weights encostou na fronteira, com nível Fable 5.1, 104 bilhões ativos e foco real em agentes. A pergunta que fica para você que opera é simples, quanto custa cada tarefa concluída no seu stack, e não cada token. Vai testar essa conta antes dos pesos saírem em novembro ou vai esperar o mercado precificar por você.