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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

приблизителна_цена =
  приблизителни_некеширани_входни_токени * входна_скорост
+ приблизителни_кеширани_входящи_токени * кеширана_входяща_скорост
+ max_output_tokens * output_rate+ заявка_такса
+ partner_markup

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

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

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

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

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

<пре><код>{ "reservation_id": "res_01J...", "tenant_id": "tenant_123", "api_key_id": "ключ_456", "request_id": "req_789", "доставчик": "пример_доставчик", "модел": "модел-а", "rate_card_version": "2026-08-01", "quoted_amount": "0,032100", "валута": "щатски долари", "статус": "запазен", "expires_at": "2026-08-11T12:05:00Z" }

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

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

Стъпка 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...", "доставчик": "пример_доставчик", "модел": "модел-а", "rate_card_version": "2026-08-01", "линии": [ { "billing_class": "input_uncached_tokens", "количество": 1200, "единица": "жетон", "единична_цена": "0,00000250", "сума": "0,003000" }, { "billing_class": "input_cached_tokens", "количество": 800, "единица": "жетон", "единична_цена": "0,00000125", "сума": "0,001000" }, { "billing_class": "output_tokens", "количество": 650, "единица": "жетон","единична_цена": "0,00001000", "сума": "0,006500" } ], "обща_сума": "0,010500", "валута": "щатски долари", "статус": "уреден" }

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

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

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

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

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

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

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

"usage_source": "gateway_estimate",
"is_estimated": вярно,
"състояние_на_съгласуване": "чакащо"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изпълнимо заключение

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

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

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

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

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