Mitä ovat LLM API -rajat?

Mikä on nopeusrajoitus tässä API:ssa

Nopeusrajoitus tässä on katto per "bucket" kiinteän aikavälin sisällä. Rajoitin laskee pyynnön API-prosessin sisällä, päästää ensimmäiset läpi ja hylkää seuraavan HTTP 429 -virheellä. Ei ole token bucketia, leaky bucketia eikä jaettua laskuria klusterin yli: "bucket" on nimi, raja ja aikaväli, ja jokainen rajoitussivun numero on renderöity samasta objektista, jota rajoitin itse lukee, eikä dokumenttiin kirjoitettu.

"Bucketit" ja niiden numerot

Päättely-bucketit ovat ne kaksi, jotka useimmat kutsujat kohtaavat. key_chat sallii 600 päättelykutsua per API-avain yhden minuutin aikavälillä; org_chat sallii 1800 päättelykutsua koko organisaatiossa samassa minuutissa. Molempien on läpäistävä, jotta kutsu etenee, ja tämä on tarkoituksellista eikä redundanttia: yksi meluisa avain ei voi kuluttaa organisaation koko budjettia, ja yksi kiireinen organisaatio ei voi nääntyä yhden avaimen takia, joka lasketaan vain itseään vastaan.

Alustan API lasketaan erikseen. platform sallii 300 kutsua per avain per minuutti organisaation luku- ja kirjoitustoiminnoille – avaimille, käytölle, jäljityksille, käytännöille. Julkisilla pinnoilla on omat IP-pohjaiset "bucketinsa": public_chat sallii 20 anonyymiä leikkikenttäkutsua per IP-osoite per tunti, public_card_request sallii 5 mallikorttipyyntöä julkisesta lomakkeesta per IP per tunti, ja auth sallii 20 sisäänkirjautumis-, rekisteröitymis-, salasanan palautus- ja nollausyritystä per IP viidentoista minuutin aikavälillä.

Yksi rivi kyseisessä taulukossa on varoitus eikä hallinta. public_page on määritelty rajalla 300 pyyntöä per tunti per IP, eikä mikään tämän käyttöönoton pyyntöpolku tarkista sitä. Se tulostetaan "ei pakotettu" -merkinnällä, koska dokumentaatiossa oleva numero, jota mikään ei sovella, ei ole raja, ja aukon piilottaminen tekisi jokaisesta muusta sivun numerosta vähemmän uskottavan.

Mitä hylkääminen todella sisältää

Hylätty pyyntö on HTTP 429, tyyppi rate_limit_error ja koodi rate_limit_exceeded. Tämä käyttöönotto ei aseta retry-after-otsaketta eikä x-ratelimit-otsakkeita lainkaan, joten vastausrunko on ainoa kello, jonka saat. Jos rajoitin tietää, milloin sen aikaväli päättyy, viesti päättyy siihen hetkeen ISO 8601 -muodossa, esimerkiksi Retry after -aikaleimaan. Organisaatiokohtaisessa rajassa viesti ei nimeä aikaa lainkaan, joten eksponentiaalinen takaisinkytkentä on ainoa rehellinen strategia siinä. Aikaisempi uudelleenyritys ei voi onnistua: laskuri liikkuu vain, kun aikaväli vaihtuu.

Samanaikaisuus on myös rajoitettu

Enintään 8 pyyntöä voi olla käynnissä yhdellä API-avaimella kerrallaan. Laskuri pidetään avainkohtaisesti eikä organisaatiokohtaisesti, se nousee, kun kutsu saapuu chat-käsittelijään ja laskee, kun se päättyy, ja rajan ylittävä pyyntö hylätään heti samalla 429-virheellä. Sen takana ei ole jonoa, mikä on se osa, jonka ihmiset unohtavat: ylirajoitettu samanaikainen pyyntö ei hidastu, se hylätään.

Miksi aikavälit ovat prosessikohtaisia

Aikavälit elävät API-prosessin muistissa. Ne kirjoitetaan takaisin rate_limits-taulukkoon 15 sekunnin välein ja sammutettaessa, ja palautetaan, kun prosessi käynnistyy, joten uudelleenkäynnistys jatkaa aikaväliä sen sijaan, että antaisi uuden budjetin. Seurauksena on todettu eikä löydetty: laskuri on API-solmukohtainen, joten kaksi API-solmua kaksinkertaistavat jokaisen tehokkaan rajan. Jaettu versio tarvitsisi tallennustilan, jota mikään ei vielä lue – REDIS_URL on varattu sille ja käyttämätön, joten käytännön neuvo on ajaa yksi API-solmu tai hyväksyä solmukohtaiset rajat tietoisesti.

Mikä ei ole nopeusrajoitus

Kolme hylkäämistä näyttää kuristukselta, mutta eivät ole sitä. Organisaation päivittäinen kulutuskatto vastaa 402 budget_exceeded ennen kuin mikään päätepiste pisteytetään; se on rahaa, ei nopeutta. Miljoonaa tokenia kohti asetettu hintakatto poistaa päätepisteen ehdokasjoukosta reitityksen aikana sen sijaan, että hylkäisi pyynnön, joten kutsu onnistuu silti halvemmalla päätepisteellä. Ja 409 no_endpoint_for_policy on residenssisuodatin, joka kieltäytyy löyhentämästä itseään; sen uudelleenyrittäminen ei muuta mitään, koska sama pyyntö epäonnistuu samalla tavalla. Vain 429 on uudelleenyrityksen arvoinen takaisinkytkennällä.

Pyyntöjen rungot on rajattu 1 Mt:iin ja ne validoidaan ennen mitään muuta, mikä on kokorajoitus eikä nopeusrajoitus, ja pinon jäljitykset kirjataan lokiin sen sijaan, että ne palautettaisiin kutsujalle.

Miten suunnitella rajoitusten ympärille

Laske, mitä integraatiosi todella lähettää avainta kohti minuutissa, ja muista, että suoratoistettu valmistuminen pitää yhden käynnissä olevan paikan koko kestonsa ajan. Jos useat palvelut jakavat yhden avaimen, ne jakavat sen 600 kutsua ja sen 8 samanaikaista paikkaa; erilliset avaimet yhden organisaation alla täyttävät silti yhdessä 1800 kutsun organisaatiokaton. Lue rajoitussivu ennen viritystä, koska se renderöidään pakotustaulukosta, ja käsittele "bucket"-nimiä sanastona, jonka mukaan virheenkäsittelysi tulisi haarautua: avain, organisaatio, IP ja alusta epäonnistuvat kukin eri tavalla, ja vain osa niistä kertoo, milloin palata.

Jos työkuormasi ei mahdu näihin numeroihin, rehellinen johtopäätös on, että tätä käyttöönottoa ei ole vielä mitoitettu sille. Taulukko on julkinen, se kertoo mitkä rivit ovat pakotettuja, ja etukäteen luettavissa oleva raja on arvokkaampi kuin tuotannossa löydetty.