Multi-Model-KI ist jetzt ein Plattformproblem, kein Anbieterproblem

Jeder Platform-Verantwortliche, der schon einmal versucht hat, sich auf einen einzigen LLM-Anbieter zu standardisieren, kennt das Muster: In Q1 ein Modell auswählen, in Q2 zusehen, wie ein Wettbewerber es überholt, und in Q3 dem Finance-Team erklären, warum die Ausschreibung inzwischen irrelevant ist. Die Woche des 24. September 2026 hat diese Frustration zu einer architektonischen Tatsache gemacht. Zwei führende Labs haben zusammen vier Modelle veröffentlicht, und ein Sicherheitsanbieter hat im selben Nachrichtenzyklus eingestanden, dass kein einzelnes Modell allein ausreicht.

Die Single-Vendor-KI-Strategie ist nun offiziell ein Legacy-Muster. Teams, die ihre 2026er-Roadmap darauf aufgebaut haben, werden Q4 damit verbringen, sie neu zu schreiben.

Was passiert ist

Anthropic hat Claude Opus 5.5 vorgestellt und positioniert es als Modell, das mit dem höherrangigen Fable 5.1 vergleichbare Leistung bei geringeren Betriebskosten bietet. In derselben Woche hat OpenAI gleich zwei Modelle veröffentlicht: GPT-6 Sol, optimiert für höhere Reasoning-Kapazität, und GPT-6 Luna, konzipiert für schnellere Workloads mit hohem Volumen. Zwei Labs, zwei verschiedene Segmentierungsstrategien, eine gemeinsame Botschaft: Die Ära des reinen Flagship-Modells ist vorbei.

Wie AI Business berichtete, signalisieren die Veröffentlichungen, dass führende Anbieter nun nach Preis, Leistung und Spezialisierung differenzieren, anstatt ein einziges Parademodell zu produzieren. Das verändert die Einkaufsfrage für Enterprise-IT grundlegend. Jeet Pattanaik, Gründer und CTO von Glokal AI, formulierte es direkt: „Die Entscheidung verlagert sich von der Beschaffung zur Architektur." Pattanaik ging noch weiter und argumentierte, dass Teams zunehmend entscheiden müssen, welches Modell zu welchem Workload passt – und diese Entscheidungen überdenken müssen, wenn Anbieter neue Modelle veröffentlichen.

In derselben Woche gab es zwei weitere Datenpunkte, die mehr Gewicht haben als die Modellveröffentlichungen selbst. Salesforce hat seine KI-Plattform weiter ausgebaut, um mehrere Modelle zu unterstützen, und durch die NVIDIA-Partnerschaft offene Modelle in Agentforce und Missionforce integriert. Und Palo Alto Networks hat am 24. September einen KI-Cybersecurity-Dienst eingeführt, der Anthropics Claude Mythos, OpenAIs GPT-5.6-Cyber und Open-Weight-Modelle kombiniert – wobei das System selbst entscheidet, welches Modell welche Sicherheitsaufgabe übernimmt. Versteckt in ihrer Ankündigung: Interne Tests ergaben, dass kein einzelnes Modell mehr als 40 % der Schwachstellen in komplexen Umgebungen erkannte.

Diese Zahl verdient eine zweite Lektüre. Es ist der ehrlichste Satz, den ein Sicherheitsanbieter in diesem Jahr über LLMs veröffentlicht hat.

Technische Analyse

Was die Ankündigungen zusammen beschreiben, ist ein Router-und-Portfolio-Muster, das das Wrapper-und-Flagship-Muster ablöst. In der Wrapper-Ära wählte man GPT-4 oder Claude, schrieb eine dünne Abstraktionsschicht und hoffte, dass die Prompts bei kleinen Versions-Updates stabil blieben. In der Router-Ära ist die Abstraktionsschicht das Produkt. Sie entscheidet pro Anfrage, welches Modell den Traffic erhält.

Die Routing-Entscheidung hat drei Eingaben: Fähigkeit, Latenz und Kosten. Anthropics Positionierung von Opus 5.5 als Fable-5.1-vergleichbar zu geringeren Kosten ist ein direktes Argument für die Kostenachse. OpenAIs Aufteilung von GPT-6 in Sol und Luna ist ein Argument für die Capability-vs.-Latenz-Achse. Sol für reasoning-intensive Pfade, Luna für Hochvolumen-Pfade, bei denen P95-Latenz und Kosten pro Token dominieren. Kein Lab fragt Sie, für welches Sie sich entscheiden. Beide verlangen von Ihnen, zu routen.

Palo Altos 40-%-Erkennungsgrenze erklärt, warum Routing für alles Relevante keine Option, sondern Pflicht ist. Wenn das beste einzelne Modell 60 % der Schwachstellen in komplexen Umgebungen übersieht, ist Ensemble-Routing keine Optimierung – es ist die minimal tragfähige Architektur. Dieselbe Logik gilt außerhalb der Security. Betrugserkennung, Vertragsanalyse, klinisches Triage, KYC, Compliance-Zusammenfassungen: In jedem Bereich, in dem Recall wichtiger ist als Komfort, entsteht ein Portfolio – ob der CTO es geplant hat oder nicht.

Die damit verbundene Engineering-Oberfläche ist real. Sie benötigen jetzt modellunabhängige Prompt-Templates, modelläre Eval-Suites, eine Routing-Policy-Engine, Kosten-Telemetrie pro Modell und Workload sowie eine Versionierungsstrategie für den Fall, dass Anbieter mitten im Quartal neue SKUs veröffentlichen. Sowohl die Anthropic API-Dokumentation als auch die OpenAI-Plattformdokumentation setzen inzwischen voraus, dass Sie mehrere Modelle in derselben Anwendung betreiben – aber der Klebstoff dazwischen ist Ihr Problem.

Meine Einschätzung: Die Gewinner der nächsten 18 Monate werden nicht die Teams mit den besten Prompts sein. Es werden die Teams mit den besten Evals und der schnellsten Modell-Austausch-Pipeline sein. Bei Produktionsvorfällen in Fintechs, die ich beobachtet habe, liegt die Fehlerquelle fast nie beim Modell selbst. Es ist die Annahme, dass sich ein Modell in Woche 12 genauso verhält wie in Woche 1.

Wer Probleme bekommt

Drei Gruppen sind derzeit gefährdet.

Erstens iGaming- und Fintech-Plattformen, die sich 2025 für Betrug, KYC und Player-Support-Agenten auf einen einzigen Anbieter standardisiert haben. Diese Teams haben Kostenmodelle gegen die Preiskurve eines Anbieters aufgebaut. Anthropics Kosten-Paritäts-Aussage für Opus 5.5 und OpenAIs Luna-Tier für Hochvolumen-Workloads bedeuten, dass das Finanzargument für die Single-Vendor-Strategie gerade erodiert ist. Wenn Luna für Chat-intensive Support-Flows deutlich günstiger ist als der aktuelle Weg, findet Ihr CFO das heraus, bevor Sie es tun.

Zweitens Security-Teams. Palo Alto Networks hat öffentlich die Grenze benchmarkt: unter 40 % Erkennung in komplexen Umgebungen für jedes einzelne Modell. Jedes SOC, das noch alles Triage durch ein einziges LLM leitet, hat ein vor Gericht schwer zu verteidigendes Problem, wenn beim nächsten Incident-Post-Mortem gefragt wird, warum das Ensemble-Muster nicht eingesetzt wurde. Die unbequeme Lektüre: Single-Model-Security-KI entspricht heute dem Betreiben einer einzigen AV-Engine im Jahr 2010. Teams, mit denen ich in Amsterdam zusammengearbeitet habe, haben vor einem Jahrzehnt genau aus diesem Grund auf Single-Engine-Erkennung verzichtet.

Drittens Enterprise-Software-Anbieter ohne Multi-Model-Strategie. Salesforces Erweiterung auf Multi-Model-Unterstützung, kombiniert mit der NVIDIA-Partnerschaft, die offene Modelle in Agentforce und Missionforce bringt, setzt die Referenzarchitektur für die Kategorie. Wenn die KI-Funktionen eines SaaS-Anbieters noch an einen einzigen Anbieter gebunden sind, werden Beschaffungsteams anfangen zu fragen, warum. Das ist kein gutes Gespräch in einem RFP-Prozess.

Die nächsten 90 Tage sehen für alle drei Gruppen ähnlich aus: Prüfen Sie, welche Workloads an welches Modell gebunden sind. Bauen Sie einen Shadow-Routing-Prototypen. Etablieren Sie per-Workload-Eval-Suites, die in unter einem Tag gegen ein neues Modell ausgeführt werden können. Wenn die Bewertung einer neuen SKU eine Woche dauert, können Sie mit dem Release-Tempo, das die Labs jetzt vorgeben, nicht mithalten.

Playbook für KI-Entwicklung

Konkrete Schritte für diese Woche, nicht dieses Quartal.

Richten Sie eine Routing-Schicht ein, auch eine einfache. Eine konfigurationsgesteuerte Zuordnung von Workload-Typ zu Modell-ID reicht aus, um anzufangen. Sie verschafft Ihnen die Möglichkeit, Modelle auszutauschen, ohne einen Refactor durchzuführen. Wenn Sie Opus 5.5 nicht durch Bearbeiten einer Konfigurationsdatei gegen das ersetzen können, was Sie letzten Monat auf Claude betrieben haben, ist das Ihr erster Bug.

Schreiben Sie Evals, bevor Sie Prompts schreiben. Definieren Sie für jeden Workload die drei häufigsten Fehlermodi und den kleinstmöglichen Testdatensatz, der diese abdeckt. Fünfzig Beispiele sind besser als keine. Führen Sie den Datensatz bei jeder neuen Modellveröffentlichung erneut aus, einschließlich kleinerer Versions-Updates. Die Palo-Alto-Zahl ist ein Geschenk: Sie gibt Ihnen die Erlaubnis, dem Management zu erklären, dass Ensemble-Ansätze bei allem mit echten Recall-Anforderungen besser abschneiden als ein einzelnes Modell.

Verfolgen Sie Kosten pro erfolgreichem Ergebnis, nicht Kosten pro Token. Dass Luna billiger pro Token ist als Sol, bedeutet nichts, wenn Sol das Ticket in einem Aufruf löst und Luna drei benötigt. Instrumentieren Sie den gesamten Flow. Bei Produktionsvorfällen, die ich gesehen habe, sehen die Token-Dashboards großartig aus – bis die Retry-Stürme in der Rechnung auftauchen.

Halten Sie schließlich eine Open-Weight-Option warm. Salesforce und Palo Alto ziehen beide offene Modelle aus einem guten Grund in ihre Stacks. Ein fein abgestimmtes offenes Modell über Hugging Face oder einen vergleichbaren Inference-Anbieter zu hosten, gibt Ihnen ein Argument im nächsten Preisgespräch und einen Fallback, wenn eine proprietäre API einen schlechten Tag hat.

Wichtigste Erkenntnisse

• Die Single-Vendor-LLM-Strategie ist überholt. Anthropics Kosten-Positionierung von Opus 5.5 und OpenAIs Sol/Luna-Aufteilung sind Portfolio-Entscheidungen, keine Flagship-Auffrischungen.
• Palo Alto Networks' Offenbarung, dass kein einzelnes Modell mehr als 40 % der Schwachstellen in komplexen Umgebungen erkennt, ist das stärkste öffentliche Argument für Ensemble-Routing bis heute.
• Routing, Evals und per-Workload-Kosten-Telemetrie sind jetzt zentrale Plattformanliegen, keine Nebenprojekte des KI-Teams.
• Salesforces Multi-Model-Erweiterung durch die NVIDIA-Partnerschaft ist die Referenzarchitektur, die Enterprise-Käufer von jedem SaaS-Anbieter erwarten werden.
• Teams, die ein Modell nicht per Konfiguration austauschen und Evals in unter einem Tag erneut ausführen können, werden innerhalb von zwei Quartalen hinter dem Release-Tempo zurückbleiben.