Pexon Consulting | 10 Min. Lesezeit | 09.06.2026
TL;DR
Multi-Model Routing löst das LLM-Kosten-Problem, das die meisten Unternehmen 2026 noch nicht auf der Roadmap haben. Brian Armstrong (Coinbase) hat gerade öffentlich bestätigt, was Pexon seit 12 Monaten in produktiven Setups sieht: 80 % der Workloads laufen wirtschaftlich auf 99 % billigeren Modellen, nur 20 % brauchen Frontier-Intelligence. Cascade-Routing mit LiteLLM und Confidence-Gates halbiert Token-Kosten ohne nennenswerten Qualitätsverlust. Pattern und Code für CTOs.
Was Brian Armstrong wirklich gesagt hat — und warum es bei deutschen Mittelständlern landen sollte
Brian Armstrong, CEO von Coinbase, hat in einem Posting Anfang Juni 2026 öffentlich formuliert, was bislang nur in Engineering-Backchannels diskutiert wurde:
Das ist mehr als ein Tweet. Das ist die explizite Bestätigung der Cost-Strategie, die wir bei Pexon seit gut einem Jahr produktiv umsetzen — und die in vielen deutschen Mittelstands-Stacks noch nicht mal als Idee existiert. Wer heute LLM-Workloads ausschließlich auf Claude Opus oder GPT-5 fährt, weil „das ist das beste Modell“, zahlt 5-30x zu viel und verbrennt FinOps-Budget, das eigentlich in den nächsten Use-Case fließen sollte.
Die deutsche Mittelstands-Erfahrung deckt sich mit Coinbase: Bei einem Versicherer haben wir mit Multi-Model Routing innerhalb von 8 Wochen die LLM-Kosten um 71 % gesenkt, während das Anfrage-Volumen im selben Zeitraum um 35 % gestiegen ist. Die Qualitäts-Metriken — Antwort-Akzeptanz durch Sachbearbeiter — blieben konstant.
Warum LLM-Kosten exponentiell wachsen und Compute zum Limit wird
Token-Nutzung in produktiven Agent-Stacks wächst nicht linear. Pro freigeschaltetem User multiplizieren sich Conversations, Tool-Calls und Re-Tries. Bei einer typischen Pexon-Roll-out-Welle (Start mit 50 Pilotnutzern, Skalierung auf 500-1.500 Mitarbeiter über 3-6 Monate) wachsen die Tokens pro Monat um Faktor 15-40. Wenn das Modell-Pricing dabei statisch ist, explodieren die Kosten.
Armstrongs These zum Compute-Limit ist dabei nicht Marketing-Theorie. Die Frontier-Modelle aller großen Anbieter (Anthropic, OpenAI, Google) haben in den letzten 12 Monaten Throttling-Mechanismen erweitert und Provisioned-Throughput-Tarife eingeführt — beides Indikatoren dafür, dass nicht die Modell-Qualität, sondern die GPU-Kapazität pro Modell-Generation der Engpass wird. Für Enterprise-Customer heißt das: Wer 100 % Frontier-Workload plant, läuft in eine Verfügbarkeits-Wand.
Die wirtschaftliche Logik dahinter ist klar: Compute pro Token sinkt schneller als Moore’s Law, aber nicht für Frontier-Modelle, sondern für deren ein bis zwei Generationen ältere Schwester. Genau das macht Multi-Model Routing zum Hebel: Frontier nur dort einsetzen, wo es einen messbaren Qualitätssprung gibt, alles andere auf die deutlich günstigere Mid-Tier oder selbst-gehostete Open-Source-Modelle routen.
Die 80/20-These — was technisch dahintersteckt
Armstrongs 80/20 ist keine zufällige Schätzung, sondern eine empirisch beobachtete Verteilung. Aus unseren Pexon-Workload-Analysen 2025/2026 in vier Branchen:
Was ist „Frontier-nötig“? In unserer Praxis sind das: Mehrstufige Reasoning-Aufgaben mit Cross-Domain-Wissen, komplexe Code-Generierung mit Test-Verifikation, Übersetzungen in seltene Sprach-Domänen, und alles, was als Orchestrator-Agent über fünf bis zehn andere Tools entscheiden muss. Das sind in keinem unserer Workloads mehr als 15 %.
„Mid-tier OK“ heißt: Strukturierte Klassifikation, Zusammenfassung von Dokumenten unter 30 Seiten, einfacher Tool-Call, RAG-basierte Antworten auf bekannten Datenbeständen. Haiku 4.5 oder GPT-4o-mini erledigen das mit über 95 % der Frontier-Qualität, bei 1-5 % der Kosten.
„Self-hosted OK“ heißt: Hochfrequente Routine-Aufgaben mit klaren Templates — Embedding-Generation, Entitäts-Extraktion, einfache Q&A auf festen Domänen. Qwen 2.5 oder Llama 3.3 auf eigener GPU-Infrastruktur ist hier oft die einzige wirtschaftliche Option, wenn die Workload sehr hoch ist.
Routing-Strategien — vier Pattern, vier Use-Cases
Multi-Model Routing ist kein einzelnes Konzept, sondern eine Familie von Pattern. Vier produktive Varianten:
Pattern 1 — Task-Type Routing. Eine vorgelagerte Klassifikation entscheidet, welche Modell-Klasse die Anfrage braucht. Einfach in der Logik (Regel-basiert oder mit einem winzigen Klassifikations-Modell), aber pflegeintensiv bei wachsender Task-Vielfalt.
Pattern 2 — Cascade Routing mit Confidence-Gate. Die Anfrage geht zuerst an das günstigere Modell. Wenn das Modell selbst signalisiert „niedrige Konfidenz“ oder „komplexer Fall“, eskaliert der Router zum teureren Modell. Das ist unser Default-Pattern für die meisten Mittelstands-Setups.
Pattern 3 — Embedding-Similarity Routing. Eine RouteLLM-ähnliche Architektur, die historische Anfragen mit Erfolg/Misserfolg-Labels nutzt, um neue Anfragen per Vektor-Match dem richtigen Modell zuzuweisen. Skaliert sehr gut, braucht aber Trainings-Daten aus der Produktion.
Pattern 4 — Budget-basiertes Routing. Pro User oder pro Mandant ein monatliches Token-Budget. Solange Budget vorhanden, läuft Anfrage auf Frontier-Modell, danach auf Mid-tier. Wirtschaftlich elegant, in der Praxis aber schwer zu kommunizieren („Warum ist die Antwort heute schlechter als gestern?“).
Unsere klare Empfehlung: Cascade Routing als Default, kombiniert mit Task-Type-Routing für klar abgegrenzte Workflows (z.B. „alle Embedding-Calls direkt auf self-hosted, alle DSGVO-sensiblen Calls direkt auf EU-Region-Frontier“). Embedding-Similarity Routing ist die Optimierung für Phase 2, wenn das System läuft.
Cascade Routing mit Confidence-Gates — das produktive Pattern
Cascade Routing funktioniert so: Der Router startet jede Anfrage mit dem günstigsten Modell, das fachlich plausibel ist. Das Modell antwortet plus ein Confidence-Signal (entweder als strukturierter Output mit confidence: float oder als Token-Log-Probability-Analyse). Liegt die Confidence unter einer Schwelle, eskaliert der Router automatisch zur nächsten Modell-Klasse.
Anfrage → Self-hosted Qwen 2.5 → Confidence > 0,85? → Antwort an User
→ Confidence < 0,85?
↓
Mid-tier Haiku 4.5 → Confidence > 0,85? → Antwort an User
→ Confidence < 0,85?
↓
Frontier Sonnet 4.6 → Antwort an UserDrei Detail-Entscheidungen, die in jedem Pattern-Setup wiederkehren:
- Confidence-Schwelle pro Modell-Klasse separat tunen. Was bei Qwen 2.5 als „hohe Konfidenz“ gilt (0,85+), bedeutet bei Haiku 4.5 nicht dasselbe. Tuning aus 50-200 Pilot-Cases pro Klasse.
- Eskalations-Anteil monitoren als FinOps-Metrik. Wenn 60 % der Anfragen am Self-hosted-Modell vorbeigehen, ist die Konfigurations-Schwelle zu konservativ oder das Modell zu schwach. Wenn weniger als 20 % eskaliert werden, ist die Schwelle zu aggressiv.
- Maximal zwei Eskalationen pro Anfrage. Drei-Stufen-Cascade hat einen Latenz-Effekt, der bei interaktiven User-Cases störend ist. Lieber Stufe 1 (self-hosted) + Stufe 3 (Frontier), Stufe 2 weglassen.
In zwei laufenden Pexon-Projekten haben wir mit Cascade Routing 65-78 % der Anfragen am günstigsten Modell terminiert, weitere 15-25 % am Mid-tier, nur 5-15 % am Frontier. Bei sonst gleicher Antwort-Qualität sinkt die Token-Rechnung um Faktor 4-8.
Code-Beispiel — LiteLLM-basierter Router
LiteLLM ist die pragmatische Open-Source-Wahl für produktives Multi-Model Routing. Es vereinheitlicht die APIs aller großen Anbieter (Anthropic, OpenAI, Azure, Bedrock, Open-Source-Endpoints) hinter einer einzigen Schnittstelle.
from litellm import Router
from litellm.utils import get_response_cost
router = Router(
model_list=[
{
"model_name": "tier-1-cheap",
"litellm_params": {
"model": "openai/qwen-2.5-72b",
"api_base": "https://qwen.intern.pexon.de/v1",
"api_key": QWEN_KEY,
},
},
{
"model_name": "tier-2-midtier",
"litellm_params": {
"model": "azure/gpt-4o-mini",
"api_base": "https://pexon-eu.openai.azure.com",
"api_key": AZURE_KEY,
},
},
{
"model_name": "tier-3-frontier",
"litellm_params": {
"model": "bedrock/anthropic.claude-sonnet-4-6",
"aws_region_name": "eu-central-1",
},
},
],
)
async def cascade_route(prompt: str, confidence_threshold: float = 0.85):
"""Cascade-Routing: günstigstes Modell zuerst, eskalieren bei niedriger Konfidenz."""
for tier in ["tier-1-cheap", "tier-2-midtier", "tier-3-frontier"]:
response = await router.acompletion(
model=tier,
messages=[{"role": "user", "content": prompt}],
response_format={"type": "json_object"},
)
result = parse_with_confidence(response.choices[0].message.content)
cost_usd = get_response_cost(response)
audit_log(tier=tier, confidence=result.confidence, cost_usd=cost_usd)
if result.confidence >= confidence_threshold:
return result.answer
return result.answer # auch auf Frontier-Antwort fallbackWichtige Pattern-Entscheidungen:
- Strukturierte Outputs mit Confidence-Feld. Ohne das ist Cascade Routing nicht zuverlässig. Modell muss seine eigene Unsicherheit beziffern können.
- Cost-Audit pro Call. Jeder Modell-Aufruf wird mit Kosten in USD geloggt — das ist die Basis für FinOps-Reporting und für Optimierungs-Entscheidungen.
- Fail-open auf Frontier. Wenn auch Frontier keine ausreichende Konfidenz hat, geben wir trotzdem die Antwort zurück mit einer Markierung „low confidence“ — der User sieht, dass die Antwort vorsichtig zu lesen ist.
Was das in einer deutschen Mittelstands-Bilanz bedeutet
Konkrete Zahlen aus drei Pexon-Projekten der letzten 12 Monate. Alle drei sind Versicherer, Industrie-Mittelstand oder Banking mit 500-3.000 MA und produktivem AI-Stack:
Projekt A — Versicherer, Schadenbearbeitung. Vor Routing: 18.500 EUR Token-Kosten/Monat. Nach Cascade Routing: 5.300 EUR/Monat bei gleichzeitig 35 % höherem Anfrage-Volumen. Einsparung absolut: 13.200 EUR/Monat = 158.000 EUR/Jahr. Setup-Aufwand: 9 Wochen, 78.000 EUR. Amortisation: 6 Monate.
Projekt B — Industrie-Mittelstand, RAG-System für Wartung. Vor Routing: 8.200 EUR/Monat. Nach Cascade Routing mit teilweise self-hosted Qwen: 1.900 EUR/Monat. Einsparung: 6.300 EUR/Monat = 75.600 EUR/Jahr. Setup: 8 Wochen, 62.000 EUR. Amortisation: 10 Monate.
Projekt C — Banking, Customer-Support-Assistent. Vor Routing: 24.500 EUR/Monat. Nach Cascade Routing: 11.800 EUR/Monat bei 60 % mehr Anfragen. Einsparung: 12.700 EUR/Monat = 152.400 EUR/Jahr. Setup: 10 Wochen, 92.000 EUR. Amortisation: 7 Monate.
Die Investment-Range für eine produktive Multi-Model-Routing-Implementierung liegt damit zwischen 60.000 und 95.000 EUR. Amortisation bei Workloads im fünfstelligen monatlichen Token-Volumen typisch 6-12 Monate. Bei sehr kleinen Workloads (unter 2.000 EUR/Monat Token-Kosten) lohnt sich der Setup-Aufwand wirtschaftlich nicht — dann besser auf einem einzelnen Mid-tier-Modell bleiben.
Fallen und Anti-Patterns
Aus den drei Projekten oben drei wiederkehrende Fallen, die in jedem Routing-Setup auftauchen:
Falle 1 — Routing-Logik im falschen Layer. Wer Routing in der Application-Layer baut, verteilt die Logik auf alle Services und macht zentrale Anpassung unmöglich. Routing gehört in einen eigenen Service oder ein eigenes Gateway, das alle LLM-Calls durchläuft.
Falle 2 — Keine Quality-Regression-Tests. Wenn das Routing schief geht, fallen die Antwort-Qualität schleichend, ohne dass jemand es merkt. Pflicht: Ein Set von 100-300 fixen Testfällen, das wöchentlich gegen alle Routing-Tiers gelaufen wird. Wenn die Mid-tier-Qualität für einen Use-Case unter einen Schwellenwert fällt, automatischer Alert.
Falle 3 — Datenschutz-Sünden beim Routing. Wer DSGVO-sensible Anfragen an US-Cloud-Modelle routet, weil die billiger sind, hat ein größeres Problem als hohe Kosten. Pflicht: Routing-Layer kennt Data-Classification jeder Anfrage und routet nur in compliance-konforme Modelle. Das ist Pflicht-Teil unseres Setup-Templates für regulierte Branchen.
Konfidenz: hoch für alle drei. Wir sehen das in jedem Routing-Projekt.
Häufig gestellte Fragen
Reduziert Multi-Model Routing die Antwort-Qualität spürbar?
In unseren Messungen 2025/2026: nein, sofern Cascade-Logik mit Confidence-Gates greift. Bei Workloads, die wir gegen menschliche Akzeptanz-Bewertungen gemessen haben, blieb die Akzeptanz-Quote zwischen Routing-on und Routing-off innerhalb von 1-3 Prozentpunkten. Wer ohne Confidence-Gate hart auf das günstigste Modell routet, sieht messbare Qualitätsverluste — das ist das No-Brain-Anti-Pattern, das die Schlagzeilen schreibt, nicht das produktive Routing.
Welche Frameworks für Multi-Model Routing empfiehlt Pexon?
LiteLLM für die meisten Mittelstands-Setups — Open-Source, produktionsstabil, breite Connector-Auswahl. Portkey für Enterprise mit komplexen Compliance-Anforderungen (eingebaute Audit-Logs, FinOps-Dashboards). OpenRouter primär für Prototyping-Phasen. RouteLLM für hochvolumige Use-Cases mit Training-Daten-Verfügbarkeit. Self-built Router nur, wenn es spezifische Compliance-Gründe gibt.
Kann Multi-Model Routing auch in stark regulierten Branchen (Banking, Versicherung, KRITIS) eingesetzt werden?
Ja, mit angepasstem Setup. Pro Daten-Klassifikations-Stufe ein eigener Modell-Pool: hochsensible Daten nur auf self-hosted oder Azure-EU-Frontier, weniger sensible Daten auf erweitertem Pool. Routing-Audit-Trail muss DORA- und NIS-2-tauglich sein (siehe unser Beitrag zu AI Agent Security mit Entra ID).
Was bedeutet Brian Armstrongs Compute-Limit-These konkret für uns als Unternehmen?
Wer sein AI-Stack-Wachstum für die nächsten 18 Monate plant, sollte zwei Annahmen einbauen: Erstens, Frontier-Modelle werden in Spitzenlast-Phasen nicht garantiert verfügbar sein (Provisioned-Throughput-Verträge werden Standard). Zweitens, self-hosted-Optionen für die hochvolumigen 30-50 % der Workloads sind eine strategische Versicherung gegen Anbieter-Engpässe — keine Nische mehr.
Wie schnell kann ein Mittelständler ein Multi-Model-Routing-Setup produktiv haben?
Aus unseren Projekten: 8-10 Wochen für ein erstes produktives Cascade Routing mit zwei Tiers, weitere 4-6 Wochen für self-hosted-Erweiterung. Total realistisch 12-16 Wochen vom Discovery zur kompletten 3-Tier-Architektur. Wer schon eine Azure-Foundation hat, ist in 6-8 Wochen produktiv.
Nächster Schritt
Wenn Sie aktuell mit einem wachsenden LLM-Kostenblock kämpfen oder die FinOps-Diskussion mit dem CFO bevorsteht: Wir machen das im 6-Wochen-Pilotprojekt für Generative AI konkret — Workload-Analyse in Woche 1, Routing-Architektur in Woche 2-3, produktives Cascade Routing mit zwei Tiers bis Woche 6.
Verwandte Themen
→Agentic Loops Production: Welches Framework hält 100 User?
→Private KI-Infrastruktur für regulierte Branchen
