IOSG : De l'Amélioration des Scores au Paiement, L'Illusion de la Demande pour la Fusion de Modèles

Auteur : Yiping & David @ IOSG

Cet article est uniquement à des fins éducatives et de communication et ne constitue pas un conseil en investissement. Veuillez indiquer la source lors de la republication et contacter l'équipe d'IOSG pour les directives d'autorisation et de republication. Tous les projets mentionnés dans cet article ne sont pas des recommandations ou des conseils d'investissement.

Qu'est-ce que la Fusion de Modèles ?

En juin 2026, le marché de l'IA a vu deux produits nommés "Fusion" en moins de trois semaines.

Le 12 juin, OpenRouter a lancé Fusion Router, intitulé Surpasser la Performance de Frontière avec Fusion. Dans son évaluation de recherche approfondie DRACO, le groupe de modèles composé de Fable 5 et GPT-5.5 a obtenu un score de 69.0, dépassant le score de 65.3 du modèle unique Fable 5. Le point de vente d'OpenRouter est simple : lorsque qu'un modèle unique n'est pas suffisant, laissez plusieurs modèles répondre à la même question, puis faites comparer et synthétiser les résultats par un modèle de révision.

Le 29 juin, Cognition a lancé Devin Fusion, mais son titre était Performance de Frontière à 35 % de Coût Inférieur. Il n'a pas fait répéter toute la tâche par plusieurs modèles, mais a plutôt confié au modèle principal la responsabilité de la planification et du jugement, tout en déléguant les tests, les modifications mécaniques et d'autres tâches à un acolyte moins cher, changeant dynamiquement de modèles pendant l'exécution.

Le même terme pointe vers deux logiques économiques opposées. OpenRouter achète des limites plus élevées avec plus de calcul ; Cognition tente de réduire le calcul coûteux tout en maintenant la qualité existante. Ce contraste illustre mieux le problème que n'importe quel classement de modèles. La proposition technique de la fusion de modèles est en effet valide : plusieurs tentatives ont une chance de dépasser une seule tentative. Cependant, le marché récompense réellement non pas "l'appel à plus de modèles" mais plutôt qui peut dépenser moins et livrer plus rapidement après avoir atteint des seuils de qualité.

▲ Figure 1 : Deux types de Fusion dans le même mois

Cet article définit la Fusion de Modèles comme une architecture plus étroite : plusieurs modèles répondent à la même tâche en parallèle, un modèle de révision compare les résultats, et finalement, un modèle produit la réponse. Devin Fusion ne tombe pas sous cette définition ; il est plus proche du routage dynamique et de la délégation de tâches. Il est placé au début car le marché traite "Fusion" comme un terme générique pour toute orchestration multi-modèles, tandis que les produits réellement efficaces s'éloignent souvent de la définition étroite de la fusion de modèles.

Notre jugement est quelque peu pessimiste : la Fusion de Modèles est une assurance qualité coûteuse. Elle peut améliorer la performance absolue de certaines tâches mais pousse rarement la frontière d'efficacité du coût—qualité—délai vers l'extérieur. Il y a peu de tâches qui valent vraiment la peine d'acheter cette assurance. Elle restera mais est plus susceptible de devenir une fonctionnalité déclenchée à faible fréquence plutôt qu'une architecture par défaut, rendant plus difficile son statut de catégorie indépendante.

Quelles Options Sont Actuellement Disponibles pour les Modèles ?

Discuter de la Fusion peut facilement mener à des classements de précision, mais les entreprises n'achètent pas des positions de classement. Les entreprises achètent des résultats qualifiés pour une tâche tout en tenant compte du prix, du délai, de la confidentialité et de la stabilité. Tant qu'un modèle moins cher a franchi la ligne d'acceptation commerciale, continuer à payer pour "plus intelligent" peut ne pas avoir de sens économique. L'efficacité des coûts est la véritable ligne principale du marché des modèles.

▲ Figure 2 : Intelligence du Modèle vs. Coût de Tâche Unique, avec l'axe horizontal sur une échelle logarithmique

L'aspect le plus remarquable du graphique n'est pas le score le plus élevé dans le coin supérieur droit mais les points s'écartant de la tendance prix—capacité : ils fournissent une capacité suffisante à un prix inférieur et sont des exceptions d'efficacité sur des charges de travail spécifiques. L'indice composite ne peut pas répondre directement à quel modèle est le meilleur pour la révision de code, les études chinoises ou les déploiements réglementés, mais il révèle une direction : l'offre de modèles devient une marchandise, et "le modèle le plus fort" se sépare de "choix optimal".

Face au même écart de qualité, le marché a actuellement quatre principales méthodes d'achat.

La première est de passer directement à un modèle unique plus puissant. C'est la méthode la plus simple et la plus facile à auditer ; tant que l'augmentation de prix marginal du modèle haut de gamme est inférieure au coût des erreurs ou des retouches, c'est généralement encore le premier choix. La deuxième est d'augmenter le calcul sur le même modèle pendant les tests, comme prolonger l'inférence, l'auto-consistance ou l'échantillonnage multiple. La troisième est le routage, le chaînage et la délégation de tâches : d'abord utiliser des modèles moins chers pour gérer les parties vérifiables ou mécaniques, puis ne mettre à niveau que lorsque des difficultés surviennent. La quatrième est la définition étroite de la Fusion de Modèles : avoir plusieurs modèles répondant à plusieurs reprises à la même question, puis former la réponse finale par le biais de modèles de révision et de synthèse.

Les quatre méthodes peuvent "échanger qualité contre plus de calcul", la différence étant où le calcul est dépensé. L'expansion du modèle unique achète un raisonnement plus profond, le routage achète une allocation de ressources plus précise, tandis que la Fusion achète plus de réponses candidates. Les trois premières méthodes concentrent le budget sur les segments les plus susceptibles de changer le résultat ; la Fusion, cependant, paie d'abord pour des opinions répétées et parie ensuite que le modèle de révision peut identifier des différences efficaces. Les modèles candidats ne peuvent surpasser les trois premières solutions que s'ils fournissent suffisamment d'informations indépendantes et que le réviseur peut reconnaître ces informations.

Le routage a déjà prouvé que les différences de capacité entre les modèles sont principalement une opportunité de planification. RouteLLM a réduit les coûts de plus de 2 fois dans certaines évaluations sans sacrifier la qualité ; Switchcraft a réalisé une réduction de coût de 84 % avec une précision de 82,9 %, estimant des économies de plus de 3 600 $ par million de requêtes selon l'article. Les résultats doivent encore être reproduits sur le trafic propre de l'entreprise, mais la logique économique est simple : il n'est pas nécessaire d'avoir plusieurs modèles dans une réunion ; il suffit d'assigner chaque tâche au modèle qualifié le moins cher.

Cela signifie que le marché utilisera d'abord des mises à niveau, du routage et de la validation pour résoudre les écarts de qualité ; seulement lorsque ces méthodes sont encore insuffisantes, il y a une raison d'acheter plus de réponses candidates pour la Fusion.

Pourquoi l'Amélioration des Scores n'Équivaut-elle Pas à de la Valeur ?

Parce que la Fusion doit simultanément franchir trois seuils : la qualité incrémentale doit couvrir les coûts et les délais supplémentaires, les modèles candidats doivent fournir des informations indépendantes, et le réviseur doit identifier de manière stable de meilleures réponses. Si l'un de ces éléments ne tient pas, les améliorations de score ne peuvent pas être converties en valeur de production.

Calcul des Coûts : Quel Budget et Quel Délai Doivent Être Ajoutés ?

L'amélioration du score provenant de la Fusion est principalement une dépense computationnelle définie. OpenRouter appellera plusieurs modèles de panel en parallèle, puis générera des réponses par le biais de modèles de révision et de synthèse. Tous les trois groupes dans DRACO ont amélioré leurs scores : Fable 5 + GPT-5.5 est passé de 65.3 à 69.0 ; l'auto-fusion d'Opus 4.8 est passée de 58.8 à 65.5 ; et le groupe à trois modèles à faible coût est passé de 60.3 à 64.7.

Cependant, l'amélioration de l'auto-fusion d'Opus est plus grande, indiquant que les gains peuvent provenir de recherches et d'échantillonnages supplémentaires plutôt que de la complémentarité des connaissances entre modèles. Une comparaison équitable devrait prendre en compte l'auto-consistance, un raisonnement plus long et des modèles uniques puissants sous le même budget de jetons. Des recherches existantes montrent également que les systèmes multi-agents peuvent s'améliorer jusqu'à 7,1 points de pourcentage sous une charge computationnelle d'environ 20 fois ; lorsque les budgets sont les mêmes, le débat et le Mixture-of-Agents ne sont que 1,3 et 2,7 points de pourcentage plus élevés que l'auto-consistance, tandis qu'une autre étude sur les jetons de raisonnement a révélé qu'un seul agent est à égalité ou meilleur. De nombreux "gains collaboratifs" peuvent disparaître après l'alignement des comptes computationnels.

▲ Figure 3 : Amélioration de Benchmark d'OpenRouter et Coût du Produit

Le coût par défaut d'OpenRouter pour un panel à 3 modèles est d'environ 4 à 5 fois celui de la génération ordinaire, et il est 2 à 3 fois plus lent, mais il n'a pas divulgué le jeton complet, le coût et le délai pour chaque configuration DRACO, rendant impossible de déterminer si une amélioration de 3,7 points en vaut la peine. L'évaluation n'a inclus que 100 tâches en anglais de texte pur, et les configurations liées à Fable n'ont terminé que 93 éléments ; changer le modèle de révision pourrait faire varier les scores absolus de 10 à 25 points de pourcentage. Cela prouve que la Fusion peut améliorer les scores mais ne prouve pas que la Fusion améliore le ROI de production.

L'appel sélectif ne peut que diluer les coûts. Selon les plages divulguées par OpenRouter, lorsque le taux de déclenchement est de 1 %, le coût global est d'environ 1,03 à 1,04 fois ; à 10 %, il est de 1,30 à 1,40 fois ; et à 25 %, il atteint 1,75 à 2,00 fois.

▲ Figure 4 : Économie Globale de la Fusion d'Appels Sélectifs

Les demandes les plus difficiles sont les plus susceptibles de déclencher la Fusion, mais le système doit attendre le membre de panel le plus lent, puis compléter la révision et la génération de manière sérielle, donc les délais de queue se concentrent sur les tâches les plus précieuses. Les appels multi-fournisseurs élargissent également la surface de faute, la complexité d'audit et l'exposition à la confidentialité. Les coûts de la Fusion ne se limitent pas aux prix des API mais incluent également les temps d'attente et les nouveaux risques systémiques.

Complémentarité de l'Information : Les Modèles Multiples Fournissent-ils Vraiment des Informations Différentes ?

La valeur de la Fusion dépend de savoir si les modèles candidats apportent des informations indépendantes, mais différents modèles partagent souvent des corpus d'entraînement, des sources web et des prémisses erronées. Dans les tâches de recherche, cela peut conduire à "un lavage de citation" : plusieurs modèles retracent la même source mais sont emballés comme plusieurs pièces de preuve indépendantes. Si le système ne conserve pas la provenance au niveau des revendications et les chemins de recherche, à mesure que le nombre de modèles augmente, les coûts API augmentent presque linéairement, tandis que la diversité des preuves peut ne pas nécessairement augmenter.

Josef Chen, co-fondateur et PDG de KAIKAKU.AI, a étudié 67 modèles de 21 fournisseurs de services dans son article de 2026 "Quand la Combinaison de Modèles Linguistiques Aide-t-elle ?" Dans les tâches mathématiques ouvertes, la probabilité prédite que tous les modèles répondent incorrectement était de 2,3 %, mais le taux réel a atteint 5,2 %—environ 2,3 fois la valeur prédite ; le taux d'échec conjoint pour l'exécution des tâches de code de notation et la version de réponse libre GPQA-Diamond a encore augmenté à 7,9 % et 12,7 %.

Lors du passage à 100 questions GPQA-Diamond, environ 13 questions feraient en sorte que tous les modèles candidats répondent incorrectement, ne laissant aucune réponse correcte disponible pour le vote, la révision ou la synthèse. Les divergences entre modèles sur des questions plus faciles amplifient la valeur de la combinaison, tandis qu'ils peuvent échouer ensemble sur des questions de fin de queue où l'assurance est le plus nécessaire.

Évaluation de la Fiabilité : Le Système Peut-il Identifier et Synthétiser de Meilleures Réponses ?

Même si les réponses candidates sont complémentaires, leur valeur dépend toujours du processus de révision. Lorsque les candidats sont cohérents, les réviseurs peuvent interpréter par erreur des erreurs connexes comme une haute confiance ; lorsque les candidats divergent, ils doivent posséder une expertise suffisante pour sélectionner correctement. Les modèles composites peuvent également effacer des opinions minoritaires clés ou réécrire de véritables divergences en conclusions définitives.

Dans les tâches de codage, les compilateurs, les tests et l'analyse statique sont généralement plus fiables que l'opinion d'un autre modèle ; dans les tâches créatives, les révisions et les composites peuvent facilement comprimer les différences en réponses moyennes. Le modèle de révision prêt à l'emploi le plus puissant dans LitBench ne s'aligne qu'avec les préférences d'écriture créative humaine 73 % du temps. Lorsque les tâches ont déjà des validateurs externes bon marché, ou lorsque "bon" lui-même repose sur un jugement subjectif, l'amélioration du score provenant de la Fusion est difficile à traduire en valeur payable.

Qui Va Payer pour la Fusion ?

La demande pour la Fusion dépend de deux seuils : si les tâches peuvent bénéficier de modèles multiples et si ce bénéfice est suffisant pour créer des paiements soutenus. Le premier est une question technique, tandis que le second est une question de marché.

De l'Applicabilité Technique à la Viabilité Économique

La probabilité de corriger des erreurs multipliée par la perte évitable par erreur doit dépasser les coûts supplémentaires des API, des délais, de la complexité opérationnelle et des risques de confidentialité.

Les scores de base ne peuvent pas répondre à cette question de profit et de perte. La Fusion n'est probablement viable que lorsque le coût des erreurs est élevé, les modèles candidats fournissent des chemins de recherche complémentaires, il n'y a pas de validateurs externes moins chers, et l'entreprise peut accepter des délais et des risques de fournisseur supplémentaires ; les résultats finaux doivent toujours être confirmés par des humains ou des preuves externes.

▲ Figure 5 : De l'Applicabilité Technique à la Demande Durable

Les principaux domaines qui répondent à ces conditions sont la recherche de haute valeur et la diligence raisonnable, les examens d'architecture et de sécurité, et les "deuxième opinions" avant des décisions irréversibles. Leur point commun réside dans des contraintes incomplètes et des coûts d'omission élevés, où une ligne de pensée indépendante est précieuse en soi. En revanche, le codage de routine, les applications consommateurs en temps réel, les flux de travail à faible marge à haut débit, et les tâches pouvant être directement vérifiées 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 de données et des exigences d'audit.

De la Volonté de Payer à la Demande Durable

L'utilité technique peut conduire à une forte volonté de payer, mais cela ne s'égale pas à une demande évolutive. Pour former une demande soutenue, les pertes d'erreurs doivent être quantifiables, les tâches doivent se reproduire, il doit y avoir des propriétaires de budget clairs au sein de l'organisation, et la Fusion doit continuellement surpasser les experts humains, les modèles uniques puissants et la validation externe. Cependant, les budgets de diligence raisonnable vont souvent aux analystes et aux sources de confiance, les budgets de sécurité vont aux audits professionnels, et les décisions irréversibles se produisent trop rarement.

Par conséquent, nous ne sommes pas optimistes quant aux entreprises qui se contentent de créer des enveloppes multi-modèles, de se reposer sur des panels par défaut, ou de traiter les algorithmes de sélection de modèles statiques comme une forteresse. La connexion des API est facilement réplicable, et les stratégies fixes deviendront rapidement inefficaces à mesure que les capacités et les prix des modèles changent ; si l'on ne sait pas combien vaut une erreur ou combien de fois la Fusion a réellement corrigé des erreurs, il devient impossible de tarifer cette assurance. Ceux qui sont les plus susceptibles de capturer de la valeur sont les parties qui possèdent les résultats réels : les plateformes de passerelle et d'agent, les applications verticales, les propriétaires de flux de travail, et les produits d'évaluation et d'observabilité. Ils comprennent les coûts d'erreurs, peuvent observer les résultats et peuvent optimiser les stratégies de déclenchement. Ce qui est vraiment difficile à reproduire n'est pas la liste des panels, mais le jugement de quand ne pas invoquer la Fusion.

Validation du Marché

Le marché public est encore insuffisant pour évaluer l'échelle de la demande pour la Fusion, mais il est déjà évident comment elle est utilisée. Le Conseil des Modèles Perplexity n'est ouvert qu'aux utilisateurs Max et aux utilisateurs Enterprise Max à 200 $ par mois, permettant aux utilisateurs de sélectionner manuellement trois modèles pour la recherche d'investissement, la prise de décision complexe et la validation d'informations ; les cas d'utilisation publics incluent l'intégration du Conseil des Modèles dans les processus de recherche boursière via l'automatisation du navigateur. Hermes Mixture of Agents a transformé la Fusion en un modèle virtuel sélectionnable au sein des agents : les utilisateurs peuvent améliorer une seule question difficile via /moa ou l'activer continuellement dans des sessions complexes, avec plusieurs modèles de référence fournissant des analyses, suivies d'un agrégateur appelant des outils pour compléter les tâches. Hermes a ensuite réduit la fréquence par défaut de diffusion, réutilisant le tour précédent d'opinions de modèles pour contrôler les coûts. Ces cas illustrent que la véritable demande pour la Fusion est concentrée dans des tâches difficiles à faible fréquence telles que la recherche, le débogage, la révision et la prise de décisions importantes, avec une utilisation typique étant des mises à niveau proactives après que des modèles uniques atteignent des goulets d'étranglement, plutôt que des processus d'automatisation à haute fréquence par défaut. Les preuves existantes prouvent que cette demande existe, mais les informations publiques sont encore insuffisantes pour déterminer si elle peut former un marché payé indépendant et évolutif.

L'Avenir de la Fusion

La baisse des prix d'inférence bénéficie superficiellement à la Fusion, mais elle réduira également simultanément les coûts des modèles uniques puissants, du routage et de la validation externe. La Fusion ne concurrence pas l'appel de modèle d'hier, mais la génération suivante de modèles uniques et les bases d'orchestration en amélioration continue.

La Devin Fusion de Cognition illustre la direction de cette concurrence : garder des modèles coûteux pour les phases de jugement tout en assignant des tâches vérifiables et mécaniques à des modèles moins chers. Dans les auto-tests des fournisseurs, le score total de Fusion + Fable 5 a légèrement augmenté de 57.0 à 57.6, tandis que le coût moyen est tombé de 5,12 $ à 3,00 $ ; cependant, dans les cinq cas publiés, les coûts ont diminué de 25 % à 62 %, tandis que les scores des tâches ont fluctué entre +12 et -27. L'ES6 refactor clairement défini et soigneusement testé est passé de 98 à 100 points ; cependant, la fonctionnalité React/Redux, qui reposait sur une compréhension interactive et des besoins implicites, est tombée de 54 points à 27 points après avoir été incorrectement déléguée.

▲ Figure 6 : Scores de Tâches et Coûts de Devin Fusion

Ce sont des cas sélectionnés par des fournisseurs et ne représentent pas la distribution globale, mais ils indiquent clairement : la capacité centrale des futurs systèmes multi-modèles n'est pas d'appeler plus de modèles, mais de délimiter les bonnes frontières de dégradation. Les tâches vérifiables et mécaniques peuvent être assignées à des modèles moins chers, tandis que les tâches nécessitant un jugement intensif doivent être réservées aux modèles de pointe. OpenRouter vend "plus d'intelligence", tandis que Cognition vend "une intelligence équivalente à un coût inférieur" ; cette dernière proposition est plus proche de la direction à long terme. Plus un système est proche de l'économie de production, moins il ressemble à une Fusion de Modèles étroite et plus il ressemble à du routage, de la délégation et de la validation.

Fin juillet, des rapports médiatiques ont indiqué que Stripe négocie pour acquérir OpenRouter pour environ 10 milliards de dollars, bien que l'accord n'ait pas été confirmé. Ce signal ne doit pas être interprété comme une validation de marché de la Fusion : la valeur centrale d'OpenRouter n'est pas un panel spécifique, mais une couche d'appel neutre connectant plus de 5 millions de développeurs avec plus de 400 modèles. Stripe a déjà fourni la facturation, la fiscalité et le contrôle des risques pour OpenRouter, permettant aux développeurs de créer des comptes, d'obtenir des clés API et de connecter des paiements directement via Stripe Projects. Ce que Stripe est susceptible d'acheter, c'est l'entrée de transaction pour l'inférence IA : OpenRouter gère la sélection de modèles, l'utilisation de jetons et les coûts, tandis que Stripe s'occupe des prix, de la facturation et des paiements. Cela fournit un signal de marché pour le jugement de valeur mentionné précédemment : la valeur à l'ère multi-modèles est plus susceptible de rester avec ceux qui peuvent observer les tâches, allouer des appels et compléter des règlements dans la couche d'orchestration, tandis que la Fusion n'est qu'une stratégie de mise à niveau coûteuse par-dessus cela.

Les futurs systèmes multi-modèles ne se réuniront pas par défaut en panels mais estimeront d'abord la difficulté des tâches, les coûts de vérification et les pertes d'erreurs ; seulement lorsque des modèles uniques plus forts, une inférence prolongée et des outils externes sont encore insuffisants entreront-ils dans des recherches de divergence multi-modèles. Les taux de déclenchement, les taux de succès incrémentiels et les coûts de résultats unitaires vérifiés seront les métriques de produit significatives. La Fusion restera une fonctionnalité à faible fréquence plutôt que de devenir une architecture par défaut ou une catégorie indépendante.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.