Kimi K3 compete com Fable, e a combinação dos dois modelos alcança desempenho de ponta

• Em uma comparação entre Kimi K3 e Fable 5 em cerca de 1.030 tarefas de agentes, o roteamento por tarefa alcançou 93% de precisão, com qualidade superior à de cada modelo isolado
• O desempenho geral foi parecido em tarefas de SWE, terminal, algoritmos, múltiplas linguagens e jurídicas, mas os domínios de tarefas em que cada modelo é forte eram diferentes
• O roteamento por oráculo atribuiu 72% a 96% das tarefas ao K3, e o K3 foi mais eficiente em custo que o Fable em todos os 5 grupos de tarefas
• Em loops longos de agentes, o K3 mostrou uma eficiência de custo até cerca de 50 vezes maior que o uso do Fable sozinho, embora muitas etapas de execução possam aumentar o tempo de processamento
• Um roteador ajustado à carga de trabalho, que use um modelo aberto mais barato como padrão e envie tarefas difíceis para outro modelo, pode melhorar qualidade e custo ao mesmo tempo

---

Medido com tarefas reais de agentes

• Kimi K3 e Fable 5 foram executados no mesmo harness para realizar cerca de 1.030 tarefas em formato de loops reais de agentes
  • SWE: 460 tarefas semelhantes a correções de bugs em repositórios reais
  • Terminal: 89 tarefas longas de agentes envolvendo segurança, criptografia, engenharia reversa, administração de sistemas etc.
  • Algoritmos: 100 problemas do tipo LeetCode e AtCoder
  • Múltiplas linguagens: 225 tarefas de implementação em 6 linguagens
  • Jurídico: 120 tarefas de agente jurídico avaliadas por advogados
• Os dois modelos foram comparados pela média dos resultados de benchmarks em vários tipos de tarefas

Significado e limites do roteamento por oráculo

• Roteamento por oráculo é uma forma teórica de medição em que cada tarefa é executada em todos os modelos e, entre as opções que chegam à resposta correta, escolhe-se o modelo mais barato
• Um roteador real não pode executar a tarefa previamente em vários modelos, portanto precisa prever de antemão o modelo com melhor equilíbrio entre custo e qualidade
• Nesse método, o K3 foi escolhido em 72% a 96% de todas as tarefas
• Pode ser possível criar um roteador que diferencie tarefas cotidianas de tarefas de cauda longa que exigem modelos de ponta
  • Para confirmar isso, seriam necessários cerca de 10 vezes mais dados de roteamento, não apenas um volume de um dígito, além de validação de desempenho em ambientes reais

Desempenho agregado é parecido, mas os pontos fortes diferem

• O resultado representativo em SWE foi quase idêntico: K3 com 92,4% e Fable com 92,6%
• Nos 5 tipos de tarefa, a diferença entre os dois modelos em geral ficou dentro de poucos pontos percentuais, com o Fable ligeiramente à frente na cobertura de programação em múltiplas linguagens
• Apesar de pontuações agregadas semelhantes, em tarefas detalhadas cada modelo mostrou áreas de vantagem claras

Diferenças por domínio de tarefa

• Ao dividir SWE por área do problema, o K3 foi superior em matemática simbólica e ferramentas de desenvolvimento, enquanto o Fable foi melhor em tarefas de web e visualização de dados
• Em tarefas de múltiplas linguagens, o Fable ficou à frente em Java, Python e C++, enquanto o K3 ficou no mesmo nível em JavaScript e Rust
• Em tarefas longas de terminal que manipulam o shell dezenas de vezes, o K3 mostrou pontos fortes
  • Ele resolveu hash 7z, criptoanálise de FEAL, segredos vazados, vulnerabilidades reais e tarefas assíncronas fora de controle que o Fable não conseguiu resolver
• Ao comparar precisão e custo em conjunto, o Fable ficou à frente em múltiplas linguagens, o K3 em terminal e jurídico, e os demais casos foram em geral parecidos

A estrutura que cria a diferença de custo

• A vantagem de custo do K3 vem de preço de tokens, caching de prompts e volume usado por tarefa
• Por tarefa de SWE, o K3 usou cerca de 55 turnos e 1,3 milhão de tokens, enquanto o Fable usou cerca de 21 turnos e 130 mil tokens
• Em tarefas longas de terminal, ocorreu o inverso: o Fable chegou a usar cerca de 64 turnos e 1,5 milhão de tokens, às vezes atingindo timeout
• Mesmo lendo 10 vezes mais tokens em SWE, o custo de execução do K3 foi menor que o do Fable graças aos acertos no cache de prompts
• Quando o número de etapas de execução aumenta, o tempo real de processamento pode ficar maior
  • Em tarefas que precisam responder em até 2 segundos, a latência é importante
  • Em agentes de grande escala rodando em segundo plano, uma cobrança menor se torna mais importante

Resultados da combinação dos dois modelos

• Ao enviar cada tarefa para o modelo mais adequado, obtém-se não um nível intermediário entre os dois, mas desempenho superior ao de cada modelo individual
• O roteamento por oráculo por tarefa sempre apresentou desempenho maior que a execução de modelos individuais, e a precisão geral chegou a 93%
• Mesmo enviando 72% a 96% do tráfego para o K3, o modelo otimizado para custo, a qualidade geral fica acima da de cada modelo e o custo se aproxima do uso exclusivo do K3
• O K3 foi mais eficiente em custo que o Fable em todos os 5 grupos de tarefas e, em loops longos de agentes, registrou uma eficiência de custo até cerca de 50 vezes maior

Roteamento por carga de trabalho, não um único modelo

• Roteando Kimi K3 e Fable em conjunto, é possível aproveitar pontos fortes diferentes e reduzir custos
• Como cada modelo tem preços e áreas de especialidade diferentes, a IA de mais alta qualidade pode vir de uma combinação de vários modelos, não de um único provedor
• Um modelo aberto como o K3, com custo até 50 vezes menor e para o qual o oráculo atribuiu a maior parte do tráfego, pode ser usado como opção padrão
• O roteador deve ser ajustado à carga de trabalho real e aprender continuamente a relação de adequação entre tarefas e modelos

[GN⁺]

Opiniões no Hacker News

• Ao executar e testar diretamente, todos esses modelos estão overfitados aos benchmarks. Mesmo que cheguem perto dos modelos de ponta em alguma métrica, desmoronam em tarefas reais, e a eficiência de tokens também é absurdamente baixa
  A Fireworks, ao contrário dos modelos fechados, lucra muito hospedando o K3, então tem um incentivo enorme para usar esse tipo de título

  • Depois de testar por alguns dias K3, Qwen 3.8 Max Preview, Fable e Sol, concordo em parte que é difícil confiar nos benchmarks, e que os modelos chineses são lentos e têm baixa eficiência de tokens
    Ainda assim, eles ficam mais ou menos no mesmo nível dos modelos topo de linha da geração anterior, Opus 4.8 e GPT 5.5, e também dá para comparar em https://senko.net/vibecode-bench/
    Usando as APIs oficiais e as respectivas ferramentas de codificação, pedi que criassem um app web simples, mas nada trivial, apenas a partir de uma especificação detalhada; os resultados de K3, Qwen 3.8 e Fable ficaram quase iguais nos testes com usuários, todos foram aceitáveis também na revisão de código do Sol, e o Fable ficou ligeiramente à frente
    No trabalho real, ainda prefiro Opus 4.8 e Sol, mas, se precisar de alternativas, K3 e Qwen 3.8 também são plenamente usáveis
  • Todos foram overfitados aos benchmarks, mas o ponto central é o quanto foram overfitados em comparação entre si
    Avalio principalmente capacidade de programação em um ambiente multiagente aberto, sem conjunto de respostas corretas, no qual os agentes influenciam uns aos outros; os modelos chineses tendem a ficar abaixo dos modelos dos EUA em relação ao que é anunciado nos model cards
    O Kimi K3 é uma exceção e realmente chega perto da fronteira, mas é muito lento. O Muse Spark 1.1 é o mais forte depois de Fable e Sol, além de ser o mais eficiente em custo, numa grande virada depois do Llama 4. Os dados estão em https://gertlabs.com/rankings
  • O Fable funciona muito bem mesmo em codebases razoavelmente grandes. Precisei corrigir ou orientar algumas vezes, mas na maior parte foi porque os requisitos do prompt eram insuficientes; de fato, ele errou só umas duas vezes, uma taxa de erro menor do que a da minha carreira profissional
    A qualidade do código fica no nível do que eu escreveria e, em áreas com as quais não estou familiarizado, é melhor. Ele também executa de forma consistente tarefas que humanos adiam ou acham tediosas, como refatoração, testes de integração e regressão, e verificação de logs de auditoria e alertas de erro, elevando o nível geral da engenharia de software
    É um serviço real em Ruby on Rails, relativamente complexo, usando PostgreSQL; no plano Max de US$ 200 por mês, o orçamento de tokens não foi problema, e o custo valeu muito a pena
  • Não li o texto, mas o título já pareceu suspeito por ser de uma empresa de serviços de inferência promovendo um modelo de nível Mythos que ela própria oferece. O GLM 5.2, que tem menos de um terço dos parâmetros do Kimi K3, ainda é o principal modelo
  • Todas essas avaliações precisam da ressalva por enquanto. Olhando a tendência, mesmo que ainda não estejam bons o suficiente para programação, é claro que chegarão lá em breve, e precisamos nos preparar para um mundo em que modelos abertos executam quase todas as tarefas de software

• É interessante que tenham testado Kimi K3 e Fable em cerca de 1.000 tarefas, divididas em 5 áreas, como engenharia de software e direito
  Eles colocam na frente um modelo roteador que prevê qual modelo será mais barato para chegar à resposta correta; no fim, acho que ele deveria continuar aprendendo com a carga de trabalho de cada um
  O roteador escolheu Kimi em 72% a 96% das tarefas, dependendo da área, e obteve uma redução de custos de 1,5 a 50 vezes, conforme o domínio

  • Aqui, o roteador é um ponto de referência oracular que executa os dois modelos, verifica se passaram e então escolhe o mais barato
    É apenas uma suposição da Fireworks de que os custos podem ser reduzidos se existir um roteador que preveja antecipadamente o mesmo resultado; a existência dele é uma premissa importante
  • Existem vários roteadores parecidos, como https://openrouter.ai/openrouter/auto

• Se for um modelo que conversa como uma pessoa, aceito até uma queda de 5% na pontuação de benchmark

  • Eu, pelo contrário, prefiro modelos que não tentem falar como pessoas
  • Não é preciso abrir mão de 5%: basta passar a saída do Fable para o Gemini Flash e pedir para reescrever em frases mais legíveis
  • Tenho uma forte preferência por modelos que não imitem meu jeito humano de falar. O comportamento do Claude de agir como amigo e responder a piadas com LOL não é só ridículo, também é prejudicial
  • Por padrão, o Opus produz um estilo que eu chamo de claudês. São frases excessivamente simplificadas e gramaticalmente incompletas, dolorosas de ler; talvez sejam fáceis de ler e escrever para o modelo, mas não para humanos
    Por exemplo, ele transformou a orientação para um artigo longo em uma linha cheia de fragmentos imperativos como “dê uma olhada agora e volte a consultar enquanto lê a Parte II”, palavras-chave em negrito e setas conectando tudo
  • LLMs não são humanos; não há motivo para precisarem falar como pessoas

• A Anthropic parece estar fazendo uma reprise acelerada do Império Romano, como se já tivesse passado do auge e entrado em declínio antes mesmo do IPO

• Ao assinar o plano de codificação do Kimi K3, fico curioso sobre como se aplicam a governança de dados e a proteção de privacidade. Quero migrar da Anthropic.

  • Segundo https://platform.kimi.ai/docs/agreement/modeluse, o conteúdo pode ser usado para fornecer, manter, desenvolver e melhorar o serviço, entre outros fins, e clientes que precisem restringir o treinamento devem discutir um contrato empresarial separado ou um acordo por escrito.
    Diferentemente do Claude, não há opção de recusa para treinamento do modelo, e, pelos termos, a Kimi pode usar o código do cliente no treinamento.
  • É preciso esperar até que provedores ocidentais comecem a hospedá-lo.
  • O jeito mais simples é assinar o OpenRouter e excluir todos os provedores que não sejam de retenção zero de dados (ZDR). Porém, o preço da API pode ser mais alto que o plano de codificação, e os 1,7 bilhão de tokens oferecidos no plano de US$ 20/mês da MiniMax valem, em termos de API, mais de US$ 200 a US$ 500, dependendo da proporção de entrada/saída e cache.
    Se não quiser lidar diretamente com empresas chinesas, o AtlasCode por US$ 20/mês, o OpenCode Go por US$ 10/mês e o Cline Pass por US$ 10/mês oferecem de 2 a 6 vezes mais uso em alguns modelos populares de pesos abertos.
    Pessoalmente, assino o Z.ai por US$ 17/mês e pago tarifas de API aos provedores originais de MiMo v2.5, Hy3, Qwen 3.7 Plus e DeepSeek v4.
  • A política de privacidade pode ser consultada em https://www.kimi.com/user/agreement/zh/userPrivacy.

• Fico curioso se é possível receber dinheiro para escrever textos assim promovendo modelos abertos e, se for, qual seria o objetivo.
  Depois de trabalhar com FastAPI/Python e Spring Boot/Java em produtos SaaS modernos, o único modelo aberto que foi bom e eficiente foi o Qwen 3.7 Max.
  GLM 5.2 e Kimi frequentemente pesquisam a base de código por quase 70 mil a 80 mil tokens antes de escrever código e, no fim, quebram o código. Eles funcionam bem quando recebem especificações extremamente detalhadas, como há um ano, mas o Qwen 3.7 conclui as tarefas sem muito esforço.

  • É um bom marketing de conteúdo. A Fireworks é uma grande provedora de inferência de modelos que vende acesso ao Kimi K3.
  • A Fireworks é especializada em executar modelos abertos rapidamente e obtém a maior parte da receita com modelos chineses, então o incentivo econômico é praticamente todo o modelo de negócio.
  • Há muito dinheiro no negócio de influência em tecnologia, mas a maior parte vem de grandes empresas, como a aquisição da tbpn pela OpenAI ou acesso antecipado para alguns influenciadores.
  • Lin Qiao é cofundadora e CEO da Fireworks AI. LLMs são o equivalente à corrida espacial da Guerra Fria entre EUA e China, então o incentivo para provar superioridade nacional/civilizacional pode ser maior que o dinheiro.

• Fico curioso se há algo em que o Kimi seja especialmente melhor aqui. Pelo que sei, o preço é parecido com o do Sonnet 5, então me pergunto como seria usar Sonnet 5 e Fable, ou o Grok 4.5, que é mais barato.

  • O texto diz que o Kimi é melhor que o Fable em algumas tarefas, mas isso provavelmente não se aplica ao Sonnet.
  • Modelos abertos têm a vantagem de permitir que grandes empresas façam execução local e fine-tuning em seus próprios data centers.

• Gosto muito dos modelos chineses e uso apenas o DeepSeek; agora também uso o Kimi K3 como um excelente assistente de planejamento para tarefas avançadas de codificação.
  O DeepSeek v4 Flash é muito rápido e resolve quase tudo que atribuo a ele em Rust, PostgreSQL, Angular e Terraform.
  Hospedo o Bifrost por conta própria como gateway de LLM, mas gostaria que os provedores cobrassem automaticamente pelo uso real mensal/diário, como VPS, em vez de recarga pré-paga e recarga automática. Quero pagar apenas pelo uso exato, em vez de manter saldos mínimos não reembolsáveis em vários provedores.
  O OpenRouter ajuda, mas não gosto do serviço em si nem das taxas extras.

  • Ultimamente uso principalmente o DeepSeek v4 Pro e, como tenho muitas tarefas simultâneas, a velocidade importa menos. Se ele falha, mudo a conversa para o GPT 5.5 no meio, peço para encontrar o problema e depois volto ao DeepSeek mantendo essa análise no contexto.
    O Kimi k2.5/6 ficou mais lento e com desempenho pior, além de mais erros engine overloaded; o k3 pensa por muito tempo, mas os resultados não melhoraram de forma perceptível. Acho possível que tenham quantizado temporariamente o modelo por pressão sobre recursos de computação.
    Recentemente uso principalmente o DeepSeek v4 Pro e recorro ao GPT 5.5 quando preciso de um modelo forte. O GLM 5.2 é bom em algumas tarefas, mas muito ruim em outras, e os modelos do Google ou da Anthropic ainda não me impressionaram.
  • Usando ferramentas como reasonix ou whale, dá para alcançar cerca de 98% de acerto de cache, tornando o custo das requisições praticamente próximo de zero. Isso é possível até com provedores americanos sem subsídio, como Cloudflare ou DigitalOcean.
  • O pré-pago impede que usuários consumam muitos recursos de inferência e depois cancelem o cartão e desapareçam. VPS é um investimento de longo prazo, então a troca é mais difícil, e o custo para o provedor é relativamente pequeno mesmo que alguns usuários deixem de pagar um mês.
  • Estou avaliando o Bifrost e fico curioso sobre por que você escolheu um gateway de LLM.
    O OpenRouter oferece quase todos os modelos desde o dia do lançamento, mas o que me atrai no Bifrost é que, se eu sair do OpenRouter no futuro, não precisarei mexer no restante da configuração técnica. Se a auto-hospedagem se tornar viável, posso reduzir a dependência de OpenAI, Anthropic e OpenRouter, além de diminuir o risco de um modelo do qual eu dependo ser descontinuado de repente.
  • Além das taxas extras, o que no serviço do OpenRouter você não gosta?

• É uma situação em que uma empresa de hospedagem de modelos abertos diz que modelos abertos são ótimos.

  • Eles divulgaram a metodologia e os resultados, e aprendi pontos fortes e fracos relativos de Kimi e Fable que não tinha visto em outros lugares. O fato de eles estarem no negócio de hospedagem de modelos não tira deles o direito de compartilhar resultados.
  • A Fireworks não hospeda apenas modelos de pesos abertos, e o fato de uma grande notícia poder atrair novos clientes não torna o conteúdo falso.
  • Quem já testou pessoalmente sabe que a avaliação deles é verdadeira.

• Como explicado no texto, estou procurando uma ferramenta de roteamento que possa ser usada com o Claude Code, ou outra boa plataforma de roteamento. Sei que o roteador deste texto usa uma abordagem de oráculo

  • https://github.com/code-yeongyu/oh-my-openagent implementa o padrão de oráculo do texto original em 11 papéis
    Cada papel tem um ranking recomendado de LLMs de vários provedores; por exemplo, usa Sisyphus (claude-opus-4-8 / kimi-k3 / glm-5) como orquestrador principal