Ein Modell für alles ist 2026 ein Architekturfehler
Multi-Model-Routing ist kein Nice-to-have mehr. Wer 2026 noch ein Modell für alles kauft, baut Vendor-Lock in die Kernprozesse.
Wer 2026 noch ein einziges Frontier-Modell als Betriebsstandard kauft, baut Vendor-Lock in die Kernprozesse. Multi-Model-Routing ist das Operating Model, mit dem Teams Kosten, Latenz und Ausfallsicherheit steuern.
Das Wichtigste in Kürze
- These klar. Ein Modell für alles war 2023 pragmatisch und ist 2026 ein Architekturfehler: Routing trennt Aufgabe, Risiko und Preis.
- Steelman zählt. Die Gegenposition (ein Stack, eine Rechnung, ein Prompt-Stil) spart Reibung – und verschiebt das Risiko in den Kern.
- Verdikt. Ab zwei produktiven Workloads lohnt ein Routing-Layer mit Policy, Fallback und Outcome-Metriken statt Token-Kosmetik.
Verwandt:Claude neben GPT: Model Choice und seine Trade-offs / Frontier-Modell per Behördenbescheid offline: Die Architektur-Lehre
Der Steelman: warum „ein Modell“ so verführerisch bleibt
Die Gegenposition verdient Respekt. Ein Provider, ein SDK, eine Rechnung, ein Prompt-Stil, ein Security-Review. Weniger Ticket-Chaos im Einkauf, weniger Drift in den Guardrails, weniger „welches Modell war das noch?“ in der Post-Mortem. Für ein kleines Team mit einem klaren Use Case ist das oft die ehrlichere Wahl als ein Bastel-Router ohne Owner.
Auch operativ gibt es Argumente: Einheitliche Observability, ein Rate-Limit-Budget, ein Datenschutz-Anhang. Wer noch experimentiert, spart sich mit einem Stack den Kontext-Switch. Genau deshalb bleibt der Single-Model-Pfad so populär – und genau deshalb muss man ihn hart gegen die reale Last 2026 prüfen, nicht gegen die Demo-Folie.
Drei Gründe, warum der Single-Model-Pfad bricht
Erstens: Aufgaben sind nicht austauschbar. Code-Refactor, strukturierte Extraktion, lange Recherche und kurze Klassifikation belasten Modelle unterschiedlich. Wer alles über dasselbe teure Frontier-Modell schickt, kauft Spitzenqualität für Aufgaben, die ein kleineres, spezialisiertes oder gecachtes Modell in Sekunden erledigt. Das ist Architekturhygiene – und mehr als eine bloße Spar-Aktion.
Zweitens: Ausfall ist ein Architektur-Event. Ein Behördenbescheid, eine Regionssperre, ein Quota-Hardcap oder ein Provider-Incident legt den gesamten Agenten-Pfad lahm – nicht nur ein einzelnes Feature. Multi-Model mit hartem Fallback trennt Produktfähigkeit von Vendor-Laune. Wer das 2026 noch als Nice-to-have verbucht, verwechselt Verfügbarkeit mit Preferenz.
Drittens: Tokens sind die falsche KPI. Token-Kosten sind Eingangsgröße, nicht Ergebnis. Entscheidend sind Zeit bis brauchbarem Output, Nacharbeitsquote, Policy-Hits und Kosten pro erledigtem Fall. Ein Routing-Layer macht diese Metriken steuerbar: teures Modell nur bei hohem Risiko oder hohem Wert, günstiges Modell für den Massendurchsatz, zweites Modell für Review- oder Consensus-Schritte.
Verdikt
Ab zwei produktiven KI-Workloads mit unterschiedlicher Kritikalität ist Single-Model die teure Vereinfachung. Routing mit Policy, Fallback und Outcome-Metriken ist das Betriebsmodell – nicht die nächste Modell-Ankündigung.
Was Multi-Model-Routing im Betrieb konkret heißt
Routing ist kein magischer Switch, der „das beste Modell“ wählt. Es ist ein Entscheidungsbaum mit harten Defaults: Task-Typ, Datenklasse, Latenzbudget, Kostenplafond, Jurisdiktion. Die Policy liegt vor dem Prompt, nicht danach. Sonst wird aus Routing nur ein teurer A/B-Test im Produktivsystem.
Pragmatischer Aufbau für DACH-Teams: (1) Katalog der Workloads mit Risiko-Stufe, (2) Default-Modell je Stufe, (3) Fallback-Modell mit gleicher Output-Schema-Garantie, (4) Review-Pfad für High-Risk, (5) Kill-Switch pro Provider. Der Router speichert Entscheidung und Begründung – sonst ist das System nicht auditierbar.
Wichtig: Model Choice in Copilot-Oberflächen und ein eigener Routing-Layer im Backend sind verwandt, aber nicht dasselbe. UI-Choice steuert Komfort. Backend-Routing steuert Betrieb, Compliance und Budget. Wer beides vermischt, bekommt weder klare UX noch saubere Telemetrie.
Die Metriken, die den Router steuern
Drei Zahlen reichen als Startset. Erfolgsquote erster Durchlauf (ohne menschliche Nacharbeit). Kosten pro erledigtem Fall in Euro, nicht pro Million Tokens. p95-Latenz je Workload. Ergänzend: Anteil der Requests mit Fallback und Anteil mit zweitem Modell im Review.
Was bewusst fehlt: Leaderboard-Benchmarks als Betriebs-KPI. Benchmarks helfen bei der Modellauswahl im Labor. Im Betrieb zählt, ob der Agent den Ticket-Status korrekt setzt, die Rechnung korrekt klassifiziert oder den Diff ohne Regression vorschlägt. Wer Benchmarks als Zielgröße nimmt, optimiert Marketing-Folien statt Prozesse.
Wann Single-Model trotzdem richtig bleibt
Es gibt ehrliche Ausnahmen. Ein reiner Pilot mit einem Team und einem Use Case. Ein streng regulierter Pfad, in dem nur ein freigegebenes Modell im Vertrag steht und die Freigabe Monate dauert. Ein Shop-Floor-System mit so engem Latenzbudget, dass jedes Extra-Hop den Nutzen zerstört. In diesen Fällen ist Single-Model kein Fehler – solange die Exit-Strategie dokumentiert ist.
Die rote Linie: Sobald ein zweiter produktiver Workload mit anderer Datenklasse oder anderer Kritikalität hinzukommt und trotzdem über dasselbe Modell läuft „weil wir das schon haben“, beginnt der Architekturfehler. Dann zahlt man Komplexität später mit Zins – in Incidents, in Nacharbeit, in Vendor-Verhandlungen.
Häufige Fragen
Ist Multi-Model-Routing nicht zu teuer für den Mittelstand?
Nein, wenn Routing Kosten pro Fall senkt. Teuer wird es, wenn jedes Ticket das teuerste Frontier-Modell nutzt. Ein schlanker Router mit Defaults und Fallback spart oft mehr als er kostet – messbar an Euro pro erledigtem Fall.
Reicht Model Choice in der Oberfläche statt eines eigenen Routers?
Für Komfort ja, für Betrieb nein. UI-Choice steuert Präferenz. Backend-Routing steuert Policy, Fallback, Audit und Budget. In produktiven Agenten-Pfaden braucht es den zweiten Layer.
Welche Metrik ersetzt Token-Kosten?
Kosten pro erledigtem Fall in Euro, plus Erfolgsquote ohne Nacharbeit und p95-Latenz. Tokens bleiben Eingangsgröße für FinOps, nicht die Zielgröße für Produktentscheidungen.
Wann ist ein einziges Modell noch vertretbar?
Bei einem klaren Pilot, einem vertraglich fixierten Modell oder extrem engen Latenzpfaden – immer mit dokumentierter Exit-Strategie. Ab zwei produktiven Workloads mit unterschiedlicher Kritikalität wird Single-Model riskant.
Wie startet man ohne Big-Bang-Plattform?
Mit drei Workloads, drei Defaults, einem Fallback und Telemetrie. Kein Multi-Provider-Zoo am Tag eins. Erst Policy und Metriken, dann mehr Modelle.
Lesetipps der Redaktion
cloudmagazinClaude neben GPT: Model Choice und seine Trade-offscloudmagazinFrontier-Modell per Behördenbescheid offline: Die Architektur-LehrecloudmagazinDas Modell-Laden frisst die teure TPU-StundeMehr aus dem MBF Media Netzwerk
MyBusinessFutureInvestitionsstau: Wie KI verborgene Budgets freilegtDigital ChiefsDie IT entscheidet, ob der Spin-off sich auszahltSecurityTodayDer AI Act ist in Wahrheit ein Security-GesetzBildquelle: KI-generiert (Juli 2026)
