Ein LLM-API-Gateway-Circuit-Breaker verhindert, dass eine Anwendung wiederholt Traffic an eine Route sendet, die bereits fehlschlägt. Ohne diese Schutzmaßnahme kann ein Timeout Wiederholungsversuche auslösen, Wiederholungsversuche können Fallback-Versuche auslösen, Fallback-Versuche können weitere Provider-Fehler auslösen, und die App kann aus einem einzelnen Upstream-Vorfall eine Provider-Fehlerschleife machen.
Das Ziel ist nicht, Retries oder Modell-Fallback zu ersetzen. Das Ziel ist zu entscheiden, wann eine Route so ungesund ist, dass das Gateway sie für ein kurzes Zeitfenster nicht mehr versuchen sollte, später einen kontrollierten Probeaufruf senden und solange der Breaker offen ist eine sicherere Option wählen sollte: Fallback, Queue, Degradierung oder geschlossenes Scheitern.
Flatkey ist relevant, weil flatkey.ai das Produkt öffentlich rund um einen API-Schlüssel, eine OpenAI-kompatible Basis-URL unter https://router.flatkey.ai/v1, Routing, vereinheitlichte Abrechnung, Nutzungsanalysen, Dashboard-Steuerung, automatisches Umschalten, Load Balancing und Kontingentgrenzen positioniert. Das sind nützliche zentrale Ansatzpunkte für Zuverlässigkeitsarbeit. Sie ersetzen jedoch nicht die Notwendigkeit, eine klare LLM-API-Gateway-Circuit-Breaker-Richtlinie für Ihre eigenen Anwendungsabläufe zu definieren.
Schnelle Antwort: Was ein LLM-API-Gateway-Circuit-Breaker leisten sollte
Ein praktischer LLM-API-Gateway-Circuit-Breaker hat drei Routing-Zustände und einen Fail-Closed-Pfad. Halten Sie die Richtlinie einfach genug, damit On-Call-Ingenieure sie während eines Incidents erklären können.
| Status | Gateway-Verhalten | Was ihn verändert | Zu protokollierende Nachweise |
|---|---|---|---|
| Geschlossen | Traffic kann den Anbieter, das Modell, die Endpunktfamilie, das Konto oder die Routing-Gruppe verwenden. | Fehlerrate, Timeout-Rate, Latenz, Überlastungsantworten oder fehlgeschlagene Health-Probes überschreiten den Schwellenwert. | Route-Policy-ID, ausgewähltes Modell, Anbieter, Endpunktfamilie, Latenz, Statuscode, Wiederholungsanzahl und Kosten. |
| Offen | Das Gateway sendet für ein Cooldown-Fenster keinen normalen Traffic mehr an die fehlerhafte Route. | Cooldown läuft ab, oder ein Operator erlaubt manuell einen Probeaufruf. | Breaker-Grund, Öffnungszeitpunkt, Anzahl blockierter Versuche, Fallback-Route, Queue-Entscheidung oder Fail-Closed-Grund. |
| Halboffen | Das Gateway erlaubt eine begrenzte Anzahl von Probe-Requests, bevor der Traffic wiederhergestellt wird. | Erfolgreiche Probes schließen den Breaker; fehlgeschlagene Probes öffnen ihn erneut. | Probe-Stichprobengröße, Probe-Workflow, Probe-Ergebnis, Latenz, Nutzung und Freigabe des Route-Eigentümers. |
| Fail closed | Das Gateway lehnt es ab, die Anfrage zu routen, weil das Problem kein Problem der Provider-Health ist. | Auth, Policy, Kontingent, Sicherheit, Daten-Grenze, ungültige Anfrage oder Tool-Side-Effect-Risiko. | Stoppgrund, Eigentümer, für den Nutzer sichtbare Meldung und Behebungsweg. |
Warum Wiederholungsversuche Anbieter-Ausfallsschleifen erzeugen
Wiederholungsversuche sind nützlich, wenn eine Anfrage aus einem vorübergehenden Grund fehlschlägt. Sie werden gefährlich, wenn jede Benutzeranfrage mehrere weitere Upstream-Aufrufe auslöst, insbesondere während eines Ausfalls oder einer Überlastungsphase beim Anbieter. Eine Retry-Schleife kann Rate Limits verbrauchen, Kontingente aufbrauchen, die Latenz erhöhen und den ursprünglichen Fehler hinter einem abschließenden Fehler verbergen.
Ein Circuit Breaker verändert die Retry-Frage. Statt zu fragen: „Soll diese eine Anfrage es noch einmal versuchen?“, fragt das Gateway: „Ist diese Route gerade gesund genug, um mehr Traffic zu empfangen?“ Diese Sicht auf Route-Ebene ist für LLM-Workloads wichtig, weil jede Anfrage teuer, langlaufend, streamend, Tool-nutzend und für den Kunden sichtbar sein kann.
Microsofts Cloud-Design-Pattern für Circuit Breaker beschreibt dieselbe Grundidee für entfernte Dienste: Nach wiederholten Fehlern öffnet sich der Schaltkreis, damit die Anwendung nicht weiter versucht, eine Operation auszuführen, die wahrscheinlich fehlschlägt. Für eine KI-Route braucht dasselbe Muster LLM-spezifische Grenzen: Modellverhalten, Endpunktfamilie, Tokenverbrauch, Streaming-Zustand, Tool-Nebenwirkungen, Datenklasse und Freigabe des Fallbacks.
Fehler klassifizieren, bevor sie den Breaker erreichen
Der schnellste Weg, einen schlechten KI-API-Circuit-Breaker zu bauen, besteht darin, jeden Fehler als Gesundheitsproblem des Anbieters zu zählen. Das erzeugt Fehlalarme. Es kann auch Probleme verschleiern, die der Eigentümer der Anwendung beheben muss.
| Fehler oder Ereignis | Entscheidung des Breakers | Grund | Standardergebnis |
|---|---|---|---|
| Anbieter 500, 503, Überlastung, nicht verfügbar, Verbindungsfehler, wiederholter Upstream-Timeout | Zur Route-Gesundheit zählen. | Dies sind plausible Signale für Anbieter-, Routen-, Kapazitäts- oder Netzwerkgesundheit. | Innerhalb eines engen Budgets erneut versuchen, dann den Routen-Breaker öffnen, wenn Schwellenwerte überschritten werden. |
| 429 Anforderungsratenlimit | Sorgfältig klassifizieren. | Ein anbieterweites Überlastungssignal und ein von der Anwendung verursachter Burst erfordern unterschiedliche Behandlung. | Drosseln, zurückfahren oder nur die begrenzte Route öffnen, die tatsächlich gesättigt ist. |
| 429 monatliches Kontingent, verbrauchte Credits oder Ausgabenlimit | Nicht als Anbieter-Gesundheit zählen. | Dies ist eine Budget- oder Konto-Inhaber-Bedingung. | Geschlossen fehlschlagen, den Budgetverantwortlichen alarmieren oder nur dann routen, wenn ein vorab genehmigtes Budget existiert. |
| 401 Auth, falscher Schlüssel, Organisationsmitgliedschaft, IP-Allowlist, nicht unterstützte Region | Nicht als Anbieter-Gesundheit zählen. | Die Anfrage darf die Route nicht verwenden. | Geschlossen fehlschlagen und Anmeldedaten, Konto, IP- oder Regionsrichtlinie korrigieren. |
| Ungültige Anfrage, nicht unterstützter Parameter, nicht unterstütztes Modell, fehlerhaftes Schema | Nicht als Anbieter-Gesundheit zählen. | Die Anwendung hat eine Anforderungsform gesendet, die die Route nicht bedienen kann. | Die Anfrage beheben oder vor dem Routing ein kompatibles Modell wählen. |
| Sicherheit, Moderation, DLP, Compliance oder Blockierung nicht freigegebener Datenklassen | Nie mit Fallback umgehen. | Das Routing zu einem anderen Modell könnte eine Richtliniengrenze überschreiten. | Geschlossen fehlschlagen und die Richtlinienentscheidung protokollieren. |
| Tool bereits ausgeführt, Teilstream bereits angezeigt, Benutzer hat Anfrage abgebrochen | Nicht stillschweigend erneut abspielen. | Die Anwendung kann doppelte Nebenwirkungen erzeugen oder zwei Modellausgaben zusammenführen. | Als unvollständig markieren, expliziten erneuten Benutzeraufruf verlangen oder einen idempotenten Wiederherstellungspfad verwenden. |
OpenAIs Leitfaden zu Fehlercodes ist ein nützliches Beispiel dafür, warum diese Taxonomie wichtig ist: Er trennt Authentifizierungs- und IP-Allowlist-Probleme, Probleme mit nicht unterstützten Regionen, Ratenlimits, Kontingenterschöpfung, Serverfehler, Überlastung und plötzliche Verlangsamungen der Anforderungsrate. Anthropic und Google Gemini-Dokus ziehen ähnliche Unterscheidungen zwischen Ratenlimits, Überlastungs-/Nichtverfügbarkeitsbedingungen, ungültigen Anfragen und Berechtigungs- oder Kontingentproblemen. Ihr LLM-API-Gateway-Circuit-Breaker sollte diese Klassen getrennt halten, bevor er eine Route öffnet.
Den Circuit Breaker auf den kleinsten Pfad eingrenzen, der den Fehler erklärt
Ein zu breit gefasster Circuit Breaker verursacht unnötige Ausfallzeiten. Ein zu eng gefasster Breaker lässt dieselbe Provider-Fehler-Schleife über benachbarte Pfade weiterlaufen. Grenzen Sie den Breaker auf die kleinste Routen-Dimension ein, die den Vorfall erklärt.
| Bereich | Wann verwenden | Risiko bei falscher Eingrenzung |
|---|---|---|
| Provider | Mehrere Modelle desselben Providers sind nicht verfügbar oder überlastet. | Zu breit, wenn nur ein Modell, ein Konto oder eine Endpunktfamilie ausfällt. |
| Modell | Eine Modellfamilie hat wiederholt 5xx-, Timeout- oder Fehler wegen nicht unterstützter Routen. | Zu eng, wenn das Upstream-Konto oder der Provider ausgelastet ist. |
| Endpunktfamilie | Chat funktioniert, aber Responses-, Bild-, Video-, Anthropic-Messages- oder Gemini-Routen verhalten sich anders. | Das Mischen von Endpunktfamilien kann protokollspezifische Fehler verdecken. |
| Konto-, Gruppen-, Regions- oder Vendor-Pfad | Nur ein Upstream-Konto, eine Routing-Gruppe, eine Region oder ein Vendor-Pfad fällt aus. | Wenn nicht isoliert wird, kann andernorts gesunde Kapazität verbraucht werden. |
| Workflow | Tool-Aufrufe, Streaming, Batch-Jobs oder kundenorientierter Chat haben unterschiedliche Sicherheits- und Replay-Regeln. | Eine Route, die für Batch-Anreicherung sicher ist, kann für Live-User-Streams unsicher sein. |
Für Flatkey-Nutzer bedeutet das, dass Sie von dem Workflow und der Route aus testen sollten, die Sie tatsächlich verwenden möchten. Der aktuelle Flatkey-Preis-API-Snapshot für diesen Artikel lieferte 638 Modellzeilen, 23 Anbieter und Endpunktfamilien für OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, Gemini generateContent, Bilderzeugung und OpenAI Video. Betrachten Sie dies als datierten Nachweis vom 18. Juni 2026, nicht als dauerhaften Routenvertrag.
Schwellenwerte festlegen, die zum LLM-Verkehr passen
Ein LLM API gateway circuit breaker sollte nicht wegen eines einzelnen isolierten Fehlers auslösen. Er sollte auch nicht warten, bis jede Kundenanfrage fehlschlägt. Verwenden Sie Schwellenwerte, die minimales Verkehrsvolumen, Fehlerrate, Latenz und Abklingzeit kombinieren.
| Schwellenwert | Praktischer Ausgangspunkt | Warum er wichtig ist |
|---|---|---|
| Minimale Stichprobengröße | Erst öffnen, nachdem genügend Anfragen oder Prüfungen beobachtet wurden. | Verhindert, dass ein einzelner teurer Abschluss eine globale Route öffnet. |
| Fehlerrate | Verfolgen Sie wiederholbare Upstream-Fehler getrennt von Fehlern, die der Anwendung selbst gehören. | Verhindert, dass Auth-, Kontingent- und fehlerhafte Anforderungsfehler die Routenintegrität beeinträchtigen. |
| Latenz- oder Timeout-Schwellenwert | Verwenden Sie endpunktspezifische Timeout-Budgets für Chat-, Streaming-, Bild- und Video-Pfade. | Ein guter Schwellenwert für Chat kann für Video- oder Batch-Generierung falsch sein. |
| Offen-Abklingzeit | Halten Sie die Route lange genug offen, um Wiederholungsstürme zu stoppen, und prüfen Sie dann erneut. | Schützt sowohl den Anbieter als auch Ihre eigene Warteschlange für Anfragen. |
| Halboffene Prüfgrenze | Erlauben Sie eine kleine, kontrollierte Anzahl von Testanfragen, bevor Sie schließen. | Verhindert einen vollständigen Verkehrsschub, wenn sich ein Anbieter nur teilweise erholt hat. |
| Kostendeckel | Setzen Sie eine maximale geschätzte Ausgabe für Wiederholungen, Fallback und Prüfungen fest. | Verhindert, dass die Wiederherstellung der Zuverlässigkeit zu einem Abrechnungsvorfall wird. |
Ratenbegrenzungen sind Teil der Diskussion über Schwellenwerte. OpenAI's rate-limit guide erklärt, dass Ratenbegrenzungen vor Missbrauch schützen, fairen Zugang sicherstellen und helfen, die Gesamtlast zu verwalten. Wenn Ihre App weiter in eine ratenbegrenzte Route hinein erneut versucht, kann Ihr eigenes Verkehrsmuster zum Vorfall werden. Der LLM API gateway circuit breaker sollte mit clientseitiger Drosselung, Warteschlangenbildung und Kontingentkontrollen zusammenarbeiten, nicht dagegen arbeiten.
Entscheiden, was geschieht, während der Unterbrecher offen ist
Das Öffnen eines Unterbrechers ist nur dann nützlich, wenn das Gateway eine definierte nächste Aktion hat. Lassen Sie nicht zu, dass jeder offene Pfad automatisch auf ein beliebiges verfügbares Modell zurückfällt.
| Open-State Action | Use When | Required Guardrail |
|---|---|---|
| Fallback route | Das Backup-Modell oder der Provider ist für den Workflow bereits freigegeben. | Führen Sie vor der Produktion dieselben Prüfungen für Eval, Schema, Tools, Datengrenzen und Kosten durch. |
| Queue | Der Job ist asynchron oder die Benutzererfahrung kann eine Verzögerung tolerieren. | Behalten Sie Owner-, Kunden-, Modell-, Kosten- und Retry-Metadaten bei. |
| Degrade | Ein risikoärmeres Teilergebnis ist akzeptabel, etwa eine zwischengespeicherte Antwort oder eine reduzierte Funktion. | Machen Sie den degradierten Zustand für die App und die Protokolle sichtbar. |
| Fail closed | Die Anfrage birgt Richtlinien-, Budget-, Sicherheits-, Auth-, Regions- oder Nebenwirkungsrisiken. | Geben Sie einen klaren Fehler zurück und alarmieren Sie den richtigen Owner, anstatt ein anderes Modell zu versuchen. |
Die öffentlichen Vercel AI Gateway-Dokumente beschreiben Model-Fallbacks als Gateway-Muster mit geordneten Backup-Modellen. Verwenden Sie das nur als kategorialen Nachweis. In Ihrem eigenen Stack ist Fallback eine separate Freigabeentscheidung. Der Unterbrecher entscheidet, ob ein Pfad derzeit gesund ist; Fallback entscheidet, ob ein anderer Pfad dieselbe Anfrage bedienen darf.
Streaming Und Tool-Aufrufe Benötigen Zusätzliche Stopps
Streaming macht es einfacher, einen Ausfall-Loop des Anbieters zu verbergen. Wenn die App eine Anfrage nach teilweiser Ausgabe stillschweigend neu startet, kann ein Benutzer eine zusammengeführte Antwort aus zwei Versuchen sehen. Tool-Aufrufe bringen ein zweites Problem mit sich: Ein Retry oder Fallback kann eine Rückerstattung, ein Ticket-Update, eine E-Mail, einen Datenbankschreibvorgang oder eine externe Aktion doppelt auslösen.
Verwenden Sie diese Regeln in der Richtlinie des LLM API Gateway Circuit Breakers:
- Vor der ersten Ausgabe: Retry oder Fallback kann erlaubt sein, wenn die Route genehmigt ist und der Breaker geschlossen oder halb offen ist.
- Nach der ersten Ausgabe: Markieren Sie den Stream als unvollständig und verlangen Sie einen expliziten erneuten Benutzerversuch statt eines stillen Fallbacks.
- Nach der Tool-Ausführung: Spielen Sie nicht erneut ab, es sei denn, das Tool ist idempotent und die Operation verfügt über einen Replay-Schlüssel.
- Nach einer Richtlinienblockierung: Fail closed. Leiten Sie nicht an ein anderes Modell weiter, um die Blockierung zu umgehen.
Dies ergänzt die Leitfäden AI API Retry-Strategie, Checkliste für Model-Fallbacks und AI API Load Balancing und Failover. Der Breaker sollte dieselbe Fehlertaxonomie wie diese Playbooks verwenden.
Observability-Felder für die Überprüfung von Circuit Breakern
Wenn eine Anfrage nur erfolgreich ist, weil das Gateway stillschweigend eine defekte Route übersprungen hat, muss der Vorfall dennoch sichtbar sein. Die Dokumentation von Cloudflares AI Gateway liefert ein öffentliches Beispiel für Observability-Muster von KI-Gateways: Request-Logs können Anbieter, Status, Tokens, Kosten und Dauer enthalten, und benutzerdefinierte Metadaten können Anfragen zur späteren Filterung markieren. Ihre Gateway-Logs sollten für Entscheidungen des Circuit Breakers denselben Grad an Routennachweisen liefern.
| Feld | Warum Betreiber es brauchen |
|---|---|
| Breaker-Richtlinien-ID und -Version | Zeigt, welche Regel die Route geöffnet, geschlossen oder umgangen hat. |
| Breaker-Status zum Zeitpunkt der Entscheidung | Erklärt, ob die Route geschlossen, offen, halb-offen oder fail-closed war. |
| Angefordertes Modell, ausgewähltes Modell, Anbieter, Konto, Gruppe und Endpunktfamilie | Trennt die Benutzerabsicht von der Route-Entscheidung des Gateways. |
| Fehlerklasse pro Versuch | Unterscheidet Upstream-Fehler von Auth-, Kontingent-, ungültige-Anfrage-, Richtlinien- und Tool-Fehlern. |
| Latenz, Timeout, Anzahl der Wiederholungen und Prüfergebnis | Zeigt, ob die Route langsam fehlschlug, schnell fehlschlug oder sich während der Half-Open-Prüfung erholte. |
| Flag für Teilausgabe und Status von Tool-Nebeneffekten | Verhindert versteckte Vorfälle mit gemischter Ausgabe oder doppelten Aktionen. |
| Nutzung, Kosten, Kontingentinhaber und endgültige Behandlung | Verknüpft die Wiederherstellung der Zuverlässigkeit mit Ausgaben, Budgets und Verantwortlichkeit. |
Der begleitende Artikel AI-API-Observability-Logs geht ausführlicher auf Incident-Logging ein. Für Circuit Breaker sollten Sie den Routenstatus und den genauen Grund priorisieren, warum eine Anfrage blockiert, geprüft, geroutet, in die Warteschlange gestellt oder fail-closed ausgeführt wurde.
Ein Rollout-Plan für Flatkey für Richtlinien von Circuit Breakern
Verwenden Sie diesen gestaffelten Ansatz, bevor Sie sich bei Kundenverkehr über Flatkey oder ein beliebiges OpenAI-kompatibles Gateway auf einen LLM-API-Gateway-Circuit-Breaker verlassen.
- Staging-Key erstellen: halten Sie Breaker-Tests getrennt vom produktiven Kundenverkehr.
- Basisroute bestätigen: richten Sie einen OpenAI-kompatiblen Client auf
https://router.flatkey.ai/v1aus und prüfen Sie Modell, Endpunktfamilie, Nutzungszeile und Dashboard-Sichtbarkeit. - Routen-Katalog snapshotten: speichern Sie die Flatkey-Preisseite und die Antwort der Pricing-API am Rollout-Tag, damit Annahmen zu Route und Preisen prüfbar sind.
- Fehler-Taxonomie definieren: legen Sie fest, welche Fehler zur Routen-Health zählen und welche bereits vor dem Breaker hart fehlschlagen.
- Mit einem Workflow beginnen: wenden Sie den Breaker auf eine Modellroute, eine Endpunktfamilie und eine Traffic-Klasse an, bevor Sie erweitern.
- Fehlersimulationen erzwingen: simulieren Sie Provider-Timeout, 500, 503, Request-Rate-429, Quota-Erschöpfung, Auth-Fehler, fehlerhafte Anfrage, partiellen Stream und Tool-Seiteneffekt.
- Verhalten im offenen Zustand prüfen: bestätigen Sie, dass Fallback-, Queue-, Degrade- oder Fail-Closed-Aktionen mit der Freigabematrix übereinstimmen.
- Logs und Billing überprüfen: bestätigen Sie nach jedem Test, dass Breaker-Status, ausgewählte Route, Nutzung, Kosten und Quota-Owner sichtbar sind.
- Rollback festlegen: deaktivieren Sie die Richtlinie, wenn sie zu breit öffnet, anwendungsseitige Fehler verdeckt oder unerwartete Ausgaben verursacht.
Circuit-Breaker-Richtlinienvorlage
Diese Vorlage ist kein Flatkey-API-Vertrag. Behandeln Sie sie als Review-Artefakt für Engineering-, Produkt-, Finanz- und Sicherheitsverantwortliche.
{
"policy_id": "support-chat-provider-breaker-v1",
"workflow": "customer-support-chat",
"environment": "production",
"route_scope": {
"provider": "primary-provider",
"model": "primary-approved-model",
"endpoint_family": "openai-chat-completions",
"traffic_class": "customer-visible-stream"
},
"count_toward_breaker": [
"upstream_5xx",
"provider_overloaded",
"provider_unavailable",
"upstream_timeout",
"connection_reset"
],
"fail_closed_before_breaker": [
"auth_error",
"ip_allowlist_error",
"unsupported_region",
"quota_exhausted",
"invalid_request",
"schema_incompatible",
"safety_or_policy_block",
"unapproved_data_class",
"tool_side_effect_already_committed"
],
"thresholds": {
"window_seconds": 60,
"minimum_requests": 20,
"failure_ratio_to_open": 0.5,
"timeout_ratio_to_open": 0.4,
"open_cooldown_seconds": 90,
"half_open_probe_requests": 3,
"max_total_attempts_per_request": 2
},
"open_state_action": {
"default": "fail_closed",
"allowed_fallback_policy_ids": [
"support-chat-fallback-v1"
],
"allow_after_partial_output": false,
"allow_after_tool_side_effect": false
},
"logging": {
"record_breaker_state": true,
"record_route_scope": true,
"record_error_class_per_attempt": true,
"record_probe_results": true,
"record_usage_cost_and_quota_owner": true
}
}Häufig gestellte Fragen
Was ist ein LLM-API-Gateway-Circuit-Breaker?
Ein LLM-API-Gateway-Circuit-Breaker ist eine Route-Health-Richtlinie, die normalen Traffic daran hindert, ein ungesundes Modell, einen Provider, ein Konto oder eine Endpunktfamilie zu erreichen, nachdem wiederholt wiederholbare Fehler aufgetreten sind. Er öffnet sich für ein Cooldown-Fenster, erlaubt begrenzte Half-Open-Probes und schließt sich erst wieder, wenn die Route erneut gesund wirkt.
Welche LLM-API-Fehler sollten einen Circuit-Breaker auslösen?
5xx-Fehler auf Provider-Seite, Überlastung, „unavailable“-Antworten, Verbindungsfehler und wiederholte Upstream-Timeouts sind typische Kandidaten. Authentifizierungsfehler, IP-Allowlist-Fehler, nicht unterstützte Regionen, erschöpftes Kontingent, fehlerhaft formatierte Anfragen, Policy-Blocks und Tool-Nebenwirkungen sollten in der Regel geschlossen fehlschlagen, statt einen Provider-Health-Breaker zu öffnen.
Worin unterscheidet sich ein Circuit-Breaker von Retry oder Fallback?
Retry entscheidet, ob eine einzelne Anfrage erneut versucht werden soll. Fallback entscheidet, ob eine andere freigegebene Route die Anfrage bedienen kann. Ein Circuit-Breaker entscheidet, ob eine Route überhaupt normalen Traffic erhalten sollte, solange sie ungesund erscheint.
Sollten Circuit-Breaker für Streaming-LLM-Antworten gelten?
Ja, aber mit strengeren Grenzen. Ein Breaker kann die Route schützen, bevor das erste sichtbare Token ankommt. Nach teilweise ausgegebenem Inhalt oder einer Tool-Nebenwirkung sollte die Anwendung nicht stillschweigend erneut abspielen oder auf Fallback umschalten, außer der Workflow ist ausdrücklich für idempotente Wiederherstellung ausgelegt.
Abschlussprüfung, bevor Sie den Unterbrecher aktivieren
Bevor Sie einen LLM API Gateway Circuit Breaker aktivieren, stellen Sie eine Frage: Wenn dieser Pfad während eines Vorfalles beim Anbieter geöffnet wird, kann das Team erklären, was ausgefallen ist, warum der normale Traffic gestoppt wurde, wohin der Traffic als Nächstes geleitet wurde, was es gekostet hat und wie die Richtlinie geschlossen oder zurückgesetzt werden kann?
Wenn die Antwort nein lautet, lassen Sie den Unterbrecher in der Staging-Umgebung. Wenn die Antwort ja lautet, nutzen Sie Flatkeys zentralisierten Modellzugriff, Routing, Nutzungstransparenz sowie Abrechnungs- und Kontingentsteuerung als Teil des Review-Zyklus. Wenn Sie bereit sind, Routen hinter einem OpenAI-kompatiblen Gateway zu validieren, holen Sie sich einen Schlüssel und beginnen Sie mit einem Workflow, einer Modellroute und einer Unterbrecher-Richtlinie.
