Sakana AI a lancé le 11 septembre Fugu Max et Fugu Ultra v2, deux nouvelles variantes de son système d’orchestration de modèles. L’API reste compatible avec l’interface d’OpenAI, mais la requête peut être répartie entre plusieurs modèles en arrière-plan. Max vise surtout un meilleur rapport coût-performance, tandis qu’Ultra v2 privilégie la qualité sur les tâches complexes.
Pour les équipes d’ingénierie, le changement le plus intéressant n’est pas le classement dans quelques benchmarks. Sakana transforme le choix du modèle en une fonction gérée par sa propre couche d’orchestration. Cela peut alléger le code de routage côté application, mais cela déplace aussi une partie du contrôle vers le fournisseur de l’orchestrateur.
Un tarif fixe pour un routage qui reste dynamique
Fugu Max est facturé 2 dollars par million de jetons en entrée, 6 dollars en sortie et 0,25 dollar pour les entrées servies depuis le cache. Sakana indique avoir élargi le groupe de modèles disponibles, avec davantage de modèles ouverts et spécialisés, notamment des modèles de la famille Nemotron de NVIDIA.
Dans ses propres évaluations, l’entreprise affirme que Max obtient le meilleur score global sur six benchmarks et améliore la frontière coût-performance dans sept cas sur dix. Il s’agit de mesures publiées par Sakana, pas d’une validation indépendante. L’un des benchmarks, SWEFish, reflète en outre des tâches de programmation internes à l’entreprise.
Le modèle économique est plus instructif pour une équipe qui exploite déjà plusieurs fournisseurs. Au lieu de recalculer le coût de chaque choix effectué par son propre routeur, elle peut traiter Fugu Max comme un service à tarif fixe. L’intégration devient plus simple, mais les décisions qui expliquent ce coût deviennent moins visibles.
Ultra v2 vise les tâches les plus exigeantes
Fugu Ultra v2 coûte 5 dollars par million de jetons en entrée et 30 dollars en sortie. Les tarifs augmentent lorsque le contexte dépasse 272 000 jetons. Sakana annonce un score de 48,3 sur Chartography et de 74,3 sur DeepSWE, ainsi que de meilleurs résultats que plusieurs modèles de référence sur certains tests. Là encore, ces chiffres doivent rester attribués au fournisseur.
Fugu n’est pas un modèle unique au sens classique. Le système comprend un modèle coordinateur qui décide quels autres modèles solliciter et comment organiser leur coopération. Le rapport technique décrit un entraînement combinant notamment ajustement du modèle, optimisation évolutionnaire et apprentissage par renforcement.
Cela change la notion même de version en production. Une application peut appeler fugu-max-v1.0 ou fugu-ultra-v2.0, mais le comportement observé dépend aussi du coordinateur et du groupe de modèles disponibles derrière cette référence. Sakana prévoit d’ailleurs de réentraîner et d’évaluer Fugu lorsque de nouveaux modèles de pointe deviennent accessibles.
Le verrouillage fournisseur ne disparaît pas, il se déplace
L’analyse d’Aipolix est que Fugu réduit la dépendance directe à un modèle unique sans supprimer la dépendance à un fournisseur. L’application dépend désormais de la politique de routage de Sakana, de la composition du groupe de modèles, de ses règles tarifaires et de son processus de mise à jour.
Pour la gouvernance des données, ce déplacement est important. Une entreprise qui doit savoir quel fournisseur peut recevoir une requête, où elle peut être traitée ou quels modèles sont autorisés ne résout pas ces questions en passant par une seule URL d’API. Elle risque au contraire d’en perdre une partie de la visibilité. La version standard de Fugu permet d’exclure certains agents pour des raisons de confidentialité ou de conformité, tandis que la documentation de Fugu Ultra décrit un groupe de modèles fixe destiné à préserver ses performances.
La reproductibilité mérite la même attention. Si le coordinateur ou les modèles sous-jacents évoluent, une exécution future peut ne plus correspondre exactement à celle qui a été évaluée auparavant. Pour un déploiement contrôlé, la configuration d’orchestration doit donc être considérée comme une partie de l’identité du système.
Le produit reste indisponible dans l’Union européenne
Sakana précise que Fugu n’est pas encore proposé dans l’Union européenne ni dans l’Espace économique européen, le temps de traiter les exigences liées au RGPD et aux réglementations régionales. Cette restriction concerne directement les développeurs et les entreprises au Portugal.
Ce n’est pas un détail secondaire. Un service capable d’acheminer une requête vers plusieurs modèles doit apporter des réponses précises sur le lieu de traitement, les fournisseurs impliqués et les règles de circulation des données. Pour une organisation portugaise, la question la plus importante n’est donc pas uniquement le prix annoncé. Elle est aussi de savoir quels contrôles et quelle transparence seront disponibles lorsque le service arrivera sur le marché européen.
Ce qu’une équipe devrait vérifier avant adoption
Fugu Max rend une architecture multimodèle plus simple à consommer et cela constitue un avantage concret. Mais l’évaluation doit porter sur l’ensemble de l’orchestrateur : modèles autorisés à recevoir les données, versionnement du groupe, visibilité des décisions de routage, comptabilisation des coûts et comportement lorsqu’un fournisseur disparaît du groupe.
Sakana livre une API utilisable et documente les principes techniques de Fugu. Le produit dépasse donc le stade de la démonstration conceptuelle. Le point à surveiller est désormais la maturité des contrôles opérationnels et de conformité autour de cette orchestration, en particulier lorsque la composition des modèles évolue.