Pexon Consulting | 9 Min. Lesezeit | 16.07.2026
TL;DR
Kein einzelnes Modell deckt alle Anforderungen ab. Wir bei Pexon (80 Mitarbeiter, Microsoft Partner) routen nach Aufgabe und Datenklasse: Claude als Default, Open-Weight-Modelle on-premise für souveräne Workloads, Managed-Dienste wo der Betrieb ausgelagert wird. Ein Gateway entkoppelt Ihre Anwendung vom Anbieter und macht Wechsel zur Konfigurationssache.
Das Problem: Ein Modell für alles scheitert
Die meisten KI-Initiativen, die wir 2026 sehen, starten mit einer Grundsatzentscheidung, die keine sein sollte: „Wir nehmen Anbieter X.“ Danach läuft jede Anwendung, jeder Prompt, jeder Batch-Job über denselben Endpunkt. Das ist bequem, bis es teuer, unsicher oder unmöglich wird.
Drei Bruchstellen tauchen dann verlässlich auf. Erstens der Preis: Ein Frontier-Modell für eine simple Klassifikation von Support-Tickets zu bezahlen, ist Geldverbrennung. Zweitens die Datensouveränität: Personenbezogene oder regulierte Daten dürfen die eigene Infrastruktur oft nicht verlassen, egal wie gut die Verschlüsselung des Anbieters ist. Drittens der Lock-in: Wenn Ihre gesamte Anwendungslogik hart gegen ein API-Format verdrahtet ist, kostet ein Anbieterwechsel Monate.
Hinzu kommt die Ausfallsicherheit. Ein Single-Vendor-Setup bedeutet, dass ein Anbieterausfall Ihre gesamte KI stilllegt. 2026 ist das kein theoretisches Risiko mehr: Modell-Releases, Kapazitätsengpässe und regionale Ausfälle gehören zum Alltag, wenn man produktiv mit KI arbeitet. Wer nur einen Endpunkt hat, hat keine Ausweichoption.
Unsere Position ist deutlich: Die Frage ist nicht „welches Modell“, sondern „welches Modell für welche Aufgabe“. Und die Antwort gehört nicht in den Anwendungscode, sondern in eine Routing-Schicht. Das ist der eine architektonische Hebel, der alle vier Bruchstellen gleichzeitig adressiert.
Anthropic-first: warum Claude der Default ist
Wir arbeiten Anthropic-first, und das ist keine Glaubensfrage, sondern eine Kalibrierung. Für Reasoning, agentische Workflows und anspruchsvolle Codearbeit ist Claude bei unseren Kunden das qualitativ stärkste Modell. Mit Claude Opus 4.8 (verfügbar seit 28. Mai 2026) und dem stärker auf Agenten und Tool-Nutzung ausgelegten Claude Sonnet 5 (seit 30. Juni 2026) deckt die Familie die Bandbreite von „maximale Intelligenz“ bis „günstiger, agentischer Alltag“ ab. Beide bieten ein Kontextfenster von 1 Million Token, was für Codebasen und lange Dokumente entscheidend ist.
Default heißt bei uns: Wenn eine Aufgabe Urteilsvermögen, mehrstufiges Denken oder verlässliche Tool-Aufrufe verlangt, geht sie ohne Diskussion an Claude. Für den ToFu-Klassifikator, der zehntausende Tickets pro Tag sortiert, gilt das ausdrücklich nicht. Anthropic-first ist ein Startpunkt, keine Zwangsjacke.
Open-Weight on-premise für souveräne Workloads
Sobald Daten die eigene Infrastruktur nicht verlassen dürfen, endet die Managed-API-Diskussion. Hier kommen Open-Weight-Modelle ins Spiel, die Sie im eigenen Rechenzentrum betreiben. Die Landschaft 2026 ist reif genug, dass das keine Kompromisslösung mehr ist.
Drei Familien dominieren: Alibabas Qwen-3.5-Reihe (März 2026, unter der permissiven Apache-2.0-Lizenz), Metas Llama 4 und Mistrals Large 3 aus dem April 2026 mit rund 405 Milliarden Parametern und einem 256.000-Token-Kontextfenster. Beim Coding liegt Qwen vorn: Das 397B-Modell erreicht laut Alibaba 76,4 Prozent auf SWE-bench Verified. Für viele fachliche Workloads reicht ein deutlich kleineres Modell mit gezieltem Fine-Tuning völlig aus.
Der ehrliche Preis: On-Premise heißt GPU-Beschaffung, Modell-Serving, Monitoring und Patchen selbst betreiben. Das lohnt sich, wenn Souveränität nicht verhandelbar ist oder die Volumina so hoch sind, dass die Fixkosten der eigenen Hardware unter den variablen API-Kosten liegen. Ein weiterer, oft unterschätzter Vorteil: Ein einmal beschafftes und fein abgestimmtes Open-Weight-Modell bringt Preisstabilität. Sie sind nicht der Preispolitik eines Anbieters ausgeliefert, und Sie können das Modell so lange betreiben, wie es Ihre Anforderungen erfüllt, ohne erzwungene Migration auf eine neue Version. Welche Architekturvariante zu Ihrem Compliance-Rahmen passt, hängt am Detail. Wir haben die Optionen im Vergleich der DSGVO-Architekturen für ChatGPT, Azure OpenAI und Self-hosted gegenübergestellt. Den konkreten Stack für souveränes Hosting beschreiben wir im Deutschland-gehosteten AI-App-Stack.
Managed via Bedrock oder Azure, wenn der Betrieb weg soll
Zwischen „voller Managed-API“ und „alles selbst on-premise“ liegt eine dritte Option, die oft untergeht: dasselbe Modell managed über AWS Bedrock oder Azure betreiben. Sie behalten die Kontrolle über die Cloud-Region und die vertragliche Datenverarbeitung, geben aber Skalierung, Verfügbarkeit und Patch-Management ab. Für Teams ohne eigenes MLOps-Team ist das häufig der pragmatischste Weg, Standard-Workloads produktiv zu bekommen.
Als Microsoft Partner sehen wir bei Kunden oft eine bestehende Azure-Landung, in die sich ein Managed-Endpunkt sauber einfügt: gleiche Identitäts- und Netzwerkkontrollen, gleiches Kostencenter, kein neuer Betriebsprozess. Der Preis dieser Bequemlichkeit ist eine dünnere Souveränität als bei echtem On-Premise. Die Daten liegen in einer definierten Region, aber sie liegen bei einem Hyperscaler. Für interne, unkritische Workloads ist das der richtige Kompromiss. Für personenbezogene oder regulierte Daten bleibt der On-Premise-Pfad die belastbarere Wahl.
Die Entscheidung zwischen diesen drei Wegen sollte pro Workload fallen, nicht pro Unternehmen. Genau das erzwingt eine saubere Routing-Policy.
Das Gateway als Entkopplung plus Routing-Policy
Der technische Kern jeder Multi-Model-Strategie ist ein LLM-Gateway. Ihre Anwendung spricht nur noch mit dem Gateway, nie direkt mit einem Anbieter. Das Gateway entscheidet anhand einer Policy, welches Modell eine Anfrage bekommt, kümmert sich um Fallback-Ketten und liefert einheitliche Observability über alle Anbieter hinweg.
# Routing-Policy nach Datenklasse und Aufgabe
routes:
- name: reasoning-default
match:
data_class: internal
task: [reasoning, agent, code]
model: claude-opus-4-8 # Qualität und Agenten-Workloads
fallback: claude-sonnet-5
- name: souveraen-onprem
match:
data_class: restricted # personenbezogen, reguliert
model: qwen-3.5-onprem # läuft im eigenen Rechenzentrum
fallback: mistral-large-3-onprem
- name: masse-guenstig
match:
task: [classify, extract, summarize]
model: bedrock/claude-haiku-4-5Die Konfiguration oben ist bewusst simpel gehalten. Sie zeigt das Prinzip: Regulierte Daten verlassen nie das eigene Rechenzentrum, teure Reasoning-Anfragen gehen an das stärkste Modell, Massenaufgaben an das günstigste. Ändert sich die Preislage oder erscheint ein besseres Open-Weight-Modell, ist der Wechsel eine Änderung in dieser Datei, nicht ein Refactoring Ihrer Anwendung.
Seien wir ehrlich: Multi-Model erhöht die Betriebskomplexität. Sie betreiben mehr Endpunkte, müssen mehr Kosten- und Latenzprofile im Blick behalten und brauchen ein Audit über alle Modelle. Genau deshalb ist das Gateway kein optionaler Luxus, sondern die Bedingung, unter der Multi-Model überhaupt beherrschbar wird. Ohne zentrale Routing-Schicht handeln Sie sich statt einem Lock-in drei unkontrollierte Insellösungen ein, was am Ende teurer und riskanter ist als der eine Anbieter, den Sie vermeiden wollten.
Häufig gestellte Fragen
Was kostet eine Multi-Model-Architektur im Vergleich zu einem einzelnen Anbieter?
Die Gateway-Schicht selbst ist günstig, oft Open-Source oder eine schlanke Eigenentwicklung. Der eigentliche Hebel ist die Ersparnis: Wenn Sie Massenaufgaben auf günstige Modelle routen und nur Reasoning an Frontier-Modelle geben, sinken die variablen Kosten spürbar. On-Premise-Betrieb hat Fixkosten für GPUs, die sich erst ab einem gewissen Volumen rechnen. Wir modellieren das pro Workload, statt eine pauschale Zahl zu versprechen.
Anthropic-first plus Open-Weight, oder gleich alles Open-Weight self-hosted?
Alles self-hosted klingt nach maximaler Souveränität, ist aber für die meisten Teams die falsche Wahl. Sie zahlen den vollen Betriebsaufwand auch für Workloads, die nie regulierte Daten sehen, und verzichten bei anspruchsvollem Reasoning auf Qualität. Der Zangenangriff aus Claude für Qualität und Open-Weight für Souveränität liefert in der Praxis das bessere Verhältnis. Reines Open-Weight lohnt nur, wenn Souveränität für wirklich jeden Workload zwingend ist.
Erhöht ein zusätzliches Gateway nicht die Latenz?
Der Routing-Overhead liegt im niedrigen zweistelligen Millisekundenbereich und ist gegenüber der Antwortzeit eines Modells vernachlässigbar. Was Latenz tatsächlich treibt, ist die Modellwahl selbst. Genau deshalb gehört ein Latenz-Budget in die Policy: Zeitkritische Pfade routen Sie auf schnellere Modelle, Batch-Jobs dürfen langsamer sein.
Wie verhindert das Gateway, dass regulierte Daten doch an eine externe API gehen?
Über die Datenklasse als hartes Routing-Kriterium. Anfragen mit der Klasse „restricted“ werden ausschließlich auf On-Premise-Modelle geroutet, ein Fallback auf externe APIs ist für diese Klasse gesperrt. Kombiniert mit einem Audit-Log über jede Anfrage haben Sie den Nachweis, dass sensible Daten die eigene Infrastruktur nie verlassen haben.
Was passiert, wenn ein Modell ausfällt oder überlastet ist?
Genau dafür sind Fallback-Ketten da. Jede Route definiert ein Ausweichmodell derselben Datenklasse. Fällt der primäre Endpunkt aus oder liefert einen Fehler, greift das Gateway automatisch auf den Fallback zurück. Das erhöht die Ausfallsicherheit deutlich gegenüber einem Single-Vendor-Setup, bei dem ein Anbieterausfall Ihre gesamte KI stilllegt.
Nächster Schritt
Verwandte Themen
→Sovereign RAG: Architektur-Pattern für BaFin und BSI
