Das melhorias de classificação aos pagamentos: a ilusão da demanda na fusão de modelos.

I. O que é Fusão de Modelos?

Em junho de 2026, o mercado de IA viu dois produtos chamados "Fusion" surgirem em menos de três semanas.

Em 12 de junho, a OpenRouter lançou o Fusion Router, intitulado " Superando o desempenho de fronteira com o Fusion ". Em sua avaliação detalhada DRACO, o grupo de modelos composto por Fable 5 e GPT-5.5 obteve 69,0 pontos, superando os 65,3 pontos do modelo único Fable 5. O diferencial da OpenRouter é simples: quando um único modelo não é suficiente, vários modelos respondem à mesma pergunta, e então os modelos são comparados e sintetizados por um avaliador.

Em 29 de junho, a Cognition lançou o Devin Fusion, mas o título era " Desempenho de ponta a um custo 35% menor ". Em vez de ter vários modelos executando repetidamente toda a tarefa, ele permite que o modelo principal lide com o planejamento e a tomada de decisões, deixando os testes, as modificações mecânicas e outras tarefas para o modelo auxiliar mais barato, alternando dinamicamente entre os modelos durante a execução.

O mesmo termo aponta para duas lógicas econômicas opostas. O OpenRouter usa mais computação para comprar limites maiores; o Cognition tenta reduzir a computação dispendiosa, mantendo sua qualidade original. Esse contraste é mais revelador do que qualquer ranking de modelos. A proposta técnica da fusão de modelos é de fato verdadeira: múltiplas tentativas têm a chance de superar uma única tentativa. Mas o que o mercado realmente recompensa não é "mais chamadas de modelo", mas sim quem consegue gastar menos e entregar mais rápido após atingir os limites de qualidade.

▲ Figura 1: Dois tipos de Fusão no mesmo mês. Este artigo define Fusão de Modelos como uma arquitetura mais restrita: múltiplos modelos respondem à mesma tarefa em paralelo, os modelos são revisados e seus resultados são comparados, e finalmente um modelo gera a resposta. A Fusão Devin não se enquadra nessa definição; ela se aproxima mais do roteamento dinâmico e da delegação de tarefas. Ela é apresentada no início porque o mercado está usando "Fusão" como um termo genérico para toda orquestração multimodelos, enquanto produtos realmente eficazes estão frequentemente se afastando da definição restrita de fusão de modelos.

Nossa avaliação é pessimista: a Fusão de Modelos é uma apólice de seguro de qualidade cara. Ela pode melhorar o desempenho absoluto de certas tarefas, mas raramente expande de fato a fronteira de eficiência custo-qualidade-latência. Pouquíssimas tarefas realmente justificam o investimento nesse seguro. Ela permanecerá, mas é mais provável que seja um recurso acionado com pouca frequência do que a arquitetura padrão, e é menos provável que se torne uma categoria independente.

II. Quais são as opções de modelo disponíveis atualmente?

As discussões sobre o Fusion facilmente descambam para rankings de precisão, mas as empresas não compram rankings. Elas compram resultados aceitáveis para uma tarefa, levando em consideração também preço, latência, privacidade e estabilidade. Contanto que um modelo barato já esteja disponível...

Uma vez ultrapassado o limite de aceitação comercial, continuar a pagar por funcionalidades "mais inteligentes" pode deixar de ser economicamente viável. A eficiência de custos é a verdadeira força motriz no mercado de modelos.

▲ Figura 2: Inteligência do Modelo e Custo de Tarefa Única. Os pontos mais notáveis na escala logarítmica não são as pontuações mais altas no canto superior direito, mas sim os pontos que se desviam da tendência preço-capacidade: estes oferecem capacidade suficiente a um preço mais baixo e são valores atípicos de eficiência para cargas de trabalho específicas. Embora o índice composto não possa responder diretamente qual modelo é o mais adequado para revisão de código, pesquisa na China ou implantação regulamentada, ele revela uma tendência: a oferta de modelos está se tornando uma commodity e o "modelo mais forte" está se distanciando da "escolha ideal".

Existem atualmente quatro principais estratégias de compra no mercado para lidar com a mesma lacuna de qualidade.

A primeira abordagem consiste em atualizar diretamente para um modelo único mais robusto. Esta é a mais simples e fácil de auditar; geralmente ainda é a opção preferida, desde que o aumento marginal no custo do modelo de ponta seja menor do que o custo de erros ou retrabalho. A segunda abordagem consiste em aumentar a capacidade computacional em tempo de teste no mesmo modelo, como estender a inferência, a autoconsistência ou a amostragem múltipla. A terceira abordagem é o roteamento, o encadeamento e a delegação de tarefas: primeiro, utiliza-se um modelo mais barato para lidar com as partes verificáveis ou mecânicas e, somente se forem encontradas dificuldades. A quarta abordagem, em um sentido mais restrito, é a Fusão de Modelos: ter vários modelos respondendo repetidamente à mesma pergunta e, em seguida, ter a resposta final formada pela revisão e síntese dos modelos.

Todos os quatro métodos podem "trocar mais computação por qualidade", mas a diferença reside em onde a computação é aplicada. Extensões de modelo único permitem inferências mais profundas, roteamento permite uma alocação de recursos mais precisa, enquanto o Fusion permite obter mais respostas candidatas. Os três primeiros métodos concentram seus orçamentos nas etapas com maior probabilidade de alterar o resultado; o Fusion, no entanto, prioriza opiniões duplicadas e, em seguida, aposta que o modelo de revisão poderá identificar diferenças válidas. Os modelos candidatos devem fornecer informações independentes suficientes, e os revisores devem ser capazes de reconhecer essas informações.

Fusion é a única opção capaz de superar as outras três.

O roteamento demonstrou que as diferenças de capacidade entre os modelos representam, principalmente, uma oportunidade de agendamento. O RouteLLM reduziu os custos em mais de 2 vezes em algumas avaliações sem sacrificar a qualidade; o Switchcraft alcançou uma redução de custos de 84% com 82,9% de precisão, o que, segundo o artigo, se traduz em uma economia de mais de US$ 3.600 por milhão de requisições. Os resultados ainda precisam ser reproduzidos no tráfego da própria empresa, mas a lógica econômica é simples: em vez de ter vários modelos em uma conferência, basta atribuir cada tarefa ao modelo qualificado mais barato.

Isso significa que o mercado primeiro abordará a lacuna de qualidade por meio de atualizações, roteamento e validação; somente quando esses métodos ainda forem insuficientes haverá um motivo para comprar mais respostas candidatas para o Fusion.

III. Por que melhorar as pontuações não significa ter valor?

Isso ocorre porque o Fusion precisa superar simultaneamente três obstáculos: o aumento da qualidade deve compensar o custo e a latência adicionais, os modelos candidatos devem fornecer informações independentes e os revisores devem identificar consistentemente as melhores respostas. Se algum desses obstáculos falhar, a melhoria na pontuação não poderá ser traduzida em valor de produção. Custo computacional: quanto orçamento e latência adicionais são necessários? A melhoria na pontuação do Fusion representa, antes de tudo, um custo computacional considerável. O OpenRouter utiliza vários modelos de painel em paralelo, e então os revisores e o modelo integrado geram a resposta. Todos os três grupos de controle no DRACO apresentaram melhorias na pontuação: Fable 5 + GPT-5.5 aumentou de 65,3 para 69,0; a autofusão do Opus 4.8 aumentou de 58,8 para 65,5; e o grupo de três modelos de baixo custo aumentou de 60,3 para 64,7.

No entanto, a melhoria na autofusão do Opus é maior, sugerindo que os ganhos podem vir de buscas e amostragens adicionais, em vez de complementaridade de conhecimento entre modelos . Uma comparação justa deve ser feita entre autoconsistência, inferência mais longa e modelos robustos de agente único, sob o mesmo orçamento de tokens. Pesquisas existentes também mostram que modelos multiagentes podem melhorar o desempenho em até 7,1 pontos percentuais com um custo computacional aproximadamente 20 vezes maior; com o mesmo orçamento, os modelos de debate e de mistura de agentes apresentam desempenho apenas 1,3 e 2,7 pontos percentuais superior à autoconsistência, respectivamente, enquanto outro estudo com o mesmo número de tokens de raciocínio constatou que os modelos de agente único têm desempenho igual ou superior. Muitos "ganhos de colaboração" desaparecem após o alinhamento do livro-razão computacional.

▲ Figura 3: Melhoria de desempenho e custo do produto do OpenRouter. O painel padrão de 3 modelos do OpenRouter custa aproximadamente 4 a 5 vezes mais do que um painel padrão gerado automaticamente e é 2 a 3 vezes mais lento . No entanto, a empresa não divulga os tokens, custos e latência completos para cada configuração DRACO, o que impossibilita determinar se a melhoria de 3,7 pontos percentuais é justificável. A avaliação incluiu apenas 100 tarefas de texto em inglês simples, com apenas 93 das configurações relacionadas ao Fable concluídas. Alterar o modelo de avaliação pode alterar a pontuação absoluta em 10 a 25 pontos percentuais. Isso comprova que o Fusion pode melhorar as pontuações, mas não comprova que o Fusion melhora o ROI em produção.

A invocação seletiva só pode reduzir custos. De acordo com estimativas divulgadas pela OpenRouter, o custo total é aproximadamente 1,03 a 1,04 vezes menor quando a taxa de ativação é de 1%; 1,30 a 1,40 vezes menor quando é de 10%; e 1,75 a 2,00 vezes menor quando é de 25%.

▲ Figura 4: Economia Geral da Invocação Seletiva de Fusão. As solicitações mais complexas são as que têm maior probabilidade de acionar a Fusão, mas o sistema precisa aguardar os membros mais lentos do painel antes de concluir a revisão e a geração em série. Portanto, a latência de cauda se concentra nas tarefas mais valiosas. A invocação de múltiplos fornecedores também expande a superfície de falha, a complexidade da auditoria e a exposição da privacidade. O custo da Fusão não se resume ao preço da API, mas também inclui o tempo de espera e os riscos adicionais para o sistema. Complementaridade da Informação: Vários Modelos Realmente Fornecem Informações Diferentes? O valor da Fusão depende de os modelos candidatos trazerem informações independentes, mas modelos diferentes frequentemente compartilham corpora de treinamento, fontes de páginas da web e premissas errôneas. Em tarefas de pesquisa, isso leva à "lavagem de citações" : múltiplos modelos remontam à mesma fonte, mas são agrupados como múltiplas peças independentes de evidência. Se o sistema não mantiver a proveniência em nível de alegação e os caminhos de busca, o custo da API aumenta quase linearmente com o número de modelos, mas a diversidade de evidências não aumenta necessariamente.

Em seu artigo de 2026 , *Quando a Combinação de Modelos de Linguagem Ajuda?* , Josef Chen, cofundador e CEO da KAIKAKU.AI, estudou 67 modelos de 21 provedores de serviços. Em tarefas matemáticas abertas, a probabilidade prevista de todos os modelos responderem incorretamente simultaneamente era de 2,3%, mas a probabilidade real atingiu 5,2% — aproximadamente 2,3 vezes o valor previsto . A taxa de falha conjunta aumentou ainda mais para 7,9% e 12,7% na tarefa de pontuação de código e na versão de resposta livre do GPQA-Diamond, respectivamente. Com 100 questões do GPQA-Diamond, aproximadamente 13 questões fariam com que todos os modelos candidatos respondessem incorretamente, não deixando nenhuma resposta correta para votação, revisão ou síntese. A divergência entre os modelos em questões fáceis amplifica o valor combinado, enquanto nas questões mais cruciais, todas podem falhar. Avaliando a confiabilidade: o sistema consegue identificar e sintetizar respostas melhores? Mesmo com respostas candidatas complementares, o valor ainda depende da revisão. Quando os candidatos são consistentes, os avaliadores podem interpretar erroneamente erros relacionados como alta confiança; quando os candidatos divergem, é necessário conhecimento especializado suficiente para selecionar a resposta correta. O modelo composto também pode apagar opiniões minoritárias importantes ou reescrever divergências reais em conclusões definitivas.

Em tarefas de programação, compiladores, testes e análises estáticas costumam ser mais confiáveis do que a opinião de outro modelo; em tarefas criativas, revisão e síntese podem facilmente homogeneizar as diferenças em uma resposta média. Mesmo o modelo de revisão mais robusto disponível no LitBench apresenta uma taxa de concordância de apenas 73% com as preferências humanas em escrita criativa. Quando existem validadores externos de baixo custo para a tarefa, ou quando o próprio conceito de "bom" depende de julgamento subjetivo, as melhorias de pontuação do Fusion são difíceis de traduzir em valor pago.

IV. Quem vai pagar pelo Fusion?

A demanda por Fusion depende de dois obstáculos: se a tarefa pode se beneficiar de múltiplos modelos e se esse benefício é suficiente para gerar receita sustentável. O primeiro é uma questão técnica, enquanto o segundo é uma questão de mercado. Da aplicabilidade técnica à viabilidade econômica, o Fusion exige que a probabilidade de corrigir um erro, multiplicada pela perda evitável decorrente de um único erro, supere o custo, a latência, a complexidade operacional e os riscos à privacidade da adição de novas APIs.

As pontuações de benchmark não conseguem responder a essa questão de lucro e prejuízo. A fusão só é viável quando o custo do erro é alto, os modelos candidatos fornecem caminhos de busca complementares, faltam validadores externos mais baratos e a empresa pode aceitar latência adicional e risco do fornecedor; o resultado final ainda deve ser confirmado por evidências humanas ou externas.

▲ Figura 5: Da Aplicabilidade Tecnológica às Necessidades Sustentáveis Aqueles que atendem a esses critérios incluem principalmente pesquisas de alto valor e due diligence, revisões de arquitetura e segurança e "segundas opiniões" antes de decisões irreversíveis. Eles compartilham características comuns: restrições incompletas, altos custos de omissões e o valor inerente de uma abordagem independente. Por outro lado, código regular, aplicações de consumo imediato, fluxos de trabalho de alto rendimento e baixa margem, e tarefas diretamente verificáveis por testes ou regras normalmente não exigem fusão. Órgãos reguladores também podem rejeitar painéis de múltiplos fornecedores devido a limites de dados e requisitos de auditoria. Da Disposição a Pagar às Necessidades Sustentáveis A utilidade tecnológica pode gerar uma alta disposição a pagar, mas não equivale a uma demanda escalável. Para que a demanda sustentável se materialize, as perdas por erros devem ser quantificáveis, as tarefas devem ser recorrentes, deve haver responsabilidades orçamentárias claramente definidas dentro da organização e a fusão deve superar consistentemente especialistas humanos, modelos de entidade única robustos e validação externa. No entanto, os orçamentos para due diligence geralmente são direcionados a analistas e fontes confiáveis, os orçamentos de segurança a auditorias profissionais, e as decisões irreversíveis ocorrem com pouca frequência.

Portanto, não estamos otimistas em relação a empresas que apenas fornecem wrappers multimodelos, executam painéis por padrão ou tratam algoritmos estáticos de seleção de modelos como uma vantagem competitiva. Conectar APIs é fácil de replicar, e estratégias fixas rapidamente se tornam ineficazes à medida que os recursos e preços dos modelos mudam; sem saber a taxa de erro e quantas vezes o Fusion realmente corrigiu os erros, é impossível precificar essa garantia. Aqueles que controlam os resultados reais têm maior probabilidade de capturar valor: plataformas de gateway e agentes, aplicativos verticais, proprietários de fluxos de trabalho e produtos de avaliação e observabilidade. Eles conhecem o custo dos erros, podem observar os resultados e otimizar as estratégias de acionamento. O que é realmente difícil de replicar não é a lista de painéis, mas determinar quando não invocar o Fusion. Validação de mercado: Os mercados públicos são insuficientes para determinar a escala da demanda pelo Fusion, mas já mostram como ele está sendo usado. O Perplexity Model Council está disponível apenas para usuários Max e Enterprise Max que pagam US$ 200 por mês. Os usuários selecionam manualmente três modelos na web para pesquisa de investimentos, tomada de decisões complexas e validação de informações; os casos de uso públicos incluem a integração do Model Council em fluxos de trabalho de pesquisa de ações por meio da automação do navegador. A abordagem "Mixture of Agents" do Hermes apresenta o Fusion como um modelo virtual selecionável dentro do agente: os usuários podem atualizar para um único problema complexo via /moa, ou habilitá-lo continuamente em sessões complexas, com análises fornecidas por múltiplos modelos de referência, e o agregador acionando ferramentas para concluir a tarefa. Posteriormente, o Hermes reduziu a frequência padrão de distribuição (fan-out) e reutilizou o feedback de modelos anteriores para controlar os custos. Esses exemplos ilustram que a demanda real pelo Fusion está concentrada em tarefas complexas e de baixa frequência, como pesquisa, depuração, revisão e tomada de decisões críticas. O uso típico consiste em atualizações proativas após um único modelo encontrar um gargalo, em vez de um processo automatizado de alta frequência habilitado por padrão. As evidências existentes comprovam a existência dessa demanda, mas as informações disponíveis publicamente ainda são insuficientes para determinar se ela pode formar um mercado pago independente e em larga escala.

V. O Futuro da Fusão

Embora a redução nos custos de inferência pareça beneficiar o Fusion, ela também reduz simultaneamente os custos de modelos individuais robustos, roteamento e validação externa. O Fusion não compete com base em modelos obsoletos, mas sim na melhoria contínua de modelos individuais de última geração e linhas de base de orquestração.

O Devin Fusion da Cognition demonstra a direção desta competição: deixar modelos dispendiosos para a fase de tomada de decisão e delegar tarefas mecânicas e verificáveis a modelos mais baratos. Nos autotestes dos fornecedores, a pontuação geral do Fusion + Fable 5 aumentou ligeiramente de 57,0 para 57,6, com o custo médio diminuindo de US$ 5,12 para US$ 3,00; no entanto, nos cinco estudos de caso publicados, embora os custos tenham diminuído entre 25% e 62%, as pontuações das tarefas oscilaram entre +12 e -27. Refatorações ES6 bem definidas e exaustivamente testadas subiram de 98 para 100 pontos; funções React/Redux que dependem da compreensão da interação e de requisitos implícitos, quando mal delegadas, caíram de 54 para 27 pontos.

▲ Figura 6: Pontuações e custos das tarefas de fusão de modelos Devin. Estes são exemplos selecionados pelos fornecedores e não representam a distribuição geral, mas apontam claramente para o seguinte: a principal capacidade dos futuros sistemas multimodelos não é chamar mais modelos, mas definir os limites de degradação corretos. Tarefas mecânicas e verificáveis podem ser atribuídas a modelos mais baratos, enquanto tarefas que exigem alto poder de decisão devem ser deixadas para modelos de ponta. O OpenRouter vende "mais inteligência", enquanto o Cognition vende "inteligência equivalente a um custo menor"; a segunda proposta está mais próxima da direção de longo prazo. Quanto mais próximo o sistema estiver da economia de produção, menos ele se assemelha à Fusão de Modelos em sentido estrito e mais se assemelha a roteamento, delegação e verificação.

No final de julho, notícias indicaram que a Stripe estava em negociações para adquirir a OpenRouter por aproximadamente US$ 10 bilhões, embora o negócio ainda não tenha sido confirmado. Esse sinal não deve ser interpretado como uma validação de mercado da Fusion: o principal valor da OpenRouter não reside em nenhum painel específico, mas em sua camada de chamadas neutra que conecta mais de 5 milhões de desenvolvedores a mais de 400 modelos. A Stripe já fornece faturamento, tributação e controle de risco para a OpenRouter e permite que os desenvolvedores criem contas, obtenham chaves de API e se conectem a pagamentos diretamente por meio do Stripe Projects. O que a Stripe provavelmente está adquirindo é o gateway de transações para inferência de IA: a OpenRouter controla a seleção de modelos, o uso de tokens e os custos, enquanto a Stripe lida com preços, faturamento e pagamentos. Isso fornece um sinal de mercado para a avaliação de valor mencionada anteriormente: o valor na era multimodelos provavelmente permanecerá na camada de orquestração, que pode observar tarefas, alocar chamadas e concluir liquidações; a Fusion é meramente uma estratégia de atualização de alto custo sobre isso.

Os futuros sistemas multimodelo não invocarão painéis automaticamente; em vez disso, primeiro estimarão a dificuldade da tarefa, os custos de validação e as penalidades por erro. A busca de divergência multimodelo só prosseguirá quando modelos individuais mais robustos, inferência estendida e ferramentas externas forem insuficientes. A taxa de ativação, a taxa de sucesso incremental e o custo validado por unidade de resultado são as únicas métricas de produto relevantes. A fusão permanecerá como um recurso de baixa frequência, em vez de se tornar a arquitetura padrão ou uma categoria independente.

VI. Fontes

OpenRouter: Superando o desempenho de ponta com o Fusion

Documentação do roteador OpenRouter Fusion

Cognição: Devin Fusion --- Desempenho de ponta com custo 35% menor

Microsoft Research: Switchcraft --- Roteador de Modelo de IA para Chamada de Ferramentas Agéticas

Quando a combinação de modelos de linguagem é útil?

O raciocínio multiagente melhora a eficiência computacional.

Sistemas LLM de agente único superam sistemas multiagentes em raciocínio multi-salto sob orçamentos de tokens de pensamento iguais.

A combinação de agentes aprimora as capacidades de modelos de linguagem de grande porte.

RouteLLM: Aprendendo a rotear LLMs com dados de preferência

LitBench: Um parâmetro de referência para avaliação da escrita criativa.

Comparação de modelos de análise artificial

O preço do progresso: desempenho de preços e o futuro da IA

Perplexidade: O que é o Conselho Modelo?

Exemplo de usuário do Perplexity: Conselho Modelo para pesquisa financeira

Agente Hermes: Documentação de Mistura de Agentes

A Stripe fornece a infraestrutura necessária para o acesso global ao modelo de IA do OpenRouter.

Axios: O que está por trás da suposta mudança da Stripe para o OpenRouter?