Cloudflare je prehodu AI Gatewayu dodal kontrolnik, ki omogoča operaterjem, da zahtevajo poverilnice ponudnika za zahteve modela tretjih oseb. Sprememba je majhna v smislu vmesnika, vendar obravnava praktično težavo upravljanja za ekipe, ki usmerjajo promet umetne inteligence prek prehoda: kaj bi se moralo zgoditi, ko stranka, projekt ali najemnik ne predloži veljavnega ključa ponudnika?
Pred to posodobitvijo je lahko Cloudflare AI Gateway uporabljal svojo nastavitev poenotenega zaračunavanja kot nadomestno pot za podprte ponudnike tretjih oseb. To je lahko priročno, če zahteva sicer ne uspe, lahko pa tudi zabriše meje dodeljevanja stroškov in skladnosti. Nova nastavitev BYOK-only lastnikom prehodov omogoča, da preprečijo ta nadomestni prehod in namesto tega zahtevajo, da zahteve uporabljajo izrecno podane poverilnice za prinesi svoj ključ.
Cloudflare pravi, da je nastavitev mogoče omogočiti na nadzorni plošči ali prek API-ja s byok_only=true. Dodal je tudi glavo na zahtevo, cf-aig-no-wholesale, za primere, ko želijo ekipe blokirati veleprodajno ali uporabo poverilnic, ki jih upravlja Cloudflare, pri posameznih klicih.
Kaj se je spremenilo
Dnevnik sprememb AI Gateway z dne 14. septembra uvaja zahtevo po poverilnicah za zahteve ponudnikov tretjih oseb. Ko je omogočen, se prehod ne bo tiho vrnil na poverilnice poenotenega zaračunavanja, ki jih upravlja Cloudflare, če klicatelj ni posredoval sprejemljivih poverilnic ponudnika.
Ta razlika je pomembna, ker prehodi umetne inteligence vedno pogosteje sedijo med številnimi notranjimi aplikacijami, zunanjimi strankami in več ponudniki modelov. Manjkajoči ključ ni samo način tehnične okvare. Odloči se lahko, kateri pravni osebi se zaračuna, kvota ponudnika katerega računa se porabi in ali se uporaba pojavi na pravem stroškovnem mestu.
Novi nadzor daje ekipam platforme strožji način delovanja. Namesto da bi manjkajoče poverilnice stranke obravnaval kot nevšečnost pri usmerjanju, jih lahko prehod obravnava kot kršitev pravilnika. To je še posebej pomembno za nastavitve preprodajalcev, uvedbe ključev v lasti strank in okolja podjetij, kjer mora odnos ponudnika ostati neposredno povezan s poslovno enoto ali najemnikom.
Zakaj je to pomembno za operaterje prehodov AI
Zasnova prehodov AI se je pogosto osredotočala na usmerjanje, zakasnitev, predpomnjenje, ponovne poskuse in abstrakcijo modela. Obnašanje pri zaračunavanju si zasluži enako pozornost. Če prehod samodejno spremeni način poverilnic, ko ena pot ni na voljo, lahko nadaljnja poročila postanejo zavajajoča. Zahteva je lahko videti kot običajen promet aplikacije, medtem ko račun pristane nekje drugje.
Za podjetja, ki uporabljajo plast osrednjega API-ja za nadzor stroškov, to ustvarja operativno tveganje. Finančne ekipe lahko izgubijo čiste podatke o povratnih bremenitvah. Varnostne ekipe morda ne vedo, katera poverilnica je bila dejansko uporabljena. Produktne skupine morda težko pojasnijo, zakaj je bila uporaba enega najemnika zaračunana prek računa platforme namesto lastnega računa ponudnika tega najemnika.
Način samo BYOK pomaga tudi pri zavezah strank. Nekateri kupci zahtevajo, da vzorčne klice urejajo pogodbe njihovega ponudnika, pogoji za obdelavo podatkov ali regionalne nastavitve. Če se lahko prehod vrne na poverilnico za upravljano obračunavanje, postane to zavezo težje uveljaviti, razen če je nadomestna možnost onemogočena s pravilnikom.
Glava na zahtevo doda bolj natančno možnost. Platforma lahko ohrani na voljo širše vedenje poenotenega obračunavanja za nekatere delovne obremenitve, medtem ko ga prepreči za zahteve, ki vsebujejo strožje zahteve glede skladnosti, preprodajalca ali pripisovanja. To razvijalcem omogoča selitveno pot, ne da bi vsako aplikacijo prisilili v najstrožji način hkrati.
Koga to zadeva
Neposredna ciljna skupina je katera koli ekipa, ki uporablja Cloudflare AI Gateway za proxy zahteve tretjim ponudnikom AI. Sprememba je najbolj pomembna, če si več skupin, najemnikov ali strank deli prehod in kjer se pričakuje, da bodo poverilnice ponudnika v lasti zunaj računa osrednje platforme.
Ekipe platforme AI za podjetja bi morale pregledati, ali se njihovo vedenje prehoda ujema z interno politiko. Če naj bi projekt uporabljal lasten račun OpenAI, Anthropic, Google, Mistral ali drugega ponudnika, mora prehod narediti to odvisnost vidno in izvršljivo. Nadomestna rešitev, ki pomaga predstavitvi uspeti, lahko postane težava v produkciji, če skriva pokvarjeno nastavitev poverilnic.
Prodajalni posredniki in partnerske platforme imajo ostrejšo različico iste težave. Če stranke prinesejo lastne ključe ponudnika, potrebujejo operaterji platforme zaupanje, da promet ni pomotoma pretvorjen v uporabo, ki se zaračuna platformi. V nasprotnem primeru lahko to vpliva na marže, račune, revizijske zapise in zaupanje strank.
Prizadeti so tudi razvijalci, čeprav večinoma zaradi jasnejših načinov napak. Z uveljavljanjem samo BYOK zahteva, ki nima ustreznih poverilnic, ne bi smela uspeti, namesto da bi bila usmerjena po alternativni poti zaračunavanja.To lahko zahteva boljša preverjanja vkrcanja, jasnejše obravnavanje napak in preskuse uvajanja, ki preverjajo ključe ponudnika, preden promet začne delovati.
Praktične posledice
Prvi praktični korak je popis pravilnikov. Skupine bi se morale odločiti, katerim delovnim obremenitvam je dovoljeno uporabljati poenoteno obračunavanje, ki ga upravlja Cloudflare, in katere morajo uporabljati poverilnice ponudnika v lasti stranke ali projekta. Ta odločitev mora biti izrecna in ne prepuščena vedenju privzetega prehoda.
Drugi korak je opazljivost. Dnevniki in analitika uporabe morajo zabeležiti, kateri način poverilnice je bil uporabljen, ali je bila zahteva blokirana, ker je bil omogočen samo BYOK, in kateri najemnik ali projekt je zagotovil ključ. Brez te vidnosti lahko strožji nadzor zmanjša dvoumnost zaračunavanja, vendar še vedno pusti operaterjem slabe podatke o odpravljanju težav.
Tretji korak je potek dela razvijalca. Aplikacije, ki so odvisne od AI Gateway, bi morale odpovedati zgodaj, ko manjkajo poverilnice. Zagonsko preverjanje, preverjanje uvedbe ali opozorilo skrbniške konzole je boljše od odkrivanja težave po zavrnitvi produkcijske zahteve.
Preostala negotovost je manj povezana s samo funkcijo in bolj z vzorci sprejemanja. Cloudflare je dokumentiral nov nadzor, vendar se mora vsak operater še odločiti, kje ga bo uporabil. Nekatere ekipe bodo imele raje odpornost nadomestnega zaračunavanja za notranje poskuse. Drugi bodo za promet produkcijskih najemnikov postavili samo BYOK kot privzeto. Pomembna sprememba je, da je to zdaj izbira upravljanja in ne implicitno vedenje, skrito znotraj usmerjevalne plasti.