Как да създадете LLM Cost Ledger за всеки екип в множество AI API

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

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

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

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

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

Факти

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

Препоръка

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

Архитектурата на Ledger

Дневникът на разходите има пет основни компонента:

1. Стабилна схема на размерите на разходите.
2. Идентификационни данни с обхват и правила за маршрутизиране.
3. Улавяне на метаданни на ниво заявка.
4. Използване на доставчика и приемане на разходите.
5. Ежедневно съгласуване и прилагане на правилата.

Целта е да се създадат два свързани изгледа: прогнозна книга за всяка заявка за операции и съгласувана дневна книга за финанси.

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

Стъпка 1: Дефинирайте размерите на разходите преди изграждането на табла за управление

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

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

• team_id: притежаващият инженерен или бизнес екип.
• product_id: продуктът, функционалната област или вътрешната платформа, използваща API.
• среда: производство, постановка, разработка, пясъчник, демонстрация или тест.
• натоварване: чат, обобщаване, извличане, класифициране, генериране на код, оценка, вграждане, прекласиране или групова обработка.
• customer_segment: корпоративни, средни пазарни, безплатен пробен период, вътрешни, партньорски или други одобрени сегменти.
• budget_owner: лицето, екипът или разходният център, отговорен за разходите.
• доставчик: доставчикът на AI API, използван за заявката.
• модел: точният модел или идентификатор на внедряване.
• request_class: интерактивен, фонов, партиден, повторен опит, резервен, оценка или администриране.

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

Подробности за внедряването

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

<предварителен код>{ "schema_version": "2025-01", "team_id": "платформа-ai", "product_id": "поддръжка-асистент", "среда": "производство", "натоварване": "обобщаване", "customer_segment": "предприятие", "собственик_на_бюджет": "разходен център-4812","request_class": "интерактивен" }

Стъпка 2: Издайте ключове с обхват по екип и среда

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

Използвайте идентификационни данни с обхват, когато е възможно:

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

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

Забележка за сигурност

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

Стъпка 3: Заснемане на метаданни на заявката на шлюза или приложния слой

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

За всяко LLM обаждане заснемете:

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

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

Не регистрирайте всичко по подразбиране

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

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

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

Прогнозна книга на заявка

Тази таблица поддържа операции в почти реално време. Тя е подробна, бърза и приблизителна.

Полезните колони включват:

• request_id
• provider_request_id
• клеймо за време
• team_id
• product_id
• околна среда
• работно натоварване
• доставчик
• модел
• таксувани_единици
• rate_card_version
• estimated_cost_usd
• latency_ms
• статус_код
• retry_count
• fallback_used
• cache_status

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

Ежедневна книга, съгласувана с фактури

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

Полезните колони включват:

• data_на_фактуриране
• доставчик
• invoice_account
• project_or_workspace
• team_id
• product_id
• околна среда
• estimated_cost_usd
• provider_reported_cost_usd
• allocated_adjustment_usd
• reconciled_cost_usd
• variance_reason

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

Стъпка 5: Съгласувайте ежедневно, а не ръчно в края на месеца

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

1. Непрекъснато поглъщане на събития в регистъра на ниво заявка.
2. Поглъщане на записи за използване и разходи на доставчика по график.
3. Групирайте вътрешни прогнози по доставчик, проект или работно пространство, модел, дата и известни измерения на разпределението.
4. Сравнете вътрешните прогнози с отчетените от доставчика общи разходи.
5. Разпределете разликите с помощта на документирана политика.
6. Напишете причините за отклонението и статуса на съгласуване.

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

Примерна политика за съгласуване

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

Тази политика не е съвършена, но е обяснима. Обяснимостта е по-важна от фалшивата точност.

Стъпка 6: Прикрепете бюджети и контроли към размерите на Ledger

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

Използвайте различни контроли за различни натоварвания:

• Sandbox: твърди дневни или седмични ограничения, автоматично изключване, нисък праг за одобрение.
• Разработка: меки сигнали плюс скромни твърди ограничения.
• Оценка: пакетни прозорци, изричен собственик на бюджета, дата на изтичане.
• Производство: меки сигнали, работен процес за ескалация, път за увеличаване на спешния лимит.
• Използване на API от партньор или клиент: разпределение на ниво клиент, прилагане на квоти и наблюдение на злоупотреби.

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

Стъпка 7: Откриване на аномалии извън общите разходи

Общите дневни разходи са закъснял сигнал. По-добрите сигнали използват оперативните полета на книгата.

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

• Цена за успешна заявка по работно натоварване.
• Съотношение изход-токен в сравнение с историческата базова линия.
• Процент на повторни опити по доставчик, модел и услуга.
• Резервна честота от по-евтини към по-скъпи модели.
• Скорост на изразходване в рамките на текущия час.
• Намаляване на честотата на попадения в кеша за работни натоварвания, които се очаква да се възползват от кеширането.
• Непроизводствени разходи извън работното време.
• В заявките липсват необходимите размери на разходите.

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

Препоръчителна последователност на внедряване

Не се опитвайте да изградите пълната архитектура в едно издание. Практическа последователност е:

1. Дефинирайте схемата на измеренията на разходите и регистъра на собствеността.
2. Разделете идентификационните данни на доставчика по екип и среда за натоварвания с най-високи разходи.
3. Добавяне на шлюз или прихващане на метаданни от клиентска библиотека.
4. Създайте прогнозната книга за заявка.
5. Добавете тарифна карта с версии за използваните доставчици и модели.
6. Вземете данни за разходите на доставчика в таблица за ежедневно отчитане.
7. Прилагане на ежедневно съгласуване и проследяване на отклоненията.
8. Добавете бюджетни политики, сигнали и работни процеси за одобрение.
9. Преглеждайте липсващите метаданни и неразпределените разходи всяка седмица.

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

Компромиси за изрично решение

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

Грануларност срещу оперативни разходи: повече ключове, проекти, работни пространства и тагове подобряват приписването, но увеличават работата по управлението. Използвайте граници, които отговарят на реалната собственост.

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

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

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

Прогноза: Книгите за разходи ще станат част от управлението на AI платформа

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

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

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

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

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