Оркестрация нескольких моделей: маршрутизация по стоимости, задержке и качеству
Использовать одну модель для всего — типичная ошибка новичка. Продакшен-системы с AI направляют разные запросы в разные модели и экономят 60–90% бюджета, попутно повышая качество. Паттерны, логика маршрутизации и компромиссы.
Самая дорогая ошибка, которую мы видим в продакшен-системах с AI, — это использование одной модели на все случаи жизни.
Команда выбирает GPT-5 (или Claude 4 Opus, или другую флагманскую модель). Строит вокруг неё приложение. Счета — пятизначные в месяц. Их можно было бы срезать на 60–90%, направив разные запросы в разные модели, — и одновременно поднять качество.
Это и есть оркестрация нескольких моделей: подбор нужной модели под каждую задачу внутри системы. Это разница между AI «для хобби» и AI в продакшене.
Статья — про паттерны, логику маршрутизации, компромиссы и пошаговое руководство по внедрению.
Почему одна модель — не оптимум
Модели, доступные в 2026 году, группируются примерно по таким уровням:
Флагманские модели для рассуждений (GPT-5, Claude 4 Opus, Gemini 3 Pro, o3): отлично справляются со сложными рассуждениями, дорогие (€2–€15 за миллион входных токенов, €10–€60 за миллион выходных), медленные (типичные 5–30 секунд).
Флагманские универсальные модели (GPT-5 turbo, Claude 4 Sonnet, Gemini 3 Pro Flash): отлично работают с большинством задач интеллектуального труда, умеренно дорогие (€0.50–€3 за миллион входных, €5–€15 за миллион выходных), разумная скорость (2–5 секунд).
Модели среднего уровня (GPT-5 Mini, Claude 4 Haiku, Gemini 3 Flash): хороши для простых и средних задач, дешёвые (€0.10–€0.50 за миллион входных, €0.50–€2 за миллион выходных), быстрые (1–2 секунды).
Маленькие модели (GPT-5 Nano, Claude Haiku Lite, Gemini Flash Lite): хороши для простых структурированных задач, очень дешёвые (€0.02–€0.10 за миллион токенов), очень быстрые (<1 секунды).
Специализированные модели (embedding-модели, reranking-модели, vision-модели, голосовые модели): оптимизированы под конкретные задачи, обычно очень дёшевы за счёт узкого фокуса.
Типичное AI-приложение делает множество разных вызовов LLM. У каждого вызова свои требования:
- Классификация намерения пользователя: нужна простая классификация, быстрый ответ. Идеально подходит модель среднего уровня.
- Извлечение структурированных данных из документов: нужна надёжность структурированного вывода, средняя сложность. Средний уровень или флагман-универсал.
- Генерация собственно ответа на запрос пользователя: нужно качество и работа с контекстом. Флагман-универсал или флагман-рассуждалка.
- Генерация саммари прошлой переписки: простая суммаризация. Средний уровень или маленькая модель.
- Фоновая пакетная обработка: к задержкам не чувствительна, важен объём. Маленькая или средняя.
Использовать флагман на всё это — расточительство. Классификации он не нужен. Суммаризации не нужен. Структурированному извлечению часто тоже не нужен. По-настоящему выигрывает от него только ответ, который видит пользователь.
Экономия — настоящая
У типичного AI-приложения для интеллектуального труда распределение запросов может выглядеть так:
- 60% вызовов LLM: простая классификация, извлечение, суммаризация. Лучше всего обслуживаются средними или маленькими моделями.
- 30% вызовов: средняя сложность. Средний уровень или флагман-универсал.
- 10% вызовов: сложные рассуждения или финальный ответ пользователю. Флагман.
Если использовать флагман на всё, затраты — 100% от его прайса. Если маршрутизировать с умом:
- 60% по цене маленькой модели (1/30 от флагмана): 2% от исходных затрат.
- 30% по цене средней (1/5 от флагмана): 6% от исходных затрат.
- 10% по цене флагмана: 10% от исходных затрат.
Итого: 18% от исходного счёта. Минус 82%. На счёте в €10 000/месяц это €8 200/месяц экономии.
Цифры зависят от формы вашего трафика, но паттерн стабилен: у большинства приложений микс запросов таков, что средний вызов сильно дешевле худшего. Маршрутизация это улавливает.
Базовые паттерны оркестрации
В продакшен-системах с несколькими моделями повторяются несколько паттернов.
Паттерн 1: маршрутизация по типу задачи
Разные типы задач уходят к разным моделям. Самый простой паттерн.
def route_request(task_type):
if task_type == "classification":
return "gpt-5-nano"
elif task_type == "extraction":
return "gpt-5-mini"
elif task_type == "summarization":
return "claude-4-haiku"
elif task_type == "user-facing-response":
return "claude-4-sonnet"
elif task_type == "complex-reasoning":
return "claude-4-opus"Тип задачи классифицирует вызывающий код (он знает, что просит). Маршрутизация детерминирована и легко отлаживается.
Паттерн 2: маршрутизация по сложности
Система оценивает сложность каждого запроса и направляет его соответственно.
def route_by_complexity(request):
complexity = estimate_complexity(request)
if complexity < 3:
return "small"
elif complexity < 7:
return "mid"
else:
return "flagship"Оценку сложности можно получать эвристиками (длина запроса, ключевые слова) или через модель (дешёвый классификатор оценивает запрос). Этот паттерн полезен, когда один и тот же тип задачи сильно варьируется по трудности.
Паттерн 3: каскадная маршрутизация
Сначала пробуем дешёвую модель. Если результат удовлетворителен — используем его. Если нет — эскалируем на более дорогую.
def cascade(request):
cheap_response = call_model("small", request)
if is_acceptable(cheap_response):
return cheap_response
return call_model("flagship", request)Это работает, когда «приемлемо» можно автоматически определить — по confidence-оценкам, валидаторам или отдельной LLM для проверки качества. Паттерн мощный: большинство простых запросов закрывается дешёвой моделью, до дорогой долетают только сложные.
Паттерн 4: специализированная маршрутизация
Используйте специализированные модели для специализированных задач:
- Embeddings: используйте отдельную embedding-модель (намного дешевле, чем гнать чат-модель ради эмбеддингов).
- Reranking: используйте отдельный reranker.
- Vision: используйте модель, заточенную под изображения.
- Голос: используйте голосовую модель для транскрипции и синтеза.
- Код: используйте code-специализированную модель для задач с кодом.
Специализированные модели обычно быстрее, дешевле и качественнее на своих задачах, чем универсал, пытающийся делать то же самое.
Паттерн 5: маршрутизация по провайдерам
Использовать модели нескольких провайдеров для отказоустойчивости и ценового рычага.
providers = ["openai", "anthropic", "google"]
preferred = "anthropic" # primary
fallback = "openai" # fallback
def call_with_failover(request):
try:
return call(preferred, request)
except (RateLimit, ProviderError):
return call(fallback, request)Это даёт устойчивость к падению отдельного провайдера и к rate-лимитам. И позволяет реагировать на изменения цен: провайдер срезал прайс — переводите туда больше трафика.
Реалистичный пример: AI-поддержка клиентов
Чтобы было предметнее — как AI-поддержка клиентов может использовать оркестрацию нескольких моделей.
На каждый тикет в системе следующие шаги:
Шаг 1: классификация намерения. Про что вообще спрашивает клиент? (5–10 категорий.)
Маршрутизация: GPT-5 Nano. Простая классификация. Стоимость: ~€0.0001 за тикет.
Шаг 2: определение срочности и тональности. Раздражён ли клиент? Срочно ли это?
Маршрутизация: GPT-5 Nano. Ещё одна простая классификация. Стоимость: ~€0.0001 за тикет.
Шаг 3: извлечение релевантных знаний.
Маршрутизация: embedding-модель + reranking-модель. Специализированные инструменты под специализированную задачу. Стоимость: ~€0.0002 за тикет.
Шаг 4: может ли AI ответить сам или нужна эскалация на человека.
Маршрутизация: Claude 4 Haiku. Чуть более тонкая классификация с учётом подтянутого контекста. Стоимость: ~€0.001 за тикет.
Шаг 5 (если AI отвечает): сгенерировать ответ для клиента.
Маршрутизация: Claude 4 Sonnet. Качество тут важно — это то, что увидит клиент. Стоимость: ~€0.02 за тикет.
Шаг 6 (если AI не отвечает): сгенерировать саммари для оператора.
Маршрутизация: GPT-5 Mini. Полезный конспект, не для клиента. Стоимость: ~€0.005 за тикет.
Шаг 7: проверка качества. Соответствует ли ответ нашим стандартам?
Маршрутизация: Claude 4 Haiku как быстрый судья. Стоимость: ~€0.001 за тикет.
Для тикетов, на которые отвечает AI (допустим, 70%):
- Итоговая стоимость тикета: ~€0.024
Для тикетов, эскалированных на человека (30%):
- Итоговая стоимость тикета: ~€0.008
Средневзвешенная: ~€0.019 за тикет.
Если бы команда гоняла на всё флагманскую reasoning-модель: ~€0.30 за тикет. Подход с несколькими моделями экономит 94%.
При 1000 тикетов в день это €280/день → €100 000/год экономии.
Логика маршрутизации
Несколько подходов к реализации.
Подход 1: хардкод по типу задачи
Самый простой. Вы знаете, какую задачу вызываете, — выбираете модель.
def classify(text):
return openai_client.chat.completions.create(
model="gpt-5-nano",
messages=[{"role": "user", "content": f"Classify: {text}"}],
)
def respond(context, query):
return claude_client.messages.create(
model="claude-4-sonnet",
messages=[{"role": "user", "content": f"Context: {context}\n\nQuery: {query}"}]
)Плюсы: прозрачно, легко отладить, легко менять. Минусы: не адаптируется к сложности конкретного запроса внутри одного типа задачи.
Подход 2: модель-маршрутизатор
Небольшая модель классифицирует каждый запрос и направляет его.
ROUTER_PROMPT = """
Classify this request as: trivial, moderate, or complex.
Output one word.
Request: {request}
"""
def route(request):
classification = small_model_call(ROUTER_PROMPT.format(request=request))
return MODEL_BY_COMPLEXITY[classification]Плюсы: учитывает сложность внутри категории. Минусы: добавляет задержку (вызов роутера), добавляет точку отказа, требует тюнинга.
Подход 3: маршрутизация по эмбеддингам
Для запросов, попадающих в известные паттерны, используется похожесть эмбеддингов на прошлые примеры.
def route(request):
embedding = embed(request)
closest = find_nearest_example(embedding)
return closest.suggested_modelПлюсы: быстро (просто векторный лукап), умнеет с накоплением данных. Минусы: нужно собрать размеченный набор примеров.
Подход 4: каскад
Сначала дёшево; эскалация при необходимости.
def cascade(request):
cheap = small_model_call(request)
if validates(cheap):
return cheap
return flagship_call(request)Плюсы: адаптивно, низкая средняя цена. Минусы: медленно для случаев, где нужна эскалация (два вызова), требует надёжной валидации.
На практике многие продакшен-системы используют гибрид: хардкод-маршрутизация для основных типов задач плюс каскады для отдельных подтипов с высокой вариативностью.
Подводные камни
Несколько ошибок, которых стоит избегать.
Камень 1: оптимизировать стоимость ценой качества
Легко перевести всё на маленькие модели и наблюдать, как падают расходы. Сложнее заметить, что качество тоже упало. Любые изменения маршрутизации всегда сопровождайте мониторингом качества.
Полезная дисциплина: переводя задачу на более дешёвую модель, гоняйте A/B-тест неделю с метриками качества. Не катите изменение без доказательств, что качество удержалось.
Камень 2: переусложнить роутер
Маршрутизатор, обслуживающий 100 типов задач со сложной логикой, поддерживать труднее, чем то, что он заменяет. Начинайте с простого. Если простая версия даёт 80% выгоды сложной, катите простую.
Типичный паттерн: 50-строчный роутер на 5–10 типов задач покрывает 90% выгоды. Дальше отдача падает.
Камень 3: игнорировать задержку
Более дешёвые модели обычно ещё и быстрее — и это хорошо. Но если у вас каскад (сначала дешёвая, потом флагман), для тяжёлых случаев задержка удваивается. Для пользовательских сценариев это важно.
Полезный паттерн: для пользовательских сценариев, чувствительных к задержке, по умолчанию используйте флагман и смиритесь с ценой. Каскады оставьте на пакетную и асинхронную обработку.
Камень 4: не обрабатывать сбои провайдеров
Когда вы зависите от нескольких моделей, и способов упасть тоже становится больше. Флагман лёг, сработал rate-лимит, протух API-ключ. Логика маршрутизации должна иметь фолбэки.
Минимум: у каждой «основной» модели должна быть «запасная» от другого провайдера. Даже если в фолбэке качество падает, система остаётся живой.
Камень 5: не мерить качество отдельно по маршрутам
Нужно понимать, какой маршрут работает хорошо, а какой нет. А значит — оценка, желательно автоматизированная.
Полезная конфигурация: на каждый продакшен-вызов логируется использованная модель, запрос, ответ и (где возможно) сигнал качества (фидбек пользователя, downstream-метрики, автоматическая оценка). Метрики сводятся по маршрутам. Так вы ловите деградацию до того, как начнут жаловаться пользователи.
Куда это всё движется
Несколько трендов, которых стоит ожидать.
Авто-маршрутизация как сервис. Инструменты вроде OpenRouter, Helicone, Portkey и других всё активнее предлагают «умную маршрутизацию» — модель за вас выбирают по настраиваемым правилам. Ожидается серьёзное созревание этой ниши.
Углубляющаяся специализация моделей. Модели под код, под математику, под конкретные домены. В маршрутизации будет всё больше специализированных моделей.
Цены продолжают падать. Модели 2026 года в 10 раз дешевле, чем эквивалентные по качеству в 2024-м. К 2028 году ожидайте ещё минус десять раз. Экономика оркестрации нескольких моделей будет только улучшаться.
On-device-уровни. Телефоны и ноутбуки с локальным AI предложат «бесплатный» уровень для части запросов. В логике маршрутизации всё чаще будет появляться «по возможности оставаться на устройстве».
Стандартизированные API между провайдерами. OpenAI-совместимые API (уже широко приняты) делают смену провайдера всё более тривиальной. Стандартизация будет продолжаться, упрощая мультипровайдерные стратегии.
Чек-лист для старта
Если вы строите систему с несколькими моделями с нуля или мигрируете с одной:
- Соберите карту задач. Какие типы вызовов LLM делает ваше приложение? Примерно как часто? Примерно насколько дорого?
- Категоризируйте по сложности. Для каждого типа задачи решите: тривиально, средне или сложно. Сопоставьте с уровнем моделей.
- Сделайте роутер. Начните с хардкод-маршрутизации по типу задачи. Не переусложняйте.
- Добавьте фолбэки. У каждой основной модели должен быть запасной вариант (другой провайдер).
- Замеряйте качество по маршрутам. Заведите логирование и базовую оценку. Нужно понимать, держится ли качество.
- Итерируйте. Переводите задачи на более дешёвые модели, где качество держится. Возвращайте обратно туда, где ломается. Подстраивайте со временем.
- Не прекращайте тюнить. Модели меняются. Появляются новые. Цены сдвигаются. Конфигурация маршрутизации, оптимальная в мае 2026, в ноябре 2026 может оказаться неоптимальной.
Главное
Оркестрация нескольких моделей — одно из изменений с самой высокой отдачей, которые можно внести в продакшен-систему с AI. Сделанная грамотно, она режет затраты на 60–90% и часто параллельно поднимает качество (потому что каждая задача обслуживается подходящей моделью).
Технический порог низкий — базовая логика маршрутизации укладывается в несколько десятков строк кода. Дисциплинарный порог выше: нужно постоянно мерить качество, чтобы убеждаться, что решения по маршрутизации не подводят.
Перестаньте гонять одну модель на всё. Соберите карту задач. Подберите модель под каждую. Замеряйте результат. Итерируйте. Экономия настоящая, а прирост качества обычно идёт бонусом.