Създайте AI API Billing Ledger: Офертирайте, резервирайте, уредете и съгласувайте всяко моделно обаждане

Клиентски AI API таксуване не може да бъде месечно експортиране на необработеното използване на доставчика. Ако шлюзът излага множество модели на наематели, екипи или партньори, таксуването трябва да отговори на по-сложен въпрос, преди да съществува фактурата: трябва ли тази заявка да бъде разрешена точно сега и как ще бъде обяснена цената й по-късно?

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

Тази статия описва този контролен цикъл за мултимоделен API шлюз. Полезно е дали шлюзът таксува вътрешни екипи, предплатени клиенти, клиенти на агенции или партньори надолу по веригата.

Проблемът с фактурирането: използването на доставчика не е фактура от клиента

Факт: основните доставчици на AI не излагат един универсален брояч на токени или една универсална цена. OpenAI публикува цени за модел с отделни входни, кеширани входни и изходни токени. OpenAI подканата за кеширане отчита използването на кеширания токен в полето за използване на отговор API. Anthropic документира отделни броячи за нормални входни жетони, входни жетони за създаване на кеш, входни жетони за четене на кеш и изходни жетони. Gemini ценообразуването разграничава входни, изходни и други категории токени, включително използване, специфично за модалност, като аудио токени.

Това означава, че шлюзът не може безопасно да таксува чрез умножаване на total_tokens по една цена. Нуждае се от специфични за доставчика адаптери зад схема за таксуване, неутрална спрямо доставчика.

Проблемът става по-видим в следните ситуации:

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

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

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

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

1. Акаунт на наемател: клиент, работно пространство, дистрибутор клиент или вътрешен разходен център.
2. Услуга с тарифи: версионни цени за доставчик, модел, клас на фактуриране, валута и правило за надценка.
3. Оценител: изчислява предварителна оферта от параметрите на заявката и политиката на модела.
4. Резервационна книга: съхранява бюджета преди да започне обаждането на доставчика.
5. Нормализатор на използването: преобразува специфичните за доставчика полета за използване във вътрешни таксуващи единици.
6. Задачи по уреждане и съгласуване: финализира таксите и ги сравнява със записите от страна на доставчика.

Контролният поток изглежда така:

client request
  -> authenticate tenant and key
  -> select model and rate-card version
  -> estimate input and max output cost
  -> reserve tenant balance
  -> call provider
  -> normalize returned usage
  -> settle actual cost
  -> release unused reservation
  -> emit invoice-ready ledger event

Важният избор на дизайн е искането не просто да се спазва. Финансово се контролира преди и след изпълнението.

Стъпка 1: оферта преди обаждането на доставчика

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

Входящите данни обикновено включват:

• ИД на наемател и план за таксуване;
• API ID на ключ или ID на проект;
• ID на доставчик и модел след прилагане на правилата за маршрутизиране;
• приблизителни некеширани входни токени;
• известна допустимост за кеширано въвеждане, ако е налично;
• max_tokens, max_output_tokens или еквивалентно ограничение на изхода;
• инструмент, изображение, аудио или други параметри на модалност;
• партньорско надценяване, отстъпка или правило за ценообразуване на дистрибутор;
• правила за валута и закръгляване.

Проста формула за кавички за генериране на текст може да бъде:

estimated_cost =
  estimated_uncached_input_tokens * input_rate
+ estimated_cached_input_tokens   * cached_input_rate
+ max_output_tokens               * output_rate
+ request_fee
+ partner_markup

Препоръка: когато крайната изходна дължина е неизвестна, резервирайте спрямо конфигурирания максимален изход. Ако приложението остави ограничението на изхода неограничено, шлюзът трябва да приложи клиент или модел по подразбиране. Изпълнението на бюджета не може да бъде детерминистично, ако няма максимална отговорност.

Това може да отхвърли някои заявки, които на практика биха били евтини. Това е компромисът. За предплатените системи по-сигурната настройка по подразбиране е песимистичната резервация с неизползвани средства, освободени след сетълмент. За фактурирани корпоративни клиенти екипите могат да разрешат меки надценки и да използват офертата главно за предупреждения.

Стъпка 2: резервирайте бюджет за наемател

Резервацията предпазва сметката на наемателя от изразходване на повече от позволеното салдо. Трябва да е атомарно: или резервацията е успешна и обаждането на доставчика може да започне, или заявката е отхвърлена, преди да бъдат направени каквито и да е разходи на доставчика.

Записът на резервация може да включва:

{
  "reservation_id": "res_01J...",
  "tenant_id": "tenant_123",
  "api_key_id": "key_456",
  "request_id": "req_789",
  "provider": "example_provider",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "quoted_amount": "0.032100",
  "currency": "USD",
  "status": "reserved",
  "expires_at": "2026-08-11T12:05:00Z"
}

Използване на кратки изтичания на резервациите за сривове в мрежата и прекъсване на връзката с клиенти. Заданието за почистване трябва да освободи изтекли резервации, които никога не са достигнали до уреждане. Въпреки това, не освобождавайте резервация само защото клиентът е прекъснал връзката; обаждането на доставчика все още може да завърши и да доведе до разходи. Проследете заявката на доставчика отделно.

Препоръка: направете резервацията идемпотентна чрез ID на заявка или ключ за идемпотентност. Повторните опити от клиенти, шлюзове или работници не трябва да създават множество бюджетни задържания за една и съща логическа заявка.

Стъпка 3: нормализиране на използването на доставчика

Отговорите на доставчика трябва да бъдат преобразувани в малка вътрешна схема. Поддържайте го стабилно дори когато доставчиците добавят нови полета за използване.

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

{
  "input_uncached_tokens": 1200,
  "input_cached_tokens": 800,
  "cache_write_tokens": 0,
  "output_tokens": 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": false
}

Тази схема умишлено не е идентична с отговора на нито един доставчик. Той улавя размерите на таксуването, от които се нуждаят фактурите, като същевременно запазва аварийните люкове за единици, специфични за доставчика.

Кешираните токени се нуждаят от собствен ред

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

Записите и четенията в кеша не винаги са еднакви

Някои доставчици правят разлика между създаване на записи в кеша и четене от кеша. Нормализаторът не трябва да приема, че кешираното въвеждане винаги означава една таксуваща ставка. Ако даден доставчик има токени за запис в кеша и токени за четене в кеша, съпоставете ги отделно или ги запазете като специфични за доставчика подединици.

Разсъжденията и скритите резултати се нуждаят от правила

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

Препоръка: фактурите, насочени към клиента, трябва да използват обикновен език. Например: „разсъждаващи изходни токени“ е по-ясно от необработено име на поле на доставчик. Поддържайте необработените полета на разположение за одит, но не принуждавайте всеки клиент да разбира вътрешността на доставчика.

Стъпка 4: уреждане на действителните разходи

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

Уредено събитие може да изглежда така:

{
  "ledger_event_id": "led_01J...",
  "event_type": "settlement",
  "tenant_id": "tenant_123",
  "request_id": "req_789",
  "reservation_id": "res_01J...",
  "provider": "example_provider",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "lines": [
    {
      "billing_class": "input_uncached_tokens",
      "quantity": 1200,
      "unit": "token",
      "unit_price": "0.00000250",
      "amount": "0.003000"
    },
    {
      "billing_class": "input_cached_tokens",
      "quantity": 800,
      "unit": "token",
      "unit_price": "0.00000125",
      "amount": "0.001000"
    },
    {
      "billing_class": "output_tokens",
      "quantity": 650,
      "unit": "token",
      "unit_price": "0.00001000",
      "amount": "0.006500"
    }
  ],
  "total_amount": "0.010500",
  "currency": "USD",
  "status": "settled"
}

Ако заявката е била запазена за 0.032100 и уредена на 0.010500, счетоводната книга освобождава 0.021600 обратно към наличния баланс.

Препоръка: Никога не преизчислявайте редове от стари фактури от текущата ценова таблица. Съхранявайте неизменни версии на тарифни карти и прикачвайте ИД на версията към всяка оферта, резервация и събитие за сетълмент. В противен случай фактурата може да стане невъзможна за възпроизвеждане, след като доставчик актуализира цените на модела.

Заявки за поточно предаване: резервирайте първо, уредете по-късно

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

Използвайте този работен процес:

1. Оценете входните токени и максималната изходна цена.
2. Запазете бюджет за наемател.
3. Отворете потока на доставчика.
4. Препращане на части към клиента.
5. Заснемане на окончателното използване, когато доставчикът го изпрати или когато е наличен последващ запис за използване.
6. Уреждане на действителните разходи и освобождаване на неизползвана резервация.

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

"usage_source": "gateway_estimate",
"is_estimated": true,
"reconciliation_status": "pending"

Препоръка: Ежедневното съгласуване трябва да дава приоритет на очакваните поточни събития, неуспешните заявки, изчакванията и повторните опити. Това са областите, които най-вероятно ще създадат разлики между записите на портала и фактурите на доставчика.

Правила за версия и маркиране на тарифната карта

Тарифната карта трябва да бъде обект с версии, а не променлива електронна таблица.

Минимум полета:

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

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

• Цена плюс: цена на доставчика плюс 20%.
• Фиксирана продажба на дребно: наемателят плаща фиксирана символична цена независимо от цената на доставчика.
• Многослойно: първо 10 милиона токена при една ставка, след това по-ниска ставка.
• Включени кредити: използването изгаря месечна надбавка, преди да започне таксуването на надвишаване.

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

Разделете счетоводната книга от анализа

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

Използване на анализ за въпроси като:

• Кои отбори използват най-много токени?
• Кои модели се развиват най-бързо?
• Къде бързото кеширане може да намали разходите?
• Кои ключове генерират необичайно скъпи заявки?

Използвайте счетоводната книга за въпроси като:

• Беше ли разрешено това искане срещу баланса на наемателя?
• Коя версия на тарифния план доведе до това таксуване?
• Освободена ли е неизползваната резервация?
• Фактурата на клиента съответства ли на уреденото използване?
• Използването на шлюза съответства ли на използването от страна на доставчика?

Факт: Семантичните конвенции на OpenTelemetry GenAI включват атрибути за използване на токени, като входни и изходни токени. Това е полезно за наблюдаемост и свързване на следи към разходни събития. Но атрибутите на телеметрията не са заместител на тарифните карти, резервациите, сетълмента, закръгляването и състоянието на фактурата.

Ежедневен работен процес за съгласуване

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

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

1. Групиране на събития в регистъра на шлюза по доставчик, модел, наемател или API ключ, клас на таксуване и UTC ден.
2. Извличане на използването от страна на доставчика, групирано по налични измерения, като API ID на ключ, модел и ден.
3. Нормализиране на експортирането на доставчик чрез същия код на адаптер, използван за отговори на заявки, където е възможно.
4. Сравнете количествата и разходите по клас на таксуване.
5. Разлика с флагове над праговете, като например 0,5% разлика в количеството или голяма разлика в абсолютните разходи.
6. Класифицирайте причините за отклонение: прогнози за поточно предаване, повторни опити, неуспешни заявки, отчитане на кеша, промени на псевдоними на модела, забавени записи на доставчик или липсващи идентификатори на заявки.
7. Създавайте събития за коригиране, вместо да редактирате стари събития за сетълмент.

Препоръка: използвайте ключове на доставчик API за наемател, когато това е оперативно осъществимо, защото опростява съгласуването. Ако това създава прекалено големи разходи за управление на ключове, съпоставете вътрешните идентификационни номера на клиенти с метаданните на доставчика, където се поддържат, и поддържайте надежден мост за идентификационен номер на заявка.

Редове във фактурите, които клиентите могат да разберат

Фактурата, обърната към клиента, не трябва да отразява доставчик JSON. Той трябва да обясни сметката със стабилни бизнес условия.

Полезни колони за фактури:

• период от време;
• наемател, проект или API етикет на ключ;
• модел или профил на модел;
• брой заявки;
• некеширани токени за въвеждане;
• кеширани токени за въвеждане;
• изходни токени;
• медия или инструментални единици, ако е приложимо;
• отстъпки, кредити или надценки;
• обща сума и валута.

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

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

Контролен списък за внедряване

Преди стартиране

• Дефинирайте нормализирани класове за таксуване за всички поддържани доставчици.
• Създаване на неизменни версии на тарифни планове с дати на влизане в сила.
• Изискване на ограничения на изхода или прилагане на настройките по подразбиране на шлюза.
• Прилагане на атомарни резервации с ключове за идемпотентност.
• Задайте правила за закръгляване за всяка валута.
• Решете как да фактурирате кеширани токени, логически токени, медийни единици и такси за заявки.
• Повторни опити за тестване, изчакване, прекъсване на връзката на клиента и грешки на доставчика.
• Изградете механизъм за коригиране на събития, вместо да редактирате уредени събития.

По време на обработка на заявка

• Удостоверяване на наемател и ключ.
• Разрешаване на окончателния модел след политиката за маршрутизиране и резервен вариант.
• Изберете правилната версия на тарифния план.
• Посочете цената в най-лошия случай.
• Запазете баланс или отхвърлете заявката.
• Идентификационен номер на заявка за доставчик на записи, когато е наличен.
• Нормализиране на използването от отговора.
• Уреждане, освобождаване на неизползвана резервация и излъчване на събития, готови за фактура.

След обработка на заявката

• Извършвайте ежедневно съгласуване по доставчик, ключ, модел, клас на таксуване и ден.
• Преглед на прогнозните споразумения за поточно предаване.
• Използване на модел с флаг с липсващи записи в тарифния план.
• Наблюдение на отклонението, причинено от отчитане на кеширани токени.
• Генерирайте визуализации на клиентски фактури преди окончателното таксуване.

Прогнози за планиране

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

Прогноза: клиентите ще очакват обяснения за използването на ниво заявка, ключ, проект и фактура. Общата месечна сума без проследими договорени позиции ще бъде недостатъчна за екипи, които препродават API достъп или налагат предплатени бюджети.

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

Приложимо заключение

Ако изложите няколко доставчици на AI през един шлюз, изградете счетоводната книга, преди оспорванията за фактуриране да предизвикат проблема. Започнете с четири гаранции:

1. Всяка таксувана заявка получава предварителна оферта.
2. Всеки предплатен или ограничен наемател има резервиран бюджет, преди да започне обаждането на доставчика.
3. Всеки отговор на доставчик се нормализира в стабилни класове за таксуване.
4. Всяка фактура може да бъде съгласувана с използването от страна на доставчика и точната версия на тарифния план, използвана в момента.

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

Свързано четене

• съединяване на LLM следи с използване и записи на разходите
• изграждане на портали за дистрибутори с измерване на използването на наематели
• използване на бързо кеширане, като същевременно поддържа разбираемост на таксуването