Zuverlässigkeitsarchitektur

Wir behandeln „Stabilität" als das wichtigste Feature des Produkts. Diese Seite erklärt, wie wir das erreichen und was passiert, wenn etwas schiefgeht.

Warum ist Zuverlässigkeit so schwierig?

Entwickler, die sich direkt mit der offiziellen API verbinden, stoßen auf Dinge wie:

• Regionale Ratenbegrenzung / Nichtverfügbarkeit
• Ein einzelner Zahlungskanal oder ein Konto wird gesperrt
• Kompatibilitätsprobleme bei Modellversionswechseln
• Warteschlangen zu Spitzenzeiten und Spitzen bei der First-Token-Latenz

Wenn ein Relay-Dienst nur ein einfacher Proxy ist, werden diese Probleme unverändert an die Nutzer weitergereicht oder sogar verschlimmert. Unser Ansatz besteht darin, das System unter der Prämisse „Upstreams sind instabil" zu konzipieren, anstatt dies als Ausnahme zu behandeln.

Unsere Multi-Source-Routing-Architektur

Für jeden API-Aufruf wird die Anfrage entlang des folgenden Pfades verarbeitet:

Kernmechanismen:

• Multi-Upstream-Pool: Mehrere unabhängige Kanäle sitzen hinter demselben Modell und vermeiden Single-Points-of-Failure
• Health-Probing: Wir überwachen kontinuierlich die Erfolgsrate, First-Token-Latenz und Rate-Limit-Rate jedes Upstreams, und ungesunde Kanäle werden automatisch abgewertet oder entfernt
• Automatisches Failover: Wenn der primäre Kanal 5xx / Ratenbegrenzung / Timeouts zurückgibt, wechselt die Anfrage innerhalb von Millisekunden zu einem Backup-Kanal, normalerweise ohne Auswirkung auf deiner Seite
• Stream-Interruption-Reconnect: Wenn eine Streaming-Antwort mittendrin abbricht, versuchen wir, sie bei Protokollen, die dies unterstützen, wieder aufzunehmen

Servicelevel (SLA)

Unsere externen Zusagen basieren auf „dem, was wir tatsächlich liefern können" — wir machen keine leeren Versprechen.

Die Economy-Stufe ist für einzelne Entwickler gedacht, die das beste Preis-Leistungs-Verhältnis wollen und gelegentliche Schwankungen tolerieren können; wenn dein Geschäft harte Zuverlässigkeitsanforderungen hat, wähle die Enterprise-Stufe oder kontaktiere unser Vertriebsteam für einen individuellen Plan.

Wie die Verfügbarkeit gemessen wird:

• Wir zählen nur die Erfolgsrate der Anfragen „auf der LMU AI-Seite", ausgenommen nutzerseitige Netzwerkprobleme, Parameterfehler und Inhaltsablehnungen durch das Upstream-Modell selbst
• Ein einzelner Ausfall von weniger als 60 Sekunden wird nicht gezählt
• Der Monatsbericht enthält Erfolgsraten und P95-Latenz aufgeschlüsselt nach Modell und nach Zeitraum

Was während eines Vorfalls passiert

Kurzes Jitter (< 5 Minuten)

• Die Routing-Schicht wechselt Upstreams automatisch, ohne Ankündigung
• Die Statusseite protokolliert das Ereignis

Ausfall eines einzelnen Upstreams (< 1 Stunde)

• Die Routing-Schicht schließt den Wechsel ab; wenn es für einige Nutzer/Modelle sichtbar ist, posten wir es auf der Statusseite
• Standard- und Enterprise-Nutzer werden per E-Mail benachrichtigt

Regionale oder gleichzeitige Multi-Upstream-Auswirkung

• Das Ereignis wird auf der Statusseite angeheftet mit regelmäßigen Aktualisierungen
• Enterprise-Nutzer erhalten Fortschrittsupdates per E-Mail in Echtzeit
• Ein Postmortem wird innerhalb von 48 Stunden nach Ende des Ereignisses veröffentlicht

Was wir nicht tun

Um Nutzer nicht in die Irre zu führen, versprechen wir derzeit nicht Folgendes:

• Nahtloser Wechsel ohne Latenz: Failover führt zusätzliche Latenz von Millisekunden bis Sekunden ein, sodass es niemals völlig nahtlos sein wird
• Cross-Model-Kompatibilitätsentschädigung: Wenn ein Upstream-Modell selbst eingestellt wird (zum Beispiel wenn eine Modellversion vom Anbieter eingestellt wird), kündigen wir dies an, anstatt stillschweigend zu einem anderen Modell zu wechseln
• Unbegrenzte Wiederholungen: Fehlgeschlagene Anfragen werden gemäß der Richtlinie eine begrenzte Anzahl von Malen wiederholt, sodass du nicht für unerwartete wiederholte Aufrufe bezahlst

FAQ

Zuletzt aktualisiert: 2026-09-10