KI-Modell-Routing einrichten: Anbieter in 1 Zeile tauschen

Zentrales KI-Modell-Routing heißt: Die Model-ID lebt an genau einer Stelle in deinem Code, und für jeden Aufgabentyp entscheidet eine Tabelle, welches Modell antwortet. So tauschst du Modell oder Anbieter in einer Zeile, statt halbe Tage durch Code zu suchen.

Eine Routing-Schicht trennt deine Anwendung von der konkreten Model-ID und dem Anbieter. Foto: SHOX ART auf Pexels

Was bedeutet zentrales KI-Modell-Routing und warum brauchst du es?

Zentrales KI-Modell-Routing bedeutet, dass die Model-ID an genau einer Stelle in deinem System steht und alle Anfragen über diese Stelle laufen. Statt überall im Code claude-sonnet-5 hart einzutragen, fragst du eine zentrale Funktion: Welches Modell ist für diesen Aufgabentyp zuständig? Diese eine Funktion kennt die Antwort, dein restlicher Code nicht.

Der Grund ist handfest. Wenn Model-IDs über Dutzende Dateien verstreut sind, wird jeder Wechsel zur Suchaktion mit Fehlerrisiko. Am 12. Juni 2026 hat die US-Regierung Anthropic per Exportkontroll-Anordnung gezwungen, Fable 5 und Mythos 5 abzuschalten; Opus 4.8, Sonnet 4.6 (heute Sonnet 5) und Haiku 4.5 liefen weiter. Seit dem 1. Juli 2026 ist Fable 5 wieder weltweit freigegeben, Mythos 5 bleibt auf eine geprüfte Gruppe von US-Organisationen begrenzt. Wer Fable 5 fest verdrahtet hatte, stand während der dreiwöchigen Sperre still. Wer eine Routing-Tabelle hatte, hat eine Zeile geändert. Mehr dazu im Hub-Artikel Claude im Unternehmenseinsatz und in Fable 5 ist zurück, Mythos 5 bleibt gesperrt.

Wie sieht die Mini-Architektur für zentrales Modell-Routing aus?

Die Architektur besteht aus drei Teilen: einer Routing-Tabelle, die Aufgabentypen auf Model-IDs abbildet, einer Abstraktionsschicht, die diese Tabelle liest und den Anbieter anspricht, und deinem Anwendungscode, der nur noch den Aufgabentyp nennt. Dein Code sagt also “fasse zusammen”, nicht “nutze claude-sonnet-5 über Anthropic”.

Wichtig ist, dass die Routing-Tabelle in einer Config-Datei oder in Umgebungsvariablen liegt, nicht im Quellcode. So änderst du das Mapping ohne Deploy. Eine anbieterneutrale Config kann minimal aussehen:

routing:
  routine:   { model: "claude-haiku-4-5",  provider: "anthropic" }
  standard:  { model: "claude-sonnet-5",  provider: "anthropic" }
  schwer:    { model: "claude-opus-4-8",    provider: "anthropic" }
  spitzenlast: { model: "claude-fable-5",   provider: "anthropic" }
fallback:
  schwer:    { model: "claude-opus-4-8",    provider: "bedrock" }
kill_switch: false

Die Abstraktionsschicht liest diesen Block, wählt anhand des Aufgabentyps das Modell und kümmert sich um die anbieterspezifischen Details. Bei Amazon Bedrock heißt Opus zum Beispiel anthropic.claude-opus-4-8 statt claude-opus-4-8. Genau solche Unterschiede gehören in den Adapter und nirgendwo sonst hin. Der Eintrag spitzenlast lief während der dreiwöchigen Fable-5-Sperre im Juni ins Leere; genau für solche Fälle steht der fallback-Block bereit, der schwere Last bei Bedarf auf Opus über Bedrock zieht. Seit der weltweiten Freigabe am 1. Juli läuft spitzenlast wieder regulär auf Fable 5.

Welches Claude-Modell passt zu welchem Aufgabentyp?

Die Regel lautet: kleinstes Modell, das die Aufgabe sauber löst. Routine-Last verschwendet auf einem Spitzenmodell nur Geld, und schwere Analyse auf einem kleinen Modell kostet dich Qualität. Die folgende Tabelle ordnet jeden Aufgabentyp einem Claude-Modell mit Listenpreis und Begründung zu. Es zählen nur die Listenpreise je 1 Million Token.

Den direkten Vergleich der Premium-Stufe findest du in Claude Fable 5 gegen Opus 4.8 im Detail. Für die meisten Betriebe tragen Haiku und Sonnet den Großteil der Last, Opus kommt punktuell dazu, Fable bleibt die Ausnahme.

Welchen Nutzen bringt dir zentrales Routing konkret?

Der greifbarste Nutzen ist Geld. Wenn du Routine-Aufgaben von einem teuren Modell auf Claude Haiku 4.5 verschiebst, fällt der Preis pro Token vom Niveau eines Spitzenmodells auf einen Bruchteil. Bei hohem Volumen ist das der größte Hebel deiner gesamten KI-Rechnung, noch vor jeder Prompt-Optimierung.

Dazu kommen zwei weitere Kostenhebel, die das Routing erst praktisch macht. Prompt-Caching legt wiederkehrende Prompt-Teile ab, und Cache-Reads kosten rund ein Zehntel des normalen Input-Preises. Die Batch-API gibt dir 50 Prozent Rabatt auf nicht zeitkritische Last. Beides steuerst du sauber, wenn der Aufgabentyp ohnehin schon zentral bekannt ist.

Routing ist kein Architektur-Luxus. Es ist die Stelle, an der du Kosten und Ausfallsicherheit zugleich steuerst.

Genauso wichtig ist die Beweglichkeit. Ein neues Modell erscheint, ein Preis ändert sich, ein Anbieter fällt aus: In allen Fällen änderst du die Routing-Tabelle, nicht den Code. Genau diese Beweglichkeit war am 12. Juni 2026 der Unterschied zwischen Stillstand und Weiterlaufen.

Welche Stolpersteine gibt es beim Modell-Routing und wie umgehst du sie?

Der häufigste Fehler ist, Model-IDs doch wieder im Code zu verstreuen, weil es im Moment schneller geht. Damit ist die ganze Idee dahin. Halte die Disziplin: Jede Model-ID, die nicht in Config oder Adapter steht, ist ein Bug. Ein Code-Review-Check auf hartkodierte Modellnamen hilft.

Der zweite Stolperstein sind die API-Unterschiede zwischen Anbietern. Amazon Bedrock nutzt anthropic.-präfixierte Model-IDs, und die Behandlung von Parametern wie dem erweiterten Thinking kann je Modell variieren. Diese Eigenheiten gehören in den Adapter, damit dein Anwendungscode sie nie sieht. Wie du Datenresidenz und Wechselrechte zusätzlich vertraglich absicherst, steht in die richtigen Vertragsklauseln mit KI-Anbietern.

Der dritte Stolperstein ist fehlendes Logging. Ohne durchgängiges Kostentracking je Aufgabentyp und Modell weißt du nicht, wo dein Geld hingeht und ob ein Wechsel etwas gebracht hat. Logge bei jeder Anfrage Aufgabentyp, Modell, Tokens, Kosten und Latenz. Und plane den Fallback bewusst über einen anderen Anbieter, denn ein zweites Modell beim selben Anbieter rettet dich nicht, wenn der ganze Anbieter wegbricht. Die Gesamtstrategie dahinter beschreibt Multi-Provider-Resilienz für den Mittelstand.

Wie richtest du Modell-Routing in 7 Schritten ein?

Du baust das Routing am besten von der Bestandsaufnahme zum Test. Die folgende Reihenfolge bringt dich von verstreuten Model-IDs zu einem System, in dem du Modell und Anbieter in einer Zeile wechselst.

1. Aufgabentypen inventarisieren. Liste auf, welche LLM-Aufgaben in deinem Betrieb laufen, wie häufig sie vorkommen und wie kritisch sie sind. Das ist die Grundlage für jede sinnvolle Zuordnung.
2. Abstraktionsschicht bauen. Schreibe eine zentrale Funktion oder ein Modul, das die Model-ID kapselt. Ab hier verweist kein Anwendungscode mehr direkt auf ein Modell.
3. Routing-Tabelle definieren. Lege das Mapping von Aufgabentyp auf Model-ID in einer Config-Datei oder Umgebungsvariable ab, niemals hartkodiert. Diese Tabelle ist dein einziger Wechselpunkt.
4. Feature-Flag und Kill-Switch einbauen. Mach Modell und Anbieter per Schalter umstellbar, ohne Deploy. So reagierst du in Minuten, wenn ein Modell wegfällt oder teurer wird.
5. Fallback und Circuit Breaker verdrahten. Bei Fehler oder Ausfall schaltet das System automatisch auf ein Ersatzmodell, idealerweise bei einem anderen Anbieter über Amazon Bedrock, Google Vertex AI oder Microsoft Foundry. Die vollständige Failover-Architektur mit Stufenmodell und Monitoring steht in unserem Multi-Provider-Resilienz-Guide, hier bleibt es bewusst beim Setup.
6. Logging und Kostentracking aktivieren. Erfasse je Aufgabentyp und Modell, welches Modell wie oft läuft, was es kostet und wie schnell es antwortet. Ohne Zahlen optimierst du blind.
7. Smoke-Test und A/B aktivieren. Vor jedem Wechsel läuft ein kurzer Funktionstest, und zwei Modelle laufen parallel zum Vergleich. So merkst du Qualitätssprünge, bevor sie Kunden merken.

Arno Hoffrichter

Chief Technology Officer, Collective Brain GmbH · Hamburg

CTO bei Collective Brain. Verantwortlich für die technische Umsetzung von Web-Projekten und SEO-Architektur.

Beratung anfragen