Fugu Ultra : comment un modèle d’orchestrateur IA défie GPT et Claude

Ce qui compte ici, ce n’est pas le score sur un classement. C’est la réflexion qui sous-tend la manière dont ce score a été obtenu.

En suivant les lancements de modèles d’IA au cours de la dernière année, on commence à remarquer un schéma récurrent.

Plus de paramètres.

Des fenêtres de contexte plus grandes.

Quelques points supplémentaires dans les benchmarks.

Des tokens moins chers.

Encore un « modèle le plus performant à ce jour ».

Puis, le 11 septembre, Sakana AI a présenté Fugu Ultra v2.0, et quelque chose dans cette annonce en particulier a brisé ce schéma.

Ce n’étaient pas les scores des benchmarks eux-mêmes qui se distinguaient.

C’est le mécanisme permettant d’obtenir ces scores qui a attiré l’attention.

Fugu Ultra ne vise pas à être le modèle d’IA le plus intelligent du monde.

Au lieu de cela, il aborde une question complètement différente :

Et si la configuration d’IA la plus puissante n’était pas un seul modèle, mais un système suffisamment intelligent pour savoir quel modèle doit gérer quelle partie d’un problème ?

Cette question pourrait avoir plus d’importance à long terme que n’importe quelle victoire sur un benchmark.

Alors, qu’est-ce que Fugu Ultra exactement ?

C’est là le premier détail qui distingue Fugu des autres.

Fugu Ultra ne fonctionne pas comme un modèle standard de type GPT ou Claude.

Sakana le présente plutôt comme un contrôleur, ou couche d’orchestration.

Imaginez-le comme un manager d’ingénierie compétent supervisant une équipe.

Vous lui soumettez une demande complexe.

Au lieu d’essayer de gérer lui-même chaque partie de cette demande, le contrôleur peut :

1. Décoder ce qui est demandé
2. Séparer la demande en sous-tâches plus petites

Déterminer quel modèle spécialisé convient à chaque sous-tâche

Transférer le travail en conséquence

Fusionner les résultats

Ajouter sa propre réflexion si nécessaire

Supposons que vous soumettiez une demande telle que :

"Examinez le rapport financier de cette entreprise, créez un graphique, mettez en évidence toute anomalie et résumez les conclusions."

Un modèle conventionnel tenterait de traiter toute la demande en utilisant un seul ensemble de compétences.

Un système orchestré aborde la même demande comme un projet confié à une équipe :

Analyse du document → un modèle spécialisé Interprétation des données → un autre spécialiste Réflexion sur le graphique → un spécialiste axé sur la vision ou les données Rédaction du code → un spécialiste en programmation Intégration de tout cela → le contrôleur

D’un point de vue utilisateur, cela ressemble toujours à une seule appel API.

Cependant, en coulisses, vous interagissez en réalité avec une liste de modèles d’IA coordonnés par un autre système d’IA.

On rapporte que la base de modèles de Sakana combine des modèles open-source avec des modèles spécialisés, parmi lesquels la gamme Nemotron d’NVIDIA.

C’est là que les choses deviennent vraiment intéressantes.

Les chiffres des benchmarks

D’après les données fournies par Sakana elle-même, Fugu Ultra v2.0 a obtenu de bons résultats dans plusieurs catégories de benchmarks.

L’entreprise affirme que Fugu a été le meilleur ou l’un des meilleurs sur 5 des 8 benchmarks, et s’est classé parmi les deux meilleurs sur 7 des 8.

Un chiffre qui se distingue immédiatement est DeepSWE : 74,3.

DeepSWE mérite une attention particulière car il évalue les compétences en ingénierie logicielle plutôt que de tester simplement des énigmes de codage.

Fugu a également affiché de bons résultats sur Chartography, SWEFish, GDP.pdf et Toolathon.

Fugu Ultra v2 face aux autres modèles Frontier

D’après les comparaisons rapportées, Fugu Ultra v2 a surpassé plusieurs systèmes bien connus, parmi lesquels :

• Claude Opus 4.8
• GPT-5.5
• Gemini 3.1 Pro

On prétend également qu’il excelle particulièrement en Chartography, un benchmark basé sur l’interprétation de graphiques et d’autres données visuelles structurées.

Voici la précision importante :

Ces chiffres ont été communiqués par Sakana au sujet de son propre système.

Jusqu’aux données rapportées ici, aucun laboratoire indépendant n’a reproduit ces résultats.

Cette distinction est importante.

Un benchmark publié par l’entreprise qui a développé le modèle peut sembler impressionnant, mais il nécessite encore une vérification externe avant d’être pleinement fiable.

La manière équitable de traiter ces résultats est donc la suivante :

Vraiment intéressant. Vaut la peine d’approfondir l’étude. Aucune conclusion définitive pour le moment.

La situation générale

On pourrait dire que le chiffre le plus révélateur ici n’est pas un score isolé, mais bien le taux de 5 sur 8.

Pourquoi est-ce plus important ?

Parce que remporter un benchmark spécifique signifie souvent simplement que le modèle a été ajusté pour cette tâche en particulier.

Se classer parmi les meilleurs sur différents types de tâches constitue un indicateur bien plus significatif.

Néanmoins, il convient de le répéter : il s’agit de résultats auto-déclarés, et non confirmés indépendamment.

Une comparaison plus intéressante : la façon dont ces systèmes pensent

La véritable différence ici réside probablement non pas dans le score lui-même, mais dans l’architecture sous-jacente.

Modèle traditionnel de frontière

User
  ↓
One large model
  ↓
Answer

GPT, Claude et Gemini suivent tous dans une large mesure cette conception, bien que leurs produits actuels intègrent de plus en plus leur propre logique de routage, d’utilisation d’outils et de comportement similaire à celui d’un agent.

Approche de Fugu

┌── Coding specialist
                 │
User → Controller├── Vision specialist
                 │
                 ├── Reasoning specialist
                 │
                 └── Other models
                         ↓
                    Final answer

Cela redéfinit entièrement le défi d’optimisation.

Au lieu de se demander :

"Comment pouvons-nous créer un seul modèle qui soit meilleur dans tout ?"

Sakana se demande essentiellement :

"Comment pouvons-nous devenir plus doués pour choisir le bon modèle pour chaque problème spécifique ?"

C’est un pari fondamentalement différent à tenter.

Fugu vs Claude vs GPT vs Gemini vs DeepSeek

Alors, comment Fugu se compare-t-il aux systèmes que l’on considère généralement lors du choix d’un fournisseur d’IA ?

Claude

Claude reste l’un des choix privilégiés pour les tâches exigeant du raisonnement, de la programmation ou une rédaction longue.

Sa principale force réside dans le fait qu’on dispose d’un modèle polyvalent et très performant dès la sortie d’usine.

Il n’est pas nécessaire de s’occuper soi-même de coordonner plusieurs modèles.

Fugu adopte une approche inverse : l’orchestration elle-même constitue le produit.

GPT

OpenAI s’est principalement concentré sur l’amélioration des capacités des modèles polyvalents, en y ajoutant progressivement des outils et des fonctionnalités d’agent.

La philosophie de Fugu va presque dans la direction opposée :

Au lieu de forcer un seul modèle à gérer tout le travail,

elle crée un système conçu pour coordonner plusieurs modèles en même temps.

Cette différence devient de plus en plus importante à mesure que le nombre de modèles disponibles continue d’augmenter.

Gemini

Gemini excelle lorsque les entrées multimodales, des fenêtres de contexte très larges ou l’intégration avec l’écosystème plus vaste de Google sont des priorités.

Ce qui distingue Fugu, ce n’est ni le support multimodal ni la longueur du contexte en eux-mêmes.

C’est la couche de routage qui se situe au-dessus de plusieurs modèles sous-jacents.

DeepSeek

DeepSeek propose un autre angle méritant d’être pris en considération.

Son attrait pour de nombreux développeurs réside dans quelque chose de simple :

des performances solides à un prix compétitif.

Fugu vise un objectif complètement différent.

Au lieu de se demander :

"Quel est le modèle le moins cher capable de gérer cela ?"

son contrôleur se demande plutôt :

"Quel modèle convient le mieux à cette tâche spécifique ?"

Ce sont deux problèmes d’optimisation distincts.

Puis il y a la tarification

C’est là que les choses deviennent encore plus intéressantes.

Sakana a apparemment divisé Fugu en deux niveaux de tarification.

Fugu Max

Entrée : 2 dollars par million de tokens

Sortie : 6 dollars par million de tokens

D’après les chiffres indiqués, ce tarif est d’environ 40 à 60 pour cent moins cher que plusieurs modèles concurrents mentionnés dans la publication.

Fugu Ultra v2

Entrée : 5 dollars par million de tokens

Sortie : 30 dollars par million de tokens

Pour les requêtes dépassant 272 000 tokens de contexte, les tarifs indiqués montent à :

Entrée : 10 dollars par million de tokens

Sortie : 45 dollars par million de tokens.

On dit également que le niveau Ultra comprend une fenêtre de contexte de 1 million de tokens, ainsi qu’un coupure des connaissances au mois d’août 2026.

Comparaison des prix

Les chiffres ci-dessus (calculés par million de tokens) proviennent du matériel source ; vous devez les vérifier contre les prix actuellement affichés par chaque fournisseur avant de prendre toute décision d’achat.

Mais il y a un piège

C’est sans doute le point le plus intéressant dans toute l’histoire de Fugu.

L’orchestration n’est pas gratuite.

Chaque fois que le système doit :

• décomposer une tâche en plusieurs parties
• affecter ces parties à des destinataires appropriés
• appeler un autre modèle
• attendre la réponse de ce modèle
• vérifier la qualité du résultat
• reconstituer tout le processus

cela entraîne des coûts supplémentaires.

Ces coûts supplémentaires peuvent se manifester sous forme de latence accrue.

Considérez une demande comme celle-ci :

« Écrivez-moi un tweet sur le café. »

Vous n’avez presque certainement pas besoin d’une couche de coordination gérant plusieurs modèles spécialisés pour quelque chose d’aussi simple.

Ce serait comme faire appel à toute une firme de conseil pour resserrer un robinet qui fuit.

Comparez cela maintenant à une demande bien plus complexe, comme celle de fournir un long document technique, de faire en sorte que le système examine la base de code associée, identifie les défauts de conception, évalue plusieurs solutions possibles et produise ensuite un plan concret pour mettre en œuvre l’approche la plus efficace.

Ici, disposer d’une couche d’orchestration devient vraiment utile.

Le problème caché : la boîte noire

Il existe un deuxième problème qui peut même être plus important que la vitesse.

Généralement, vous n’avez aucune visibilité sur le modèle sous-jacent qui a réellement traité chaque partie de votre demande.

Pour une utilisation quotidienne par les particuliers, cela ne pose pas de gros problème.

Pour un usage en entreprise, cela peut représenter un véritable obstacle.

Pensez aux organisations qui gèrent :

• du code source confidentiel
• des documents financiers
• des informations sur les clients
• des documents propriétaires
• des données soumises à des réglementations

Si la couche de routage choisit en silence différents modèles en arrière-plan, les entreprises souhaiteront légitimement des réponses à des questions telles que :

Quel modèle a réellement traité mes données ? Où ont-elles été traitées ? Qu’a exactement été envoyé à chaque modèle ? La décision de routage est-elle auditable ? Est-il possible d’attribuer des charges de travail spécifiques uniquement à des modèles approuvés ?

Ces préoccupations ne sont pas hypothétiques.

Dans les environnements d’entreprise, la capacité à observer et à gérer le système peut être tout aussi importante que l’intelligence brute du modèle.

Toute plateforme d’orchestration qui souhaite être considérée comme une infrastructure fondamentale, et non simplement un autre wrapper API, devra finir par combler ces lacunes en matière de gouvernance.

Pourquoi cela pourrait être plus important qu’un simple lancement de modèle

C’est là l’idée qui reste particulièrement marquante.

Supposons qu’un concurrent lance le mois prochain un modèle de codage nettement supérieur.

Un fournisseur de modèles traditionnel devrait réentraîner le modèle, l’évaluer et publier une nouvelle version complète.

En revanche, un système basé sur l’orchestration pourrait simplement intégrer ce nouveau modèle à son ensemble existant d’options.

Le responsable de la gestion dispose ainsi d’un spécialiste supplémentaire à qui s’adresser.

C’est un avantage significatif.

La structure qui en résulte ressemble à ceci :

AI Model A
                  │
              AI Model B
                  │
User → Controller → AI Model C
                  │
              AI Model D
                  │
              AI Model E

Sous ce modèle, la capacité de l’ensemble du système peut augmenter simplement parce que l’écosystème des modèles qui l’entoure continue d’évoluer.

Le contrôleur lui-même n’a pas nécessairement besoin de devenir drastiquement plus intelligent à chaque itération.

Ce dont il a besoin, c’est de devenir de plus en plus compétent pour prendre des décisions.

Cette évolution des priorités pourrait représenter une direction importante pour l’avenir de l’IA agente.

La course à l’IA pourrait être en train de changer

Pendant longtemps, le schéma derrière les progrès de l’IA était assez prévisible : rendre le modèle plus grand, lui fournir davantage de données d’entraînement, améliorer ses capacités de raisonnement, y consacrer plus de ressources informatiques, et répéter ce cycle. Cette formule commence à sembler insuffisante.

Génération 1

Un seul modèle gérant toutes les tâches par lui-même.

Génération 2

Un seul modèle associé à des outils externes.

Génération 3

Un agent qui coordonne plusieurs outils et plusieurs modèles.

Génération 4 ?

Un système qui assemble en temps réel une équipe personnalisée de modèles, adaptée au problème qu’il doit résoudre.

Cette dernière étape semble être exactement ce que vise Fugu.

Si cette stratégie fonctionne, le produit d’IA le plus précieux à l’avenir ne sera pas nécessairement celui doté des meilleurs scores de raisonnement. Il pourrait plutôt s’agir d’un système suffisamment intelligent pour reconnaître quand un modèle particulier ne doit absolument pas être utilisé.

Faut-il vraiment utiliser Fugu ?

Voici une analyse pratique.

Pour des tâches simples en style API

Mieux vaut l’éviter.

Si votre cas d’usage implique des choses comme :

• une synthèse courte
• des tâches de classification simples
• une génération de contenu routinière
• des questions factuelles rapides

Alors, cette couche de coordination supplémentaire n’est probablement pas à la hauteur de la complexité qu’elle ajoute.

Pour des systèmes d’agents sophistiqués

C’est là que les choses deviennent intéressantes.

En particulier pour des tâches impliquant :

• le développement logiciel
• des missions de recherche
• l’analyse de documents volumineux
• des pipelines gourmands en données
• des chaînes de raisonnement à plusieurs étapes
• le comportement d’agents autonomes
• des problèmes nécessitant plusieurs types d’expertise distincts

C’est précisément dans ce domaine que le routage entre modèles commence à se révéler utile.

Conclusions

Il serait prématuré de proclamer Fugu Ultra comme le successeur définitif de GPT ou Claude. Les résultats des benchmarks semblent solides, mais ils proviennent pour l’instant du fournisseur lui-même, et une vérification indépendante reste nécessaire avant de tirer des conclusions définitives.

Cela dit, qualifier cela de simple ajout aux guerres des benchmarks reviendrait à manquer le point essentiel. L’histoire réelle ici est d’ordre architectural, et non numérique.

OpenAI, Anthropic et Google ont investi d’énormes ressources pour rendre leurs modèles individuels aussi performants que possible. Sakana semble tester une hypothèse différente :

Peut-être que l’objectif n’est pas de créer un modèle parfait, mais plutôt un excellent coordinateur pour un ensemble de modèles imparfaits.

C’est un petit changement conceptuel, mais pas anodin. S’il s’avère valide, il pourrait redéfinir la manière dont les applications d’IA seront développées à l’avenir.

Le système d’IA qui finit par gagner n’est pas nécessairement celui qui affiche le plus grand nombre de paramètres, la plus grande fenêtre de contexte ou la meilleure note sur n’importe quelle liste de classement. Il peut simplement s’agir de celui qui est capable d’examiner une tâche et de conclure : ce modèle en particulier est le plus adapté à ce travail spécifique.

C’est cette partie de Fugu Ultra v2.0 qui mérite d’être prise en compte, et non le tableau de classement.