Kako izgraditi posrednika za ograničenje stope koji je neutralan prema pružatelju usluga za višemodelne LLM API-je

Kada nekoliko timova dijeli više pružatelja LLM-a, ograničavanje stope prestaje biti detalj integracije pružatelja. To postaje problem dijeljenog kapaciteta. Jedan pružatelj može ograničiti zahtjeve i ulazne tokene, drugi može odvojiti ulazne i izlazne tokene, a treći može primijeniti kvote na razini projekta ili kroz pokretni prozor potrošnje. Petlja ponovnog pokušaja unutar svakog SDK ne može koordinirati ta ograničenja između zakupaca, aplikacija, ključeva partnera i ruta modela.

Praktično rješenje je posrednik središnjeg ograničenja stope na pristupniku. Posrednik procjenjuje potražnju, rezervira kapacitet prije slanja, stavlja u red ili odbija posao u skladu s politikom i usklađuje rezervaciju sa stvarnim korištenjem nakon završetka. Odgovori pružatelja zatim pročišćavaju brokerov pogled na raspoloživi kapacitet umjesto da pokreću nezavisne oluje ponovnih pokušaja.

Ova je arhitektura korisna za bilo koje poduzeće LLM API koje treba predvidljivu propusnost preko internih timova, proizvodnih aplikacija, agenata za automatizaciju ili vanjskih partnera.

Zašto se ograničenja stope pružatelja ne mogu svesti na zahtjeve po minuti

Činjenica: Kvote davatelja koriste različite dimenzije i opsege. Uobičajene dimenzije uključuju zahtjeve po minuti, ulazne tokene po minuti, izlazne tokene po minuti, ukupne tokene, zahtjeve po danu, konkurentnost, prozore potrošnje i ograničenja ubrzanja ili rampe. Isti pružatelj može izložiti različita ograničenja za organizaciju, projekt, radni prostor, model ili API proizvod.

Na primjer, dokumentacija dobavljača opisuje kombinacije kao što su:

• Ograničenja zahtjeva i tokena s informacijama o preostalom kapacitetu i resetiranju u zaglavljima odgovora.
• Odvojena ograničenja ulaznog i izlaznog tokena za API-je poruka.
• Kvote na razini projekta umjesto kvota povezanih s pojedinačnim API ključevima.
• Dnevna ograničenja zahtjeva koja se poništavaju u vrijeme koje definira pružatelj usluga.
• Pokretni prozori temeljeni na potrošnji koji mogu odbiti promet čak i kada se cijene zahtjeva i tokena čine prihvatljivima.
• Ograničenja ubrzanja koja reagiraju na nagli porast prometa, čak i kada je upotreba u stabilnom stanju ispod objavljene kvote.

Gateway koji pohranjuje samo jedan broj pod nazivom provider RPM na kraju će prepustiti promet u jednoj dimenziji ili premalo iskoristiti kapacitet u drugoj. Također ne može objasniti je li do odbijanja došlo zbog pravila stanara, projektne kvote pružatelja usluga, dnevnog ograničenja ili odgovora na preopterećenje.

Referentna arhitektura za brokera ograničenja stope

Postavite brokera na stazu zahtjeva prije adaptera pružatelja. Svaki zahtjev treba proći kroz isti tok rezervacije, bez obzira na to je li stigao putem ključa SDK, interne usluge, agenta za automatizaciju ili partnera API.

1. Normalizirajte identitet. Razriješite organizaciju, stanara, tim, aplikaciju, okruženje, partnera, API ključ, rutu modela i klasu radnog opterećenja.
2. Procijenite potražnju. Izračunajte očekivane ulazne tokene, maksimalne izlazne tokene, procijenjenu potrošnju i sve troškove istovremenosti.
3. Procijenite pravila. Provjerite proračune zakupaca, rokove u redu čekanja, prihvatljivost rute, prioritet i rezervna pravila.
4. Rezervni kapacitet. Atomski rezervni kapacitet u relevantnim internim spremnicima i segmentima okrenutim prema pružatelju.
5. Pošalji. Pošaljite zahtjev tek nakon što rezervacija uspije.
6. Uskladi. Zamijeni procjene stvarnom upotrebom, otpusti neiskorištene rezervacije i zabilježi zaglavlja pružatelja usluga i klasifikaciju odgovora.
7. Odlučite o sljedećoj radnji. Vratite rezultat, stavite posao u red čekanja, ponovno pokušajte centralno, vratite se natrag ili ga odbacite prema ugovoru o radnom opterećenju.

Usluga rezervacije trebala bi biti horizontalno skalabilna, ali njezina odluka mora biti atomska za svaki zahtjev. Distribuirani brojač koji omogućuje dvojici radnika da promatraju isti preostali kapacitet može ponovno stvoriti problem pružatelja 429 unutar pristupnika.

Koristite kanonski model kvote bez skrivanja razlika u pružatelju usluga

Definirajte kanonski model koji može predstavljati ograničenja specifična za pružatelja usluga umjesto prisiljavanja svakog pružatelja na jednu apstrakciju.

Predstavite svako ograničenje kao kantu s opsegom, kapacitetom, pravilom za ponovno punjenje ili poništavanje, jedinicom i izvorom. Kanta projekta pružatelja može sadržavati zahtjeve i ulazne tokene. Kanta radnog prostora može sadržavati izlazne tokene. Politika internog partnera može dodati istodobnost i ograničenja potrošnje. Odluka o prijemu je uspješna samo ako su sve potrebne rezervacije uspješne.

Nemojte zaglavlja pružatelja smatrati potpunim izvorom istine. Koristite ih za ispravljanje brokerovih procjena, ali zadržite konfigurirani model za ograničenja koja nisu izložena pri svakom odgovoru. Nazivi zaglavlja, dostupnost i semantika poništavanja ovise o pružatelju i ruti.

Rezervirajte tokene prije slanja, a zatim ih uskladite

Rezervacija tokena najvažnija je razlika između brokera i omotača za ponovni pokušaj. Posrednik treba procjenu potražnje prije slanja zahtjeva.

Za ulazne tokene, procijenite iz serijaliziranih poruka, definicija alata, sheme strukturiranog izlaza i bilo kojeg dohvaćenog konteksta. Za izlazne tokene koristite maksimum zahtjeva kada je dostupan ili procjenu specifičnu za model i radno opterećenje kada je klijent ne daje. Držite procjenu priloženu uz rezervaciju kako biste je kasnije mogli usporediti sa stvarnim korištenjem.

A simple reservation record can contain:

• A unique request and reservation ID.
• Zakupac, aplikacija, API ključ, ruta i klasa radnog opterećenja.
• Procijenjeni ulazni tokeni, izlazni tokeni, ukupni tokeni i potrošnja.
• Svaku kantu naplaćuje rezervacija.
• Vrijeme stvaranja, vrijeme isteka, rok čekanja i ključ idempotencije.
• Konačna stvarna upotreba i iznos oslobođen ili naplaćen tijekom usklađivanja.

Konzervativne procjene smanjuju odgovore pružatelja 429, ali mogu smanjiti kapacitet. Mjerite pogrešku procjene prema modelu, ruti, obitelji upita, duljini konteksta i načinu strukturiranog izlaza. Zatim prilagodite procjene korištenjem ograničenih korekcija umjesto da dopustite da jedan neobičan zahtjev iskrivi cijeli model.

Streaming requires a specific policy. Možete rezervirati maksimalni izlazni kapacitet i osloboditi neiskorišteni dio kada tok završi ili rezervirati izlazni kapacitet u manjim koracima kako tokeni pristižu. The first approach is easier to reason about; drugi može poboljšati korištenje, ali zahtijeva pouzdano rukovanje otkazivanjem, vremenskim ograničenjem i prekidom veze.

Enforce quotas hierarchically

Kapacitet treba provjeriti od najužeg pravila do najšireg zajedničkog resursa. A typical hierarchy is:

1. API key or service identity.
2. Application and environment.
3. Team or customer tenant.
4. Partner or reseller account.
5. Provider workspace or subaccount.
6. Provider project or organization.
7. Model and route.

Zahtjev iz partnerske aplikacije stoga može zahtijevati četiri uspješne rezervacije: partnerova politika istovremenosti, proračun tokena korisnika zakupca, dodjela rute pristupnika i dostupna kvota projekta pružatelja. Ako bilo koja rezervacija ne uspije, oslobodite već stečene rezervacije i primijenite odluku neuspjelog segmenta.

Radi poštenja, upotrijebite ponderirano pošteno čekanje u redu ili manjak kružnog rada umjesto da dopustite onom radniku koji prvi stigne da iskoristi zajednički skup. Dodijelite veće pondere proizvodnom prometu i manje pondere pozadinskim poslovima, uz očuvanje burst kredita za svakog stanara. Tvrdo particioniranje je lakše objasniti, ali može ostaviti kapacitet u stanju mirovanja kada je jedan stanar tih. Ponderirano dijeljenje općenito učinkovitije koristi kapacitet, pod uvjetom da bučni stanari imaju ograničena ograničenja praska.

Dizajnirajte redove oko ugovora o radnom opterećenju

Ček čekanja nije automatski značajka pouzdanosti. Može pretvoriti vidljivi 429 u nevidljivo desetominutno kašnjenje. Svaka klasa reda čekanja treba rok, ponašanje otkazivanja, maksimalnu dubinu i radnju preopterećenja.

• Interaktivno: Kratak rok, mali red, predvidljivo odbijanje ili degradacija modela kada kapacitet nije dostupan.
• Pozadina proizvodnje: Dulji rok, izdržljivi red čekanja, ključ idempotencije i kontrolirani proračun za ponovni pokušaj.
• Partner: Kvote specifične za stanara, objavljeni metapodaci odgovora i nema pristupa stanju čekanja drugog stanara.
• Batchable: Odgođeno izvršenje, veći red čekanja i izborno usmjeravanje prema paketu pružatelja API kada radno opterećenje to dopušta.

Prijem u red čekanja trebao bi dati jasnu odluku. Ovisno o API ugovoru, izložite 429 ili odgovor preopterećenja specifičan za pristupnik s vrijednošću ponovnog pokušaja, identifikatorom čekanja i kodom razloga. Nemojte obećavati vrijeme dovršetka osim ako sustav ne može izvršiti to obećanje.

Skupna obrada može ukloniti neinteraktivan rad iz sinkronog kapaciteta, ali mijenja vrijeme rezultata, ponašanje ponovnog pokušaja, otkazivanje i usklađivanje. Tretirajte ga kao zaseban put izvršenja umjesto jednostavnog postavljanja sinkronih zahtjeva u vrlo dugačak red čekanja. Za pozadinska radna opterećenja, usporedite operativne kompromise s AI API politikama kontrole troškova i postojećim skupnim operacijama.

Centraliziranje ponovnog pokušaja i rukovanje preopterećenjem

Činjenica: Odgovori na privremena ograničenja brzine obično koriste HTTP 429, dok uvjeti preopterećenja pružatelja mogu koristiti 503 ili kôd pogreške specifičan za pružatelja. Neki davatelji vraćaju zaglavlje Retry-After, a dokumentacija davatelja preporučuje da ga poštujete kada postoji. Brza prometna rampa također može proizvesti ubrzanje ili usporavanje bez običnog iscrpljivanja kante.

Preporuka: Tretirajte Retry-After kao donju granicu, a ne kao neobavezan prijedlog. Pauzirajte zahvaćeni opseg pružatelja usluga do tog vremena, dodajte ograničeno podrhtavanje kako biste spriječili sinkronizirana buđenja i pustite posrednika da odluči koji zahtjevi u redu čekanja mogu koristiti obnovljeni kapacitet.

Kada je Retry-After odsutan ili nevažeći, upotrijebite ograničeno eksponencijalno odlaganje s podrhtavanjem. Držite proračun za ponovni pokušaj u posredniku, a ne zasebno u svakom SDK i adapteru pružatelja usluga. U suprotnom, jedan logički zahtjev može proizvesti ponovni pokušaj pristupnika, SDK ponovni pokušaj, HTTP ponovni pokušaj klijenta i ponovnu reprodukciju na strani pružatelja usluga.

Klasificirajte pogreške prije ponovnog pokušaja:

• Kapacitet za ponovni pokušaj: Privremeni 429 ili dokumentirani prolazni odgovor na kvotu.
• Preopterećenje koje se može ponoviti: Privremeni 503 ili ekvivalentni signal preopterećenja pružatelja usluga.
• Pogreška pravila koja se ne mogu ponovno pokušati: dnevna kvota, ograničenje potrošnje, onemogućeni projekt ili ograničenje zakupca.
• Neuspjeh zahtjeva koji se ne može ponovno pokušati: Nevažeća shema, nepodržani parametar, neuspjeh provjere autentičnosti ili neispravan unos.
• Neuspjeh roka: Zahtjev čiji je preostali korisnik ili rok tijeka rada kraći od sljedećeg sigurnog pokušaja.

Zamjena je zasebna odluka. Različiti pružatelji mogu imati različito izlazno ponašanje, cijene, latenciju, prebivalište ili ograničenja konteksta. Koristite zamjenu samo kada politika rute potvrdi da ugovor o radnom opterećenju može tolerirati te razlike.

Izložite odluke i izmjerite zasićenost

Timovi ne mogu riješiti probleme s prigušivanjem ako pristupnik vraća samo generički 429. Vrati sigurne metapodatke kao što su primjenjivo ograničenje, preostali kapacitet, vrijeme ponovnog postavljanja, odluka o čekanju, klasa radnog opterećenja i razlog odbijanja. Izbjegavajte izlaganje korištenja drugog stanara ili neobrađenih vjerodajnica davatelja.

Nadzirite najmanje:

• Stopa uspješnosti i odbijanja rezervacije prema stanarima, ruti i segmentu.
• Dubina čekanja, vrijeme čekanja u redu, istek roka i otkazivanja.
• Stope davatelja usluga 429 i 503, učestalost ponovnog pokušaja nakon i stopa odbijanja rampe.
• Procijenjena naspram stvarne upotrebe tokena i kapaciteta izgubljenog prekomjernom rezervacijom.
• Zasićenost istovremenosti i udio kapaciteta koji troši svaki stanar.
• Ponovni pokušaji po logičnom zahtjevu i zamjenskoj učestalosti.
• Dnevna kvota i prostor za potrošnju.

Testovi opterećenja trebaju uključivati brzi promet, zahtjeve dugog konteksta, zahtjeve za maksimalnim izlazom, prekide strujanja, iscrpljenost dnevne kvote, odgovore davatelja 429 i 503 i jednog bučnog stanara koji se natječe s produkcijskim prometom. Provjerite ne samo jesu li zahtjevi na kraju dovršeni, nego i jesu li rokovi čekanja, pravednost i proračuni za ponovne pokušaje ostali nepromijenjeni.

Popis za provjeru implementacije

• Definirajte kanonske dimenzije bez odbacivanja ograničenja specifičnih za pružatelja usluga.
• Dodijelite svakom zahtjevu normaliziranog stanara, rutu, klasu radnog opterećenja i ključ idempotencije.
• Procijenite i rezervirajte ulaz, izlaz, ukupne tokene, potrošnju, zahtjeve i istovremenost prije slanja.
• Napravite atomske rezervacije s više spremnika i sigurno isteknite napuštene rezervacije.
• Uskladite stvarnu upotrebu pružatelja usluga i zaglavlja odgovora nakon svakog pokušaja.
• Koristite ponderiranu pravednost, brze kredite i eksplicitne klase prioriteta.
• Dajte svakom redu čekanja rok, maksimalnu dubinu i radnju preopterećenja.
• Centralizirajte ponovne pokušaje i poštujte vrijednosti Retry-After pružatelja usluge.
• Odvojite privremene pogreške kapaciteta od stalnih pogrešaka pravila i zahtjeva.
• Objavite metapodatke o prigušivanju i nadzirite zasićenost po zakupcu i ruti.
• Iscrpljenost kvote davatelja testova, ograničenja rampe, strujanje, zamjena i bučno ponašanje susjeda.

Zaključak

Pristupnik s više modela trebao bi upravljati kvotom pružatelja usluga kao zajedničkim kapacitetom infrastrukture, a ne kao skupom neovisnih SDK postavki. Posrednik s ograničenjem stope koji je neutralan u odnosu na pružatelja usluga daje platformskim timovima jedan pristupni put, jednu politiku pravednosti, jedan proračun za ponovni pokušaj i jedno mjesto za usklađivanje procjena sa stvarnošću.

Dizajn zahtijeva više od generičkog spremnika tokena. Mora predstavljati zahtjeve, ulazne i izlazne tokene, dnevne kvote, prozore potrošnje, konkurentnost, opseg pružatelja i stopu povećanja. Nakon što su te dimenzije eksplicitne, pristupnik može donositi predvidljive izbore: otpremiti sada, staviti u red s rokom, prekinuti rad, ponovno pokušati centralno ili koristiti zamjenu sigurnu za ugovor. Tako kontrola propusnosti postaje operativna sposobnost, a ne stalni izvor incidenata proizvodnje 429 i 503.

Povezana literatura

• skupna obrada za neinteraktivna radna opterećenja LLM-a