inference.eu

Anleitungen · Rate limits and errors

Rate Limits und Fehler: Statuscodes, Header und Wiederholungen

Jede produktive Integration trifft früher oder später auf Fehler: eine fehlerhafte Anfrage, einen abgelaufenen Schlüssel, einen Lastschub über Ihrem Limit oder eine kurze Unterbrechung. Dieser Leitfaden erklärt, wie die inference.eu API jeden Fall meldet, welche Fehler eine Wiederholung lohnen, wie Sie Rate-Limit-Header lesen und wie Sie eine Retry-Schleife bauen, die mit allem zurechtkommt.

Vertrieb kontaktierenBeispielanfrage
  1. 01API-Format: OpenAI und Anthropic
  2. 02Rechenzentren in der EU
  3. 03Durch einen AV-Vertrag abgedeckt
retry.py
import os, random, time
import openai
from openai import OpenAI

# The SDK already retries some errors; max_retries=0 here so the loop below is explicit.
client = OpenAI(base_url="https://api.inference.eu/v1", api_key=os.environ["INFERENCE_EU_API_KEY"], max_retries=0)

def complete(messages, attempts=6):
    for attempt in range(attempts):
        try:
            return client.chat.completions.create(model="gpt-oss-120b", messages=messages)
        except (openai.RateLimitError, openai.InternalServerError, openai.APIConnectionError) as err:
            if attempt == attempts - 1:
                raise
            retry_after = getattr(getattr(err, "response", None), "headers", {}).get("retry-after")
            delay = float(retry_after) if retry_after else min(2 ** attempt, 30) + random.random()
            time.sleep(delay)
        except openai.BadRequestError as err:
            # 400s will fail again unchanged: log and fix the request instead of retrying
            print("Invalid request:", err.message)
            raise

Statuscodes und Fehlerobjekt

Fehler nutzen übliche HTTP-Statuscodes und bei Endpunkten im OpenAI-Format einen JSON-Körper mit einem Objekt error, das message, type, param und code enthält. Die Meldung richtet sich an Entwickler und nennt das betroffene Feld oder den Wert. Endpunkte im Anthropic-Format liefern stattdessen {"type": "error", "error": {"type", "message"}}.

Diese Codes begegnen Ihnen: 400 bei ungültiger Anfrage, etwa einem falschen Feld oder einem Prompt über dem Kontextfenster; 401 bei fehlendem oder ungültigem Schlüssel; 403, wenn der Schlüssel ein Modell oder eine Funktion nicht nutzen darf; 404 bei unbekanntem Modell oder Objekt; 413 bei zu großem Anfragekörper; 422 bei gültiger, aber nicht verarbeitbarer Anfrage; 429 bei Rate Limits; 500, 502, 503 oder 529 bei vorübergehenden Problemen auf Serverseite.

So funktionieren Rate Limits

Limits gelten pro Organisation oder Projekt und pro Modell und umfassen meist Anfragen und Tokens pro Minute. Die Werte hängen von Ihrem Tarif ab und werden mit Ihnen vereinbart, statt festen öffentlichen Stufen zu folgen. Erwarten Sie einen Launch oder eine große Migration, sagen Sie uns vorher Bescheid, dann erhöhen wir sie.

Antworten enthalten Header, die Ihren Stand zeigen: x-ratelimit-limit-requests, x-ratelimit-remaining-requests und x-ratelimit-reset-requests, dazu passende -tokens-Header. Überschreiten Sie ein Limit, liefert die API 429 mit einem Header Retry-After, der die Wartezeit in Sekunden angibt. Lesen Sie diese Header, um vor dem Limit zu drosseln, nicht erst danach.

Ein belastbares Retry-Muster

Wiederholen Sie 429, 5xx und Verbindungsfehler, aber nicht 400, 401, 403 oder 404, denn dieselbe Anfrage scheitert erneut. Warten Sie vor jedem Versuch: Nutzen Sie Retry-After, falls vorhanden, sonst exponentiellen Backoff mit zufälligem Jitter wie im Beispiel, damit nicht viele Clients gleichzeitig wiederholen. Begrenzen Sie Versuche und Gesamtwartezeit.

Die OpenAI- und Anthropic-SDKs wiederholen manche Fehler bereits standardmäßig. Verlassen Sie sich entweder darauf und setzen Sie max_retries, oder schalten Sie es ab und nutzen Ihre eigene Schleife, aber nicht beides. Für große Mengen eignet sich eine Warteschlange mit fester Parallelität oder gleich ein Batch.

Sonderfälle, die Sie abfangen sollten

Ein 400 wegen der Kontextlänge kommt bei langen Dokumenten häufig vor. Zählen Sie Tokens vorher, kürzen Sie den Verlauf oder teilen Sie die Eingabe. Auch eine erfolgreiche Antwort kann unvollständig sein: Prüfen Sie finish_reason oder status, bevor Sie das Ergebnis nutzen. Beim Streaming kann ein Fehler mitten im Stream als Event kommen; behandeln Sie Teilausgaben als unfertig.

Setzen Sie Client-Timeouts lang genug für Reasoning-Modelle und große Ausgaben und machen Sie wiederholte Operationen idempotent, etwa durch Deduplizierung über eine eigene Anfrage-ID. Protokollieren Sie bei jedem Fehler die Request-ID aus den Antwort-Headern, damit wir die Anfrage finden, wenn Sie sich bei uns melden.

Rate limits and errors: häufige Fragen

Die Fragen, die uns Einkauf, Entwicklung und Rechtsabteilungen am häufigsten stellen. Etwas fehlt? Fragen Sie uns direkt.

Frage stellen

Verwandte Seiten

API-Überblick

Verlagern Sie Ihre KI-Workloads auf europäische Infrastruktur

Sagen Sie uns, welche Modelle Sie nutzen und wie viel Verkehr Sie ungefähr haben. Wir antworten innerhalb eines Werktags mit Preisen und nächsten Schritten.

  • Antwort innerhalb eines Werktags
  • Preise für Ihr Volumen
  • AV-Vertrag unterschriftsreif