A Cloudflare egy kicsi, de fontos vezérlőelemet adott az AI Gateway-hez: a csapatok mostantól megkövetelhetik a harmadik féltől származó szolgáltató hitelesítési adatait, mielőtt egy kérés futhatna. Ha az átjáró nem találja a megfelelő hitelesítési adatokat, a kérés HTTP 400 esetén meghiúsul, ahelyett, hogy a Cloudflare által felügyelt egyesített számlázásra térne vissza.

Ez megváltoztatja a "hozd el a saját kulcsod" vagy a BYOK gyakorlati jelentését. Eddig a hiányzó szolgáltatói kulcs olyan konfigurációs probléma lehetett, amely továbbra is sikeres modellhívást eredményezett, de más számlázási útvonalon. Az új beállítással a hiányzó hitelesítő adatok súlyos irányelvsértést jelentenek. Azon szervezetek számára, amelyek elválasztják az ügyfelek tulajdonában lévő modellfiókokat a központilag számlázott forgalomtól, ez a megkülönböztetés többet számít, mint azt az állapotkód sugallja.

Mi változott?

A Cloudflare szeptember 14-i frissítése kétféle módon kényszeríti ki az új viselkedést. Az átjáró szintjén a rendszergazdák engedélyezhetik a byok_only beállítást. Kérésre a hívók elküldhetik a cf-aig-no-wholesale fejlécet, hogy megakadályozzák a nagykereskedelmi számlázás visszaesését az adott kérésnél.

Ha a vezérlő érvényes, és a szolgáltatói hitelesítési adatok nem állnak rendelkezésre, az AI Gateway HTTP 400-at ad vissza. A Cloudflare szerint a Workers AI szolgáltatói kérelmei engedélyezettek maradnak, így a házirend kifejezetten a harmadik félig terjedő kérésről szól. hitelesítő adatok.

A funkció nem új típusú útválasztó vagy árengedmény. Ez egy számlázási módú védőkorlát. Ez közvetlenül relevánssá teszi az egységes AI API-számlázást, mivel egyetlen átjáró most élesebb határvonalat tud húzni a központilag számlázott forgalom és az ügyfél saját szolgáltatói számlájára terhelendő kérések között.

Miért kockázatos a tartalék számlázás, amikor az elsőbbség kényelmes

. Ha egy szolgáltatói hitelesítési adat hiányzik, lejárt vagy nem a megfelelő útvonalhoz van csatolva, az átjáró által kezelt hitelesítő adatok fenntarthatják az alkalmazás működését. De ugyanez a kényelem zűrzavaros számlanyomokat hozhat létre.

Egy SaaS-szolgáltató, ügynökség vagy belső platformcsapat megígérheti, hogy egy adott bérlő forgalma csak az adott bérlő OpenAI-, Anthropic-, Google- vagy más szolgáltatói fiókja ellen fut. Ha az átjáró csendben egy nagykereskedelmi hitelesítő adatot használ helyette, a kérés továbbra is sikeres lehet, de a kereskedelmi jelentés megváltozott. Előfordulhat, hogy a platform üzemeltetője felveszi a költségeket, hibásan utalja át azt, vagy elveszíti azt a képességét, hogy összeegyeztesse a használatot az ügyfél saját szolgáltatói számlájával.

Ez különösen érzékeny a viszonteladói és partner API-modellek esetében. Egy ügyfél a BYOK-on lehet a beszerzési szabályok miatt. Másik platform által számlázott jóváírást használhat. A harmadik fél szabályozási vagy adatkezelési okokból külön szolgáltatói fiókokat írhat elő. Ebben a környezetben a számlázási útvonal a termékszerződés része, nem pedig megvalósítási részlet.

A Cloudflare új vezérlője lehetőséget ad a csapatoknak arra, hogy a szerződést az átjáró határán érvényesíthetővé tegyék. A sikertelen kérés működési szempontból bosszantó, de könnyebb hibakeresést végezni, mint egy sikeres kérést, amely később rossz költséghelyen jelenik meg.

Kit érintett

A közvetlen közönség bármely olyan csapat, amely a Cloudflare AI Gateway-t használja a szolgáltató tulajdonában lévő hitelesítő adatok és a Cloudflare által kezelt számlázás keverékével. A változás leginkább ott számít, ahol több bérlő, környezet vagy üzleti egység osztozik egy átjáró-konfiguráción.

A fejlesztőknek el kell dönteniük, hogy az útvonal a rendelkezésre állást vagy a szigorú számlázási elkülönítést részesítse előnyben. A pénzügyi és üzemeltetési csapatok tisztább mechanizmust kapnak a véletlen nagykereskedelmi felhasználás megelőzésére. A biztonsági és platformos csapatok egy újabb eszközt kapnak az API-kulcsok kezeléséhez, mivel a szolgáltatói hitelesítési adatok megléte vagy hiánya immár közvetlen végrehajtási következményekkel jár.

Tágabb értelemben az AI-átjárók üzemeltetői számára a frissítés jelzés. A számlázási vezérlők házirend-vezérlőkké válnak. Már nem elég megmutatni, hogy egy kérés egy adott modellt használt. Az átjáróknak egyre gyakrabban kell rögzíteniük, hogy melyik hitelesítési útvonalat használták, kié volt az adott hitelesítési adat, melyik bérlő vagy API-kulcs kezdeményezte a hívást, és hogy engedélyezték-e a tartalékot.

A Model Gate felhasználóinak ugyanazzal a mögöttes problémával kell szembenézniük, amikor csapatokat, API-kulcsokat, használati elemzéseket és partnerkapcsolati hozzáférést kezelnek. Az ügyfél-hatókörű kulcs nem csak egy hitelesítési token; tartalmazhat számlázási módot, költési korlátot, szolgáltatói fiókot és egy sor ellenőrzési elvárást. Ha ezeket a jelentéseket nem érvényesítik következetesen, az analitikai irányítópultok és számlák eltávolodhatnak attól, amit az ügyfelek úgy gondolnak, hogy vásároltak.

Gyakorlati következmények

Az első gyakorlati változás a hibakezelés. A csak BYOK-vezérlőket engedélyező alkalmazásoknak az átjáró HTTP 400-át konfigurációs vagy hitelesítési problémaként kell kezelniük, nem pedig modellhibaként.Ha újra megpróbálja ugyanazt a kérést a hitelesítési adatok javítása nélkül, csak zaj keletkezhet.

A második változtatás a beépítés. Azoknak a csapatoknak, amelyek lehetővé teszik az ügyfelek számára, hogy szolgáltatói kulcsokat hozzanak, erősebb hitelesítés-ellenőrzési lépésre van szükségük az éles forgalom megkezdése előtt. A bérlőnek nem szabad felfedeznie egy élő munkafolyamat során, hogy a szolgáltatói kulcsa soha nem volt csatolva az átjáró útvonalához.

A harmadik változás a megfigyelhetőség. Az átjárónaplóknak és a használati jelentéseknek fel kell fedniük, hogy egy kérés BYOK-ot, platformszámlázást vagy blokkolt tartalék útvonalat használt-e. E mező nélkül a támogatási csapatok tudhatják, hogy egy kérés sikertelen volt, de azt nem, hogy a hiba védte-e a számlázási határt.

Végül a partnerplatformoknak felül kell vizsgálniuk alapértelmezett beállításaikat. A szigorú BYOK végrehajtás nem mindig a megfelelő választás. Előfordulhat, hogy egyes termékek szándékosan visszatérnek a platformszámlázáshoz a szolgáltatás folytonosságának megőrzése érdekében. Másoknak a szerződések, az ügyfelek bizalma vagy az árrésvédelem miatt kemény szétválasztásra lehet szükségük. A fontos változás az, hogy a döntés lehet explicit a véletlen helyett.

Ami továbbra is tisztázatlan

A nyilvános változás leírja a házirend mechanikáját, de a csapatoknak továbbra is tesztelniük kell, hogyan viselkedik a saját szolgáltatói összetételükben, útvonalstruktúrájukban és hitelesítő adatok öröklődési modelljében. Az sem világos, hogy az alkalmazási keretrendszerek és a harmadik féltől származó megfigyelési eszközök milyen széles körben jelenítik meg ezt a számlázási mód szerinti megkülönböztetést az alapértelmezett irányítópultjaikon.

A nagyobb irány elég egyértelmű. A többmodelles átjárók éppúgy pénzügyi irányítási síkokká válnak, mint az API-proxyk. A Cloudflare csak BYOK-beállítása szűk funkció, de valódi hibaüzemmódot kezel: a kérést, amely technikailag működik, miközben megsérti a tervezett számlázási modellt.