Der teuerste Einzelfehler, den wir bei KI-Systemen im Produktivbetrieb beobachten, ist die Verwendung eines einzigen Modells für alle Aufgaben.
Ein Team wählt ein Spitzenmodell wie GPT-5.5 oder Claude Opus 4.8 und baut seine Anwendung darum herum. Die monatlichen Rechnungen liegen im fünfstelligen Bereich. Werden verschiedene Anfragen an unterschiedliche Modellstufen geleitet, sinkt die Rechnung meist erheblich – im unten modellierten Beispiel um etwa 70–75 % – und oft verbessert sich zugleich die Latenz.
Das ist Multi-Modell-Orchestrierung: Für jede Aufgabe eines Systems wird das passende Modell eingesetzt. Darin liegt ein wesentlicher Unterschied zwischen einer KI-Bastellösung und einem produktionsreifen KI-System.
Dieser Artikel behandelt die Muster, die Routing-Logik, die Kompromisse und einen Schritt-für-Schritt-Leitfaden zur Umsetzung.
Warum ein einziges Modell nicht optimal ist
Die Modelle, die 2026 auf dem Markt sind, lassen sich grob in folgende Stufen einteilen:
Spitzenklassen für Reasoning (die Denkmodi von GPT-5.5, Claude Opus 4.8 und Gemini 3.1 Pro sowie DeepSeek R1): hervorragend bei komplexen Schlussfolgerungen, teuer ($3–30 pro Million Eingabetoken und $15–50 pro Million Ausgabetoken bei den gängigen Spitzenmodellen; spezialisierte Pro-Stufen liegen noch deutlich höher) und langsamer (typischerweise 5–30 Sekunden).
Allgemeine Spitzenmodelle (GPT-5.5, Claude Sonnet 5, Gemini 3.1 Pro): hervorragend für die meisten Wissensarbeiten, moderat teuer ($2–5 pro Million Eingabetoken und $12–30 pro Million Ausgabetoken) und angemessen schnell (2–5 Sekunden).
Modelle der mittleren Klasse (Claude Haiku 4.5, Gemini 3.5 Flash und OpenAIs mittlere Modellklasse): gut für einfache bis mittelschwere Aufgaben, günstig ($1–2.50 pro Million Eingabetoken und $5–15 pro Million Ausgabetoken) und schnell (1–2 Sekunden).
Kleine Modelle (die derzeit kleinsten Klassen der Anbieter, z. B. Gemini 3 Flash Preview, sowie kleine Open-Source-Modelle): gut für einfache strukturierte Aufgaben, sehr günstig ($0.50–1 pro Million Eingabetoken) und sehr schnell (<1 Sekunde).
Spezialisierte Modelle (Embedding-, Reranking-, Bildverarbeitungs- und Sprachmodelle): für bestimmte Aufgaben optimiert und aufgrund dieser Spezialisierung oft sehr günstig.
(Preise überprüft am 07.07.2026 anhand der Preislisten der Anbieter; vor Zitaten erneut prüfen.)
Eine typische KI-Anwendung macht viele verschiedene Arten von LLM-Aufrufen. Jeder Aufruf hat seine eigenen Anforderungen:
- Klassifizieren der Nutzerabsicht: erfordert eine einfache Klassifizierung und eine schnelle Antwort. Ein Modell der mittleren Klasse ist ideal.
- Extrahieren strukturierter Daten aus Dokumenten: erfordert zuverlässige strukturierte Ausgaben bei mittlerer Komplexität. Modelle der mittleren Klasse oder allgemeine Spitzenmodelle.
- Erzeugen der eigentlichen Antwort auf eine Nutzeranfrage: benötigt hohe Qualität und gute Kontextverarbeitung. Allgemeines Spitzenmodell oder Reasoning-Spitzenmodell.
- Erzeugen von Zusammenfassungen früherer Gespräche: eine einfache Zusammenfassungsaufgabe. Modelle der mittleren Klasse oder kleine Modelle.
- Batch-Verarbeitung im Hintergrund: nicht latenzkritisch, aber vom Volumen abhängig. Kleine Modelle oder Modelle der mittleren Klasse.
Ein Spitzenmodell für all diese Aufgaben einzusetzen, ist verschwenderisch. Weder die Klassifizierung noch die Zusammenfassung benötigen es; auch die strukturierte Extraktion kommt häufig ohne ein solches Modell aus. Nur die Antwort, die der Nutzer tatsächlich sieht, profitiert eindeutig davon.
Die Kostenersparnisse sind real
Bei einer typischen KI-Anwendung für Wissensarbeit könnten sich die Anfragen wie folgt verteilen:
- 60 % der LLM-Aufrufe: einfache Klassifizierung, Extraktion, Zusammenfassung. Bestens durch mittlere oder kleine Modelle abgedeckt.
- 30 % der Aufrufe: mittlere Komplexität. Modelle der mittleren Klasse oder allgemeine Spitzenmodelle.
- 10 % der Aufrufe: komplexe Schlussfolgerungen oder die endgültige Nutzerantwort. Spitzenmodell.
Wenn Sie für alles ein Spitzenmodell verwenden, entstehen 100 % der Kosten dieses Spitzenmodells. Bei einem angemessenen Routing ergibt sich:
- 60 % zu den Kosten eines kleinen Modells (1/30 der Kosten des Spitzenmodells): 2 % der ursprünglichen Kosten.
- 30 % zu den Kosten eines Modells der mittleren Klasse (1/5 der Kosten des Spitzenmodells): 6 % der ursprünglichen Kosten.
- 10 % zu den Kosten des Spitzenmodells: 10 % der ursprünglichen Kosten.
Insgesamt: 18 % der ursprünglichen Kosten, also eine Reduktion um 82 %. Bei einer monatlichen Rechnung von €10.000 sparen Sie €8.200 pro Monat.
Die konkreten Zahlen hängen von der Zusammensetzung Ihres Datenverkehrs ab, doch das Muster bleibt gleich: Bei den meisten Anwendungen kann der durchschnittliche Aufruf wesentlich günstiger sein als der teuerste Aufruf. Routing erschließt dieses Einsparpotenzial.
Die grundlegenden Orchestrierungsmuster
Einige Muster treten in produktiven Multi-Modell-Systemen immer wieder auf:
Muster 1: Aufgabenbasiertes Routing
Verschiedene Arten von Aufgaben werden an verschiedene Modelle weitergeleitet. Dies ist das einfachste Muster.
# Model IDs verified 2026-07-07; SMALL_TIER is your provider's current
# small model — check the live model list rather than hard-coding blindly.
def route_request(task_type):
if task_type == "classification":
return SMALL_TIER
elif task_type == "extraction":
return "claude-haiku-4-5"
elif task_type == "summarization":
return "claude-haiku-4-5"
elif task_type == "user-facing-response":
return "claude-sonnet-5"
elif task_type == "complex-reasoning":
return "claude-opus-4-8"
Der aufrufende Code klassifiziert die Aufgaben, da er weiß, was er anfordert. Das Routing ist deterministisch und leicht zu debuggen.
Muster 2: Komplexitätsbasiertes Routing
Das System schätzt die Komplexität jeder Anfrage und leitet 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 von Schlüsselwörtern – oder modellbasiert, indem ein kostengünstiger Klassifikator die Anfrage bewertet. Dieses Muster eignet sich für Fälle, in denen ein und derselbe Aufgabentyp unterschiedlich schwierig sein kann.
Muster 3: Kaskaden-Routing
Zunächst wird ein kostengünstiges Modell aufgerufen. Ist dessen Ausgabe ausreichend gut, wird sie verwendet; andernfalls eskaliert das System an ein teureres Modell.
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, Validatoren oder einem separaten LLM zur Qualitätsprüfung. Das Muster ist wirkungsvoll: Die meisten einfachen Anfragen beantwortet das kostengünstige Modell; nur schwierige Fälle erreichen das teure Modell.
Muster 4: Spezialisiertes Routing
Für spezialisierte Aufgaben werden spezialisierte Modelle verwendet:
- Embeddings: ein dediziertes Embedding-Modell verwenden (wesentlich günstiger als ein Chatmodell, das Embeddings erzeugen soll).
- Reranking: einen dedizierten Reranker verwenden.
- Bild: ein für Bildanalysen spezialisiertes Modell verwenden.
- Sprache und Audio: ein spezialisiertes Sprachmodell für Transkription oder Sprachsynthese verwenden.
- Code: ein für Code-Aufgaben spezialisiertes Modell verwenden.
Spezialisierte Modelle sind bei ihrer jeweiligen Aufgabe meist schneller, günstiger und leistungsfähiger als ein allgemeines Modell.
Muster 5: Anbieterbasiertes Routing
Modelle von mehreren Anbietern verwenden, um Redundanz und Preisvorteile zu nutzen.
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 Ausfallsicherheit bei Störungen oder Rate-Limits eines einzelnen Anbieters. Zudem können Sie Preisänderungen nutzen: Senkt ein Anbieter seine Preise, lässt sich mehr Datenverkehr dorthin verlagern.
Ein realistisches Beispiel: KI für Kundensupport
Das folgende konkrete Beispiel zeigt, wie ein KI-System für den Kundensupport Multi-Modell-Orchestrierung einsetzen könnte.
Das System durchläuft pro Ticket folgende Schritte:
Schritt 1: Absicht klassifizieren. Worum geht es dem Kunden? (5–10 Kategorien.)
Routing: ein Modell der kleinen Klasse. Es handelt sich um eine einfache Klassifizierungsaufgabe. Kosten: ~$0.0005 pro Ticket (≈500 Token zu den Preisen der kleinen Modellklasse).
Schritt 2: Dringlichkeit und Stimmung bestimmen. Ist der Kunde frustriert? Ist dies dringend?
Routing: dasselbe kleine Modell. Eine weitere einfache Klassifizierung. Kosten: ~$0.0005 pro Ticket.
Schritt 3: Relevantes Wissen abrufen.
Routing: Embedding-Modell plus Reranking-Modell. Spezialisierte Werkzeuge für spezialisierte Aufgaben. Kosten: ~$0.002 pro Ticket (Reranking dominiert mit ~$2 pro 1.000 Suchvorgänge).
Schritt 4: Bestimmen, ob die KI antworten kann oder ob ein Mensch eingeschaltet werden muss.
Routing: Claude Haiku 4.5. Aufgrund des abgerufenen Kontexts ist die Klassifizierung etwas anspruchsvoller. Kosten: ~$0.002 pro Ticket (≈2K Kontexttoken).
Schritt 5 (wenn die KI antworten kann): Antwort für den Kunden erzeugen.
Routing: Claude Sonnet 5. Hier zählt die Qualität, denn diese Antwort liest der Kunde. Kosten: ~$0.015 pro Ticket (≈3K Eingabe / 400 Ausgabe).
Schritt 6 (wenn die KI nicht antworten kann): Zusammenfassung für den menschlichen Agenten generieren.
Routing: ein Modell der mittleren Klasse. Die Zusammenfassung muss nützlich sein, ist aber nicht für den Kunden bestimmt. Kosten: ~$0.004 pro Ticket.
Schritt 7: Qualität prüfen. Hat die Antwort unsere Standards erfüllt?
Routing: Claude Haiku 4.5 als schnelles Bewertungsmodell. Kosten: ~$0.002 pro Ticket.
Diese Zahlen beruhen auf einer Modellrechnung. Die angenommenen Tokenmengen sind für jeden Schritt angegeben, damit Sie die Rechnung mit Ihrem eigenen Datenverkehr wiederholen können.
Für Tickets, die die KI beantwortet (angenommen 70 %): ~$0.022 pro Ticket. Für Tickets, die an Menschen eskaliert werden (30 %): ~$0.009 pro Ticket. Gewichteter Durchschnitt: ~$0.018 pro Ticket.
Würden stattdessen alle Schritte mit einem Reasoning-Spitzenmodell ausgeführt (gleiche Tokenmengen zu ~$5/M Eingabe und $25/M Ausgabe), lägen die Kosten bei ungefähr $0.06–0.08 pro Ticket. Der Multi-Modell-Ansatz senkt die Rechnung um etwa 70–75 %.
Bei 1.000 Tickets pro Tag entspricht das einer Einsparung von ~$50 pro Tag und damit ungefähr $18.000 pro Jahr. Das ist erheblich; der größere betriebliche Vorteil ist jedoch meist die Latenz: Die geroutete Pipeline beantwortet einfache Tickets in einer statt in dreißig Sekunden.
Die Routing-Logik
Einige Ansätze zur Umsetzung des Routings:
Ansatz 1: Fest im Code nach Aufgabentyp
Einfachste Lösung. Sie wissen, welche Aufgabe Sie aufrufen, und wählen das Modell.
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="claude-sonnet-5", # ID verified 2026-07-07
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 nicht an unterschiedliche Schwierigkeitsgrade innerhalb eines Aufgabentyps 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 an die Komplexität innerhalb einer Kategorie an. Nachteile: erzeugt zusätzliche Latenz durch den Router-Aufruf, schafft eine weitere Fehlerquelle und muss abgestimmt werden.
Ansatz 3: Embedding-basierter Router
Für Anfragen, die in bekannte Muster fallen, wird die Ähnlichkeit zu früheren Beispielen verwendet.
def route(request):
embedding = embed(request)
closest = find_nearest_example(embedding)
return closest.suggested_model
Vorteile: schnell, da nur eine Vektorsuche nötig ist; verbessert sich mit wachsender Datenbasis. Nachteile: erfordert den Aufbau eines annotierten Beispieldatensatzes.
Ansatz 4: Kaskade
Zuerst ein kostengünstiges Modell ausprobieren und bei Bedarf eskalieren.
def cascade(request):
cheap = small_model_call(request)
if validates(cheap):
return cheap
return flagship_call(request)
Vorteile: adaptiv und mit niedrigen Durchschnittskosten. Nachteile: bei Fällen, die eskaliert werden müssen, langsam (zwei Aufrufe); erfordert eine zuverlässige Validierung.
In der Praxis verwenden viele Produktivsysteme eine Mischform: fest codiertes Routing für die wichtigsten Aufgabentypen und Kaskaden für bestimmte Untertypen mit stark schwankender Schwierigkeit.
Die Fallstricke
Einige Fehler, die vermieden werden sollten:
Fallstrick 1: Kostenoptimierung auf Kosten der Qualität
Es ist einfach, alles an kleine Modelle zu leiten und zuzusehen, wie die Kosten sinken. Schwieriger ist zu erkennen, dass zugleich die Qualität nachlässt. Verbinden Sie Routing-Änderungen deshalb immer mit einer Qualitätsüberwachung.
Eine nützliche Regel: Wenn Sie eine Aufgabe auf ein günstigeres Modell verlagern, führen Sie eine Woche lang einen A/B-Test mit Qualitätsmetriken durch. Nehmen Sie die Änderung erst produktiv, wenn belegt ist, dass die Qualität erhalten bleibt.
Fallstrick 2: Überkonstruktion des Routers
Ein Router, der 100 Aufgabentypen mit komplexer Logik verarbeitet, kann schwerer zu warten sein als das Routing, das er ersetzt. Beginnen Sie einfach. Erreicht die einfache Variante 80 % der Leistung der komplexen, führen Sie die einfache Variante ein.
Ein typisches Muster: Ein Router mit 50 Codezeilen für 5–10 Aufgabentypen erschließt 90 % des Nutzens. Danach nimmt der zusätzliche Ertrag ab.
Fallstrick 3: Latenz ignorieren
Günstigere Modelle sind in der Regel auch schneller, was von Vorteil ist. Bei einer Kaskade – zuerst günstig, dann Spitzenmodell – kann sich die Latenz in schwierigen Fällen jedoch verdoppeln. Bei Abläufen mit direkter Nutzerinteraktion ist das relevant.
Ein nützliches Muster: Verwenden Sie für nutzerseitige, latenzkritische Antworten standardmäßig ein Spitzenmodell und akzeptieren Sie die Kosten. Nutzen Sie Kaskaden stattdessen für Batch- oder asynchrone Verarbeitung.
Fallstrick 4: Anbieterausfälle nicht abfangen
Wenn Sie von mehreren Modellen abhängen, entstehen auch mehrere Ausfallmöglichkeiten: Ein Spitzenmodell ist nicht verfügbar, ein Rate-Limit wird erreicht oder ein API-Schlüssel läuft ab. Ihre Routing-Logik benötigt Ausweichpfade.
Mindestanforderung: Für jedes „primäre“ Modell muss ein Ausweichmodell eines anderen Anbieters vorhanden sein. Selbst wenn die Qualität im Ausweichbetrieb sinkt, bleibt das System verfügbar.
Fallstrick 5: Qualität nicht pro Route messen
Sie müssen wissen, welche Route gut funktioniert und welche nicht. Dafür ist eine möglichst automatisierte Evaluation erforderlich.
Eine sinnvolle Einrichtung: Protokollieren Sie bei jedem Produktivaufruf das verwendete Modell, die Anfrage, die Antwort und – soweit möglich – ein Qualitätssignal wie Nutzerfeedback, nachgelagerte Kennzahlen oder eine automatisierte Bewertung. Aggregieren Sie die Kennzahlen nach Route. So erkennen Sie Qualitätsdrift, bevor Nutzer sich beschweren.
Wohin dies führt
Mit folgenden Trends ist zu rechnen:
Auto-Routing als Dienst. Tools wie OpenRouter, Helicone, Portkey und andere bieten zunehmend „intelligentes Routing“ an: Sie wählen das Modell anhand konfigurierbarer Regeln aus. Diese Angebote dürften deutlich ausreifen.
Zunehmende Spezialisierung einzelner Modelle. Es entstehen Modelle für Code, Mathematik und bestimmte Fachgebiete. Das Routing wird solche spezialisierten Modelle zunehmend einbeziehen.
Weiter sinkende Kosten. Modelle mit vergleichbarer Qualität sind 2026 zehnmal günstiger als 2024. Bis 2028 ist eine weitere Senkung um den Faktor 10 zu erwarten. Die Wirtschaftlichkeit der Multi-Modell-Orchestrierung verbessert sich dadurch weiter.
Lokale Modellklassen auf Endgeräten. Smartphones und Laptops mit lokalen KI-Fähigkeiten bieten für manche Anfragen eine „kostenlose“ Stufe. Routing-Regeln werden zunehmend vorsehen, Anfragen nach Möglichkeit auf dem Gerät zu verarbeiten.
Anbieterübergreifend standardisierte APIs. OpenAI-kompatible APIs sind bereits weit verbreitet und erleichtern den Anbieterwechsel zunehmend. Weitere Standardisierung wird Strategien mit mehreren Anbietern vereinfachen.
Eine Checkliste für den Einstieg
Wenn Sie ein Multi-Modell-System von Grund auf bauen oder von einem Einzelmodell migrieren:
-
Erfassen Sie Ihre Aufgaben. Welche Arten von LLM-Aufrufen führt Ihre Anwendung aus? Wie häufig und wie teuer sind sie ungefähr?
-
Kategorisieren Sie nach Komplexität. Ordnen Sie jeden Aufgabentyp als trivial, mittelschwer oder komplex ein und weisen Sie ihm eine passende Modellklasse zu.
-
Bauen Sie einen Router. Beginnen Sie mit einem fest codierten, aufgabenbasierten Routing. Vermeiden Sie unnötige Komplexität.
-
Fügen Sie Fallbacks hinzu. Jedes primäre Modell sollte einen Fallback (anderer Anbieter) haben.
-
Messen Sie die Qualität pro Route. Richten Sie Protokollierung und eine grundlegende Evaluation ein. Sie müssen erkennen können, ob die Qualität erhalten bleibt.
-
Iterieren Sie. Verlagern Sie Aufgaben auf günstigere Modelle, solange die Qualität stabil bleibt. Wechseln Sie zurück zu teureren Modellen, wenn sie einbricht. Passen Sie das Routing fortlaufend an.
-
Optimieren Sie kontinuierlich. Modelle ändern sich, neue erscheinen und Preise verschieben sich. Eine Routing-Konfiguration, die im Mai 2026 optimal ist, kann im November 2026 bereits suboptimal sein.
Nutzen Sie nicht ein einziges Modell für alles
Multi-Modell-Orchestrierung gehört zu den Änderungen mit dem höchsten ROI, die Sie an einem produktiven KI-System vornehmen können. Richtig umgesetzt, senkt sie die Kosten um 60–90 % und verbessert häufig zugleich die Qualität, weil für jede Aufgabe ein geeignetes Modell eingesetzt wird.
Die technische Hürde ist niedrig: Eine grundlegende Routing-Logik umfasst nur wenige Dutzend Codezeilen. Höher ist die organisatorische Hürde, denn Sie müssen die Qualität kontinuierlich messen, damit Ihre Routing-Entscheidungen dauerhaft tragfähig bleiben.
Verwenden Sie nicht länger ein einziges Modell für alles. Erfassen Sie Ihre Aufgaben, wählen Sie für jede das passende Modell, messen Sie die Ergebnisse und iterieren Sie. Die Einsparungen sind real; Qualitätsverbesserungen kommen häufig als zusätzlicher Vorteil hinzu.
