Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
A colpo d'occhio
Obiettivo: Testare il modo in cui l'app gestisce il limite di frequenza OpenAI e gli errori di overload
Tempo: 10 minuti
Plugins:GenericRandomErrorPlugin, RetryAfterPlugin
Prerequisiti:Configurare il proxy di sviluppo
La tua app funziona in fase di sviluppo, poi non funziona in produzione con 429 Too Many Requests. I limiti di frequenza OpenAI dipendono dal livello di utilizzo dell'organizzazione, dal modello e da tutti gli altri utenti che usano la stessa organizzazione, quindi non puoi raggiungerli intenzionalmente in modo affidabile. Dev Proxy restituisce gli stessi errori restituiti dall'API OpenAI, in modo da poter vedere come si comporta l'app prima che lo facciano gli utenti.
Scopri cosa restituisce OpenAI
Non tutti gli errori OpenAI indicano "riprova". L'app deve distinguerle.
| Status | error.code |
Che cosa significa | Operazioni da eseguire nell'app |
|---|---|---|---|
| 429 | rate_limit_exceeded |
È stato raggiunto il limite di richieste al minuto (RPM) o token al minuto (TPM). | Attendere il tempo indicato nell'intestazione Retry-After, quindi riprovare. |
| 429 | slow_down |
Il tuo tasso di richieste è aumentato troppo rapidamente, anche se rientri nei limiti. | Attendere Retry-After, ridurre la frequenza delle richieste e aumentarla gradualmente. |
| 429 | credit_balance_exhausted |
L'organizzazione non ha più crediti prepagati. | Non riprovare. Riprovare non ripristinerà l'accesso. Informare l'utente o avvisare un amministratore. |
| 503 | server_is_overloaded |
Il modello non ha una capacità sufficiente al momento. | Attendere Retry-After se presente, quindi riprovare con ritardi crescenti. |
Per l'elenco completo, vedere Codici di errore nella documentazione di OpenAI.
Important
Tutti e 3 gli errori nelle 429 righe usano lo stesso codice di stato. Se l'app ritenta ogni 429, continua a ripetere gli errori di fatturazione che non si risolvono mai. Controlla error.code per decidere cosa fare.
Scopri cosa fa per te l'SDK OpenAI
Gli SDK OpenAI ufficiali per Python e JavaScript riprovano le risposte 408, 409, 429 e 5xx e gli errori di connessione, 2 volte per impostazione predefinita con backoff esponenziale. È possibile cambiarlo con l'opzione max_retries in Python e maxRetries in JavaScript.
I tentativi dell’SDK coprono brevi raffiche. L'app deve comunque decidere cosa accade quando si esauriscono i tentativi e come gestire gli errori che i tentativi non risolvono. In Python, un 429 genera RateLimitError e un 503 genera InternalServerError, quindi gestiscili entrambi.
Tip
Per visualizzare esattamente ciò che il codice di gestione degli errori riceve, impostare max_retries=0 (Python) o maxRetries: 0 (JavaScript) durante il test. Riattiva successivamente i tentativi dell'SDK.
Simula i limiti di frequenza di OpenAI
Il proxy di sviluppo ha una preimpostazione con gli errori OpenAI nella tabella. Scaricalo:
devproxy config get openai-throttling
Avvia Dev Proxy con il predefinito:
devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json"
Il set di impostazioni non riesce a elaborare il 90% delle richieste a https://api.openai.com/* con un errore casuale dalla tabella. Per le risposte di limitazione della frequenza, imposta l'intestazione Retry-After e usa RetryAfterPlugin per verificare che l'app attenda tale tempo prima di chiamare nuovamente l'API.
Assicurarsi che l'app invii le richieste tramite Dev Proxy e consideri attendibile il certificato del proxy di sviluppo. Per Node.js, vedere Usare Dev Proxy con applicazioni Node.js. Per altri runtime, vedere Risolvere i problemi relativi al proxy di sviluppo.
Eseguire l'app e verificare che:
- Dopo un errore
rate_limit_exceededoslow_down, l'app attende il tempoRetry-After. Se chiama l'API troppo presto, Dev Proxy lo segnala e limita la richiesta. - Dopo un
credit_balance_exhaustederrore, l'app smette di chiamare l'API e visualizza un messaggio chiaro. - Dopo un errore
server_is_overloaded, l'app ritenta con un ritardo e, quando i tentativi si esauriscono, esegue il fallback o visualizza un messaggio chiaro anziché uno stack trace. - L'app non fa perdere il lavoro svolto. Ad esempio, una conversazione di chat lunga o un processo batch continuano dopo l'errore.
Per modificare la frequenza con cui le richieste hanno esito negativo, usare l'opzione --failure-rate . Ad esempio, per far fallire ogni richiesta:
devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json" --failure-rate 100
Simula i limiti dei token per Azure OpenAI e altri provider
Il set di impostazioni restituisce errori in modo casuale, indipendentemente dal numero di token usati dall'app. Per limitare le richieste in base all'uso effettivo dei token, ad esempio per vedere cosa accade quando una conversazione lunga supera il limite di TPM, usare LanguageModelRateLimitingPlugin. Funziona con qualsiasi API compatibile con OpenAI, inclusi Azure OpenAI e i modelli locali. Per altre informazioni, vedere Testare i limiti dei token del modello linguistico.
Passaggio successivo
Scopri come simulare i limiti basati su token.
Vedere anche
- Metti alla prova la mia app con errori del modello linguistico - Simula risposte impreviste del modello linguistico
- Simula gli errori dalle API OpenAI - Crea un file di errori OpenAI personalizzato
- Verifica che l'applicazione gestisca correttamente il throttling - Throttling su qualsiasi API
- Usa i preset - Lavora con i preset
- RetryAfterPlugin - Verificare il comportamento dei tentativi
Collabora con noi su GitHub
L'origine di questo contenuto è disponibile in GitHub, in cui è anche possibile creare ed esaminare i problemi e le richieste pull. Per ulteriori informazioni, vedere la guida per i collaboratori.
