Проблема подхода «берите GPT-4 и всё»
Большинство ИИ-платформ принимают за вас молчаливое решение: выбирают понравившуюся модель, подключают к ней всё и идут дальше. Это работает, пока не перестаёт работать — пока модель не упадёт, пока конкурент не выпустит нечто лучшее для конкретной задачи, пока вы не захотите принести свой API-ключ и держать расходы на своём счету, пока вам не понадобится генерировать изображения, а модель по умолчанию этого не умеет.
Обычное средство — выпадающий список. Выберите модель, используйте везде, сами разбирайтесь с компромиссами. Это не маршрутизация, это делегирование. ToRun делает нечто структурно иное.
Конвейер, ставящий возможности на первое место
Каждый запрос в ToRun проходит четыре этапа, прежде чем коснуться модели.
1. Режим определяет продуктовую поверхность. Когда вы открываете сессию Чата или запускаете задачу Исследования, вы выбираете Режим. Режим — не просто ярлык интерфейса: он несёт определённый набор обязательных и необязательных возможностей. Задача Исследования требует инструментов (веб-поиск), длинного контекста и структурированного вывода. Обычная сессия чата по умолчанию требует только генерации текста.
2. Набор возможностей становится фильтром. ToRun ведёт каталог моделей многих поставщиков — OpenAI, Anthropic/Claude, Google/Gemini, DeepSeek, xAI/Grok, Mistral и других. Каждая запись несёт объединение возможностей, которые модель действительно поддерживает: зрение, инструменты, выполнение кода, генерация изображений, аудио на входе, аудио на выходе, генерация видео, эмбеддинги, переупорядочивание, потоковая передача в реальном времени, рассуждение и другое. Набор из первого шага сверяется с этим каталогом. Модели, не удовлетворяющие всем обязательным возможностям, отбрасываются.
3. Ранжирование цена-качество выбирает победителя. Среди моделей, прошедших фильтр, ToRun ранжирует по тому, чем запрос является на самом деле. Короткий простой вопрос ранжируется по стоимости, поэтому вы получаете быстрый и дешёвый ответ. Более длинный или трудный ранжируется по возможностям на единицу стоимости, с нижней границей качества. Ход, несущий изображение, ранжируется по тому, насколько хорошо модель видит, а не по рассуждению на рубль. Исполнители рабочих процессов переключаются на приоритет качества, потому что автоматизированный конвейер, работающий без присмотра, должен выбирать лучший результат, а не самый дешёвый обходной путь. Пользователи BYOK входят в ценообразование иначе, поскольку запрос идёт через их собственный счёт у поставщика.
4. Цепочки резерва поглощают сбои поставщика. Если выбранная модель возвращает служебную ошибку, тот же конвейер выполняется заново, исключая эту модель. Отвечает вторая по пригодности модель. Вы не видите никакой ошибки, если только не отключены все жизнеспособные кандидаты.
Конкретный пример: зрение плюс инструменты
Допустим, вы вставляете снимок экрана и просите ToRun поискать в сети контекст о том, что на нём. Этот запрос затрагивает две возможности сразу: зрение (модель должна принимать изображение на входе) и инструменты (модель должна уметь вызвать функцию веб-поиска).
При подходе с одной моделью вы застряли: ваша платформа поддерживает эту комбинацию или нет. При маршрутизации по возможностям ToRun пересекает оба требования. Фильтр переживают только модели с подтверждённой поддержкой И зрения, И вызова инструментов. Из этого короткого списка ранжирование по цене и качеству выбирает лучшую для вашего текущего режима. Если основной кандидат ограничен или недоступен, следующий обрабатывает запрос без каких-либо действий с вашей стороны.
На практике это важно: набор моделей со зрением сильно изменился за последний год и продолжит меняться. Маршрутизация по возможностям заставляет ToRun автоматически учитывать новые модели, как только они внесены в каталог, без всякого обновления с вашей стороны.
Почему это выигрывает у привязки
У платформы с одной моделью есть единственная стратегия резерва: ждать, пока поставщик устранит сбой. У платформы, ставящей возможности на первое место, есть каталог. Когда у OpenAI инцидент, запросы, которые могут обслужить Anthropic или Gemini, обслуживаются там. Когда новая модель Mistral даёт лучшее соотношение цены и качества на структурированном выводе, она входит в ранжирование соответствующих режимов без принудительной миграции.
Та же логика применима к BYOK. Когда вы добавляете свой API-ключ для поставщика, эти учётные данные ограничены внутри слоя маршрутизации. Запросы, подходящие пригодным моделям этого поставщика, могут использовать ваш ключ вместо счёта ToRun, перенося расходы в ваши отношения с поставщиком на подходящем биллинговом уровне. Конвейер маршрутизации не меняется: меняется лишь то, какие учётные данные используются в момент выполнения.
Компромисс — честность: ToRun не может гарантировать, что самая дешёвая модель окажется самой умной для вашей задачи. Ранжирование явное — вы видите, что было выбрано и почему, и можете это переопределить. Такая прозрачность и есть цель. Каждый запрос пишет биллинговую запись с использованной моделью, единицей тарификации, активной при выполнении, и разбивкой стоимости. Вы можете проверить любой вызов спустя месяцы, даже после изменения тарифов поставщика, потому что снимок заморожен на момент выполнения запроса.
Одна модель, которая делает всё, — удобная выдумка. Что вам действительно нужно — платформа, которая находит правильную модель для каждой задачи и делает этот выбор читаемым.