Бюджет на API нейросетей: метод расчета затрат проекта

Пословный подсчёт как финансовая ловушка

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

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

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

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

Математика токенизации: почему пословный подсчёт ведёт к убыткам

Базовая формула стоимости одного запроса к LLM выглядит прозрачно:

Стоимость запроса = (входные токены / 1 000 000 × цена входных токенов) + (выходные токены / 1 000 000 × цена выходных токенов)

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

Главная ошибка возникает, когда объём оценивают словами:

«У нас тысяча слов, значит, примерно тысяча токенов».

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

Нельзя и приписывать конкретному слову заранее установленное число токенов без проверки. Для токенизатора OpenAI и кодировки o200k_base результат зависит от точного текста и версии инструмента; у других провайдеров могут использоваться другие токенизаторы. Слово, написанное с заглавной буквы, с пробелом до или после него, внутри JSON-строки или рядом со знаком препинания, может быть разбито иначе. Поэтому корректный вопрос звучит не «сколько токенов обычно в слове», а «сколько токенов занимает именно наша репрезентативная выборка в том режиме, который использует приложение».

Что именно нужно измерить

Для первичного расчёта соберите несколько групп запросов:

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

Затем пропустите эти данные через официальный токенизатор, SDK или инструмент, рекомендованный для нужной модели. Там, где провайдер не предоставляет локальный токенизатор или не обещает полное совпадение локального подсчёта с биллингом, ориентируйтесь на usage-поля в ответах API и сверяйте их с данными в кабинете.

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

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

Формула прогнозирования: от базового запроса до retry multiplier

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

Для первого приближения формула выглядит так:

Месячные расходы = средняя стоимость запроса × количество исходных запросов × retry multiplier

Средняя стоимость запроса должна быть рассчитана отдельно для входных и выходных токенов:

Средняя стоимость запроса = средние входные токены × тариф входа + средние выходные токены × тариф выхода

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

Retry multiplier — коэффициент, который показывает, во сколько раз число фактических вызовов превышает число пользовательских или бизнес-запросов. Его нельзя назначать по универсальной таблице. Сначала зафиксируйте, какие события приводят к повтору:

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

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

Пример с явными допущениями

Предположим, приложение обрабатывает 100 000 запросов в месяц. На один запрос приходится в среднем 2 000 входных и 500 выходных токенов. Это не характеристика конкретной модели, а условный сценарий для демонстрации метода.

Если в тарифной таблице выбранного провайдера указана цена 0,10 доллара за миллион входных токенов и 0,40 доллара за миллион выходных токенов, расчёт без повторов будет таким:

• вход: 100 000 × 2 000 = 200 млн токенов;
• выход: 100 000 × 500 = 50 млн токенов;
• входная часть: 200 × 0,10 = 20 долларов;
• выходная часть: 50 × 0,40 = 20 долларов;
• всего: 40 долларов до учёта повторов, инструментов, налогов и других начислений.

При retry multiplier 1,10 стоимость той же нагрузки составит около 44 долларов, если повторы имеют такое же среднее соотношение входных и выходных токенов. Если же повторы происходят после длинного контекста, простое умножение может занизить расходы: повторный вызов в таком сценарии будет дороже среднего.

Для второго сценария возьмём 50 000 запросов, 10 000 входных и 1 000 выходных токенов на каждый. При условных тарифах 1 доллар за миллион входных и 5 долларов за миллион выходных токенов получится 500 долларов за вход и 250 долларов за выход, то есть 750 долларов до повторов. Это иллюстрация зависимости от объёма, а не обещание актуальной цены модели. При составлении сметы подставляйте тарифы из действующей таблицы провайдера на дату расчёта.

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

Перед запуском в продакшен проверьте:

1. Идентификатор модели. Значение в конфигурации должно точно соответствовать доступному ID из документации и тарифной сетки. Некорректный ID обычно приводит к ошибке API или отказу в маршрутизации, а не к автоматическому переключению на другую модель. Если в коде есть собственный fallback, именно его нужно явно учитывать в расчёте.

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

3. Реальную длину контекста. Измеряйте системный промпт, пользовательские данные, историю, результаты поиска и служебные поля в том виде, в каком они уходят по сети.

4. Распределение выходов. Ограничение max output tokens задаёт потолок, но не означает, что каждый ответ будет иметь такую длину. Снимайте фактические значения.

5. Задержку p50 и p95. Она влияет на вероятность таймаутов, очередь запросов и количество повторных попыток.

6. Отказы и tool calls. Дополнительные вызовы модели и инструментов должны быть связаны с исходной операцией и включены в её себестоимость.

7. Правила повторов. У каждого повтора должны быть лимит, причина и идентификатор исходной операции. Иначе невозможно отличить полезный retry от бесконечного цикла.

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

Экономия на масштабе: Batch API и кэширование промптов

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

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

Для расчёта экономии сравнивайте не рекламный процент, а две полные строки сметы:

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

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

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

Чтобы проверить эффект, отслеживайте:

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

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

Как считать оптимизацию без самообмана

Не записывайте в бюджет «экономия до 50%» как гарантированный результат. Корректнее построить три сценария:

Возьмём условный пример из предыдущего раздела: 200 млн входных и 50 млн выходных токенов в месяц. Если половина входного объёма приходится на кэшируемый префикс, а провайдер действительно применяет к нему пониженную ставку, итоговая экономия будет зависеть от цены чтения кэша и платы за его создание. Если cache hit rate оказался 20%, результат будет совсем другим. Поэтому обещание «сэкономим половину» следует заменять моделью, где меняются доля попаданий, объём стабильного контекста и тариф.

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

Инструментарий верификации: от tiktoken до платформ мониторинга

Расчёт на бумаге — гипотеза. Верификация — данные.

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

Отдельно проверьте, что именно входит в usage-метрики API. В некоторых системах отображаются входные и выходные токены, а для кэширования, рассуждений или инструментов используются дополнительные поля. Локальный подсчёт текста не всегда включает служебные компоненты, которые добавляет клиентская библиотека или сам API.

На этапе запуска подключите наблюдаемость для LLM-приложения. Helicone, Langfuse, Portkey и другие инструменты могут помочь собирать трассировки, стоимость, задержку и ошибки, но их ценность определяется настройкой. Важно не просто видеть общий счёт, а связать каждый вызов с:

• фичей и пользовательским сценарием;
• версией промпта;
• ID модели;
• окружением;
• типом запроса;
• количеством повторов;
• результатом валидации;
• наличием вызовов инструментов.

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

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

Полезны такие метрики:

• входные и выходные токены на исходный запрос;
• входные и выходные токены на завершённую операцию;
• retry rate;
• доля ошибок и таймаутов;
• средняя и перцентильная стоимость;
• cache hit rate;
• стоимость по версии промпта;
• доля ответов, ушедших на fallback-модель;
• стоимость tool calls;
• расход в день и накопительный расход за месяц.

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

Стратегия FinOps: лимиты, буферы и оповещения

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

Бюджет по фичам, а не одна общая сумма

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

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

Так становится видно, что рост счёта вызван не абстрактным «увеличением популярности AI», а, например, новой версией промпта, которая добавила историю диалога в каждый запрос.

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

Оповещения и ограничения

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

На стороне провайдера и собственного шлюза настройте ограничения:

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

Ограничение max tokens защищает от слишком длинного ответа, но не решает проблему бесконечных повторов. И наоборот, низкий лимит запросов не спасает от дорогого контекста, если каждый вызов содержит большой документ. Защита должна работать на нескольких уровнях.

Пересмотр модели и промпта

Стоимость следует пересчитывать при каждом существенном изменении:

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

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

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

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