429, 5xx und Timeouts: Engineering-Praxis für die Ausfallsicherheit von LLM-Gateways

Erst klassifizieren, dann über die Behandlung entscheiden

'Bei jedem Fehler dreimal erneut versuchen' ist die häufigste falsche Vorgehensweise. Die Semantik unterschiedlicher Fehlercodes ist völlig verschieden, und die Behandlungsstrategie muss es ebenfalls sein. Die folgende Tabelle zeigt die Strategie, die unser Gateway tatsächlich verwendet, und kann auch als Referenz für Ihre eigene Implementierung dienen.

• Verbindungsfehler / DNS / TLS: sofort auf den Ausweichkanal wechseln.
• Timeout (Ausgabe noch nicht begonnen): auf den Ausweichkanal wechseln, höchstens 1–2 Mal.
• HTTP 429: nach kurzer Abkühlphase auf einen anderen Kanal wechseln und gleichzeitig die Gewichtung dieses Kanals reduzieren.
• HTTP 5xx: im Fehlerfenster zählen; aufeinanderfolgende Fehler lösen den Circuit Breaker aus.
• 401 / 403: Problem mit Zugangsdaten oder Berechtigungen; diese deaktivieren und alarmieren, nicht erneut versuchen.
• Unzureichendes Guthaben: diesen Kanal pausieren und alarmieren.
• 400 Parameterfehler: nach der Normalisierung direkt an den Kunden zurückgeben, nicht erneut versuchen, nicht abrechnen.
• SSE nach teilweiser Ausgabe abgebrochen: upstream_stream_error zurückgeben, standardmäßig nicht erneut versuchen.

Warum ein SSE-Abbruch nicht einfach wiederholt werden kann

Sobald eine Streaming-Antwort begonnen hat, Tokens an den Client auszugeben, hat der Upstream bereits Ausgaben erzeugt (und abgerechnet). Wenn das Gateway in diesem Moment stillschweigend auf einen anderen Kanal wechselt und neu beginnt, sieht der Nutzer doppelte Inhalte, und Sie zahlen für beide Ausgaben.

Die richtige Vorgehensweise ist, diesen halben Stream als Teilerfolg zu behandeln: einen Fehlercode zurückgeben, der dem Client mitteilt, dass der Upstream unterbrochen wurde, und es der Geschäftslogik überlassen, ob die bereits vorhandenen Inhalte plus ein Wiederholungshinweis angezeigt oder alles neu gestartet wird.

Circuit Breaker: die Schicht, die wichtiger ist als Wiederholungen

Wiederholungen behandeln eine einzelne Anfrage, ein Circuit Breaker beurteilt den Gesamtzustand über einen Zeitraum. Wenn ein Kanal einen Schwellenwert aufeinanderfolgender Fehler erreicht, wird er direkt als 'offen' markiert, eine Zeit lang erhält er keinen Datenverkehr mehr, dann wird mit einer kleinen Menge Probe-Datenverkehr getestet (halb-offen), und nach einigen erfolgreichen Proben wird er vollständig wiederhergestellt (geschlossen).

Ohne Circuit Breaker drücken Wiederholungen einen bereits ausgefallenen Kanal noch tiefer in die Knie und lassen die durchschnittliche Latenz der Kunden stark ansteigen.

Idempotenz und Abrechnung bei Wiederholungen

• Nicht-Streaming-Anfragen: Nach einer Wiederholung wird nur die usage des letztlich erfolgreichen Versuchs abgerechnet.
• Streaming-Anfragen: Der Versuch, der bereits Tokens ausgegeben hat, verursacht real Upstream-Kosten und muss erfasst werden; die Abrechnung darf nicht durch eine Wiederholung ausgeglichen werden.
• Weisen Sie jeder Nutzeranfrage eine request_id zu, die alle Wiederholungen teilen, sodass später vollständig nachvollzogen werden kann, 'warum dieser Kanal gewählt wurde'.
• Rückerstattungen/Korrekturen müssen über das Ledger als Buchungen laufen, das Guthaben darf nicht direkt geändert werden.

Was Admesh bereits umsetzt

Die oben beschriebene Strategie ist im Admesh-Gateway Standardverhalten: Zwischen mehreren Upstream-Kanälen desselben public_model wird automatisch gewechselt, jede Routing-Entscheidung wird persistiert, und Kunden können in den Nutzungsprotokollen request_id, das tatsächlich verwendete Modell und den Kanalzustand einsehen; Fehlercodes werden in einem einheitlichen Format zurückgegeben (error.type / error.code / request_id).

Bemerkenswert ist: Das Routing findet nur innerhalb des Kanalpools desselben public_model statt. Nur weil Sie anthropic/xxx anfragen, werden Sie nicht auf das Modell eines anderen Anbieters umgeleitet – ein modellübergreifender Austausch würde die Ausgabequalität direkt verändern, und diese Entscheidung können wir Ihnen nicht abnehmen.

Fehlercode-Übersicht ansehen →