Fugu Ultra: Wie ein KI-Orchestrationsmodell GPT und Claude in Frage stellt
Erklärt, wie Sakana AI’s Fugu Ultra v2 Aufgaben über spezialisierte Modelle statt über ein einziges großes LLM verteilt, und wie es sich in Bezug auf Benchmarks, Preise und Transparenz schneidet.
Quellen: This AI Model Beats GPT-6 and Claude Opus 5 — Without Even Using Them
Was hier zählt, ist nicht die Punktzahl in einer Leaderboard-Liste. Es geht um den Denkprozess hinter der Erzielung dieser Punktzahl.
Wenn man den Veröffentlichungen von KI-Modellen im letzten Jahr folgt, fällt einem allmählich ein Muster auf.
Mehr Parameter.
Großere Kontextfenster.
Ein paar zusätzliche Benchmark-Punkte.
Günstigere Tokens.
Noch ein „bislang leistungsstärkstes Modell“.
Dann präsentierte Sakana AI am 11. September Fugu Ultra v2.0, und etwas an dieser speziellen Ankündigung durchbrach dieses Muster.
Nicht die Benchmark-Punktzahlen an sich fielen auf.
Bemerkenswert war vielmehr der Mechanismus, der diese Punktzahlen erzeugt.
Fugu Ultra strebt nicht danach, das intelligenteste KI-Modell der Welt zu sein.
Stattdessen verfolgt es eine völlig andere Frage:
Was, wenn die leistungsstärkste KI-Lösung nicht ein einzelnes Modell ist, sondern ein System, das intelligent genug ist, um zu wissen, welches Modell welche Aufgabe eines Problems übernehmen sollte?
Diese Frage könnte langfristig wichtiger sein als jeder einzelne Benchmark-Sieg.
Was ist also genau Fugu Ultra?
Das ist bereits der erste Unterschied, der Fugu von anderen Modellen abhebt.
Fugu Ultra funktioniert nicht wie ein herkömmliches Modell im Stil von GPT oder Claude.
Sakana beschreibt es stattdessen als Kontroller oder Orchestrierungsschicht.
Stellen Sie sich einen erfahrenen Projektmanager vor, der ein Team leitet.
Sie übergeben ihm eine komplexe Anfrage.
Anstatt selbst jede Komponente dieser Anfrage zu bearbeiten, kann der Kontroller:
- Das Gewünschte analysieren
- Die Anfrage in kleinere Teilaufgaben aufteilen
Nehmen wir an, Sie senden eine Anfrage wie folgt:
">Prüfen Sie den Finanzbericht dieses Unternehmens, erstellen Sie einen Diagramm, kennzeichnen Sie alle Anomalien und fassen Sie die Erkenntnisse zusammen."
Ein herkömmliches Modell würde versuchen, die gesamte Anfrage mit einem einheitlichen Satz an Fähigkeiten zu bearbeiten.
Ein orchestriertes System behandelt dieselbe Anfrage eher wie ein Projekt, das einem Team übertragen wird:
Dokumentanalyse → ein spezialisiertes Modell Dateninterpretation → ein anderes Spezialmodell Analyse des Diagramms → ein auf Visionen oder Daten fokussiertes Spezialmodell Codeverfassung → ein Codingspezialist Zusammenführung aller Komponenten → der Controller
Von Ihrer Seite aus sieht es weiterhin wie ein einziger API-Aufruf aus.
Hinter den Kulissen interagiert man jedoch tatsächlich mit einer Liste von KI-Modellen, die von einem anderen KI-System koordiniert werden.
Laut Berichten kombiniert Sakanas Modellpool offene Modelle mit spezialisierten Modellen, darunter NVIDIAs Nemotron-Reihe.
Dort wird es wirklich interessant.
Die Benchmark-Zahlen
Basierend auf Sakanas eigenen Angaben erzielte Fugu Ultra v2.0 starke Ergebnisse in mehreren Benchmark-Kategorien.
Das Unternehmen gibt an, dass Fugu in 5 von 8 Benchmarks den ersten Platz belegte oder gleichauf lag und In den Top 2 in 7 von 8 Benchmarks war.
Eine Zahl, die sofort ins Auge fällt, ist DeepSWE: 74,3.
DeepSWE verdient Aufmerksamkeit, da es die Fähigkeiten im Softwareengineering misst anstatt einfache Programmieraufgaben zu testen.
Fugu zeigte auch starke Ergebnisse in Chartography, SWEFish, GDP.pdf und Toolathon.
Fugu Ultra v2 im Vergleich zu anderen Frontier-Modellen
Laut den veröffentlichten Vergleichen übertraf Fugu Ultra v2 mehrere bekannte Systeme, darunter:
- Claude Opus 4.8
- GPT-5.5
- Gemini 3.1 Pro
Es wird außerdem behauptet, dass es besonders in Chartography hervorragt – einem Benchmark, der auf der Interpretation von Diagrammen und anderen strukturierten visuellen Daten basiert.
Hier ist die wichtige Einschränkung:
Es handelt sich um Zahlen, die Sakana über sein eigenes System berichtet hat.
Bis zum Zeitpunkt der hier dargestellten Berichterstattung hat kein unabhängiges Labor diese Werte nachgeprüft.
Dieser Unterschied ist wichtig.
Ein von dem Unternehmen, das das Modell entwickelt hat, veröffentlichter Benchmark mag beeindruckend erscheinen, benötigt aber trotzdem eine externe Überprüfung, bevor er vollständig vertrauenswürdig ist.
Die angemessene Art und Weise, mit diesen Ergebnissen umzugehen, ist daher:
Wirklich interessant. Es lohnt sich, tiefer nachzuforschen. Noch keine endgültige Schlussfolgerung.
Das Benchmark-Bild
Möglicherweise ist die aussagekräftigste Zahl hier nicht ein einzelner Wert, sondern die Zahl 5 von 8.
Warum ist das wichtiger?
Weil der Sieg in einem bestimmten Benchmark oft nur bedeutet, dass ein Modell für diese spezielle Aufgabe abgestimmt wurde.
Es ist ein aussagekräftigeres Zeichen, wenn man in einer Vielzahl unterschiedlicher Aufgabentypen ganz oben liegt.
Trotzdem sei nochmals betont: Es handelt sich um eigene Angaben der Hersteller, keine unabhängig bestätigten Ergebnisse.
Der interessantere Vergleich: Wie diese Systeme denken
Der eigentliche Unterschied liegt hier wahrscheinlich nicht im Wert selbst.
Sondern in der zugrundeliegenden Architektur.
Traditionelles Grenzmodell
User
↓
One large model
↓
Answer
GPT, Claude und Gemini folgen größtenteils diesem Design, obwohl ihre aktuellen Produkte zunehmend eigene Routing-Logik, Werkzeugnutzung sowie agentenähnliches Verhalten hinzufügen.
Fugus Ansatz
┌── Coding specialist
│
User → Controller├── Vision specialist
│
├── Reasoning specialist
│
└── Other models
↓
Final answer
Dies verändert die gesamte Optimierungsfrage grundlegend.
Anstatt zu fragen:
"Wie bauen wir ein einziges Modell, das in allem besser ist?"
Fragt Sakana im Grunde:
"Wie werden wir besser darin, für jedes spezifische Problem das richtige Modell auszuwählen?"
Das ist ein völlig anderer Ansatz.
Fugu vs Claude vs GPT vs Gemini vs DeepSeek
Wie steht Fugu im Vergleich zu den Systemen, die man normalerweise bei der Auswahl eines KI-Anbieters in Betracht zieht?
Claude
Claude bleibt weiterhin eine der bevorzugten Optionen für anspruchsvolle Aufgaben im Bereich des logischen Denkens, Programmierens und langformatigen Schreibens.
Seine größte Stärke liegt darin, dass man direkt ein einzelnes, hochleistungsfähiges Allzweckmodell erhält.
Es ist nicht notwendig, selbst über die Koordination mehrerer Modelle nachzudenken.
Fugu verfolgt den gegenteiligen Ansatz: die Orchestrierung an sich ist das Produkt.
GPT
OpenAI konzentriert sich im Allgemeinen darauf, die Leistungsfähigkeit von Allzweckmodellen zu steigern und dabei Tools sowie agierende Funktionen hinzuzufügen.
Fugus Philosophie verläuft fast in die entgegengesetzte Richtung:
Anstatt ein einzelnes Modell dazu zu zwingen, alles zu bewältigen,
wird ein System entwickelt, das darauf ausgelegt ist, mehrere Modelle gleichzeitig zu koordinieren.
Dieser Unterschied wird immer wichtiger, da die Anzahl der verfügbaren Modelle stetig wächst.
Gemini
Gemini zeigt seine Stärken, wenn multimodale Eingaben, sehr große Kontextfenster oder die Integration in Googles umfassenderes Ökosystem im Vordergrund stehen.
Was Fugu auszeichnet, sind nicht allein die multimodale Unterstützung oder die Länge des Kontexts.
Es ist die Routing-Schicht, die auf mehreren zugrunde liegenden Modellen basiert.
DeepSeek
DeepSeek bietet noch einen weiteren Aspekt, den man in Betracht ziehen sollte.
Ihre Anziehungskraft auf viele Entwickler beruht auf etwas Einfachem:
solide Leistung zu einem attraktiven Preis.
Fugu verfolgt ein völlig anderes Ziel.
Anstatt zu fragen:
"Welches ist das günstigste Modell, das damit umgehen kann?"
fragt sein Controller:
"Welches Modell eignet sich am besten für diesen spezifischen Aufgabenteil?"
Das sind zwei unterschiedliche Optimierungsprobleme.
Dann gibt es noch die Preise
Bei den Preisen wird es erst richtig interessant.
Sakana hat offensichtlich Fugu in zwei Preisstufen unterteilt.
Fugu Max
Eingabe: 2 Dollar pro Million Token
Ausgabe: 6 Dollar pro Million Token
Laut den angegebenen Zahlen ist das etwa 40 bis 60 Prozent günstiger als mehrere Konkurrenzmodelle, die in der Veröffentlichung erwähnt werden.
Fugu Ultra v2
Eingabe: 5 Dollar pro Million Token
Ausgabe: 30 Dollar pro Million Token
Für Anfragen, die über 272.000 Kontext-Token hinausgehen, steigen die angegebenen Preise auf:
Eingabe: 10 Dollar pro Million Token
Ausgabe: 45 Dollar pro Million Token.
Es wird auch behauptet, dass die Ultra-Ebene über ein 1-Million-Token-Kontextfenster sowie einen Wissensstopp vom August 2026 verfügt.
Preisvergleich
Die oben genannten Zahlen (gemessen pro Million Token) stammen aus den Quellenmaterialien; Sie sollten sie vor jeder Kaufentscheidung mit den aktuellen, veröffentlichten Preisen der jeweiligen Anbieter abgleichen.
Aber es gibt ein Problem
Das ist wohl die interessanteste Komplikation in der gesamten Fugu-Geschichte.
Die Orchestrierung ist nicht kostenlos.
Jedes Mal, wenn das System muss:
- eine Aufgabe in Teile aufteilen
- diese Teile weiterleiten
- einen anderen Modell aufrufen
- auf die Antwort dieses Modells warten
- die Qualität des Ergebnisses überprüfen
- und alles wieder zusammenfügen
entsteht zusätzlicher Aufwand.
Der Aufwand kann sich als Zusatzverzögerung zeigen.
Betrachten Sie einen solchen Antrag:
„Schreiben Sie mir einen Tweet über Kaffee.“
Für eine so einfache Aufgabe benötigen Sie mit ziemlicher Sicherheit keine Koordinierungsstufe, die mehrere spezialisierte Modelle verwalten muss.
Das wäre so, als würde man ein ganzes Beratungsunternehmen hinzuziehen, nur um einen locker sitzenden Wasserhahn zu reparieren.
Vergleichen Sie das nun mit einer weitaus anspruchsvolleren Aufgabe – beispielsweise dem Einreichen eines umfangreichen technischen Dokuments, wobei das System durch die dazugehörige Codebasis geht, Designfehler aufspürt, mehrere mögliche Lösungen gegeneinander abwägt und anschließend einen konkreten Plan zur Umsetzung des besten Ansatzes erstellt.
In diesem Fall bringt eine Orchestrierungsschicht erhebliche Vorteile.
Das versteckte Problem: Die Black Box
Es gibt ein weiteres Problem, das möglicherweise sogar wichtiger ist als die Geschwindigkeit.
In der Regel haben Sie keine Kenntnis darüber, welches zugrunde liegende Modell tatsächlich jeden Teil Ihrer Anfrage verarbeitet hat.
Für den alltäglichen Verbrauchergebrauch ist das kein großes Problem.
Für unternehmenseigenen Einsatz kann es jedoch zu erheblichen Schwierigkeiten führen.
Betrachten Sie Organisationen, die mit folgendem umgehen müssen:
- vertraulichen Quellcode
- Finanzunterlagen
- Kundeninformationen
- exklusiven Dokumenten
- regulierten Daten
Falls die Routing-Schicht im Hintergrund stumm zwischen verschiedenen Modellen wählt, werden Unternehmen zu Recht Antworten auf Fragen wie folgende wünschen:
Welches Modell hat tatsächlich meine Daten bearbeitet? Wo wurde es verarbeitet? Was genau wurde an jedes Modell gesendet? Ist die Routing-Entscheidung überprüfbar? Können bestimmte Arbeitslasten ausschließlich auf genehmigte Modelle beschränkt werden?
Das sind keine hypothetischen Bedenken.
In Unternehmensumgebungen kann die Fähigkeit, das System zu überwachen und zu steuern, genauso wichtig sein wie die reine Intelligenz des Modells.
Jede Orchestrierungsplattform, die als Kerninfrastruktur und nicht nur als weiterer API-Wrapper betrachtet werden möchte, muss letztendlich diese Steuerungsdefizite beheben.
Warum das wichtiger sein könnte als die Veröffentlichung eines einzelnen Modells
Das ist die Idee, die besonders hervorsticht.
Nehmen wir an, ein Wettbewerber bringt nächsten Monat ein deutlich besseres Codiermodell auf den Markt.
Ein herkömmlicher Modellanbieter müsste das Modell neu trainieren, bewerten und eine völlig neue Version veröffentlichen.
Ein auf Orchestrierung basierendes System hingegen könnte dieses neue Modell einfach in seinen bestehenden Pool an Optionen einbinden.
Der Steuerungsmechanismus erhält somit effektiv einen weiteren Spezialisten, auf den er zurückgreifen kann.
Das ist ein bedeutender Vorteil.
Die resultierende Struktur sieht ungefähr so aus:
AI Model A
│
AI Model B
│
User → Controller → AI Model C
│
AI Model D
│
AI Model E
Unter diesem Modell kann die Leistungsfähigkeit des gesamten Systems einfach dadurch steigen, dass das umgebende Ökosystem der Modelle ständig verbessert wird.
Der Controller selbst muss nicht unbedingt bei jeder Iteration dramatisch intelligenter werden.
Was er braucht, ist, besser darin zu werden, Entscheidungen zu treffen.
Und dieser Schwerpunktwechsel könnte sich als wichtige Richtung für die Zukunft der agierenden KI erweisen.
Der größere Wettlauf um KI könnte sich ändern
Über einen langen Zeitraum hinweg war das Muster des Fortschritts in der KI recht vorhersehbar: Das Modell vergrößern, es mit mehr Trainingsdaten versorgen, seine Fähigkeiten im Schlussfolgern weiter ausbauen, mehr Rechenleistung einsetzen und den Kreislauf wiederholen. Diese Formel beginnt nun unvollständig zu wirken.
Generation 1
Ein einzelnes Modell, das alle Aufgaben eigenständig bewältigt.
Generation 2
Ein einzelnes Modell in Kombination mit externen Tools.
Generation 3
Ein Agent, der mehrere Tools und Modelle koordiniert.
Generation 4?
Ein System, das spontan ein maßgeschneidertes Team aus Modellen zusammenstellt, angepasst an das jeweilige Problem.
Diese letzte Stufe scheint genau das zu sein, was Fugu anstrebt.
Falls dieses Konzept aufgeht, könnte das wertvollste KI-Produkt der Zukunft nicht das Modell mit den höchsten Schlussfolgerungsleistungen sein. Vielmehr könnte es das System sein, das klug genug ist, zu erkennen, wann ein bestimmtes Modell überhaupt nicht verwendet werden sollte.
Sollten Sie Fugu tatsächlich verwenden?
Hier ist eine praktische Aufschlüsselung.
Für einfache, API-basierte Aufgaben
Vermeiden Sie es wahrscheinlich.
Falls Ihr Anwendungsfall Dinge wie folgende umfasst:
- kurze Zusammenfassungen
- einfache Klassifizierungsaufgaben
- routinemäßige Inhaltsgenerierung
- schnelle, faktenbasierte Fragen
Dann lohnt sich die zusätzliche Koordinierungsstufe vermutlich nicht aufgrund der dadurch entstehenden Komplexität.
Für ausgefeilte Agentensysteme
Hier wird es interessant.
Vor allem bei Arbeiten, die Folgendes beinhalten:
- Softwareentwicklung
- Forschungsaufgaben
- Analyse dichter Dokumente
- datenintensive Pipelines
- mehrstufige Schlussfolgerungsketten
- autonomes Agentenverhalten
- Probleme, die verschiedene Arten von Expertise erfordern
Genau hier beginnt die Routenplanung zwischen Modellen Früchte zu tragen.
Zusammenfassende Gedanken
Es wäre voreilig, Fugu Ultra als eine Art endgültigen Nachfolger von GPT oder Claude zu bezeichnen. Die Benchmark-Werte erscheinen stark, stammen aber derzeit vom Hersteller selbst, und es ist weiterhin eine unabhängige Überprüfung erforderlich, bevor endgültige Schlussfolgerungen gezogen werden können.
Aber wenn man das als nur einen weiteren Eintrag in den Benchmark-Kriegen abtut, verkennt man den eigentlichen Punkt. Die wirkliche Geschichte hier ist architektonischer Natur, nicht numerisch.
OpenAI, Anthropic und Google haben enorme Ressourcen in die Weiterentwicklung ihrer Modelle investiert, um sie so leistungsfähig wie möglich zu machen. Sakana scheint hingegen eine andere Hypothese zu testen:
Möglicherweise besteht das Ziel nicht darin, ein perfektes Modell zu entwickeln. Vielmehr könnte es darum gehen, einen hervorragenden Koordinator für eine Reihe unvollkommener Modelle zu schaffen.
Das ist ein kleiner konzeptioneller Wandel, aber keineswegs unbedeutend. Sollte sich das bewähren, könnte es die Art und Weise verändern, wie künftig KI-Anwendungen entwickelt werden.
Das KI-System, das letztendlich gewinnt, ist vielleicht nicht das mit den meisten Parametern, dem längsten Kontextfenster oder der höchsten Punktzahl in irgendeiner Rangliste. Es könnte einfach das sein, das in der Lage ist, eine Aufgabe zu betrachten und zu erkennen: Dieses spezielle Modell eignet sich am besten für diese konkrete Aufgabe.
Das ist der Aspekt von Fugu Ultra v2.0, dem man Aufmerksamkeit schenken sollte – nicht die Rangliste.