Как разработчикам игр рассчитать стоимость длинных диалогов с ИИ

1. Определите единицу измерения для оценки

Сначала выберите четкую единицу измерения: например, стоимость инференса модели за диалоговую сессию, за активный игроко-день или за 1 000 сессий. Для оценки по сессиям определите, когда сессия начинается и заканчивается. Практическим правилом может быть «от первого диалогового запроса до 30 минут без запросов», однако этот таймаут — вопрос договоренности при измерениях, а не универсальный стандарт. Зафиксируйте его, чтобы другой разработчик мог воспроизвести расчет.

Считайте запросы к модели, а не просто сообщения игрока. Одно взаимодействие может породить несколько вызовов — например, ответ, за которым следует отдельный вызов инструмента — а повторные попытки (retries) могут еще больше увеличить их число. Если в игре используется голос, ввод изображений, поиск (retrieval) или инструменты, учитывайте их в отдельных полях затрат и параллельно фиксируйте связанные с ними токены модели. Тарифы провайдеров могут включать плату за инструменты или специфические ставки для разных модальностей помимо стандартной оплаты за токены текста; например, OpenAI указывает отдельные сборы за инструменты и отмечает, что токены модели, использованные для встроенных инструментов, тарифицируются по ставкам выбранной модели (OpenAI API pricing).

2. Измеряйте фактическое количество токенов на запрос

Для каждого вызова логируйте провайдера, идентификатор модели, временную метку, идентификатор сессии, цель запроса, количество входных токенов, количество выходных токенов и любую предоставляемую детализацию по кешированным токенам или токенам рассуждений (reasoning tokens). Фиксируйте повторные попытки, ошибки, вызовы инструментов и то, завершился ли вызов успешно. Избегайте хранения самого содержимого диалога, если оно не требуется для отдельно обоснованных целей продукта; для оценки затрат обычно достаточно итогового количества токенов и операционных метаданных.

Используйте данные о потреблении, предоставленные провайдером по завершенным вызовам, в качестве основного источника измерений. Предварительный подсчет полезен для тестирования структуры промпта, но он может не совпадать с финальными полями в счете. OpenAI указывает в документации, что сообщаемый объем вывода включает токены помимо видимого текста, такие как некоторые токены форматирования и структурные токены инструментов, и рекомендует не оценивать вывод исключительно по тому, что видит игрок (OpenAI token-counting guide). Документация Google Gemini аналогичным образом разделяет количество токенов промпта, кешированного содержимого, кандидатов вывода и токенов рассуждений в метаданных использования (Gemini token guide).

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

3. Учитывайте рост истории и повторное использование контекста

Во многих диалоговых системах каждый запрос включает текущую реплику пользователя плюс часть или всю историю переписки. Если история пересылается снова и снова, объем входных токенов может расти с каждым ходом, даже если сообщения игрока остаются короткими. Измеряйте фактический объем полезной нагрузки (payload), отправляемой модели; не умножайте размер промпта за один ход на количество ходов, если только реализация действительно не отправляет каждый раз одинаковый объем.

Кеширование меняет тариф, применяемый к подходящему под условия повторному вводу; это не означает, что весь диалог становится бесплатным или что непрерывная сессия гарантирует попадание в кеш. OpenAI описывает кеширование промптов как повторное использование неизмененного префикса промпта и отмечает, что новый ввод все равно должен обрабатываться. Ее средства диагностики кеша помогают измерять попадания (reads) и промахи (misses) (OpenAI prompt-caching guide). Anthropic точно так же разделяет операции записи в кеш и чтения из кеша, публикуя для них раздельные тарифы и время жизни кеша (Anthropic pricing and prompt caching).

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

4. Применяйте тарифы с помощью прозрачного расчета

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

стоимость сессии = (некешированный ввод × ставка за ввод + кешированный ввод × ставка за кешированный ввод + запись в кеш × ставка за запись в кеш + вывод × ставка за вывод) ÷ 1 000 000 + другие применимые расходы

Используйте ставки для конкретной модели, эндпоинта, модальности, региона и уровня обслуживания в развернутой конфигурации. Проверяйте их независимо на странице тарифов провайдера непосредственно перед составлением бюджета; расценки и каталоги моделей меняются. Включайте расходы на хранение, если за объем закешированных токенов и длительность их хранения взимается плата. Например, в опубликованных тарифах Gemini указаны категории токенов для платного использования и стоимость часа хранения для определенных конфигураций кеширования контекста, а в платежной документации входные, выходные, кешированные токены и длительность хранения кеша названы тарифицируемыми факторами (Gemini pricing; Gemini billing).

Пример расчета делает предположения наглядными. Предположим (исключительно для иллюстрации), что измеренные вызовы в рамках одной сессии содержат 18 000 некешированных входных токенов, 12 000 кешированных входных токенов и 6 000 выходных токенов. Применение тарифов платного уровня Gemini 3.8 Flash, опубликованных для использования до 31 декабря 2026 года ($0,75 за миллион входных токенов, $0,075 за миллион кешированных токенов и $3,75 за миллион выходных токенов), дает $0,0135 + $0,0009 + $0,0225, то есть $0,0369 до учета платы за хранение кеша или других сборов. В этом примере предполагается, что указанные кешированные токены тарифицируются по ставке для кеша, и не учитываются начальные затраты на создание кеша сверх измеренных итогов. Срок действия тарифов ограничен по времени, и их следует перепроверить при расчете на более поздний период (Gemini pricing).

5. Учитывайте распределение длительности сессий

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

Например, если в выборке много коротких сессий и небольшое число очень длинных, укажите как долю сессий в каждой группе, так и стоимость каждой группы. Прогноз для 10 000 сессий в таком случае можно рассчитать как сумму произведений (число сессий в группе × средняя стоимость в группе), вместо того чтобы предполагать, что каждая сессия похожа на общую медиану. Если характер использования существенно различается в зависимости от режима игры, языка, платформы или статуса игрока (новый или вернувшийся), стратифицируйте эти группы перед их объединением. Выбор сегментации — это аналитическое решение; объясните, почему каждый сегмент может изменить расход токенов или характер запросов.

6. Документируйте неопределенность и обновляйте оценку

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

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

Продолжить изучение темы