Modellorchestrierung: Wie KI-Systeme Modelle auswählen und kombinieren | Bibliothek

Goldene Regel: Orchestriere Modelle nicht, weil es klug klingt. Tu es, wenn verschiedene Aufgaben nachweislich unterschiedliche Anforderungen haben und du messen kannst, wann der günstigere Pfad reicht, wann er an einen stärkeren Pfad übergeben muss und wann das System stoppen soll.

Was es ist und was nicht

Modellorchestrierung ist die operative Schicht, die für jeden Teil einer Aufgabe Modell, Konfiguration und nächsten Schritt auswählt. Sie kann zwischen einem kleinen schnellen Modell, einem teureren Frontier-Modell, einem lokalen Modell und deterministischem Code entscheiden. Sie setzt Grenzen für Budget und Latenz und berücksichtigt Datensensibilität, Ergebnisqualität und Fehlerbehandlung.

Sie ist kein anderes Wort für ein Multi-Agenten-System. Ein fester Workflow kann drei Modelle verwenden und trotzdem ein fester Workflow bleiben. Sie ist auch kein universeller Proxy, der lediglich Endpoint-Namen austauscht. Modelle unterscheiden sich bei Tool-Nutzung, Kontextgrenzen, strukturierten Ausgaben, Sicherheitsverhalten und Fehlermustern. Und sie ist kein Grund, einen einfachen Prompt auf fünf Modelle zu verteilen.

Beginne mit einer Baseline aus einem sinnvoll gewählten Modell. Füge Orchestrierung erst hinzu, wenn Logs ein konkretes Problem zeigen: Routineaufgaben sind unnötig teuer, eine Aufgabenklasse funktioniert schlecht, bestimmte Daten müssen lokal bleiben oder das Ergebnis braucht eine unabhängige Prüfung.

Entscheidungsbaum für das Routing

Ein Router muss nicht als weiteres LLM beginnen. Die erste Version ist als kleine Regelmenge oft leichter zu verstehen:

Ist die Aufgabe deterministisch?
├─ ja → Code, SQL, Suche oder Validator ohne LLM
└─ nein
   Müssen die Daten in einer Region oder auf einem Gerät bleiben?
   ├─ ja → lokales oder für die Region zugelassenes Modell
   └─ nein
      Ist das Ergebnis unumkehrbar oder mit hohem Risiko verbunden?
      ├─ ja → stärkeres Modell + Prüfung + möglicherweise Mensch
      └─ nein
         Besteht das günstigere Modell die Evals für diese Aufgabenklasse?
         ├─ ja → günstigeres Modell
         └─ nein → stärkeres Modell

Nach jedem Schritt:
- Schema- oder Tool-Fehler → einmal reparieren, dann übergeben
- geringe überprüfbare Sicherheit → Retrieval, stärkeres Modell oder Mensch
- Timeout oder Provider-Ausfall → kompatibler Ersatzpfad
- Sicherheitsproblem → stoppen statt improvisieren

Routing-Signale sollten vor dem Aufruf des teuren Modells vorliegen: Anfragetyp, Sprache, Eingabegröße, Datenquelle, benötigte Tools, Tenant, SLA und Risikoklasse. Die Selbsteinschätzung des Modells kann ein Signal sein, aber nicht der einzige Beleg. Ein Modell kann den eigenen Fehler sehr selbstbewusst freigeben.

Ein praktischer Architekturplan

Eine brauchbare Architektur hat wenige, dafür explizite Schichten:

Eingabenormalisierung entfernt unnötige Daten, ordnet den Tenant zu und erzeugt eine Lauf-ID.
Policy Gate bestimmt erlaubte Provider und Regionen, Datenklassifizierung, Maximalkosten und zustimmungspflichtige Aktionen.
Router wählt anhand versionierter Regeln oder eines Klassifikators einen Pfad und liefert den Entscheidungsgrund.
Modelladapter übersetzt das interne Nachrichten-, Tool- und Ausgabeformat in die API des Providers.
Executor führt Modelle und Tools mit Timeout, Schrittlimit und Idempotenzschlüssel aus.
Verifier prüft Schema, Quellen, Geschäftsregeln oder ein anderes maschinell überprüfbares Ergebnis.
Handoff Controller entscheidet über Reparatur, Eskalation, Modellwechsel, menschliche Prüfung oder Abbruch.
Observability und Eval Store speichern Prompt-Version, Modell, Routing-Grund, Latenz, Kosten, Prüfergebnis und Endstatus.

Die Domänenlogik sollte keine Provider-Namen kennen. Ein kompakter interner Vertrag kann task, risk, data_class, allowed_tools, output_schema und budget enthalten. Adapter behandeln die Unterschiede. Die Abstraktion darf jedoch nicht alles auf den kleinsten gemeinsamen Nenner reduzieren. Verbessert eine besondere Fähigkeit eines Modells das Ergebnis messbar, sollte sie über ein explizites Capability-Flag verfügbar sein, mit einem gepflegten Ersatzpfad.

Handoffs und Fallbacks ohne stilles Chaos

Ein Handoff übergibt die Arbeit aus einem sachlichen Grund an einen anderen Pfad: Die Eingabe war schwieriger als erwartet, die Prüfung ist fehlgeschlagen oder eine andere Fähigkeit wird benötigt. Übergib strukturierten Zustand, nicht das vollständige rohe Gespräch. Das nächste Modell braucht das ursprüngliche Ziel, geprüfte Fakten, Tool-Ergebnisse, bisherige Fehler und das verbleibende Budget.

Ein Fallback behandelt Nichtverfügbarkeit oder ein bekanntes Fehlermuster. Die Reihenfolge muss vorher feststehen. Beispiel: dasselbe Modell nur bei einem vorübergehenden Netzwerkfehler erneut aufrufen; eine Schemaabweichung reparieren; nach einer fehlgeschlagenen Faktenprüfung ein stärkeres Modell verwenden; bei Ausfall den Provider wechseln; für eine unumkehrbare Aktion einen Menschen einschalten. Eine endlose Retry-Kette ist keine Resilienz, sondern eine versteckte Rechnung.

Jeder Übergang muss die Sicherheitsrichtlinie erhalten. Das Ersatzmodell darf keine Daten bekommen, die das primäre Modell wegen Standortvorgaben nicht erhalten durfte. Ein Fallback darf aus „Freigabe erforderlich“ nicht „automatisch versuchen“ machen.

Evals und Kosten pro Erfolg

Der Preis pro Million Token ist eine Einkaufsinformation, keine Systemmetrik. Entscheidend sind die Kosten pro erfolgreich abgeschlossener Aufgabe:

Gesamtkosten + Retrieval + Tools + Prüfung + menschliche Korrektur
──────────────────────────────────────────────────────────────────
Anzahl der Aufgaben, die das definierte Erfolgskriterium erfüllen

Das Eval-Set sollte echte Aufgabenklassen, Grenzfälle, lange Eingaben, mehrere Sprachen und Sicherheitsszenarien enthalten. Miss für jeden Pfad Erfolgsquote, Latenz, Versuche, Handoff-Häufigkeit, menschliche Eingriffe und Fehlertypen. Vergleiche den Orchestrator mit einer Ein-Modell-Baseline. Ein nur auf Kosten optimierter Router lernt, billig zu scheitern; ein nur auf Durchschnittsqualität optimierter Router schickt alles an das Frontier-Modell.

Ändere jeweils nur eine Routing-Entscheidung und spiele dasselbe Eval-Set erneut durch. Überwache die Produktion separat, denn ein anderer Anfragemix kann eine alte Richtlinie entwerten. Öffentliche Benchmarks sind kein Beleg für dein Produkt. Entscheidend ist die Leistung bei deinen Aufgaben und nach deiner Erfolgsdefinition.

Sicherheit und Datenlokalität

Der Router ist sicherheitskritische Infrastruktur. Er sieht die Metadaten, nach denen über den Datenweg entschieden wird. Die Klassifizierung muss daher vor der Provider-Auswahl stattfinden und durch eine Policy-Schicht erzwungen werden, nicht nur im Prompt stehen.

Dokumentiere für jedes Modell zugelassene Regionen, Aufbewahrungsbedingungen, Nutzung für Training, unterstützte Verschlüsselung, Auditfunktionen und erlaubte Tools. Minimiere oder entferne personenbezogene Daten und Geheimnisse vor jedem Modellaufruf. Logs dürfen nicht durch Speicherung des vollständigen Prompts ein neues Leck erzeugen. Halte Tool-Zugangsdaten außerhalb des Modellkontexts und autorisiere jedes Tool für den konkreten Lauf.

Ein lokales Modell ist nicht automatisch sicher und ein Cloud-Modell nicht automatisch unsicher. Der gesamte Fluss zählt: wo die Inferenz läuft, wohin Telemetrie geht, was im Cache bleibt, wer Logs lesen kann und ob Aktionen auditierbar sind.

Häufige Fehler

Routing nach Gefühl: „schwierige“ Aufgaben sind nicht definiert. Lösung: Aufgabentaxonomie, Eval-Set und versionierte Richtlinie.
Frontier-Modell für alles: Premiumqualität wird auch dort angenommen, wo sie nichts verbessert. Lösung: günstigere Baseline und Kosten pro Erfolg messen.
Billigstes Modell für alles: Einsparungen verschwinden in Retries und menschlichen Korrekturen. Lösung: den gesamten Lauf zählen.
Stiller Fallback: Ein Vorfall sieht wie ein Erfolg aus. Lösung: Grund, Pfad und Endstatus protokollieren und eingeschränkten Betrieb anzeigen.
Zustandsverlust beim Handoff: Das zweite Modell wiederholt Arbeit oder glaubt einer ungeprüften Behauptung. Lösung: strukturiertes Übergabepaket.
Das Modell bewertet sich selbst: Derselbe blinde Fleck besteht zweimal. Lösung: deterministische Prüfung, unabhängiger Bewerter oder Mensch je nach Risiko.
Die Abstraktion besitzt den Workflow: Das Produkt hängt an einem visuellen Agent Builder, dessen Speicher und proprietären Tool-Definitionen. Verschwindet der Dienst, verschwindet auch der Ausweg. Lösung: Zustand, Prompts, Schemata, Evals und Regeln im eigenen versionierten Format halten.
Provider-Wechsel ohne Evals: Kompatibles JSON bedeutet kein kompatibles Verhalten. Lösung: repräsentative Aufgaben vor dem Wechsel erneut ausführen.

Konkretes Beispiel: Kundensupport vorsortieren

Ein Unternehmen erhält Support-E-Mails in mehreren Sprachen. Das System soll eine Kategorie zuweisen, passende Dokumentation finden und einen Antwortentwurf erstellen. Vertragsänderungen und Erstattungen brauchen einen Menschen.

Code entfernt Signaturen, erkennt Anhänge und markiert personenbezogene Daten.
Ein kleines lokales Modell klassifiziert Sprache, Thema und Risiko in ein festes JSON-Schema.
Das Policy Gate verhindert, dass sensible Anhänge externe APIs erreichen. Für normale Fragen erlaubt es einen zugelassenen Cloud-Provider.
Ein günstigeres Modell bekommt die gefundenen Artikel und erstellt einen Entwurf mit Quellenangaben.
Der Verifier prüft, ob zitierte Dokumente existieren, die Antwort kein unzulässiges Versprechen enthält und jede Produktaussage belegt ist.
Ein Schemafehler erhält einen gezielten Reparaturversuch. Bei sachlicher Abweichung bekommt ein stärkeres Modell Ziel, Quellen und Prüfergebnis. Ein Hochrisikofall geht direkt an einen Menschen.
Das System speichert Pfad, Grund, Gesamtkosten und ob der Mensch den Entwurf angenommen, bearbeitet oder abgelehnt hat.

Nach mehreren Eval-Zyklen kann das Team feststellen, dass das günstigere Modell Routinefragen sicher bearbeitet, bei unklaren Beschwerden aber häufig eine Reparatur braucht. Der Router eskaliert dann nicht nach E-Mail-Länge, sondern nach einer Kombination aus Thema, Risiko und Retrieval-Ergebnis. Das ist evidenzbasierte Orchestrierung statt Markenhierarchie.

Quellen

Building effective agents (Anthropic) - praktische Abgrenzung einfacher Workflows von agentischen Systemen und ein starkes Argument für den einfachsten funktionierenden Entwurf.
RouteLLM (LMSYS) - Forschung zu Routern, die je nach Anfrage zwischen einem stärkeren und einem günstigeren Pfad wählen.
FrugalGPT (Stanford University) - frühe Arbeit zu Modellkaskaden, Budgets und der Optimierung von Qualität gegenüber Kosten.
NIST AI Risk Management Framework - Rahmenwerk zum Erfassen, Messen und Steuern von KI-Risiken einschließlich operativer Verantwortung.
OWASP Top 10 for LLM Applications - Katalog von Angriffen und Betriebsrisiken, die Router, Tools und Fallbacks berücksichtigen müssen.
OpenAI Evals - offenes Framework und Beispiele zur Beschreibung von Eval-Aufgaben und zum Vergleich von Modellverhalten.

Das Wichtigste

Orchestrierung ist keine Modellsammlung. Sie ist die Kontrollschicht für Entscheidungen, Übergaben, Prüfung und Abbruch. Beginne mit einem Modell und einer messbaren Baseline. Route anhand von Belegen, nicht nach Markenprestige. Zähle Kosten pro Erfolg einschließlich Retries und menschlicher Arbeit. Erzwinge die Sicherheitsrichtlinie vor dem Modell und erhalte sie bei Fallbacks. Halte Zustand, Evals und Tool-Verträge in einem Format unter eigener Kontrolle. Gute Orchestrierung ist langweilig, auditierbar und austauschbar.