A Cloudflare egy vezérlővel egészítette ki az AI Gateway-t, amely lehetővé teszi az üzemeltetőknek, hogy szolgáltatói hitelesítési adatokat kérjenek harmadik féltől származó modellkérések esetén. A módosítás az interfész szempontjából kicsi, de megoldja az AI-forgalmat átjárón keresztül irányító csapatok gyakorlati irányítási problémáját: mi történik, ha egy ügyfél, projekt vagy bérlő nem adott meg érvényes szolgáltatói kulcsot?
A frissítés előtt a Cloudflare AI Gateway az egységes számlázási beállítását tartalék útvonalként használhatta a támogatott külső szolgáltatók számára. Ez kényelmes lehet, ha egy kérés egyébként meghiúsulna, de elmoshatja a költség-hozzárendelést és a megfelelési határokat is. Az új BYOK-only beállítás lehetővé teszi az átjáró-tulajdonosok számára, hogy megakadályozzák ezt a visszaesést, és megkövetelik, hogy a kérések a kifejezetten megadott "hozd el a saját kulcsod" hitelesítő adatait helyette.
A Cloudflare szerint a beállítás engedélyezhető az irányítópulton vagy az API-n keresztül a byok_only=true paraméterrel. Ezenkívül hozzáadott egy kérésenkénti fejlécet (cf-aig-no-wholesale) azokra az esetekre, amikor a csapatok blokkolni akarják a nagykereskedelmi vagy a Cloudflare által felügyelt hitelesítő adatok használatát az egyes hívásoknál.
Mi változott
A szeptember 14-i AI Gateway változásnapló bevezeti a harmadik hitelesítési részre vonatkozó szolgáltatói kérelmeket. Ha engedélyezve van, az átjáró nem tér vissza csendben a Cloudflare által kezelt egyesített számlázási hitelesítő adatokhoz, ha a hívó fél nem adott meg elfogadható szolgáltatói hitelesítési adatokat.
Ez a különbségtétel azért fontos, mert az AI-átjárók egyre inkább számos belső alkalmazás, külső ügyfél és több modellszolgáltató között helyezkednek el. A hiányzó kulcs nem csupán műszaki hibaüzenet. El tudja dönteni, hogy melyik jogi személynek számlázzon, melyik fiók szolgáltatói kvótáját használja fel, és hogy a használat a megfelelő költséghelyen jelenjen-e meg.
Az új vezérlés szigorúbb működési módot biztosít a platformcsapatok számára. Ahelyett, hogy a hiányzó ügyfél-hitelesítő adatokat az útválasztási kényelmetlenségként kezelné, az átjáró irányelvsértésként kezelheti azokat. Ez különösen fontos a viszonteladói beállítások, az ügyfelek tulajdonában lévő kulcsok telepítése és a vállalati környezetek esetében, ahol a szolgáltatói kapcsolatnak közvetlenül egy üzleti egységhez vagy bérlőhöz kell kötődnie.
Miért fontos ez az AI-átjárók üzemeltetői számára?
Az AI-átjárók tervezése gyakran az útválasztásra, a késleltetésre, a gyorsítótárazásra, az újrapróbálkozásokra és a modellekre összpontosított. A számlázási magatartás ugyanilyen figyelmet érdemel. Ha egy átjáró automatikusan megváltoztatja a hitelesítési adatok módját, amikor az egyik elérési út nem érhető el, a downstream jelentések félrevezetővé válhatnak. Egy kérés közönséges alkalmazásforgalomnak tűnhet, miközben a számla valahol máshol érkezik.
A központi AI API költségellenőrzési réteget működtető vállalkozások számára, ami működési kockázatot jelent. A pénzügyi csapatok elveszíthetik a tiszta visszaterhelési adatokat. Előfordulhat, hogy a biztonsági csapatok nem tudják, hogy valójában melyik hitelesítő adatot használták. A termékcsapatok nehezen tudják megmagyarázni, hogy az egyik bérlő használatáért miért platformfiókon keresztül számláztak, nem pedig a bérlő saját szolgáltatói fiókján keresztül.
A csak a BYOK mód az ügyfelek kötelezettségvállalásait is segíti. Egyes vásárlók megkövetelik, hogy saját szolgáltatói szerződéseik, adatfeldolgozási feltételeik vagy regionális beállításaik szabályozzák a modellhívásokat. Ha egy átjáró visszakerülhet egy kezelt számlázási hitelesítő adatra, akkor ezt a kötelezettségvállalást nehezebb lesz érvényesíteni, hacsak a házirend nem tiltja le a tartalékot.
A kérésenkénti fejléc egy részletesebb beállítást ad hozzá. Egy platform szélesebb körű egységesített számlázási viselkedést biztosíthat bizonyos munkaterheléseknél, miközben megakadályozza azt a szigorúbb megfelelőségi, viszonteladói vagy hozzárendelési követelményeket támasztó kérések esetében. Így a fejlesztők migrációs útvonalat biztosítanak anélkül, hogy minden alkalmazást egyszerre a legszigorúbb módra kényszerítenének.
Kit érint az érintett
A közvetlen közönség bármely olyan csapat, amely a Cloudflare AI Gateway-t használja a harmadik féltől származó mesterségesintelligencia-szolgáltatók proxykérésére. A változás leginkább ott releváns, ahol több csapat, bérlő vagy ügyfél osztozik egy átjárón, és ahol a szolgáltatói hitelesítési adatok várhatóan a központi platformfiókon kívül lesznek a tulajdonosok.
A vállalati mesterséges intelligencia platform csapatainak meg kell vizsgálniuk, hogy az átjáró viselkedése megfelel-e a belső szabályzatnak. Ha egy projektnek saját OpenAI-, Anthropic-, Google-, Mistral- vagy más szolgáltatói fiókot kell használnia, az átjárónak láthatóvá és végrehajthatóvá kell tennie ezt a függőséget. A demó sikerességét elősegítő tartalék problémát jelenthet az éles környezetben, ha elrejti a hibás hitelesítő adatok beállítását.
A viszonteladók és a partnerplatformok élesebb verzióval rendelkeznek ugyanannak a problémának. Ha az ügyfelek saját szolgáltatói kulcsaikat hozzák magukkal, a platform üzemeltetőinek bízniuk kell abban, hogy a forgalom véletlenül sem alakul át platformszámlás használatba. Ellenkező esetben az árrés, a számlák, az ellenőrzési nyilvántartások és az ügyfelek bizalma egyaránt érintett lehet.
A fejlesztők is érintettek, bár többnyire tisztább hibamódok miatt. A csak BYOK általi kényszerítés esetén a megfelelő hitelesítési adatokat nem tartalmazó kérésnek meg kell kudarcot vallania, nem pedig alternatív számlázási útvonalon.Ehhez jobb beépítési ellenőrzésekre, tisztább hibakezelésre és olyan telepítési tesztekre lehet szükség, amelyek ellenőrzik a szolgáltatói kulcsokat, mielőtt a forgalom életbe lépne.
Gyakorlati következmények
Az első gyakorlati lépés a házirend-leltár. A csapatoknak el kell dönteniük, hogy mely munkaterhelések használhatják a Cloudflare által felügyelt egységes számlázást, és melyiknek kell az ügyfél vagy a projekt tulajdonában lévő szolgáltatói hitelesítési adatokat használnia. Ennek a döntésnek egyértelműnek kell lennie, nem szabad az alapértelmezett átjáró viselkedésére hagyni.
A második lépés a megfigyelhetőség. A naplóknak és a használati elemzéseknek rögzíteniük kell, hogy melyik hitelesítési módot használták, hogy egy kérés blokkolva volt-e, mert a BYOK-only engedélyezve volt, és hogy melyik bérlő vagy projekt adta meg a kulcsot. E láthatóság nélkül a szigorúbb ellenőrzés csökkentheti a számlázási kétértelműséget, de az üzemeltetők továbbra is gyenge hibaelhárítási adatokkal rendelkeznek.
A harmadik lépés a fejlesztői munkafolyamat. Az AI-átjárótól függő alkalmazások korán meghibásodhatnak, ha hiányoznak a hitelesítő adatok. Az indítási ellenőrzés, az üzembe helyezés ellenőrzése vagy a felügyeleti konzol figyelmeztetése jobb, mint a probléma felfedezése egy éles kérés elutasítása után.
A fennmaradó bizonytalanság kevésbé magára a szolgáltatásra, hanem inkább az átvételi mintákra vonatkozik. A Cloudflare dokumentálta az új vezérlőt, de minden kezelőnek még el kell döntenie, hogy hol alkalmazza azt. Egyes csapatok a belső kísérleteknél a tartalék számlázás rugalmasságát részesítik előnyben. Mások csak a BYOK-ot teszik alapértelmezetté az éles bérlői forgalom számára. A fontos változás az, hogy ez most egy irányítási választás, nem pedig az útválasztási rétegben elrejtett implicit viselkedés.