Сокращение затрат на API LLM вдвое: руководство по маршрутизации моделей для производственных нагрузок в 2026 году

Проблема со стоимостью, спрятанная в вашем счете

Посмотрите на параметр модели в вашем продакшн-коде. У большинства команд, чья нагрузка на LLM перешла из прототипа в реальный трафик, этот параметр однажды устанавливается (обычно на самую сильную модель, доступную на момент релиза) и больше не пересматривается. Каждый запрос, независимо от сложности, отправляется в одну и ту же модель. Именно здесь и прячется тихий перерасход.

В любом нетривиальном продакшн-ворклоаде запросы неодинаково сложны. Помощник службы поддержки может получать 80% запросов как простые лукапы, классификации или короткие фоллоу-апы и 20% — те, что действительно требуют передового уровня рассуждений. Ассистент по коду может обрабатывать стабильный поток мелких рефакторингов и длинный «хвост» архитектурных изменений по нескольким файлам. Контентный пайплайн может выполнять сотни задач по суммаризации на каждый случай, где требуется структурированное творческое письмо. Форма работы неровная, но маршрутизация к модели — нет.

Если сегодня вы прогоняете 100M токенов в месяц на GPT-5.5 и 70% этих запросов столь же хорошо отвечались бы более дешевой моделью, вы платите примерно $600 в месяц за неиспользуемую мощность. На больших объемах этот же паттерн линейно накапливается: на каждые 1B токенов разница между немаршрутизированной и маршрутизированной схемой составляет несколько тысяч долларов в месяц.

Маршрутизация — инженерный ответ на эту асимметрию. Принцип прост: отправляйте каждый запрос в самую дешевую модель, которая способна с ним справиться, и повышайте уровень только при необходимости. Реализации — там, где живут интересные компромиссы, и большинство публикаций описывают их плохо. Этот материал разбирает три паттерна, которые действительно работают в продакшне, экономику, делающую кейс убедительным, режимы отказов, которые подстерегают вас, и план миграции от схемы с одной моделью к маршрутизированной — без переписывания приложения.

Ценообразование в этой статье опирается на сопроводительный материал (сравнение цен на LLM API 2026), который устанавливает тарифы для каждой модели. Везде, где приводится стоимость, она взята из тех данных.

Три паттерна маршрутизации, которые работают в продакшне

Существует три устоявшихся паттерна маршрутизации трафика LLM. Они различаются сложностью реализации, накладными задержками и типами экономии, которые открывают. Большинство продакшн-систем в итоге комбинируют все три; понимание сильных сторон каждого помогает упорядочить работу.

Паттерн 1: Статические правила

Самый простой паттерн. Вы пишете правила, которые направляют запросы в разные модели на основе наблюдаемых свойств запроса: длина ввода, тариф пользователя, тип запроса (если у вас уже есть классификатор), API-эндпоинт или бизнес-логика. Короткие запросы — в дешевую модель; длинные — в более сильную. Пользователи бесплатного тарифа получают более дешевую модель, чем платные. Запросы на генерацию кода — в модель, натренированную на коде; остальные — в универсальную.

Статическая маршрутизация предсказуема, удобна для отладки и практически не добавляет задержки: решение — это несколько строк локального кода. Потолок тоже ниже: вы маршрутизируете по свойствам, видимым до запуска модели, а значит, не можете маршрутизировать по «насколько запрос действительно сложный», потому что пока этого не знаете. Для ворклоадов, где свойства ввода хорошо коррелируют со сложностью (длинные документы обычно сложнее; код обычно отличается от прозы; платные пользователи, как правило, предъявляют более высокий запрос), статические правила позволяют собрать 30–50% доступной экономии при минимальных инженерных усилиях.

Паттерн 2: Каскад

Самый широко применимый паттерн. Вы сначала отправляете запрос в дешевую модель; если ответ проходит порог качества, возвращаете его; если нет — повышаете уровень до более способной модели и используете уже ее ответ. Экономия возникает потому, что по тем запросам, с которыми справляется дешевая модель, вы платите только по ее тарифу.

Отличительная черта каскада — решение о маршрутизации информируется выходом модели, а не только входом: вы позволяете дешевой модели попробовать, а затем оцениваете, достаточно ли хорошо получилось. Оценка может быть реализована по-разному: Confidence-скор от самой модели, валидация структурированного вывода (парсится ли ответ в ожидаемую схему?), self-evaluation промпты (спросить маленькую модель, отвечает ли ответ на вопрос), или сигналы поведения downstream (принял ли пользователь ответ или переформулировал и попробовал снова?).

Каскад — паттерн, который в итоге внедряют большинство продакшн-систем, потому что он извлекает экономию, недоступную статике. Компромисс в том, что на эскалировавших запросах вы платите и за вызов дешевой модели, и за вызов флагмана, так что экономия зависит от доли запросов, которые проходят на дешевом уровне. Этот паттерн мы разбираем подробнее ниже.

Паттерн 3: Маршрутизация на основе классификатора

Самый высокий потолок и максимальные инженерные вложения. Небольшая быстрая модель (часто дообученная версия модели ниже фронтирного уровня или специальный классификатор) смотрит на каждый входящий запрос и предсказывает, какая downstream-модель должна его обработать. Классификатор может решать по типу запроса («похоже на генерацию кода; отправить в модель, натренированную на коде»), оценке сложности («похоже на тяжелый запрос на рассуждение; отправить в GPT-5.5») или по обученной политике маршрутизации, натренированной на историческом трафике и исходах.

Маршрутизация на основе классификатора может превосходить каскад, потому что решение принимается до запуска какой-либо дорогой модели — вы не платите «налог дешевой модели» на запросах, которые все равно потребуют флагмана. Цена — это инженерная работа по построению, обучению и поддержке самого классификатора плюс небольшая задержка на его вызов. Для очень больших объемов эта сделка окупается; для малых — обычно нет.

С чего начать: Статические правила — сначала, если ваш ворклоад имеет очевидные сигналы маршрутизации (длина ввода, тариф пользователя, эндпоинт). Каскад — если таких сигналов нет, или после того, как вы исчерпали статические правила. Маршрутизация на классификаторе — только после внедрения и статических правил, и каскада, и если объем действительно оправдывает затраты. Перепрыгивание прямо к классификатору — классическая ловушка сверхинженерии, о которой большинство команд жалеют.

Что измерить перед началом маршрутизации

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

Минимально полезная инструментация:

• На уровне запроса: используемая модель, число токенов на входе, число токенов на выходе, стоимость (по токенам и тарифу), end-to-end латентность, статус ответа (успех / ошибка / частичный), и метка типа запроса, если есть.
• На уровне диалога или пользователя: длина сессии, число ретраев (сигнал, что пользователь не принял первый ответ), доля фоллоу-апов (сигнал, что ответ потребовал уточнения).
• Отложенный набор для оценки: 100–500 репрезентативных запросов, которые можно прогонять на любой модели, с референсными ответами, которым вы доверяете. Так вы измеряете, дает ли более дешевая модель приемлемое качество на вашем ворклоаде. Без этого каждое решение по маршрутизации — угадывание.

Именно в набор для оценки большинство команд инвестируют недостаточно, а это — самый рычажный элемент инфраструктуры любого проекта по маршрутизации. Легковесные инструменты вроде Promptfoo или Helicone evals позволяют быстро поднять его; для ранних стадий достаточно вручную подобранного набора из 50 запросов с ручной оценкой.

После инструментации прогоните текущий ворклоад как есть минимум неделю, чтобы зафиксировать базу. Форма данных (насколько перекошено распределение длины ввода, какая доля запросов короткие и простые, какая — выглядят сложными) подскажет, с какого паттерна маршрутизации начать.

Каскад: детали и экономика

Каскад заслуживает большего места, поскольку он самый широко применимый и чаще всего внедряется первым или вторым. Математика также делает кейс маршрутизации конкретным.

Рассмотрим репрезентативный продакшн-ворклоад, работающий сегодня на Claude Sonnet 4.6: 100M токенов в месяц, 80% на входе и 20% на выходе, $475 в месяц по прайс-листу. Предположим, мы вводим каскад: запросы сначала идут в Claude Haiku 4.5 и лишь при провале проверки качества эскалируют в Sonnet 4.6. Haiku 4.5 стоит $1.00 за вход и $5.00 за выход за миллион токенов — треть ставки Sonnet.

Экономика зависит от двух параметров: какой процент запросов проходит на уровне Haiku (назовем это долей успеха), и как отличается соотношение вход/выход между успешными и эскалированными запросами. Для простоты предположим одинаковое соотношение и долю успеха 70%, то есть ответ Haiku приемлем в 70% случаев, и 30% эскалируют в Sonnet.

Что это значит. Даже при умеренной доле успеха 70% (когда Haiku дает правильный ответ 7 раз из 10) каскад сокращает счет вдвое. Причина в том, что вызов дешевой модели настолько дешевле вызова флагмана, что платить за обе на 30% эскалировавших запросов все равно куда выгоднее, чем платить за флагман на каждом. Точка безубыточности (где каскад равен по стоимости схеме с одной моделью) — примерно 33% успехов. Ниже — лучше идти напрямую; выше — каскад выигрывает.

Минимально жизнеспособная реализация каскада

Ниже — самый простой вариант паттерна на Python с клиентом, совместимым с OpenAI (работает с любым провайдером, у кого есть совместимый с OpenAI endpoint, включая Claude через слой совместимости Anthropic, Gemini и унифицированный endpoint CometAPI). Структура намеренно минимальна; в продакшне добавьте наблюдаемость, обработку ошибок и более продвинутые проверки качества.

from openai import OpenAI
import json

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.cometapi.com/v1",  # or your provider of choice
)

CHEAP_MODEL = "claude-haiku-4-5"
FLAGSHIP_MODEL = "claude-sonnet-4-6"


def cascade(messages, output_schema=None):
    """
    Run a query through a cascade.
    Returns (response, model_used, escalated).
    """

    # Step 1: try the cheap model
    cheap_response = client.chat.completions.create(
        model=CHEAP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    cheap_text = cheap_response.choices[0].message.content

    # Step 2: judge whether the cheap response is good enough
    if is_acceptable(cheap_text, output_schema):
        return cheap_text, CHEAP_MODEL, False

    # Step 3: escalate to the flagship
    flagship_response = client.chat.completions.create(
        model=FLAGSHIP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    flagship_text = flagship_response.choices[0].message.content

    return flagship_text, FLAGSHIP_MODEL, True


def is_acceptable(response_text, output_schema=None):
    """
    Quality gate.
    Returns True if the cheap model's output is good enough.
    """

    if not response_text or len(response_text.strip()) < 10:
        return False

    if output_schema:
        # Structured output: it has to parse against the schema
        try:
            parsed = json.loads(response_text)
            return validate_schema(parsed, output_schema)

        except (json.JSONDecodeError, ValueError):
            return False

    # For free-form responses, plug in your own quality signal:
    # - confidence score from the model
    # - self-evaluation prompt to a small model
    # - rules-based checks (length, format, refusal patterns)

    return True

Это отправная точка, а не готовая реализация. Три вещи, которые вы добавите в продакшне:

• Реальный гейт качества. Функция is_acceptable выше намеренно минимальна. На практике гейт — самый важный элемент каскада: слишком мягкий — отгружаете низкое качество; слишком строгий — эскалируете слишком часто и теряете экономию. В продакшне обычно комбинируют валидацию структурированного вывода, детектирование отказов (когда дешевая модель говорит «не могу ответить») и самооценку маленькой моделью, которой промптом задается критерий проверки ответа.
• Наблюдаемость на уровне запроса. Логируйте, какая модель использована, была ли эскалация, латентность на каждом уровне и стоимость. Это покажет через неделю работы каскада, совпадает ли доля успеха с вашим предположением.
• Канареечный путь для оценки. Отправляйте небольшой процент трафика (скажем, 5%) через флагман даже тогда, когда каскад прошел на дешевом уровне. Сравнивайте ответы по отложенной задаче оценивания. Так вы поймаете скрытое ухудшение качества; см. следующий раздел.

Где маршрутизация ломается

Экономия выше — реальна, но это оптимистичный сценарий. Есть три режима отказа, которые подстерегают команды; честное их называние отличает маршрутизацию, которая приносит накопленный эффект, от той, что тихо ухудшает продукт.

Накладная задержка на эскалированных запросах

Когда запрос эскалирует, вы платите за вызов дешевой модели до начала вызова флагмана. Если дешевая модель отвечает за 800 мс, а флагман — за 1.5 с, эскалированный запрос займет 2.3 с end-to-end. Для чувствительных к задержке ворклоадов это важно. Митигации: выбирать быструю дешевую модель (Haiku 4.5 и Gemini 3 Flash для этого и сделаны), ставить агрессивные таймауты на вызов дешевой модели и рассмотреть параллельные вызовы для запросов, которые, вероятно, эскалируют. Некоторые команды принимают задержку из-за большой экономии; другие добавляют статические правила, чтобы не пропускать очевидно сложные запросы через каскад.

Скрытая деградация качества

Самый коварный режим. Дешевая модель дает ответы, которые проходят ваш гейт качества, но тонко хуже флагманских: чуть менее точные, чуть менее полезные, чуть чаще упускают крайние случаи. Пользователи не жалуются сразу; наблюдаемые метрики (латентность, доля ошибок, доля прохождений гейта) выглядят нормально; но downstream-метрики (ретеншн, конверсия, эскалации в поддержку) уползают. Пока вы замечаете, вы уже отгрузили недели деградации.

Защита — упомянутый канареечный путь: отложенный процент трафика, который проходит через флагман параллельно каскаду, и оба ответа оцениваются по рубрике. Оценку может делать сама модель (LLM-as-judge) или выборочный ручной обзор. Смысл — поддерживать непрерывный сигнал качества, независимый от гейта каскада, чтобы деградация проявлялась как дрейф этого сигнала, а не как downstream-сюрприз.

Стоимость сложности в коде и наблюдаемости

Каждая дополнительная модель в графе маршрутизации — это еще одна модель для оценки, мониторинга и обновления при выпуске новых версий провайдером. Двухуровневый каскад управляем; роутер на пяти моделях с классификатором и отдельными путями для кода, RAG, чата, агентов и краевых кейсов существенно сложнее схемы с одной моделью. Эта сложность оправдана при достаточно больших объемах; ниже порога потраченные инженерные часы могут превысить экономию. Будьте честны насчет вашего порога по объему.

Как помогают агрегаторы (и где — нет)

Агрегаторы LLM (сервисы, предоставляющие доступ к нескольким моделям через единый совместимый с OpenAI API) взаимодействуют с маршрутизацией двумя различными способами. Оба стоит понимать, потому что ответ на вопрос «нужен ли мне агрегатор в слое маршрутизации?» зависит от того, какой из аспектов для вас важнее.

Настоящая помощь: убрать налог на интеграцию

Построить каскад или роутер на классификаторе на прямых API провайдеров — это управлять несколькими SDK, несколькими учетными данными, несколькими биллингами и набором провайдер-специфичных особенностей (таймауты, форматы ошибок, семантика rate-limit). Для мультимодельной маршрутизации это значимо. Агрегатор вроде CometAPI дает все модели через один совместимый с OpenAI endpoint, а значит, изменение маршрутизации — это просто замена параметра модели, без переключения провайдеров, без отдельных ключей, без отдельного слоя наблюдаемости. Для команд, у которых главный барьер — интеграция, а не оценка качества, это решающе.

Осторожность: встроенные слои маршрутизации

Некоторые агрегаторы предлагают «умную маршрутизацию» или «оптимизатор моделей», который сам выбирает модель по запросу. Это может быть полезно на этапе прототипа, но обычно неверный дефолт для продакшна. Причина: решение о маршрутизации — одно из самых зависимых от ворклоада: что считать «достаточно сложным для эскалации» зависит от ваших критериев оценки, бюджетов по латентности, качества и стоимости. Универсальный роутер этого не знает. Большинству продакшн-систем лучше подходит тонкий, прозрачный агрегатор (который дает те же модели, что и напрямую, с одними учетными данными и одним биллингом) плюс собственная логика маршрутизации поверх, чем черный ящик, который нельзя настроить.

План миграции

Безопасный пошаговый путь от продакшн-ворклоада с одной моделью к маршрутизированному. Принцип — вносить изменения, которые по одному можно откатить, и измерять эффект каждого шага до следующего.

• Проинструментируйте текущий ворклоад. Логируйте каждый запрос: модель, токены на входе/выходе, стоимость, латентность и метку типа запроса. Запустите минимум на неделю, чтобы зафиксировать базу. Без этого дальнейшие шаги — угадывание.
• Соберите набор для оценки. Кураторский набор из 100–500 репрезентативных запросов с референсными ответами. Это отложенный набор, которым вы будете сравнивать каскад с базовой схемой на каждом шаге.
• Выделите самый высокообъемный тип запросов. По данным инструментации найдите категорию с наибольшим трафиком. Именно там вы запустите пилот каскада. Это не обязательно самая простая категория — важен объем, потому что там концентрируется экономия.
• Соберите прототип каскада для этой одной категории. Два уровня: сначала дешевая модель, затем флагман при провале гейта. Прогоните на наборе для оценки. Сравните стоимость и качество с базой. Если качество сохраняется и стоимость падает — вперед; если качество падает — ужесточите гейт и повторите.
• Выкатите за процентом трафика. Начните с 5–10% продакшн-трафика выбранного типа. Запустите минимум на неделю. Мониторьте долю эскалаций, стоимость на запрос, латентность на каждом уровне и сравнение качества по канареечному пути. Если метрики совпадают с прогнозом прототипа — расширяйте на 25%, затем 50%, затем 100%.
• Повторите для следующей категории. Когда первая категория полностью мигрирована и экономия зафиксирована, переходите к следующей по объему. Каждый каскад — отдельное решение; не предполагайте, что паттерн, сработавший для одной категории, подойдет другой.
• Добавьте постоянный канареечный контроль качества. Когда несколько категорий работают на каскадах, сделайте отложенный канареечный путь постоянным, с 5% трафика через флагман для оценивания. Это раннее предупреждение о скрытой деградации и то, что поддерживает доверие к слою маршрутизации при обновлениях моделей.

Когда маршрутизация не оправдана

Честно о границах. Есть ворклоады, где инженерные вложения в маршрутизацию не окупаются; важно распознать их заранее:

• Нагрузки с одной моделью, где одна модель действительно лучшая для всего. Если ваш набор для оценки показывает значимое падение качества на дешевом уровне по всему ворклоаду, у каскада нет пространства для экономии. Например, генерация кода, ограниченная способностью к рассуждению: Haiku слишком часто провалит гейт, и каскад не окупится.
• Очень низкие объемы. Ниже примерно $200/месяц на LLM инженерные часы на построение и поддержку маршрутизации обычно превышают экономию. Порог специфичен для ворклоада, но реален. Будьте честны, достаточно ли высок ваш расход.
• Регулируемые среды, где важен vendor-of-record. Если ваша комплаенс-позиция требует, чтобы весь продакшн-трафик шел через конкретные отношения с одним провайдером, мультимодельная маршрутизация усложняет это. Возможно, есть варианты маршрутизации у одного провайдера (Sonnet → Opus у Anthropic; GPT-5 nano → GPT-5.5 у OpenAI), но кросс-провайдерная маршрутизация обосновывается сложнее.

Честная рамка: маршрутизация окупается, когда у вас высокие объемы, запросы неодинаково сложны и есть инфраструктура оценивания, чтобы знать, когда каскад дает приемлемое качество. Большинство продакшн-ворклоадов на сколько-нибудь значимом масштабе соответствуют этому описанию; некоторые — нет и быстрее двигаются с одной моделью. Оба решения защитимы.

Куда идти дальше: Если вы еще не разобрали прайс-лист по моделям, на который опирается эта статья, сопроводительный материал The 2026 LLM API Pricing Comparison: GPT-5.5, Claude Sonnet 4.6, Gemini 3.5 Flash and DeepSeek V4 — фундамент. Приведенные там цены делают экономику в этом гайде конкретной для вашего ворклоада.