Как ограничить расходы на API нейросети: бюджет, тест и аварийная остановка

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

Нарисуйте один законченный сценарий

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

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

Считайте вход, выход и повторы отдельно

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

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

Поставьте три уровня границ

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

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

Не делайте бесконечные повторы

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

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

Проверяйте не только рубли

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

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

Контроль перед выпуском

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

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

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

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

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

Почему одинаковые вопросы стоят по-разному? Отличается переданная история, извлечённые фрагменты, длина ответа и число повторных вызовов.

Можно ли просто выбрать самую дешёвую модель? Только после сравнения качества принятой работы и полной стоимости маршрута, включая проверку человеком.