Cloudflare промени начина, по който използването на AI Gateway се показва на месечните фактури и корекцията е по-оперативно значима, отколкото може да изглежда на пръв поглед. В запис в регистъра на промените от 1 септември компанията каза, че месечните фактури за използване вече показват един ред с обща цена за модел, вместо отделни редове за входни токени и изходни токени. Cloudflare също каза, че има стандартизирани имена на модели във фактурите и регистрационните файлове, използвайки последователен идентификатор на доставчик/модел.

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

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

Какво се промени в таксуването на Cloudflare AI Gateway

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

Новата структура на фактурата на Cloudflare свива тези отделни позиции от тип токен в един ред с обща цена за модел. Практическият ефект е по-чисто таксуване на ниво модел, но по-малко подробности на ниво фактура за това как са произведени тези разходи.

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

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

Защо детайлността на фактурата има значение

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

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

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

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

Кой е засегнат

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

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

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

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

Промяната на името на модела може да е по-големият дългосрочен сигнал

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

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

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

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

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