Fugu Ultra: Як модель-оркестратор штучного інтелекту кидає виклик GPT та Claude

Тут важливим не є рейтинг у табелі лідерів. Важливим є мислення, яке лежить в основі отримання цього рейтингу.

Слідкуючи за запусками моделей ШІ протягом останнього року, можна помітити певну закономірність.

Більше параметрів.

Більші вікна контексту.

Кілька додаткових балів у тестах продуктивності.

Дешевші токени.

Ще одна модель, яку називають „найсильнішою серед усіх“.

Але 11 вересня Sakana AI представила Fugu Ultra v2.0, і щось у цьому конкретному анонсі порушило цю закономірність.

Не самі бали тестів продуктивності привернули увагу.

Увагу привернув механізм, який забезпечує ці бали.

Fugu Ultra не прагне стати найрозумнішою моделлю ШІ у світі.

Натомість вона ставить зовсім інше завдання:

А що, як найсильніша система ШІ — це не одна модель, а система, достатньо розумна, щоб знати, яка модель має обробляти кожну частину проблеми?

У довгостроковій перспективі це питання може бути важливішим за будь-яку окрему перемогу у тестах.

То що ж таке Fugu Ultra?

Ось перша деталь, яка відрізняє Fugu від інших.

Fugu Ultra не працює як стандартна модель на кшталт GPT чи Claude.

Sakana називає його контролером або шаром оркестрації.

1. Розібрати, про що йдеться
2. Розділити запитання на менші підзавдання

Визначте, яка спеціалізована модель підходить для кожного підзавдання

Передайте роботу відповідним чином

Об’єднайте результати

За потреби додайте власні міркування

Припустимо, ви надсилаєте запит на кшталт:

"Проаналізуйте фінансову звітність цієї компанії, створіть графік, позначте будь-які аномалії та узагальніть результати."

Традиційна модель намагатиметься виконати всю роботу, використовуючи єдиний набір навичок.

Організована система розглядає такий самий запит скоріше як проект, переданий команді:

Аналіз документа → спеціалізована модель Інтерпретація даних → інша спеціалізована модель Аналіз графіка → спеціаліст, який зосереджений на візуалах чи даних Написання коду → спеціаліст з програмування Об’єднання всього → контролер

З вашої точки зору це все одно виглядає як один виклик API.

Однак насправді ви взаємодієте з набором моделей ШІ, які координує інша система ШІ.

Як повідомляється, банк моделей Sakana поєднує моделі з відкритим кодом із спеціалізованими моделями, серед яких лінійка Nemotron від NVIDIA.

Саме тут ситуація стає справді цікавою.

Цифри тестування

Згідно з даними, наданими самою Sakana, Fugu Ultra v2.0 показав високі результати у кількох категоріях тестування.

Компанія стверджує, що Fugu посів перше місце або поділив перше місце у 5 з 8 тестів, а також увійшов до топ-2 у 7 з 8 тестів.

Одним із показників, який відразу привертає увагу, є DeepSWE: 74.3.

DeepSWE заслуговує на увагу, оскільки він оцінює навички програмної інженерії, а не просто тестує навички програмування.

Fugu також показав високі результати у тестах Chartography, SWEFish, GDP.pdf та Toolathon.

Fugu Ultra v2 проти інших моделей Frontier

Згідно з оприлюдненими порівняннями, Fugu Ultra v2 перевершив кілька відомих систем, серед яких:

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

Також стверджується, що він особливо добре справляється з тестом Chartography, який орієнтований на аналіз діаграм та інших структурованих візуальних даних.

Ось ключове уточнення:

Це цифри, які Sakana навела щодо власної системи.

Станом на час оприлюднення цієї інформації жодна незалежна лабораторія не вдалась повторити ці показники.

Ця різниця має значення.

Бенчмарк, оприлюднений компанією-розробником моделі, може здаватися вражаючим, але все одно потребує зовнішньої перевірки, перш ніж його можна буде повністю довіряти.

Отже, справедливий підхід до оцінки цих результатів полягає у наступному:

Справді цікаво. Варто детальніше дослідити. Ще немає остаточних висновків.

Картинка за допомогою бенчмарків

Можна стверджувати, що найбільш значущим показником тут є не якийсь окремий бал, а цифра 5 з 8.

Чому це має більше значення?

Тому що досягнення перемоги в одному конкретному бенчмарку часто означає лише те, що модель була налаштована під це конкретне завдання.

Досягнення високих позицій у різних типах завдань є більш значущим сигналом.

Проте варто знову підкреслити: це результати, надані самими виробниками, а не підтверджені незалежно.

Більш цікаве порівняння: як думають ці системи

Справжня різниця тут, ймовірно, полягає не у самому балі.

Вона криється у базовій архітектурі.

Традиційна модель фронтиру

User
  ↓
One large model
  ↓
Answer

GPT, Claude та Gemini у більшості випадків дотримуються цього підходу, хоча їхні поточні продукти все частіше додають власну логіку маршрутизації, інструменти та поведінку, схожу на поведінку агентів.

Підхід Fugu

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

Це змінює саму сутність завдання оптимізації.

Замість того, щоб запитувати:

"Як нам створити єдину модель, яка буде кращою у всьому?"

Sakana по суті запитує:

"Як нам краще вибирати правильну модель для кожної конкретної проблеми?"

Це зовсім інша стратегія, яку потрібно обрати.

Fugu проти Claude, GPT, Gemini та DeepSeek

Як же Fugu порівнюється з системами, які ви зазвичай розглядаєте під час вибору постачальника ШІ?

Claude

Claude досі залишається одним із основних виборів для складних завдань з логічного мислення, програмування та написання довгих текстів.

Його головною перевагою є те, що ви отримуєте одну потужну універсальну модель вже з самого початку.

Немає потреби самостійно координувати кілька моделей.

Fugu обирає протилежний підхід: саме координація є продуктом.

GPT

OpenAI зазвичай зосереджується на підвищенні можливостей універсальних моделей, додаючи до них інструменти та функції агентів.

Філософія Fugu йде майже протилежним напрямком:

Замість того, щоб змушувати одну модель виконувати все,

він створює систему, призначену для одночасної координації кількох моделей.

Ця різниця стає все важливішою зі зростанням кількості доступних моделей.

Gemini

Gemini досягає найкращих результатів, коли пріоритетом є багатомодальний вхід, дуже великі вікна контексту чи інтеграція з більш широкою екосистемою Google.

Те, що відрізняє Fugu, — це не сама багатомодальна підтримка чи довжина контексту окремо.

Це шар маршрутизації, який розташовується над кількома базовими моделями.

DeepSeek

DeepSeek пропонує ще один підхід, який варто розглянути.

Його привабливість для багатьох розробників зводиться до чогось простого:

висока продуктивність за конкурентоспроможною ціною.

Fugu прагне зовсім іншої мети.

Замість того, щоб запитувати:

"Яка найдешевша модель, здатна впоратися з цим?"

його контролер запитує:

"Яка модель найкраще підходить для цієї конкретної частини завдання?"

Це дві різні проблеми оптимізації.

А ще є ціноутворення

Саме тут все стає ще цікавішим.

Схоже, Sakana розділила Fugu на два рівні ціноутворення.

Fugu Max

Вхідні дані: 2 долари за мільйон токенів

Вихідні дані: 6 доларів за мільйон токенів

Згідно з наведеними цифрами, цей варіант приблизно на 40–60 відсотків дешевший, ніж кілька конкуруючих моделей, згаданих у оголошенні.

Fugu Ultra v2

Вхідні дані: 5 доларів за мільйон токенів

Вихідні дані: 30 доларів за мільйон токенів

Для запитів, які перевищують обсяг 272 000 токенів контексту, ціни підвищуються до:

Вхідні дані: 10 доларів за мільйон токенів

Вихідні дані: 45 доларів за мільйон токенів.

Кажуть, що тариф Ultra також включає вікно контексту на 1 мільйон токенів разом із датою закінчення оновлення знань — серпень 2026 року.

Порівняння цін

Ці дані (вимірювані за мільйон токенів) наведені у вихідному матеріалі; перед прийняттям рішення про покупку вам слід перевірити їх у порівнянні з поточними опублікованими цінами кожного постачальника.

Але є одна умова

Це, мабуть, найцікавіша складність у всій історії з Fugu.

Оркестрація не є безкоштовною.

Кожного разу, коли системі потрібно:

• розділити завдання на частини
• направити ці частини
• звернутися до іншої моделі
• чекати відповіді цієї моделі
• перевірити якість результату
• знову об’єднати все разом

це створює додаткові витрати.

Ці додаткові витрати можуть проявлятися у вигляді збільшення затримки.

Розгляньмо такий запит:

„Напишіть мені твіт про каву.“

Для чогось настільки простого вам майже напевно не потрібен шар координації, який би керував кількома спеціалізованими моделями.

Це було б схоже на те, щоб викликати цілу консалтингову фірму для того, щоб затягнути відпускаючий кран.

Тепер порівняйте це з набагато складнішим завданням — наприклад, надати довгий технічний документ, щоб система проаналізувала відповідну базу коду, виявила проблеми з дизайном, порівняла кілька можливих рішень та створила конкретний план для впровадження найкращого підходу.

У такому випадку наявність шару оркестрації починає приносити значну користь.

Прихована проблема: чорна скринька

Існує ще одна проблема, яка може бути навіть важливішою за швидкість.

Зазвичай ви не можете бачити, яка саме основна модель насправді обробляла кожну частину вашого запиту.

Для повсякденного використання споживачами це не є серйозною проблемою.

Однак у корпоративному середовищі це може стати справжньою перешкодою.

Уявіть організації, які працюють із:

• конфіденційним вихідним кодом
• фінансовою звітністю
• інформацією про клієнтів
• ексклюзивними документами
• даними, підлягаючими регулюванню

Якщо шар маршрутизації таємно обирає між різними моделями на невидимому рівні, компанії цілком логічно будуть шукати відповіді на такі запитання:

Яка саме модель фактично працювала з моїми даними? Де вони були оброблені? Що саме було надіслано кожній моделі? Чи можлива перевірка рішень щодо маршрутизації? Чи можна прив’язати певні завдання лише до схвалених моделей?

Це не гіпотетичні проблеми.

У корпоративних умовах здатність спостерігати за системою та керувати нею може бути настільки ж важливою, як і сама розумність моделі.

Будь-яка платформа оркестрації, яка хоче розглядатися як основна інфраструктура, а не просто ще один обгорток API, зрештою буде змушена усунути ці прогалини в управлінні.

Чому це може бути важливіше, ніж випуск однієї моделі

Ось ідея, яка постійно залишається значущою.

Припустимо, наступного місяця конкурент випускає значно кращу модель кодування.

Традиційний постачальник моделей буде змушений перенавчати її, оцінювати та випускати абсолютно нову версію.

Натомість система на основі оркестрації може просто додати цю нову модель до свого існуючого набору варіантів.

Контролер фактично отримує ще одного спеціаліста, до якого може звернутися.

Це справжня перевага.

Отримана структура виглядає приблизно так:

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

За цією моделлю можливості всієї системи можуть покращуватися просто через постійне вдосконалення навколишньої екосистеми моделей.

Сам контролер не обов’язково має ставати значно розумнішим з кожною ітерацією.

Йому потрібно постійно краще приймати рішення.

І ця зміна акценту може стати важливим напрямком розвитку агентних ШІ в майбутньому.

Гонка за кращими ШІ може змінюватися

Протягом тривалого часу закономірності прогресу в галузі ШІ були досить передбачуваними: робити модель більшою, надавати їй більше даних для навчання, розвивати її здатність до міркувань, використовувати більше обчислювальних ресурсів та повторювати цей цикл. Однак ця формула починає здаватися неповною.

Покоління 1

Одна модель, яка самостійно виконує всі завдання.

Покоління 2

Одна модель у поєднанні з зовнішніми інструментами.

Генерація 3

Один агент, який координує кілька інструментів та моделей.

Генерація 4?

Система, яка на льоту формує індивідуальну команду моделей, адаптовану до конкретної проблеми, з якою вона стикається.

Здається, саме цього прагне Fugu.

Якщо цей крок виявиться успішним, найціннішим продуктом ШІ в майбутньому може стати не модель з найвищими показниками логічного мислення, а система, достатньо розумна, щоб розпізнавати коли певну модель взагалі не слід використовувати.

Чи варто справді використовувати Fugu?

Ось практичний аналіз.

Для простих завдань у стилі API

Ймовірно, краще обійтися без нього.

Якщо ваш випадок використання передбачає такі завдання:

• коротке узагальнення
• прості завдання класифікації
• рутинна генерація контенту
• швидкі запитання на факти

Тоді додатковий шар координації, ймовірно, не вартий доданої складності.

Для складних систем агентів

Саме тут все стає цікавим.

Особливо для роботи, яка включає:

• розробку програмного забезпечення
• дослідницькі завдання
• аналіз об’ємних документів
• процеси з великим обсягом даних
• ланцюжки міркувань з кількох етапів
• поведінку автономних агентів
• задачі, які вимагають кількох різних видів експертизи

Саме в цій сфері маршрутизація між моделями починає приносити користь.

Заключні міркування

Було б передчасно називати Fugu Ultra якимось остаточним наступником GPT чи Claude. Показники тестів виглядають сильними, але наразі вони надані самим постачальником, і перед тим, як робити остаточні висновки, все ще потрібна незалежна перевірка.

Проте відкидати це як ще одну участь у „війнах“ бенчмарків означатиме не зрозуміти суті. Справжня історія тут архітектурна, а не числова.

OpenAI, Anthropic та Google вклали величезні ресурси у те, щоб зробити окремі моделі якомога потужнішими. Sakana, схоже, тестує іншу гіпотезу:

Можливо, мета не у створенні ідеальної моделі. Можливо, йдеться про створення чудового координатора для недосконалих моделей.

Це невелика концептуальна зміна, але вона не є тривіальною. Якщо вона підтвердиться, це може змінити спосіб створення штучних інтелектуальних додатків у майбутньому.

Система ШІ, яка у підсумку перемагає, може не бути тією, що має найбільшу кількість параметрів, найширше вікно контексту чи найвищий рейтинг у будь-якому списку лідерів. Це може бути просто та система, яка здатна розглянути завдання та дійти висновку: саме ця модель підходить для цієї конкретної роботи.

Саме цьому аспекту Fugu Ultra v2.0 варто приділити увагу, а не таблиці ранжування.