Limiti di frequenza
I limiti applicati da questa distribuzione, resi dalla tabella che il limitatore legge, con ciò che ogni bucket conteggia.
| Bucket | Limite | Finestra | Conteggiato |
|---|---|---|---|
| key_chat chiamate di inferenza effettuate con una chiave API |
600 | 1 min | per chiave API |
| org_chat chiamate di inferenza per un'intera organizzazione |
1800 | 1 min | per organizzazione |
| platform chiamate API della piattaforma: organizzazione, chiavi, utilizzo, tracce, policy |
300 | 1 min | per chiave API |
| public_chat chiamate anonime al playground |
20 | 1 h | per indirizzo IP |
| public_page richieste di pagine pubbliche |
300 | 1 h | per indirizzo IP |
| public_card_request richieste di model card inviate dal modulo pubblico |
5 | 1 h | per indirizzo IP |
| auth tentativi di accesso, registrazione, recupero password e reset |
20 | 15 min | per indirizzo IP |
Concorrenza
Al massimo 8 richieste possono essere in volo su una chiave API alla volta. Una richiesta oltre quel limite attende invece di fallire, finché la coda non è piena.
Come si presenta un rifiuto
429 con codice rate_limit_exceeded e tipo rate_limit_error. Oggi non ci sono header x-ratelimit-* o retry-after: il messaggio indica l'orario di reset della finestra, e quello è l'unico segnale. Tratta un 429 come ritentabile con backoff; tratta ogni altro errore in questa documentazione come una richiesta che deve cambiare prima di poter riuscire.
Dove risiede il contatore
Le finestre sono conteggiate nel processo API e riscritte nel database ogni pochi secondi, quindi un riavvio continua la finestra invece di distribuire un nuovo budget. Il tetto che ne deriva è dichiarato invece che scoperto: il contatore è per nodo API, quindi due nodi raddoppiano ogni limite effettivo. REDIS_URL è riservato alla versione condivisa e nulla lo legge ancora — esegui un solo nodo API, oppure accetta limiti per nodo.