# Wie sollten Anfragen auf mehrere KI-Modelle verteilt werden?

> Sollten Anfragen in einem KI-System mit mehreren Modellen über explizite Regeln, prädiktives Routing, Kaskaden oder Fallback-Pfade zugeordnet werden?

> 💡 **Kurzfassung:**
> - **Mehrere Modelle rechtfertigen nicht automatisch ein intelligentes Routingsystem.** Wenn Sprache, Dokumenttyp, Risiko oder Datenrichtlinie die Wahl bestimmen, beginnen Sie mit einer expliziten Regel.
> - **Model Routing fügt dem System eine weitere Vorhersage hinzu.** Ein Router kann das falsche Modell wählen, obwohl jedes Modell bei den Aufgaben, für die es vorgesehen ist, korrekt arbeitet.
> - **Ein Router muss beim tatsächlichen Arbeitsvolumen sowohl das beste einzelne Modell als auch einfache Routingregeln schlagen.** In den Vergleich gehören Bewertung, Latenz, Monitoring und Fehlerkorrektur – nicht nur die Modellpreise.

Stellen Sie sich vor, Ihr System nutzt zwei KI-Modelle. Ein kleineres Modell bearbeitet häufige, leicht zu klassifizierende Anfragen zu geringeren Kosten. Ein leistungsfähigeres Modell bleibt Vertragsausnahmen, mehrdeutigen Kundennachrichten und Fragen vorbehalten, die tieferes Schlussfolgern verlangen.

Dieser Beitrag fragt nicht, ob das zweite Modell überhaupt existieren sollte. [Wann ein Modell ausreicht und was ein zweites Modell belegen muss, bevor es ins System kommt, habe ich im vorherigen Beitrag behandelt](/de/wann-reicht-ein-ki-modell){target="_blank" rel="noopener"}. Hier erfüllen beide Modelle bereits eine messbare Aufgabe und haben sich ihren Platz verdient.

Nun muss das System entscheiden, welche Anfrage an welches Modell geht.

Wählt ein Kunde in einem Formular „Lieferproblem“, kann die Entscheidung offensichtlich sein. Die Software kann die Anfrage an das zuständige Modell senden. Schwieriger wird es, wenn der Kunde frei schreibt und mehrere Anliegen in einer Nachricht verbindet. Das System muss dann vorhersagen, welches Modell wahrscheinlich die bessere Antwort erzeugt, bevor eines der Modelle geantwortet hat.

Die Schicht, die eine Anfrage prüft und ein Modell auswählt, wird meist **Model Router** genannt. Der Vorgang heißt **Model Routing**.

Dieser Begriff umfasst jedoch mehrere unterschiedliche Entscheidungen.

## Entscheiden Sie zuerst, welche Art von Routing Sie brauchen

Eine Anfrage an ein anderes Modell zu senden ist nicht immer eine „intelligente“ Entscheidung. Manchmal steht das Ziel fest, bevor ein Modell läuft. Manchmal muss das System zunächst das Ergebnis des ersten Modells prüfen. In anderen Fällen existiert das zweite Modell nur für einen technischen Fehler.

| Methode | Wann fällt die Entscheidung? | Einfaches Beispiel | Betriebsaufwand |
| --- | --- | --- | --- |
| Explizite Regel | Vor einem Modellaufruf | Eine eingescannte Rechnung an ein Vision-Modell, eine Textdatei an ein Sprachmodell senden | Regeln und Ausnahmen aktuell halten |
| Prädiktives Routing | Vor einem Modellaufruf | Schwierigkeit der Anfrage schätzen und das kleinere oder leistungsfähigere Modell wählen | Routerfehler, eigene Bewertung und Monitoring |
| Kaskade | Nach Prüfung des ersten Ergebnisses | Das stärkere Modell erneut versuchen lassen, wenn das kleinere nicht genügt | Weiterer Aufruf, höhere Kosten und mehr Latenz |
| Fallback | Nach technischem Fehler oder Ausfall | Anbieter wechseln, wenn das primäre Modell nicht antwortet | Laufend prüfen, ob beide Optionen dieselbe Aufgabe erfüllen können |

Produkte verwenden diese Begriffe nicht immer gleich. Googles [API Gateway Model Routing](https://docs.cloud.google.com/api-gateway/docs/model-routing-overview){.dofollow target="_blank" rel="noopener"} ordnet in seiner Vorschau von 2026 einen Modellnamen in der Anfrage einem vordefinierten Ziel zu. Es entscheidet nicht, welches Modell die bessere Antwort erzeugen würde, sondern sendet den angeforderten Namen an das konfigurierte Ziel.

Amazons [Intelligent Prompt Routing](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-routing.html){.dofollow target="_blank" rel="noopener"} prüft dagegen die Anfrage und sagt voraus, welches von zwei Modellen wahrscheinlich besser abschneidet. In einem Produkt bezeichnet „Routing“ eine explizite Verkehrsregel, im anderen eine zusätzliche Vorhersage.

Definieren Sie die Entscheidung, bevor Sie das Werkzeug wählen.

## Sagen Sie keine Entscheidung voraus, die bereits feststeht

Ein Versicherer kann eingescannte Schadendokumente an ein Vision-Modell und Aufzeichnungen aus dem Callcenter an ein Sprachmodell senden. Wenn das Eingabeformat das Modell bereits bestimmt, gibt es keinen Grund, einen weiteren Router zu trainieren.

Manche Anfragen müssen wegen der Datenrichtlinie in einer vom Unternehmen kontrollierten Umgebung bleiben. Transaktionen mit hohem Risiko dürfen möglicherweise nie für das günstigere Modell infrage kommen. Diese Grenzen gelten, bevor ein Router irgendeine Qualitätsprognose abgibt.

Eine explizite Regel ist nicht deshalb richtig, weil sie weniger anspruchsvoll wäre. Sie ist richtig, weil die Entscheidung bereits klar ist. Das Team kann nachvollziehen, warum eine Anfrage bei einem bestimmten Modell landete, und prüfen, was sich ändert, wenn die Regel angepasst wird.

Dafür müssen Sie unterscheiden, was ein Modell technisch leisten kann und was das System ihm erlauben darf. Ein Modell kann sensible Daten möglicherweise technisch verarbeiten. Wenn die Richtlinie verbietet, diese Daten an den Anbieter oder in dessen Region zu senden, darf der Router dieses Modell gar nicht erst als Kandidaten berücksichtigen.

AWS erklärt entsprechend für [geografische regionsübergreifende Inferenz](https://docs.aws.amazon.com/bedrock/latest/userguide/geographic-cross-region-inference.html){.dofollow target="_blank" rel="noopener"}, dass Anfragen die Quellregion verlassen und unter bestimmten Umständen zur Missbrauchserkennung in der Zielregion gespeichert werden können. Eine Routingrichtlinie darf daher nicht nur Qualität und Preis betrachten. Sie muss auch beachten, wohin Daten gesendet werden dürfen.

## Wann verdient ein intelligenter Router seinen Platz?

Ein Kundensupportkanal kann einfache Adressänderungen und zugleich Streitfälle erhalten, die mehrere Vertragsklauseln betreffen. Beide Anfragen sind Text. Sie können in derselben Sprache formuliert sein. Trotzdem verlangen sie nicht dieselbe Modellfähigkeit.

Bei einem solchen Arbeitsvolumen sagt ein Router voraus, welches Modell für die jeweilige Anfrage besser geeignet ist. Bearbeitet das kleinere Modell einfache Anfragen mit akzeptabler Qualität, können die Kosten sinken. Schwierigere Fälle an das stärkere Modell zu senden kann die Qualität erhalten.

Die [Forschenden hinter RouteLLM](https://arxiv.org/abs/2406.18665){.dofollow target="_blank" rel="noopener"} berichteten, dass Router, die mit menschlichen Präferenzdaten trainiert wurden, bei einigen Benchmarks die Antwortqualität erhalten und die Kosten um mehr als die Hälfte senken konnten. Das zeigt, dass Routing funktionieren kann. Es zeigt nicht, was im echten Kundenverkehr eines Unternehmens geschieht, wie viel Zeit Beschäftigte mit Fehlerkorrekturen verbringen oder ob sich das Geschäftsergebnis verbessert.

Auch die Modelle vor dem Router müssen einander ergänzen. Drei Modelle mit ähnlichen Stärken und Schwächen in einen Pool zu legen macht die Auswahl nicht wertvoller. Wenn ohnehin fast jede Anfrage das stärkere Modell erreichen muss, kann der Router eine weitere Verzögerung hinzufügen, ohne nennenswerte Einsparungen zu erzielen.

Ein intelligenter Router braucht deshalb mindestens drei Voraussetzungen:

1. Die Modelle schneiden bei unterschiedlichen Teilen der echten Arbeit messbar besser ab.
2. Das Anfragevolumen ist groß genug, um Aufbau und Betrieb der Routingschicht zu rechtfertigen.
3. Sie können eine falsch zugeordnete Anfrage erkennen und ihre Wirkung auf das Geschäftsergebnis messen.

Fehlt eine dieser Voraussetzungen, sind ein Modell oder wenige explizite Regeln möglicherweise der bessere Ausgangspunkt.

## Mehr Modelle machen den Router nicht automatisch besser

Die in *Findings of ACL 2026* veröffentlichte [LLMRouterBench-Studie](https://aclanthology.org/2026.findings-acl.1881/){.dofollow target="_blank" rel="noopener"} verglich mehr als 400.000 Beispiele aus 21 Datensätzen, 33 Modelle und zehn Routingmethoden.

Die Forschenden bestätigten, dass Modelle einander über verschiedene Aufgaben hinweg ergänzen können. Anschließend setzten sie eine einfache Baseline: Jede Anfrage geht an das einzelne Modell, das insgesamt am besten abschneidet. Einige neuere Routingmethoden und der kommerzielle Dienst OpenRouter konnten diese Baseline nicht schlagen. Wenn sie Kosten senkten, hielten sie nicht dieselbe Qualität. Mit wachsendem Modellpool nahmen die Gewinne außerdem ab. Eine sorgfältig ausgewählte kleine Modellgruppe konnte nützlicher sein als ein größerer Pool.

Die Studie verwendet Benchmark-Datensätze, kein echtes Kundensupportsystem. Trotzdem zieht sie eine wichtige Grenze: Einen Router einzusetzen bedeutet nicht, das richtige Modell gewählt zu haben. Der Router ist selbst ein Modell oder Entscheidungssystem, dessen Wert belegt werden muss.

Ein verwalteter Dienst nimmt Ihnen diese Verantwortung nicht ab. Amazon erklärt, sein Intelligent Prompt Routing sei für englische Prompts optimiert und könne seine Entscheidungen nicht an die eigenen Leistungsdaten eines Unternehmens anpassen. Microsoft empfiehlt in seinem [Leitfaden zur Bewertung eines Model Routers](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/evaluate-model-router){.dofollow target="_blank" rel="noopener"}, den Router anhand einer für die tatsächlichen Anfragen des Unternehmens repräsentativen Stichprobe mit der direkten Modellnutzung zu vergleichen.

## Eine falsche Route ist eine eigene Fehlerart

Schickt der Router eine schwierige Anfrage an das kleinere Modell, kann dessen Dienst genau wie vorgesehen arbeiten. Die Antwort kann für die Aufgabe trotzdem unzureichend sein. Schlimmer noch: Sie kann so plausibel aussehen, dass das System keinen technischen Fehler meldet.

Ein Fallback löst dieses Problem nicht. Er wird gewöhnlich ausgelöst, wenn das erste Modell nicht antwortet, sein Kontingent ausgeschöpft ist oder der Anbieter ausfällt. Liefert das erste Modell eine schnelle, aber falsche Antwort, erkennt das System keinen technischen Fehler und wechselt das Modell nicht.

Eine Kaskade verfolgt einen anderen Ansatz. Das System lässt zuerst das kleinere Modell arbeiten und entscheidet anschließend, ob es dessen Antwort akzeptiert. Ein unzureichendes Ergebnis geht an das stärkere Modell. Manche Anfragen verursachen dadurch zwei Modellaufrufe, einen weiteren Bewertungsschritt und eine längere Wartezeit.

Unabhängig von der gewählten Methode genügt es nicht, jedes Modell isoliert zu messen. Sie müssen außerdem wissen:

- Warum ging diese Anfrage an dieses Modell?
- Wie oft erreichte eine schwierige Anfrage das kleinere Modell?
- Wie oft ging eine einfache Anfrage unnötig an das teure Modell?
- Wie hoch waren die Gesamtkosten je nutzbarem Ergebnis einschließlich Routing?
- Wie veränderten sich Latenz und Korrekturzeit nach Einführung des Routers?

Im [Beitrag über die Messung von Geschäftsergebnissen eines KI-Systems](/de/erzielt-ihr-ki-system-tatsaechlich-geschaeftsergebnisse){target="_blank" rel="noopener"} habe ich Modelloutput und abgeschlossene Arbeit voneinander getrennt. Routing ergänzt diese Messung um eine weitere Frage: War bei einem schlechten Ergebnis das Modell der Aufgabe nicht gewachsen oder hat das System die richtige Arbeit an das falsche Modell geschickt?

## Auch der Router muss sich seinen Platz verdienen

Sie können mehrere Modelle verwenden, ohne intelligentes Routing zu benötigen. Visuelle Dokumente können an ein Modell gehen, stabile Klassifikationsarbeit an ein anderes und Entscheidungen mit hohem Risiko direkt an den zuverlässigsten Pfad. Bestimmen explizite Regeln die Auswahl, lässt sich das System leichter verstehen und prüfen.

Wenn solche Regeln jede Anfrage zuverlässig zuordnen, bauen Sie keinen Router. Reichen die Regeln irgendwann nicht mehr, können Sie prädiktives Routing testen. Ein Vergleich nur mit einem System, das jede Anfrage an das teuerste Modell sendet, wäre jedoch irreführend. Lassen Sie dasselbe Arbeitsvolumen durch drei Varianten laufen: das insgesamt beste einzelne Modell, explizite Routingregeln und den Router.

Ein zweites Modell braucht einen Grund, um ins System zu kommen. Ein neues Entscheidungssystem, das bei jeder Anfrage zwischen diesen Modellen wählt, braucht einen zweiten Grund.

[Der vorherige Beitrag erklärt, wann ein KI-Modell ausreicht](/de/wann-reicht-ein-ki-modell).

Die weiteren Entscheidungen zu Modellen, Informationen, Befugnis und Bewertung finden Sie im [Leitfaden zum Entwurf eines KI-Systems für Ihr Unternehmen](/de/ki-systeme-fuer-unternehmen-gestalten).

---

Language: German
License: CC BY 4.0
License URL: https://creativecommons.org/licenses/by/4.0/
Scope: Evren Bal-authored text, unless this article expressly states otherwise.
Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights.
Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes.
Source: https://evrenbal.com/de/wie-sollten-anfragen-auf-mehrere-ki-modelle-verteilt-werden