Fusion vs
оркестратор
Fugu
Smart routing на платформе и обученная модель-дирижёр — смежные, но разные слои. Когда хватит gateway, когда нужен Fugu-уровень.
В индустрии всё чаще сравнивают OpenRouter Fusion и Sakana Fugu: оба обещают «не одну модель, а умный выбор из пула». Разница в том, кто принимает решение и насколько глубоко идёт координация.
Коротко: Fusion — маршрутизация и ансамбль на уровне платформы. Fugu — отдельная обученная модель-оркестратор с multi-step workflow внутри одного API-вызова.
OpenRouter Fusion
- платформа агрегирует десятки моделей;
- Fusion подбирает модель(и) под запрос — ближе к smart routing;
- клиент остаётся в парадигме «один запрос — ответ», без явного agent graph в коде.
Sakana Fugu
- своя foundation model, обученная orchestrate;
- рекурсивные вызовы себя и экспертов из пула;
- акцент на длинных задачах: review, security, research reproduction;
- отдельный продукт Sakana, не каталог чужих API.
Аналог в контуре IRI
IRI Gateway сегодня ближе к OpenRouter для РФ: каталог, рубли, единый ключ. Слой «Fusion-подобной» маршрутизации и agent runtime — зона Agent Studio и будущего orchestration в runtime, не замена каталога.
Выбор:
- нужен доступ к моделям и billing → Gateway;
- нужен внешний оркестратор уровня Fugu → отдельная интеграция Sakana (или аналог);
- нужен свой контроль политик и логов → IRI runtime поверх gateway.
Итог
Fusion и Fugu решают смежные, но не одинаковые задачи. Для большинства российских команд первый шаг — multi-provider gateway; оркестрационные модели — когда single-shot ответа уже не хватает.