Создайте книгу выставления счетов AI API: котируйте, резервируйте, рассчитывайте и согласовывайте каждый вызов модели

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

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

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

Проблема с выставлением счетов: использование услуг провайдера не является счетом клиента

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

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

Проблема становится более заметной в следующих ситуациях:

<ул>

Предоплаченные кредиты. шлюз должен отклонять запросы до того, как арендатор потратит деньги ниже нуля.

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

Потоковая передача. Ответ начинается до того, как станет известно окончательное использование токена.

Быстрое кеширование. Кэшированные входные данные могут быть дешевле, чем некэшированные, но только если измерять их отдельно.

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

Изменение цен поставщика. Счет за прошлый месяц должен по-прежнему воспроизводиться после изменения прейскуранта.

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

Основная архитектура

Надежная платежная архитектура состоит из шести компонентов:

<ол>

Учетная запись арендатора: клиент, рабочее пространство, клиент реселлера или внутренний центр затрат.

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

Оценщик рассчитывает предварительную цену на основе параметров запроса и политики модели.

Журнал резервирования: хранит бюджет до начала звонка поставщику.

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

Работы по расчетам и сверке: окончательно определите платежи и сравните их с записями поставщика услуг.

Поток управления выглядит следующим образом:

запрос клиента
  -> аутентифицировать арендатора и ключ
  -> выберите модель и версию прейскуранта
  -> оценить входную и максимальную выходную стоимость
  -> резервный баланс арендатора
  -> позвонить провайдеру
  -> нормализовать возвращаемое использование
  -> рассчитать фактическую стоимость
  -> освободить неиспользованное резервирование
  -> создать событие реестра готовности счета

Важный выбор дизайна заключается в том, чтобы запрос не просто выполнялся. Он подвергается финансовому контролю до и после исполнения.

Шаг 1: рассчитайте цену до звонка поставщика услуг

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

Вводы обычно включают в себя:

<ул>

Идентификатор клиента и тарифный план;

Идентификатор ключа API или идентификатор проекта;

идентификатор поставщика и модели после применения правил маршрутизации;

оценочное количество некэшированных входных токенов;

известное право на кэширование входных данных, если таковое имеется;

max_tokens, max_output_tokens или эквивалентное ограничение вывода;

инструмент, изображение, аудио или другие параметры модальности;

партнерская наценка, скидка или правило ценообразования для реселлеров;

валюта и политика округления.

Простой формулой цитаты для генерации текста может быть:

оценочная_стоимость =
  оцененные_uncached_input_tokens * input_rate
+ оцененные_cached_input_tokens *cache_input_rate
+ max_output_tokens * выходная_ставка+ запрос_комиссия
+ партнерская_разметка

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

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

Шаг 2. Зарезервируйте бюджет арендатора

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

Запись о резервировании может включать:

{
  "reservation_id": "res_01J...",
  "tenant_id": "tenant_123",
  "api_key_id": "key_456",
  "request_id": "req_789",
  "провайдер": "example_provider",
  "модель": "модель-а",
  "rate_card_version": "01.08.2026",
  "quoted_amount": "0,032100",
  "валюта": "доллар США",
  "статус": "зарезервировано",
  "expires_at": "2026-08-11T12:05:00Z"

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

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

Шаг 3. Нормализуйте использование провайдера

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

Практическая нормализованная схема использования:

{
  «input_uncached_tokens»: 1200,
  «input_cached_tokens»: 800,
  «cache_write_tokens»: 0,
  «выходные_токены»: 650,
  "reasoning_or_hidden_output_tokens": 0,
  "tool_or_media_units": [],
  "request_fee_units": 1,
  "provider_request_id": "prov_abc",
  "usage_source": "provider_response",
  «is_estimated»: ложь

Эта схема намеренно не идентична ответу какого-либо поставщика. Он фиксирует параметры выставления счетов, необходимые для выставления счетов, сохраняя при этом запасные варианты для единиц, специфичных для конкретного поставщика.

Кэшированным токенам нужна отдельная строка

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

Запись в кэш и чтение из кэша не всегда одинаковы

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

Рассуждения и скрытый вывод требуют политики

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

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

Шаг 4. Уточните фактическую стоимость

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

Урегулированное событие может выглядеть так:

{
  "ledger_event_id": "led_01J...",
  "event_type": "поселение",
  "tenant_id": "tenant_123",
  "request_id": "req_789",
  "reservation_id": "res_01J...",
  "провайдер": "example_provider",
  "модель": "модель-а",
  "rate_card_version": "01.08.2026",
  "линии": [
    {
      "billing_class": "input_uncached_tokens",
      «количество»: 1200,
      "единица": "жетон",
      "unit_price": "0,00000250",
      "сумма": "0,003000"
    },
    {
      "billing_class": "input_cached_tokens",
      «количество»: 800,
      "единица": "жетон",
      "unit_price": "0,00000125",
      "сумма": "0,001000"
    },
    {
      "billing_class": "output_tokens",
      «количество»: 650,
      "единица": "жетон","unit_price": "0,00001000",
      "сумма": "0,006500"
    }
  ],
  "total_amount": "0,010500",
  "валюта": "доллар США",
  "статус": "поселен"

Если запрос был зарезервирован для 0,032100 и урегулирован на уровне 0,010500, реестр освобождает 0,021600 обратно к доступному балансу.

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

Запросы на потоковую передачу: сначала зарезервируйте, затем согласуйте

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

Используйте этот рабочий процесс:

<ол>

Оцените входные токены и максимальную выходную стоимость.

Зарезервировать бюджет арендатора.

Откройте поток поставщика.

Пересылать фрагменты клиенту.

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

Урегулируйте фактическую стоимость и отмените неиспользованное резервирование.

Если окончательное использование недоступно, отметьте расчет как расчетный, а не притворяйтесь, что он точный:

"usage_source": "gateway_estimate",
«is_estimated»: правда,
"reconciliation_status": "ожидает"

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

Правила создания версий и наценки прейскурантов

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

Минимум полей:

<ул>

поставщик;

идентификатор модели;

класс расчета;

единица, например токен, запрос, изображение, аудиосекунда или единица инструмента;

цена за единицу;

валюта;

эффективные временные метки начала и окончания;

политика округления;

план клиента или правило разметки партнера;

ссылка на источник и метаданные утверждения.

Правила разметки должны быть ясными. Например:

<ул>

Затраты плюс: затраты поставщика плюс 20%.

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

Многоуровневое: сначала 10 миллионов токенов по одной ставке, затем по более низкой ставке.

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

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

Отделите книгу платежей от аналитики

Аналитика и выставление счетов имеют разные допуски. Аналитические данные можно агрегировать, откладывать, выбирать или корректировать. Выставление счетов должно быть полным, идемпотентным, проверяемым и объяснимым.

Используйте аналитику для таких вопросов, как:

<ул>

Какие команды используют больше всего токенов?

Какие модели растут быстрее всего?

Где оперативное кэширование может снизить затраты?

Какие ключи создают необычно дорогие запросы?

Используйте книгу счетов, чтобы ответить на такие вопросы, как:

<ул>

Был ли этот запрос разрешен на баланс арендатора?

Какая версия прейскуранта привела к такому списанию?

Было ли неиспользованное резервирование снято?

Соответствует ли счет клиента расчетному использованию?

Соответствует ли использование шлюза использованию на стороне поставщика?

Факт: Семантические соглашения OpenTelemetry GenAI включают атрибуты использования токенов, такие как входные и выходные токены. Это полезно для наблюдения и объединения трассировок с событиями стоимости. Однако атрибуты телеметрии не заменяют прейскуранты, резервирование, расчет, округление и состояние счета.

Ежедневный рабочий процесс сверки

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

Практическая ежедневная работа:

<ол>

Группируйте события реестра шлюза по поставщику, модели, арендатору или ключу API, классу выставления счетов и дню UTC.

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

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

Сравните количество и стоимость по классам выставления счетов.

Отметить превышение пороговых значений, например разницу в количестве на 0,5 % или большую абсолютную разницу в стоимости.

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

Создавайте события корректировки вместо редактирования старых событий урегулирования.

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

Строки счета-фактуры, понятные клиентам

Счет, ориентированный на клиента, не должен отражать JSON поставщика. Он должен объяснить законопроект с точки зрения стабильного бизнеса.

Полезные столбцы счетов:

<ул>

диапазон дат;

метка ключа клиента, проекта или API;

модель или профиль модели;

количество запросов;

некэшированные входные токены;

кешированные входные токены;

токены вывода;

носители или инструменты, если применимо;

скидки, кредиты или наценки;

общая сумма и валюта.

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

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

Контрольный список реализации

Перед запуском

<ул>

Определите нормализованные классы выставления счетов для всех поддерживаемых поставщиков.

Создавайте неизменяемые версии прейскурантов с датами вступления в силу.

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

Реализовать атомарное резервирование с помощью ключей идемпотентности.

Установите правила округления для каждой валюты.

Решите, как выставлять счета за кэшированные токены, токены обоснования, медиа-единицы и комиссию за запросы.

Повторные попытки тестирования, тайм-ауты, отключения клиентов и ошибки поставщика.

Создайте механизм корректировок вместо редактирования установленных событий.

Во время обработки запроса

<ул>

Аутентификация клиента и ключа.

Определите окончательную модель после политики маршрутизации и резервного варианта.

Выберите правильную версию прейскуранта.

Укажите наихудшую стоимость.

Зарезервируйте баланс или отклоните запрос.

Запишите идентификатор запроса поставщика, если он доступен.

Нормализация использования ответа.

Урегулирование, освобождение неиспользованного резервирования и создание событий готовности счета.

После обработки запроса

<ул>

Выполнять ежедневную сверку по поставщику, ключу, модели, классу выставления счетов и дню.

Просмотрите примерные расчеты за потоковую передачу.

Отметить использование модели при отсутствии записей в прейскурантах.

Отслеживание отклонений, вызванных учетом кэшированных токенов.

Создавайте предварительный просмотр счетов клиента перед окончательным выставлением счета.

Прогнозы для планирования

Прогноз: Биллинг AI API станет более многомерным, а не менее. Классы токенов, классы кэша, медиа-единицы, выполнение инструментов и счетчики, связанные с рассуждениями, вероятно, будут продолжать расширяться по мере изменения возможностей модели.

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

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

Практическое заключение

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

<ол>

Каждому оплачиваемому запросу предоставляется предварительная расценка.

Каждому арендатору с предоплатой или ограничением бюджета зарезервирован бюджет до начала звонка поставщику услуг.

Каждый ответ поставщика классифицируется по стабильным классам выставления счетов.

Каждый счет можно сверить с использованием на стороне поставщика и точной версией прейскуранта, используемой в данный момент.

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

Связанное чтение

• объединение трассировок LLM с записями использования и затрат
• создание порталов реселлеров с измерением использования арендаторами
• использование оперативного кэширования при сохранении понятности выставления счетов