altrouter.ai
← Блог

Не одна модель, а маршрут: как раздавать задачи разным моделям

· 6 минут чтения

Коротко

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

Одна модель на весь продукт означает одно из двух: вы платите за рассуждения там, где их не нужно, или экономите там, где они нужны.

Рабочих схем три, и они складываются друг с другом:

  1. Маршрут по типу задачи — самая простая и самая выгодная.
  2. Каскад — дешёвая модель делает первый проход, дорогая подключается на неуверенных случаях.
  3. Фолбэк — переключение при отказе провайдера, чтобы пользователь не увидел ошибку.

Ниже — как каждая устроена, сколько экономит и что при этом ломается.

Почему «лучшая модель» — неправильный вопрос

Разница между моделями неравномерна по типам задач.

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

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

Отсюда практический принцип: чем формальнее задача, тем легче модель. Не «возьму лучшую на всякий случай», а «возьму достаточную».

Схема 1: маршрут по типу задачи

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

ROUTES = {
    "classify":  "claude-haiku-4-5",   # формально, объём
    "extract":   "gpt-5.6-mini",       # структура из текста
    "chat":      "claude-sonnet-5",    # диалог с пользователем
    "reasoning": "claude-opus-4-8",    # разбор сложного
    "style":     "claude-fable-5",     # тексты, где важен слог
}

def ask(kind, messages, **kw):
    return client.chat.completions.create(
        model=ROUTES[kind], messages=messages, **kw
    )

Работает это потому, что смена модели у OpenAI-совместимого API — это смена одной строки. Один ключ, один баланс, разные модели.

Что даёт: обычно 40–70% экономии против «всё на флагмане» без потери качества там, где оно важно.

Схема 2: каскад

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

Считаем на реальной задаче: классификация 100 000 обращений, 500 входных и 50 выходных токенов на каждое.

ПодходСтоимость
Всё на Claude Opus 4.8$337.50
Всё на Claude Haiku 4.5$58.60
Каскад: Haiku + Opus на 15% случаев$109.23

Каскад дешевле сплошного Opus на 68%, а по качеству близок к нему: сложные случаи всё равно доходят до сильной модели.

Ключевой вопрос — как понять, что модель не уверена. Три работающих признака:

  • Модель сама говорит. Попросите вернуть поле уверенности вместе с ответом и задайте порог.
  • Ответ не проходит валидацию. Не тот формат, категория вне списка, поле пустое — отправляйте на вторую модель.
  • Внешняя проверка. Для кода — тесты, для извлечения — сверка с источником.

Порог подбирается замером, а не на глаз. Возьмите пару сотен размеченных примеров, прогоните с разными порогами и посмотрите, где кривая «качество против денег» перестаёт расти.

Схема 3: фолбэк

Другая задача: не сэкономить, а не упасть.

Модели у вендоров бывают перегружены — Anthropic в пиковые часы отдаёт 529, и это нормальная ситуация, а не авария. Вопрос в том, что увидит ваш пользователь.

CHAIN = ["claude-sonnet-5", "gpt-5.6", "gemini-3-pro"]

def ask_resilient(messages, **kw):
    for model in CHAIN:
        try:
            return client.chat.completions.create(
                model=model, messages=messages, **kw
            )
        except Exception as e:
            if getattr(e, "status_code", None) in (429, 500, 529):
                continue
            raise
    raise RuntimeError("все модели в цепочке недоступны")

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

🔴 Важная оговорка про деньги: резервный провайдер может стоить не столько же, сколько основной. Если у вас жёсткий бюджет, фолбэк надо считать отдельно, а не считать бесплатной страховкой.

Что ломается при маршрутизации

Четыре вещи, о которые спотыкаются все.

Промпт не переносится один в один

Формулировка, отлаженная на одной модели, на другой даёт другой результат. Особенно это заметно на строгости следования формату: одна модель вернёт чистый JSON, другая обернёт его в объяснение.

Лечится просьбой о структурированном ответе и валидацией на вашей стороне — а не надеждой.

Разный формат ответа между моделями

Если у вас каскад или фолбэк, обе модели должны отдавать одинаково разбираемый ответ. Проверяйте это на этапе выбора цепочки, а не в проде.

Незаметный рост стоимости

Маршрутизация делает счёт менее предсказуемым: доля дорогих вызовов плавает вместе с характером входящих данных. Смотрите в логи регулярно, а не один раз при запуске.

Слишком много моделей

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

С чего начать

Порядок, который работает:

  1. Разметьте свои задачи по типам. Обычно их три-четыре, а не двадцать.
  2. Возьмите дешёвую модель и замерьте качество на сотне реальных примеров. Часто оказывается, что её достаточно.
  3. Оставьте сильную там, где дешёвая проседает. Не наоборот — не начинайте с флагмана, экономя потом.
  4. Добавьте фолбэк на самый важный для пользователя сценарий.
  5. Смотрите в логи через неделю. Соотношение вызовов почти никогда не совпадает с ожиданием.

Все 44 модели с ценами — на витрине. Как снижать расход внутри выбранной модели — десять приёмов с расчётами, а про выбор под конкретно кодовые задачи — здесь.

FAQ

Какая нейросеть лучше для всех задач?

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

Что такое каскад моделей?

Схема, при которой дешёвая модель обрабатывает все запросы, а дорогая подключается только там, где первая не уверена. На классификации 100 000 обращений каскад обходится примерно в $109 против $337 при сплошной работе флагмана — экономия 68% при сопоставимом качестве.

Как понять, что модель не уверена в ответе?

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

Сколько моделей стоит держать в продукте?

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

Можно ли переключаться между моделями без переписывания кода?

Да, если сервис отдаёт OpenAI-совместимый API: меняется одно поле model в запросе, ключ и адрес остаются прежними. Но промпт при переезде обычно требует правки — модели по-разному строго следуют формату ответа.

Фолбэк на другую модель — это бесплатная страховка?

Нет. Во-первых, резервная модель может стоить дороже основной, и при жёстком бюджете это надо считать. Во-вторых, ответы разных моделей отличаются по стилю и формату, поэтому цепочку нужно проверять целиком, а не только на доступность.