Modelos de fronteira: onde está a verdadeira diferença? Há outros?! Qwen, Kimi
Modelos de fronteira: onde está a verdadeira diferença? Há outros?! Qwen, Kimi
GPT-5.6 Sol ou Claude Fable 5? A escolha já não se faz pela tabela
Indo directamente ao assunto, a comparação entre modelos de fronteira continua, para já, é concentrada sobretudo no GPT-5.6 Sol e no Claude Fable 5 (ou no Mythos 5, quando existe acesso autorizado às suas capacidades menos restringidas).
Circulam também alegações sobre novos modelos da Kimi e da Qwen, acompanhadas por números impressionantes, supostas classificações e quantidades de parâmetros difíceis de ignorar. O problema é que um rumor, mesmo plausível, não é um produto disponível. Enquanto não existirem anúncio oficial, documentação técnica, preços, condições de acesso e testes reproduzíveis, esses modelos não devem influenciar uma decisão tecnológica.
No artigo anterior, comparei o comportamento do Sol e do Fable em tarefas práticas, incluindo modelação 3D, criação editorial, programação para hardware antigo e desenvolvimento de experiências interactivas. Repetir agora que um tende a chegar mais depressa a soluções funcionais e que o outro demonstra frequentemente maior persistência ou coerência criativa acrescentaria pouco. A questão mais interessante passou a ser outra: o que significa, na prática, escolher um modelo de fronteira?
Capacidade anunciada não é capacidade disponível
O desempenho de um modelo deixou de poder ser separado das condições em que é fornecido.
O Claude Fable 5 foi lançado como a versão de acesso geral de uma arquitectura da classe Mythos. Em pedidos considerados sensíveis, sobretudo nas áreas da cibersegurança, biologia e química, as salvaguardas podem encaminhar a sessão para o Claude Opus 4.8. A Anthropic afirma que este mecanismo é activado, em média, em menos de 5% das sessões, mas reconhece a possibilidade de falsos positivos. O Mythos 5 utiliza o mesmo modelo de base, com algumas dessas restrições removidas, mas permanece limitado a programas de acesso controlado. Segundo a Anthropic, a diferença entre Fable e Mythos está, portanto, menos na inteligência fundamental e mais no nível de acesso permitido às suas capacidades.
A disponibilidade também pode mudar por razões externas ao produto. Após uma directiva de controlo de exportações dos Estados Unidos, o acesso ao Fable 5 e ao Mythos 5 foi suspenso. As restrições foram posteriormente levantadas e o Fable regressou ao Claude, Claude Code, API e restantes plataformas, embora sujeito às regras de utilização de cada subscrição. A cronologia foi documentada pela própria Anthropic.
O GPT-5.6 da OpenAI passou igualmente por uma antevisão limitada antes da disponibilização geral. A família Sol, Terra e Luna encontra-se agora acessível no ChatGPT, Codex e API, mas os níveis de raciocínio e a modalidade multiagente ultra dependem do produto e do plano utilizado. A OpenAI apresenta o Sol como o modelo mais capaz da família e destaca sobretudo a quantidade de trabalho útil obtida por token e por unidade de custo.
Isto significa que comparar apenas os modelos é insuficiente. É necessário comparar o modelo, o plano, as ferramentas autorizadas, as salvaguardas aplicadas e a probabilidade de essas condições se manterem durante o projecto.
Um benchmark não é uma sentença
As tabelas publicadas pelas empresas continuam a ser úteis, mas dizem menos do que parecem.
Um modelo pode liderar uma avaliação de programação e perder noutra porque foram usadas ferramentas, limites de tempo ou níveis de raciocínio diferentes. Pode também obter uma pontuação superior à custa de mais tentativas, mais tokens ou maior latência. Mesmo quando os nomes dos testes coincidem, o ambiente de execução nem sempre é idêntico.
Há ainda outro problema: os resultados oficiais são escolhidos e apresentados pelas organizações que vendem os modelos. Isso não torna os números falsos, mas torna indispensável ler a metodologia, os limites e as notas de rodapé.
Um benchmark deve ser tratado como uma indicação sobre onde testar, não como a resposta final sobre o que comprar. É uma hipótese de trabalho, não uma coroa.
O preço por token pode ser a métrica errada
O GPT-5.6 Sol apresenta uma vantagem clara no preço anunciado por milhão de tokens: 5 dólares na entrada e 30 na saída, contra 10 e 50 dólares no Claude Fable 5. À primeira vista, a conclusão parece evidente.
Mas o custo relevante não é o preço por token. É o custo de concluir correctamente a tarefa.
Um modelo mais barato pode tornar-se mais dispendioso se necessitar de cinco tentativas, produzir alterações que têm de ser revistas manualmente ou falhar perto do fim de uma sequência longa. Da mesma forma, um modelo mais caro pode justificar a diferença se reduzir horas de validação humana ou resolver problemas que uma alternativa abandona a meio.
A unidade de comparação deveria ser algo como "custo por resultado aceite", incluindo:
- consumo de tokens;
- tempo total de execução;
- número de tentativas;
- intervenções humanas;
- erros introduzidos;
- tempo necessário para rever e corrigir o resultado;
- percentagem de tarefas efectivamente concluídas.
Sem estes elementos, uma comparação de preços descreve apenas a factura da API, não o custo real do trabalho.
A melhor avaliação cabe num pequeno teste interno
Uma empresa não necessita de reproduzir dezenas de benchmarks académicos. Precisa de seleccionar algumas tarefas que representem o trabalho que realmente executa.
Pode, por exemplo, pedir aos dois modelos que corrijam o mesmo erro num repositório, analisem um contrato, preparem uma proposta comercial, pesquisem um tema com fontes e executem uma sequência de ferramentas. Os dados de entrada, permissões, limites e critérios de aceitação devem ser iguais.
Cada tarefa deveria ser repetida várias vezes. Um único resultado pode beneficiar do acaso, de uma interpretação particularmente favorável ou de uma falha temporária do serviço.
Também convém registar onde o modelo falhou. Uma resposta errada mas confiante, uma alteração de código sem testes e uma tarefa interrompida por uma salvaguarda representam problemas muito diferentes. Colocá-los simplesmente na coluna «falhou» elimina precisamente a informação mais útil para decidir.
A decisão pode não ser escolher apenas um
A evolução recente sugere que a estratégia mais robusta poderá passar por distribuir tarefas entre modelos.
Um modelo pode assumir a execução inicial, enquanto outro revê o resultado. Determinadas tarefas podem ser encaminhadas segundo o custo, a latência, o contexto necessário ou a sensibilidade dos dados. Um terceiro modelo, mesmo menos capaz em termos gerais, pode ser suficiente para operações simples e repetitivas.
Esta abordagem evita transformar a escolha tecnológica numa aposta permanente num único fornecedor. Também reduz o impacto de alterações de preços, limites, políticas de segurança ou disponibilidade regional.
Naturalmente, trabalhar com vários modelos aumenta a complexidade da integração. Exige formatos de saída consistentes, registos de execução, critérios de validação e mecanismos para impedir que um erro seja apenas transferido de um sistema para outro. Ainda assim, para fluxos importantes, essa complexidade pode ser preferível à dependência total de uma única plataforma.
A verdadeira fronteira é operacional
O GPT-5.6 Sol e o Claude Fable 5 estão suficientemente próximos para que nenhum deva ser escolhido apenas por reputação ou por uma tabela divulgada pelo fabricante.
A diferença decisiva aparece quando o modelo entra no ambiente real: com os ficheiros da empresa, as ferramentas disponíveis, os limites da subscrição, as salvaguardas activas e os erros que inevitavelmente surgem durante a execução.
Novos concorrentes entrarão nesta comparação (incluindo alguns dos nomes que hoje ainda circulam sobretudo como rumores). Quando forem oficialmente apresentados, terão de enfrentar o mesmo teste: não apenas demonstrar inteligência, mas provar disponibilidade, previsibilidade, custo e capacidade para terminar trabalho útil.
A pergunta deixou, portanto, de ser "qual é o modelo mais inteligente?". A pergunta certa será antes: "qual deles conclui melhor as nossas tarefas, nas condições em que realmente o podemos utilizar?".
Essa resposta não virá de uma tabela. Virá dos registos de execução, dos resultados aceites e do número de vezes em que um humano teve de salvar o trabalho.
