A Cloudflare megváltoztatta az AI Gateway egy elbűvölő, de fontos részét: mi történik, ha egy felsőbb szintű AI-szolgáltató elutasítja az ügyfél hitelesítő adatait.
A Cloudflare AI Gateway változásnaplója szerint a POST /ai/run következetesebb válaszokat ad vissza, ha egy szolgáltató megtagadja a hitelesítő adatokat. A legkonkrétabb példa a Google Vertex. Az elutasított Vertex hitelesítési adatok, amelyek korábban HTTP 500-as választ adtak felfelé irányuló újrapróbálkozásokkal, most a 2009-es Cloudflare-hibakóddal a HTTP 401-es számot adják vissza. A Cloudflare szerint az alkalmazásoknak a HTTP 401-et érvénytelen vagy elutasított szolgáltatói hitelesítő adatként kell értelmezniük. Ezzel szemben egy szolgáltatói elutasítás a Cloudflare által kezelt egyesített számlázásban a HTTP 503.
Ez egy szűk körű hibaszerződés-frissítésnek tűnik. Az AI-átjárókat üzemeltető csapatok számára ez több annál. A rossz szolgáltatói kulcsot nem szabad átmeneti infrastruktúra-hibaként kezelni. Ha igen, az alkalmazások újra próbálkoznak, de nem sikerül, a tartalék rendszerek rossz okból áthelyezhetik a forgalmat, és az ügyfélszolgálati csapatoknak el kell különíteniük a hitelesítési hibákat a szolgáltató instabilitásától.
Mi változott az átjárószerződésben
A változás szabványosítja a termelésben fontos megkülönböztetést: ki javíthatja ki a hibát.
Ha egy felhasználó hozza a saját szolgáltatói kulcsát, és az érvénytelen, visszavont, lejárt, hiányzik a megfelelő projektengedély, vagy a szolgáltató elutasítja, az ügyfélnek vagy a platformadminisztrátornak ki kell javítania a hitelesítési adatokat. A 401 visszatérése ezt láthatóvá teszi. Közli az alkalmazással, hogy a hitelesítés nem sikerült a szolgáltató határán, és a vak újrapróbálkozások valószínűleg nem segítenek.
Korábban, legalábbis az elutasított Google Vertex hitelesítő adatok esetében, a Cloudflare azt mondta, hogy a hiba HTTP 500-asként jelentkezhet, és felfelé irányuló újrapróbálkozásokat válthat ki. Az 500-as válasz általában szerveroldali hibát vagy upstream problémát jelent, amely önmagában is megoldódhat. Sok ügyfélkönyvtár és átjáró-burkoló ezt a hibaosztályt újrapróbálhatóként kezeli. Az AI-forgalomban ez drága lehet, mert a kérések tartalmazhatnak hosszú felszólításokat, eszközkontextust vagy nagy mennyiségű kötegelt munkát.
Az új felosztás az egységes számlázási viselkedést is tisztázza. A Cloudflare szerint a szolgáltató elutasítása az egyesített számlázás alatt a HTTP 503-as számra van leképezve. Ez a hibát a szolgáltatás-elérhetőség családban tartja, ahelyett, hogy az ügyfél saját kulcsproblémájaként mutatná be. Azon szoftverek esetében, amelyek támogatják a saját kulcsot hozó és az átjáró által számlázott forgalmat is, ennek a megkülönböztetésnek az újrapróbálkozási szabályokat és a felhasználóknak szóló üzeneteket is meg kell határoznia.
Miért fontos ez a BYOK és a viszonteladói termékek esetében
A frissítés egy olyan piacon érkezik, ahol több mesterségesintelligencia-platform keveri az átjáró által számlázott hozzáférést az ügyfelek által biztosított hitelesítési adatokkal. A többmodell API átjáró csapatoknak egy kérést egy platformfiókon, egy másikat az ügyfél OpenAI kulcsán, a harmadikat pedig egy vállalati vevő által felügyelt Google felhőprojekten keresztül irányíthat. A HTTP állapotkód gyakran az első jel, amelyet a vezérlősík lát, ha valami elromlik.
A BYOK-munkafolyamatok esetében a szolgáltatói hitelesítő adatok elutasításának 401-esként történő kezelése tisztább működési útvonalat tesz lehetővé. Az irányítópult egy hitelesítő adatot elutasítottként jelölhet meg, csak az érintett útvonalat szüneteltetheti, értesítheti a megfelelő tulajdonost, és elkerülheti az újrapróbálkozási költségkeret elköltését egy olyan kérés esetén, amely ismét sikertelen lesz. Ezenkívül segít elkülöníteni a kulcshigiéniát a modell elérhetőségétől. A Vertex-hitelesítés visszavonása nem ugyanaz, mint a szolgáltató leállása vagy a sebességkorlátozási esemény.
A viszonteladói és partnerplatformok hasonló problémával küzdenek, de az ügyfeleket érintő következményekkel jár. Egy AI API viszonteladói platform kezelheti a kulcsokat, a számlázási állapotot és a szolgáltatói útvonalakat számos downstream ügyfél számára. Ha az elutasított hitelesítési adatok általános szerverhibának tűnnek, a támogatási csapatok rossz kiváltó okot jelenthetnek, átléphetnek egy drágább útvonalra, vagy felvállalhatják a költségeket, amelyeket az ügyfél rosszul konfigurált hitelesítő adatainak kellett volna tulajdonítani.
A gyakorlati változás tehát nem csak a hibás elemzésben rejlik. Az üzemeltetőknek újra meg kell vizsgálniuk az újrapróbálkozási irányelveket, a figyelmeztető címkéket, az irányítópult-másolatokat és az incidensek besorolását. Az átjáró útvonaláról érkező 401-es számnak általában le kell állítania az automatikus szolgáltatói újrapróbálkozásokat, és át kell helyeznie a problémát a hitelesítő adatok javítására. Az 503 alatti kezelt számlázás továbbra is indokolttá teheti a szolgáltatói állapotellenőrzést, a feladatátvételi logikát vagy az állapotoldali incidenst, a termék architektúrájától függően.
Mit kell frissíteniük a fejlesztőknek
A Cloudflare AI Gateway-t használó fejlesztőknek ellenőrizniük kell minden olyan kliens logikát, amely széles HTTP osztályokon keresztül kezeli a szolgáltatói hibákat. Ha a 401-es válaszokat jelenleg csak átjáró-token-problémaként kezelik, akkor előfordulhat, hogy a kódnak különbséget kell tennie az alkalmazás Cloudflare hitelesítő adatai és a 2009-es Cloudflare hibakód által képviselt upstream szolgáltatói hitelesítő adatok között.
A csapatoknak felül kell vizsgálniuk a tartalék útvonalakat is. A tartalék akkor hasznos, ha egy szolgáltató nem elérhető, túlterhelt vagy a várakozási időn kívül esik. Kockázatosabb, ha az eredeti hiba az ügyfél hitelesítési problémája. A forgalom automatikus átirányítása egy elutasított BYOK útvonalról a platform által számlázott útvonalra váratlan díjakat, irányelvsértéseket vagy adatkezelési változásokat eredményezhet. Az Unified AI API billing termékeknek egyértelművé kell tenniük ezt a viselkedést.
A támogatási eszközöknek is pontosabbnak kell lenniük. Egy hasznos irányítópult állapot azt mondhatja, hogy egy szolgáltató elutasította a konfigurált hitelesítő adatokat, azonosíthatja az érintett szolgáltatói útvonalat, és megjelenítheti az utolsó hibaidőt. Ez jobban végrehajtható, mint egy általános upstream hiba. A vállalati ügyfelek esetében az ellenőrzési naplóknak meg kell őrizniük az állapotkódot, a szolgáltatót, a hitelesítő adatok hivatkozását és az útválasztási döntést, hogy a csapatok megmagyarázhassák, hogy a kérés sikertelen volt, megkísérelték-e újra, vagy másik számlázási útvonalra helyezték át.
Ami még bizonytalan
A Cloudflare változásnaplója a Google Vertex-et konkrét javított esetként azonosítja, és az ElevenLabs-t a szélesebb szolgáltatói hitelesítő adatok kontextusában nevezi meg, de a nyilvános feljegyzés nem úgy olvasható, mint egy teljes mátrix minden szolgáltatóról és minden lehetséges hitelesítési adathibáról. Az átjáró üzemeltetőinek tesztelniük kell azokat a szolgáltatókat, amelyekre támaszkodnak, ahelyett, hogy azt feltételeznék, hogy az összes elutasított kulcsú forgatókönyv most ugyanúgy viselkedik.
Van egy terméktervezési kérdés is az AI Gatewayre épülő platformokhoz: a Cloudflare hibaszókincsének mekkora részét kell nyilvánosságra hozni a végfelhasználók számára? A nyers kódok hasznosak a fejlesztők számára, de a viszonteladói portáloknak gyakran szükségük van egy tartósabb, az ügyfelek számára megfelelő kategóriára, például a „szolgáltatói hitelesítési adatok elutasítva”, külön a „átjárószámlázás nem elérhető” vagy „szolgáltató átmenetileg nem elérhető” kategóriától.
A nagyobb irány egyértelmű. Az AI-átjárók már nem egyszerű átmenő proxy-k a modellhívásokhoz. Ezek házirend- és számlázás-ellenőrzési síkok, és a hibaszemantika kis különbségei eldönthetik, hogy a rendszer újrapróbálkozzon, átadja-e a feladatát, megterhelje-e az ügyfelet, vagy megkéri-e a rendszergazdát, hogy csatlakoztassa újra a szolgáltatói fiókot.