Fugu Ultra: Как модель-оркестратор ИИ бросает вызов GPT и Claude

Здесь важен не балл в табличке лидеров, а способ формирования этого балла.

Если следить за выпусками ИИ-моделей за прошедший год, становится заметен определённый паттерн.

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

Более большие окна контекста.

Несколько дополнительных баллов в тестах производительности.

Дешевле токены.

Ещё одна модель, названная «самой мощной на сегодняшний день».

Однако 11 сентября компания Sakana AI представила Fugu Ultra v2.0, и что-то в этом анонсе нарушило этот паттерн.

Не сами баллы в тестах производительности привлекли внимание.

Внимание привлёк механизм, формирующий эти баллы.

Fugu Ultra не стремится стать самой умной ИИ-моделью в мире.

Вместо этого она решает совершенно другую задачу:

Что, если самая мощная система ИИ — это не одна модель, а система достаточно умная, чтобы понимать, какая модель должна решать ту или иную часть задачи?

В долгосрочной перспективе этот вопрос может оказаться важнее любой победы на тестах производительности.

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

Вот первая особенность, которая отличает Fugu от других решений.

Fugu Ultra не работает как стандартная модель вроде GPT или Claude.

Kompanия 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

Клод по-прежнему остается одним из лучших выборов для задач, требующих сложного мышления, программирования и написания длинных текстов.

Его главное преимущество заключается в том, что вы получаете единую, высокоэффективную универсальную модель сразу после распаковки.

Не нужно самостоятельно заботиться о согласовании работы нескольких моделей.

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 стоит уделять внимание, а не таблице рейтингов.