Как да създадете 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 доставчикът, използван за заявката.
• model: точният модел или идентификатор на внедряване.
• request_class: интерактивен, фонов, партиден, повторен опит, резервен, оценка или администриране.

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

Подробности за изпълнение

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

{
  "schema_version": "2025-01",
  "team_id": "platform-ai",
  "product_id": "support-assistant",
  "environment": "production",
  "workload": "summarization",
  "customer_segment": "enterprise",
  "budget_owner": "cost-center-4812",
  "request_class": "interactive"
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• request_id
• provider_request_id
• timestamp
• team_id
• product_id
• environment
• workload
• provider
• model
• billable_units
• rate_card_version
• estimated_cost_usd
• latency_ms
• status_code
• retry_count
• fallback_used
• cache_status

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

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

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

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

• billing_date
• provider
• invoice_account
• project_or_workspace
• team_id
• product_id
• environment
• 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 се разпространява от пилотни проекти към производствени работни потоци, счетоводните книги на разходите ще станат част от нормалното управление на платформата заедно с контрола на достъпа, ротацията на ключовете, регистрирането на одит, ограниченията на скоростта и анализа на използването. Екипите, които определят своята таксономия на разходите рано, ще имат по-лесно време да добавят бюджети, разпределение на ниво клиент и автоматизирани контроли по-късно.

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

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

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