Wenn eine erfolgreiche Anfrage trotzdem ein Fehler ist
Stell dir vor, du sprichst seit Wochen mit demselben Charakter. Seine Stimme ist vertraut, seine Sprache bleibt konsistent und seine Antworten wirken klug und lebendig.
Dann fühlt sich plötzlich etwas falsch an, obwohl weder der Charakter noch das Modell geändert wurde.
Die nächste Antwort braucht zehn Sekunden, bis sie beginnt. Eine Funktion, die strukturierte Ausgaben benötigt, funktioniert auf einmal nicht mehr. Der Charakter schweift ab, mischt Fragmente einer anderen Sprache ein oder antwortet in einem Stil, der von einem deutlich schwächeren Modell zu stammen scheint.
Aus Sicht des Servers ist nichts fehlgeschlagen. Die API hat 200 OK zurückgegeben, Tokens sind angekommen und die Anfrage wurde abgerechnet.
Aus Sicht des Nutzers ist das Modell gerade schlechter geworden.
Diese Lücke ist der Grund, warum wir für Reverie ein Anbieter-Canary mit Routing-Quarantäne entwickelt haben.
Ein Modellname, viele Inferenzumgebungen
OpenRouter ist unser primäres Modell-Gateway. Eine seiner Stärken besteht darin, dass ein einzelnes Modell von vielen unabhängigen Inferenzanbietern bereitgestellt werden kann. Ist ein Anbieter nicht verfügbar, kann ein anderer die Anfrage übernehmen. Das verschafft uns mehr Kapazität, wettbewerbsfähige Preise und höhere Ausfallsicherheit als ein einzelner Endpoint.
Dadurch entsteht aber auch eine unsichtbare Variable.
Der Modellname bleibt gleich, während die dahinterliegende Infrastruktur von Anfrage zu Anfrage wechseln kann. Jeder Anbieter kann eine andere Inferenz-Engine, Hardwarekonfiguration, Quantisierungsstufe, einen anderen Parser, ein anderes Chat-Template, eine andere Warteschlange oder zusätzliche Richtlinien verwenden.
OpenRouter beschreibt in seiner Dokumentation zur Anbieter-Routingauswahl, dass das Standardrouting die jüngste Verfügbarkeit und den Preis berücksichtigt und weitere Anbieter als Fallback bereithält. Diese Signale sind wichtig. Ein Endpoint kann jedoch online und günstig sein und trotzdem ein Ergebnis liefern, das für ein bestimmtes Produkt nicht akzeptabel ist.
OpenRouter hat außerdem öffentlich über messbare Unterschiede zwischen Anbietern desselben Modells geschrieben. Theoretisch sollten identische Gewichte bei identischer Präzision ähnlich reagieren. In der Produktion ist der Betrieb großer Modelle komplex, und Unterschiede entstehen.
Was wir unter „Modelldegradation“ verstehen
„Modelldegradation“ ist keine einzelne, standardisierte Diagnose. Sie bedeutet auch nicht automatisch, dass ein Anbieter absichtlich ein kleineres Modell ausliefert.
Wir verwenden den Begriff operativ: Ein Inferenz-Endpoint ist beeinträchtigt, wenn er bei repräsentativen Prompts das erwartete Verhalten, die Fähigkeiten oder die interaktive Leistung des angeforderten Modells nicht mehr bewahrt – selbst wenn die Anfrage technisch erfolgreich ist.
Für Reverie sind die deutlichsten Formen:
- Latenzdegradation: Die Verbindung gelingt, aber die Zeit bis zum ersten Token ist so lang, dass das Gefühl eines Live-Gesprächs verloren geht.
- Fähigkeitsdegradation: Ein Endpoint, der strukturierte Ausgabe unterstützen soll, liefert fehlerhaften Text oder erfüllt das Schema nicht mehr.
- Verhaltensdegradation: Antworten sind beschädigt, inkohärent, unerwartet repetitiv oder wechseln deutlich in eine andere Sprache.
- Richtlinienkonflikt: Ein Host ergänzt eine eigene Filterebene und verwandelt eine von Reverie unterstützte Szene in eine Ablehnung, leere Antwort oder abgeschnittene Ausgabe.
Die Ursachen können vielfältig sein. Quantisierung mit geringerer Präzision kann schwierige Prompts beeinträchtigen, wie sowohl die OpenRouter-Dokumentation als auch veröffentlichte Forschung zur Quantisierung zeigen. Quantisierung ist jedoch keine Universalerklärung: Fehler in Inferenz-Engines, Tool-Parsern, Tokenizern oder Chat-Templates, überlastete Warteschlangen und Middleware des Anbieters können ebenso wichtig sein. OpenRouter hat bei Tool-Aufrufen beobachtet, dass Parser häufig größere Unterschiede verursachen als die Präzision allein.
Die entscheidende Frage lautet nicht „Welche Ursache klingt am verdächtigsten?“, sondern „Können wir den Endpoint isolieren und den Fehler reproduzieren?“.
Zwei Fälle, die das Problem greifbar machten
Für uns war das keine theoretische Sorge.
In einem fest auf Anbieter gepinnten Vergleich beschädigte ein Anbieter den Anfang von 19 von 20 Antworten, indem er Satzzeichen oder Fragmente eines unbeteiligten Tokens einfügte. Bei vierzehn anderen Hosts desselben Modells trat das Problem in 0 von 49 Antworten auf. Beim Rollenspiel ist das erste Zeichen oft ein Markdown-Marker für Hervorhebung, sodass bereits ein zusätzliches Byte die Formatierung der gesamten Antwort zerstören konnte.
In einem weiteren Test erzeugte ein Endpoint in 3 von 3 Generierungen eine starke Mischung aus Portugiesisch und Spanisch. Derselbe Prompt blieb beim offiziellen Host des Modells und bei anderen getesteten Hosts derselben Präzisionsklasse auf Portugiesisch. „Das Modell ist einfach inkonsistent“ war damit keine gute Erklärung mehr – der Fehler folgte dem Endpoint.
Solche Fehler sind schwer zu erkennen, weil sie nicht zwingend Exceptions auslösen. Klassisches Uptime-Monitoring sieht eine gesunde API. Der Nutzer erlebt einen Charakter, der plötzlich nicht mehr richtig sprechen kann.
Unsere Antwort: Jede Route testen, nicht nur das Modell
Alle dreißig Minuten ermittelt unser Canary die aktiven Anbieter für Reveries Standard-Chatmodell. Anschließend sendet es eine kleine Gruppe synthetischer Anfragen an jeden Anbieter, fest auf diesen einen Anbieter gepinnt und ohne Fallbacks.
Das Pinning ist entscheidend. Darf eine Probe ausweichen, kann ein zweiter gesunder Anbieter den Fehler des ersten verbergen. Wir müssen genau wissen, welche Umgebung das Ergebnis erzeugt hat.
Das System prüft vier eng umrissene Verträge, die maschinell bewertet werden können.
1. Zeit bis zum ersten Token
Bei einem gestreamten Gespräch ist der Durchsatz nur die Hälfte des Erlebnisses. Das erste Token entscheidet, wie lange der Nutzer auf einen Ladeindikator blickt.
Wir messen die Zeit direkt im Stream. Liefert ein Anbieter innerhalb von zehn Sekunden keinen Text, schlägt die Latenzprobe fehl. Der Grenzwert ist bewusst großzügig, und eine einzelne langsame Runde reicht nicht aus, um einen Host zu entfernen – kurzfristiger Warteschlangendruck kommt vor.
2. Filterung und stille Ablehnungen
Wir senden eine fest definierte Rollenspiel-Fortsetzung, die für den von Reverie unterstützten Datenverkehr repräsentativ ist. Die Probe untersucht den Finish Reason, eindeutige Ablehnungsmuster und leere Ausgaben.
Zusätzlich läuft sie gegen bekanntermaßen filternde Hosts als Positivkontrollen. Besteht eine solche Kontrolle unerwartet, erklären wir nicht alle anderen Anbieter für gesund, sondern markieren die Probe selbst als zu schwach. Ein Test, der seinen bekannten Fehler nicht mehr erkennt, ist kein Gesundheitsnachweis.
3. Strukturierte Ausgabe
Wir fordern ein kleines Objekt mit festem Schema an und validieren das Ergebnis. Transportfehler und fehlerhafte Ausgaben werden unterschiedlich behandelt: Eine unterbrochene Verbindung bedeutet, dass der Anbieter nicht erreichbar war. Eine abgeschlossene Generierung, die das Schema nicht erfüllen kann, ist dagegen ein Hinweis auf einen Fähigkeitsrückschritt.
„Der Endpoint gibt an, den Parameter zu unterstützen“ und „der Endpoint erfüllt ihn zuverlässig“ sind nicht dasselbe Versprechen.
4. Sprachintegrität
Reverie unterstützt 17 Oberflächensprachen. Ein reiner Englisch-Smoke-Test würde daher einige Fehler übersehen, die unsere Nutzer tatsächlich erleben.
Das Canary rotiert mit synthetischen Rollenspiel-Prompts durch die unterstützten Sprachen. Ein lokaler, deterministischer Sprachdetektor sucht nach einem eindeutigen Sprachwechsel der gesamten Antwort, anhaltender Sprachmischung und offensichtlicher Zeichenkodierungsbeschädigung. Es werden keine echten Gespräche verwendet und kein zweites Modell um ein subjektives Urteil gebeten.
Mehrdeutige oder zu kurze Ausgaben gelten als nicht entscheidbar, nicht als Fehler. Wird eine Sprachabweichung erkannt, führt das Canary sofort zwei Bestätigungsversuche aus und verlangt eine Mehrheit. Dieselbe Sprache wird in der nächsten Runde erneut getestet, damit ein Anbieter die Regel für aufeinanderfolgende Runden nicht durch die Rotation umgeht.
Das System soll seinen eigenen Schlussfolgerungen misstrauen
Inferenzkapazität automatisch zu entfernen ist nützlich. Ein Fehlalarm kann jedoch einen größeren Ausfall verursachen als der ursprüngliche Defekt. Deshalb besitzt das Canary mehrere Bremsen:
- Transportfehler zählen nicht als Qualitätsmängel. Timeouts, Rate Limits und 5xx-Antworten frieren den Score ein, statt eine Suspendierungsserie zu verlängern.
- Eine schlechte Runde reicht nicht. Ein Anbieter muss in zwei aufeinanderfolgenden, halbstündlichen Runden fehlschlagen.
- Beobachtung und Durchsetzung sind getrennt. Wir können das System zunächst im Beobachtungsmodus betreiben, potenzielle Suspendierungen protokollieren, Administratoren informieren und Fehlalarme messen, bevor automatische Maßnahmen aktiviert werden.
- Die Kapazität hat eine Untergrenze. Das Canary suspendiert keinen Anbieter, wenn danach weniger als zwei Produktionshosts übrig wären. Stattdessen wird ein Administrator gewarnt.
- Auch die Erholung wird getestet. Suspendierte Anbieter bleiben prüfbar. Zwei vollständig bestandene Runden stellen einen Host vorzeitig wieder her.
- Wiederholte Ausfälle eskalieren schrittweise. Die erste Suspendierung dauert einen Tag, die nächste drei und weitere sieben Tage. Nach vierzehn Tagen ohne neue Suspendierung verblasst die Vorgeschichte und die Staffel beginnt von vorn.
Das Ziel besteht nicht darin, Anbieter zu bestrafen. Wir wollen Nutzerverkehr von einer reproduzierbar fehlerhaften Route weglenken und zugleich einen klaren Rückweg offenhalten, sobald das Problem behoben ist.
Drei Schutzebenen
Die endgültige Routingentscheidung kombiniert drei Arten von Ausschlüssen:
- Geprüfte, fest integrierte Ausschlüsse für gemessene Defekte oder Richtlinienkonflikte, die nicht versehentlich zurückkehren sollen.
- Laufzeit-Ausschlüsse für Vorfälle, die ein Administrator sofort und ohne neues Deployment hinzufügen kann.
- Zeitlich begrenzte Canary-Suspendierungen für Anbieter, die den automatischen Fehlerschwellenwert überschreiten.
Diese Listen werden beim Erstellen einer Anfrage in OpenRouters provider.ignore-Vorgabe zusammengeführt. Nutzer müssen nicht so lange wiederholen, bis zufällig ein besserer Anbieter ausgewählt wird; die fehlerhafte Route wird gar nicht mehr berücksichtigt.
Jede automatische Entscheidung wird protokolliert, Administratoren werden bei wichtigen Zustandswechseln benachrichtigt und eine Suspendierung kann bei Bedarf manuell aufgehoben werden.
Was dieses System garantiert – und was nicht
Das Canary ist absichtlich eng gefasst. Latenz, Schemavalidität, eindeutige Filterung, Sprach- und Kodierungsintegrität lassen sich per Code bewerten. Es gibt nicht vor, beurteilen zu können, ob ein Charakter lustig genug, emotional feinfühlig genug oder einer komplexen Persönlichkeit treu genug ist.
Solche umfassenderen Fragen benötigen weiterhin Evaluationen mit repräsentativen Prompts, menschliche Prüfung, Produktionstelemetrie und vor allem Nutzerberichte.
Das System bedeutet auch nicht, dass jede seltsame Antwort eine Modelldegradation beweist. Generative Modelle sind probabilistisch. Lange Gespräche können widersprüchlichen Kontext ansammeln, und Charakterdefinitionen können konkurrierende Anweisungen enthalten. Manchmal ist eine seltsame Antwort einfach nur seltsam.
Verändert hat sich, dass „dasselbe Modell“ nicht mehr das Ende unserer Untersuchung ist. Wir können die Route isolieren, objektive Fehler reproduzieren und nachfolgenden Verkehr von ihr fernhalten.
Zuverlässigkeit bedeutet, das Erlebnis zu bewahren
Multi-Anbieter-Routing bleibt wertvoll. Es gibt Reverie die Kapazität und Ausfallsicherheit, Gespräche verfügbar zu halten, wenn einzelne Endpoints ausfallen.
Doch Ausfallsicherheit bedeutet nicht nur, irgendeine HTTP-Antwort zu erhalten. Eine Antwort, die zu spät beginnt, ihre erforderliche Struktur verliert, unterstützte Inhalte ablehnt oder plötzlich die Sprache wechselt, ist nicht gesund, nur weil sie auf der Rechnung als erfolgreich erscheint.
Bei einem KI-Charakterprodukt bedeutet Zuverlässigkeit etwas Menschlicheres: Der Charakter sollte sich weiterhin wie derselbe Charakter anfühlen – unabhängig davon, welche Maschine gerade für ihn spricht.
Diesen Standard sollen unsere neuen Routing-Schutzmechanismen bewahren.
Wenn du eine plötzliche Veränderung der Antwortqualität oder Sprache bemerkst, sende uns bitte einen Bericht mit dem Modellnamen und der ungefähren Uhrzeit. So können wir dein Erlebnis genau der Route zuordnen, die es ausgeliefert hat.