Fugu Ultra: Jak model orkiestratora AI kwestionuje GPT i Claude

Tutaj nie ma znaczenia wynik na liście liderów. Ważne jest myślenie stojące za uzyskaniem tego wyniku.

Obserwując wprowadzanie nowych modeli sztucznej inteligencji w ciągu ostatniego roku, można dostrzec pewien wzorzec.

Jeszcze więcej parametrów.

Większe okna kontekstowe.

Kilka dodatkowych punktów w testach wydajności.

Taniejsze tokeny.

Kolejny „najpotężniejszy model do tej pory”.

Następnie, 11 września, Sakana AI zaprezentowało Fugu Ultra v2.0, a coś w tym konkretnym ogłoszeniu złamało ten wzorzec.

To nie same wyniki testów wydajności wyróżniały się.

Uwagę przyciągnął mechanizm generujący te wyniki.

Fugu Ultra nie dąży do bycia najmądrzejszym modelem sztucznej inteligencji na świecie.

Zamiast tego stawia sobie zupełnie inne pytanie:

A co, jeśli najsilniejsza konfiguracja sztucznej inteligencji to nie jeden model, lecz system na tyle inteligentny, by wiedzieć, który model powinien zajmować się którym elementem problemu?

To pytanie może okazać się ważniejsze w dłuższej perspektywie niż jakikolwiek pojedynczy sukces w testach.

Więc co dokładnie jest Fugu Ultra?

Oto pierwsza cecha, która odróżnia Fugu od innych rozwiązań.

Fugu Ultra nie funkcjonuje jak standardowy model w stylu GPT czy Claude.

Zamiast tego Sakana przedstawia je jako kontroler, czyli warstwę orkiestracji.

Wyobraźmy to sobie jako wykwalifikowanego kierownika inżynieryjnego nadzorującego zespół.

Podajemy mu złożone żądanie.

Zamiast próbować samodzielnie zajmować się każdą częścią tego żądania, kontroler może:

1. Przetworzyć treść żądania
2. Rozbić żądanie na mniejsze zadania podrzędne

Określ, który model specjalistyczny pasuje do każdego podzadania

P przekaż pracę odpowiednio

Złącz wyniki

Gdy to konieczne, dodaj własną analizę

Załóżmy, że składasz prośbę w następujący sposób:

">Przejrzyj raport finansowy tej firmy, stwórz wykres, zaznacz wszelkie anomalie i podsumuj ustalenia."

Konwencjonalny model próbowałby wykonać całą prośbę, korzystając z jednego zestawu umiejętności.

Zorganizowany system traktuje tę samą prośbę bardziej jak projekt przekazany zespołowi:

Analiza dokumentu → model specjalistyczny Interpretacja danych → inny specjalista Analiza wykresu → specjalista od wizji lub danych Pisanie kodu → specjalista od programowania Połączenie wszystkiego → kontroler

Z twojej strony nadal wygląda to jak jedna żądanie API.

Za kulisami jednak faktycznie masz do czynienia z zbiorem modeli AI koordynowanym przez inny system AI.

Mówi się, że zbiór modeli Sakana łączy modele o otwartym kodzie z modelami specjalistycznymi, w tym serię Nemotron firmy NVIDIA.

Wtedy właśnie robi się naprawdę ciekawie.

Liczby z testów benchmark

Na podstawie danych podanych przez samą Sakanę, Fugu Ultra v2.0 osiągnął dobre wyniki we wszystkich kategoriach testów benchmark.

Firma twierdzi, że Fugu zajął miejsce pierwsze lub dzieliło pierwsze miejsce w 5 z 8 testów benchmark, a w dwóch z ośmiu znalazł się w czołowej dwójce.

Jedną z liczb, która od razu rzuca się w oczy, jest DeepSWE: 74,3.

DeepSWE zasługuje na uwagę, ponieważ mierzy umiejętności w inżynierii oprogramowania, a nie testuje proste zadania programistyczne.

Fugu również osiągnął dobre wyniki w testach Chartography, SWEFish, GDP.pdf i Toolathon.

Fugu Ultra v2 kontra inne modele Frontier

Zgodnie z przedstawionymi porównaniami, Fugu Ultra v2 przewyższył kilka dobrze znanych systemów, między którymi:

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

Twierdzi się również, że szczególnie dobrze radzi sobie z Chartography, standardem oceny opartym na interpretacji wykresów i innych strukturalnych danych wizualnych.

Oto kluczowe sprostowanie:

To są dane podane przez Sakana na temat jego własnego systemu.

W momencie publikacji tych informacji żaden niezależny laboratorium nie powtórzył tych wyników.

To ma znaczenie.

Standard oceny opracowany przez firmę, która stworzyła model, może wydawać się imponujący, ale nadal wymaga weryfikacji z zewnątrz, zanim będzie można mu w pełni zaufać.

Zatem sprawiedliwy sposób traktowania tych wyników jest następujący:

Naprawdę interesujące. Warto się tym bliżej zająć. Jeszcze nie ma ostatecznego wniosku.

Obraz bazowy

Prawdopodobnie najważniejszą liczbą tutaj nie jest żaden pojedynczy wynik, lecz wartość 5 z 8.

Dlaczego to ma większe znaczenie?

Ponieważ wygrana w jednym konkretnym teście bazowym często oznacza jedynie dostosowanie modelu do tego konkretnego zadania.

Zdobycie wysokiej pozycji w różnych typach zadań jest bardziej znaczącym sygnałem.

Mimo to warto powtórzyć: są to wyniki samodzielnie zgłoszone, a nie potwierdzone niezależnie.

Bardziej interesujące porównanie: jak myślą te systemy

Prawdziwa różnica tutaj prawdopodobnie nie leży w samym wyniku.

Lecz w podstawowej architekturze.

Tradycyjny model graniczny

User
  ↓
One large model
  ↓
Answer

GPT, Claude i Gemini w dużej mierze stosują taki projekt, chociaż ich obecne produkty coraz częściej dodają własną logikę routingu, narzędzia oraz zachowania przypominające agenta.

Podejście Fugu

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

To zmienia całkowicie koncepcję optymalizacji.

Zamiast pytać:

"Jak stworzyć jeden model, który będzie lepszy we wszystkim?"

Sakana w istocie pyta:

"Jak stać się lepszym w doborze odpowiedniego modelu do każdego konkretnego problemu?"

To zupełnie inna strategia, którą należy przyjąć.

Fugu vs Claude vs GPT vs Gemini vs DeepSeek

Jak więc Fugu porównuje się z systemami, które zwykle bierze się pod uwagę przy wyborze dostawcy AI?

Claude

Claude wciąż jest jednym z najlepszych wyborów do zadań wymagających rozumowania, programowania oraz pisania tekstów dłuższych.

Jego główną zaletą jest to, że otrzymujemy pojedynczy, wysoce sprawny model uniwersalny od razu po rozpakowaniu.

Nie trzeba martwić się o samodzielne koordynowanie kilku modeli.

Fugu przyjmuje przeciwną strategię: sama orkiestracja jest produktem.

GPT

OpenAI koncentrowało się głównie na rozwijaniu możliwości modeli uniwersalnych, dodając przy tym różne narzędzia i funkcje typu agencji.

Filozofia Fugu zmierza niemal w przeciwnym kierunku:

Zamiast zmuszać jeden model do obsługi wszystkiego,

tworzy system zaprojektowany do koordynowania kilku modeli jednocześnie.

Różnica ta staje się coraz ważniejsza w miarę wzrostu liczby dostępnych modeli.

Gemini

Gemini sprawdza się najlepiej, gdy priorytetem są dane wielomodalne, bardzo duże okna kontekstowe lub integracja z szerszym ekosystemem Google.

To, co wyróżnia Fugu, to nie tyle wsparcie wielomodalne czy długość kontekstu same w sobie.

Jest to warstwa routingu, która znajduje się nad kilkoma podległymi modelami.

DeepSeek

DeepSeek oferuje kolejny interesujący punkt do rozważenia.

Jego atrakcyjność dla wielu programistów wynika z czegoś prostego:

dobry wydajność przy konkurencyjnej cenie.

Fugu dąży do zupełnie innego celu.

Zamiast pytać:

">Który model jest najtańszy i nadaje się do tego zadania?"

jego sterownik pyta:

">Który model najlepiej pasuje do tej konkretnej części zadania?"

To są dwa odrębne problemy optymalizacyjne.

A potem jest kwestia cen

Kwestia cen sprawia, że sytuacja staje się jeszcze ciekawsza.

Sakana najwyraźniej podzieliła Fugu na dwa poziomy cenowe.

Fugu Max

Wejście: 2 dolary za milion tokenów

Wyjście: 6 dolarów za milion tokenów

Zgodnie z podanymi danymi, jest to mniej więcej o 40 do 60 procent tańsze niż kilka konkurencyjnych modeli wymienionych w komunikacie.

Fugu Ultra v2

Wejście: 5 dolarów za milion tokenów

Wyjście: 30 dolarów za milion tokenów

Dla zapytań przekraczających 272 000 tokenów kontekstu, podane stawki wzrastają do:

Wejście: 10 dolarów za milion tokenów

Wyjście: 45 dolarów za milion tokenów.

Mówi się również, że poziom Ultra obejmuje okno kontekstowe na 1 milion tokenów wraz z Data końcowa wiedzy na sierpień 2026 roku.

Porównanie cen

Podane powyżej wartości (obliczane na milion tokenów) pochodzą z materiałów źródłowych; przed podjęciem jakichkolwiek decyzji zakupowych powinieneś je sprawdzić w odniesieniu do aktualnych cen publikowanych przez poszczególnych dostawców.

Jest jednak haczyk

To chyba najciekawszy aspekt całej historii z Fugu.

Koordynacja nie jest bezpłatna.

Za każdym razem, gdy system musi:

• rozbijać zadanie na części
• kierować te części
• wzywać inny model
• czekać na odpowiedź tego modelu
• weryfikować jakość wyniku
• i łączyć wszystko z powrotem

powstaje dodatkowy obciążenie.

To obciążenie może objawiać się jako dodatkowy opóźnienie.

Rozważmy prośbę taką jak:

">Napisz mi tweeta o kawie."

Prawie na pewno nie potrzebujesz warstwy koordynacyjnej, która miałaby obsługiwać kilka specjalistycznych modeli w tak prostym przypadku.

To byłoby jak wezwanie całej firmy konsultingowej tylko po to, by dokręcić luźny kran.

Porównaj to teraz z znacznie bardziej skomplikowaną prośbą – na przykład dostarczeniem długiego dokumentu technicznego, żądaniem od systemu przeanalizowania powiązanego kodu, wskazania błędów projektowych, porównania kilku możliwych rozwiązań oraz stworzenia konkretnego planu wdrożenia najlepszej metody.

Tutaj posiadanie warstwy orkiestracji zaczyna przynosić znaczące korzyści.

Prywatny problem: Czarna skrzynka

Istnieje jeszcze jeden problem, który może być nawet ważniejszy od szybkości.

Zazwyczaj nie masz możliwości sprawdzenia, który konkretny model przetworzył poszczególne elementy twojej prośby.

Dla codziennego użytku konsumenckiego nie stanowi to większego problemu.

Jednak w środowiskach korporacyjnych może to być poważnym utrudnieniem.

Pomyśl o organizacjach, które zajmują się:

• tajnym kodem źródłowym
• dokumentacją finansową
• informacjami o klientach
• dokumentami własnościowymi
• Danymi podlegającymi regulacjom

Jeśli warstwa routingu potajemnie wybiera różne modele w tle, firmy będą słusznie chciały odpowiedzi na pytania takie jak:

Który model faktycznie miał dostęp do moich danych? Gdzie zostały one przetworzone? Co dokładnie zostało wysłane do każdego modelu? Czy decyzja o routingu może być sprawdzona? Czy określone obciążenia pracy mogą być przypisane wyłącznie do zatwierdzonych modeli?

To nie są hipotetyczne obawy.

W środowiskach korporacyjnych zdolność do monitorowania i zarządzania systemem może być równie ważna jak sama inteligencja modelu.

Każda platforma orkiestracji, która chce być traktowana jako kluczowa infrastruktura, a nie tylko kolejny wrapper API, w końcu będzie musiała rozwiązać te problemy związane z brakiem odpowiedniego zarządzania.

Dlaczego to może być ważniejsze niż pojedyncza wersja modelu

Oto idea, która szczególnie rzuca się w oczy.

Załóżmy, że konkurent wprowadzi następnego miesiąca znacznie lepszy model do kodowania.

Konwencjonalny dostawca modeli musiałby przeszkolić nowe modele, je ocenić i wydać zupełnie nową wersję.

Z kolei system oparty na orkiestracji mógłby po prostu dodać ten nowy model do swojego istniejącego zestawu opcji.

Kontroler w ten sposób uzyskuje dodatkowego specjalistę, do którego może się zwrócić.

To jest znacząca przewaga.

Wynikowa struktura wygląda mniej więcej tak:

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

Zgodnie z tym modelem możliwości całego systemu mogą rosnąć po prostu dlatego, że otaczający go ekosystem modeli stale się udoskonala.

Sam kontroler nie musi koniecznie stawać się znacznie inteligentniejszy z każdą iteracją.

Ważne jest, aby stale stawał się lepszy w podejmowaniu decyzji.

A ta zmiana nacisku może okazać się ważnym kierunkiem rozwoju sztucznej inteligencji agentowej w przyszłości.

Rywalizacja w dziedzinie sztucznej inteligencji może się zmieniać

Generacja 1

Jeden model obsługujący każde zadanie samodzielnie.

Generacja 2

Jeden model połączony z zewnętrznymi narzędziami.

Generacja 3

Jeden agent koordynujący wiele narzędzi i modeli.

Generacja 4?

System, który w czasie rzeczywistym tworzy spersonalizowaną grupę modeli, dostosowaną do aktualnego problemu.

To ostatnie etap wydaje się być dokładnie tym, do czego dąży Fugu.

Jeśli ta strategia się powiedzie, najcenniejszym produktem AI w przyszłości może nie być model o najwyższych wynikach w testach rozumowania. Może to być raczej system na tyle inteligentny, by rozpoznać kiedy dany model w ogóle nie powinien być używany.

Czy naprawdę warto korzystać z Fugu?

Oto praktyczny podział.

Dla prostych zadań w stylu API

Prawdopodobnie lepiej go pominąć.

Jeśli Twój przypadek użycia obejmuje m.in.:

• krótkie streszczenia
• proste zadania klasyfikacyjne
• rutynową generację treści
• szybkie pytania faktograficzne

Następnie dodatkowy warstwa koordynacji prawdopodobnie nie jest warta wprowadzonej złożoności.

Dla zaawansowanych systemów agentowych

Tutaj sytuacja staje się interesująca.

W szczególności w przypadku zadań obejmujących:

• rozwój oprogramowania
• Zadania badawcze
• Analizę złożonych dokumentów
• Pipeline wymagające dużej ilości danych
• Lance rozumowania wieloetapowego
• Zachowanie autonomicznych agentów
• Problemy wymagające kilku różnych rodzajów specjalistycznej wiedzy

To właśnie w tym obszarze routowanie między modelami zaczyna przynosić korzyści.

Podsumowanie

Będzie przedwczesne uznawać Fugu Ultra za jakiegoś ostatecznego następcę GPT lub Claude. Wskaźniki benchmarkowe wyglądają dobrze, ale pochodzą obecnie od samego dostawcy, a przed wyciągnięciem ostatecznych wniosków konieczna jest niezależna weryfikacja.

Mimo to lekceważenie tego jako kolejnego elementu walki o standardy benchmarkowe sprawiłoby, że przegapimy sedno sprawy. Prawdziwa historia dotyczy tu aspektów architektonicznych, a nie liczb.

OpenAI, Anthropic i Google zainwestowały ogromne zasoby w rozwój poszczególnych modeli, aby były jak najskuteczniejsze. Sakana wydaje się testować inną hipotezę:

Być może celem nie jest stworzenie jednego doskonałego modelu, lecz wybitnego koordynatora dla zestawu niedoskonałych modeli.

To niewielka zmiana koncepcyjna, ale bynajmniej nie błahe. Jeśli się sprawdzi, może zmienić sposób tworzenia aplikacji opartych na sztucznej inteligencji w przyszłości.

System AI, który ostatecznie wygrywa, niekoniecznie musi mieć najwięcej parametrów, najdłuższe okno kontekstowe ani najwyższą ocenę na jakiejkolwiek liście rankingowej. Może to po prostu być system zdolny do przyjrzenia się zadaniu i stwierdzenia, że ten konkretny model jest odpowiedni do tego konkretnej pracy.

To właśnie ta część Fugu Ultra v2.0 zasługuje na uwagę – a nie tabela rankingowa.