Rate-Limit-Aware AI API lüüsid: kuju RPM, TPM, sarivõtted ja üürnike õiglus enne 429s tabamust
Praktiline lüüsiarhitektuur LLM API 429-de kaskaadsete tõkestamise vältimiseks: normaliseerige teenusepakkuja piirangud, hinnake märgi survet enne saatmist, reserveerige üürniku kvoot, sujuvad liiklusrabid ja muutke piirangud auditeeritavaks.
LLM-i pakkuja 429 ei ole lihtsalt korduskatse signaal. Tootmises on sageli tõend, et teie rakendus on juba kaotanud kontrolli sissepääsu, rentnike õigluse, latentsusaja või teenusepakkujapõhise kvoodiarvestuse üle.
Üldine parandus – eksponentsiaalne taganemine – on vajalik, kuid mittetäielik. Backoff reageerib pärast seda, kui teenusepakkuja keeldub liiklusest. Intressipiiranguteadlik AI API lüüs peaks liiklust kujundama enne, kui päringud teie süsteemist lahkuvad: hindama lubade survet, reserveerima kvooti, eraldama rentnikke, seadma õiged tööd järjekorda, lükkama vale töö tagasi ja kohandama, kui teenusepakkuja piirangud muutuvad.
Selles artiklis kirjeldatakse praktilist lüüsi kvoodi valitsejat meeskondadele, kes saadavad ühtse API kaudu tootmiskoormust mitmele LLM-i pakkujale.
Lugeja probleem: 429-d on mitmemõõtmelised
Paljud meeskonnad kohtlevad tariifide piiranguid nii, nagu oleks tegemist ühe taotluste minutinumbriga. See eeldus murrab kiiresti LLM-i API-de puhul.
Faktid praegusest pakkuja dokumentatsioonist:
- OpenAI-dokumente, mis piiravad piiranguid, võidakse jõustada reklaamitud minutipiirangust lühemate akende korral, nii et lühikesed sarivõtted võivad ebaõnnestuda isegi siis, kui keskmine minut tundub ohutu.
- Azure OpenAI kvoot määratakse tellimuse, piirkonna, mudeli ja juurutuse tüübi järgi märkides minutis. TPM-i määramine kasutuselevõtule määrab ka jõustatud järelduse RPM-i piirangud ning RPM-i ja TPM-i suhted on mudeliti erinevad.
- Azure OpenAI märgib ka, et intressipiirangu loa arvutused tehakse hinnanguliselt pärast taotluse vastuvõtmist ja need ei ole samad, mis lõplikud arveldusmärgid.
- Antroopsed dokumendid eraldavad taotluste minutis, sisendtunnuste minutis ja väljundlubade minutis piirangud. Piirmäärade ületamine tagastab 429 päisega uuesti proovige pärast.
- Anthropic hoiatab, et liikluse järsk suurenemine võib tabada kiirenduspiiranguid, ja soovitab järk-järgult kiirendada.
- Enamik Claude'i mudelite puhul ei võeta sisendmärke vahemällu lugevaid Anthropic dokumente arvesse sisendmärgi minuti kohta kehtivate piirangute puhul, mis tähendab, et kiire vahemällu salvestamine võib muuta tegelikku vaba ruumi.
- Google Gemini API määrapiirangud on seotud projekti kasutustasemetega, kõrgemad tasemed sõltuvad arvelduse seadistusest, kumulatiivsest kulust ja pärast maksete vahe-eesmärke kulunud ajast.
Kasutustund on selge: OpenAI-ga ühilduv päringu kujund ei tähenda OpenAI-ga ühilduvat kvoodi käitumist. Mitme teenusepakkuja lüüs vajab sisemist kvoodimudelit, mis on rikkalikum kui „proovi uuesti, kui 429”.
Disaini eesmärk: muuta sissepääsukontroll lüüsi vastutusalaks
Intressipiiranguteadlik lüüs peaks enne päringu saatmist vastama viiele küsimusele.
- Milline pakkuja, mudel, juurutus, piirkond, projekt või tööruum taotluse saab?
- Kui palju päringu-, sisend-, väljund- ja samaaegsusvõimsust võib see tarbida?
- Millise rentniku, meeskonna, API-võtme, kliendi või töökoormuse klassi tuleks jagatud võimsuse arvelt tasuda?
- Kas taotlus tuleks kohe vastu võtta, korraks järjekorda panna, alandada, mujale suunata või tagasi lükata?
- Kuidas tuleks broneering kooskõlastada pärast seda, kui teenusepakkuja tagastab tegeliku kasutuse?
Lüüsist saab kvoodi valitseja. See ei asenda teenusepakkuja piiranguid. See muudab teenusepakkuja piirangud teie enda süsteemis nähtavaks, prognoositavaks ja õiglaseks.
Looge normaliseeritud kvoodimudel
Alustage sisemiste piirajate mõõtmete määratlemisega, mis võivad esindada suuremaid pakkujaid ilma neid ühte eksitavasse gruppi sundimata.
Soovitatud piiraja mõõtmed
- RPM: taotlust minutis.
- Sisesta TPM: viip, sõnum, tööriist ja konteksti märgid minutis.
- Väljund-TPM: lõpetamise märgid minutis, reserveeritud eraldi voogesituse ja pikkade põlvkondade jaoks.
- Kogu TPM: kasulik pakkujatele või juurutustele, mis avaldavad kombineeritud märgisurvet.
- Korraaegsus: aktiivsed taotlused, aktiivsed vood või lennu ajal tehtavad tööd.
- Voogesituse kestus: pikaealised voogedastused võivad hõivata ühenduse ja väljundmärke isegi siis, kui RPM on madal.
- Pakkujapõhine ulatus: Azure'i tellimus/regioon/juurutus, antropiline tööruum/mudeliklass, Google'i projekt/tasand või OpenAI organisatsioon/projekt/mudelirühm.
Ärge peitke teenusepakkujapõhiseid mõõtmeid. Normaliseerige need ühiseks skeemiks, kuid säilitage piisavalt üksikasju, et hiljem tagasilükkamist selgitada.
See sisemine objekt peaks olema selgesõnaliselt konfigureeritud, mitte ainult mudelinimede põhjal. Pakkuja armatuurlauad, kontotasemed, piirkondlikud juurutused ja tööruumi sätted võivad kõik muuta sama mudelipere tõhusust.
Prognoosige märgi survet enne saatmist
Pakkujapoolne tariifide piiramine toimub sageli enne, kui lõplik arvelduskasutus on teada. Teie lüüs peaks enne liikluse saatmist tegema samasuguse konservatiivse hinnangu.
Eellennu broneerimise sisendid
- Serialiseeritud viip ja sõnumi pikkus.
- Mudelispetsiifiline tokeniseerimine ja lisakulud rollide, tööriistade, piltide või struktureeritud väljundjuhiste jaoks.
max_completion_tokensvõi samaväärne väljundpiirang.- Selle lõpp-punkti, rentniku, mudeliprofiili ja päringuklassi ajalooline valmimise suhe.
- Oodatakse vahemälu lugemise lubasid, kui kiire vahemälu on saadaval ja mõõdetav.
- Voogesituse lipp ja eeldatav voogeestus.
Alustuseks piisab sageli lihtsast broneerimisreeglist:
estimated_input_tokens = tokenize(request_messages) + model_overhead
hinnangulised_väljundi_märgid = min(
max_completion_tokens,
p95_historical_output_tokens_for_route
)
reserved_total_tokens = hinnangulised_sisendmärgid + hinnangulised_väljundmärgidTundmatute marsruutide puhul kasutage konservatiivset vaikeseadet. Stabiilsete tootmismarsruutide jaoks värskendage hinnanguid pidevalt tegelikust kasutamisest.
Broneerige, seejärel viige vastavusse
Kvoodireserveeringud ei tohiks muutuda püsivateks tasudeks. Kohtle neid nagu kinnipidamisi:
- tsitaat: hinnake sisend- ja väljundrõhku.
- Reserv: lahutage enne saatmist asjakohastest märgisalvedest.
- Arveldage: asendage prognoos pakkuja teatatud kasutusega, kui see on saadaval.
- Tagasimakse või debiteerimine: tagastage kasutamata reserveeritud võimsus või nõudke ülejäägid vajaduse korral järgmisele aknale.
See on kõige olulisem pika konteksti ja voogesituskõnede puhul. Kui kontrollite enne saatmist ainult sisendi TPM-i, võib voog edukalt alata ja seejärel langeda väljundmärgi surve alla. Väljundruumi eraldi reserveerimine vähendab keskmise voo rikke ja seiskumise ohtu.
Üürniku õigluse tagamiseks kasutage hierarhilisi märgisalve
Üks globaalne piiraja kaitseb pakkuja kontot, kuid ei kaitse üürnikke üksteise eest. Üks pika kontekstiga pakktöö võib kasutada jagatud TPM-i ja põhjustada teiste meeskondade interaktiivsete päringute ebaõnnestumist.
Kasutage hierarhilisi märgisalve:
organisatsioon
└── üürnik
└── meeskond
└── api_key
└── mudeli_profiil
└── pakkuja_juurutusTaotlus peab läbima iga asjakohase rühma. See võimaldab teil korraga jõustada mitut poliitikat:
- Organisatsioon ei tohi ületada teenusepakkuja võimsust.
- Üürnik ei saa tarbida rohkem, kui on lepingus sätestatud.
- API-võti ei tohi ületada ettenähtud keskkonna või rakenduse limiiti.
- Partiimudeli profiil ei saa interaktiivset mudeliprofiili näljutada.
- Pakkuja juurutust ei saa üle koormata isegi siis, kui mõnel teisel juurutusel on vaba kvoot.
Õiglane jagamine versus kasutamine
Soovitus: kasutage kaalutud õiglast jagamist kontrollitud sarilaenamisega.
Rangeid üürnikupõhiseid piirmäärasid on lihtne seletada, kuid need võivad kasutamata võimsust ammendada. Sarjalaenutamine parandab kasutamist, võimaldades üürnikul ajutiselt kasutada jagatud kogumi jõudeoleku kvooti. Kompromiss on keerukus: armatuurlauad peavad näitama, mis oli garanteeritud, mis laenati ja millal laenamine tühistati.
Praktiline reegel:
- Andke igale üürnikule garanteeritud lähtetase.
- Luba sarilaenamine kasutamata jagatud võimsusest.
- Võtke laenatud võimsus tagasi, kui ilmub kõrgema prioriteediga või garanteeritud liiklus.
- Ärge kunagi laske laenatud liiklusel luua garanteeritud liikluse jaoks teenusepakkuja tasemel 429-sid.
Enne võistlemist eraldage liiklusklassid
Kõik päringud ei vääri sama järjekorra käitumist. Paigutage liiklus eraldi järjekordade ja kvoodikogumitega mudeliprofiilidesse.
Järjekorras seismine parandab edukuse määra, kuid suurendab saba latentsust. Lüüs peaks selle kompromissi selgelt väljendama. Näiteks võib interaktiivne taotlus oodata kvoodi saamiseks kuni 300 millisekundit, seejärel taanduda või ebaõnnestuda. Igaöine paketttöö võib oodata 20 minutit ja seda peetakse siiski edukaks.
Normaliseerige 429-d üheks veaskeemiks
Isegi hea sissepääsukontrolli korral esineb teenusepakkuja 429 endiselt. Piirangud võivad muutuda, teenusepakkuja hinnangud võivad erineda teie omadest ja liiklus võib tulla oodatust teravamalt.
Normaliseerige iga pakkuja 429 lüüsi veaobjektiks:
Võtmeväli on gateway_decision. 429 pärast lüüsi vastuvõtmist erineb päringust, mille lüüs enne saatmist kohapeal tagasi lükkas. Esimene viitab piiraja kalibreerimise probleemile. Teine tähistab tahtlikku kaitset.
Kohandage pakkuja päistest, kuid ärge sõltuge neist
Mõned pakkujad tagastavad kasulikke päiseid, nagu uuesti proovimise või järelejäänud võimsuse indikaatorid. Kasutage neid võimaluse korral.
Soovitus: pakkuja päised peaksid teie kohalikku valitsejat häälestama, mitte seda asendama.
Põhjused:
- Päise saadavus erineb olenevalt teenusepakkujast ja lõpp-punktist.
- Päised ei pruugi paljastada kõiki piiraja mõõtmeid.
- Uuesti proovimine ütleb teile, millal uuesti proovida, mitte see, milline rentnik peaks järgmisena võimsust saama.
- Pakkujapoolsed lubade hinnangud võivad teie arveldamisest või sisemisest raamatupidamisarvestusest erineda.
Tugev juurutus värskendab päiste põhjal kohalikke kogumite täitmismäärasid ja jahtumisi, jõustades samal ajal rentniku, API-võtme, liiklusklassi ja pakkuja juurutuspiirangud lüüsis.
Lisage üleminekute ja ajastatud tööde jaoks rambiregulaatorid
Paljud piiranguga seotud juhtumid juhtuvad kavandatud muudatuste ajal: ühelt mudelilt teisele üleminek, pakkujate vahetamine, uue agendi töövoo lubamine või ajastatud hindamiskäivitamine.
Soovitus: käsitlege liikluse kasvu kui kontrollitud levitamist.
- Funktsioonilipu mudeli migreerimine rentniku, marsruudi või liikluse protsendi järgi.
- Määrake uute pakkujate juurutamiseks minutipõhise kasvu ülemmäärad.
- Soojendage liiklust järk-järgult tundide jooksul, selle asemel, et kogu liiklust koheselt ümber lülitada.
- Peata levitamine, kui 429 määr, alandamise määr, järjekorra sügavus või p95 latentsus ületab läve.
- Hoidke hädaolukorras tagasipööramise marsruut ühilduvuspoliitikaga, mitte ainult varumudeliga.
Prognoos: kuna pakkuja marsruutimisrežiimid, prioriteeditasemed ja tööruumi taseme juhtelemendid muutuvad tavalisemaks, muutub kaldtee haldamine tavapäraseks lüüsi funktsiooniks, mitte intsidentidele reageerimise skriptiks.
Tagavara on poliitiline otsus, mitte ainult võimsusotsus
Kui üks teenusepakkuja tagastab numbri 429, võib teise teenusepakkuja juurde suunamine olla õige vastus. See võib olla ka ebaturvaline.
Tagavara võib muutuda:
- Väljundi kvaliteet ja juhised on järgmised.
- Konteksti pikkus.
- Tööriistakutse käitumine.
- Struktureeritud väljundi töökindlus.
- Andmete säilitamine ja elukoha poos.
- Kulu ja latentsusaeg.
Kvoodi valitseja peaks küsima ühilduvuskihilt, kas selle päringuklassi puhul on tagavara kasutamine lubatud. Kui ei, peaks see järjekorda jääma või ebaõnnestuma selge kohaliku kiiruspiirangu vastusega, mitte vaikselt semantikat muutma.
Avage otsuseid selgitavad kvootide armatuurlauad
Kvoodisüsteemist, millest keegi aru ei saa, jäetakse mööda. Koostage armatuurlauad tööküsimuste ümber:
- Millised üürnikud tarbivad kõige rohkem RPM-i, sisend-TPM-i ja väljund-TPM-i?
- Millised mudeliprofiilid on järjekorras, lükkavad tagasi või langevad tagasi?
- Milline pakkuja ulatus on kitsaskoht: projekt, piirkond, juurutus, tööruum, mudeliklass või kontotasand?
- Kui sageli erinevad lüüsi hinnangud teenusepakkuja kasutusest?
- Mis on uuesti proovimine pärast jaotust pakkuja ja piiraja tüübi järgi?
- Kui palju tõhusat ruumi loob vahemälu viipade lugemine?
- Millised liiklusklassid laenavad sarivõtte mahtu?
Kliendile või partnerile suunatud toodete puhul kasutage ohutuid juhtseadiseid.
- Võtmepõhised määrapiirangud.
- Meeskonnapõhised sarivõtte piirangud.
- Kliendipõhised päevapiirangud.
- Hädapeatus üürniku või võtme jaoks.
- Hoiatused 429 hüppe, järjekorra kasvu ja ebanormaalse märgisurve kohta.
- Partner API lõpp-punktid edasimüüja kvoodi haldamiseks.
See muudab kiiruse piiramise salapärasest pakkuja veast meeskonna API halduse auditeeritavaks osaks.
Rakendamise kontroll-loend
1. faas: jälgige ja klassifitseerige
- Iga kõne jaoks logi pakkuja, mudel, juurutus, piirkond, tööruum, projekt, rentnik, API võti ja päringuklass.
- Püüdke teenusepakkuja 429-sid koos uuesti proovimise ja toorvea metaandmetega.
- Salvestage hinnangulised ja tegelikud sisend-/väljundmärgid eraldi.
- Telemeetrias eraldage interaktiivne, pakett-, hindamis- ja taustaliiklus.
2. etapp: kohalik sissepääsu kontroll
- Looge RPM-i, sisend-TPM-i, väljundi TPM-i, kogu-TPM-i ja samaaegsuse jaoks sisemised piirajaobjektid.
- Lisage lennueelse loa hinnang.
- Broneerige kvoot enne saatmist ja kooskõlastage pärast teenusepakkuja kasutuse saabumist.
- Keelduge kohapeal, kui taotlus ei mahu selle rentniku või pakkuja ämbrisse.
3. faas: õiglus ja järjekorrad
- Lisage hierarhilisi gruppe alates organisatsioonist kuni pakkuja juurutamiseni.
- Määrake garanteeritud üürniku osakuid ja kontrollige kiiret laenamist.
- Looge liiklusklasside kaupa eraldi järjekorrad.
- Määrake klassipõhised maksimaalsed ooteajad ja varureeglid.
4. faas: kohandamine ja toimingud
- Kasutage teenusepakkuja päiseid, et kohandada jahtumist ja täitmiseeldusi.
- Lisage üleminekute ja ajastatud tööde jaoks rambiregulaatorid.
- Avage kvoodi juhtpaneelid ja märguanded.
- Vaadake igal nädalal üle hinnanguviga ja luhtunud kvoot.
Tehtitav järeldus
Kui teie lüüs proovib uuesti ainult 429 sekundit, töötab see pärast riket. Tootmistasemel AI API lüüs peaks ära hoidma enamiku kiiruspiiranguga seotud tõrkeid, otsustades, kellel on lubatud mida saata, millal ja millise pakkuja kvoodi alusel.
Alustage normaliseeritud piiraja mudeli, lennueelse loa broneerimise ja liiklusklassi järjekordadega. Seejärel lisage hierarhiline rentnike õiglus, pakkuja-päise kohandamine ja rambihaldurid. Tulemuseks pole lihtsalt vähem 429 sekundit. See on selgem võimsuse jaotamine, prognoositavam latentsusaeg, turvalisem migratsioon ja piirangukäitumine, mida teie inseneri-, finants- ja klienditoe meeskonnad saavad tegelikult selgitada.