Cloudflare je promijenio neglamurozan, ali važan dio AI Gatewaya: što se događa kada uzvodni pružatelj AI odbije korisničku vjerodajnicu.
Prema Cloudflareovom dnevniku promjena AI Gatewaya, POST /ai/run sada vraća dosljednije odgovore kada pružatelj odbije vjerodajnice. Najkonkretniji primjer je Google Vertex. Odbijene vjerodajnice Vertexa koje su prethodno proizvele odgovor HTTP 500, uz uzvodne ponovne pokušaje, sada vraćaju HTTP 401 s Cloudflare šifrom pogreške 2009. Cloudflare kaže da bi aplikacije trebale interpretirati HTTP 401 kao nevažeću ili odbijenu vjerodajnicu davatelja. Nasuprot tome, odbijanje pružatelja usluga u objedinjenoj naplati kojom upravlja Cloudflare preslikava se na HTTP 503.
To zvuči kao usko ažuriranje ugovora o pogrešci. Za timove koji upravljaju AI pristupnicima, to je više od toga. Loš ključ pružatelja usluga ne bi se trebao tretirati kao prolazna pogreška infrastrukture. Kada jest, aplikacije ponovno pokušavaju obaviti posao koji ne može uspjeti, zamjenski sustavi mogu preusmjeriti promet iz pogrešnog razloga, a timovi korisničke podrške moraju razdvojiti neuspjehe autentifikacije od nestabilnosti pružatelja usluga nakon toga.
Što se promijenilo u ugovoru pristupnika
Promjena standardizira razliku koja je važna u proizvodnji: tko može popraviti kvar.
Ako korisnik donese vlastiti ključ davatelja usluga, a taj je ključ nevažeći, opozvan, istekao, nedostaju mu prava projektna dopuštenja ili ga je davatelj odbio, korisnik ili administrator platforme mora popraviti vjerodajnicu. Vraćanje 401 čini to vidljivim. Kaže aplikaciji da provjera autentičnosti nije uspjela na granici pružatelja usluga i da slijepi ponovni pokušaji vjerojatno neće pomoći.
Ranije, barem za odbijene Google Vertex vjerodajnice, Cloudflare kaže da bi greška mogla isplivati kao HTTP 500 i pokrenuti ponovne pokušaje uzvodno. Odgovor 500 obično znači grešku na strani poslužitelja ili uzvodni problem koji može nestati sam od sebe. Mnoge klijentske biblioteke i omotači pristupnika tretiraju tu klasu pogreške kao ponovni pokušaj. U prometu umjetne inteligencije to može biti skupo jer zahtjevi mogu uključivati duge upite, kontekst alata ili masovni skupni rad.
Nova podjela također pojašnjava ponašanje objedinjene naplate. Cloudflare kaže da se odbijanje pružatelja usluga prema Unified Billingu preslikava na HTTP 503. To zadržava pogrešku u obitelji dostupnosti usluge, umjesto da je predstavlja kao ključni problem korisnika. Za softver koji podržava i "donesi svoj ključ" i promet koji se naplaćuje putem pristupnika, ova bi razlika trebala oblikovati i pravila ponovnog pokušaja i poruke upućene korisniku.
Zašto je to važno za BYOK i proizvode preprodavača
Ažuriranje dolazi na tržište gdje više AI platformi kombiniraju pristup koji se naplaćuje putem pristupnika s vjerodajnicama koje dostavljaju korisnici. Multi-model API pristupnik za timove može usmjeriti jedan zahtjev preko računa platforme, drugi kroz korisnikov OpenAI ključ, a treći kroz Google Cloud projekt kojim upravlja poslovni kupac. Statusni kod HTTP često je prvi signal koji kontrolna razina vidi kada nešto pođe po zlu.
Za BYOK tijekove rada, tretiranje odbijanja vjerodajnice davatelja kao 401 omogućuje čistiji radni put. Nadzorna ploča može označiti vjerodajnicu kao odbijenu, pauzirati samo zahvaćenu rutu, obavijestiti vlasnika prava i izbjeći trošenje proračuna za ponovni pokušaj na zahtjev koji ponovno neće uspjeti. Također pomaže odvojiti ključnu higijenu od dostupnosti modela. Opozvana Vertex vjerodajnica nije isti incident kao ispad pružatelja usluge ili događaj ograničenja brzine.
Platforme prodavača i partnera imaju sličan problem, ali s većim posljedicama za klijente. AI API platforma preprodavača može upravljati ključevima, stanjem naplate i rutama pružatelja za mnoge klijente na nižem nivou. Ako odbijene vjerodajnice izgledaju kao generičke pogreške poslužitelja, timovi za podršku mogu prijaviti krivi uzrok, prijeći na skuplju rutu ili apsorbirati troškove koji su trebali biti pripisani korisnikovoj pogrešno konfiguriranoj vjerodajnici.
Praktična promjena stoga nije samo u raščlanjivanju pogrešaka. Operateri bi trebali ponovno pregledati pravila ponovnih pokušaja, oznake upozorenja, kopiju nadzorne ploče i klasifikaciju incidenata. 401 s putanje pristupnika općenito bi trebao zaustaviti automatske ponovne pokušaje pružatelja usluga i premjestiti problem na ispravljanje vjerodajnica. 503 prema upravljanoj naplati i dalje može zahtijevati provjere ispravnosti davatelja usluga, logiku preusmjeravanja greške ili incident stranice statusa, ovisno o arhitekturi proizvoda.
Što bi programeri trebali ažurirati
Razvojni programeri koji koriste Cloudflare AI Gateway trebali bi provjeriti bilo koju logiku klijenta koja obrađuje kvarove pružatelja putem širokih HTTP klasa. Ako se odgovorima 401 trenutačno rukuje samo kao problemima gateway-tokena, taj kod će možda trebati razlikovati Cloudflare vjerodajnice aplikacije i vjerodajnice uzvodnog pružatelja predstavljene Cloudflare šifrom pogreške 2009.
Timovi bi također trebali pregledati rezervno usmjeravanje. Zamjena je korisna kada je pružatelj nedostupan, preopterećen ili izvan ciljne latencije. Rizičnije je kada je izvorni kvar problem s vjerodajnicama korisnika. Automatsko preusmjeravanje prometa s odbijene BYOK rute na rutu koja se naplaćuje platformom može stvoriti neočekivane troškove, kršenja pravila ili promjene u rukovanju podacima. Proizvodi s objedinjenom AI API naplatom moraju to ponašanje učiniti eksplicitnim.
Alati za podršku također bi trebali postati precizniji. Korisno stanje na nadzornoj ploči moglo bi reći da je pružatelj odbio konfiguriranu vjerodajnicu, identificirati pogođenu rutu pružatelja i prikazati vrijeme posljednjeg kvara. To je djelotvornije nego generička uzvodna pogreška. Za poslovne korisnike, revizijski zapisnici trebali bi sačuvati statusni kod, davatelja, referencu vjerodajnice i odluku o usmjeravanju kako bi timovi mogli objasniti je li zahtjev neuspješan, ponovni pokušaj ili premješten na drugi put naplate.
Ono što ostaje neizvjesno
Cloudflareov zapisnik promjena identificira Google Vertex kao određeni ispravljeni slučaj i imenuje ElevenLabs u širem kontekstu vjerodajnica pružatelja, ali javna bilješka ne čita se kao potpuna matrica svakog pružatelja i svake moguće greške vjerodajnice. Operateri pristupnika trebali bi testirati pružatelje na koje se oslanjaju umjesto da pretpostavljaju da se svi scenariji odbijenih ključeva sada ponašaju identično.
Postoji i pitanje dizajna proizvoda za platforme izgrađene na AI Gatewayu: koliko Cloudflareovog vokabulara pogrešaka treba biti izloženo krajnjim korisnicima? Neobrađeni kodovi korisni su za programere, ali portali preprodavača često trebaju trajniju kategoriju okrenutu klijentima, kao što je "vjerodajnica davatelja odbijena", odvojena od "naplata pristupnika nedostupna" ili "pružatelj privremeno nedostupan."
Širi smjer je jasan. AI pristupnici više nisu jednostavni prolazni proxyji za pozive modela. Oni su razine kontrole pravila i naplate, a male razlike u semantici pogreške mogu odlučiti hoće li sustav pokušati ponovno, prestati raditi, naplatiti korisniku ili zatražiti od administratora da ponovno poveže račun pružatelja usluga.