Маршрутизация LLM: как выбирать модели и проверять качество

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

Описанное ниже поведение продуктов сверено с актуальной документацией 21 октября 2026 года. Нагрузка приложения поддержки и расчёты приведены для иллюстрации: это не замеры работающей системы и не заявления поставщиков об экономии.

Как работает маршрутизация LLM

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

Представьте диспетчера, который распределяет обращения между сотрудниками поддержки. Обычный поиск сведений достаётся тому, кто быстро с ним справится, а спорный случай — специалисту. Диспетчеру также нужно правило передачи на дальнейшее рассмотрение задач, которые никто из исполнителей не вправе завершить самостоятельно.

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

Выбор модели, выбор провайдера и резервное переключение решают разные задачи. Маршрутизация между моделями определяет, какая модель отвечает. Маршрутизация между провайдерами определяет, где запустить уже выбранную модель, например у какого поставщика хостинга. Резервное переключение, или fallback, определяет, что попробовать после неудачной попытки. Шлюз — слой доступа между приложением и API моделей — может поддерживать все эти механизмы. Но само по себе добавление шлюза не даёт механизма выбора модели с учётом качества ответов.

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

Три подхода к маршрутизации между моделями

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

Правила, заданные в приложении

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

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

Автоматическая маршрутизация в шлюзе

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

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

Как обучается роутер LLM

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

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

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

Разбираем правила маршрутизации для приложения поддержки

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

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

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

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

Учитывайте вызовы при передаче сложных случаев

Допустим, условный пакет содержит 1,000 запросов. По вашим правилам 700 направляются малой модели, а 300 — сразу флагманской. Из первоначальных вызовов малой модели 70 не проходят проверку и повторно выполняются на флагманской.

Теперь вы оплачиваете 700 вызовов малой модели и 370 вызовов флагманской, а также маршрутизацию и проверку. Получается 1,070 вызовов отвечающих моделей, а не 1,000. Повторная попытка — это дополнительная работа, даже если пользователь видит только окончательный ответ.

Обозначим через r среднюю стоимость маршрутизации одного исходного запроса, через s — среднюю стоимость вызова малой модели, через f — среднюю стоимость вызова флагманской, а через g — дополнительные расходы на шлюз или проверку всего пакета. В этом упрощённом примере предположим, что средняя стоимость флагманского вызова одинакова в базовом варианте, при прямом обращении и при передаче после неудачной попытки:

Стоимость с маршрутизацией = 1,000r + 700s + 370f + g

Базовый вариант: всё на флагманской модели = 1,000f

Маршрутизация дешевле только при 700(f − s) > 70f + 1,000r + g. Левая часть — экономия на первоначальных ответах, порученных малой модели; правая — дополнительные повторные вызовы флагманской модели и накладные расходы.

Подставьте стоимость вызовов выбранных моделей по их тарифам: стоимость вызова = (некэшированные входные токены × тариф на вход + кэшированные входные токены × тариф на кэш + оплачиваемые выходные токены × тариф на выход) / 1,000,000, если тарифы указаны за миллион токенов. Отдельно прибавьте плату за инструменты и запросы, если она взимается.

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

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

Что умеют решения для маршрутизации по документации

Прежде чем подключать эндпоинт маршрутизации, разберитесь, как он выбирает модель. Эти продукты принимают разные решения; общее слово «роутер» не делает их поведение по умолчанию одинаковым.

OpenRouter: Auto Router с учётом типа задачи

OpenRouter — управляемый шлюз к нескольким провайдерам моделей — предоставляет Auto Router через openrouter/auto. В актуальной документации описана классификация задачи с последующим ранжированием моделей по совокупным расходам пользователей на задачи этого типа за скользящее 7-дневное окно, а затем фильтрация по ценовому диапазону и допустимости выбора. Это агрегированный сигнал использования, а не ваши критерии качества поддержки. Документация Auto Router.

Параметр cost_tier принимает значения low, medium, high, xhigh и max; поведение по умолчанию примерно соответствует low. Уровень задаёт диапазон, а не жёсткий лимит расходов. Ограничивайте выбор через allowed_models и excluded_models и записывайте поле model из ответа. Привязка выбора к беседе может сохранять выбранную модель, но не гарантирует её неизменность.

Если ключ API задан в переменной окружения, следующий пример отправит минимальный запрос с маршрутизацией:

curl --fail-with-body https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/auto",
    "messages": [{"role": "user", "content": "Rewrite this status politely: Your parcel is in transit."}],
    "plugins": [{"id": "auto-router", "cost_tier": "low"}]
  }'

Для оценки ограничьте набор моделей. Иначе изменения в этом наборе затруднят интерпретацию вчерашних результатов проверки качества.

LiteLLM: маршрутизация между развёртываниями и Auto Router — разные механизмы

LiteLLM — настраиваемый шлюз для LLM. Его документация описывает стратегии маршрутизации между развёртываниями, включая взвешенный выбор, выбор наименее загруженного варианта, а также выбор по задержке и стоимости. Стратегия по умолчанию simple-shuffle не классифицирует сложность обращений в поддержку. Документация роутера.

В документации отдельного механизма Auto Router описаны классификаторы на основе эвристик, LLM, правил по ключевым словам и пользовательских плагинов. Уровни SIMPLE, MEDIUM, COMPLEX и REASONING сопоставляются с настроенными моделями или пулами. В панели управления документация предлагает путь Models + Endpoints → Add Model → Auto Router, затем настройку и Test Routing. Документация Auto Router.

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

Vercel AI Gateway: выбор провайдера и явные настройки маршрутизации

Vercel AI Gateway — управляемый слой доступа к API моделей. По умолчанию он выбирает провайдеров с учётом недавней доступности и задержки. Настройки провайдеров управляют их порядком и фильтрацией; резервные модели, заданные строковыми идентификаторами, вызываются, если основная модель выдаёт ошибку или недоступна. Это полезные механизмы надёжности. Сами по себе они не решают, нужна ли обращению в поддержку флагманская модель. Документация по выбору провайдера и резервному переключению.

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

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

Microsoft Foundry: обученный роутер под управлением провайдера

Роутер моделей Microsoft Foundry — обученный механизм выбора модели, доступный как развёртывание. Microsoft описывает выбор с учётом сложности, потребности в рассуждениях, типа задачи и других признаков. Доступны режимы Balanced, Quality и Cost, а также ограничение набора моделей. Принципы работы роутера моделей.

Это подходит приложению, которое уже использует Foundry и хочет поручить сервису выбор среди допустимых моделей. Существенное ограничение связано с составом этого набора: доступность зависит от региона и прав доступа, а документация Microsoft предупреждает, что минимальное контекстное окно среди входящих в набор моделей ограничивает объём данных, который роутер может надёжно принять. Оставьте в наборе только модели, соответствующие вашим требованиям к входным данным.

Название режима Quality не заменяет оценку на ваших задачах. Проверьте выбранный набор на реальной длине переписок, с вашими инструментами и критериями приёмки.

Как выбрать роутер моделей ИИ

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

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

Как оценить роутер на тестовой выборке

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

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

Набор метрик должен делать дорогостоящие ошибки заметными:

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

До теста определите допустимую некритическую разницу в качестве и расследуйте каждое новое критическое ухудшение. Используйте доверительные интервалы, подходящие для парной выборки. Если неопределённость всё ещё допускает неприемлемое снижение качества, соберите больше данных, прежде чем объявлять результаты равноценными.

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

Какие обещания о маршрутизации моделей преувеличены

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

Успешный ответ API тоже мало говорит о качестве содержания. Резервное переключение при ошибке поможет, если эндпоинт недоступен, но не обнаружит выдуманное правило в гладко написанном ответе. Чтобы передавать запрос дальше из-за недостаточного качества, нужна отдельная проверка, у которой есть собственная частота ошибок и стоимость.

Оценки сложности требуют такой же проверки. Уверенность классификатора не равна автоматически вероятности того, что выбранная модель ответит верно. Калибруйте любой порог по наблюдаемым результатам задач. Не позволяйте пользовательскому тексту вроде «это легко» отменять ограничения полномочий приложения или допустимого набора моделей.

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

Кому пора внедрять роутер, кому стоит подождать и с чего начать

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

Командам эксплуатации нужны доказательства на уровне всего процесса. Снижения расходов на инференс недостаточно, если растёт число повторно открытых обращений, объём ручной проверки или время решения. Отслеживайте эти результаты наряду с оценкой на тестовой выборке.

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

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

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

Частые вопросы о маршрутизации моделей

Подпишитесь на рассылку, чтобы получать практические руководства по разработке и оценке приложений с ИИ.