Оркестрационные
модели
вместо scale
Следующий шаг в AI — модель-дирижёр: кого вызвать, как проверить шаг, как собрать ответ. Отличие от gateway-роутера.
Несколько лет прогресс в AI шёл через scale: больше данных, больше параметров, один монолит на всё. Sakana Fugu и похожие системы смещают фокус: следующий скачок — оркестрационные модели, которые учатся выбирать экспертов, а не быть единственным экспертом.
Коротко: вместо «одна модель на все задачи» — модель-дирижёр, которая знает, кого позвать, как проверить промежуточный результат и как собрать финальный ответ.
Чем оркестратор отличается от роутера
- Роутер (классический gateway, OpenRouter) — правило или эвристика: «этот промпт → Claude, тот → GPT».
- Оркестратор (Fugu, Conductor) — обученная LM: планирует шаги, ведёт диалог между агентами, может вызвать себя рекурсивно, верифицирует и синтезирует.
Роутер экономит деньги и упрощает интеграцию. Оркестратор ближе к «агенту над агентами» — дороже по latency, но сильнее на messy multi-step work.
Когда имеет смысл
- code review и security audit с десятками находок;
- воспроизведение research paper;
- долгий research / data science с итерациями;
- продукты, где важна стабильная persona на длинной сессии.
Для FAQ-бота или короткого summary оркестратор избыточен — хватит одной fast-модели через IRI Gateway.
Связь с IRI
IRI Lab строит runtime: Gateway (model layer) + Agent Studio (контроль, политики, логи). Внешние оркестрационные модели — потенциальный «мозг» над нашим пулом; внутри — те же принципы: делегирование, проверка, rollback. Подробнее — в разборе Sakana Fugu.
Итог
Оркестрационные модели — не замена gateway, а слой выше. Ставка на scale остаётся, но для production-агентов выигрывает тот, кто умеет координировать коллектив моделей, а не молиться на один чекпоинт.