TL;DR
Динамический роутер (сервис, который сам выбирает модель под каждый запрос: простое отправляет дешёвой, сложное дорогой) в проверке проиграл простой схеме: две хорошо выбранные модели и «подбрасывание монетки» в нужной пропорции при той же цене. Эта схема — «дешёвая, но почти топовая модель» плюс «самая сильная». Доля запросов к каждой задаёт итоговую цену и качество.
Роутеры не делают того, что обещают. Они почти не отличают сложный запрос от простого. Они чаще отправляют сильной модели короткие запросы, потому что это дешевле. Они часто привязывают тему запроса к одной модели: «вся математика — сюда, весь код — туда». Кроме того, они раскидывают запросы по десяткам моделей, из которых большинство не выгодно ни по цене, ни по качеству. В итоге часть роутеров уступает случайному выбору больше чем на 10 процентных пунктов при той же цене.
Практический вывод: не покупайте «умный выбор модели» вслепую. Найдите две модели на границе «цена — качество», проверьте на своих задачах, сколько вы теряете на дешёвой, и решайте пропорцию сами. Даже идеальный роутер из двух моделей даёт мало: если дешёвая модель почти не уступает дорогой, маршрутизировать почти нечего.
Схема метода
Это не промпт, а проверка и правило выбора моделей (отдельные запросы, в основном вручную или в автоматизации).
ШАГ 1: Собрать кандидатов → таблица «модель / цена за запрос / точность на ваших задачах»
ШАГ 2: Оставить только модели на границе «цена–качество» → обычно 2 (максимум 3)
ШАГ 3: Построить «случайный роутер»: доля p запросов → сильной, остальные → дешёвой
(цена и качество = взвешенное среднее двух моделей)
ШАГ 4: Любой роутер сравнить с этой линией при ТОЙ ЖЕ цене
ШАГ 5: Диагностика роутера по 4 признакам:
— различает ли сложность? — не экономит ли на коротких ответах?
— не привязывает ли тему к модели? — не раздут ли список моделей?
Пример применения
Задача: Вы запускаете ИИ-ассистента поддержки для интернет-магазина на Ozon/Wildberries. Бот работает на n8n, а к API подключён OpenRouter. Обращений около 20 000 в месяц, счёт растёт. Коллега предлагает включить OpenRouter Auto: «пусть сам выбирает дешёвую или дорогую модель». Вы хотите сначала проверить, выгодно ли это.
Промпт:
Ты помогаешь мне проверить, нужен ли роутер моделей, или хватит двух моделей с ручной пропорцией.
Контекст: ассистент поддержки интернет-магазина, ~20 000 обращений в месяц, бюджет на API — 40 000 ₽/мес.
Типы обращений: статус заказа (60%), возвраты и споры (25%), сложные случаи с жалобами (15%).
У меня есть результаты прогона 100 реальных обращений (правильно/неправильно по оценке нашего менеджера) и цены:
| Модель | Цена за 1000 обращений, ₽ | Правильных ответов из 100 |
| Модель А (дешёвая) | 300 | 78 |
| Модель Б (средняя) | 900 | 82 |
| Модель В (топовая) | 6 000 | 88 |
| Роутер «Авто» (результат моего теста) | 2 100 | 80 |
Сделай:
1. Оставь только модели на границе «цена–качество» (те, которые не побиты более дешёвой и более точной).
2. Для оставшихся двух моделей посчитай точность и цену при доле запросов к сильной модели 10%, 20%, 30%, 50%.
3. Сравни роутер «Авто» с этой линией при той же цене. Напиши прямо: выигрывает он или проигрывает и на сколько пунктов.
4. Скажи, что мне проверить вручную, прежде чем доверять роутеру: отправляет ли он сложные жалобы дорогой модели, не гонит ли все «возвраты» в одну модель.
Результат: Модель выдаст короткую таблицу с отсевом неэффективных моделей и расчёт смеси двух моделей для разных долей. Затем она сравнит роутер с линией смеси при той же цене и скажет, лучше он или хуже. В конце будет чек-лист ручной проверки: куда роутер отправляет сложные и короткие обращения, нет ли привязки темы к модели.
Почему это работает
Слабость роутеров. Роутер должен угадать по тексту запроса, насколько он сложный. Это трудно, и угадывать «источник» запроса или его длину гораздо проще. Стандартная оценка роутеров поощряет именно такие лазейки. Она смотрит на баланс «цена — точность» при реальной стоимости ответов. Поэтому выгодно эскалировать (передавать сильной модели) средне-сложные запросы, а не самые трудные: на самых трудных обе модели ошибаются, прироста нет. Выгодно и отправлять сильной модели короткие запросы: ответ короткий, значит, сильная модель обойдётся дёшево. Авторы называют это «накруткой точности» (accuracy hacking). Реальные сложные запросы при этом остаются у слабой модели.
Сильная сторона. Сильные модели последних поколений ведут себя примерно одинаково по темам. Если модель сильнее, она чаще побеждает в любой области. «Специализации» (эта модель лучше в коде, та в праве) слишком слабы, чтобы на них строить маршрутизацию. Поэтому двух моделей хватает: дешёвая отстаёт от топовой на считанные пункты при многократной скидке.
Как это используют. «Случайный роутер» из двух моделей — честный эталон. Любой роутер должен его побеждать при той же цене. Если не побеждает, он не нужен, а список моделей у него слишком длинный или политика слабая.
Рычаги управления: - Доля p запросов к сильной модели → двигайте под бюджет: больше p — выше цена и качество, линейно. - Состав пары → дешёвую выбирайте как «почти топ за малые деньги», а не как «самую дешёвую». - Определение «сложных» → задайте свой порог (например, запросы, где модели чаще всего ошибаются) и отправляйте их сильной модели отдельным правилом. - Размер списка → добавляйте третью модель, только если на ваших данных она явно выигрывает.
Шаблон промпта
В статье готовых промптов нет. Ниже — шаблон для чата, который воспроизводит логику проверки из статьи: отсев моделей и сравнение роутера со случайной смесью двух.
Помоги проверить, нужен ли роутер моделей.
Задача: {описание_задачи}
Объём: {число_запросов_в_месяц} запросов, бюджет {бюджет}.
Данные прогона на {N} реальных запросах:
{таблица: модель | цена за 1000 запросов | число правильных ответов}
Роутер, который я рассматриваю: {название_роутера}, результаты его теста: {цена_и_точность_роутера}.
Сделай по шагам:
1. Отбрось модели, которые хуже другой модели одновременно по цене и по точности.
2. Из оставшихся выбери пару: дешёвую и сильную.
3. Посчитай цену и точность смеси «доля p → сильной модели, остальное → дешёвой» для p = {список_долей}.
4. Найди на этой линии точку с той же ценой, что у роутера. Сравни точности и скажи, во сколько пунктов роутер выигрывает или проигрывает.
5. Перечисли, что проверить вручную у роутера: (а) отправляет ли он трудные запросы сильной модели; (б) не экономит ли он на запросах с короткими ответами; (в) не привязывает ли он тему запроса к одной модели; (г) сколько разных моделей он использует.
Подставляйте: описание задачи, объёмы, таблицу вашего прогона (достаточно 50–100 запросов с ручной оценкой), данные по роутеру.
🚀 Быстрый старт — вставь в чат:
Вот шаблон проверки роутера моделей. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про тип запросов, объём, бюджет и список моделей с ценами — это нужно, чтобы построить таблицу «цена — точность» и отсеять неэффективные модели. Она возьмёт структуру из шаблона и подготовит план прогона на ваших данных.
Ограничения
⚠️ Не про промптинг: вывод касается выбора и подключения моделей через API, в обычном чате его не применить. Нужен доступ к нескольким моделям и их ценам, а лучше ещё и автоматизация без кода.
⚠️ Общий поток запросов: результаты получены на «универсальном» одиночном трафике: один вопрос — один ответ. Для длинных диалогов, агентов с инструментами и узкоспециализированных систем вывод может не сработать.
⚠️ Сильный выигрыш от роутера возможен не всегда: если дешёвая модель сильно отстаёт от топовой, роутер, который точно знает сложность, даёт реальную экономию. Статья показывает лишь, что на актуальном наборе моделей дешёвая почти не уступает.
⚠️ Быстро устаревает: выводы привязаны к конкретному набору моделей и цен на 2026 год. Когда цены и модели сменятся, пару придётся выбирать заново.
⚠️ Спорное допущение авторов: они считают, что пользователь хочет, чтобы самые трудные запросы шли сильной модели, даже если обе всё равно ошибутся. Это принято как позиция, а не доказано.
⚠️ Текст обрезан: часть про специализацию моделей и собственный роутер авторов не дочитана, выводы по ним взяты из аннотации.
Как исследовали
Команда Fastino Labs взяла шесть коммерческих роутеров в 14 режимах: OpenRouter, Azure, vLLM, Not Diamond, Nadir, Orca. Они хотели проверить продукты, которые можно использовать «из коробки». Для каждого запроса записали, какую модель выбрал роутер, потом отдельно сгенерировали и проверили ответ по одинаковым правилам. Набор: 17 бенчмарков, 8 категорий (код, математика, инструкции, знания, офисные задачи, инструменты, QA, Humanity’s Last Exam), по 100 тестовых запросов на категорию. Прогнали 26 моделей в два этапа, чтобы не завязаться на один момент времени. Выводы повторили на трёх внешних наборах (RouterBench, SPROUT, LLMRouterBench).
Эталон — случайный выбор между Gemini 3.7 Flash и Opus 5 (high). Ни один роутер его не обошёл. Исключение — vLLM Semantic Router, но он обучен на данных самих авторов. Худший результат у Orca: −10,5 пункта. Лучшие — Nadir (около −1,4) и vLLM SR (−1,0). Эталон оставался сильным, даже когда его выбор ограничили моделями, доступными самому роутеру.
Сложнее всего было объяснить, почему так вышло. Авторы показали: стандартная оценка «цена — точность» при реальной стоимости ответов сама поощряет плохие привычки. Эскалация 60–80-го процентиля сложности дала на 6,3 пункта больше, чем эскалация самых трудных 20%. Эскалация самых коротких 20% по длине ответа дала 59,5% точности за $1,03 на 1000 запросов. Это всего на 1,6 пункта ниже эскалации самых трудных, а стоит в 1,5% от цены. Роутеры «хакают» метрику, а не решают задачу.
Удивило, что большие списки моделей почти не помогают. Даже при идеальном знании сложности двухмодельный роутер не уступал лучшему набору любого размера больше чем на 1 пункт. Gemini 3.7 Flash отстаёт от Opus 5 (high) на 1,6 пункта при скидке 96%. Вывод для практики: сначала выберите хорошую пару, потом думайте о маршрутизации.
Адаптации и экстраполяции
💡 Адаптация для ручной эскалации в автоматизации: вместо готового роутера можно задать правило в инструкции дешёвой модели. Это моя идея, а не метод статьи, и надёжность самооценки сложности не проверена. Статья как раз показывает, что оценка сложности у роутеров слабая. Проверяйте на выборке.
Ты — первая линия поддержки. Отвечай сам, если вопрос про статус заказа, сроки или стандартный возврат.
Если в обращении есть: спор о деньгах свыше {порог_₽}, угроза жалобы или суда, противоречие между документами — не отвечай клиенту.
Выведи только: ЭСКАЛАЦИЯ: {причина в одной строке}.
🔧 Техника: убрать оценку «по длине» → не экономить на коротких запросах. Если пишете правило эскалации, не используйте длину обращения как признак простоты. Короткая жалоба «верните деньги, я иду в суд» бывает самой тяжёлой. Статья показывает, что именно такая привязка к длине даёт «накрутку точности».
Ресурсы
- Работа: Dynamic LLM Routers are Often Misguided — Sam Wang, Julia White, Sahibzada Allahyar, Dhruv Atreja, Urchade Zaratiana, Kelton Zhang, Fastino Labs.
- Упомянутые наборы для оценки роутеров: RouterBench, LLMRouterBench, RouterArena, TwinRouterBench, SPROUT.
- Упомянутые роутеры: OpenRouter (Auto), Azure, vLLM Semantic Router, Not Diamond, Nadir, Orca; подход CARROT (прогноз качества и длины ответа).
- Методы, на которых построен анализ: модель Раша (теория ответов на задания), индекс интеллекта Artificial Analysis.