Роутер выбирает.
Агент делает.
Роутер решает, какой модели достанется запрос. Но экономить можно и без него: заранее назначить дешёвую модель на узкую задачу или вынести чтение файлов в отдельного исполнителя.
Под одним названием часто обсуждают разные механизмы. Для выбора стека полезно разделить четыре уровня.[1][3][6][10]
Выбрать модель
До ответаОценить тип задачи, сложность и ограничения. Отправить запрос подходящему исполнителю: локальному или облачному.
Делегировать работу
Внутри агентаОставить планирование основной модели. Поручить чтение, извлечение полей или шаблонный код дешёвому субагенту.
Проверить и повысить класс
После попыткиСначала вызвать дешёвую модель. При провале проверки передать задачу сильной. В счёте останутся обе попытки.
Выбрать сервер
ИнфраструктураНайти доступную реплику, учесть лимиты и кэш. Это балансировка: она сама по себе не определяет, какой интеллект нужен задаче.
Что распределяют
Uber, Pinterest, Spotify и AT&T
Ниже — опубликованные архитектуры, а не независимый аудит. Проценты относятся к разным метрикам. Они не образуют рейтинг эффективности.
Uber
от июньского пика[1]
Uber собирает тесты из рабочих задач и сравнивает frontier- и open-weight-модели в общей среде запуска. Выбор зависит от стоимости завершённой задачи, качества и надёжности. Для code review проверяют найденные баги, ложные замечания, задержки и тайм-ауты.
Основная модель разбивает задачу и оценивает результат. Субагентам по умолчанию достаётся более дешёвая модель. Дешёвая не обязательно означает открытую.
Граница вывода. Снижение на 52% измерено при фиксированной модели и связано с набором оптимизаций. Приписывать его замене на открытые веса нельзя. Динамический роутинг по языку, репозиторию и типу агента в статье отнесён к следующему этапу.[1]
закрытых моделей[2]
В Pinterest Assistant основная мультимодальная LLM понимает запрос, строит план и вызывает поиск, рекомендации и специализированные модели. Значительная часть работы проходит в этих инструментах, а не в одной большой LLM.
Компания смещает выбор в сторону дообученных открытых моделей. Внешние модели остаются для прототипов, инженерных инструментов и недостающих возможностей.
Граница вывода. Экономия описана для визуальных нагрузок и собственного хостинга, не для всех задач Pinterest. Семейство модели Assistant в этой публикации не названо. Вывод «это Qwen» из неё не следует.[2]
Spotify
в bulk-read тестах[3]
Плагин Shunt перехватывает объёмное чтение. Если файл длиннее заданного порога — по умолчанию 350 строк, — hook предлагает вызвать отдельного исполнителя. Тот читает файлы и возвращает ответ по вопросу. В примере исполнитель — Gemini 2.5 Flash.
Похожим способом Shunt выносит генерацию шаблонного кода. Отладку, архитектурные решения и критичный код автор оставляет основной модели.
Граница вывода. 90% — сокращение токенов основной модели в тестах чтения Java-монорепозитория, а не всего счёта. Вызовы исполнителя тоже стоят денег. Это пример делегирования, не перехода на open weights.[3]
AT&T
по заявлению компании[4]
AT&T использует собственный cache-aware router: он учитывает кэш при выборе модели. На каждом ходе шлюз сопоставляет ожидаемое качество, скорость и стоимость. Модель может меняться внутри многошагового диалога.
Параллельно компания обучает открытые модели под телеком-задачи. Здесь экономия складывается из двух направлений: выбирать подходящего исполнителя и делать специализированных исполнителей дешевле.
Граница вывода. «До 90%» — верхняя заявленная экономия, не среднее по всем задачам. В статье нет открытого кода шлюза или набора тестов, по которому можно воспроизвести цифру.[4]
Что можно взять,
а что придётся собрать
Код уже есть. Но готовый шлюз, исследовательский роутер и плагин к облачной платформе решают разные задачи.
Три решения можно развернуть на своём сервере. Shunt открыт как плагин. Microsoft и Amazon предлагают управляемые сервисы, а не код для локального запуска.
| Решение | Как принимает решение | Открытые веса + frontier | Что учесть | Код / docs |
|---|---|---|---|---|
| vLLM Semantic RouterСлой выбора моделей | Сигналы → политика → модель, каскад или несколько моделей. | Да: настроенные локальные и облачные бэкенды. | Нужно настроить сигналы, правила и тесты. Агентный цикл остаётся в приложении.[6][7] | Открыть ↗Apache-2.0 |
| RouteLLMСильная / дешёвая модель | Обученный роутер оценивает, когда стоит выбрать сильную модель. | Да: подключаемые модели и совместимые endpoints. | Порог и качество нужно заново проверить на своей паре моделей и запросах.[8][9] | Открыть ↗Apache-2.0 |
| LiteLLM + Auto RoutingШлюз + выбор модели | Эвристики, смысловые правила или LLM-классификатор → уровень модели. | Да: локальные endpoints и внешние API через шлюз. | Auto Routing — бета. Не путать с обычной балансировкой или fallback при ошибке.[10][11][12] | Открыть ↗MIT* |
| Spotify ShuntДелегирование внутри агента | Hooks перехватывают объёмное чтение и отправляют работу модели-исполнителю. | В примере — Claude + Gemini, не открытые веса. | Нужны Portal и AiKA. Это не автономный роутер для любого локального API.[3][5] | Открыть ↗Apache-2.0 |
| Microsoft FoundryManaged model router | Обученная модель выбирает исполнителя; есть режимы цены и качества. | Открытые и закрытые модели из пула Foundry. Не ваш домашний сервер. | Состав пула и регионы задаёт сервис; доступный контекст зависит от моделей.[13] | Открыть ↗Закрытый сервис |
| Amazon BedrockIntelligent prompt routing | Прогноз качества → выбор модели внутри одного семейства. | Есть семейство Llama. Не произвольная смесь local + Claude. | Оптимизирован для английского; не обучается на метриках вашего приложения.[14] | Открыть ↗Закрытый сервис |
Совпадений нет. Измените запрос или выберите «Все».
На узком экране таблица прокручивается вправо. * Основная часть LiteLLM — MIT; каталог enterprise/ имеет отдельную лицензию.[12]
vLLM Semantic Router
Отдельный слой выбирает модели по намерению, сложности, контексту, риску и другим сигналам. Есть каскады и проверка результатов. Сам агент продолжает управлять инструментами и состоянием задачи.[6][7]
В Vela 2.0 есть модель 0.3B для CPU/ONNX. Это компонент принятия решений, а не готовая замена всему роутеру.[15]
RouteLLM
Подходит для эксперимента «дешёвая или сильная». Содержит обученные роутеры и инструменты оценки. Результаты старых бенчмарков не гарантируют ту же экономию на новой паре моделей и русскоязычных задачах.[8][9]
Свой стек: правила,
две модели, проверка
Сначала ограничьте, куда можно отправлять данные. Потом выбирайте модель. В конце проверяйте не уверенность ответа, а результат.
Ниже — предлагаемая схема для своего проекта, не копия внутреннего стека компаний. Для первого стенда достаточно шлюза, двух моделей и проверки результата. Отдельный semantic router добавляйте, когда простых правил перестанет хватать.
Локальные или частные модели.
Узкая задача, понятный тест.
Архитектура, сложная отладка.
Только разрешённые данные.
Нет подходящей модели
или риск ошибки слишком высок.
Эскалация разрешена только внутри политики доступа
Извлечь дату и сумму из документа с уже распознанным текстом. Если локальная модель прошла ваши тесты, дайте ей первую попытку. Проверьте формат и значения; только затем примите результат.
Проверка сильнее самооценки
Для JSON — схема и допустимые значения. Для кода — тесты и просмотр изменений. Для ответа по документам — проверка опоры на источник. Фраза модели «уверен на 95%» сама по себе не условие приёмки.
Приватность касается всего пути
Запрет на внешнюю отправку должен распространяться на классификатор, эмбеддинги, проверяющую модель и журналы. Локальный исполнитель не поможет, если чувствительный текст уже ушёл в облачный роутер.
В многошаговых агентных задачах отдельно проверяйте историю, tool calls и состояние. Переключение модели может менять поведение и условия кэширования. В документации vLLM SR агентный цикл отделён от роутинга; в LiteLLM есть настройка session affinity.[6][11]
Считайте и попытку,
и переделку
Дешёвая попытка не бесплатна. Если после неё нужен дорогой повтор, оплачиваются обе модели — плюс выбор маршрута и проверка.
Поменяйте вводные под свои измерения. Цены по умолчанию условные: это арифметическая модель, а не тарифы провайдеров и не прогноз экономии.
Формула и границы расчёта
N — число задач; F — сильная попытка; L — дешёвая попытка; p — доля задач для дешёвой модели; r — доля её попыток, переданных сильной; R — средняя дополнительная цена выбора и проверки; H — дополнительные фиксированные расходы за месяц.
Повтор у сильной модели здесь стоит столько же, сколько прямой вызов. Если повтор несёт разросшийся контекст, скорректируйте цену. Общие для обеих схем расходы не влияют на разницу и не включены. Налоги и договорные скидки не моделируются.
Если часть задач не проходит приёмку, делите полный расход на фактическое число принятых задач, а не на число запросов. Снижение счёта при росте брака не доказывает экономию.
Начните с одного
типа задач
Не копируйте инфраструктуру Uber. Возьмите один повторяемый процесс и проверьте, где заканчиваются возможности дешёвой модели.
Соберите эталон
Для первого опыта возьмите 100–200 своих задач разных уровней сложности. Задайте признаки приёмки. Измерьте сильную и дешёвую модель отдельно.
Включите одно правило
Поручите дешёвой модели только тот класс задач, где она прошла проверку. Начните с копии трафика без влияния на пользователя. Считайте повторы и задержки.
Сравните принятые задачи
Проверьте качество, полный расход и p95 задержки. Сохраняйте причину маршрута и версии моделей. Расширяйте охват только после проверки на новых задачах.
Мой выбор для первого стенда: LiteLLM с явными правилами или его Auto Routing — если важнее сократить число компонентов. RouteLLM — для опыта с парой моделей. vLLM Semantic Router — когда нужны отдельная политика, несколько сигналов и каскады. Shunt — образец делегирования внутри coding-agent, но с зависимостью от Portal.[5][6][8][10][11]
Универсальной доли «70% локально, 20% дёшево в облаке, 10% frontier» нет. У сложной отладки и извлечения полей разные требования. Для русского языка и собственных данных нужен отдельный набор тестов.
а не цену миллиона токенов.
Проверить и забрать
Основа обзора — инженерные публикации компаний, документация и репозитории. Отчётные проценты не проверялись независимым воспроизведением. Архитектурная схема и план запуска — редакторские предложения; калькулятор — условный расчёт.
- 01Uber — Running a Software Factory Efficiently at Uber Scale ↗
Выбор модели по рабочим тестам; роли основной модели и субагентов; границы показателя −52%.
www.uber.com · 27.08.2026 - 02Pinterest — On the (re)-prioritization of open-source AI ↗
LLM как координатор инструментов; дообученные открытые модели; стоимость визуального инференса.
medium.com · 04.12.2025 - 03Spotify — Portal by Spotify cut my Claude Code token usage by 90% ↗
Hooks, порог 350 строк, Gemini 2.5 Flash, методика bulk-read и ограничения делегирования.
engineering.atspotify.com · 03.09.2026 - 04AT&T — The Tokenomics Equation ↗
Собственный cache-aware router, выбор на каждом ходе и специализированные telco-модели.
about.att.com · 23.07.2026 - 05Spotify — Portal AI Plugins / Shunt ↗
Открытый код плагина; Apache-2.0; зависимость Shunt от Portal CLI и AiKA.
github.com · Проверено 07.10.2026 - 06vLLM Semantic Router — документация ↗
Сигналы, правила выбора, каскады; разделение роутера, агента и инференса.
vllm-sr.ai · Проверено 07.10.2026 - 07vLLM Semantic Router — репозиторий ↗
Код, Apache-2.0, единый API и локальные, частные и облачные бэкенды.
github.com · Проверено 07.10.2026 - 08LMSYS — RouteLLM ↗
Двухмодельный роутинг, обученные роутеры, инструменты оценки; Apache-2.0.
github.com · Проверено 07.10.2026 - 09LMSYS — публикация о RouteLLM ↗
Эксперименты с сильной и слабой моделью. Исторические результаты не перенесены на новые модели.
www.lmsys.org · 01.07.2024 - 10LiteLLM — Router / Load Balancing ↗
Шлюз, балансировка, лимиты, повторы, тайм-ауты и резервные провайдеры.
docs.litellm.ai · Проверено 07.10.2026 - 11LiteLLM — Auto Routing [Beta] ↗
Классификация сложности, правила, LLM-классификатор, уровни моделей, session affinity.
docs.litellm.ai · Проверено 07.10.2026 - 12LiteLLM — лицензия ↗
MIT для основной части; каталог enterprise/ регулируется отдельной лицензией.
github.com · Проверено 07.10.2026 - 13Microsoft Foundry — Model router ↗
Управляемый выбор модели, режимы Cost / Balanced / Quality, состав пула и ограничения.
learn.microsoft.com · Проверено 07.10.2026 - 14Amazon Bedrock — Intelligent prompt routing ↗
Выбор внутри семейства моделей; ограничения для языка и адаптации к данным приложения.
docs.aws.amazon.com · Проверено 07.10.2026 - 15vLLM — Vela 2.0: Open Foundation Routing Models ↗
Семейство моделей для решений; компактный вариант 0.3B для CPU/ONNX. Не замена всей системе роутинга.
vllm-sr.ai · 06.10.2026
Срез: 7 октября 2026. Документация и состав моделей меняются. Перед внедрением закрепите версии, проверьте лицензии конкретных весов, поддержку инструментов и правила передачи данных.