Маршрутизатор моделей, встроенный в harness кодинг-агента Open SWE, снизил медианную стоимость обработки одного треда на 64%: с $2,61 до $0,94. LangChain получила этот результат в A/B-тесте на 973 реальных тредах и не обнаружила измеримого падения качества. Источник цифр и логики - разбор How to Build a Model Router in the Harness.
Прямой ответ на главный вопрос звучит так: решение о выборе модели должно приниматься там, где есть контекст задачи. Harness агента этот контекст собирает по ходу работы: промпт, инструменты, историю треда и доменные знания. Универсальный шлюз таким набором не располагает.
Дальше разбираем, что такое маршрутизация моделей, какие цифры получила LangChain, из каких шагов состоит роутер, где он ломается и как понять, нужен ли он вашему проекту.
Что такое маршрутизация моделей и почему она важна для AI-агентов
Маршрутизация моделей (model router) означает выбор конкретной LLM под каждую задачу вместо привычного "всегда зовём самую сильную". LangChain формулирует цель как соответствие "модель - harness - задача": правильная модель получает правильный контекст для конкретной задачи.
Стимул экономический. Frontier-модели остаются дорогими, и когда агентов много и они работают постоянно, платить за топовый тир на каждом шаге становится неприемлемо. При этом большинство агентов не нуждаются в frontier-уровне интеллекта для каждой задачи. Дальше включается убывающая отдача: более способная модель добавляет мало качества, зато стоимость и задержка продолжают расти.
Anthropic в своём руководстве по выбору модели замечает, что для многих приложений оптимально начинать с более быстрой и экономичной модели, например Claude Haiku 4.5. Логика простая: если дешёвый тир закрывает типовой запрос, платить за дорогой незачем. LangChain описывает тот же принцип на примере собственного агента.
Почему универсальный шлюз не справляется с выбором модели
Шлюз (generic gateway) стоит между приложением и API моделей. Он умеет считать токены, повторять неудачные запросы, распределять ключи и подменять провайдера. Чего он не знает, так это какая именно задача пришла.
Выбор правильной модели требует доменного и задачного контекста, который harness уже собирает, а шлюз обычно не имеет. Разница видна на примере Open SWE: harness понимает, что пришёл вопрос по кодовой базе или запрос на изменение кода, какие инструменты агент уже вызвал и что было в предыдущих сообщениях треда. В теле HTTP-запроса к API этой информации нет, поэтому шлюзу остаётся гадать по длине промпта.
Формулировка LangChain прямая: эффективный роутер живёт в harness, а не в универсальном шлюзе. Практический вывод для тех, кто строит своего агента: логику выбора модели стоит держать рядом с той частью системы, которая знает о задаче больше всего.
Кейс LangChain: как роутер в Open SWE снизил стоимость на 64%
Open SWE - открытый кодинг-агент LangChain. Инженеры пользуются им из Slack и веб-интерфейса: задают вопросы о своих кодовых базах и просят внести изменения в код. Месячные расходы на этого агента начали быстро расти, и ту же проблему LangChain слышала от клиентов. Из этого вырос проект роутера моделей для Open SWE.
Базовая линия в тесте - всегда топовая frontier-модель. После включения роутера медианная стоимость одного треда упала на 64%: с $2,61 до $0,94, без измеримого изменения качества.
Детали A/B-теста: 973 треда и метрики качества
Замер проводился на 973 тредах живого агента, а не на синтетических задачах. Качество отслеживали по двум метрикам: доля merged PR для запросов на изменение кода и пользовательский фидбек для вопросов по кодовой базе. Отсутствие измеримого падения означает, что роутер выбирал модели, которых хватало для выполнения задачи.
Работа с данными шла в течение недели интерактивных тредов: их разметили по типам задач, чтобы понять, какие запросы вообще приходят агенту и сколько каждый из них стоит.
Оговорка, без которой цифра 64% вводит в заблуждение: опубликованный фрагмент разбора не раскрывает методологию теста, состав выборки и статистическую значимость. Результат относится к конкретному агенту, конкретному набору моделей и конкретным задачам. Переносить его на свой проект без собственного A/B-замера не стоит, тем более что структура задач у разных команд отличается заметно.
Как построить model router: четыре шага от LangChain
Дизайн роутера опирается на observability и evals. Нужно понимать пространство задач агента, изучить производительность моделей и заранее зафиксировать критерии успеха. Без этого выбор моделей превращается в подбор на вкус.
Анализ трейсов с помощью LangSmith
Первый шаг - данные. Команда вытащила из трейсов LangSmith данные уровня тредов: типы входящих запросов, стоимость и число ходов каждого треда. Стоимость и число ходов здесь работают приблизительными мерами сложности. Исследование велось в LangSmith Custom Apps: поверх трейсов Open SWE построили небольшой интерфейс.
Затем неделю интерактивных тредов разметили по типу задачи с помощью LLM-классификатора. Похожую группировку по трейсам умеет делать LangSmith Insights.
Распределение по типам задач выглядело так (категории - эвристики на основе заголовка и метаданных треда, а не строгая таксономия):
| Тип задачи | Доля тредов |
|---|---|
| Новые функции | 22% |
| Исправления багов | 17% |
| Тестовые или no-op запуски | 16% |
Изменения кода доминировали. Остальные категории в разборе не перечислены.
Отдельный вывод касается длины: треды, связанные с исследованием функциональных задач, как правило, оказывались длиннее остальных. Это аргумент против одной модели на все случаи. Короткий вопрос по кодовой базе и многошаговое исследование новой фичи различаются по числу ходов и стоимости кратно, и платить за них одинаково смысла нет.
Выбор моделей и классификатор на первом сообщении
Второй шаг - несколько моделей вдоль кривой "интеллект/стоимость". На практике это дешёвый быстрый тир для типовых вопросов, средний для правок кода и топовый для сложных многошаговых изменений. Критерий подбора - поведение модели на ваших задачах, а не абстрактный рейтинг из таблицы бенчмарков.
Третий шаг - классификатор. Он срабатывает на первом сообщении треда и направляет запрос в самый дешёвый подходящий тир. Требование к нему одно: быть достаточно лёгким, чтобы не съесть экономию задержкой. Вариантов реализации несколько (правила по ключевым словам, классификатор на эмбеддингах, few-shot промпт к дешёвой модели), но какой именно выбрала LangChain, в опубликованном фрагменте не раскрывается.
Четвёртый шаг - запуск и мониторинг. Роутер не заканчивается на выборе моделей: нужно видеть, какие тиры выбираются на каких задачах, где классификатор ошибается и как меняется стоимость по неделям.
Ограничения наивной реализации роутера
Роутер экономит ровно настолько, насколько точен его классификатор и насколько аккуратно устроено переключение моделей. Две ошибки встречаются чаще всего.
Проблема перемаршрутизации и prompt cache
Первая: отсутствие перемаршрутизации внутри треда. Классификатор принимает решение один раз, на первом сообщении. Если задача по ходу разговора оказалась сложнее, чем выглядела вначале, роутер не переключится на более мощную модель. Экономия оборачивается проваленной задачей, а повторная попытка на дорогой модели съедает всю выгоду.
Вторая: потеря prompt cache при смене модели. Кэш промптов у провайдеров привязан к конкретной модели и её версии. Смена модели внутри треда обнуляет кэшированный префикс: следующий запрос оплачивается без скидки за кэш, а задержка растёт. Маршрутизация на первом сообщении с фиксацией модели на весь тред выглядит компромиссом именно поэтому: переключение посреди диалога может стоить дороже, чем экономит.
Оговорка: в опубликованном фрагменте разбора эти ограничения детально не раскрыты. Механика prompt cache выше - общее свойство инфраструктуры провайдеров, а не результат замера LangChain в этом кейсе.
Третья проблема менее очевидна: цена ошибки классификатора асимметрична. Дешёвый тир на сложной задаче даёт провал и расходы на переделку. Дорогой тир на простом вопросе просто сжигает бюджет. Поэтому типовая стратегия - отправлять спорные случаи в тир выше, а не ниже.
Как измерять успех: метрики и evals
Метрики в кейсе LangChain: медианная стоимость на тред, доля merged PR по задачам изменения кода и пользовательский фидбек по вопросам. Сравнивать их нужно с базовой линией на сопоставимом наборе задач, а не с прошлым месяцем наугад. Роутер приносит пользу, если качество держится на прежнем уровне при меньшей цене.
Трейсы отвечают на вопрос, какая модель выбирается на каких задачах и где классификатор промахнулся. Без этого роутер остаётся чёрным ящиком, который почему-то экономит деньги, и при первом же падении качества непонятно, что откатывать. Автоматизировать проверки помогает подход из разбора Eval Engineering Skill: тесты для AI-агентов из репозитория и трейсов, а логику оценки на длинных агентных прогонах разбирает кейс Similarweb и LangSmith с LLM-as-judge.
Практическое правило: держите отдельный набор тестовых задач, на котором прогоняете и базовую линию, и роутер после каждого изменения классификатора. Иначе сравнение быстро теряет смысл, а изменение промпта классификатора незаметно ломает качество.
Стоит ли внедрять маршрутизацию моделей в вашем проекте
Смотрите на две вещи: разброс сложности задач и абсолютный счёт за LLM. Если агент обслуживает разнородные запросы, а расходы растут быстрее числа пользователей, роутер окупается. Если все задачи примерно одинаковы, выигрыш даст подбор одной более дешёвой модели.
Первый шаг не требует кода: выгрузите неделю трейсов и посмотрите, какие типы задач преобладают и сколько стоит каждая. Если большинство запросов простые, а платите вы по цене топовой модели, экономия на ровном месте.
Альтернативы роутеру тоже стоит держать в голове. Снизить расход можно на уровне harness: например, в разборе Deep Agents v0.7 входные токены сократили примерно с 6k до 2k. Другой путь - сравнить свою разработку агента с готовыми решениями и посчитать полную стоимость владения, что разобрано в материале про архитектуру самописного AI-агента, latency, cost и reliability.
Ограничения подхода честнее назвать сразу. Роутеру нужна инфраструктура трейсинга, поддержка классификатора и регулярные evals. Для небольшого проекта с десятком запросов в день это лишняя работа. Цифра 64% из кейса LangChain получена на масштабе, где медианная стоимость треда измеряется долларами, а не центами, и где накопленная статистика позволяет ловить ошибки классификатора.
Практический старт: возьмите один типовой сценарий, замерьте его стоимость и качество на текущей модели, а затем прогоните тот же набор задач на более дешёвой модели. Если качество не проседает, классификатор для этого сценария может быть совсем простым - иногда достаточно правила по типу запроса.