Pay-per-inference биллинг: где ломается учёт вызовов модели
Считать вызовы модели проще, чем их тарифицировать. Счётчик фиксирует факт запроса, а стоимость определяют входной контекст и длина ответа: один и тот же вызов при длинном входе и коротком ответе отличается по потреблению в разы. Когда цена берётся из числа обращений, тарификация инференса перестаёт отражать нагрузку — тяжёлые сценарии списываются по цене лёгких.
Учёт вызовов модели ломается на повторных попытках и потоковой отдаче. Ответ оборвался на середине — обращение уже засчитано, клиент повторил запрос, и в журнале две записи там, где была одна операция. Пакетная обработка и кешированные ответы добавляют своё: один запрос приносит несколько результатов, а тарифицируется как единица.
Лимиты и квоты требуют резервирования, а не подсчёта по факту. Пока потребление списывается после ответа модели, параллельные запросы одного клиента проходят проверку одновременно и уводят его за порог; предоплаченный остаток обнуляется в минус, а разницу приходится списывать задним числом или прощать.
Дальше начинаются спорные списания. Без журнала, где у каждого обращения есть идентификатор, версия модели, объём входа и выхода и признак повторной попытки, расхождения в счетах нечем подтвердить — обе стороны опираются на слова. Разбираем, как это закрывается.
Измеримый эффект: точность списаний и простои
Эффект от переработки биллинга измеряется не ощущениями, а набором контрольных точек — мы снимаем их на стенде до запуска и на проде после. Ниже перечень, по которому принимаем работу: каждая позиция либо выполнена, либо нет, и это видно в отчётах.
- Точность списаний — расчётный журнал сверяется с фактическими вызовами модели: расхождение в пределах долей процента, неучтённые вызовы остаются единичными случаями, а не системной потерей.
- Доля спорных списаний — операции, которые не сопоставляются со счётом, держим ниже 1% и разбираем автоматическим правилом, без ручного пересчёта.
- Закрытие периода — вместо выгрузок на несколько дней отчёт закрывается за часы: агрегаты считаются по мере поступления событий.
- Пиковая нагрузка — кратный рост потока вызовов не теряет события: приём и расчёт разведены, поэтому всплеск растягивается, а не превращается в дырку в счёте.
- Повторные вызовы — идемпотентность по ключу запроса: ретрай клиента или обрыв соединения не приводят к двойному списанию, дубли отсекаются на входе.
- Простой биллинга — при отказе узла списания принимаются в буфер и доезжают после восстановления, окно потери данных измеряется минутами, а не часами.
- Наблюдаемость — отклонения и скорость обработки событий видим в Grafana, алерт приходит раньше, чем клиент заметит расхождение в счёте.
Модели тарификации pay-per-inference: сравнение подходов
Любая модель тарификации опирается на один слой учёта: каждый вызов модели пишет событие — арендатор, модель, объём потреблённых токенов. Тариф — это правило, по которому события превращаются в списание. Поэтому режим выбирают не по удобству биллинга, а по форме нагрузки и по тому, сколько расхождений при сверке готов терпеть заказчик.
Режимы редко живут поодиночке: подписка закрывает базовый объём, а вызовы сверх лимита уходят в отдельный тариф. Ниже — сравнение по нагрузке и сверке: где режим ведёт себя предсказуемо, а где начинает мешать.
| Режим | Когда подходит | Ограничения по нагрузке и сверке |
|---|---|---|
| Тарификация по вызовам | Неровный поток, ценность вызова легко измерить | Требует точного журнала событий; при пиках счёт для клиента непредсказуем |
| Пакетные схемы | Стабильный объём, нужно заранее зафиксировать лимит | Нужна политика на неиспользованный остаток: перенос или сгорание |
| Подписка | Регулярное потребление, клиенту важен ровный платёж | Жёстко ограничивает объём; превышение лимита требует отдельного правила |
| Гибрид | Базовый объём стабилен, пики сезонны | Две сущности учёта — сверка и отчётность усложняются |
| Предоплаченный баланс | Разовые проекты, самообслуживание | При исчерпании баланса вызовы отклоняются; нужны порог и уведомления |
Общее ограничение у всех режимов одно: списание не точнее журнала событий под ним. Повторная доставка, потеря ответа, ретраи со стороны клиента — всё это либо гасится идемпотентным ключом вызова, либо превращается в расхождения.
Этапы внедрения биллингового контура
Биллинг pay-per-inference ломается не на модели, а на учёте: ретраи, отменённые стримы и частично отданные ответы превращаются в спорные строки в счёте. Поэтому начинаем с инвентаризации событий, а не с кода.
- Аудит учёта. Собираем источники событий — журналы шлюза, метрики модели, логи доступа — и фиксируем, где теряется факт запроса и как идентифицируется клиент. На выходе карта учёта с перечнем дыр.
- Схема тарификации. Выбираем единицу: токены, вызовы или время инференса; задаём округление, градации по моделям, лимиты и поведение при их превышении. Схему согласуем таблицей до написания кода.
- Настройка контура. Ставим счётчики с идемпотентностью по идентификатору запроса, агрегируем в расчётные периоды, привязываем тариф к клиенту. Ретраи и отмены обрабатываем так, чтобы один вызов не попал в счёт дважды.
- Тестовые прогоны. Гоняем синтетику и теневой трафик, сверяем суммы биллинга с сырыми логами. Граничные случаи: разрыв стрима, отмена на середине, повторная отправка, пустой ответ.
- Акт сверки. Сводим расчёт с фактическим потреблением за период и разбираем расхождения по источникам до нуля. После подписи акта цифрам можно доверять.
- Передача регламентов. Отдаём описание схемы тарификации, процедуру разбора расхождений, алерты на аномалии и доступы. Команда заказчика закрывает типовые вопросы сама.
Схемы учёта, политики лимитов и документация
Работа над биллингом по модели pay-per-inference заканчивается не запуском, а передачей контура: заказчик должен сам менять лимиты, читать начисления и объяснять расхождения. Поэтому всё, что мы проектируем, остаётся в артефактах — от схемы учёта до регламента сверки.
- Схема учёта: что считается вызовом, где фиксируются вход и выход, как корректно закрывается потоковый ответ при таймауте или обрыве.
- Конфигурация тарифов: привязка модели к цене за единицу, версионность тарифов, справочники моделей, правила округления.
- Политики лимитов: пороги на ключ, команду и проект, поведение при исчерпании — мягкий отказ или деградация, исключения для внутренних задач.
- Регламент сверки: как сходятся счётчики провайдера и наши, где хранится журнал расхождений, кто и в какой срок закрывает инцидент.
- Панели мониторинга и оповещения: расход по проектам, доля отказов, отклонение фактического потребления от ожидаемого.
- Инструкции для поддержки: как найти начисления по ключу, перевыпустить ключ, что делать при аномальном росте расхода.
- Матрица ролей и доступов: кто меняет лимиты, кто видит финансы, кто работает только с логами.
- Передача контура: репозиторий, схемы данных, миграции, окружения и порядок выката изменений.
Отдельно передаём журнал решений — почему выбрана такая гранулярность учёта, какие компромиссы приняли по идемпотентности и потоковым ответам. Новая команда не переоткрывает эти споры заново, а правки в биллинг вносит по документированным правилам.
Кейс: как убрали расхождения в списаниях
Что было
Платформа отдавала доступ к нескольким моделям: генерация текста, распознавание, векторные представления. Учёт шёл по событиям от сервисов-исполнителей, и при повторе запроса после таймаута одно обращение попадало в счёт дважды. Расхождения в списаниях доходили до 4% обращений, доля спорных счетов — около 5%, а сверку поддержка делала руками: два-три дня в конце каждого расчётного периода.
Что изменили
Событие стало формироваться в одной точке — на шлюзе перед вызовом модели — и уходило в поток на Kafka. У каждого вызова появился ключ идемпотентности, а учётный сервис пишет журнал только на дозапись: повтор с тем же ключом отбрасывается, а не суммируется. Тариф и объём токенов фиксируются в том же событии, поэтому сумма в счёте восстанавливается из первичных данных.
Что стало
Расхождения в списаниях упали ниже 0,1% обращений, доля спорных счетов — до 0,4%. Автосверка идёт ежедневно, занимает 10-15 минут и поднимает алерт при отклонении выше порога: ошибка видна на следующий день, а не при закрытии периода. Класс отказов «двойное списание при повторе» закрыт схемой данных — обработчик не может применить одну операцию дважды.
Перед сменой схемы расчёт месяц шёл в теневом режиме: старый и новый считались параллельно, расхождения разбирали построчно. С поддержки ушла большая часть обращений про счёт — типовой вопрос разбирается по журналу вызова за пару минут.
Что делать, если биллинг уже работает на самописном учёте?
Самописный учёт почти не переписывают с нуля — его достраивают до управляемого контура. Обычно он уже собирает поток событий и агрегаты, но в нём нет устойчивости к повторным запросам, чётких границ отчётного периода и возможности пересчитать закрытый месяц — отсюда и накопленные расхождения. Первый шаг — зафиксировать текущую логику как эталон и снять с неё поведение на исторических данных.
Ключ — держать журнал использования отдельно от агрегатов: сырые события с ключом, моделью, расходом на входе и выходе, признаком попадания в кэш и признаком повтора позволяют пересчитать любую сумму заново и объяснить её. Тогда сверка расхождений идёт не «по итогу месяца», а по каждой позиции, и у каждой находится причина: двойной учёт при повторе, сдвиг границы периода по часовому поясу, потерянный расход при потоковом ответе, округление на агрегации. Для биллинга pay-per-inference это и есть источник истины.
Миграция данных делится на справочную и событийную. Справочная — сопоставление клиентов, аккаунтов и ключей с историческими балансами и лимитами; событийная — перенос сырых событий за период сверки, чтобы новый контур воспроизвёл те же цифры. Пока суммы не совпали, начисления идут по старым правилам.
Поэтапное внедрение строится так: сначала теневой режим, где новый контур считает параллельно и ничего не списывает; затем списание переводится на часть аккаунтов, остальные продолжают идти через старый учёт. На каждом шаге — отчёт сверки и порог расхождения, при котором шаг откатывается. Полный переход возможен только после того, как расхождения на живом потоке сведены к объяснимым.
Так учёт перестаёт быть чёрным ящиком: любую сумму можно разложить до события, а расхождение — показать клиенту до того, как он его заметит.
Технические сомнения: повторные вызовы, лимиты, сверка
Пять вопросов чаще всего звучат, когда выбирают подрядчика по учёту потребления моделей. Все они про одно: как ведёт себя pay-per-inference, когда запросы идут пачками, падают по таймауту и расходятся с тем, что клиент видит в отчёте.
Что происходит при повторных вызовах и ретраях?
Запрос с тем же идентификатором операции попадает в дедупликацию: в начисление идёт первый успешный вызов, остальные помечаются как дубли. Если результат до клиента не дошёл, событие списания не создаётся вовсе — фиксируется доставка ответа, а не факт отправки.
Как задаются лимиты и квоты?
Ограничения ставятся на уровне ключа, клиента и модели — отдельно по числу вызовов и по объёму обработанного текста за окно времени. При исчерпании работает либо мягкий режим с очередью и понятным ответом, либо жёсткий отказ; правило меняется без перезапуска сервиса.
Как устроены возвраты списаний?
Ошибочное начисление откатывается компенсирующей операцией, а не удалением записи, — остаётся след: кто, когда и по какой причине вернул. Массовый возврат идёт пакетом по выборке за период, с журналом по каждой позиции.
Как проходит сверка сумм и что делать с расхождениями?
Агрегаты по клиенту и модели сходятся с первичными событиями регулярно, расхождения автоматически попадают в отчёт для разбора. Итог в отчёте всегда собирается из событий, а не из заранее посчитанного итога, поэтому любую строку можно развернуть до конкретного вызова.
Не ляжет ли учёт на нагрузку основного контура?
События пишутся асинхронно, вне критического пути ответа модели, — рост числа вызовов не добавляет задержки генерации. Буфер переживает рестарт сервиса: при обновлении ни одно событие не теряется.
Обсудим задачу: схема учёта и тарификации
Чтобы обсуждение задачи шло по фактам, а не по общим соображениям, нужен доступ к текущей схеме учёта: как фиксируется обращение к модели, в какой момент появляется событие тарификации и как оно доходит до счёта. Разбор текущей схемы обычно выявляет основное быстрее, чем последующая сверка расхождений — двойной учёт повторных запросов, потерянные события при таймауте, расхождение единиц измерения.
Для предметного разбора достаточно прислать:
- Схему потока запроса: от входной точки до ответа модели, с пометкой, где именно фиксируется факт обработки.
- Выгрузку журналов за период: идентификатор запроса, модель, длительность, статус, признак повторной попытки — по ним видно, где журнал расходится со счетами.
- Текущую логику тарификации: единица учёта (обращение, токены, время работы), правила округления, обработка отказов, таймаутов и частично выполненных запросов.
- Описание интеграций биллинга: как формируются лимиты и предоплата, куда уходят события, кто и как делает сверку.
- Требования к отчётности: разрезы по клиентам, моделям и периодам, которые должны сходиться без ручных правок.
- Ограничения контура: пиковые значения нагрузки, требования к задержке учёта, политика хранения и обезличивания данных.
После этого вернёмся с планом внедрения, оценкой объёма работ и разбивкой по этапам — от схемы учёта и идемпотентной обработки событий pay-per-inference до сверки и отчётности. Если данных пока мало, сформулируем минимальный набор проверок на ограниченном контуре: опишите задачу, и мы предложим, с чего начать.
