Cloudflare je promijenio način na koji se korištenje AI Gatewaya pojavljuje na mjesečnim fakturama, a prilagodba je operativnije značajnija nego što se na prvi pogled čini. U unosu u dnevnik promjena od 1. rujna, tvrtka je rekla da mjesečni računi za korištenje sada prikazuju jednu stavku retka ukupnog troška po modelu, umjesto zasebnih stavki retka za ulazne tokene i izlazne tokene. Cloudflare je također rekao da je standardizirao nazive modela na fakturama i zapisima koristeći dosljedan identifikator dobavljača/modela.

Promjena se ne odnosi na fakture za kupnje kredita AI Gatewaya. Riječ je o mjesečnim fakturama za korištenje: zapisima koje financijski timovi, platformski timovi i preprodavači koriste za usklađivanje potrošnje nakon što je promet već prošao kroz pristupnik.

Kupcima koji trebaju samo račun na visokoj razini, novi format može biti lakši za čitanje. Za timove koji izračunavaju marže, dodjeljuju troškove umjetne inteligencije stanarima ili reviziju mješavine tokena prema radnom opterećenju, mijenja se mjesto gdje mora živjeti detaljna knjiga. Faktura postaje sve manje artefakt obračuna tokena, a više sažetak troškova na razini modela.

Što se promijenilo u naplati Cloudflare AI Gatewaya

Do ovog ažuriranja, mjesečne fakture za korištenje mogle su odvojiti troškove ulaznog tokena i izlaznog tokena. Ta je razlika važna jer mnogi pružatelji modela cijene te klase tokena drugačije. Radno opterećenje koje šalje velike upite i prima kratke odgovore ima drugačiji troškovni profil od onog koje šalje male upite i generira duge odgovore, čak i ako su oba povezana s istim modelom.

Cloudflareova nova struktura fakture sažima te odvojene stavke retka tipa tokena u jedan redak ukupnog troška po modelu. Praktični učinak je čišća naplata na razini modela, ali manje detalja na razini fakture o tome kako je taj trošak proizveden.

U isto vrijeme, standardizacija identifikatora modela na fakturama i zapisnicima rješava drugačiji, ali povezan problem: pomicanje aliasa. U sustavima s više modela, isti se model može pojaviti pod nešto drugačijim imenima u zapisima, izvozima naplate, nadzornim pločama, korisničkim izvješćima i internim pravilima usmjeravanja. Konzistentan format naziva pružatelja/modela smanjuje šanse da financijski i inženjerski timovi uspoređuju jedan niz u zapisima upotrebe s malo drugačijim nizom na fakturama.

Taj je dio promjene očito koristan svima koji koriste objedinjenu naplatu AI API-ja. Ako račun kaže jedno, a tok dnevnika kaže drugo, usklađivanje postaje vježba ručnog mapiranja. Standardni identifikatori olakšavaju vjerovanje automatiziranim spojevima, nadzornim pločama i izjavama korisnika.

Zašto je granularnost fakture važna

Teži kompromis je granularnost tokena. Timovi za infrastrukturu umjetne inteligencije često trebaju više od ukupnog iznosa koji se naplaćuje za model. Moraju znati je li do skoka troškova došlo zbog dužih upita, opširnijih izlaza, promjene usmjeravanja, uzorka promašaja predmemorije, nove petlje agenta ili integracije korisnika koja je počela slati velike datoteke kao kontekst.

Redak fakture na razini modela može potvrditi iznos duga. Ne može, samo po sebi, objasniti ponašanje koje je stvorilo naboj. To objašnjenje mora proizaći iz zapisa, izvoza, telemetrije pristupnika ili zasebne knjige korištenja.

Ovo je najvažnije za tvrtke koje se nalaze između dobavljača modela i krajnjeg korisnika. Prodavači, interni platformski timovi, SaaS proizvodi s ugrađenim značajkama umjetne inteligencije i agencije koje upravljaju radnim opterećenjima klijenata trebaju branjivu atribuciju troškova. Ako njihova ulazna i izlazna faktura više ne izlaže ulazne i izlazne troškove tokena kao zasebne retke, moraju sačuvati tu razliku prije vremena fakture.

Isti problem vrijedi i za povrat unutar većih tvrtki. Financijski tim može biti zadovoljan s "ovoliko košta model X". Voditelj inženjeringa možda mora znati da je određeni pomoćnik repozitorija, bot za podršku ili tijek rada dokumenta generirao neuobičajenu količinu izlaznih tokena. To su različita računovodstvena pitanja.

Koga to utječe

Korisnici Direct Cloudflare AI Gatewaya neposredna su publika. Svaki tim koji se oslanja na mjesečne fakture kao svoj primarni izvor istine o naplati trebao bi provjeriti podržava li novi format još uvijek njegove potrebe za internim izvješćivanjem.

Gateway operateri i AI API preprodavači su pogođeni dublje. Ako preprodaju pristup višestrukim modelima, izdaju fakture klijentima ili primjenjuju prilagođene marže, trebaju vlastite zapise po zahtjevu: identifikator modela, davatelj, ulazni tokeni, izlazni tokeni, predmemorirani tokeni gdje je relevantno, jedinična cijena, primijenjeni popust, korisnički ključ, projekt, stanar i vremenska oznaka. Bez te knjige, pojednostavljena uzvodna faktura može otežati provjeru daljnje naplate.

Razvojni programeri koji izrađuju nadzorne ploče suočavaju se sa sličnom prilagodbom. Standardizacija naziva modela trebala bi smanjiti pogreške mapiranja, ali samo ako interni sustavi usvoje iste kanonske identifikatore ili održavaju namjernu tablicu aliasa.Ovdje nadzorna ploča za analizu upotrebe AI API-ja postaje više od pogodnosti za izvješćivanje. To postaje mjesto gdje se detalji uklonjeni s fakture zadržavaju, ispituju i objašnjavaju.

Za korisnike Model Gatea i slične kupce pristupnika s više pružatelja, lekcija je jasna: ne tretirajte fakturu pružatelja kao jedini izvor istine. Objedinjena naplata korisna je upravo zato što davatelji različito formatiraju, cijene i izlažu korištenje. Glavna knjiga na razini pristupnika omogućuje timovima da normaliziraju te informacije prije nego što se komprimiraju u format fakture koji pružatelj odabere.

Promjena naziva modela može biti veći dugoročni signal

Ažuriranje standardiziranog identifikatora moglo bi nadživjeti raspravu o formatu fakture. Imenovanje modela postaje operativni problem na svim skupovima umjetne inteligencije. Pružatelji revidiraju ID-ove modela, platforme u oblaku omotavaju isti model pod nazivima specifičnim za kanale, pristupnici uvode pseudonime radi kompatibilnosti, a nazive pinova aplikacija u konfiguracijskim datotekama.

Prilikom imenovanja mijenja se nekoliko stvari tiho. Izvješća o troškovima dijele jedan model u više redaka. Provjerama zastarjelosti nedostaje promet koji još uvijek koristi stariji alias. Pravila usmjeravanja primjenjuju se na jedno ime, ali ne i na drugo. Fakture korisnika pokazuju oznaku koja ne odgovara zapisnicima razvojnog programera.

Cloudflareov pomak prema dosljednim identifikatorima dobavljača/modela odražava širu potrebu za sustavima ai model odabira koji se mogu revidirati, a ne samo praktični. Pseudonim prilagođen ljudima i dalje može biti koristan na aplikacijskom sloju, ali naplata i zapisnici trebaju stabilna kanonska imena.

Preostala neizvjesnost je koliko će detaljnih podataka o korištenju Cloudflare korisnici zadržati izvan fakture i koliko ih lako mogu izvesti za dugoročno usklađivanje. Dnevnik promjena potvrđuje fakture i promjene naziva, ali sam po sebi ne odgovara na svako daljnje računovodstveno pitanje za preprodavače ili poduzeća s prilagođenim modelima povrata uplate.

Praktični odgovor nije kompliciran, ali je hitan: zabilježite upotrebu na razini tokena prije nego što stigne mjesečna faktura, normalizirajte identifikatore modela pri ulasku i učinite internu knjigu autoritetom za naplatu klijentima i analizu troškova. Cloudflareova faktura sada je možda jednostavnija. Tvrtke s umjetnom inteligencijom ne bi trebale dopustiti da njihovo računovodstvo postane manje precizno.