Kimi K3.1 Pro: o que a Moonshot comprova sobre 1M de contexto, velocidade e pesos

Há um detalhe no lançamento do Kimi K3.1 Pro que diz mais do que qualquer gráfico. A página de quickstart da API (abre em nova aba), datada de 23 de outubro, foi ao ar com marcadores no lugar de números. No Terminal-Bench 4.0, o modelo marca "[xx.x%]". No Terminal-Bench-Science 0.1, também "[xx.x%]", e a página informa que esse valor fica acima do K3, que marca "[xx.x%]". Um dia depois, o blog técnico (abre em nova aba) trouxe os valores preenchidos.

Isso não é escândalo. É o tipo de descuido que acontece quando documentação e marketing andam em ritmos diferentes. Ainda assim, a página revela a ordem das coisas: a frase "supera o antecessor" já estava escrita antes do número que deveria sustentá-la. Vale ler o resto do anúncio com essa ordem em mente. Este texto separa o que a Moonshot AI demonstra do que apenas declara sobre o K3.1 Pro e sua variante Highspeed.

O que foi lançado

Segundo o blog, o Kimi K3.1 Pro é o primeiro modelo da série K3.1 e o "mais capaz modelo de pesos abertos da classe 3T" que a empresa já fez. A janela de contexto é de 1 milhão de tokens. Tecnicamente, não é uma arquitetura nova: é uma versão do Kimi K3 com pós-treinamento bem maior, feito com aprendizado por reforço conjunto em "centenas de domínios". Junto com ele chega o K3.1 Pro Highspeed, descrito como 2 a 3 vezes mais rápido.

Os dois modelos estão disponíveis no Kimi.ai, no Kimi Work, no Kimi Code e na API. Os pesos completos foram prometidos "até 4 de novembro de 2026".

Sobre o tamanho, convém precisão. A documentação do Kimi Code (abre em nova aba) informa que o K3 tem 2,8 trilhões de parâmetros, mas não atribui número algum ao K3.1 Pro. Como ele é um pós-treinamento do K3, é razoável supor a mesma base. "Classe 3T", porém, é uma categoria, não uma especificação. Quem planeja hospedar o modelo deve esperar o cartão técnico antes de fazer contas de memória.

Um milhão de tokens: a janela existe, a qualidade ainda não foi medida

O que está documentado é concreto. O Kimi Code especifica o limite exato de 1.048.576 tokens. O quickstart da API afirma que o preço é "pay-as-you-go plano, sem faixas por tamanho de contexto". Esse segundo ponto pesa mais do que parece. Vários fornecedores cobram mais caro acima de certo limiar de contexto. Um preço único significa que preencher a janela custa, por token, o mesmo que uma pergunta curta. Os valores ficam numa página separada de preços, que o quickstart não reproduz.

O que não está documentado é mais importante. Nem o blog nem as duas páginas de documentação apresentam qualquer avaliação de recuperação ou raciocínio em contexto longo. Não há curva de desempenho por posição na janela, nem teste de agulha no palheiro, nem comparação entre 128 mil e 1 milhão de tokens. Uma janela de 1M prova apenas que o modelo aceita 1M de tokens na entrada. Não prova que ele usa bem o que está no meio. Quem já colocou um repositório inteiro num prompt sabe que essas duas coisas raramente coincidem.

Dois detalhes do Kimi Code tornam essa lacuna mais relevante na prática:

• O 1M é restrito a planos mais caros. Nos planos novos, o K3.1 Pro exige Plus ou superior, e o contexto de 1M exige Pro ou superior. Nos planos antigos, o modelo pede Moderato ou superior, e o 1M pede Allegretto ou superior.
• O raciocínio não pode ser desligado. O reasoning_effort aceita low, high e max, com max como padrão. Uma requisição com thinking desativado é rejeitada com HTTP 400. Num prompt de 1 milhão de tokens, raciocínio obrigatório no nível máximo pesa em latência e em custo de saída. A documentação não quantifica esse peso.

O que existe, portanto, é capacidade de entrada. Utilidade em contexto longo ainda é uma pergunta em aberto, e a Moonshot não tentou respondê-la.

Highspeed: mais rápido onde, exatamente?

A promessa do Highspeed é a mais fácil de entender e a mais fácil de superestimar. O Kimi Code afirma que a variante tem "capacidades de modelo idênticas" e entrega "aproximadamente 2–3×" a velocidade do Pro. Logo em seguida vem a frase que mais importa para quem constrói agentes: o Highspeed acelera apenas a geração de saída. Chamadas de ferramenta e execução de scripts não mudam.

Isso é aritmética, não ressalva. Imagine um agente de programação em que metade do tempo de parede é o modelo escrevendo e a outra metade é rodar testes, ler arquivos e esperar o terminal. Dobrar a velocidade de geração leva o ganho total para cerca de 1,33×, e não 2×. Quanto mais o fluxo depende de ferramentas, mais o ganho anunciado se dilui. Essa é a lei de Amdahl, e nenhum provedor está isento dela. O caso mais favorável é o chat interativo com respostas longas, em que gerar texto é quase todo o trabalho.

O custo também é explícito: no Kimi Code, o Highspeed consome cerca do dobro da cota da versão regular.

A afirmação de capacidades "idênticas" merece atenção. A Moonshot não diz como obtém a aceleração, e as fontes não trazem benchmark algum rodado no Highspeed. Se a qualidade é de fato idêntica, a diferença está no serviço de inferência, não nos pesos, e isso teria consequências para quem baixar o modelo em novembro. Mas isso é inferência minha, não algo que a empresa afirme. Até haver números do Highspeed nos mesmos testes do Pro, "idêntico" é uma descrição, não uma medição.

Os benchmarks, lidos com a nota de rodapé ao lado

Estes são os números que a Moonshot publicou no blog:

À primeira vista, o K3.1 Pro fica a 0,7 ponto do Opus 5.5 no Terminal-Bench e 7,5 pontos à frente do GPT-6 Astra. É um resultado forte para um modelo que promete pesos abertos. A nota de rodapé do blog, porém, muda a leitura em três pontos:

1. Configuração favorável. Os resultados usam reasoning_effort "max", temperatura 1.0 e top-p 0.95. Ou seja, é o modelo no seu nível mais caro. A Moonshot não diz quanto disso sobra em low ou high.
2. Ambiente de execução escolhido. O Terminal-Bench 4.0 rodou com o harness do Claude Code. Em benchmarks de agente, o harness faz parte do resultado. Trocar o ambiente pode mover vários pontos.
3. Comparação assimétrica. As notas dos concorrentes são "o máximo" entre o que aparece em blogs e no leaderboard oficial. O K3.1 Pro é medido numa configuração específica da Moonshot. Os rivais aparecem pelo seu melhor número disponível, obtido por outras pessoas, em outras condições. Essa escolha até favorece os rivais, o que é honesto. Mas também significa que a diferença de 0,7 ponto não vem de um experimento controlado. São duas fontes lado a lado.

Há ainda os testes que só a própria Moonshot pode rodar: Kimi Code Bench, as avaliações de finanças (+7,2 pontos em Financial Modeling, +11,6 em Financial Research, cerca de 4,2× o K3 em Business Operation) e o Kimi Hallu Bench Hard. Benchmarks internos têm valor como sinal de direção. Não têm valor como prova para terceiros. Até a data deste texto, as fontes oficiais não citam nenhuma reprodução independente.

A discrepância na alucinação

Este é o ponto em que a documentação contradiz a si mesma. O blog afirma que, no Kimi Hallu Bench Hard, a alucinação por afirmação caiu de 23,4% no K3 para 8,3%. Segundo o blog, respostas com pelo menos um erro factual passaram a ocorrer em 42,4% da taxa anterior. O quickstart da API descreve uma avaliação feita com conversas anonimizadas em que usuários haviam sinalizado erros factuais. Ali, a queda é de 23,35% para 6,85%, e a proporção é de 46,4%.

As linhas de base praticamente coincidem: 23,35% arredonda para 23,4%. Os resultados finais, não. Pode ser outra versão do teste, outro checkpoint ou uma revisão entre um dia e outro. As páginas não explicam. Para um modelo vendido também pela redução de alucinação, duas taxas finais diferentes para o que parece ser a mesma medição são exatamente o tipo de inconsistência que deveria ter sido resolvida antes da publicação. O blog acerta ao avisar que se trata de um "teste de estresse, não uma taxa de erro diária". Ainda falta dizer qual dos dois números vale.

O dado mais honesto do anúncio

No xdev-bench-hard, a Moonshot divulga algo que poucos laboratórios divulgam: o checkpoint treinado sem remover dados relacionados a segurança ofensiva marcava 90,5% em pass@3. O modelo final, com esses dados retirados, marca 81,0%. São 9,5 pontos sacrificados de propósito, e a empresa mostra a conta. Concordando ou não com a escolha, publicar o custo de uma decisão de segurança é mais útil do que afirmar que ela não custou nada. Para quem usa o modelo em engenharia de segurança legítima, esse é também um aviso concreto: há um teto deliberado nesse domínio.

Pesos abertos: a promessa ainda sem detalhes

O blog diz duas vezes que os pesos completos serão liberados "até 4 de novembro de 2026". O prazo ainda não venceu: faltam dez dias. As fontes oficiais deixam em aberto quatro pontos:

• Licença. O blog usa "open-weight" e "Advancing Open Intelligence", mas não nomeia licença nem condições de uso comercial.
• Escopo. "Pesos completos" do K3.1 Pro, mas não fica claro se o Highspeed entra no pacote. Se a diferença entre as variantes estiver no serviço de inferência, talvez nem haja um segundo conjunto de pesos para liberar.
• Hardware. Nenhum requisito publicado. Num modelo da classe de trilhões de parâmetros, isso é parte central da utilidade da abertura, não um detalhe.
• Contexto de 1M fora da Moonshot. Também não está documentado se a janela completa será reproduzível com os pesos e as ferramentas de inferência que acompanharem o lançamento.

Até 4 de novembro, "pesos abertos" descreve uma intenção com data marcada. Depois disso, a pergunta passa a ser o que exatamente foi entregue.

Armadilhas para quem integra hoje

A documentação traz detalhes operacionais que podem custar uma tarde de depuração:

Os identificadores e endpoints também mudam conforme o produto. A API usa kimi-k3.1-pro e kimi-k3.1-pro-highspeed, e o exemplo do quickstart aponta para https://api.moonshot.ai/v1. O Kimi Code usa k3.1-pro e k3.1-pro-highspeed, com endpoints compatíveis com OpenAI em https://api.kimi.com/coding/v1 (China) e https://api.kimi.ai/coding/v1 (fora da China). Copiar a configuração de um ambiente para o outro é o caminho mais curto para o fallback descrito acima.

Um cliente defensivo mínimo, usando o SDK compatível com OpenAI e os valores do quickstart:

from openai import OpenAI

client = OpenAI(
    api_key="SUA_CHAVE",
    base_url="https://api.moonshot.ai/v1",
)

MODELO = "kimi-k3.1-pro"

resp = client.chat.completions.create(
    model=MODELO,
    messages=[{"role": "user", "content": "Resuma este diff."}],
)

# Registre qual modelo respondeu de fato, em vez de presumir.
print(resp.model)

Do Brasil: o que está e o que não está documentado

O quickstart traz poucos dados sobre acesso fora da China. O K3.1 Pro é liberado após uma primeira recarga bem-sucedida, com mínimo de US$ 1. O total recarregado ao longo do tempo define o nível da conta e os limites de taxa. Na prática, um time que vai rodar agentes com contexto longo precisa recarregar mais para ter vazão, e não apenas para ter saldo. O blog menciona Zero Data Retention para clientes da API. É um ponto de partida útil para conversas de conformidade, embora a página não detalhe termos nem jurisdição.

As fontes não tratam de meios de pagamento aceitos no Brasil, de restrições regionais nem de desempenho em português. Nenhum dos benchmarks divulgados mede o modelo em nosso idioma. Quem pretende usar o K3.1 Pro em produto voltado ao público brasileiro precisa fazer essa avaliação por conta própria.

Julgamento

O Kimi K3.1 Pro é, pelo que a própria Moonshot mostra, um pós-treinamento ambicioso sobre uma base conhecida. Os números de agente de programação o colocam no mesmo patamar dos modelos fechados mais caros, numa configuração que favorece o modelo e com comparações que não vêm de experimentos controlados. Três coisas estão de fato comprovadas: a janela de 1.048.576 tokens existe, o preço não sobe com o tamanho do contexto e o Highspeed acelera a saída, mas não o agente inteiro. Duas coisas apenas se afirmam: que o modelo usa bem esse milhão de tokens e que o Highspeed não perde qualidade. Uma terceira ainda está no calendário: os pesos.

Minha leitura é que vale testar agora, com cautela proporcional ao que ainda não foi demonstrado. Para fluxos de programação com contexto médio, os dados oficiais justificam uma avaliação séria contra o modelo que você já usa, no seu próprio harness. Para contexto longo de verdade, não há base publicada para confiar, e o custo do raciocínio obrigatório no nível máximo pode surpreender. Para o Highspeed, meça a latência de ponta a ponta do seu agente, não a velocidade de geração isolada. Antes de qualquer decisão, compare o ganho com o dobro de cota.

O que vai definir o lugar deste modelo é o que acontecer até 4 de novembro e logo depois: licença, requisitos de hardware e as primeiras reproduções feitas por quem não tem interesse no resultado. Uma empresa que publica o custo de 9,5 pontos da sua própria decisão de segurança mostra que sabe ser transparente quando quer. Falta aplicar o mesmo cuidado às páginas que ainda têm números divergentes e lacunas importantes.