Паттерн роутера недооценён: как выбор модели на каждый вызов снижает расходы на токены

Проблема: модель привязана к агенту, а не к задаче

Автор материала на DEV.to описывает случай из практики: исследовательский пайплайн за один день потратил около $340. Причина не в сбое, а в успешном выполнении — все 23 шага обращались к фронтир-модели, хотя большинство из них были рутинными (форматирование JSON, извлечение дат, классификация тикетов).

Ключевое наблюдение: разница в стоимости за токен между фронтир-моделью (в тексте упоминается Claude Opus) и небольшой моделью (Claude Haiku) составляет от 5 до 25 раз. На одном вызове это незаметно, но на цепочке из нескольких шагов накопленный эффект становится значительным.

Что такое capability-based routing

Автор называет решением паттерн маршрутизации по возможностям (capability-based routing, он же semantic routing). Идея: классифицировать каждый вызов по тому, что ему действительно нужно, направлять его к самой дешёвой достаточной модели и повышать уровень только тогда, когда проверка отклонила результат.

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

Что показали измерения в тексте

Автор приводит сравнение трёх конфигураций на задаче ревью (16 вызовов на 1000 ревью):

• Маршрутизация на уровне вызова отправила к фронтир-модели только 2 из 16 вызовов и стоила $1.37 за 1000 ревью.

• Это примерно в пять раз дешевле отправки всех вызовов к фронтир-модели и менее половины стоимости конфигурации с привязкой модели к агенту.

• По качеству: найдено 4 из 6 заложенных багов — столько же, сколько при полностью фронтирном варианте, и больше, чем при привязке к агенту (3).

Исследования, на которые ссылается автор

В материале упоминаются две работы:

• Статья Federation of Agents описывает Versioned Capability Vectors (VCVs) — машиночитаемые профили, делающие возможности агентов доступными для семантического поиска. Слой маршрутизации сопоставляет задачи и агентов через шардированные индексы HNSW, применяя оптимизацию со смещением в сторону стоимости.

• Работа LatentGate от Equinix формулирует корпоративный сценарий: при 100 специализированных агентах роутер должен одновременно обеспечивать задержку менее 100 мс, высокую точность и дешёвое подключение новых агентов. Маршрутизация на основе промптов даёт хорошее семантическое рассуждение, но задержка около 1500–2000 мс и точность падает до 70–77% при 100 агентах.

Что стоит держать в голове

Материал — это разбор практического опыта с опорой на упомянутые публикации, а не независимое исследование. Цифры ($340, $1.37, 4 из 6 багов, 5–25x, 1500–2000 мс, 70–77%) взяты из источника и требуют проверки по первоисточникам. Формулировка про «привязку модели к агенту как предсказание, сделанное один раз о работе, которую ещё никто не видел» приписывается команде vLLM — стоит уточнить контекст цитаты.