Цлоудфларе је променио начин на који се употреба АИ Гатеваи-а приказује на месечним фактурама, а прилагођавање је оперативно значајније него што изгледа на први поглед. У уносу у дневнику промена од 1. септембра, компанија је рекла да месечне фактуре о коришћењу сада показују једну ставку укупне цене по моделу, уместо одвојене ставке за улазне токене и излазне токене. Цлоудфларе је такође рекао да има стандардизоване називе модела за све фактуре и евиденције користећи конзистентан идентификатор добављача/модела.

Промена се не односи на фактуре за куповину кредита АИ Гатеваи-а. Реч је о месечним фактурама за коришћење: евиденцију финансијских тимова, тимова платформи и препродаваца користе за усаглашавање потрошње након што је саобраћај већ прошао кроз мрежни пролаз.

За клијенте којима је потребан само рачун високог нивоа, нови формат ће можда бити лакши за читање. За тимове који израчунавају марже, додељују трошкове вештачке интелигенције закупцима или ревидирају мешавину токена према обима посла, мења се где детаљна књига мора да живи. Фактура постаје мање артефакт обрачуна токена, а више резиме трошкова на нивоу модела.

Шта се променило у обрачуну Цлоудфларе АИ Гатеваи-а

До овог ажурирања, месечне фактуре за коришћење могле би да раздвоје наплате улазног токена и излазног токена. Та разлика је важна јер многи добављачи модела другачије цене те класе токена. Радно оптерећење које шаље велике упите и прима кратке одговоре има другачији профил трошкова од оног који шаље мале упите и генерише дугачке одговоре, чак и ако су оба повезана са истим моделом.

Нова структура фактура Цлоудфларе-а сажима те засебне ставке поруџбина типа токена у једну линију са укупним трошковима по моделу. Практични ефекат је чистији обрачун на нивоу модела, али мање детаља на нивоу фактуре о томе како је тај трошак произведен.

У исто време, стандардизација идентификатора модела у фактурама и евиденцијама решава другачији, али повезан проблем: померање алијаса. У системима са више модела, исти модел се може појавити под незнатно другачијим именима у евиденцијама, извозима наплате, контролним таблама, извештајима клијената и интерним правилима рутирања. Доследан формат именовања добављача/модела смањује шансе да финансијски и инжењерски тимови упарују један низ у евиденцији коришћења са мало другачијим низом у фактурама.

Тај део промене је очигледно користан за свакога ко користи обједињени АИ API обрачун. Ако рачун каже једно, а дневник каже друго, помирење постаје ручна вежба мапирања. Стандардни идентификатори олакшавају поверење у аутоматска спајања, контролне табле и изјаве клијената.

Зашто је важна грануларност фактуре

Тежи компромис је грануларност токена. Тимовима за АИ инфраструктуру често је потребно више од укупног износа који се наплаћује за модел. Они морају да знају да ли је до повећања трошкова дошло због дужих упита, детаљнијих излаза, промене рутирања, шаблона пропуштања кеш меморије, нове петље агента или интеграције корисника која је почела да шаље велике датотеке као контекст.

Линија фактуре на нивоу модела може потврдити износ дуга. Не може, само по себи, објаснити понашање које је створило набој. То објашњење мора да потиче из евиденције, извоза, телеметрије мрежног пролаза или посебне књиге коришћења.

Ово је најважније за предузећа која се налазе између добављача модела и крајњег купца. Препродавци, интерни тимови за платформе, СааС производи са уграђеним АИ функцијама и агенције које управљају радним оптерећењем клијената захтевају оправдану атрибуцију трошкова. Ако њихова претходна фактура више не излаже улазне и излазне токене трошкове као засебне линије, они морају да сачувају ту разлику пре времена фактуре.

Исти проблем се односи на повраћај средстава унутар већих компанија. Финансијски тим може бити задовољан са „модел Кс кошта оволико“. Менаџер инжењеринга ће можда морати да зна да је одређени помоћник спремишта, бот за подршку или ток посла генерисао необичну количину излазних токена. То су различита рачуноводствена питања.

Ко је погођен

Корисници Дирецт Цлоудфларе АИ Гатеваи-а су непосредна публика.Сваки тим који се ослања на месечне фактуре као свој примарни извор истине о обрачуну треба да прегледа да ли нови формат и даље подржава потребе интерног извештавања.

Оператори мрежног пролаза и препродавци АИ API су дубље погођени. Ако препродају приступ вишеструким моделима, издају фактуре клијентима или примењују прилагођене ознаке, потребни су им сопствени записи по захтеву: идентификатор модела, добављач, улазни токени, излазни токени, кеширани токени где је релевантно, цена јединице, примењени попуст, кључ клијента, пројекат, закупац и временска ознака. Без те књиге, поједностављена фактура на почетку може отежати верификацију наплате на даљем току.

Програмери који праве контролне табле суочавају се са сличним прилагођавањем. Стандардизација имена модела би требало да смањи грешке у мапирању, али само ако интерни системи усвоје исте канонске идентификаторе или одржавају намерну табелу алијаса. Овде АИ API контролна табла за аналитику коришћења постаје више од погодности извештавања. То постаје место где се задржавају детаљи уклоњени са фактуре, постављају упити и објашњавају.

За Model Gate кориснике и сличне клијенте мрежног пролаза са више добављача, лекција је једноставна: не третирајте фактуру добављача као једини извор истине. Обједињени обрачун је користан управо зато што провајдери другачије форматирају, цене и излажу употребу. Књига на нивоу мрежног пролаза омогућава тимовима да нормализују те информације пре него што се компримују у било који формат фактуре који добављач одабере.

Промена назива модела може бити већи дугорочни сигнал

Ажурирање стандардизованог идентификатора може наџивети дебату о формату фактуре. Именовање модела постаје оперативни проблем у свим групама АИ. Провајдери ревидирају ИД-ове модела, клауд платформе умотавају исти модел под називе специфичне за канале, гејтвеји уводе псеудониме ради компатибилности, а апликације закачују имена у конфигурационим датотекама.

Приликом именовања одступања, неколико ствари се тихо прекида. Извештаји о трошковима деле један модел у више редова. Застарелост проверава пропуштени саобраћај и даље користећи старији алиас. Политика рутирања се примењује на једно име, али не и на друго. Фактуре клијената приказују ознаку која се не поклапа са евиденцијама програмера.

Цлоудфларе-ово кретање ка доследним идентификаторима добављача/модела одражава ширу потребу за системима АИ модела за избор који се могу ревидирати, а не само погодни. Псеудоним прилагођен људима и даље може бити користан на нивоу апликације, али за обрачун и евиденцију су потребна стабилна канонска имена.

Преостала несигурност је колико ће детаљних података о коришћењу Цлоудфларе клијенти задржати ван фактуре и колико лако могу да их извезу ради дугорочног усаглашавања. Дневник промена потврђује фактуру и промене назива, али сам по себи не одговара на свако рачуноводствено питање за препродавце или предузећа са прилагођеним моделима повраћаја средстава.

Практичан одговор није компликован, али је хитан: снимите коришћење на нивоу токена пре него што стигне месечна фактура, нормализујте идентификаторе модела и направите идентификаторе модела и извршите аналитичку анализу корисника за интерну анализу трошкова. Цлоудфларе-ова фактура је сада можда једноставнија. Предузећа са вештачком интелигенцијом не би требало да допусте да њихово сопствено рачуноводство постане мање прецизно.