Anfragen an günstigere Modelle leiten, ohne Qualitätsverluste zu verbergen

Zwei Routing-Fehler mit unterschiedlichen Kosten

Unterrouting schickt eine Anfrage, die das starke Modell gebraucht hätte, an das günstige. Der Nutzer bekommt eine schlechtere Antwort, und im Kosten-Dashboard ist davon nichts zu sehen. Überrouting schickt eine einfache Anfrage an das starke Modell. Die Antwort ist in Ordnung, und die Ersparnis ist kleiner als möglich. Die meisten Routing-Projekte berichten nur den zweiten Fehler, weil nur er auf der Rechnung auftaucht.

Beide Fehler hängen über den Schwellenwert des Routers voneinander ab. Entscheiden Sie also vor dem Feintuning, welchen Sie eher tolerieren können. Bei einem Coding-Assistenten kostet eine schwache Antwort einen Engineer ein paar Minuten. Bei einem Schreiben zu einem Versicherungsfall kann sie eine Beschwerde kosten.

Den Abnahmetest bauen, bevor etwas eingeschaltet wird

Nehmen Sie eine aktuelle Stichprobe echter Anfragen und lassen Sie jede durch beide Modelle laufen. Lassen Sie Fachleute oder ein gegen Fachleute geprüftes Bewertungsmodell jede Antwort jedes Modells anhand einer Referenz oder ihres eigenen Urteils als akzeptabel oder nicht markieren. Nehmen Sie nicht an, dass das starke Modell immer richtig liegt: Anfragen, bei denen keine Antwort akzeptabel ist, sind ein Problem des Prompts oder der Aufgabe und gehören nicht in die Routing-Zahlen. Dann lassen Sie den Router auf derselben Stichprobe laufen. Ein hypothetisches Ergebnis für 1.000 Anfragen, bei denen die starke Antwort immer und die günstige in 700 Fällen akzeptabel war:

• Günstig geroutet und akzeptabel: 610
• Günstig geroutet, aber nicht akzeptabel, also unterroutet: 40
• Stark geroutet, obwohl günstig akzeptabel gewesen wäre, also überroutet: 90
• Stark geroutet und nötig: 260

Angenommen, das günstige Modell kostet pro Anfrage ein Zehntel, und die Kosten des Routers selbst bleiben außen vor. Alles an das starke Modell zu schicken kostet 1.000 Einheiten, dieses Routing 415, aber 4 Prozent der Nutzer bekommen eine schlechtere Antwort. Liegt die vereinbarte Grenze bei 1 Prozent, erhöhen Sie den Schwellenwert und behandeln diese Stichprobe als Kalibrierungsset. Angenommen, der neue Schwellenwert schickt 560 Anfragen an das günstige Modell, davon 9 unterroutet, für 496 Einheiten. Bestätigen Sie das dann auf einer getrennten zurückgehaltenen Stichprobe, die der Schwellenwert nie gesehen hat. Kleine Zahlen brauchen ein Intervall: 9 Fehler bei 1.000 passen bei 95 Prozent Konfidenz zu einer tatsächlichen Quote von etwa 0,5 bis 1,7 Prozent. Um zu zeigen, dass die Grenze hält, kann eine größere abschließende Stichprobe nötig sein.

Regeln, gelernte Router und Kaskaden

Regeln nach Funktion, Aufgabentyp oder Mandant sind am leichtesten zu prüfen und können einen großen Teil der möglichen Ersparnis erfassen. Gelernte Router entscheiden pro Anfrage: RouteLLM trainiert sie auf menschlichen Präferenzdaten und berichtet, auf einigen Benchmarks die Kosten mehr als halbiert zu haben, ohne die Antwortqualität zu senken. Kaskaden rufen zuerst das günstige Modell auf und eskalieren, wenn eine Prüfung fehlschlägt. FrugalGPT berichtet auf diese Weise große Einsparungen, doch eskalierte Anfragen bezahlen zwei Aufrufe, warten auf beide, und die Prüfung selbst muss verlässlich sein.

Veröffentlichte Einsparungen sind ein Beleg dafür, dass Routing funktionieren kann, aber keine Prognose. Sie stammen aus Benchmark-Traffic und Preisabständen, die sich von Ihren unterscheiden. Auch Gateways bringen inzwischen Router mit: Das Auto-Routing von LiteLLM, zum Zeitpunkt des Schreibens in der Beta, ordnet Anfragen mit Heuristiken, einem LLM-Klassifikator oder einem eigenen Plugin Stufen zu. Was auch immer Sie nutzen, es durchläuft denselben Abnahmetest.

Fallbacks sichern Verfügbarkeit, nicht Qualität

Ein Fallback greift bei Fehlern. In LiteLLM wechselt ein Aufruf, der nach seinen Wiederholungen noch scheitert, zur nächsten Modellgruppe einer geordneten Liste, und eigene Listen können Fehler wegen Kontextfenster oder Inhaltsrichtlinien abfangen. Nichts davon prüft die Antwort. Ist das Fallback-Ziel ein Modell, das Ihr Abnahmetest nie abgedeckt hat, wird aus einem Ausfall eine ungetestete Qualitätsänderung. LiteLLM weist zudem darauf hin, dass ein Fallback zu einem anderen Anbieter verschlüsseltes Reasoning aus früheren Runden nicht lesen kann.

Lassen Sie jedes Fallback-Ziel durch den Abnahmetest laufen und proben Sie den Wechsel in einer Nicht-Produktionsumgebung mit einem echten Anbieterfehler, wie es die LiteLLM-Dokumentation empfiehlt.

Erkennen, wann das Routing in der Produktion danebenliegt

Protokollieren Sie zuerst, welches Modell tatsächlich geantwortet hat. Beim Auto-Routing von LiteLLM behält der Antworttext den Alias, den der Client aufgerufen hat, und das bedienende Modell steht im Antwort-Header x-litellm-model-id. Erfassen Sie ihn. Die Spend-Logs halten für jede Anfrage außerdem attempted_fallbacks und original_model_group fest und trennen so Fallback-Traffic von geroutetem Traffic. Beobachten Sie dann diese Signale je Stufe:

• Eine kleine Stichprobe von Anfragen der günstigen Stufe, die zusätzlich an das starke Modell geht und verglichen wird, damit Unterrouting gemessen statt geschätzt wird
• Nutzer, die kurz nach einer Antwort der günstigen Stufe erneut fragen oder umformulieren
• Der Traffic-Anteil je Stufe, der sich verschiebt, wenn sich die Mischung der Anfragen oder die Eingaben des Routers ändern
• Fallback-Quote je Anbieter, getrennt von Routing-Entscheidungen