Расчёт и прогнозирование стоимости API

При большом масштабе затраты на API для приложений с LLM могут оказаться неожиданно высокими. Один запрос, который кажется дешёвым при стоимости $0,002, превращается в $200 при 100 000 запусков. Без прогнозирования затрат и мониторинга функции ИИ могут привести к неожиданно большим счетам за облачные ресурсы, которые превысят все расходы на инфраструктуру.

Хорошая новость заключается в том, что затраты на LLM можно полностью предсказать до отправки запроса: Вы знаете модель, можете посчитать входные токены с помощью tiktoken и оценить количество выходных токенов на основе настройки max_tokens или исторических средних значений. Внедрение прогнозирования затрат в приложение с самого начала предотвращает неожиданные счета.

OpenAI отдельно взимает плату за входные токены и выходные токены, причём вывод обычно стоит в 3–4 раза дороже. Цены зависят от модели. Ориентиры на 2025 год (всегда проверяйте актуальную страницу с ценами, поскольку они меняются):

• gpt-4o-mini: около $0,15 за миллион входных токенов, около $0,60 за миллион выходных
• gpt-4o: около $2,50 за миллион входных токенов, около $10,00 за миллион выходных
• text-embedding-3-small: около $0,02 за миллион токенов

Разница в стоимости моделей огромна: один входной токен в gpt-4o примерно в 17 раз дороже, чем в gpt-4o-mini. Выбор модели — Ваш главный инструмент управления затратами: всегда начинайте с самой дешёвой модели, которая соответствует требованиям к качеству.

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

После каждого вызова API объект ответа содержит фактическое количество использованных токенов. Извлекайте эти данные, чтобы записывать реальные затраты и сравнивать их с оценками. Со временем разница между оценочным и фактическим количеством выходных токенов покажет, насколько точно Вы прогнозируете использование, а журналы предоставят разбивку затрат по функциям или группам пользователей.

Когда известны средняя стоимость запроса и ожидаемый объём запросов, прогнозировать ежемесячные затраты несложно. Создайте электронную таблицу с моделью затрат или простой скрипт на Python, позволяющий проверять разные предположения: что произойдёт, если число ежедневно активных пользователей удвоится? Что произойдёт, если добавить функцию, которая выполняет 3 вызова API вместо 1 на одно действие пользователя?

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

Ещё эффективнее стратегия маршрутизации по уровням: классифицируйте входящие запросы по сложности, направляя простые запросы к дешёвым моделям, а сложные — к дорогим. Даже если направлять 70% запросов к дешёвой модели, а 30% — к дорогой, можно сэкономить примерно 70% затрат на ИИ.

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

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

OpenAI предлагает пакетный API, который обрабатывает запросы асинхронно со скидкой 50% от стандартной цены. Если в Вашем случае задержка не критична — например, при обработке документов, ночном анализе или массовой генерации контента, — пакетный API позволит вдвое сократить затраты при минимальных изменениях кода.

Пакетные запросы отправляются в виде файлов JSONL, обрабатываются в течение 24 часов, а результаты извлекаются через API. Это идеально подходит для конвейеров предварительной обработки, которые запускаются по расписанию и не требуют ответов в реальном времени.

Всегда устанавливайте лимиты расходов, чтобы предотвратить неконтролируемый рост затрат. В панели управления OpenAI можно задать месячные лимиты расходов, после достижения которых доступ к API будет отключён. Установите жёсткий лимит на уровне максимально приемлемой суммы, а мягкий — на уровне 80% от неё, чтобы получить предупреждение по электронной почте до достижения жёсткого лимита.

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

Самый дешёвый вызов API — тот, который Вы вообще не выполняете. Реализуйте кэширование на уровне приложения, чтобы возвращать идентичные запросы из кэша, а не снова обращаться к API. Даже простой кэш Redis с ключом в виде хэша SHA256 запроса может устранить значительную долю повторных вызовов в рабочем приложении.

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

В рабочей среде Вам необходимо видеть затраты на ИИ с разбивкой по функциям, пользователям и моделям. Создайте панель мониторинга затрат: записывайте сведения о количестве токенов и связанные метаданные каждого вызова API (идентификатор пользователя, название функции, модель) в базу данных временных рядов. Затем выполняйте агрегацию, чтобы отвечать на такие вопросы: какая функция приводит к наибольшим расходам? Не создают ли опытные пользователи непропорционально высокие затраты? Растёт ли стоимость запроса после изменения запроса к модели?

Такая прозрачность необходима для принятия решений по оптимизации на основе данных, а не для предположений о том, где следует сокращать расходы. Большинство компаний обнаруживают, что 20% их функций обеспечивают 80% затрат на ИИ, поэтому оптимизация этих функций даёт непропорционально большой результат.

Проверьте, насколько хорошо Вы усвоили концепции разработки систем ИИ из этого урока.

В этом уроке Вы узнали, что стоимость API можно спрогнозировать до отправки запроса, подсчитав входные токены с помощью инструмента для подсчёта токенов и оценив количество выходных токенов, выбор модели — самый эффективный способ снизить затраты: gpt-4o-mini может быть в 17 раз дешевле gpt-4o для подходящих задач, а кэширование, пакетная обработка и лимиты расходов предотвращают неконтролируемый рост затрат в рабочей среде. Далее мы рассмотрим стратегии управления длинными беседами, которые превышают размер контекстного окна.