Sebességkorlátok

A telepítés által alkalmazott korlátok, abból a táblából előállítva, amelyet a korlátozó olvas, azzal együtt, hogy az egyes vödrök mit számolnak.

Vödör Korlát Ablak Számolt
key_chat
egy API-kulccsal tett inferenciahívások
600 1 min API-kulcsonként
org_chat
inferenciahívások egy egész szervezet szintjén
1800 1 min szervezetenként
platform
platform API hívások: szervezet, kulcsok, használat, nyomkövetések, házirendek
300 1 min API-kulcsonként
public_chat
névtelen játszótér-hívások
20 1 h IP-címenként
public_page
nyilvános oldal kérései
300 1 h IP-címenként
public_card_request
a nyilvános űrlapról küldött modellkártya-kérések
5 1 h IP-címenként
auth
bejelentkezési, regisztrációs, jelszó-helyreállítási és jelszó-visszaállítási kísérletek
20 15 min IP-címenként

Egyidejűség

Egy API-kulcson egyszerre legfeljebb 8 kérés lehet folyamatban. Az e feletti kérés inkább várakozik, mint hogy meghiúsuljon, amíg a sor meg nem telik.

Hogyan néz ki egy elutasítás

429 a rate_limit_exceeded kóddal és a rate_limit_error típussal. Ma nincsenek x-ratelimit-* vagy retry-after fejlécek: az üzenet megnevezi az ablak visszaállási idejét, és ez az egyetlen jelzés. A 429-et kezelje újrapróbálhatónak, növekvő várakozással; a dokumentációban szereplő minden más hibát olyan kérésnek tekintsen, amelynek meg kell változnia ahhoz, hogy sikerülhessen.

Hol él a számláló

Az ablakokat az API-folyamat számolja, és néhány másodpercenként visszaírja az adatbázisba, így az újraindítás folytatja az ablakot ahelyett, hogy új keretet osztana ki. Az ebből következő plafont nem felfedezni kell, hanem ki van mondva: a számláló API-csomópontonkénti, így két csomópont megduplázza az összes tényleges korlátot. A REDIS_URL a megosztott változat számára van fenntartva, és egyelőre semmi sem olvassa — futtasson egy API-csomópontot, vagy fogadja el a csomópontonkénti korlátokat.