AI API Отчитане на използването API: Проследяване на LLM използване, цена, ключове, модели и клиенти

Отчитане на употребата на AI API API е програмен начин за отговор на прост, но критичен за бизнеса въпрос: откъде идва нашето използване и разходи за AI?

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

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

Какво трябва да прави AI API отчитане на използването API

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

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

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

Защо таблата за управление и фактурите не са достатъчни

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

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

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

Основният модел на данни: регистър на използването на ниво заявка

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

Практичният запис в счетоводната книга включва:

• ID на заявка и, когато е наличен, ID на заявка на доставчик.
• Акаунт, организация, екип, проект, работно пространство, API ключ, клиент, наемател, краен потребител, работно натоварване и идентификатори на средата.
• Заявен модел или псевдоним, разрешен модел на доставчик, доставчик, крайна точка, маршрут и ниво на услугата.
• Начален час, краен час, забавяне на отговора, група за агрегиране и период на фактуриране.
• Статус, клас на грешка, номер на повторен опит, резервна верига, състояние на анулиране и завършване на стрийминг състояние.
• Единици за използване като входни токени, изходни токени, кеширани четения, кеш записи, логически токени, единици за изображения, аудио продължителност, извиквания за търсене на файлове, извиквания за търсене в мрежата, хранилище на вектори, сесии с инструменти и брой партидни артикули.
• Версия на каталог за ценообразуване, прогнозна цена, уредена цена, цена, съобразена с фактура, валута, кредити, корекции и състояние на съгласуване.
• Защитени с поверителност метаданни, като дължина на съдържанието, хешове, категория на подканата или идентификатори на проследяване, без да се изисква необработена подкана и изходно хранилище по подразбиране.

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

Важни измерения на отчитането

Стойността на отчитането на използването API зависи от приписването. Броят на токените не е много полезен, ако цялото използване се записва под един споделен ключ или един общ проект.

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

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

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

Единиците за използване са по-широки от токените

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

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

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

Прогнозни, уредени и фактурирани разходи

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

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

Отчитането на разходите от AI API API трябва да изясни състоянието на разходите. Полета като estimated_cost, settled_cost, invoice_cost, cost_status, settlement_time, invoice_period, валута, provider_amount, reporting_amount, adjustment_amount и price_version помагат на потребителите да разберат кое число гледат.

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

Версии на каталог за ценообразуване

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

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

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

Поточно предаване, повторни опити, резервни и асинхронни задания

Отчитането на LLM е по-трудно от обикновеното API измерване, тъй като жизненият цикъл на заявката не винаги е чиста заявка-отговор събитие.

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

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

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

Агрегати, разбивка, експорти и пагиниране

Отчет API обикновено се нуждае от няколко модела за достъп.

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

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

Крайните точки за експортиране трябва да поддържат CSV, JSON и схеми, удобни за съхранение. По-големите експорти трябва да се изпълняват като идемпотентни задания, които могат да бъдат изпробвани повторно без дублиращи се редове или пропуснати страници. Екипите на Finance и FinOps може да искат вдъхновени от FOCUS таблици за разходи и използване за разпределение, наблюдение и оптимизация, но специфични за AI единици, като четения на кеша, извиквания на инструменти и генерирана медия, често се нуждаят от допълнителни колони.

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

Съгласуване между доставчици и фактури

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

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

Очаквайте разлики. Таблата за управление на доставчика може да се актуализират по-късно от регистрационните файлове на заявките. Периодите на фактуриране може да не съвпадат с местните клиентски периоди. Някои доставчици отчитат в UTC. Облачните таблици за таксуване могат да включват данъци, кредити или агрегиране на ниво проект. Персонализираните споразумения за ценообразуване може да не се виждат в отговорите по време на изпълнение. Доброто отчитане API не се преструва, че тези разлики не съществуват; дава на екипите полетата, за да ги обяснят.

Поверителност и задържане

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

Има случаи, в които заснемането на съдържание помага за отстраняване на грешки, преглед на злоупотреби или поддръжка. Ако съдържанието се съхранява, то трябва да се контролира от изрична политика, контрол на достъпа, ограничения на задържане и правила за редактиране. Регистрирането само на метаданни е по-безопасното по подразбиране за много системи за отчитане на използването на LLM.

Запазването трябва да бъде документирано. Често срещан модел е да се запази подробна история на заявките за по-кратък период и обобщени обобщения за по-дълго. Може да се наложи отчетите за фактуриране, насочени към клиента, да останат достъпни за живота на фактурата или договора.Вътрешните следи за отстраняване на грешки може да имат много по-кратък период на задържане.

Контрол на достъпа и граници на клиента

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

Контролът на достъпа трябва да съответства на модела на продукта. Индивидуалните разработчици могат да виждат само собствените си ключове. Администраторите на екипи могат да виждат всички проекти в работно пространство. Потребителите на Finance може да виждат разходите, но не и да изискват съдържание. Партньорите и дистрибуторите може да се нуждаят от отчети с обхват на клиента без видимост към несвързани наематели. Акаунтите за услуги трябва да имат тесни обхвати за експортиране и автоматизация.

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

Къде пасва шлюзът

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

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

За Model Gate конкретно, съответните възможности са унифицирано таксуване, API-ключово управление, анализ на използването, екипни контроли, хронология на заявките, транзакции, Telegram интеграции, обратни извиквания, крайни точки за баланс и автоматизация на партньор API в множество модели.Практическата стойност не е просто по-хубав доклад; това е последователен контролен слой за приписване, лимити, съгласуване и таксуване надолу по веригата.

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

Когато проектирате или оценявате AI API отчитане на употребата API, използвайте този контролен списък:

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

Често срещани грешки

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

Друг често срещан неуспех е загубата на приписване. Ако множество приложения, клиенти или среди споделят един и същ ключ, отчетът API не може да възстанови отговорността по-късно. Разпространете идентификатори на клиент, наемател, потребител, работно натоварване и среда по време на заявка.

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

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

Накрая, избягвайте да съхранявате необработени подкани като отговор по подразбиране на видимостта. Безопасните за поверителност метаданни обикновено отговарят на въпроси за докладване с по-малък риск.

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

Отчитането на употребата на AI API API трябва да даде на разработчиците, операторите, финансовите екипи и собствениците на продукти споделен, програмен поглед върху потреблението на AI. Устойчивият дизайн е регистър на ниво заявка с ясно приписване, необработени единици за използване, отделни състояния на разходите, версии на ценообразуване, произход на доставчика, полета за съгласуване и запазване, съобразено с поверителността.

За прототип на един доставчик може да са достатъчни таблата за управление на доставчика и администраторските API. За производствени системи, продукти, ориентирани към клиента, приложения с множество модели или работни процеси на дистрибутори, отчитането трябва да стане част от архитектурата на приложението.Шлюз като Model Gate може да осигури контролната точка, където се срещат API ключове, анализи на използването, транзакции, разрешения за екипи, унифицирано таксуване и работни потоци на партньор API, като същевременно запазва данните за доставчика, необходими за съгласуване на окончателната сметка.