Мультимодельная маршрутизация для AI-агентов

Как мультимодельная маршрутизация влияет на агента для написания кода

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

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

Четыре термина, определенные один раз. Маршрутизатор (router) выбирает модель для каждого запроса. Шлюз (gateway) — это прокси, через который проходит запрос и который может выполнять или не выполнять маршрутизацию. Кэш промптов (prompt cache) — это хранение провайдером обработанного префикса вашего промпта, благодаря чему последующий запрос, повторяющий этот префикс, оплачивается как малая доля от стоимости входных данных. KV-кэш (key value cache) — это аналогичная концепция внутри сервера, который вы запускаете самостоятельно.

Почему чат-трафик маршрутизируется эффективно, а агентский — нет

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

Агентский цикл — это не один запрос. Одна инструкция, например «исправь падающий тест», превращается в двадцать-шестьдесят вызовов API. Каждый вызов повторно отправляет всю историю переписки: системный промпт, определения всех инструментов, каждый файл, прочитанный агентом, и вывод каждой выполненной команды. Контекст только растёт. К тридцатому вызову повторяющийся префикс может достигать десятков тысяч токенов, в то время как действительно новый контент в каждом вызове составляет лишь несколько сотен.

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

Кэш промптов привязан к конкретной модели, а агент существует внутри него

Anthropic оценивает чтение из кэша в 0.1 от базовой стоимости входных данных, а запись в кэш с пятиминутным сроком хранения — в 1.25 от этой стоимости. Это официальные цены, актуальные на август 2026 года.

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

Сравните второй ряд с первым, двигаясь по строкам, а не по столбцам. Чтение из кэша для Opus 5 стоит 0.50 долларов за миллион токенов. Ввод без использования кэша для Haiku 4.5, самой дешевой модели в списке, стоит 1.00 долларов. Таким образом, повторное чтение «разогретого» префикса на самой дорогой модели обходится дешевле в пересчете на входной токен, чем чтение того же префикса «на холодную» на самой дешевой модели.

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

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

Во что на самом деле обходится одно переключение в ходе сессии

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

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

Оставаться на Opus 5 с прогретым кэшем стоит 0.020 долларов за префикс в этом обращении. Первое обращение после переключения на Sonnet 5 стоит 0.100 долларов, так как у Sonnet нет записи для этого префикса, и её приходится создавать. Возврат на Opus 5 стоит 0.250 долларов, так как исходная запись истекла, пока сессия была переключена.

Таким образом, за «путешествие туда и обратно» приходится дважды оплатить запись в кэш, чтобы избежать двух чтений из кэша. Взамен переключение даёт один цикл вывода по цене Sonnet вместо цены Opus. В блоке подробностей приведён расчёт всей операции: экономия составляет доли цента, а штраф за кэширование — десятки центов. Штраф превышает экономию более чем на порядок, и он растёт вместе с длиной префикса, в то время как экономия остаётся неизменной.

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

Форматы вызова инструментов различаются у разных провайдеров

Агент представляет собой цикл вызова инструментов, поэтому формат вызова инструментов здесь критически важен, в отличие от обычного чата. Messages API от Anthropic возвращает блок содержимого tool_use и ожидает в ответ блок tool_result. API, совместимые с OpenAI, возвращают массив tool_calls, в котором function.arguments является JSON-строкой, а не вложенным объектом. Шлюз выполняет трансляцию между этими форматами, и для стандартных вызовов преобразование проходит корректно.

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

Для self-hosted эндпоинтов это требует явной настройки. Сервер vLLM, совместимый с OpenAI, требует использования --enable-auto-tool-choice вместе с --tool-call-parser, соответствующим семейству моделей (hermes, mistral, llama3_json и другие), а также шаблона чата, который обрабатывает сообщения с ролью tool. Документация vLLM прямо указывает на ограничения этого пути: при использовании tool_choice="auto" без строгих ограничений схемы vLLM извлекает вызовы инструментов из «сырого» текста, поэтому аргументы могут быть повреждены или нарушать схему параметров функции. Выбор неверного парсера для вашей модели — это конфигурационная ошибка, из-за которой агент не сможет вызывать инструменты. Об этом стоит знать до того, как вы направите на него трафик. Здесь важна разница между Ollama и vLLM при самостоятельном развертывании моделей, поскольку эти инструменты предоставляют доступ к вызову функций на разных условиях.

Изменение поведения при промежуточном переключении на резервный маршрут без ошибки

Функция резервной маршрутизации (fallback routing) чаще всего активируется по ошибке. Шлюз настраивается на повторную попытку с использованием другой модели, если первая возвращает ограничение частоты запросов (rate limit) или ошибку 5xx, после чего переводит сбойную модель в режим ожидания (cooldown) на несколько секунд. Для чат-трафика это верное решение. Однако при выполнении длительной задачи агента это означает, что вторая половина задачи была выполнена моделью, которую вы не выбирали.

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

Та же ловушка подстерегает при сжатии контекста. Многие агенты суммируют длинную историю, обращаясь к небольшой модели. Если этот вызов использует другую модель или другой системный промпт, он создает собственную запись в кэше и не обновляет основную сессию. В результате при следующем полном обращении приходится заново обрабатывать «холодный» префикс. Сжатие позволило сэкономить токены, но привело к потере кэша.

Накладные расходы на маршрутизацию реальны, но задержка — не главная проблема

Маршрутизаторы действительно добавляют работы на каждый запрос, и важно точно понимать, насколько значительны эти затраты. DigitalOcean сообщает, что их модель Arch-Router определяет намерение маршрутизации примерно за 51 миллисекунду с точностью 93.17% согласно их собственной оценке. Это их цифры, полученные в ходе их измерений и тестов, а не наши и не универсальный результат. Если принять их как есть, вывод обнадеживает: 51 миллисекунда на сорок вызовов агента — это около двух секунд, добавленных к задаче, которая выполняется несколько минут.

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

На сервере, который вы обслуживаете самостоятельно, действует то же правило, но с меньшим пространством для маневра. Локальным эквивалентом кэша промптов является кэширование префиксов в KV-кэше, который находится в памяти GPU. Размещение двух моделей на одном GPU разделяет эту память между ними, поэтому каждая из них хранит меньший KV-кэш и быстрее вытесняет префиксы. Маршрутизация между двумя локальными моделями может из-за этого снизить коэффициент попаданий в кэш для обеих моделей одновременно. Если вы подбираете оборудование для этой задачи, объем памяти и CPU, которые реально нужны кодинг-агенту на VPS, будет более полезной отправной точкой, чем маршрутизатор.

Правило принятия решений

• Маршрутизируйте запросы между провайдерами для обеспечения доступности. Когда альтернативой является ошибка запроса, любая цена оправдана. Закрепите резервный вариант за моделью с тем же форматом вызова инструментов, чтобы цикл агента продолжал работать, и логируйте, какая модель обслужила каждый вызов.
• Маршрутизируйте между уровнями (tiers) для оптимизации затрат только на границах задач. Выбор Haiku для переименования и Opus для рефакторинга — это верное решение, принятое один раз перед началом сессии. Это плохое решение, если оно принимается на тридцатом шаге той же сессии.
• Закрепляйте одну модель за сессией для любых агентных задач. Ценность сессии заключается в её «прогретом» кэше. Относитесь к смене модели так же, как к очистке этого кэша, потому что именно это и происходит.
• Свободно маршрутизируйте субагентов. Субагент, который начинает работу с «чистым» и небольшим контекстом, не имеет «прогретого» кэша, который можно потерять, поэтому он может работать на любой модели, подходящей для его задачи. Это единственное место внутри агента, где маршрутизация практически бесплатна.

Для реализации этого процесса используется шлюз: псевдонимы моделей и явные списки резервных вариантов. Минимальная конфигурация прокси LiteLLM выглядит следующим образом.

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

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

Когда одна правильно подобранная модель эффективнее любого роутера

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

Поэтому честный подход по умолчанию — это одна модель, выбранная один раз, с включенным кэшированием и достаточно долгим TTL (time to live), чтобы перекрыть паузы, когда вы останавливаетесь для чтения diff. Anthropic предлагает запись в кэш с временем жизни один час по цене 2 базовых тарифов на входные токены, что окупается уже после двух прочтений. Это зачастую более эффективный рычаг, чем любой роутер. Выбирайте тариф осознанно, используя прямое сравнение Opus, Sonnet и Haiku, и если счет все еще остается проблемой, снижайте его с помощью бюджетов и уменьшения контекста, как описано в контроле расходов на AI-агентов на VPS, а не с помощью переключения моделей в середине сессии.

Используйте маршрутизацию, когда запросы независимы и коротки, или когда субагенты начинают работу с чистого контекста. Фиксируйте модель, когда у вас одна длинная сессия для выполнения одной задачи. Большая часть работы агента для написания кода относится ко второму типу, поэтому роутер, который экономит деньги в вашем чат-продукте, здесь будет незаметно увеличивать ваши расходы. Если вы еще не определились с самим агентом, сравнение Claude Code с Cursor, Codex и Copilot описывает, как каждый из них управляет выбором модели, причем некоторые из них принимают это решение за вас.

FAQ

Действительно ли переключение моделей во время сессии приводит к потере кэша промптов?

Да. Кэши промптов привязаны к хешу префикса промпта и хранятся отдельно для каждой модели. Запрос к другой модели проверяет хранилище, в котором этот префикс отсутствует. Система не находит совпадений, оплачивает полную стоимость входных токенов без кэширования, а при включенном кэшировании — еще и стоимость записи в кэш. Возврат к исходной модели также не восстанавливает запись, так как стандартный пятиминутный срок жизни кэша к этому моменту обычно истекает. Проверяйте поля cache_read_input_tokens и cache_creation_input_tokens в объекте использования ответа: признаком проблемы является ситуация, когда в длинной сессии количество прочитанных кэшированных токенов равно нулю.

Выгоднее ли перенаправлять запросы агента на более дешевую модель?

Только если нет «прогретого» кэша, который можно потерять. Чтение из кэша у Anthropic стоит 0.1 от базовой стоимости входных токенов, что делает чтение из кэша Opus 5 дешевле, чем ввод без кэширования на Haiku 4.5. Как только в сессии появляется большой кэшированный префикс, текущая модель становится наиболее дешевым вариантом по стоимости ввода. Маршрутизация выгодна, когда контекст свежий и небольшой: в начале задачи или в субагенте, который несет только необходимый ему контекст.

Почему поведение моего агента изменилось в середине выполнения задачи?

Проверьте, не сработал ли механизм переключения на резервный шлюз (gateway fallback). При достижении лимита запросов или ошибке 5xx на основной модели шлюз повторяет запрос через резервную модель и переводит основную в режим ожидания (cooldown) на несколько секунд, поэтому остальная часть задачи выполняется на другом ресурсе. Это не вызывает ошибок или предупреждений, и задача по-прежнему помечается как успешная. Поле model в логе запросов шлюза или метаданных ответа — единственный надежный источник информации, поэтому логируйте его для каждого запроса, если вы используете резервные модели.

Одинаково ли работают вызовы инструментов (tool calls) у всех провайдеров?

Не совсем. Messages API от Anthropic использует блоки контента tool_use и tool_result, в то время как API, совместимые с OpenAI, используют массив tool_calls, где function.arguments является JSON-строкой. Шлюз хорошо справляется с типичными случаями, но параллельные вызовы инструментов и строгое соблюдение схем различаются в зависимости от провайдера. При использовании self-hosted vLLM необходимо настроить --enable-auto-tool-choice и --tool-call-parser, соответствующие семейству вашей модели. В документации vLLM указано, что без строгого ограничения схемы сервер извлекает вызовы инструментов из обычного текста, поэтому аргументы иногда могут быть сформированы некорректно.

Какой TTL кэша следует установить для сессии программирования?

Используйте стандартный пятиминутный срок жизни для непрерывной работы и часовой вариант, если человек просматривает diff-файлы между итерациями. Anthropic оценивает пятиминутную запись в 1.25 от базовой стоимости ввода, а часовую — в 2 раза, при стоимости чтения 0.1. Пятиминутная запись окупается одним чтением, а часовая — двумя. Поэтому в любой сессии, где вы планируете вернуться к работе, более длительный срок жизни обычно обходится дешевле, чем повторная оплата «холодного» префикса.