Fugu (Sakana AI) : l’IA multi-agents bat les modèles géants

L'essor des LLM open source : vers une intelligence artificielle plus démocratique et durable

Sakana AI a présenté Fugu, une famille d’orchestrateurs de modèles qui remet en débat un des sujets les plus chargés de l’IA moderne : la progression des performances viendra-t-elle de l’entraînement de modèles monolithiques toujours plus grands, ou de la coordination de plusieurs modèles spécialisés via des systèmes multi-agents ?

Ce concept n’est pas nouveau pour les équipes techniques familières avec LangGraph, CrewAI, AutoGen, MCP, les agents de code ou les flux RAG. Ce qui est remarquable, c’est que Sakana AI en a fait un rapport technique avec des résultats mesurables. Fugu-Ultra, sa version axée sur la qualité maximale, atteint 73,7 % sur SWE-Bench Pro, contre 69,2 % pour Claude Opus 4.8 dans le même rapport. Sur Terminal Bench 2.1, elle réalise 82,1 %, contre 78,2 % pour GPT-5.5 et 74,6 % pour Opus 4.8.

Le message est clair : Fugu n’est pas « un autre LLM ». C’est un modèle entraîné pour décider quel agent doit intervenir, comment diviser une tâche, quelles réponses doivent être vérifiées et quand synthétiser une réponse finale. L’IA commence à ressembler moins à un seul cerveau massif, et plus à un système distribué de spécialistes.

Un orchestrateur à la frontière des modèles

Le rapport de Sakana AI définit Fugu comme une famille d’orchestrateurs exploitant et amplifiant les capacités d’une équipe d’agents LLM. L’utilisateur interagit comme s’il s’agissait d’un seul modèle, mais le système peut router, déléguer et coordonner des tâches entre plusieurs modèles. Dans sa version initiale, le pool comprend Claude Opus 4.8, GPT-5.5 et Gemini 3.1 Pro.

Deux variantes principales existent. Fugu est conçue pour une utilisation interactive à faible latence : elle sélectionne un seul agent pour chaque tâche, avec une réponse quasi immédiate comparable à un appel direct à un modèle frontière. Fugu-Ultra privilégie la qualité : elle crée des flux avec plusieurs agents pour chaque tâche, en acceptant une latence supérieure et une complexité accrue.

SystèmeApprocheAvantage principalCoûts opérationnels
FuguRoutage vers un seul agentFaible latence et sélection dynamique du meilleur agentSimilaire à un appel direct, avec surcharge d’orchestration
Fugu-UltraFlux multi-agent à plusieurs étapesQualité supérieure pour des tâches complexesPlus d’appels, plus de latence, coûts plus élevés
Modèle monolithiqueUn seul modèle répondant à toutSimplicité d’utilisation et déploiementPeut être coûteux ou moins adapté aux tâches spécifiques
Multi-agents manuelFlux conçus par le développeurContrôle précis du processusPlus d’ingénierie, maintenance accrue, risque de points de défaillance

L’aspect technique mérite attention. Fugu ne se limite pas à une simple majorité de votes entre modèles ou à l’envoi de la même question à plusieurs systèmes. Dans sa version à faible latence, elle utilise un module de sélection léger basé sur l’état interne du système pour choisir l’agent le plus approprié. Avec Fugu-Ultra, le système génère des flux de travail en langage naturel : il divise la tâche, attribue des sous-tâches, détermine quels agents peuvent voir quelles réponses antérieures, et décide comment synthétiser le résultat final.

Les benchmarks : ce que les chiffres disent vraiment

Les résultats publiés sont significatifs, mais doivent être interprétés avec contexte. Sakana AI compare Fugu et Fugu-Ultra à des modèles de pointe via SWE-Bench Pro, Terminal Bench 2.1, LiveCodeBench Pro, GPQA Diamond, CharXiv Reasoning et Humanity’s Last Exam. Dans plusieurs cas, Fugu-Ultra dépasse les modèles individuels qu’elle utilise comme agents.

BenchmarkFugu-UltraFuguClaude Opus 4.8Gemini 3.1GPT-5.5
SWE-Bench Pro73,759,069,254,258,6
Terminal Bench 2.182,180,274,670,378,2
LiveCodeBench Pro90,887,884,882,988,4
GPQA Diamond95,595,592,094,393,6
CharXiv Reasoning86,685,184,283,384,1
Humanity’s Last Exam50,047,249,844,441,4

Ce qui compte ici, ce n’est pas qu’« un petit orchestrateur japonais » ait dépassé Claude ou GPT. C’est que Fugu-Ultra y parvient précisément parce qu’elle utilise ces modèles puissants comme composants d’un système supérieur. La progression vient de la coordination : choisir le spécialiste adapté, alterner les modèles au cours d’une tâche, utiliser la validation croisée quand nécessaire.

En programmation, Fugu peut appeler GPT-5.5 pour construire, puis Claude Opus 4.8 lors des phases critiques de débogage. En sciences, elle peut s’appuyer davantage sur Gemini pour le savoir spécialisé et sur GPT pour les calculs mathématiques. Cette adaptation par domaine représente une voie différente pour faire évoluer l’IA.

Ce que cela révèle sur les modèles fermés

Le succès de Fugu soulève une question difficile : dans quelle mesure la performance des grands modèles fermés provient-elle du modèle de base ou de la couche systèmique qui l’entoure ?

Il n’existe pas de preuve publique indiquant que Claude, GPT-5.5 ou d’autres modèles fermés fonctionnent exactement comme Fugu en interne. Mais il est raisonnable de penser que les systèmes de pointe ne se résument pas à de simples appels à un modèle brut. Dans des produits comme Claude Code, Codex ou les agents avancés en production, la performance dépend aussi d’outils, de mémoire, d’exécution de commandes, de récupération de contexte, de validateurs, de prompts internes et de boucles de rétroaction.

Fugu met en lumière une architecture que beaucoup d’entreprises pressentaient : la capacité pratique d’un LLM ne se limite pas à ses seuls poids. Elle dépend aussi du système dans lequel il s’insère — ce que Sakana AI appelle les « agents scaffolds », des structures qui transforment un modèle autorégressif en un agent capable de planifier, d’utiliser des outils, de vérifier son travail et d’exploiter les signaux de l’environnement.

Ce que cela implique pour le marché de l’IA

Fugu trace une voie concrète pour le secteur : la performance ne dépend plus uniquement de l’entraînement de modèles plus grands. Elle peut venir d’une meilleure composition des capacités existantes. Les implications techniques, économiques et stratégiques sont réelles.

Modularité : un système peut intégrer de nouveaux modèles dès leur apparition, exclure certains pour des raisons de confidentialité ou de conformité, privilégier des modèles locaux pour des données sensibles, ou utiliser des modèles premium uniquement quand la tâche le justifie. L’orchestration ouvre la possibilité de configurer des pools d’agents selon les contraintes d’utilisateur, de fournisseur ou de conformité.

Coût et latence : si une tâche simple peut être réalisée par un modèle moins cher, il n’a pas de sens d’appeler systématiquement le modèle le plus coûteux. Cette sélection dynamique devient d’autant plus stratégique que la consommation énergétique des systèmes IA explose : les racks NVIDIA Rubin Ultra atteignent déjà 660 kW chacun.

Accessibilité : entraîner un modèle de pointe exige des ressources considérables. Concevoir une bonne couche d’orchestration est difficile aussi, mais plus accessible pour les entreprises disposant déjà de plusieurs modèles, d’outils internes et de données propres. Toutes ne pourront pas réaliser un Fugu-Ultra, mais beaucoup peuvent s’inspirer de cette logique pour leurs systèmes en production.

Complexité : les systèmes multi-agents ne sont pas une solution magique. Ils introduisent de la latence, un coût en tokens, des défis de traçabilité, la gestion des erreurs, des contradictions entre agents et une dépendance à plusieurs fournisseurs. Un mauvais orchestrateur peut détériorer le résultat. Fugu se concentre précisément sur la formation de cette coordination, pas sur l’assemblage aléatoire d’agents.

La compétition entre modèle monolithique et ensemble d’agents ne produira pas une réponse unique. Certaines tâches resteront parfaitement adaptées à un seul modèle puissant. D’autres bénéficieront d’une orchestration de spécialistes. Dans les domaines du logiciel, de la science, de la recherche, de la sécurité ou des analyses longues intégrant outils et APIs, la seconde approche s’impose progressivement — un phénomène que l’on voit aussi dans la course aux infrastructures IA, où Qualcomm mise sur des CPU spécialisés pour les data centers IA de Meta plutôt que sur des GPU généralistes.

Sakana AI n’a pas démontré que les grands modèles fermés sont devenus obsolètes. Elle a montré quelque chose de plus intéressant : l’unité de compétition n’est plus forcément le « modèle » individuel. La nouvelle unité pourrait bien être le système dans son ensemble, où l’orchestration, la mémoire, les rôles, les outils et la vérification comptent autant que la taille du LLM.

FAQ

Qu’est-ce que Fugu de Sakana AI ?

Fugu est une famille de modèles orchestrateurs qui coordonnent plusieurs LLM de pointe pour résoudre des tâches. L’utilisateur interagit avec un seul système, mais Fugu choisit, combine et vérifie les réponses de différents agents selon la nature de la tâche.

Fugu-Ultra dépasse-t-elle réellement Claude Opus 4.8 ?

Sur certains benchmarks du rapport Sakana AI, oui : 73,7 % contre 69,2 % sur SWE-Bench Pro, et 82,1 % contre 74,6 % sur Terminal Bench 2.1. Ces résultats reposent sur une architecture multi-agent orchestrée, pas sur un seul modèle autonome.

Fugu utilise-t-elle les dernières versions fermées de Claude ?

Non. Le rapport précise que Fable 5 et Mythos Preview ne font pas partie du pool d’agents de Fugu, car ils ne sont pas accessibles publiquement. Les agents utilisés sont Claude Opus 4.8, GPT-5.5 et Gemini 3.1 Pro.

Quelles implications pour les entreprises utilisant l’IA en production ?

Elles peuvent améliorer leurs résultats en combinant modèles spécialisés, outils, validateurs et routeurs, plutôt qu’en s’appuyant uniquement sur un modèle premium unique. La clé est une architecture bien conçue et une mesure précise du rendement, des coûts et de la latence.

Pourquoi l’orchestration multi-agents est-elle plus difficile qu’un simple appel de modèle ?

Elle introduit de la latence, un coût en tokens plus élevé, des défis de traçabilité, la gestion des échecs entre agents et une dépendance à plusieurs fournisseurs. Un orchestrateur mal conçu peut détériorer les résultats plutôt que les améliorer.

Source : Sakana AI, Rapport Technique Fugu, arXiv:2606.21228v1

le dernier