Kako zgraditi do ponudnika nevtralnega posrednika za omejitev obrestne mere za API-je LLM z več modeli

Ko si več skupin deli več ponudnikov LLM, omejevanje stopnje ni več podrobnost integracije ponudnika. To postane problem skupne zmogljivosti. En ponudnik lahko omeji zahteve in vhodne žetone, drugi lahko loči vhodne in izhodne žetone, tretji pa lahko uporabi kvote na ravni projekta ali v tekočem oknu porabe. Ponovna poskusna zanka znotraj vsakega SDK ne more uskladiti teh omejitev med najemniki, aplikacijami, partnerskimi ključi in modelnimi potmi.

Praktična rešitev je osrednji posrednik omejitev obrestne mere na prehodu. Posrednik oceni povpraševanje, rezervira zmogljivost pred odpremo, postavi v čakalno vrsto ali zavrne delo v skladu s politiko in uskladi rezervacijo z dejansko uporabo po zaključku. Odzivi ponudnika nato izboljšajo posrednikov pogled na razpoložljivo zmogljivost, namesto da sprožijo neodvisne ponovne nevihte.

Ta arhitektura je uporabna za vsako podjetje LLM API, ki potrebuje predvidljivo pretočnost med notranjimi ekipami, proizvodnimi aplikacijami, agenti za avtomatizacijo ali zunanjimi partnerji.

Zakaj omejitev hitrosti ponudnika ni mogoče zmanjšati na zahteve na minuto

Dejstvo: Kvote ponudnika uporabljajo različne dimenzije in obsege. Običajne dimenzije vključujejo zahteve na minuto, vhodne žetone na minuto, izhodne žetone na minuto, skupno število žetonov, zahteve na dan, sočasnost, okna porabe in omejitve pospeška ali hitrosti. Isti ponudnik lahko izpostavi različne omejitve za organizacijo, projekt, delovni prostor, model ali API izdelek.

Dokumentacija ponudnika na primer opisuje kombinacije, kot so:

• Omejitve zahtev in žetonov s podatki o preostali zmogljivosti in ponastavitvi v glavah odgovorov.
• Ločene omejitve vhodnih in izhodnih žetonov za API-je sporočil.
• Kvote na ravni projekta namesto kvot, priloženih posameznim API ključem.
• Dnevne omejitve zahtev, ki se ponastavijo ob času, ki ga določi ponudnik.
• Tekoča okna, ki temeljijo na porabi, ki lahko zavrnejo promet, tudi če se zdijo stopnje zahtev in žetonov sprejemljive.
• Omejitve pospeška, ki se odzovejo na močno povečanje prometa, tudi če je uporaba v stabilnem stanju pod objavljeno kvoto.

Prehod, ki hrani samo eno številko, imenovano provider RPM, bo sčasoma prepustil promet v eni dimenziji ali premalo izkoristil zmogljivost v drugi. Prav tako ne more pojasniti, ali je do zavrnitve prišlo zaradi pravilnika najemnika, kvote projekta ponudnika, dnevne omejitve ali odziva na preobremenitev.

Referenčna arhitektura za posrednika za omejitev stopnje

Posrednik postavite na pot zahteve pred vmesnik ponudnika. Vsaka zahteva mora iti skozi isti tok rezervacije, ne glede na to, ali je prispela prek ključa SDK, notranje storitve, posrednika za avtomatizacijo ali partnerja API.

1. Normalizirajte identiteto. Razrešite organizacijo, najemnika, ekipo, aplikacijo, okolje, partnerja, API ključ, model poti in razred delovne obremenitve.
2. Ocena povpraševanja. Izračunajte pričakovane vhodne žetone, največje izhodne žetone, ocenjeno porabo in vse stroške sočasnega delovanja.
3. Ocenite politiko. Preverite proračune najemnikov, roke čakalnih vrst, primernost poti, prioriteto in nadomestna pravila.
4. Rezervna zmogljivost. Atomsko rezervirana zmogljivost v ustreznih notranjih vedrih in vedrih, usmerjenih k ponudniku.
5. Pošiljanje. Zahtevo pošljite šele, ko je rezervacija uspešna.
6. Uskladi. Zamenjaj ocene z dejansko uporabo, sprosti neuporabljene rezervacije ter zabeleži glave ponudnika in klasifikacijo odgovorov.
7. Odločite se za naslednje dejanje. Vrnite rezultat, postavite delo v čakalno vrsto, znova poskusite centralno, se vrnite nazaj ali ga zavrnite v skladu s pogodbo o delovni obremenitvi.

Rezervacijska storitev mora biti vodoravno razširljiva, vendar mora biti njena odločitev atomska za vsako zahtevo. Porazdeljeni števec, ki dvema delavcema omogoča, da opazujeta isto preostalo zmogljivost, lahko znova ustvari težavo ponudnika 429 znotraj prehoda.

Uporaba kanoničnega modela kvot brez skrivanja razlik med ponudniki

Definirajte kanonični model, ki lahko predstavlja omejitve, specifične za ponudnika, namesto da vsakega ponudnika vsili v eno abstrakcijo.

Predstavite vsako omejitev kot vedro z obsegom, zmogljivostjo, pravilom za ponovno polnjenje ali ponastavitev, enoto in virom. Projektno vedro ponudnika lahko vsebuje zahteve in vhodne žetone. Vedro delovnega prostora lahko vsebuje izhodne žetone. Politika notranjega partnerja lahko doda sočasnost in omejitve porabe. Odločitev o sprejemu je uspešna le, če uspejo vse zahtevane rezervacije.

Glave ponudnika ne obravnavajte kot popoln vir resnice. Uporabite jih za popravljanje posrednikovih ocen, vendar obdržite konfiguriran model za omejitve, ki niso izpostavljene pri vsakem odgovoru. Imena glav, razpoložljivost in semantika ponastavitve se razlikujejo glede na ponudnika in pot.

Rezervirajte žetone pred pošiljanjem in jih nato uskladite

Rezervacija žetona je najpomembnejša razlika med posrednikom in ovojom za ponovne poskuse. Posrednik potrebuje oceno povpraševanja, preden pošlje zahtevo.

Za vhodne žetone ocenite iz serializiranih sporočil, definicij orodij, strukturirane izhodne sheme in morebitnega pridobljenega konteksta. Za izhodne žetone uporabite največjo vrednost zahteve, če je na voljo, ali oceno, specifično za model in delovno obremenitev, če je odjemalec ne zagotovi. Oceno hranite priloženo rezervaciji, da jo lahko pozneje primerjate z dejansko porabo.

Preprost zapis rezervacije lahko vsebuje:

• Edinstvena zahteva in ID rezervacije.
• Najemnik, aplikacija, API ključ, pot in razred delovne obremenitve.
• Ocenjeni vhodni žetoni, izhodni žetoni, skupno število žetonov in poraba.
• Vsako vedro zaračuna rezervacija.
• Čas ustvarjanja, čas poteka, rok čakalne vrste in ključ idempotence.
• Končna dejanska uporaba in znesek, sproščen ali zaračunan med usklajevanjem.

Konzervativne ocene zmanjšajo odzive ponudnika 429, vendar lahko zmanjšajo zmogljivost. Izmerite napako ocene glede na model, pot, družino pozivov, dolžino konteksta in način strukturiranega izhoda. Nato prilagodite ocene z uporabo omejenih popravkov, namesto da bi dovolili, da ena nenavadna zahteva popači celoten model.

Pretakanje zahteva poseben pravilnik. Rezervirate lahko največji dovoljeni izhod in sprostite neuporabljeni del, ko se tok konča, ali pa rezervirate izhodno zmogljivost v manjših korakih, ko žetoni prispejo. O prvem pristopu je lažje sklepati; drugi lahko izboljša uporabo, vendar zahteva zanesljivo preklic, časovno omejitev in prekinitev povezave.

Uveljavite kvote hierarhično

Zmogljivost je treba preveriti od najožjega pravilnika do najširšega vira v skupni rabi. Tipična hierarhija je:

1. API ključ ali identiteta storitve.
2. Aplikacija in okolje.
3. Najemnik ekipe ali stranke.
4. Račun partnerja ali prodajalca.
5. Delovni prostor ali podračun ponudnika.
6. Projekt ali organizacija ponudnika.
7. Model in pot.

Zahteva iz partnerske aplikacije bo zato morda potrebovala štiri uspešne rezervacije: partnerjevo politiko sočasnosti, proračun žetona najemnika stranke, dodelitev poti prehoda in razpoložljivo kvoto projekta ponudnika. Če katera koli rezervacija ne uspe, sprostite že pridobljene rezervacije in uporabite odločitev za neuspelo vedro.

Zaradi pravičnosti uporabite tehtano pošteno čakalno vrsto ali primanjkljaj krožnega dela, namesto da dovolite, da delavec, ki prvi prispe, porabi skupni bazen. Dodelite višje uteži produkcijskemu prometu in nižje uteži opravilom v ozadju, pri tem pa ohranite razpočne kredite za vsakega najemnika. Trdo particioniranje je lažje razložiti, vendar lahko pusti zmogljivost nedejavno, ko je en najemnik tih. Utežena souporaba na splošno učinkoviteje uporablja zmogljivost, pod pogojem, da imajo hrupni najemniki omejene omejitve izbruha.

Načrtujte čakalne vrste okoli pogodb o delovni obremenitvi

Čakalna vrsta ni samodejno funkcija zanesljivosti. Vidno številko 429 lahko spremeni v nevidno desetminutno zamudo. Vsak razred čakalne vrste potrebuje rok, vedenje preklica, največjo globino in dejanje preobremenitve.

• Interaktivno: Kratek rok, majhna čakalna vrsta, predvidljiva zavrnitev ali degradacija modela, ko zmogljivost ni na voljo.
• Ozadje proizvodnje: Daljši rok, trajna čakalna vrsta, ključ idempotence in nadzorovan proračun za ponovni poskus.
• Partner: Kvote, specifične za najemnika, objavljeni metapodatki odgovora in brez dostopa do stanja čakalne vrste drugega najemnika.
• Paketno: Zakasnjeno izvajanje, večja čakalna vrsta in izbirno usmerjanje k paketu ponudnika API, ko delovna obremenitev to dopušča.

Sprejem v čakalni vrsti mora vrniti jasno odločitev. Odvisno od pogodbe API izpostavite 429 ali odgovor na preobremenitev, specifičen za prehod, z vrednostjo za ponovni poskus, identifikatorjem čakalne vrste in kodo vzroka. Ne obljubljajte časa dokončanja, razen če sistem lahko uveljavi to obljubo.

Paketna obdelava lahko odstrani neinteraktivno delo iz sinhrone zmogljivosti, vendar spremeni časovno razporeditev rezultatov, vedenje ponovnih poskusov, preklic in uskladitev. Obravnavajte ga kot ločeno pot izvajanja, namesto da preprosto postavite sinhrone zahteve v zelo dolgo čakalno vrsto. Za delovne obremenitve v ozadju primerjajte operativne kompromise s politikami nadzora stroškov AI API in obstoječimi paketnimi operacijami.

Centralizirajte ponovni poskus in obravnavanje preobremenitve

Dejstvo: Odgovori na začasno omejitev hitrosti običajno uporabljajo HTTP 429, medtem ko lahko pogoji preobremenitve ponudnika uporabljajo 503 ali kodo napake, specifično za ponudnika. Nekateri ponudniki vrnejo glavo Retry-After in dokumentacija ponudnika priporoča, da jo upoštevate, ko je prisotna. Hitra prometna rampa lahko povzroči tudi pospeševanje ali upočasnitev brez običajne izčrpanosti žlice.

Priporočilo: Ponovni poskus obravnavajte kot spodnjo mejo, ne kot izbirni predlog. Zaustavite prizadeti obseg ponudnika do tega časa, dodajte omejeno tresenje, da preprečite sinhronizirana prebujanja, in pustite posredniku, da se odloči, katere zahteve v čakalni vrsti lahko uporabijo obnovljeno zmogljivost.

Ko Retry-After ni ali je neveljaven, uporabite omejeno eksponentno odmikanje s tresenjem. Proračun za ponovne poskuse hranite v posredniku, ne ločeno v vsakem SDK in adapterju ponudnika. V nasprotnem primeru lahko ena logična zahteva povzroči ponovni poskus prehoda, SDK ponovni poskus, HTTP ponovni poskus odjemalca in ponovno predvajanje na strani ponudnika.

Razvrsti napake pred ponovnim poskusom:

• Zmogljivost, ki jo je mogoče znova poskusiti: Začasni 429 ali dokumentiran prehodni odziv kvote.
• Preobremenitev, ki jo je mogoče znova poskusiti: Začasni 503 ali enakovreden signal preobremenitve ponudnika.
• Napaka pravilnika brez ponovnega poskusa: dnevna kvota, omejitev porabe, onemogočen projekt ali omejitev najemnika.
• Napaka zahteve, ki je ni mogoče ponoviti: Neveljavna shema, nepodprt parameter, napaka pri preverjanju pristnosti ali napačno oblikovan vnos.
• Neuspeh roka: Zahteva, katere preostali uporabnik ali rok poteka dela je krajši od naslednjega varnega poskusa.

Nadomestna možnost je ločena odločitev. Drug ponudnik ima lahko drugačno izhodno vedenje, cene, zakasnitev, rezidenčnost ali omejitve konteksta. Nadomestno možnost uporabite le, če pravilnik o poti potrdi, da lahko pogodba o delovni obremenitvi dopušča te razlike.

Izpostavite odločitve in izmerite nasičenost

Ekipe ne morejo odpraviti težav z dušenjem, če prehod vrne le generično 429. Vrne varne metapodatke, kot so veljavna omejitev, preostala zmogljivost, čas ponastavitve, odločitev o čakalni vrsti, razred delovne obremenitve in razlog za zavrnitev. Izogibajte se razkrivanju uporabe drugega najemnika ali neobdelanih poverilnic ponudnika.

Nadzirajte najmanj:

• Stopnja uspešnosti in zavrnitve rezervacije po najemniku, poti in vedru.
• Globina čakalne vrste, čas čakanja v čakalni vrsti, izteki rokov in odpovedi.
• Stopnje ponudnikov 429 in 503, pogostnost ponovnega poskusa in stopnja zavrnitev.
• Ocenjena uporaba žetona v primerjavi z dejansko uporabo in zapravljena zmogljivost zaradi prevelike rezervacije.
• Nasičenost sočasnosti in delež zmogljivosti, ki jo porabi vsak najemnik.
• Ponovni poskusi na logično zahtevo in nadomestno pogostost.
• Dnevna kvota in prostor za okno porabe.

Preskusi obremenitve morajo vključevati hitri promet, zahteve z dolgim kontekstom, zahteve za največji izhod, prekinitve pretočne povezave, izčrpanost dnevne kvote, odzive ponudnika 429 in 503 ter enega hrupnega najemnika, ki konkurira produkcijskemu prometu. Preverite ne samo, ali so zahteve končno dokončane, ampak tudi, ali roki v čakalni vrsti, pravičnost in proračuni za ponovne poskuse ostanejo nedotaknjeni.

Kontrolni seznam za implementacijo

• Določite kanonične dimenzije, ne da bi zavrgli omejitve, specifične za ponudnika.
• Vsako zahtevo dodelite normaliziranemu najemniku, poti, razredu delovne obremenitve in ključu idempotence.
• Ocenite in rezervirajte vnos, izhod, skupne žetone, porabo, zahteve in sočasnost pred pošiljanjem.
• Naredite rezervacije z več segmenti atomskimi in varno potečite opuščene rezervacije.
• Uskladi dejansko uporabo ponudnika in glave odgovorov po vsakem poskusu.
• Uporabite ponderirano pravičnost, hitre kredite in eksplicitne prednostne razrede.
• Dodajte vsaki čakalni vrsti rok, največjo globino in dejanje preobremenitve.
• Centralizirajte ponovne poskuse in upoštevajte ponudnikove vrednosti Retry-After.
• Ločite začasne napake glede zmogljivosti od stalnih napak pravilnika in zahtev.
• Objava metapodatkov o dušenju in spremljanje nasičenosti po najemniku in poti.
• Izčrpanost kvot ponudnika testiranja, omejitve rampe, pretakanje, nadomestno delovanje in vedenje hrupnega soseda.

Sklep

Prehod z več modeli bi moral kvoto ponudnika upravljati kot skupno zmogljivost infrastrukture, ne kot zbirko neodvisnih SDK nastavitev. Posrednik za omejitev obrestne mere, ki je nevtralen glede ponudnika, daje ekipam platforme eno vstopno pot, en pravilnik pravičnosti, en proračun za ponovni poskus in eno mesto za uskladitev ocen z realnostjo.

Zasnova zahteva več kot le generično žetonsko vedro. Predstavljati mora zahteve, vhodne in izhodne žetone, dnevne kvote, okna porabe, sočasnost, obseg ponudnika in stopnjo naraščanja. Ko so te razsežnosti eksplicitne, lahko prehod sprejme predvidljive odločitve: odpošlje zdaj, postavi v čakalno vrsto z rokom, opusti delo, znova poskusi centralno ali uporabi pogodbeno varno nadomestno možnost. Tako nadzor pretoka postane operativna zmogljivost in ne ponavljajoči se vir produkcijskih incidentov 429 in 503.

Sorodno branje

• paketna obdelava za neinteraktivne delovne obremenitve LLM