Ratenlimits

Ratenlimits legen fest, wie oft eine Person oder ein Client innerhalb eines bestimmten Zeitraums über unsere API auf unsere Dienste zugreifen kann.

Warum gibt es Ratenlimits?

Ratenlimits sind bei APIs üblich und werden aus verschiedenen Gründen eingesetzt:

• Sie helfen, die API vor Missbrauch oder unsachgemäßer Nutzung zu schützen. Beispielsweise könnte jemand die API gezielt mit Anfragen überfluten, um sie zu überlasten oder den Dienst zu stören. Mit Ratenlimits kann OpenAI solche Aktivitäten verhindern.
• Ratenlimits tragen dazu bei, dass alle fairen Zugang zur API haben. Wenn eine Person oder Organisation übermäßig viele Anfragen stellt, könnte das die API für alle anderen verlangsamen. Indem OpenAI die Anzahl der Anfragen pro Person begrenzt, stellt OpenAI sicher, dass möglichst viele Menschen die API ohne Verzögerungen nutzen können.
• Ratenlimits können OpenAI helfen, die Gesamtlast der Infrastruktur zu steuern. Wenn die Anzahl der API-Anfragen stark ansteigt, kann das die Server belasten und zu Leistungsproblemen führen. Mit Ratenlimits kann OpenAI dazu beitragen, dass der Dienst für alle reibungslos und zuverlässig funktioniert.

Wie funktionieren diese Ratenlimits?

Ratenlimits verwenden Kennzahlen wie RPM (Anfragen pro Minute), RPD (Anfragen pro Tag), TPM (Token pro Minute), TPD (Token pro Tag), IPM (Bilder pro Minute) und bei einigen Modellen für Audiostreaming auch Audiominuten pro Minute. Entscheidend ist, welches dieser Limits zuerst erreicht wird. Wenn du beispielsweise 20 Anfragen mit nur 100 Token an den ChatCompletions-Endpunkt sendest, ist dein Limit bei einem RPM-Limit von 20 bereits ausgeschöpft, auch wenn du mit diesen 20 Anfragen noch keine 150.000 Token gesendet hast und dein TPM-Limit bei 150.000 liegt.

Die Warteschlangenlimits der Batch API werden anhand der Gesamtzahl der Eingabetoken berechnet, die für ein bestimmtes Modell in der Warteschlange stehen. Token aus noch nicht abgeschlossenen Aufträgen zur Stapelverarbeitung werden auf dein Warteschlangenlimit angerechnet. Sobald ein solcher Auftrag abgeschlossen ist, werden seine Token nicht mehr auf das Limit dieses Modells angerechnet.

Weitere wichtige Hinweise:

• Ratenlimits werden auf Organisationsebene und auf Projektebene festgelegt, nicht für einzelne Personen.
• Die Ratenlimits hängen vom verwendeten Modell ab.
• Bei Modellen mit großem Kontextfenster wie GPT-5.5 gibt es ein separates Ratenlimit für Anfragen mit langem Kontext. Du kannst diese Ratenlimits in der Entwicklerkonsole einsehen.
• OpenAI legt für jede Organisation ein genehmigtes monatliches Nutzungslimit fest. Dieses ist unabhängig von den Ausgabenlimits, die du für eine Organisation oder ein Projekt konfigurieren kannst.
• Einige Modellfamilien haben gemeinsame Ratenlimits. Alle Modelle, die auf der Seite mit den Limits deiner Organisation unter einem „gemeinsamen Limit“ aufgeführt sind, teilen sich ein Ratenlimit. Wenn das angegebene gemeinsame TPM-Limit beispielsweise 3,5 Millionen beträgt, werden alle Aufrufe an Modelle in dieser Liste auf diese 3,5 Millionen angerechnet.
• Auch für das Einlesen von Daten in Vektorspeicher gelten Ratenlimits pro Vektorspeicher-ID. /vector_stores/{vector_store_id}/files und /vector_stores/{vector_store_id}/file_batches teilen sich für jeden Vektorspeicher ein Limit von 300 Anfragen pro Minute. Verwende für größere Datenmengen vorzugsweise /vector_stores/{vector_store_id}/file_batches.

Nutzungsstufen

Die Raten- und Nutzungslimits deiner Organisation findest du in deinen Kontoeinstellungen im Abschnitt Limits. Wenn deine Ausgaben für unsere API steigen, stufen wir dich automatisch in die nächste Nutzungsstufe hoch. Dadurch erhöhen sich in der Regel die Ratenlimits für die meisten Modelle.

Eine Übersicht über die Ratenlimits pro Modell findest du auf der Modellseite.

Ratenlimits in Headern

Neben deinem Ratenlimit auf der Kontoseite findest du auch in den Headern der HTTP-Antwort wichtige Informationen zu deinen Ratenlimits, etwa die verbleibenden Anfragen und Token sowie weitere Metadaten.

Antworten können die folgenden Header-Felder enthalten:

Header für projektbezogene Tokenlimits können vorhanden sein, wenn ein solches Limit gilt. Retry-After kann sowohl in 429-Antworten aufgrund eines vorübergehenden Ratenlimits als auch in 503-Antworten aufgrund einer vorübergehenden Modellüberlastung enthalten sein. Das bedeutet nicht, dass sich Kontingent- oder Abrechnungsfehler sowie andere Fehler, bei denen du selbst tätig werden musst, durch erneute Versuche beheben lassen.

Ratenlimits für Fine-Tuning

Die Ratenlimits für das Fine-Tuning deiner Organisation findest du ebenfalls im Dashboard. Du kannst sie auch über die API abrufen:

curl https://api.openai.com/v1/fine_tuning/model_limits \
  -H "Authorization: Bearer $OPENAI_API_KEY"

Fehler abfangen

Mit schnell steigendem Anfragevolumen und Modellüberlastung umgehen

Die API kann slow_down zurückgeben, wenn deine Anfragerate zu schnell steigt, oder server_is_overloaded, wenn das angeforderte Modell vorübergehend überlastet ist. Prüfe den HTTP-Status und error.code, um diese Fälle zu unterscheiden:

Wenn Retry-After fehlt, verlängere die Wartezeit zwischen den Versuchen und füge eine kurze zufällige Verzögerung hinzu.

Ein slow_down-Fehler kann auch dann auftreten, wenn dein Anfragevolumen innerhalb der Limits für Anfragen pro Minute und Token pro Minute liegt. Er zeigt an, wie schnell das Anfragevolumen gestiegen ist, nicht, ob du diese Limits ausgeschöpft hast.

Als Faustregel gilt: Sobald dein Anfragevolumen 1 Million Eingabetoken pro Minute (TPM) erreicht, solltest du es alle 15 Minuten um höchstens 50 % erhöhen. Ab wann genau die Begrenzung für den Anstieg greift, kann je nach Modell und aktueller Last variieren.

Unternehmen, deren nutzungsbasiert abgerechnetes Anfragevolumen regelmäßig an die Grenzen für den zulässigen Anstieg stößt, können Scale Tier für besser planbare Kapazitäten bei unterstützten Modellen in Betracht ziehen. Für GPT-5.6 und neuere Modelle siehe Reserved Tier. Die gewählte Kapazitätsstufe ändert nichts daran, wie du mit einer slow_down-Antwort umgehen solltest: Halte dich an Retry-After, sofern vorhanden, reduziere das Anfragevolumen und erhöhe es anschließend schrittweise.

Bestehende Fehlerbehandlung aktualisieren

Wenn deine Anwendung die bisherigen Antworten bei Drosselung und Überlastung verarbeitet hat, prüfe sowohl den HTTP-Status als auch error.code:

• Endpunkte, die bisher in beiden Fällen 503 mit dem Code slow_down zurückgegeben haben, geben bei einem schnellen Anstieg des Anfragevolumens jetzt 429 mit slow_down zurück. Bei Modellüberlastung bleibt es bei 503, allerdings mit dem Code server_is_overloaded.
• Videoanfragen, die vor dem Erstellen eines Jobs abgelehnt wurden, lieferten in diesen Fällen bisher 429 mit dem Typ invalid_request_error und dem Code rate_limit_exceeded. Bei einem schnellen Anstieg des Anfragevolumens wird jetzt 429 mit rate_limit_error und slow_down zurückgegeben, bei Modellüberlastung 503 mit service_unavailable_error und server_is_overloaded. Fehler, die im Status eines Videojobs gemeldet werden, sind gesondert zu betrachten.

Berücksichtige in deiner SDK-Fehlerbehandlung sowohl 429 als auch 503. Beispielsweise verwenden Python, TypeScript und Ruby RateLimitError für 429 und InternalServerError für 503; Java verwendet RateLimitException und InternalServerException. Unterstütze die bisherigen Antwortcodes weiterhin, solange deine Anwendung sie noch erhalten kann. Auch andere Fehler können dieselben HTTP-Statuscodes verwenden. Prüfe deshalb den Inhalt der Fehlerantwort, bevor du eine Maßnahme zur Fehlerbehebung auswählst.

Bei Streaming-Anfragen gelten diese HTTP-Fehlerantworten, bevor der Stream beginnt. Ein Fehler nach Beginn des Streamings kann als Stream-Ereignis eintreffen. Wiederhole eine Anfrage nicht automatisch, nachdem du bereits Ausgabedaten verarbeitet hast.

Was kann ich tun, um diese Fehler abzufangen?

Im OpenAI Cookbook findest du ein Python-Notebook, das erklärt, wie du Ratenlimitfehler vermeidest, sowie ein Python-Beispielskript, mit dem du bei der Stapelverarbeitung von API-Anfragen unter den Ratenlimits bleibst.

Sei außerdem vorsichtig, wenn du programmatischen Zugriff, Funktionen zur Massenverarbeitung oder automatisiertes Posten in sozialen Medien anbietest. Erwäge, diese Funktionen nur für vertrauenswürdige Kundschaft freizuschalten.

Lege zum Schutz vor automatisiertem Missbrauch und Missbrauch in großem Umfang ein Nutzungslimit pro Person für einen festgelegten Zeitraum fest (täglich, wöchentlich oder monatlich). Erwäge eine feste Obergrenze oder eine manuelle Überprüfung bei Personen, die das Limit überschreiten.

Erneute Versuche mit exponentiellem Backoff

Wenn eine Anfrage ein vorübergehendes Ratenlimit überschreitet, gibt die API einen 429-Fehler zurück. Die Antwort kann einen Retry-After-Header enthalten, der angibt, wie viele Sekunden du vor einem erneuten Versuch warten sollst. Betrachte diesen Wert als Minimum: Warte mindestens so lange und füge eine kurze zufällige Verzögerung hinzu, damit mehrere Clients ihre Anfragen nicht gleichzeitig wiederholen.

Jedes offizielle OpenAI SDK wiederholt Anfragen bei dafür geeigneten 429- und 503-Antworten automatisch gemäß seinen Einstellungen für erneute Versuche. Wie Retry-After behandelt wird, insbesondere bei langen Wartezeiten, hängt von der SDK-Version und der Konfiguration ab. Prüfe das Wiederholungsverhalten deiner installierten Version, statt davon auszugehen, dass jede vom Server vorgegebene Wartezeit unterstützt wird.

Wenn eine gültige, vom Server vorgegebene Wartezeit die unterstützte oder konfigurierte maximale Wartezeit für erneute Versuche überschreitet, beende die Wiederholungen und verschiebe die Anfrage auf später, statt sie vorzeitig zu wiederholen. Ein SDK kann den ursprünglichen HTTP-Fehler zurückgeben, wenn es eine Wartezeit oberhalb seiner Grenze ablehnt. Behandle Abbrüche und Zeitüberschreitungen weiterhin gesondert: Eine abgebrochene Anfrage oder eine abgelaufene Frist kann die Wiederholungen beenden, ohne dass dieser HTTP-Fehler zurückgegeben wird. Ein Zeitlimit für jeden einzelnen Versuch begrenzt nicht zwangsläufig die Dauer des gesamten Vorgangs.

Wenn du deinen eigenen HTTP-Client verwendest, halte dich an Retry-After, sofern der Header vorhanden ist und einen gültigen Wert enthält. Wenn er fehlt oder ungültig ist, verwende exponentiellen Backoff mit zufälliger Streuung (Jitter). Begrenze sowohl die Anzahl der Versuche als auch die Gesamtdauer der Wiederholungen. Wenn du Wiederholungen in deiner Anwendung steuerst, deaktiviere die SDK-Wiederholungen oder berücksichtige sie in diesen Grenzen, damit verschachtelte Wiederholungsschleifen die Anzahl der Anfragen nicht vervielfachen. Wiederhole Anfragen nicht bei Kontingent- oder Abrechnungsfehlern sowie anderen Fehlern, bei denen du selbst tätig werden musst.

Exponentieller Backoff bedeutet, nach einer fehlgeschlagenen Anfrage kurz zu warten und die Wartezeit nach jedem weiteren fehlgeschlagenen Versuch zu verlängern. Das wird fortgesetzt, bis die Anfrage erfolgreich ist oder eine konfigurierte Grenze für erneute Versuche erreicht wird.

Dieser Ansatz hat viele Vorteile:

• Automatische Wiederholungen ermöglichen es, Ratenlimitfehler ohne Abstürze oder fehlende Daten zu überwinden
• Mit exponentiellem Backoff können die ersten erneuten Versuche schnell erfolgen. Schlagen diese fehl, profitierst du bei weiteren Versuchen von längeren Wartezeiten
• Eine zufällige Streuung der Wartezeit hilft zu verhindern, dass alle erneuten Versuche gleichzeitig eintreffen.

Beachte, dass auch fehlgeschlagene Anfragen auf dein Limit pro Minute angerechnet werden. Eine Anfrage ständig erneut zu senden, hilft daher nicht.

Die folgenden Python-Beispiele zeigen Backoff als Ausweichlösung. Sie werten Retry-After nicht aus: Ergänze vor ihrem Einsatz die Verarbeitung gültiger Serverhinweise, damit die Wrapper Anfragen nicht vor Ablauf der vorgegebenen Wartezeit wiederholen. Deaktiviere die SDK-Wiederholungen oder berücksichtige sie in den Wiederholungsgrenzen deiner Anwendung.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19from openai import OpenAI
from tenacity import (
    retry,
    stop_after_attempt,
    wait_random_exponential,
)  # for exponential backoff

client = OpenAI()


@retry(wait=wait_random_exponential(min=1, max=60), stop=stop_after_attempt(6))
def completion_with_backoff(**kwargs):
    return client.completions.create(**kwargs)


completion_with_backoff(
    model="gpt-3.5-turbo-instruct",
    prompt="Once upon a time,",
)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16import backoff
import openai
from openai import OpenAI

client = OpenAI()


@backoff.on_exception(backoff.expo, openai.RateLimitError)
def completions_with_backoff(**kwargs):
    return client.completions.create(**kwargs)


completions_with_backoff(
    model="gpt-3.5-turbo-instruct",
    prompt="Once upon a time,",
)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59# imports
import random
import time

import openai
from openai import OpenAI

client = OpenAI()

# define a retry decorator


def retry_with_exponential_backoff(
    func,
    initial_delay: float = 1,
    exponential_base: float = 2,
    jitter: bool = True,
    max_retries: int = 10,
    errors: tuple = (openai.RateLimitError,),
):
    """Retry a function with exponential backoff."""

    def wrapper(*args, **kwargs):
        # Initialize variables
        num_retries = 0
        delay = initial_delay

        # Loop until a successful response or max_retries is hit or an exception is raised
        while True:
            try:
                return func(*args, **kwargs)

            # Retry on specific errors
            except errors:
                # Increment retries
                num_retries += 1

                # Check if max retries has been reached
                if num_retries > max_retries:
                    raise Exception(
                        f"Maximum number of retries ({max_retries}) exceeded."
                    )

                # Increment the delay
                delay *= exponential_base * (1 + jitter * random.random())

                # Sleep for the delay
                time.sleep(delay)

            # Raise exceptions for any errors not specified
            except Exception:
                raise

    return wrapper


@retry_with_exponential_backoff
def completions_with_backoff(**kwargs):
    return client.completions.create(**kwargs)

Reduziere max_tokens auf die Länge deiner Vervollständigungen

Dein Ratenlimit wird anhand des höheren der beiden Werte berechnet: max_tokens oder die anhand der Zeichenanzahl deiner Anfrage geschätzte Tokenanzahl. Versuche, den Wert für max_tokens möglichst nah an der erwarteten Antwortlänge festzulegen.

Anfragen bündeln

Wenn dein Anwendungsfall keine sofortigen Antworten erfordert, kannst du mit der Batch API große Mengen an Anfragen einfacher übermitteln und ausführen, ohne deine Ratenlimits für synchrone Anfragen zu belasten.

Für Anwendungsfälle, die tatsächlich synchrone Antworten erfordern, gelten in der OpenAI API separate Limits für Anfragen pro Minute und Token pro Minute.

Wenn du das Limit für Anfragen pro Minute erreichst, aber noch Kapazität bei den Token pro Minute hast, kannst du deinen Durchsatz erhöhen, indem du mehrere Aufgaben in jeder Anfrage bündelst. So kannst du mehr Token pro Minute verarbeiten, insbesondere mit unseren kleineren Modellen.

Das gebündelte Senden von Prompts funktioniert genau wie ein normaler API-Aufruf. Du übergibst dem Parameter prompt lediglich eine Liste von Zeichenfolgen statt einer einzelnen Zeichenfolge. Mehr dazu erfährst du im Leitfaden zur Batch API.