Cloudflare AI Gateway spremeni zavrnjene ključe ponudnika v jasnejšo napako 401

Cloudflare je spremenil neglamurozen, a pomemben del prehoda AI Gateway: kaj se zgodi, ko višji ponudnik AI zavrne poverilnico stranke.

Glede na dnevnik sprememb AI Gateway podjetja Cloudflare, POST /ai/run zdaj vrne bolj dosledne odgovore, ko ponudnik zavrne poverilnice. Najbolj konkreten primer je Google Vertex. Zavrnjene poverilnice Vertex, ki so prej ustvarile odgovor HTTP 500, s ponovnimi poskusi navzgor, zdaj vrnejo HTTP 401 s kodo napake Cloudflare 2009. Cloudflare pravi, da bi morale aplikacije razumeti HTTP 401 kot neveljavne ali zavrnjene poverilnice ponudnika. Nasprotno pa se zavrnitev ponudnika v poenotenem obračunavanju, ki ga upravlja Cloudflare, preslika na HTTP 503.

To zveni kot ozka posodobitev pogodbe o napaki. Za ekipe, ki upravljajo prehode AI, je več kot to. Slabega ključa ponudnika ne bi smeli obravnavati kot prehodno napako infrastrukture. Ko je, aplikacije znova poskušajo opraviti delo, ki ne more uspeti, nadomestni sistemi lahko preusmerijo promet iz napačnega razloga in ekipe za podporo strankam morajo ločiti napake pri preverjanju pristnosti od nestabilnosti ponudnika po dejstvu.

Kaj se je spremenilo v pogodbi o prehodu

Sprememba standardizira razlikovanje, ki je pomembno v proizvodnji: kdo lahko odpravi napako.

Če uporabnik prinese svoj ključ ponudnika in je ta ključ neveljaven, preklican, potekel, manjkajo mu prava projektna dovoljenja ali ga je ponudnik zavrnil, mora stranka ali skrbnik platforme popraviti poverilnico. Če vrnete 401, je to vidno. Aplikaciji sporoči, da preverjanje pristnosti na meji ponudnika ni uspelo in da slepi ponovni poskusi verjetno ne bodo pomagali.

Vsaj za zavrnjene Google poverilnice Vertex Cloudflare pravi, da bi se napaka lahko pojavila kot HTTP 500 in sprožila ponovne poskuse navzgor. Odgovor 500 običajno pomeni napako na strani strežnika ali težavo navzgor, ki se lahko odpravi sama od sebe. Številne odjemalske knjižnice in ovoji prehodov obravnavajo ta razred napake kot ponovni poskus. Pri prometu z umetno inteligenco je to lahko drago, ker lahko zahteve vključujejo dolge pozive, kontekst orodja ali obsežno paketno delo.

Nova razdelitev tudi pojasnjuje vedenje enotnega obračunavanja. Cloudflare pravi, da se zavrnitev ponudnika v okviru poenotenega zaračunavanja preslika na HTTP 503. To napako ohranja v družini razpoložljivosti storitev, namesto da bi jo predstavili kot ključno težavo stranke. Pri programski opremi, ki podpira prinesi svoj ključ in promet, ki se zaračunava prek prehoda, bi moralo to razlikovanje oblikovati tako pravila ponovnega poskusa kot sporočila, namenjena uporabniku.

Zakaj je to pomembno za izdelke BYOK in prodajalce

Posodobitev pristane na trgu, kjer več platform umetne inteligence kombinira dostop, ki se zaračuna prek prehoda, s poverilnicami, ki jih zagotovijo stranke. Večmodelni API prehod za ekipe lahko eno zahtevo usmeri prek računa platforme, drugo prek strankinega OpenAI ključa in tretjo prek Google projekta v oblaku, ki ga nadzira poslovni kupec. Statusna koda HTTP je pogosto prvi signal, ki ga vidi nadzorna ravnina, ko gre kaj narobe.

Za poteke dela BYOK obravnava zavrnitve poverilnice ponudnika kot 401 omogoča čistejšo operativno pot. Nadzorna plošča lahko označi poverilnico kot zavrnjeno, začasno ustavi samo prizadeto pot, obvesti pravega lastnika in se izogne ​​porabi proračuna za ponovni poskus za zahtevo, ki bo znova neuspešna. Pomaga tudi ločiti ključno higieno od razpoložljivosti modela. Preklicana poverilnica Vertex ni enak dogodek kot izpad ponudnika ali dogodek omejitve hitrosti.

Platforme prodajnih posrednikov in partnerjev imajo podobno težavo, vendar z večjimi posledicami za stranke. AI API platforma preprodajalcev lahko upravlja ključe, stanje zaračunavanja in poti ponudnika za številne nižje stranke. Če so zavrnjene poverilnice videti kot splošne napake strežnika, lahko ekipe za podporo poročajo o napačnem vzroku, preklopijo na dražjo pot ali krijejo stroške, ki bi jih morali pripisati napačno konfigurirani poverilnici stranke.

Praktična sprememba torej ni le v razčlenjevanju napak. Operaterji bi morali ponovno pregledati pravilnike o ponovnem poskusu, oznake opozoril, kopijo nadzorne plošče in klasifikacijo incidentov. 401 s poti prehoda bi moral na splošno ustaviti samodejne ponovne poskuse ponudnika in premakniti težavo v odpravo poverilnic. 503 pod upravljanim obračunavanjem lahko še vedno upravičuje preverjanje stanja ponudnika, logiko samodejnega preklopa ali incident na strani s stanjem, odvisno od arhitekture izdelka.

Kaj naj razvijalci posodobijo

Razvijalci, ki uporabljajo Cloudflare AI Gateway, morajo preveriti logiko odjemalca, ki obravnava napake ponudnika prek širokih HTTP razredov. Če se odzivi 401 trenutno obravnavajo samo kot težave z žetonom prehoda, bo ta koda morda morala razlikovati med poverilnico Cloudflare aplikacije in poverilnico ponudnika navzgor, ki jo predstavlja koda napake Cloudflare 2009.

Ekipe bi morale pregledati tudi nadomestno usmerjanje. Nadomestna storitev je uporabna, ko ponudnik ni na voljo, je preobremenjen ali zunaj cilja zakasnitve. Bolj tvegano je, če je prvotna napaka težava s poverilnicami stranke. Samodejno preusmerjanje prometa z zavrnjene poti BYOK na pot, ki se zaračuna platformi, lahko povzroči nepričakovane stroške, kršitve pravilnika ali spremembe pri ravnanju s podatki. Izdelki z poenotenim AI API zaračunavanjem morajo to vedenje jasno navesti.

Tudi podporna orodja bi morala postati natančnejša. Koristno stanje nadzorne plošče lahko pove, da je ponudnik zavrnil konfigurirano poverilnico, prepozna prizadeto pot ponudnika in prikaže čas zadnje napake. To je bolj primerno kot generična napaka navzgor. Za poslovne stranke morajo revizijski dnevniki ohraniti statusno kodo, ponudnika, referenco poverilnice in odločitev o usmerjanju, tako da lahko ekipe pojasnijo, ali je zahteva neuspešna, ali je bila vnovična ali premaknjena na drugo obračunsko pot.

Kaj ostaja negotovo

Cloudflarejev dnevnik sprememb identificira Google Vertex kot poseben popravljen primer in imenuje ElevenLabs v širšem kontekstu poverilnic ponudnika, vendar se javna opomba ne bere kot popolna matrika vsakega ponudnika in vsake možne napake poverilnice. Operaterji prehodov bi morali preizkusiti ponudnike, na katere se zanašajo, namesto da predvidevajo, da se vsi scenariji z zavrnjenimi ključi zdaj obnašajo enako.

Obstaja tudi vprašanje zasnove izdelka za platforme, zgrajene na vrhu AI Gateway: kolikšen del besednjaka napak Cloudflare bi moral biti izpostavljen končnim strankam? Neobdelane kode so uporabne za razvijalce, vendar portali preprodajalcev pogosto potrebujejo trajnejšo kategorijo, namenjeno strankam, kot je »poverilnica ponudnika zavrnjena«, ločeno od »obračunavanje prehoda ni na voljo« ali »ponudnik začasno ni na voljo«.

Večja smer je jasna. Prehodi umetne inteligence niso več enostavni prehodni posredniki za modelne klice. So ravnine za nadzor pravilnika in zaračunavanja, majhne razlike v semantiki napak pa lahko odločijo, ali sistem znova poskusi, preklopi, zaračuna stranki ali prosi skrbnika, da znova poveže račun ponudnika.