Fehler 429: was tun, wenn gemini-flash-latest fehlschlägt

Ein 429 bedeutet, dass eine Ratenbegrenzung gegriffen hat: Die Anzahl der Anfragen oder Tokens pro Zeitfenster hat das Kontingent Ihres Tarifs überschritten.

429 Too Many Requests ist eine Drosselungsantwort, kein Fehler. Die Anfrage selbst ist gültig, überschreitet aber die für Ihren Tarif erlaubte Anfragerate oder Parallelität. Wiederholen Sie mit Wartezeit im vom Antwortheader vorgegebenen Fenster; der Request-Body muss nicht geändert werden.

gemini-flash-latest wird von Google bereitgestellt. Alles auf dieser Seite — Ursachen, Lösungen und gemessene Daten — basiert auf dem tatsächlichen Laufzeitverhalten dieses Modells auf der Gatewayschicht.

An diesem Gateway ist die häufigste Ursache: Zu viele parallele Anfragen. Empfohlene erste Maßnahme: Parallelität begrenzen und mit exponentiellem Backoff wiederholen.

Häufige Ursachen

  • Zu viele parallele Anfragen
  • Kontingent des aktuellen Tarifs erschöpft
  • Wiederholung ohne Pause

So beheben Sie es

  • Parallelität begrenzen und mit exponentiellem Backoff wiederholen
  • Zu einem Tarif mit größerem Kontingent wechseln
  • Wiederholte Anfragen zwischenspeichern

Wiederholung mit exponentiellem Backoff

Der folgende Code wiederholt den Aufruf, wenn gemini-flash-latest 429 liefert: bis zu 5 Versuche, mit wachsender Wartezeit und zufälligem Jitter, damit parallele Anfragen nicht gleichzeitig wiederholen. Base-URL und API-Key werden aus Umgebungsvariablen gelesen — nicht hart codieren.

import os, time, random
import requests

BASE  = os.getenv("OPENAI_BASE_URL")   # e.g. https://<your-gateway>/v1
KEY   = os.getenv("OPENAI_API_KEY")
MODEL = 'gemini-flash-latest'


def chat(messages, retries=5):
    """Retry with exponential backoff + jitter."""
    for i in range(retries):
        try:
            r = requests.post(
                BASE + "/chat/completions",
                headers={"Authorization": "Bearer " + KEY},
                json={"model": MODEL, "messages": messages, "stream": True},
                timeout=60,
            )
            if r.status_code == 429 or r.status_code >= 500:
                time.sleep(min(2 ** i + random.uniform(0, 1), 30))
                continue
            r.raise_for_status()
            return r.json()
        except requests.exceptions.Timeout:
            time.sleep(min(2 ** i + random.uniform(0, 1), 30))
    raise RuntimeError("gave up after " + str(retries) + " retries")


print(chat([{"role": "user", "content": "hello"}]))

Wichtige Daten zu diesem Modell

API-Endpunkthttps://api.airai.cc/v1
OpenAI-kompatibelOpenAI-compatible
AnbieterGoogle
Kontext1M
FunktionenReasoning, Tools, Files, Vision, Audio
API-Formateopenai, openai-response, openai-response-compact, anthropic, gemini, openai-alpha-search
Abrechnungsformelp * 0.75 + cr * 0.075 + ai * 0.75 + c * 3.75

Häufige Fragen

Macht ein langer Kontext 429 wahrscheinlicher?

Die Request-Parameter müssen geändert werden; Retry allein hilft nicht. Das ist ein clientseitiges Konfigurationsproblem; serverseitig ändert sich nichts. Die Fähigkeits-Tags sind Reasoning, Tools, Files, Vision, Audio, daraus ergeben sich die Parameter-Obergrenzen. Kürzen oder verdichten Sie lange Eingaben — das senkt 429 deutlich.

Tritt 429 eher bei direkten Frontend-Aufrufen oder über einen Backend-Proxy auf?

Halten Sie zusätzlich ein Ausweichmodell bereit. Ein Fallback in der Architektur ist verlässlicher als jede Fehlermeldung einzeln zu flicken. Dieses Modell von Google hat mehrere Upstream-Knoten, zwischen denen das Gateway wechseln kann. Halten Sie ein leichteres Ersatzmodell bereit, damit der Hauptfluss nicht abbricht. Legen Sie den Modellnamen in die Konfiguration, dann braucht ein Upstream-Wechsel keine Codeänderung.

Wie sollte ich 429 in Produktion überwachen?

Behalten Sie die Request-ID und den rohen Antworttext, sonst lässt sich nichts zuordnen. Das Modell wird von Google bereitgestellt, der Upstream-Status richtet sich nach den Ankündigungen des Anbieters. Protokollieren Sie bei jedem Fehler die Request-ID — sie hilft mehr als der Statuscode. Reproduzieren Sie es zuerst in der Testumgebung mit demselben Request-Body.

Erhöht ein gemeinsamer Key über mehrere Services die 429-Wahrscheinlichkeit?

Sowohl ein höheres Tariflimit als auch eine niedrigere Aufruffrequenz helfen. Der Eingabepreis liegt bei etwa $0.75 pro Million Tokens. Bei der Abrechnung p * 0.75 + cr * 0.075 + ai * 0.75 + c * 3.75 werden fehlgeschlagene Anfragen nicht angerechnet. Wenn Sie Kosten nach p * 0.75 + cr * 0.075 + ai * 0.75 + c * 3.75 schätzen, rechnen Sie das Retry-Budget mit ein.

Weitere Fehler bei diesem Modell

Andere Modelle mit demselben Fehler

Zurück zur Modellseite

Daten aktualisiert: 2026-10-10 08:15

Technischer SupportLive-Support
Nach oben