Für jeden Aufruf dasselbe Modell zu verwenden, kann unnötig teuer sein. Routing ist jedoch nicht automatisch eine Verbesserung.
Ein Team kann feststellen, dass Klassifizierung, Extraktion, Texterstellung und anspruchsvolle Schlussfolgerungen unterschiedliche Anforderungen an Qualität und Latenz stellen. Routing kann diese Unterschiede nutzen. Es kann aber auch einen zusätzlichen Klassifizierungsaufruf, neue Ausfallmöglichkeiten bei Anbietern, uneinheitliches Sicherheitsverhalten und mehr Evaluierungsaufwand mit sich bringen. Eine belastbare Einsparungsprognose lässt sich nur aus den tatsächlich gemessenen Token-Mengen, den aktuellen Anbieterpreisen und den Qualitätsvorgaben berechnen.
Darum geht es bei der Orchestrierung mehrerer Modelle: Für einen klar definierten Aufruftyp wird unter ausdrücklichen Vorgaben zu Qualität, Latenz, Datenschutz und Kosten ein Modell oder spezialisierter Dienst ausgewählt.
Dieser Artikel erläutert die wichtigsten Muster, die Routing-Logik und die Abwägungen und zeigt Schritt für Schritt, wie sich ein solches System umsetzen lässt.
Warum ein einzelnes Modell nicht optimal ist
Die Modellkataloge der Anbieter ändern sich häufig. Für eine konkrete Arbeitslast lassen sich dennoch funktionale Klassen definieren:
Klasse für anspruchsvolle Schlussfolgerungen: Kandidaten für schwierige Planungs- oder Analyseaufgaben. Bewerten Sie anhand Ihrer eigenen Fälle die Genauigkeit, den Umgang mit Werkzeugen, die Latenz in den oberen Perzentilen und die Gesamtzahl der für Schlussfolgerungen erzeugten Token.
Allgemeine Klasse: Kandidaten für Texte, die Nutzerinnen und Nutzer zu sehen bekommen, sowie für gemischte Wissensarbeit, bei der Qualität wichtig ist, aber keine ausführlichen Schlussfolgerungen nötig sind.
Klasse mit niedriger Latenz: Kandidaten für klar begrenzte Klassifizierungs-, Extraktions- und Umformulierungsaufgaben. Ein kleineres Modell garantiert weder ausreichende Genauigkeit noch eine geringere Gesamtlatenz.
Lokale oder kleine Modelle: Kandidaten, wenn lokale Datenhaltung, Offline-Betrieb oder niedrige Grenzkosten bei der Bereitstellung wichtig sind. Beziehen Sie Hardware, Betrieb, Energieverbrauch, Parallelverarbeitung und die Auswirkungen der Quantisierung in den Vergleich ein.
Spezialisierte Dienste für Einbettungen, Neusortierung, Bildverarbeitung oder Sprache: Vergleichen Sie sie bei genau der vorgesehenen Aufgabe mit allgemeinen Modellen. Spezialisierung allein belegt weder eine höhere Qualität noch geringere Gesamtkosten.
Verwenden Sie bei der Entscheidung die jeweils aktuellen Modell- und Preisseiten: OpenAI-Modelle und Preise, Anthropic-Modelle und Preise sowie Google-Modelle und Preise. Behandeln Sie weder Verfügbarkeit noch Preise als dauerhaft gültige Architekturannahmen.
Eine typische KI-Anwendung führt viele verschiedene Arten von LLM-Aufrufen durch. Jeder Aufruf hat seine eigenen Anforderungen:
- Nutzerabsicht klassifizieren: Bewerten Sie einen Kandidaten mit niedriger Latenz anhand eines annotierten Datensatzes, der auch mehrdeutige und nicht abgedeckte Fälle enthält.
- Strukturierte Daten extrahieren: Messen Sie die Genauigkeit auf Feldebene und die Gültigkeit des Schemas, nicht die Modellgröße.
- Eine Antwort für Nutzerinnen und Nutzer erzeugen: Messen Sie Faktentreue, Einhaltung der Richtlinien und Latenz in den oberen Perzentilen.
- Frühere Gespräche zusammenfassen: Prüfen Sie, ob Entscheidungen, Namen, Einschränkungen oder Verneinungen ausgelassen werden.
- Hintergrundverarbeitung in größeren Mengen: Messen Sie Durchsatz, Kosten von Wiederholungsversuchen und die Einhaltung von Fristen.
Gehen Sie weder davon aus, dass der günstigste Kandidat ausreicht, noch dass der teuerste der beste ist. Prüfen Sie alle Routen mit demselben Evaluierungsdatensatz.
Berechnen Sie die Einsparungen aus der Telemetrie
Erfassen Sie für jeden Aufruftyp Folgendes:
- monatliche Aufrufanzahl;
- Eingabe-, zwischengespeicherte Eingabe- und Ausgabe-Token-Verteilungen;
- Anteil der Wiederholungsversuche und Kaskaden;
- Gebühren für Werkzeuge, Suche, Stapelverarbeitung oder Hosting;
- Latenz-Perzentile; und
- Bestehensquote in der Freigabeevaluierung der Route.
Berechnen Sie jede Kandidatenroute mit den aktuellen Preisen:
monthly route cost = calls × (
input_tokens × input_price
+ cached_tokens × cached_price
+ output_tokens × output_price
) + tool_charges + hosting + expected_retry_cost
Vergleichen Sie das Ergebnis mit dem Ausgangswert nur bei Kandidaten, die dieselben Freigabekriterien für Qualität und Sicherheit erfüllen. Geben Sie die Annahmen zusammen mit dem Ergebnis an. Eine Route, die Token-Kosten spart, aber mehr manuelle Korrekturen, Vorfälle oder Latenz verursacht, kann insgesamt teurer sein.
Falls keine Telemetriedaten vorliegen, führen Sie zunächst eine parallele Evaluierung ohne Produktionswirkung durch. Leiten Sie aus einer pauschalen Aufteilung des Datenverkehrs keinen Einsparprozentsatz ab.
Die grundlegenden Orchestrierungsmuster
Einige Muster kehren in produktiven Systemen mit mehreren Modellen immer wieder:
Muster 1: Routing nach Aufgabentyp
Verschiedene Aufgabentypen werden an unterschiedliche Modelle weitergeleitet. Dies ist das einfachste Muster.
# Resolve these aliases from reviewed configuration; provider IDs change.
def route_request(task_type):
if task_type == "classification":
return SMALL_TIER
elif task_type == "extraction":
return EXTRACTION_TIER
elif task_type == "summarization":
return SUMMARY_TIER
elif task_type == "user-facing-response":
return RESPONSE_TIER
elif task_type == "complex-reasoning":
return REASONING_TIER
Die Aufgaben werden vom aufrufenden Code klassifiziert (dieser weiß, was er anfordert). Die Routing-Logik ist deterministisch und einfach zu debuggen.
Muster 2: Komplexitätsbasiertes Routing
Das System schätzt die Komplexität jeder Anfrage und leitet sie entsprechend weiter.
def route_by_complexity(request):
complexity = estimate_complexity(request)
if complexity < 3:
return "small"
elif complexity < 7:
return "mid"
else:
return "flagship"
Die Komplexität lässt sich heuristisch schätzen, etwa anhand der Anfragelänge oder bestimmter Schlüsselwörter, oder von einem günstigen Klassifizierungsmodell bewerten. Dieses Muster eignet sich für Fälle, in denen derselbe Aufgabentyp unterschiedlich schwierig sein kann.
Muster 3: Kaskadenrouting
Probieren Sie zunächst ein günstiges Modell aus. Wenn das Ergebnis zufriedenstellend ist, verwenden Sie es. Falls nicht, steigen Sie auf ein teureres Modell um.
def cascade(request):
cheap_response = call_model("small", request)
if is_acceptable(cheap_response):
return cheap_response
return call_model("flagship", request)
Dies funktioniert, wenn sich „akzeptabel“ zuverlässig erkennen lässt – anhand von Konfidenzwerten, Prüfregeln oder einem separaten LLM zur Qualitätsprüfung. Die meisten einfachen Anfragen kann dann das günstigere Modell beantworten; nur schwierige Fälle erreichen das teurere Modell.
Muster 4: Spezial-Routing
Verwenden Sie spezialisierte Modelle für spezifische Aufgaben:
- Einbettungen: Verwenden Sie ein dediziertes Einbettungsmodell (deutlich günstiger als die Verwendung eines Chat-Modells zum Erzeugen von Einbettungen).
- Neusortierung (Reranking): Verwenden Sie ein eigens dafür vorgesehenes Reranking-Modell.
- Bildverarbeitung: Verwenden Sie ein darauf spezialisiertes Modell für die Bildanalyse.
- Stimme und Audio: Verwenden Sie ein darauf spezialisiertes Modell für Transkription und Synthese.
- Code: Verwenden Sie für Programmieraufgaben ein auf Code spezialisiertes Modell.
Spezialisierte oder kleinere Modelle können bei einer engen Aufgabe schneller, günstiger oder leistungsfähiger sein, doch keine dieser Vorteile ergibt sich allein aus der Bezeichnung. Evaluieren Sie das genaue Modell, den Anbieter, den Prompt, die Sprache, das Latenz-Perzentil, die Preisliste und den Evaluierungssatz.
Muster 5: Anbieter-Routing
Nutzen Sie Modelle von mehreren Anbietern für Redundanz und Preisvorteile.
providers = ["openai", "anthropic", "google"]
preferred = "anthropic" # primary
fallback = "openai" # fallback
def call_with_failover(request):
try:
return call(preferred, request)
except (RateLimit, ProviderError):
return call(fallback, request)
Dies erhöht die Widerstandsfähigkeit gegenüber Ausfällen einzelner Anbieter und Ratenbegrenzungen. Außerdem können Sie auf Preisänderungen reagieren und nach einer Preissenkung mehr Datenverkehr zu einem Anbieter verlagern.
Ein realistisches Beispiel: KI im Kundensupport
Um es konkret zu machen: So könnte eine KI im Kundensupport die Orchestrierung mehrerer Modelle nutzen.
Das System führt folgende Schritte pro Ticket aus:
Schritt 1: Absicht klassifizieren. Worum geht es in der Kundenanfrage?
Routing-Kandidat: ein Modell mit niedriger Latenz, das beim annotierten Datensatz für Kundenabsichten die Freigabekriterien erfüllt.
Schritt 2: Dringlichkeit und Stimmung bestimmen. Ist die Kundin oder der Kunde frustriert? Ist der Fall dringend?
Routing-Kandidat: dasselbe Modell, aber nur, wenn die Falsch-negativ-Rate bei der Dringlichkeit den eigens festgelegten Sicherheitsschwellenwert erfüllt. Die erkannte Stimmung ist kein verlässlicher Ersatz für die Dringlichkeitsprüfung.
Schritt 3: Relevante Informationen abrufen.
Routing-Kandidat: eine Einbettungssuche mit anschließender Neusortierung, geprüft anhand eines ticketspezifischen Datensatzes für den Informationsabruf.
Schritt 4: Prüfen Sie, ob die KI diese Frage beantworten kann oder eine Eskalation an den Menschen erforderlich ist.
Routing-Kandidat: ein Modell, das speziell auf das Erkennen von Eskalationsfällen geprüft wurde. Regeln sollten bei Kontozugriffen, Sicherheitsfragen, rechtlichen oder finanziellen Angelegenheiten und anderen in den Richtlinien festgelegten Fällen die Übergabe an einen Menschen erzwingen.
Schritt 5 (falls die KI antworten kann): Antwortentwurf für die Kundin oder den Kunden erstellen.
Routing-Kandidat: ein hochwertigeres allgemeines Modell. Verwenden Sie die Ausgabe nur als Entwurf, bis Faktentreue, Richtlinieneinhaltung, Datenschutz und Ton die Freigabekriterien erfüllen.
Schritt 6 (falls die KI nicht antworten kann): Zusammenfassung für die zuständige Person erstellen.
Routing-Kandidat: ein kostengünstigeres Modell, dessen Zusammenfassungen das Problem, die Belege, bereits versuchte Schritte, die Einschränkungen auf Kundenseite und bestehende Unsicherheiten bewahren.
Schritt 7: Qualitätsprüfung. Erfüllt die Antwort unsere Standards?
Routing-Kandidat: deterministische Prüfungen und ein kalibriertes Bewertungsmodell. Ein solches Modell bietet keine unabhängige Garantie; lassen Sie Menschen eine Stichprobe seiner Entscheidungen prüfen.
Erfassen Sie jeden Schritt und setzen Sie in die Kostenformel oben die gemessenen Token-Verteilungen, aktuellen Preise, Eskalations- und Wiederholungsanteile sowie die Kosten der menschlichen Prüfung ein. Dieses Beispiel nennt bewusst keine pauschale Einsparung: Das Ergebnis hängt von der Zusammensetzung der Tickets und den Akzeptanzschwellen ab.
Die Routing-Logik
Einige Ansätze zur Implementierung von Routing:
Ansatz 1: Starr durch Aufgabentyp vorgegeben
Am einfachsten: Sie wissen, welche Aufgabe Sie aufrufen möchten, und wählen das Modell aus.
def classify(text):
return openai_client.chat.completions.create(
model=SMALL_TIER, # your provider's current small model
messages=[{"role": "user", "content": f"Classify: {text}"}],
)
def respond(context, query):
return claude_client.messages.create(
model=RESPONSE_TIER, # reviewed config alias, not a frozen provider ID
max_tokens=1024,
messages=[{"role": "user", "content": f"Context: {context}\n\nQuery: {query}"}]
)
Vorteile: transparent, leicht zu debuggen und leicht zu ändern. Nachteile: passt sich innerhalb eines Aufgabentyps nicht an die Schwierigkeit einzelner Anfragen an.
Ansatz 2: Router-Modell
Ein kleines Modell klassifiziert jede Anfrage und leitet sie weiter.
ROUTER_PROMPT = """
Classify this request as: trivial, moderate, or complex.
Output one word.
Request: {request}
"""
def route(request):
classification = small_model_call(ROUTER_PROMPT.format(request=request))
return MODEL_BY_COMPLEXITY[classification]
Vorteile: passt sich innerhalb einer Kategorie an die Komplexität an. Nachteile: verursacht durch den Router-Aufruf zusätzliche Latenz, schafft eine weitere Fehlerquelle und muss abgestimmt werden.
Ansatz 3: Einbettungsbasierter Router
Bei Anfragen, die bekannten Mustern entsprechen, können Sie die Ähnlichkeit ihrer Einbettungen mit früheren Beispielen nutzen.
def route(request):
embedding = embed(request)
closest = find_nearest_example(embedding)
return closest.suggested_model
Vorteile: schnell, da nur eine Vektorsuche nötig ist, und mit zusätzlichen Daten verbesserbar. Nachteile: erfordert den Aufbau eines annotierten Beispieldatensatzes.
Ansatz 4: Kaskade
Versuchen Sie es zuerst mit einem günstigeren Modell und wechseln Sie bei Bedarf zu einem leistungsfähigeren.
def cascade(request):
cheap = small_model_call(request)
if validates(cheap):
return cheap
return flagship_call(request)
Vorteile: anpassungsfähig und im Durchschnitt kostengünstig. Nachteile: langsam bei Fällen, die einen zweiten Aufruf benötigen, und auf eine verlässliche Prüfung angewiesen.
In der Praxis verwenden viele Produktivsysteme eine Mischform: fest vorgegebenes Routing für die wichtigsten Aufgabentypen und Kaskaden für bestimmte Untertypen mit stark schwankender Schwierigkeit.
Die Fallstricke
Einige Fehler, die Sie vermeiden sollten:
Fallstrick 1: Optimierung der Kosten bei gleichzeitiger Verschlechterung der Qualität
Es ist einfach, alles an kleine Modelle weiterzuleiten und den sinkenden Kosten zuzusehen. Schwerer fällt auf, wenn zugleich die Qualität nachlässt. Verknüpfen Sie Änderungen am Routing deshalb immer mit einer Qualitätsüberwachung.
Ein sinnvoller Grundsatz: Prüfen Sie eine günstigere Route parallel oder in einem A/B-Test, bis die Stichprobe wichtige Eingabeklassen und Fehlermodi abdeckt. Eine festgelegte Testdauer von einer Woche ist für sich genommen kein Beleg. Nehmen Sie die Änderung erst in den Produktivbetrieb auf, wenn die zuvor festgelegten Qualitäts- und Sicherheitskriterien erfüllt sind.
Fallstrick 2: Überkomplexität des Routers
Ein Router mit vielen Aufgabentypen und intransparenter Logik kann schwieriger zu warten sein als das Routing, das er ersetzt. Beginnen Sie mit der kleinstmöglichen Anzahl von Routen, die Ihre Messwerte rechtfertigen.
Fügen Sie eine Route nur hinzu, wenn sie eine betriebliche Entscheidung verändert und eine gemessene Anforderung so deutlich verbessert, dass sich der zusätzliche Verwaltungs- und Testaufwand sowie der nötige Ausweichpfad rechtfertigen lassen.
Fallstrick 3: Latenz ignorieren
Günstigere Modelle sind nicht zwangsläufig schneller. Messen Sie Latenz und Qualität getrennt. Eine Kaskade, die zunächst ein Modell versucht und bei Bedarf auf ein anderes ausweicht, benötigt in diesen Fällen mindestens einen zusätzlichen Aufruf und kann die Latenz in den oberen Perzentilen bei nutzerseitigen Abläufen deutlich erhöhen.
Vergleichen Sie bei einer nutzerseitigen, latenzkritischen Antwort die direkte Route und die Kaskade sowohl anhand der Bestehensquote als auch der Latenz in den oberen Perzentilen. Bei Stapelverarbeitung oder asynchronen Abläufen sind Kaskaden häufig leichter zu verkraften. Die richtige Route hängt jedoch von der konkreten Arbeitslast ab.
Fallstrick 4: Anbieterausfälle nicht berücksichtigen
Wenn Sie von mehreren Modellen abhängen, gibt es auch mehr Ausfallmöglichkeiten: Ein Spitzenmodell ist nicht verfügbar, eine Ratenbegrenzung greift oder ein API-Schlüssel läuft ab. Ihre Routing-Logik braucht klar definierte Ausweichpfade.
Definieren Sie das Verhalten bei Ratenbegrenzungen, Zeitüberschreitungen und Anbieterfehlern ausdrücklich. Ein anbieterübergreifender Ausweichpfad ist nur dann vertretbar, wenn dessen Bedingungen für die Datenverarbeitung, regionaler Verarbeitungsweg, Werkzeug- und Schemavertrag sowie Evaluierungsergebnisse akzeptabel sind. Andernfalls muss das System sicher abbrechen, den Vorgang in eine Warteschlange stellen oder an einen Menschen eskalieren. Eine deutlich schlechtere Antwort bereitzustellen, ist keine Verfügbarkeit.
Fallstrick 5: Qualität pro Route nicht messen
Sie müssen wissen, welche Route gut abschneidet und welche nicht. Das bedeutet Evaluierung, idealerweise automatisiert.
Ein sinnvoller Ansatz: Protokollieren Sie für jeden Aufruf im Produktivbetrieb das verwendete Modell, die Anfrage, die Antwort und – soweit möglich – ein Qualitätssignal wie Nutzerfeedback, nachgelagerte Kennzahlen oder eine automatisierte Evaluierung. Fassen Sie die Kennzahlen je Route zusammen, damit Qualitätsabweichungen auffallen, bevor sich Nutzerinnen und Nutzer beschweren.
Live-Abhängigkeiten erneut validieren
Modell-IDs, Abkündigungstermine, Kontextgrenzen, Preise, Ratenbegrenzungen, regionale Verarbeitung sowie die Semantik strukturierter Ausgaben und Werkzeuge können sich unabhängig voneinander ändern. Prüfen Sie die aktuelle Anbieterdokumentation und wiederholen Sie die Evaluierung der Routen, bevor Sie einen Alias ändern. Ein OpenAI-kompatibler Transport garantiert weder gleichwertige Schemata noch dasselbe Werkzeugverhalten, dieselbe Token-Abrechnung, dieselben Sicherheitsrichtlinien oder dieselbe Datenverarbeitung.
Eine erste Checkliste
Wenn Sie ein Multi-Modell-System von Grund auf neu entwickeln oder eine Migration von einem einzelnen Modell durchführen:
-
Erfassen Sie Ihre Aufgaben. Welche Arten von LLM-Aufrufen führt Ihre Anwendung aus? Wie häufig ungefähr und zu welchen ungefähren Kosten?
-
Ordnen Sie sie nach Komplexität ein. Entscheiden Sie für jeden Aufgabentyp, ob er einfach, mittel oder komplex ist, und weisen Sie ihm eine passende Modellklasse zu.
-
Erstellen Sie einen Router. Beginnen Sie mit einer fest vorgegebenen, aufgabenbasierten Routing-Logik und halten Sie sie zunächst einfach.
-
Definieren Sie das Fehlerverhalten. Nutzen Sie je nach möglichen Folgen und Datenrichtlinie einen getesteten Ausweichpfad, eine Warteschlange, einen sicheren Abbruch oder die Übergabe an einen Menschen.
-
Messen Sie die Qualität jeder Route. Richten Sie Protokollierung und eine grundlegende Evaluierung ein. Sie müssen erkennen können, ob die Qualität erhalten bleibt.
-
Verbessern Sie schrittweise. Verlegen Sie Aufgaben zu günstigeren Modellen, solange die Qualität erhalten bleibt. Wechseln Sie wieder zu leistungsfähigeren Modellen, wenn die Qualität einbricht, und passen Sie das Routing fortlaufend an.
-
Überprüfen Sie das System regelmäßig. Modelle ändern sich, neue kommen hinzu und Preise verschieben sich. Eine Routing-Konfiguration, die im Mai 2026 optimal ist, kann im November 2026 bereits ungeeignet sein.
Nutzen Sie Routing nur, wenn die Belege dafür sprechen
Die Orchestrierung mehrerer Modelle kann Kosten oder Latenz verringern, wenn sich die Aufruftypen tatsächlich unterscheiden und jede Route geprüft wird. Sie kann aber auch die Betriebskosten erhöhen und die Konsistenz verschlechtern. Veröffentlichen Sie statt einer pauschalen Einsparungsbehauptung den gemessenen Ausgangswert, das Ergebnis mit Routing, die Qualitätskriterien und den Zeitraum der Stichprobe.
Die eigentliche Routing-Bedingung kann kurz sein. Die Arbeit für den Produktivbetrieb umfasst die kontrollierte Konfiguration, Evaluierung, Beobachtbarkeit, Datenschutzprüfung, Logik für Wiederholungsversuche und Ausweichpfade.
Erfassen Sie Ihre Aufgaben, prüfen Sie geeignete Kandidaten und leiten Sie nur dort an ein anderes Modell weiter, wo die Belege dies rechtfertigen. Messen Sie auch nach der Freigabe kontinuierlich weiter.
