В цикле · S1E05 Жизненный цикл агента
Модель в продакшене: маршрутизация, резервирование и кэш
Как выбирать модель и провайдера, ограничивать резервные переходы и оценивать экономику кэша на примере OpenRouter.
На прототипе вызов модели выглядит как одна строка: отправить запрос и дождаться ответа. В продакшене за ней появляются лимиты, очереди, разные провайдеры, нестабильная задержка и стоимость повторных попыток. Даже удачно выбранная модель ещё не определяет поведение всей системы.
В пятом выпуске «В цикле» рассматриваем этот слой на примере OpenRouter. Конкретные параметры сервиса меняются; здесь важны решения, которые команда должна принять независимо от шлюза: кого допускать к запросам, когда переключаться и какую экономику считать.
Два отдельных решения: модель и провайдер
Выбор модели определяет доступные способности, контекст и характер ответов. Выбор провайдера определяет, где обслуживается запрос к этой модели, с какой производительностью, доступностью и политикой данных. Резервирование на другой endpoint той же модели и переход на другую модель — разные изменения.
Например, запасной провайдер может помочь при временной недоступности. Но другая модель способна иначе выбирать инструменты, соблюдать формат и интерпретировать инструкцию. Проверять её нужно как самостоятельный вариант продукта, а не как технически эквивалентный адрес.
Маршрутизация внутри вашего workflow тоже отличается от маршрутизации инфраструктуры. Отправить запрос о возврате в отдельный процесс — продуктовая логика. Выбрать, кто выполнит LLM-вызов этого процесса, — инфраструктурная.
Сначала ограничения, затем оптимизация
Перед сортировкой по скорости и цене определите допустимый набор: нужные инструменты и формат ответа, предел контекста, политика хранения данных, бюджет и доступные регионы. Только среди подходящих вариантов имеет смысл искать самый выгодный.
| Правило | Смысл | Что может произойти при сбое |
|---|---|---|
| Предпочитать низкую задержку | Лучшие по скорости кандидаты идут первыми | Запрос может уйти к более медленному кандидату |
| Разрешить только заданных провайдеров | Выход за список недопустим | Запрос завершится ошибкой, если подходящих нет |
| Ограничить стоимость | Не допускать тариф выше потолка | Повышается вероятность отсутствия допустимого маршрута |
| Потребовать поддержку параметров | Не терять необходимые свойства запроса | Набор подходящих endpoint становится уже |
В OpenRouter объект provider управляет выбором провайдера. Поля order, only, ignore, allow_fallbacks и require_parameters задают разные ограничения. Явный порядок сам по себе не всегда означает запрет резервного перехода к остальным: это нужно проверять отдельно.
Не следует принимать мягкий порог задержки за гарантию SLO. Предпочтение меняет выбор кандидатов, а пользовательское обещание требует измерения всего пути запроса, включая очередь, повторы и работу инструментов.
Резервный переход должен сохранять смысл задачи
Список резервных моделей повышает шанс получить ответ. Но HTTP-успех ещё не означает, что задача решена правильно. Важно проверить поддержку инструментов, структуру ответа, доступный контекст и поведение на характерных запросах.
Полезно различать причины сбоя. При сетевой ошибке можно попробовать другой допустимый endpoint. При некорректной схеме повтор без изменения запроса бесполезен. При отказе по правилам безопасности автоматический поиск модели, которая согласится, способен нарушить политику продукта.
Установите общий дедлайн всей цепочки. Три кандидата с отдельными длинными таймаутами могут превратить короткое обращение пользователя в минутное ожидание. В трассировке сохраняйте фактически ответившую модель и провайдера, количество попыток и полную длительность.
План резервирования включает не только следующий адрес, но и условие прекращения попыток. Иногда корректная ошибка или передача человеку лучше ответа от непроверенной модели.
Что именно экономит кэш промпта
Кэш промпта переиспользует обработку совпадающего входного префикса. Он не означает, что пользователь получает старый готовый ответ. Выигрыш зависит от того, какая часть запроса повторяется, как долго живёт запись и сколько стоят её создание и чтение.
Для агента повторяющимся префиксом могут быть системные инструкции и определения инструментов. Если они постоянно меняются или запросы переключаются между независимыми кэшами провайдеров, ожидаемая экономия исчезает.
Стабильный порядок определений и постепенная загрузка редких инструментов помогают управлять контекстом. Но уменьшение префикса и рост доли попаданий — разные эффекты: важно смотреть на итоговый счёт и задержку, а не только на красивую долю cache hits.
Липкость, скорость и качество конкурируют
Липкая маршрутизация старается сохранить провайдера для связанной последовательности запросов, чтобы использовать прогретый кэш. Динамический роутер может предпочесть другой endpoint, если первый стал медленнее или хуже выполняет вызовы инструментов.
В материалах выпуска этот конфликт показан через prompt caching и Auto Exacto в OpenRouter. Один механизм бережёт повторно используемый контекст, другой учитывает характеристики исполнения. Устойчивый выбор зависит от нагрузки: длинный агентный диалог и одиночная короткая классификация имеют разную экономику.
Автороутер также не заменяет собственные evals. Популярность модели, общие бенчмарки и результаты других команд не доказывают, что она правильно обрабатывает ваши запросы. Подходящие маршруты нужно допускать по результатам проверки продукта.
Считайте стоимость полезного результата
Цена миллиона токенов удобна для сравнения прайс-листов, но недостаточна для решения о маршруте. Добавьте вход и выход всех шагов, операции инструментов, повторы, стоимость кэша и ручную обработку неудачных случаев.
Стоимость решённой задачи =
затраты на все попытки и обработку
÷ число успешно решённых задачЭто управленческая метрика, а не формула счёта конкретного провайдера. Её надо считать на сопоставимых сценариях и с определённым критерием успеха. Более дорогой вызов может дать более дешёвую решённую задачу, если существенно уменьшит повторы и эскалации.
Что проверить перед переключением маршрута
- Качество основной и резервных моделей на одном наборе задач.
- Соблюдение ограничений данных и параметров запроса на каждом переходе.
- Полную задержку, включая таймауты и повторы, и её высокие перцентили.
- Фактическую стоимость успешной задачи и долю ручной обработки.
- Поведение при недоступности всех разрешённых кандидатов.
Чтобы такая проверка не превращалась в набор разовых демонстраций, нужна система evals. А чтобы правильно читать графики времени ответа, полезен разбор задержки и хвостов.
Источники
Основа — глава 6 материалов «Жизненный цикл агента» и сценарий S1E05. Тарифы, доступные модели и алгоритмы выбора здесь не фиксируются как постоянные характеристики.
