В AI-сервисах расход можно измерять токенами, API-запросами, обработанными минутами, документами или другими метриками.

Допустим, сервис обработал запрос и получил от AI-модели информацию: использовано 12 500 токенов. Или другой пример: сервис обработки документов знает, что клиент отправил 20 документов и на их обработку ушло 350 страниц, а клиенту в месяц доступно всего 3000 страниц. И где хранить эти 350 страниц? Кто должен посчитать, сколько клиент уже использовал за расчетный период? Кто должен определить, сколько ему еще доступно?

Факт расходования знает сам продукт. А вот дальше возможны варианты: можно самостоятельно считать расход или передавать информацию об использовании в биллинг. При этом стоимость использования в любом случае рассчитывает биллинг. Он применяет тарифные правила и определяет сумму начисления.

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

Что считается потреблением

Это может быть любая измеримая единица, связанная с ценностью продукта:

  • токены;

  • API-запросы;

  • обработанные документы;

  • обработанные минуты;

  • объем обработанных данных;

  • другие операции или ресурсы.

Например, в генераторе текста могут быть токены, в юридической платформе - количество проверенных договоров.

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

Факт использования всегда фиксирует AI-сервис

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

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

Кто считает потребление: AI-сервис или биллинг

И здесь возникает следующий вопрос: кто должен это потребление считать? И кто должен определять, сколько ресурса доступно пользователю?

AI-сервис считает потребление и контролирует лимит

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

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

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

Такой вариант подходит, если доступный объем используется при выполнении операций и продукту нужно самостоятельно контролировать лимит.

Биллинг считает потребление

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

Например, после обработки запроса можно передать в биллинг:

  • account_id: 123

  • operation: generation

  • unit: tokens

  • quantity: 12500

  • event_id: abc-456

Биллинг получает такие события и суммирует их за расчетный период. В LBX Биллинг мы еще добавили metadata - дополнительные параметры события (например модель AI или источник использования), которые сохраняют контекст потребления и позволяют использовать его для детализации клиенту и отчетности. Продукту не нужно самостоятельно вести этот накопленный учет.

Когда же нужно узнать доступный объем, можно получить эту информацию от биллинга.

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

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

Как выбрать между двумя вариантами

Тут важно понять, для чего требуется информация о потреблении.

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

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

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

Что рассчитывает биллинг

Допустим, пользователь использовал 7,3 млн токенов. Из этого значения еще не следует сумма начисления.

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

Биллинг получает данные о потреблении и применяет к ним тариф.

Он может определить:

  • какой объем входит в тариф;

  • какой объем является перерасходом;

  • какая ставка применяется;

  • какую сумму нужно начислить клиенту.

Например, сервис передает в биллинг информацию о том, что пользователь использовал 7,3 млн токенов. Биллинг уже сам решает, какая часть этого объема входит в тариф, какая тарифицируется отдельно и какая сумма должна попасть в начисление.

Итог

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

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

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

Комментарии (2)


  1. achekalin
    23.09.2026 23:32

    Кажется, самое интересное начинается сразу после последнего абзаца :)

    Кто именно суммирует usage — продукт или биллинг — вопрос скорее вторичный. Гораздо веселее становится, когда запрос выполнился, usage-event отправился дважды; либо не отправился вообще; либо клиент успел одновременно запустить десять генераций при остатке в 1000 токенов.

    Тут уже появляются idempotency по event_id, reservation/pre-authorize лимита, eventual consistency и reconciliation между продуктом и биллингом. И вот граница ответственности между ними становится действительно архитектурной задачей.

    А так как вводная схема — вполне понятная.


    1. lidia_zakharova Автор
      23.09.2026 23:32

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