Des améliorations de notation aux paiements : l’illusion de la demande dans la fusion de modèles

I. Qu'est-ce que la fusion de modèles ?

En juin 2026, le marché de l'IA a vu apparaître deux produits appelés « Fusion » en moins de trois semaines.

Le 12 juin, OpenRouter a lancé Fusion Router, présenté comme « Dépasser les performances de Frontier avec Fusion ». Lors de son évaluation approfondie DRACO, le groupe de modèles composé de Fable 5 et GPT-5.5 a obtenu un score de 69,0 points, surpassant ainsi les 65,3 points du modèle Fable 5 seul. L'argument de vente d'OpenRouter est simple : lorsqu'un modèle unique ne suffit pas, plusieurs modèles permettent de répondre à la même question, puis sont comparés et synthétisés par un expert.

Le 29 juin, Cognition a lancé Devin Fusion, mais sous le titre « Des performances de pointe à un coût 35 % inférieur ». Au lieu de faire exécuter la tâche complète par plusieurs modèles, ce système permet au modèle frontal de gérer la planification et le jugement, laissant les tests, les modifications mécaniques et autres tâches au modèle secondaire moins coûteux, et changeant dynamiquement de modèle pendant l'exécution.

Ce même terme renvoie à deux logiques économiques opposées. OpenRouter utilise davantage de calculs pour atteindre des plafonds plus élevés ; Cognition, quant à lui, cherche à réduire les coûts de calcul tout en préservant la qualité initiale. Ce contraste est plus révélateur que n'importe quel classement de modèles. Le principe technique de la fusion de modèles est certes valable : plusieurs tentatives peuvent surpasser une tentative unique. Mais ce que le marché récompense réellement, ce n'est pas le nombre d'appels de modèles, mais la capacité à dépenser moins et à livrer plus rapidement une fois les seuils de qualité atteints.

▲ Figure 1 : Deux types de fusion au cours du même mois. Cet article définit la fusion de modèles comme une architecture plus restreinte : plusieurs modèles traitent la même tâche en parallèle, leurs résultats sont analysés et comparés, et un seul modèle fournit finalement la réponse. Devin Fusion ne correspond pas à cette définition ; elle se rapproche davantage du routage dynamique et de la délégation de tâches. Elle est placée en début d’article car le marché utilise le terme « fusion » comme un terme générique pour toute orchestration multi-modèles, alors que les produits réellement performants s’éloignent souvent de cette définition restrictive.

Notre analyse est pessimiste : la fusion de modèles est une assurance qualité onéreuse. Elle peut améliorer les performances absolues de certaines tâches, mais elle repousse rarement les limites de l'efficacité en termes de coût, de qualité et de latence. Très peu de tâches justifient réellement cet investissement. Elle subsistera, mais il est plus probable qu'elle devienne une fonctionnalité ponctuelle plutôt que l'architecture par défaut, et il est peu probable qu'elle devienne une catégorie à part entière.

II. Quelles options de modèle sont actuellement disponibles ?

Les discussions autour de Fusion s'orientent souvent vers les classements de précision, mais les entreprises ne s'intéressent pas à ces classements. Elles recherchent des résultats acceptables pour une tâche donnée, tout en tenant compte du prix, de la latence, de la confidentialité et de la stabilité. Tant qu'un modèle bon marché est déjà disponible…

Une fois le seuil d'acceptation par l'entreprise franchi, continuer à payer pour des fonctionnalités « plus intelligentes » peut ne plus être économiquement viable. La rentabilité est le véritable moteur du marché des modèles.

▲ Figure 2 : Intelligence du modèle et coût d’une tâche unique. Sur l’échelle logarithmique, les points les plus significatifs ne sont pas les scores les plus élevés en haut à droite, mais plutôt ceux qui s’écartent de la tendance prix-capacités : ils offrent des capacités suffisantes à un prix inférieur et constituent des exceptions en termes d’efficacité pour des charges de travail spécifiques. Bien que l’indice composite ne permette pas de déterminer directement quel modèle est le mieux adapté à la revue de code, à la recherche chinoise ou au déploiement réglementé, il révèle une tendance : l’offre de modèles se banalise et le « modèle le plus performant » se distingue de « l’option optimale ».

Il existe actuellement quatre principales stratégies d'achat sur le marché pour combler ce même écart de qualité.

La première approche consiste à passer directement à un modèle unique plus performant. C'est la méthode la plus simple et la plus facile à auditer ; elle reste généralement privilégiée tant que le surcoût marginal du modèle haut de gamme est inférieur au coût des erreurs ou des reprises. La deuxième approche consiste à augmenter la puissance de calcul lors des tests sur le même modèle, par exemple en étendant l'inférence, la cohérence interne ou en effectuant un échantillonnage multiple. La troisième approche repose sur le routage, la mise en cascade et la délégation de tâches : on utilise d'abord un modèle moins coûteux pour gérer les parties vérifiables ou mécaniques, et on ne procède à une mise à niveau qu'en cas de difficultés. La quatrième approche, dans un sens plus restreint, est la fusion de modèles : plusieurs modèles répondent de manière répétée à la même question, puis la réponse finale est obtenue par l'analyse et la synthèse des modèles.

Les quatre méthodes permettent d'« augmenter la puissance de calcul au détriment de la qualité », mais la différence réside dans la répartition de cette puissance. Les extensions de modèle unique permettent une inférence plus poussée, le routage une allocation de ressources plus précise, tandis que Fusion privilégie un plus grand nombre de réponses candidates. Les trois premières méthodes concentrent leurs ressources sur les étapes les plus susceptibles d'influencer le résultat ; Fusion, en revanche, investit d'abord dans les avis redondants, puis parie sur la capacité du modèle de révision à identifier les différences pertinentes. Les modèles candidats doivent fournir suffisamment d'informations indépendantes, et les réviseurs doivent être capables de les reconnaître.

Fusion est la seule option qui surpasse les trois autres.

Le routage a démontré que les différences de capacités entre les modèles représentent principalement une opportunité d'optimisation de la planification. RouteLLM a permis de réduire les coûts de plus de moitié dans certaines évaluations, sans compromettre la qualité ; Switchcraft a quant à lui réalisé une réduction des coûts de 84 % avec une précision de 82,9 %, ce qui, selon l'étude, correspond à des économies de plus de 3 600 $ par million de requêtes. Ces résultats doivent encore être reproduits sur le trafic interne de l'entreprise, mais la logique économique est simple : au lieu de faire appel à plusieurs modèles lors d'une conférence, il suffit d'attribuer chaque tâche au modèle le plus économique et le plus performant.

Cela signifie que le marché comblera d'abord le déficit de qualité par des mises à niveau, le routage et la validation ; ce n'est que lorsque ces méthodes seront encore insuffisantes qu'il y aura une raison d'acheter davantage de réponses candidates pour Fusion.

III. Pourquoi l'amélioration des scores n'équivaut-elle pas à avoir de la valeur ?

Fusion doit surmonter simultanément trois obstacles : l’amélioration de la qualité doit compenser le surcoût et la latence supplémentaires, les modèles candidats doivent fournir des informations indépendantes et les évaluateurs doivent identifier systématiquement de meilleures réponses. Si l’un de ces obstacles est franchi, l’amélioration du score ne se traduit pas en valeur ajoutée en production. Coût de calcul : quel est le coût supplémentaire en termes de budget et de latence ? L’amélioration du score de Fusion représente avant tout une dépense de calcul. OpenRouter appelle plusieurs modèles de panel en parallèle, puis les évaluateurs et le modèle intégré génèrent la réponse. Les trois groupes témoins de DRACO ont tous enregistré des améliorations de score : Fable 5 + GPT-5.5 est passé de 65,3 à 69,0 ; Opus 4.8 (auto-fusion) de 58,8 à 65,5 ; et le groupe à trois modèles à faible coût de 60,3 à 64,7.

Cependant, l'amélioration de l'auto-fusion d'Opus est plus importante, ce qui suggère que les gains proviennent davantage de la recherche et de l'échantillonnage que de la complémentarité des connaissances entre les modèles . Une comparaison équitable devrait être effectuée entre l'auto-cohérence, les inférences plus longues et les modèles mono-agent robustes, à budget de jetons égal. Les recherches existantes montrent également que les modèles multi-agents peuvent améliorer les performances jusqu'à 7,1 points de pourcentage pour un coût de calcul environ 20 fois supérieur ; à budget égal, les modèles « débat » et « Mixture-of-Agents » ne sont supérieurs que de 1,3 et 2,7 points de pourcentage à l'auto-cohérence, respectivement, tandis qu'une autre étude, avec un nombre égal de jetons de raisonnement, a conclu que les modèles mono-agent sont équivalents, voire meilleurs. De nombreux « gains de collaboration » disparaissent après l'alignement des registres de calcul.

▲ Figure 3 : Amélioration des performances et coût du produit d’OpenRouter. Le panneau par défaut à 3 modèles d’OpenRouter coûte environ 4 à 5 fois plus cher qu’un panneau standard et est 2 à 3 fois plus lent . Cependant, les informations complètes concernant les jetons, les coûts et la latence pour chaque configuration DRACO ne sont pas divulguées, ce qui empêche de déterminer si l’amélioration de 3,7 points est réellement intéressante. L’évaluation ne portait que sur 100 tâches de texte en anglais simple, dont seulement 93 configurations liées à Fable ont été réalisées. Modifier le modèle d’évaluation peut faire varier le score absolu de 10 à 25 points de pourcentage. Cela prouve que Fusion peut améliorer les scores, mais ne prouve pas que Fusion améliore le retour sur investissement en production.

L'invocation sélective ne peut que réduire les coûts. Selon les estimations d'OpenRouter, le coût global est environ 1,03 à 1,04 fois supérieur lorsque le taux de déclenchement est de 1 % ; 1,30 à 1,40 fois supérieur lorsqu'il est de 10 % ; et 1,75 à 2,00 fois supérieur lorsqu'il est de 25 %.

▲ Figure 4 : Analyse économique globale de l’invocation sélective de Fusion. Les requêtes les plus complexes sont les plus susceptibles de déclencher Fusion, mais le système doit attendre les membres du panel les plus lents avant de terminer l’examen et la génération séquentielle. Par conséquent, la latence de fin de traitement se concentre sur les tâches les plus importantes. L’invocation multi-fournisseurs augmente également la surface de défaillance, la complexité des audits et l’exposition à la confidentialité. Le coût de Fusion ne se limite pas au prix de l’API, mais inclut également le temps d’attente et les risques système supplémentaires. Complémentarité de l’information : plusieurs modèles fournissent-ils réellement des informations différentes ? La valeur de Fusion dépend de la capacité des modèles candidats à apporter des informations indépendantes, mais différents modèles partagent souvent des corpus d’entraînement, des sources de pages Web et des prémisses erronées. Dans les tâches de recherche, cela conduit à une « falsification de citations » : plusieurs modèles remontent à la même source, mais sont présentés comme plusieurs éléments de preuve indépendants. Si le système ne conserve pas la provenance et les chemins de recherche au niveau de l’affirmation, le coût de l’API augmente de manière quasi linéaire avec le nombre de modèles, mais la diversité des preuves n’augmente pas nécessairement.

Dans son article de 2026 , *Quand la combinaison de modèles de langage est-elle utile ?* , Josef Chen, cofondateur et PDG de KAIKAKU.AI, a étudié 67 modèles provenant de 21 fournisseurs de services. Pour les tâches mathématiques ouvertes, la probabilité prédite que tous les modèles répondent incorrectement simultanément était de 2,3 %, mais la probabilité réelle atteignait 5,2 %, soit environ 2,3 fois la valeur prédite . Le taux d'échec simultané augmentait encore, atteignant 7,9 % et 12,7 % respectivement pour la tâche de codage et la version à réponse libre de GPQA-Diamond. Avec 100 questions GPQA-Diamond, environ 13 questions suffisaient à entraîner des réponses incorrectes de tous les modèles candidats, ne laissant aucune réponse correcte pour le vote, la révision ou la synthèse. La divergence des modèles sur les questions faciles amplifie la valeur combinée, tandis que sur les questions finales les plus cruciales, ils pouvaient tous échouer. Évaluation de la fiabilité : le système est-il capable d'identifier et de synthétiser de meilleures réponses ? Même avec des réponses de candidats complémentaires, la valeur reste soumise à l'évaluation. Lorsque les candidats sont cohérents, les évaluateurs peuvent interpréter à tort des erreurs similaires comme un niveau de confiance élevé ; en cas de divergence, une expertise suffisante est nécessaire pour sélectionner la bonne réponse. Le modèle composite peut également occulter des opinions minoritaires importantes ou transformer de véritables désaccords en conclusions définitives.

Dans les tâches de programmation, les compilateurs, les tests et l'analyse statique sont souvent plus fiables que l'avis d'un autre modèle ; dans les tâches créatives, la relecture et la synthèse peuvent facilement gommer les différences et aboutir à une réponse moyenne. Même le modèle de relecture le plus performant de LitBench n'atteint qu'un taux de concordance de 73 % avec les préférences des auteurs. Lorsqu'il existe des validateurs externes peu coûteux pour la tâche, ou lorsque la notion même de « bon » repose sur un jugement subjectif, les améliorations apportées par Fusion sont difficiles à justifier financièrement.

IV. Qui paiera pour Fusion ?

La demande pour Fusion est soumise à deux conditions essentielles : la possibilité d’exploiter plusieurs modèles pour la tâche et la capacité de cet avantage à générer des revenus durables. La première est d’ordre technique, la seconde relève du marché. Du point de vue de l’applicabilité technique et de la viabilité économique, Fusion exige que la probabilité de corriger une erreur, multipliée par la perte évitable liée à une seule erreur, soit supérieure au coût, à la latence, à la complexité opérationnelle et aux risques d’atteinte à la vie privée associés à l’ajout de nouvelles API.

Les scores de référence ne permettent pas de répondre à cette question de rentabilité. La fusion n'est viable que lorsque le coût de l'erreur est élevé, que les modèles candidats offrent des pistes de recherche complémentaires, que les validateurs externes moins coûteux font défaut et que l'entreprise peut accepter une latence supplémentaire et un risque lié au fournisseur ; le résultat final doit néanmoins être confirmé par une analyse humaine ou par des preuves externes.

▲ Figure 5 : De l’applicabilité technologique aux besoins durables. Les éléments répondant à ces critères comprennent principalement la recherche et la diligence raisonnable à forte valeur ajoutée, les revues d’architecture et de sécurité, ainsi que les « seconds avis » avant les décisions irréversibles. Ils partagent des points communs : des contraintes incomplètes, des coûts d’omission élevés et la valeur intrinsèque d’une approche indépendante. À l’inverse, le code régulier, les applications à consommation immédiate, les flux de travail à haut débit et à faible marge, et les tâches directement vérifiables par des tests ou des règles ne nécessitent généralement pas de fusion. Les organismes de réglementation peuvent également rejeter les panels multi-fournisseurs en raison des limites des données et des exigences d’audit. De la disposition à payer aux besoins durables . L’utilité technologique peut générer une forte disposition à payer, mais elle n’équivaut pas à une demande évolutive. Pour qu’une demande durable se matérialise, les pertes dues aux erreurs doivent être quantifiables, les tâches doivent être récurrentes, les responsabilités budgétaires doivent être clairement définies au sein de l’organisation et la fusion doit systématiquement surpasser les experts humains, les modèles robustes à entité unique et la validation externe. Cependant, les budgets alloués aux vérifications préalables sont souvent dirigés vers des analystes et des sources fiables, les budgets de sécurité vers des audits professionnels, et les décisions irréversibles sont trop rarement prises.

Par conséquent, nous ne sommes pas optimistes quant aux entreprises qui se contentent de fournir des interfaces multi-modèles, d'exécuter des panels par défaut ou de considérer les algorithmes de sélection de modèles statiques comme un avantage concurrentiel. La connexion des API est facile à reproduire et les stratégies fixes deviennent rapidement inefficaces à mesure que les capacités et les prix des modèles évoluent. Sans connaître le taux d'erreur ni le nombre de corrections effectuées par Fusion, il est impossible de tarifer cette assurance. Ceux qui maîtrisent les résultats réels sont plus susceptibles d'en tirer profit : plateformes de passerelle et d'agent, applications verticales, responsables de flux de travail et produits d'évaluation et d'observabilité. Ils connaissent le coût des erreurs, peuvent observer les résultats et optimiser les stratégies de déclenchement. La véritable difficulté ne réside pas dans la liste des panels, mais dans la détermination des situations où il ne faut pas invoquer Fusion. Validation du marché : les marchés publics ne permettent pas d'évaluer précisément la demande pour Fusion, mais ils illustrent déjà son utilisation. Perplexity Model Council est réservé aux utilisateurs de Max et Enterprise Max, qui paient 200 $ par mois. Ces utilisateurs sélectionnent manuellement trois modèles en ligne pour la recherche d'investissements, la prise de décision complexe et la validation d'informations. Parmi les cas d'utilisation publics, on peut citer l'intégration de Model Council dans les flux de travail de recherche boursière via l'automatisation du navigateur. La solution « Mixture of Agents » d'Hermes présente Fusion comme un modèle virtuel sélectionnable au sein de l'agent : les utilisateurs peuvent passer à un modèle dédié pour résoudre un problème complexe via la commande /moa, ou l'activer en continu lors de sessions complexes. L'analyse est alors assurée par plusieurs modèles de référence, et l'agrégateur fait appel à des outils pour mener à bien la tâche. Hermes a par la suite réduit la fréquence de diffusion par défaut et réutilisé les retours d'information des modèles précédents afin de maîtriser les coûts. Ces exemples montrent que la demande réelle pour Fusion se concentre sur des tâches complexes et peu fréquentes, telles que la recherche, le débogage, la relecture et la prise de décision critique. L'utilisation typique consiste en des mises à niveau proactives lorsqu'un modèle rencontre un goulot d'étranglement, plutôt qu'en un processus automatisé à haute fréquence activé par défaut. Les données existantes confirment l'existence de cette demande, mais les informations publiques disponibles restent insuffisantes pour déterminer si elle peut constituer un marché payant indépendant et de grande envergure.

V. L'avenir de la fusion

Bien que la baisse des coûts d'inférence semble profiter à Fusion, elle réduit simultanément les coûts liés aux modèles uniques performants, au routage et à la validation externe. Fusion ne mise pas sur les appels de modèles d'hier, mais sur l'amélioration continue des modèles uniques de nouvelle génération et des référentiels d'orchestration.

Devin Fusion de Cognition illustre la tendance actuelle : réserver les modèles coûteux à la phase de décision et déléguer les tâches mécaniques et vérifiables à des modèles moins onéreux. Lors des autotests des fournisseurs, le score global de Fusion + Fable 5 a légèrement progressé, passant de 57,0 à 57,6, tandis que le coût moyen a diminué de 5,12 $ à 3,00 $. Cependant, dans les cinq études de cas publiées, malgré une baisse des coûts de 25 % à 62 %, les scores des tâches ont fluctué entre +12 et -27. Les refactorisations ES6 bien définies et rigoureusement testées ont vu leur score passer de 98 à 100 points ; en revanche, les fonctions React/Redux reposant sur la compréhension des interactions et des exigences implicites, lorsqu'elles sont mal déléguées, ont chuté de 54 à 27 points.

▲ Figure 6 : Scores et coûts des tâches de fusion Devin. Ces exemples, sélectionnés par les fournisseurs, ne représentent pas la distribution globale, mais illustrent clairement le point suivant : la capacité essentielle des futurs systèmes multimodèles ne consiste pas à faire appel à davantage de modèles, mais à définir les seuils de dégradation appropriés. Les tâches mécaniques vérifiables peuvent être attribuées à des modèles moins coûteux, tandis que les tâches nécessitant un jugement important doivent être réservées aux modèles de pointe. OpenRouter vend « plus d’intelligence », tandis que Cognition vend « une intelligence équivalente à moindre coût » ; cette seconde proposition est plus conforme à la vision à long terme. Plus le système se rapproche des économies d’échelle de la production, moins il ressemble à la fusion de modèles au sens strict, et plus il ressemble au routage, à la délégation et à la vérification.

Fin juillet, des articles de presse indiquaient que Stripe était en pourparlers pour acquérir OpenRouter pour environ 10 milliards de dollars, bien que l'opération n'ait pas encore été confirmée. Ce signal ne doit pas être interprété comme une validation de marché pour Fusion : la valeur fondamentale d'OpenRouter ne réside pas dans un panel particulier, mais dans sa couche d'appel neutre connectant plus de 5 millions de développeurs à plus de 400 modèles. Stripe assure déjà la facturation, la gestion des taxes et le contrôle des risques pour OpenRouter, et permet aux développeurs de créer des comptes, d'obtenir des clés API et de se connecter directement aux paiements via Stripe Projects. Ce que Stripe acquiert vraisemblablement, c'est la passerelle de transaction pour l'inférence IA : OpenRouter contrôle la sélection des modèles, l'utilisation des jetons et les coûts, tandis que Stripe gère la tarification, la facturation et les paiements. Ceci confirme l'analyse de valeur mentionnée précédemment : à l'ère du multi-modèle, la valeur réside probablement davantage dans la couche d'orchestration, capable d'observer les tâches, d'allouer les appels et de finaliser les règlements ; Fusion n'est qu'une stratégie de mise à niveau coûteuse.

Les futurs systèmes multimodèles n'invoqueront pas automatiquement de panels ; ils estimeront d'abord la difficulté de la tâche, les coûts de validation et les pénalités d'erreur. La recherche de divergence multimodèle ne sera entreprise que lorsque des modèles uniques plus performants, une inférence étendue et des outils externes s'avéreront insuffisants. Le taux de déclenchement, le taux de réussite incrémentiel et le coût validé par unité de résultat seront les seuls indicateurs de performance pertinents. La fusion restera une fonctionnalité peu fréquente, et ne deviendra ni l'architecture par défaut ni une catégorie à part entière.

VI. Sources

OpenRouter : Dépasser les performances de Frontier avec Fusion

Documentation du routeur OpenRouter Fusion

Cognition : Devin Fusion – Des performances de pointe à un coût réduit de 35 %

Microsoft Research : Switchcraft – Un routeur de modèles IA pour l’appel d’outils automatisés

Quand la combinaison de modèles de langage est-elle utile ?

Le raisonnement multi-agents améliore l'efficacité du calcul

Les modèles LLM mono-agent surpassent les systèmes multi-agents en matière de raisonnement multi-sauts avec des budgets de jetons de pensée égaux.

Le modèle mixte d'agents améliore les capacités des grands modèles de langage

RouteLLM : Apprendre à router les LLM avec des données de préférence

LitBench : un outil d'évaluation de l'écriture créative

Comparaison de modèles d'analyse artificielle

Le prix du progrès : performance des prix et avenir de l'IA

Perplexité : Qu'est-ce qu'un conseil modèle ?

Exemple d'utilisateur de Perplexity : Conseil modèle pour la recherche financière

Agent Hermès : Documentation sur le mélange d'agents

Stripe permet à OpenRouter d'accéder à son modèle d'IA global

Axios : Que se cache derrière le déménagement annoncé de Stripe vers OpenRouter ?