Снижение затрат LLM API: Switchyard и AI Gateway

На странице OpenAI о prompt caching указано, что автоматическое кэширование применяется для поддерживаемых моделей при общих префиксах промпта длиной от 1 024 токенов, а повторно используемый ввод может тарифицироваться дешевле обычного. Из этого следует главный вывод: снижение затрат LLM API нельзя сводить к переходу на более дешёвую модель. Сначала нужно разделить запросы по сложности и качественным требованиям, затем внедрить маршрутизацию Switchyard, сжатие контекста, безопасный кэш, лимиты AI Gateway и контроль повторных вызовов.

Кому пригодится этот разбор

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

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

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

Сначала найдите механизм перерасхода

Рост счёта обычно связан не с одной причиной. На практике расходы усиливаются несколькими коэффициентами, которые перемножаются внутри одной бизнес-операции.

Первый фактор — ошибочное соответствие модели и задачи. Если классификация документов, нормализация полей или простой ответ пользователю всегда отправляются на наиболее мощную модель, компания оплачивает избыточное качество. Однако глобальная замена на дешёвый вариант создаёт обратный риск: сложные задачи начинают завершаться с ошибками, а затем запускают ручную проверку, повторный запрос или обращение к более дорогой модели.

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

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

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

Пятый фактор — отсутствие финансовой атрибуции. Если журнал хранит только название модели и время ответа, невозможно понять, какой проект, команда, окружение или тип операции потребляет бюджет. Поэтому AI Gateway должен связывать расходы с идентификатором бизнес-запроса, а не только с API-ключом.

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

Первый этап: разделите запросы по качественной планке

До настройки маршрутизации требуется создать таксономию задач. Минимальная версия может включать три класса:

• простые операции с фиксированным форматом — классификация, извлечение, короткое преобразование;
• стандартные рабочие задачи — суммаризация, подготовка черновика, анализ небольшого набора документов;
• критичные операции — сложное рассуждение, код, юридически или финансово значимые выводы, работа с неоднозначными данными.

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

В официальном репозитории Switchyard описаны режимы прямой передачи, маршрутизация через профили, классификатор запросов и этапный переход между слабой и сильной моделью. Документация также указывает на сбор статистики по задержке, токенам и стоимости. Это делает Switchyard удобным слоем для эксперимента, но не заменяет корпоративное бюджетирование и аудит. (github.com)

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

• исходный класс задачи;
• выбранная модель;
• результат проверки;
• причина повышения на более мощный маршрут;
• число вызовов до успешного ответа;
• стоимость всей операции, а не только первого обращения.

Если дешёвая модель проходит проверку только на простых запросах, её нельзя автоматически расширять на весь трафик. Правильное решение — ограничить область маршрута и записать условие возврата на сильную модель.

Пример логики маршрута

если запрос критичный:
    использовать сильный маршрут
иначе если формат фиксирован и контекст короткий:
    использовать экономичный маршрут
иначе:
    отправить классификатору
    при низкой уверенности использовать стандартный маршрут

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

Второй этап: установите бюджет контекста

Оптимизация начинается с разметки входа на четыре части:

1. системные инструкции;
2. текущая задача пользователя;
3. исторический контекст;
4. динамические результаты поиска и инструментов.

Для каждой части определяется срок полезности. Системные правила меняются редко, история может быть свёрнута, поисковая выдача быстро устаревает, а результат инструмента иногда действителен только в рамках одного шага.

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

Полезно также ввести лимит контекста на уровне класса задачи. Значение не должно быть единым для всех операций: анализ договора, короткая классификация и coding-agent используют разные объёмы входных данных. Если лимит превышен, система должна сначала выполнить сокращение, а не молча отправлять более дорогой вызов.

При сжатии нельзя удалять:

• идентификаторы документов;
• ограничения безопасности;
• обязательные поля результата;
• факты, на которых основано решение;
• сведения, необходимые для повторной проверки.

Можно удалять повторяющиеся инструкции, уже учтённые результаты и нерелевантные сообщения, если правило удаления проверено на контрольной выборке.

Официальное описание prompt caching объясняет, что кэшируемый префикс должен быть стабильным, а сведения об использованных кэшированных токенах доступны в структуре usage. Поэтому порядок элементов промпта влияет не только на читаемость, но и на возможность повторного использования. (openai.com)

Третий этап: добавьте кэш без нарушения изоляции

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

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

Ключ кэша должен учитывать как минимум:

tenant_id
project_id
model_id
prompt_version
input_fingerprint
permission_scope
data_expiry

Если исключить tenant_id или permission_scope, ответ одного клиента может попасть в контекст другого. Если не учитывать prompt_version, обновлённая инструкция продолжит получать старый результат. Если забыть data_expiry, кэш станет источником устаревшей информации.

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

В документации OpenAI указано, что prompt caches обычно очищаются после периода неактивности и не являются постоянным хранилищем. Поэтому провайдерское кэширование нельзя использовать как единственный механизм бизнес-кэша или аудита. (openai.com)

Четвёртый этап: ограничьте повторы и откаты

Политика повторов должна зависеть от класса ошибки:

Причина сбоя	Повтор	Задержка	Резервное действие
Временный сетевой сбой	Ограниченный	Экспоненциальная	Другой endpoint
Ограничение скорости	Ограниченный	С учётом Retry-After	Очередь или резерв
Тайм-аут	Ограниченный	Увеличение интервала	Короткий контекст
Невалидный формат	Не повторять вслепую	Нет	Исправление схемы или другой маршрут
Ошибка безопасности	Не повторять	Нет	Блокировка и журналирование

Количество попыток должно учитываться на уровне бизнес-запроса. Если один пользовательский запрос вызвал три обращения к модели и одно обращение к классификатору, именно пять вызовов должны попасть в показатель фактической стоимости.

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

Документация LiteLLM о маршрутизаторе и fallback-механизмах показывает распространённый подход к единому интерфейсу, повторным попыткам, резервным deployment и отслеживанию расходов. Эти функции полезно рассматривать как ориентир при проектировании AI Gateway, но конкретные параметры нужно проверять в используемой реализации. (docs.litellm.ai)

Пятый этап: свяжите расходы с проектом и владельцем

AI Gateway должен записывать не только токены, но и контекст их возникновения. Минимальная схема события:

request_id
tenant_id
project_id
environment
use_case
model_requested
model_selected
prompt_tokens
cached_tokens
completion_tokens
retry_count
fallback_count
latency
quality_result
estimated_cost

Поле request_id должно проходить через backend, очередь, Switchyard и журнал ответа. Тогда финансовый отчёт можно сопоставить с конкретной бизнес-операцией: обработкой документа, сообщением поддержки, запуском агента или сборкой кода.

Бюджет лучше разделять по нескольким уровням:

• общий лимит компании;
• лимит команды;
• лимит проекта;
• лимит окружения;
• лимит отдельного сценария;
• аварийный резерв для критичных операций.

Для каждого лимита нужны предупреждение и действие. Например, при приближении к порогу система уведомляет владельца, а при превышении запрещает новые некритичные запросы и оставляет доступ только к утверждённому маршруту.

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

Шестой этап: сделайте снижение стоимости проверяемым

Экономия должна измеряться не одним счётом. Для каждого класса запросов формируется контрольная выборка, а затем сравниваются четыре группы показателей:

• стоимость завершённой бизнес-операции;
• качество ответа;
• задержка;
• доля ошибок и повторов.

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

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

В актуальном руководстве OpenAI по выбору моделей отдельно подчёркивается необходимость сравнивать успешность задачи, полноту результата, число токенов, задержку и стоимость, а не объявлять улучшением одно лишь уменьшение числа вызовов. (developers.openai.com)

Три конфигурации для разных уровней зрелости

Уровень	Что настроено	Для каких задач подходит	Основной риск
Наблюдение	Единый шлюз, request_id, токены, модель и ошибки	Сбор исходной статистики	Расходы видны, но не управляются
Контролируемая оптимизация	Классы задач, лимиты контекста, кэш, ограниченные повторы	Внутренние сервисы и пилотные агенты	Неверно выбранные критерии качества
Динамическая маршрутизация	Switchyard, классификатор, повышение маршрута, бюджеты и контрольная выборка	Несколько проектов и моделей	Ошибка классификации масштабируется на весь трафик

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

Сравнение способов снижения расходов

Мера	Что уменьшает	Что может ухудшиться	Условие безопасного запуска
Переход на экономичную модель	Стоимость отдельного вызова	Точность и полнота	Контрольная выборка для конкретного класса
Сжатие контекста	Объём входных токенов	Потеря фактов или ограничений	Проверка сохранения обязательных данных
Прикладной кэш	Количество повторных вызовов	Актуальность и изоляция	Ключ с правами, версией и сроком действия
Prompt caching	Стоимость повторяемого префикса	Низкий hit rate при изменчивом промпте	Стабильная структура и наблюдение за usage
Ограничение повторов	Скрытое умножение вызовов	Доля завершённых запросов	Разные политики для сетевых и логических ошибок
Бюджет AI Gateway	Неконтролируемый рост	Отказы после лимита	Предупреждения, резерв и понятный fallback

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

Рекомендуемый порядок запуска

• [ ] Зафиксировать все точки вызова моделей и связать их единым request_id.
• [ ] Разделить отчётность минимум по проекту, окружению и типу операции.
• [ ] Записать исходные токены, повторы, fallback, задержку и качество.
• [ ] Выделить пять наиболее дорогих сценариев по стоимости завершённой операции.
• [ ] Для каждого сценария определить допустимую модель и минимальную планку качества.
• [ ] Сжать системные инструкции, историю и результаты инструментов без удаления аудиторских данных.
• [ ] Включить кэш только для повторяемых результатов с проверкой прав и срока актуальности.
• [ ] Настроить разные правила повторов для тайм-аутов, лимитов и невалидных ответов.
• [ ] Задать бюджеты по проектам и окружениям, а не только общий лимит API-ключа.
• [ ] Запустить Switchyard на ограниченной доле трафика или в изолированном тестовом контуре.
• [ ] Сравнить стоимость, качество, задержку и ошибки на одной и той же контрольной выборке.
• [ ] Оставить динамический маршрут только там, где критерии повышения и отката формализованы.

Какой порядок внедрения даст меньше риска

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

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

Этап приёмки	Обязательные данные	Решение
Базовая линия	Стоимость операции, токены, модель, повторы	Можно сравнивать изменения
Сжатие контекста	До/после по токенам и качеству	Оставить или откатить
Кэширование	Hit rate, актуальность, ошибки доступа	Расширить только безопасные ключи
Маршрутизация	Класс, выбранная модель, upgrade rate	Расширить проверенный класс
Бюджетирование	Расход по проекту и реакция на лимит	Настроить уведомление или блокировку
Production	Ошибки, задержка, качество, стоимость	Разрешить постоянную эксплуатацию

Частые вопросы

Почему расходы компании на LLM API могут расти при стабильном трафике?

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

Как Switchyard выбирает модель?

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

Как AI Gateway задаёт бюджет проекта?

В шлюзе проекту назначаются лимит, период сброса, предупреждение и действие при превышении. Учёт нужно вести по проекту, окружению, тенанту и назначению запроса. Важна связь с request_id: иначе команда увидит общий расход, но не сможет доказать, какой продукт или workflow его создал.

Может ли кэш уменьшить использование API?

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

Как проверить качество после понижения модели?

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

Когда изолированная среда лучше прямого запуска в production

Прямая интеграция нескольких поставщиков без промежуточного шлюза быстро приводит к разрозненным ключам, неравномерным логам, сложному бюджетированию и непрозрачным fallback-правилам. Облачный AI Gateway, в свою очередь, может оказаться неудобным для тестов с чувствительными данными, воспроизведения трафика или длительной отладки маршрутов.

Для эксперимента разумно сначала экспортировать реальные записи за одну неделю, обезличить их, воспроизвести в изолированной среде и только после проверки перенести правила в production. Если требуется временный контур для такого прогона, аренда Mac в nuvcloud может оказаться практичнее покупки отдельной машины: не придётся заранее оплачивать постоянное оборудование, а окружение можно использовать только на период эксперимента. Перед началом следует сверить условия помощи nuvcloud и выбрать подходящий формат доступа.

Такой вариант не заменяет собственную инфраструктуру при постоянной тяжёлой нагрузке, строгих требованиях к физическим интерфейсам или необходимости полного контроля над локальным оборудованием. Но для ограниченного теста маршрутизации, изоляции данных и воспроизведения вызовов он позволяет проверить архитектуру до того, как команда закрепит её в production и начнёт масштабировать расходы.

Частые вопросы

Почему расходы компании на LLM API могут расти даже при стабильном числе пользователей?

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

Как Switchyard выбирает модель для конкретного запроса?

Switchyard может работать как прокси с явным выбором модели, использовать профили маршрутизации или классификатор, который оценивает запрос перед отправкой. На практике безопаснее начинать с ограниченного набора классов: простые задачи, стандартные рабочие запросы и критичные операции. Каждый маршрут следует проверять на отложенной выборке, иначе классификатор может экономить токены за счёт незаметного падения качества.

Как задать бюджет проекта через AI Gateway?

Бюджет задаётся на уровне, который совпадает с финансовой ответственностью: проект, команда, окружение или клиентский тенант. Для каждого уровня нужны лимит, период сброса, предупреждение и действие при превышении. В мягком режиме шлюз сообщает об отклонении, в жёстком — блокирует новый вызов или переводит запрос на заранее разрешённый резервный маршрут.

Может ли кэш действительно уменьшить объём обращений к большой языковой модели?

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

Как сохранить качество после перевода части запросов на более дешёвую модель?

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