Frekvensgränsfel (”Too Many Requests”, ”Rate limit reached”) orsakas av att organisationens frekvensgräns nås, vilket är det högsta antalet begäranden och token som kan skickas per minut. Om gränsen nås kan organisationen inte skicka begäranden förrän frekvensgränsen har återställts. Felmeddelandet ser ut så här:
Frekvensgräns nådd för gpt-3.5-turbo i organisationen org-exampleorgid123 för Token per minut.
Gräns: 10000.000000 / min. Aktuellt: 10020.000000 / min. Vi rekommenderar att dessa fel hanteras med exponentiell backoff. Exponentiell backoff innebär att en kort paus görs när ett frekvensgränsfel inträffar, och att den misslyckade begäran sedan görs om. Om begäran fortfarande misslyckas förlängs pausen och processen upprepas. Detta fortsätter tills begäran lyckas eller tills ett maximalt antal försök har uppnåtts.
Eftersom misslyckade begäranden räknas mot din gräns per minut fungerar det inte att skicka om en begäran kontinuerligt. Frekvensgränser kan tillämpas över kortare perioder – till exempel 1 begäran per sekund för en gräns på 60 RPM – vilket innebär att korta begäransetoppar med hög volym också kan leda till frekvensgränsfel. Exponentiell backoff fungerar bra genom att sprida ut begäranden för att minimera frekvensen av dessa fel.
I Python kan en lösning med exponentiell backoff se ut så här:
from openai import OpenAI, RateLimitError
import backoff
client = OpenAI()
@backoff.on_exception(backoff.expo, RateLimitError)
def completions_with_backoff(**kwargs):
response = client.completions.create(**kwargs)
return response(Observera: backoff-biblioteket är ett tredjepartsverktyg. Vi uppmuntrar alla våra kunder att göra sin egen granskning när det gäller att validera extern kod för sina projekt.)
Om felet fortfarande uppstår efter att exponentiell backoff har implementerats kan du behöva höja din användningsnivå. Du kan se dina nuvarande frekvensgränser och hur du höjer din förtroendenivå för att öka dina frekvensgränser i gränsavsnittet i dina kontoinställningar.