Kuidas AI API päringupiirangud toimivad

Mis on AI API päringumäärade piirang?

AI API päringumäärade piirang määrab, kui palju tööd saab konto, projekt, organisatsioon, mudel, lõpp-punkt või rakendus teatud aja jooksul esitada. Olenevalt teenusest võib piirang arvestada päringuid, tokeneid, samaaegseid töid, pilte, heli kestust, järjekorras olevate pakktöötluse tokenite arvu, kulutusi või kogu kasutust päevase või libiseva ajavahemiku jooksul.

Näiteks võib teenusepakkuja piirata nii päringute arvu minutis kui ka minutis töödeldavate tokenite arvu. Need on erinevad piirangud. Paljud lühikesed päringud võivad ammendada esmalt päringupiirangu, samas kui mõned pikki dokumente sisaldavad päringud võivad ammendada tokenipiirangu.

Päringumäärade piirangud ei ole sama mis mudeli väljundivorming, kontekstiaken või vastuse maksimaalne pikkus. Need reguleerivad kasutust aja jooksul, mitte seda, mis mahub ühte päringusse.

Miks teenusepakkujad kehtestavad päringumäärade piiranguid?

AI-järeldus kasutab jagatud arvutusressursse ja päringute maksumus võib suuresti erineda. Lühike klassifitseerimispäring ja pika dokumendi analüüs võivad kumbki arvestuda ühe päringuna, kuid teine võib kasutada palju rohkem tokeneid ja töötlemisvõimsust.

Päringumäärade piirangud aitavad teenusepakkujatel:

• kaitsta taristut liikluse hüpete, juhuslike tsüklite ja kuritarvitamise eest;
• jagada piiratud järeldusvõimsust klientide vahel;
• kontrollida kasutust konto, projekti, mudeli ja lõpp-punkti eri tasemetel;
• pakkuda prognoositavaid teenusetasemeid, lubamata piiramatut võimsust.

Need kaitsevad ka teie enda rakendust. Ilma rakenduse tasemel piirangu või järjekorrata võiks üks kasutaja, ajastatud töö või tarkvaraviga ära kasutada kogu jagatud kasutuslimiidi.

Päringumäärade piiramise peamised mõõtmed

Päringud minutis

Päringud minutis ehk RPM piirab seda, kui palju API-kutseid saab teha ühe minuti või võrreldava libiseva ajavahemiku jooksul. Päringud päevas, mida nimetatakse sageli RPD-ks, rakendavad sama põhimõtet pikema ajavahemiku jooksul.

Näidatud piirang 60 päringut minutis ei tähenda tingimata, et 60 päringut saab saata korraga. Teenusepakkujad võivad rakendada ka lühemaid alamaknaid, lühiajalise koormuse piiranguid, samaaegsuspiiranguid või kasutuskiiruse suurendamise reegleid.

Tokenid minutis

Tokenid minutis ehk TPM piirab aja jooksul töödeldava mudeli teksti mahtu. Token on mudeli tokeniseerija toodetud ühik; see ei ole täpselt sama mis sõna. Tokenite arv sõltub keelest, vormindusest ja koodist.

Tokenite arvestus erineb teenusepakkujate vahel. Teenus võib arvestada sisendtokeneid, väljundtokeneid, hinnangulist väljundimahtu või muud teenusepakkujaspetsiifilist kasutust. Mõni süsteem võib reserveerida võimsust taotletud maksimaalse väljundi põhjal juba enne genereerimise lõppu. Ärge eeldage, et kõik API-d arvestavad tokeneid ühtemoodi, vaid kontrollige teenusepakkuja dokumentatsiooni.

Samaaegsus

Samaaegsus näitab, kui palju päringuid või töid võib korraga aktiivsed olla. See erineb RPM-ist. Rakendus võib jääda minutipõhisest päringupiirangust allapoole, kuid avada siiski rohkem samaaegseid genereerimisi, kui teenusepakkuja lubab.

Kvoodid, kulupiirangud ja päevased kasutuslimiidid

Kvoot on laiem kasutuslimiit. See võib hõlmata päevast või igakuist kasutust, järjekorras olevate pakktöötluse tokenite arvu või konto kinnitatud võimsust. Kulupiirang kontrollib kulutatud raha, mitte päringute kiirust. Mõlemad võivad päringuid takistada, kuid lühike ootamine ei pruugi ammendunud arveldus- või kasutuslimiiti taastada.

Lühiajalised koormushüpped ja kasutuskiiruse kasv

Lühiajaline koormushüpe tähendab liikluse järsku koondumist. Kasutuskiiruse kasvupiirang kontrollib, kui kiiresti kasutus suureneb. Rakendusel võib olla nõuetele vastav keskmine kiirus, kuid järsu liikluse kasvu järel võidakse päringuid siiski aeglustada või tagasi lükata.

Mis juhtub päringu saatmisel?

1. Klient saadab lõpp-punkti autentitud päringu.
2. Teenusepakkuja tuvastab asjakohased ulatused, nagu konto, organisatsioon, projekt, API-võti, mudel, piirkond, lõpp-punkt ning mõnikord ka kasutaja või IP-aadress.
3. Teenusepakkuja kontrollib üht või mitut loendurit või eelarvet, sealhulgas päringumäära, tokenite läbilaset, samaaegsust, päevast kvooti ja kulutusi.
4. Kui võimsust on saadaval, võetakse päring vastu ja kasutusarvestust uuendatakse.
5. Kui piirang on ületatud, võib teenusepakkuja päringu tagasi lükata, järjekorda panna, seda aeglustada või tagastada ülekoormuse vastuse.

Teenusepakkujad võivad kasutada tokenikopaid, lekkivaid kopaid, fikseeritud või libisevaid aknaid, libisevaid ajavahemikke, vastuvõtukontrolli, samaaegsuspiiranguid või nende kombinatsioone. Avalik dokumentatsioon kirjeldab sageli jälgitavat piirangut, paljastamata täpset sisemist algoritmi.

Miks võib üks piirang enne teist ammenduda?

Kujutage ette rakendust, mille piirang on 60 päringut minutis ja 100 000 tokenit minutis. Kuuskümmend väikest päringut võivad päringulimiidi ammendada, kasutades samal ajal suhteliselt vähe tokeneid. Kümme suurt dokumendipäringut võivad tokenilimiidi ammendada enne, kui päringuloendur jõuab 60-ni.

Kui sama teenus lubab korraga aktiivsena hoida ainult viit päringut, võib kuue päringu üheaegne saatmine põhjustada samaaegsusvea või järjekorda sattumise isegi siis, kui mõlemas minutipõhises loenduris on veel ruumi. Esmalt ammenduv mõõde määrab, mis juhtub.

Mida tähendab HTTP 429?

HTTP 429 „Too Many Requests” on standardne olek, mida kasutatakse tavaliselt siis, kui klient ületab määra- või ressursipiirangu. See on oluline signaal, kuid ei anna täielikku diagnoosi.

429 võib tähendada ajutist piirangut, liiga palju päringuid, liiga palju tokeneid, ammendunud kasutustaset, projekti kvoodi või kulutustega seotud tingimust. Mõni teenusepakkuja kasutab 429-t ka püsivate kontopiirangute korral. Lugege vastuse sisu, teenusepakkuja veakoodi, vastuse päiseid, juhtpaneeli teavet ja limiidi lähtestamise juhiseid.

Ajutine kliendipoolne piirang erineb ka teenusepakkuja ülekoormusest. Ülekoormusest võidakse teatada HTTP 503, HTTP 529 või mõne muu teenusepakkujaspetsiifilise koodiga isegi siis, kui teie enda kvoot on saadaval.

Retry-After ja vastuse päised

Vastus võib sisaldada päist Retry-After, mis näitab, kui kaua tuleb enne uut katset oodata. Kõik teenusepakkujad ega vead seda ei sisalda. Mõni API avaldab teenusepakkujaspetsiifilistes päistes ka allesjäänud päringu- või tokenivõimsuse ning lähtestamisajad.

Need päised on kasulikud signaalid, kuid nende nimed ja tähendused ei ole universaalsed. Tõlgendage neid teenusepakkuja dokumentatsiooni kohaselt.

Kuidas päringumäärade piiranguid usaldusväärselt käsitleda?

Kasutage järjekorda ja kontrollige samaaegsust

Selle asemel et lubada igal töötajal kohe API-d kutsuda, paigutage tööd järjekorda ja töödelge neid kontrollitud arvu töötajatega. See piirab samaaegsete päringute arvu ja muudab järjekorra pikkuse nähtavaks.

Ajastage päringuid ennetavalt

Päringumäära piiraja võib jaotada päringud aja peale, selle asemel et saata need lühikeste koormushüpetena. Tokenimahukate töökoormuste puhul ei piisa ainult päringupõhisest ajastamisest; hinnake ka tokenivajadust.

Korrake ajutiste tõrgete korral ettevaatlikult

Ajutise 429 või sobiva 5xx-vastuse korral oodake enne uut katset. Kui olemas on Retry-After, järgige selle juhist. Vastasel juhul kasutage eksponentsiaalset tagasipöördumist: suurendage pärast iga ebaõnnestunud katset viivitust, lisage juhuslik hajutus ning määrake maksimaalne viivitus ja katsete arv.

Juhuslik hajutus takistab paljudel töötajatel täpselt samal hetkel uuesti proovimast. Koordineeritud kohesed korduskatsed võivad tekitada nn rahvahulgaefekti ja piirangute kehtimist pikendada.

Ärge proovige lõputult uuesti. Autentimisvead, kehtetud parameetrid, toetamata mudelid, ammendunud krediit, ranged kulupiirangud ja ammendunud päevakvoodid nõuavad üldjuhul seadistuse, arvelduse või operaatori sekkumist, mitte uusi katseid.

Muuda korduv töö ohutuks

Korduskatsed võivad põhjustada töö või kõrvalmõjude dubleerimist. Kirjeid loovate, sõnumeid saatvate või väliseid toiminguid käivitavate operatsioonide puhul kasutage idempotentsusvõtmeid, duplikaatide eemaldamist või püsivat tööolekut, kui rakendus ja teenusepakkuja seda toetavad.

Vähendage tokenite koormust

Kärpige ebavajalikku konteksti, piirake väljundit realistlike vajadustega, kasutage lühikesi viipasid ja vältige sellise teabe korduvat saatmist, mida rakendus ei vaja. Korduva konteksti vahemällu salvestamine, kui seda toetatakse, võib samuti vähendada tööd, kuid see ei kõrvalda kõiki päringu- ega samaaegsuspiiranguid.

Kasutage kiireloomuliste tööde puhul pakktöötlust

Pakktöötluse API-d võivad olla kasulikud suurte asünkroonsete tööde puhul, näiteks kirjete öisel klassifitseerimisel. Neil on sageli eraldi kvoodid ja järjekorrareeglid, seega ei ole pakktöötlus universaalne võimalus teenusepakkuja piirangutest pääsemiseks. See vahetab kohesed vastused läbilaskevõime vastu ning võib kaasa tuua faili-, järjekorra-, töötlemisaja- ja mudelipiiranguid.

Teenusepakkuja piirangud võivad kehtida mitmel tasemel

Teenusepakkuja võib kehtestada piirangud API-võtme, projekti, organisatsiooni, konto, mudeli, mudeliperekonna, lõpp-punkti, piirkonna või rakenduse tasemel. Ühele päringule võivad kehtida mitu ulatust.

Näiteks kirjeldab OpenAI organisatsiooni- ja projektipõhiseid piiranguid, mis erinevad mudeliti, kusjuures mõni mudeliperekond jagab piiranguid. Google Gemini kirjeldab projektipõhiseid ja mudelist sõltuvaid mõõtmeid, nagu päringud minutis, sisendtokenid minutis, päringud päevas ning muud kasutus- või kulupiirangud. Anthropic kirjeldab organisatsioonipõhiseid kasutustasemeid ja kasutab päringumäärade piirangute korral HTTP 429, eristades seda ülekoormusvastustest.

Need näited näitavad, miks teenusepakkujate käitumist ei tohiks pidada universaalseks. API-võtmete lisamine ei pruugi võimsust suurendada, kui tegelik piirang kehtib jagatud projekti, organisatsiooni, konto või arvelduse ulatusele.

Päringumäärade piirangud võrreldes seotud mõistetega

• Kontekstiaken: piirab sisendit ja väljundit, mis mahub ühte päringusse. See ei määra, kui palju päringuid saab aja jooksul saata.
• Väljundtokenite maksimum: piirab üht vastust. TPM piirab päringuteülest tokenite koguläbilaset.
• Päeva- või kuupõhine kvoot: piirab kogukasutust pikema ajavahemiku jooksul. Mõne sekundi ootamine ei pruugi seda taastada.
• Kulupiirang: kontrollib kulutatud raha, mitte päringute kiirust.
• Teenusepakkuja ülekoormus: tähendab, et taustsüsteemil ei pruugi olla piisavalt võimsust isegi siis, kui teie kvoot on saadaval.
• Rakenduse piirang: teie enda tarkvara kehtestatud piirang kasutaja, rentniku või lõpp-punkti kohta. See võib olla teenusepakkuja piirangust rangem.
• Tarbijatoote sõnumipiirang: juturoboti tootes kehtiv piirang, mida ei tohiks eeldada API käitumisega samasuguseks.

Praktiline veaotsingu kontrollnimekiri

Kui päringud hakkavad ebaõnnestuma, uurige probleemi süstemaatiliselt:

1. Salvestage HTTP olek, teenusepakkuja veakood, veateade, ajatempel, mudel, lõpp-punkt ja asjakohased vastuse päised.
2. Kontrollige, kas tõrge on seotud päringumäära, tokenite, samaaegsuse, päeva-, kulutus-, arvelduse-, autoriseerimis- või teenusepakkuja ülekoormuse piiranguga.
3. Võrrelge sisend- ja väljundtokenite hinnangulist arvu tegeliku kasutusega, kui see on saadaval.
4. Otsige koormushüppeid, sünkroonseid korduskatseid, ajastatud töid, töötajate arvu suurenemist või hiljutist mahu kasvu.
5. Kontrollige teenusepakkuja juhtpaneeli ja ajakohast mudelipõhist dokumentatsiooni.
6. Peatage nende vigade korduskatsetamine, mis nõuavad arvelduse, juurdepääsu, kvoodi või seadistuse muutmist.
7. Katsetage uuesti ühe päringuga korraga ja suurendage seejärel samaaegsust järk-järgult.

Kasulik katse on saata 20 väikest päringut ja seejärel viis suurt päringut, logides tokenite hinnangud, olekukoodid, korduskatsete viivitused, samaaegsuse ja kulunud aja. Võrrelge ühtlaselt ajastatud liiklust koormushüppega. See võib näidata, kas töökoormust piiravad päringud, tokenid, samaaegsus või koormushüpete käitumine.

Levinud väärarusaamad

„Kui RPM-i piirangut ei ületata, ei saa päringut piirata.”

Kehtida võivad ka tokeni-, samaaegsus-, päeva-, projekti-, kulu-, jagatud mudeli ja võimsuspiirangud.

„429 tähendab alati, et tuleb kohe uuesti proovida.”

Mõni 429-vastus tähistab arvelduse, kasutustaseme või kvoodiga seotud tingimust, mida korduskatse ei lahenda. Kontrollige esmalt vea üksikasju.

„Voogedastus väldib päringumäärade piiranguid.”

Voogedastus muudab viisi, kuidas väljundit edastatakse. Üldjuhul ei kõrvalda see päringu-, tokeni-, samaaegsus- ega kontopõhiseid piiranguid.

„Tasuline juurdepääs tähendab piiramatut võimsust.”

Tasulised tasemed võivad suurendada kasutuslimiite või anda juurdepääsu suurema võimsusega lahendustele, kuid neil on endiselt dokumenteeritud või kokkulepitud piirangud.

„Eraldi API-võtmed loovad eraldi kvoodid.”

Paljud teenusepakkujad rakendavad piiranguid võtmetasemest kõrgemal, mistõttu võivad mitu võtit kasutada sama projekti, organisatsiooni, konto või arvelduskogumi võimsust.

Peamised järeldused

AI API päringumäärade piirangud on mitmemõõtmelised kontrollmehhanismid, mitte lihtsalt kõnede loendur. Päring võib ebaõnnestuda päringumahu, tokenite läbilaske, samaaegsuse, koormushüppe, päevakvoodi, kulutuste või teenusepakkuja võimsuse tõttu.

Usaldusväärsed rakendused ühendavad ennetava ajastamise ja reageeriva veakäsitluse. Kasutage järjekordi, samaaegsuspiiranguid, tokenipõhist eelarvestamist, eksponentsiaalset tagasipöördumist koos juhusliku hajutusega, piiratud korduskatseid ning selget käsitlust püsivate arvelduse- või autoriseerimisvigade jaoks. Lõpuks käsitlege täpseid piiranguid ja veakäitumist teenusepakkuja- ja mudelipõhiste üksikasjadena, mida tuleb enne tootmiskasutust kontrollida.