A Cloudflare megváltoztatta azt, ahogyan az AI Gateway használata megjelenik a havi számlákon, és a korrekció működési szempontból jelentősebb, mint amilyennek elsőre tűnik. Egy szeptember 1-jei változásnapló-bejegyzésben a vállalat azt mondta, hogy a havi használati számlák modellenként egy teljes költségsort mutatnak, nem pedig külön sorokat a bemeneti és kimeneti tokenek számára. A Cloudflare azt is közölte, hogy szabványosította a modellneveket a számlák és naplók között, konzisztens szolgáltató/modellazonosító használatával.
A változás nem vonatkozik az AI Gateway-hitelvásárlások számláira. A havi használati számlákról van szó: a pénzügyi csapatok, platformcsapatok és viszonteladók által használt nyilvántartások a fogyasztás egyeztetésére szolgálnak, miután a forgalom már áthaladt az átjárón.
Azoknak az ügyfeleknek, akiknek csak magas szintű számlára van szükségük, az új formátum könnyebben olvasható. Azon csapatok esetében, amelyek a haszonkulcsot számítják ki, a mesterséges intelligencia költségeit bérlőkhöz rendelik, vagy a token-keveréket munkaterhelés szerint vizsgálják, megváltozik a részletes főkönyv helye. A számla egyre kevésbé egy token-könyvelési műtermék, és inkább egy modellszintű költségösszegzés.
Mi változott a Cloudflare AI Gateway számlázásában
E frissítésig a havi használati számlák elválaszthatták a bemeneti- és kimeneti-token díjakat. Ez a különbségtétel azért fontos, mert sok modellszolgáltató eltérően árazza ezeket a tokenosztályokat. A nagy kéréseket küldő és rövid válaszokat fogadó munkaterhelés költségprofilja eltér a kis kéréseket küldő és hosszú válaszokat generáló terheléstől, még akkor is, ha mindkettő ugyanahhoz a modellhez van társítva.
A Cloudflare új számlastruktúrája ezeket a külön token típusú sorokat modellenként egy összköltség-sorba tömöríti. A gyakorlati hatás tisztább modellszintű számlázás, de kevesebb számlaszintű részlet arról, hogyan keletkezett ez a költség.
Ugyanakkor a modellazonosítók szabványosítása a számlák és naplók között egy másik, de kapcsolódó problémát is megold: az álnevek eltolódását. A több modellből álló rendszerekben ugyanaz a modell kissé eltérő néven jelenhet meg a naplókban, a számlázási exportálásokban, az irányítópultokon, az ügyféljelentésekben és a belső útválasztási szabályokban. A konzisztens szolgáltató/modell elnevezési formátum csökkenti annak esélyét, hogy a pénzügyi és mérnöki csapatok a használati naplókban egy karakterláncot egy kicsit más karakterlánchoz illesztenek a számlákban.
A változtatásnak ez a része egyértelműen hasznos az egységes AI API-számlázást használók számára. Ha a számla egyet mond, a naplófolyam pedig mást, akkor az egyeztetés kézi feltérképezési gyakorlattá válik. A szabványos azonosítók megkönnyítik az automatizált összekapcsolások, irányítópultok és ügyfélkimutatások megbízhatóságát.
Miért számít a számla részletessége?
A nehezebb kompromisszum a token részletesség. Az AI-infrastruktúra-csapatoknak gyakran többre van szükségük, mint amennyit egy modellért felszámítanak. Tudniuk kell, hogy a költségcsúcs a hosszabb promptokból, a bőbeszédesebb kimenetekből, az útválasztási módosításból, a gyorsítótár kihagyási mintájából, egy új ügynökhurokból vagy az ügyfélintegrációból származott-e, amely nagy fájlokat kezdett el küldeni kontextusként.
A modellszintű számlasor megerősítheti a tartozás összegét. Ez önmagában nem tudja megmagyarázni a töltést létrehozó viselkedést. Ennek a magyarázatnak a naplókból, az exportálásból, az átjáró telemetriájából vagy egy külön használati főkönyvből kell származnia.
Ez leginkább azon vállalkozások számára számít, amelyek a modellszolgáltató és a végfelhasználó között helyezkednek el. A viszonteladóknak, a belső platformcsapatoknak, a beágyazott mesterségesintelligencia-funkciókkal rendelkező SaaS-termékeknek és az ügyfelek munkaterhelését kezelő ügynökségeknek mind védhető költségmegosztásra van szükségük. Ha az upstream számlájuk már nem teszi ki külön sorként a bemeneti és kimeneti token költségeket, meg kell őrizniük ezt a különbséget a számla kiállításának időpontja előtt.
Ugyanez a probléma vonatkozik a nagyobb vállalatokon belüli visszaterhelésre is. Egy pénzügyi csapat elégedett lehet azzal, hogy „az X modell ennyibe kerül”. Egy mérnöki vezetőnek tudnia kell, hogy egy adott adattárasszisztens, támogató robot vagy dokumentum-munkafolyamat szokatlanul sok kimeneti tokent hozott létre. Ezek különböző számviteli kérdések.
Kit érint?
A közvetlen Cloudflare AI Gateway felhasználói jelentik a közvetlen közönséget. Minden olyan csapatnak, amely a havi számlákra támaszkodik a számlázási igazság elsődleges forrásaként, felül kell vizsgálnia, hogy az új formátum továbbra is támogatja-e belső jelentési igényeit.
A Gateway üzemeltetőit és az AI API viszonteladóit ez nagyobb mértékben érinti. Ha több modellhez való hozzáférést értékesítenek, vevői számlákat állítanak ki vagy egyéni jelöléseket alkalmaznak, saját kérésenkénti rekordra van szükségük: modellazonosító, szolgáltató, bemeneti tokenek, kimeneti tokenek, adott esetben gyorsítótárazott tokenek, egységár, alkalmazott kedvezmény, ügyfélkulcs, projekt, bérlő és időbélyeg. A főkönyv nélkül az egyszerűsített upstream számla megnehezítheti a későbbi számlázás ellenőrzését.
Az irányítópultokat készítő fejlesztők hasonló kiigazítással szembesülnek. A modellnév szabványosításnak csökkentenie kell a leképezési hibákat, de csak akkor, ha a belső rendszerek ugyanazokat a kanonikus azonosítókat veszik át, vagy szándékos álnévtáblázatot tartanak fenn.Ez az a hely, ahol az AI API-használati elemzési irányítópult több, mint jelentéskészítési kényelem. Ez lesz az a hely, ahol a számláról eltávolított részletet megőrzik, lekérdezik és elmagyarázzák.
A Model Gate-felhasználók és a hasonló többszolgáltatós átjáró ügyfelek számára a lecke egyértelmű: ne kezelje a szolgáltatói számlát az igazság egyetlen forrásaként. Az egységes számlázás éppen azért hasznos, mert a szolgáltatók eltérően formázzák, árazzák és kiteszik a felhasználást. Az átjárószintű főkönyv lehetővé teszi a csapatok számára, hogy normalizálják ezeket az információkat, mielőtt azokat a szolgáltató által választott számlaformátumba tömörítenék.
A modellnév változása lehet a nagyobb hosszú távú jelzés
A szabványos azonosítófrissítés túlnyúlhat a számlaformátumról szóló vitán. A modellelnevezés működési problémává válik az AI-veremekben. A szolgáltatók felülvizsgálják a modellazonosítókat, a felhőplatformok ugyanazt a modellt csatornaspecifikus nevek alá burkolják, az átjárók álneveket vezetnek be a kompatibilitás érdekében, az alkalmazások pedig pinneveket helyeznek el a konfigurációs fájlokban.
Az elsodródások elnevezésekor több dolog is csendben megszakad. A költségjelentések egy modellt több sorra osztanak fel. Az elavulási ellenőrzések még mindig egy régebbi álnevet használnak. Az útválasztási irányelvek egy névre vonatkoznak, egy másik névre nem. Az ügyfelek számlái olyan címkét tartalmaznak, amely nem egyezik a fejlesztő naplóival.
A Cloudflare egységes szolgáltatói/modellazonosítói felé való elmozdulása azt tükrözi, hogy szélesebb körű igény van olyan AI-modell-kiválasztási rendszerekre, amelyek nem csak kényelmesek, hanem auditálhatók. Az emberbarát álnév továbbra is hasznos lehet az alkalmazási rétegben, de a számlázáshoz és a naplókhoz stabil kanonikus nevekre van szükség.
A fennmaradó bizonytalanság az, hogy a Cloudflare-ügyfelek mennyi részletes használati adatot őriznek meg a számlán kívül, és milyen könnyen exportálhatják azokat hosszú távú egyeztetés céljából. A változásnapló megerősíti a számla- és elnevezési változásokat, de önmagában nem válaszol minden további számviteli kérdésre a viszonteladók vagy egyéni visszaterhelési modellekkel rendelkező vállalkozások számára.
A gyakorlati válasz nem bonyolult, de sürgős: rögzítse a tokenszintű használatot a havi számla megérkezése előtt, normalizálja a modellazonosítókat a feldolgozáskor, és a belsőleg vezetett számlázási jogosultságot állítsa be az ügyfél számára. A Cloudflare számlája most egyszerűbb lehet. Az AI-vállalkozásoknak nem szabad engedniük, hogy saját könyvelésük kevésbé legyen pontos.