Оркестрация нескольких моделей: маршрутизация по стоимости, задержке и качеству

Самая дорогая ошибка, которую мы видим в продакшен-системах с 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 (уже широко приняты) делают смену провайдера всё более тривиальной. Стандартизация будет продолжаться, упрощая мультипровайдерные стратегии.

Чек-лист для старта

Если вы строите систему с несколькими моделями с нуля или мигрируете с одной:

1. Соберите карту задач. Какие типы вызовов LLM делает ваше приложение? Примерно как часто? Примерно насколько дорого?

1. Категоризируйте по сложности. Для каждого типа задачи решите: тривиально, средне или сложно. Сопоставьте с уровнем моделей.

1. Сделайте роутер. Начните с хардкод-маршрутизации по типу задачи. Не переусложняйте.

1. Добавьте фолбэки. У каждой основной модели должен быть запасной вариант (другой провайдер).

1. Замеряйте качество по маршрутам. Заведите логирование и базовую оценку. Нужно понимать, держится ли качество.

1. Итерируйте. Переводите задачи на более дешёвые модели, где качество держится. Возвращайте обратно туда, где ломается. Подстраивайте со временем.

1. Не прекращайте тюнить. Модели меняются. Появляются новые. Цены сдвигаются. Конфигурация маршрутизации, оптимальная в мае 2026, в ноябре 2026 может оказаться неоптимальной.

Главное

Оркестрация нескольких моделей — одно из изменений с самой высокой отдачей, которые можно внести в продакшен-систему с AI. Сделанная грамотно, она режет затраты на 60–90% и часто параллельно поднимает качество (потому что каждая задача обслуживается подходящей моделью).

Технический порог низкий — базовая логика маршрутизации укладывается в несколько десятков строк кода. Дисциплинарный порог выше: нужно постоянно мерить качество, чтобы убеждаться, что решения по маршрутизации не подводят.

Перестаньте гонять одну модель на всё. Соберите карту задач. Подберите модель под каждую. Замеряйте результат. Итерируйте. Экономия настоящая, а прирост качества обычно идёт бонусом.