Kompatibilität bestimmt die Form, der Vertrag das Verhalten
Ein gemeinsames Anfrage- und Antwortformat verringert Änderungen in der Anwendung und erleichtert den Wechsel zwischen Modellen oder Anbietern. Auch der Zugang lässt sich über eine Schnittstelle bündeln. Gleiche Felder sagen jedoch nicht, ob eine Anfrage angenommen wurde, welcher Anbieter sie ausführte, wann eine Wiederholung zulässig ist, wie ein Teilergebnis einzuordnen ist oder wie sich die endgültige Nutzung abgleichen lässt. Sobald Menschen sich auf das System verlassen, gehören diese Fragen zum Produktvertrag.
Ein Gateway braucht deshalb klare Grenzen für Eingabeprüfung, Zulassung und Regeln, Routenwahl, Ausführung, Ergebnisbewertung und Nutzungsnachweise. Das sind Architekturaufgaben, keine Behauptung, alle Gateways setzten sie gleich um. Ein erfolgreicher HTTP-Austausch beweist nicht, dass die Arbeit abgeschlossen ist. Umgekehrt kann die Antwort beim Aufrufer verloren gehen, obwohl der Anbieter bereits gearbeitet hat. Beides pauschal als Fehler zu behandeln verdeckt die eigentliche Entscheidung im Betrieb.
Ein Stream ist eine Folge von Belegen, keine einzelne Antwort
Streaming zeigt Text, während das Modell ihn noch erzeugt. Der von OpenAI dokumentierte HTTP-Stream nutzt beispielsweise servergesendete Ereignisse und unterscheidet schrittweise Ausgabe von einem Abschlussereignis. Eine Anwendung kann bereits einen nützlichen Anfang anzeigen, ohne zu wissen, ob die Antwort vollständig ist. Empfängt sie zwei Absätze und läuft dann die Verbindung ab, beweist der sichtbare Text keinen Abschluss. [2]
Das Gateway sollte festhalten, was bekannt ist: Anfragekennung, gewählte Route, Annahme durch den Anbieter, beobachtete Ereignisse und bestätigten oder fehlenden Abschluss. Sichtbarer Teiltext ist kein endgültiges Ergebnis. Das ist eine Architekturentscheidung, kein Versprechen, dass jeder Anbieter Streams fortsetzen kann. Das System kann den unvollständigen Stand zeigen, eine bewusste Entscheidung über einen neuen Versuch verlangen oder einen Anbieter-Datensatz prüfen, sofern möglich. Wichtig ist, Unsicherheit auszuweisen, statt sie stillschweigend in Erfolg oder Misserfolg umzudeuten.
Vor einem neuen Versuch doppelte Arbeit bedenken
Ein ausdrücklich fiktives Beispiel: Eine Anwendung schickt einen Schreibauftrag, der Anbieter beginnt zu streamen, zwei Absätze kommen an, dann endet die Verbindung mit Timeout. Der Anbieter könnte weiter erzeugen und bereits entstandene Kosten berechnen. Schickt die Anwendung sofort denselben Prompt erneut, können eine zweite Generierung und weitere Kosten entstehen, selbst wenn nur eine Antwort gezeigt wird. Das Timeout beweist nicht, dass der erste Versuch nie stattfand. Laut OpenAIs Chat-Completions-Dokumentation kann bei unterbrochenem Stream zudem der letzte Block mit dem vollständigen Verbrauch fehlen. [3]
Die HTTP-Semantik formuliert die Vorsicht genau: Nicht idempotente Anfragen sollen nicht automatisch wiederholt werden, außer ihre tatsächliche Idempotenz oder die Nichtausführung des ersten Versuchs ist bekannt; ein Proxy darf sie nicht automatisch wiederholen. Modellgenerierung wird häufig per POST aufgerufen, daher reicht die vertraute Form der Schnittstelle nicht als Begründung. [1] Eine Regel kann Wiederholungen vor dem Versand zulassen, eine vom Anbieter angebotene Idempotenz nutzen oder nach einem unklaren Stream einen ausdrücklich neuen Versuch verlangen. Geschwindigkeit und Komfort stehen gegen doppelte Arbeit und unklare Kosten.
Erst die Zulässigkeit klären, dann den Ausführungsort
Routing entscheidet, wo eine zulässige Anfrage ausgeführt wird. Richtlinien entscheiden, ob und unter welchen Grenzen sie ausgeführt werden darf. Eine Aufgabe kann Modalität, Kontextlänge, Region, erlaubte Anbieter, Werkzeugrechte oder Kostengrenzen vorgeben. Fällt der bevorzugte Anbieter aus, hilft eine Ausweichroute nur, wenn sie diese Anforderungen weiter erfüllt. Unbemerkt auf eine unzulässige Route zu wechseln verändert die Vereinbarung mit der Anwendung.
Ein beispielhafter Ablauf lautet: Anfrage prüfen → Richtlinien und Budget bewerten → geeignete Route wählen → mit Frist ausführen → Ergebnis einordnen → beobachtete Nutzung erfassen → Abrechnungsereignis im eigenen System des jeweiligen Produkts erzeugen. Das beschreibt keine bereits ausgelieferten RouterShift-Interna. Routenwahl, Fehlerbehandlung und Abrechnung sollten getrennt erklärbar sein. Feste Regeln lassen sich leichter prüfen; adaptive Auswahl kann bei verlässlicher Rückmeldung helfen, erfordert aber eine Begründung für die konkrete Entscheidung.
Beobachtete Nutzung messen, bevor daraus Geld wird
Eine Anfrage, ein Ausführungsversuch und die endgültige Nutzungsangabe des Anbieters sind verschiedene Tatsachen. Bei einem abgebrochenen Stream kann der Endwert fehlen. Eine Schätzung anhand des sichtbaren Textes darf nicht als endgültige Belastung erscheinen. Anbieterangabe, Versuchskennung und Grundlage jeder Schätzung sollten erhalten bleiben. Liegt die maßgebliche Angabe vor, kann sie abgeglichen werden; Korrekturen müssen nachvollziehbar bleiben. [3]
Die aktuellen GenAI-Konventionen von OpenTelemetry benennen Eingabe- und Ausgabetokens, Modell, Anbieter und Fehlerarten. Sie liefern ein Vokabular für Telemetrie, kein Abrechnungssystem und keine Garantie gleicher Einheiten bei allen Anbietern. Außerdem warnen sie vor sensiblen Daten in aufgezeichneten Nachrichten. [4] Preisbildung und Kontobewegungen folgen nach der Messung und benötigen Währung, Tarifversion und Prüfbarkeit. Für Bild, Audio und Video können andere Einheiten als Tokens nötig sein.
Den Vertrag im Alltag überprüfbar machen
Bei einem Vorfall muss das Team beantworten können: Welche Anfrage war betroffen? Welche Route wurde warum gewählt? Hat der Anbieter den Auftrag angenommen? Ist die Ausgabe vollständig? Welche Nutzung ist bestätigt, geschätzt oder unbekannt? Welche Regel- und Preisversion galt? Anfrage- und Versuchskennungen, Ergebniszustände und Verweise auf Traces ermöglichen Antworten, ohne Prompt-Inhalte standardmäßig zu protokollieren. Die Darstellung muss für Betriebsteams verständlich sein, nicht nur für Entwickler.
Diese Fragen prüfen auch die Versprechen eines Gateways. Scheitert ein Anbieter vor dem Versand, kann eine andere geeignete Route sinnvoll sein. Bricht ein Stream nach Beginn ab, sollte das System ein unvollständiges oder ungewisses Ergebnis nennen und die nächsten Möglichkeiten erklären. Fehlende Nutzungsdaten bleiben bis zum Abgleich offen. Kompatibilität senkt den Einstiegspreis; ein Betriebsvertrag macht Verhalten außerhalb des Idealfalls vorhersehbar. RouterShift ist SlateMoths aktives Produkt für Modellzugang. Dieser Rahmen erläutert eine Entwurfsaufgabe, ohne zu behaupten, dass jeder genannte Mechanismus dort bereits verfügbar ist.