Multi-Modell-Strategie: Wie Unternehmen KI-Abhängigkeiten vermeiden

Die meisten Unternehmen, die heute KI produktiv einsetzen, haben dasselbe Problem wie Firmen, die vor zwanzig Jahren ihre gesamte IT-Infrastruktur auf einen einzigen Cloud-Anbieter migrierten: Sie merken die Abhängigkeit erst, wenn der Anbieter die Preise erhöht, ein Modell depreciert oder eine API-Änderung den Produktivbetrieb unterbricht. Ein Multi-Modell-Setup ist die architektonische Antwort auf dieses Risiko.

Warum Single-Vendor-Abhängigkeit ein strukturelles Risiko ist

Die Dynamik im Markt für Large Language Models ist ungewöhnlich volatil. Modelle, die heute als Industriestandard gelten, können innerhalb weniger Monate durch Nachfolger ersetzt werden, deren API-Signaturen, Kontextfenster und Ausgabeformate sich substanziell unterscheiden. Wer seine Anwendungslogik eng an ein spezifisches Modell koppelt, schreibt technische Schulden in die Architektur, bevor die erste Zeile Produktionscode deployed ist.

Hinzu kommt das Preisrisiko. Laut dem Stanford AI Index 2025 sind die Inferenzkosten für frontier-Modelle zwar im Durchschnitt gesunken, aber die Preisgestaltung einzelner Anbieter folgt keiner vorhersehbaren Kurve. OpenAI, Anthropic, Google und die aufkommenden Open-Source-Alternativen wie Meta Llama oder Mistral konkurrieren auf unterschiedlichen Dimensionen: Preis, Latenz, Kontextlänge, Multimodalität, Compliance. Wer nur einen Anbieter kennt, kann diese Dimensionen nicht gegeneinander ausspielen.

Die drei Schichten eines belastbaren Multi-Modell-Setups

Ein durchdachtes Multi-Modell-Setup ist keine Sammlung von API-Keys. Es besteht aus drei klar getrennten Schichten: der Abstraktionsschicht, der Routing-Logik und der Evaluierungsinfrastruktur. Wer diese Schichten nicht explizit designt, baut implizit eine Monokultur, auch wenn er mehrere Anbieter nutzt.

Die Abstraktionsschicht entkoppelt die Anwendungslogik von der konkreten Modell-API. Frameworks wie LiteLLM, LangChain oder LlamaIndex bieten hier standardisierte Interfaces, die es erlauben, das zugrundeliegende Modell zu wechseln, ohne Anwendungscode anzufassen. LiteLLM etwa unterstützt über 100 Modell-Endpunkte hinter einer einheitlichen OpenAI-kompatiblen API-Signatur. Das ist keine akademische Übung: Wenn ein Anbieter seine Preise verdoppelt oder ein Modell depreciert, ist der Wechsel eine Konfigurationsänderung, kein Refactoring-Projekt.

Die Routing-Logik entscheidet, welches Modell für welche Anfrage genutzt wird. Hier liegt der größte Hebel für Kostenoptimierung. Einfache Klassifikationsaufgaben, Zusammenfassungen kurzer Texte oder strukturierte Datenextraktion aus standardisierten Formularen erfordern kein frontier-Modell. Open-Source-Modelle, die lokal oder auf günstiger Infrastruktur laufen, erledigen diese Aufgaben zu einem Bruchteil der Kosten. Komplexe Reasoning-Tasks, mehrstufige Analysen oder Aufgaben mit hohem Fehlerpotenzial werden an leistungsstärkere Modelle geroutet. Dieses Prinzip nennt sich Modell-Routing oder Cascading und ist in Produktionssystemen bei Unternehmen wie Zalando und Deutsche Telekom dokumentiert.

"The organizations that will win with AI are not those that pick the best model today, but those that build the infrastructure to swap models tomorrow."

Andrej Karpathy, KI-Forscher und ehemaliger Director of AI bei Tesla, in einem öffentlichen Statement zur Modellstrategie, 2024

Evaluierungsinfrastruktur: Das unterschätzte Fundament

Wer mehrere Modelle betreibt, braucht eine systematische Methode, um deren Ausgaben zu vergleichen. Ohne Evaluierungsinfrastruktur ist ein Multi-Modell-Setup kein strategischer Vorteil, sondern organisiertes Chaos. Die Frage ist nicht, welches Modell im Benchmark-Test besser abschneidet, sondern welches Modell für den spezifischen Anwendungsfall des Unternehmens die konsistentere, korrektere und wirtschaftlichere Ausgabe produziert.

Tools wie LangSmith, Braintrust oder das Open-Source-Framework RAGAS ermöglichen es, Modellausgaben systematisch zu tracken, zu vergleichen und gegen definierte Qualitätskriterien zu evaluieren. Bosch hat in öffentlichen Beiträgen beschrieben, wie das Unternehmen interne Evaluierungs-Pipelines aufgebaut hat, um Modellwechsel datengetrieben zu entscheiden, statt auf Basis von Anbieter-Marketing. Dieser Ansatz ist auf den Mittelstand übertragbar: Eine einfache Evaluierungs-Pipeline mit 200 bis 500 repräsentativen Testfällen aus dem eigenen Geschäftsbetrieb ist in wenigen Wochen aufzubauen und liefert mehr Entscheidungssicherheit als jeder externe Benchmark.

Open Source als strategische Komponente, nicht als Kompromiss

Die Qualitätslücke zwischen proprietären frontier-Modellen und leistungsstarken Open-Source-Alternativen hat sich in den vergangenen zwölf Monaten erheblich verringert. Modelle der Llama-Familie, Mistral-Varianten und spezialisierte Fine-Tunes auf Basis dieser Architekturen erreichen auf domänenspezifischen Aufgaben oft Parität mit deutlich teureren proprietären Modellen. Für den DACH-Mittelstand ist das relevant, weil Open-Source-Modelle on-premise oder in einer privaten Cloud-Umgebung betrieben werden können, was Datenschutzanforderungen nach DSGVO und branchenspezifischen Compliance-Vorgaben deutlich einfacher erfüllbar macht.

Siemens hat öffentlich kommuniziert, dass das Unternehmen für interne Anwendungen, bei denen sensible Produktionsdaten verarbeitet werden, auf lokal betriebene Modelle setzt, während externe, weniger datensensitive Aufgaben über proprietäre APIs abgewickelt werden. Diese hybride Strategie ist kein Kompromiss, sondern eine bewusste Risikoverteilung: Datensouveränität für kritische Prozesse, Zugang zu frontier-Fähigkeiten für Aufgaben, bei denen das Modell keinen Zugriff auf schützenswerte Daten hat.

Für den Betrieb lokaler Modelle haben sich Plattformen wie Ollama, vLLM und Hugging Face TGI als Produktionsstandard etabliert. Sie ermöglichen es, Modelle mit standardisierten APIs zu betreiben, die kompatibel mit den Abstraktionsschichten sind, die ohnehin für das Multi-Modell-Setup benötigt werden. Der Infrastrukturaufwand ist real, aber kalkulierbar: Ein mittelgroßes Sprachmodell mit 7 bis 13 Milliarden Parametern läuft auf einem einzelnen GPU-Server, dessen Anschaffungskosten sich bei ausreichender Nutzung innerhalb von 12 bis 18 Monaten amortisieren.

Agentic Workflows und Multi-Modell: Besondere Anforderungen

Agentic Systeme, also KI-Architekturen, in denen Modelle autonom Werkzeuge aufrufen, Entscheidungen treffen und mehrstufige Aufgaben ausführen, stellen besondere Anforderungen an ein Multi-Modell-Setup. Hier reicht es nicht, verschiedene Modelle für verschiedene Aufgabentypen zu nutzen. Die Koordinationslogik zwischen Agenten, die Zuverlässigkeit von Tool-Calls und die Konsistenz von Ausgaben über mehrere Schritte hinweg müssen modellübergreifend gewährleistet sein.

Frameworks wie LangGraph, CrewAI oder das Microsoft AutoGen-Ökosystem ermöglichen es, Agenten-Workflows zu definieren, die modellunabhängig sind. Ein Orchestrator-Agent, der auf einem leistungsstarken frontier-Modell läuft, kann spezialisierte Sub-Agenten koordinieren, die auf günstigeren oder domänenspezifisch fine-getunten Modellen operieren. DHL hat in öffentlichen Präsentationen beschrieben, wie das Unternehmen Agenten-Architekturen für Logistikoptimierung einsetzt, bei denen verschiedene Modelle für Planung, Ausführung und Qualitätsprüfung zuständig sind. Dieses Prinzip der funktionalen Spezialisierung innerhalb eines Agenten-Systems ist der nächste Reifegrad nach dem einfachen Modell-Routing.

Was bedeutet das für Unternehmen?

Ein Multi-Modell-Setup ist kein Projekt, das man einmalig abschließt. Es ist eine Designentscheidung, die von Anfang an in die Architektur eingebaut werden muss. Wer heute mit einem einzelnen Anbieter startet und plant, später zu diversifizieren, unterschätzt den Refactoring-Aufwand, der entsteht, wenn Anwendungslogik eng an proprietäre APIs gekoppelt ist. Die folgenden Handlungsempfehlungen sind nach Priorität geordnet.

• ›Abstraktionsschicht von Tag eins: Nutze LiteLLM, LangChain oder ein vergleichbares Framework als Middleware zwischen Anwendungslogik und Modell-API. Kein Produktionscode sollte direkt gegen eine proprietäre API programmiert sein.
• ›Eigene Evaluierungs-Pipeline aufbauen: Definiere 200 bis 500 repräsentative Testfälle aus dem eigenen Geschäftsbetrieb und nutze sie, um Modellwechsel datengetrieben zu entscheiden. Tools wie Braintrust oder LangSmith reduzieren den Aufwand erheblich.
• ›Aufgaben nach Komplexität klassifizieren: Nicht jede Anfrage braucht das teuerste Modell. Implementiere Routing-Logik, die einfache Aufgaben an günstigere oder lokale Modelle delegiert. Das allein kann die Inferenzkosten um 30 bis 45 Prozent senken.
• ›Datensensitivität als Routing-Kriterium: Definiere, welche Daten das Unternehmen verlassen dürfen und welche nicht. Datensensitive Prozesse laufen auf lokalen oder privaten Modellen, unkritische Aufgaben können über externe APIs abgewickelt werden.
• ›Fallback-Mechanismen einplanen: Jeder Modell-Endpunkt kann ausfallen. Definiere für jeden Anwendungsfall einen primären und mindestens einen sekundären Anbieter. Automatisches Failover ist keine Kür, sondern Grundanforderung für produktionskritische Systeme.

Häufig gestellte Fragen

Ab welcher Unternehmensgröße lohnt sich ein Multi-Modell-Setup?

Die Frage der Unternehmensgröße ist weniger relevant als die Frage der KI-Nutzungsintensität. Sobald ein Unternehmen KI-Funktionen in produktionskritische Prozesse integriert, also Ausfälle oder Qualitätsprobleme direkte operative Konsequenzen haben, ist ein Multi-Modell-Setup gerechtfertigt. Das kann bereits bei 50 Mitarbeitern der Fall sein, wenn KI etwa in der Kundenkommunikation oder der Auftragsverarbeitung eingesetzt wird. Die initiale Investition in eine Abstraktionsschicht ist überschaubar und zahlt sich durch vermiedene Refactoring-Kosten und Kostenoptimierung schnell aus.

Wie komplex ist die Implementierung einer Abstraktionsschicht?

Mit modernen Frameworks wie LiteLLM ist die grundlegende Implementierung einer Abstraktionsschicht eine Aufgabe von wenigen Tagen, nicht Wochen. LiteLLM stellt eine OpenAI-kompatible API bereit, die Anfragen an über 100 verschiedene Modell-Endpunkte weiterleiten kann. Die eigentliche Komplexität liegt nicht in der technischen Integration, sondern in der Definition der Routing-Logik und der Aufbau der Evaluierungsinfrastruktur. Für ein erstes produktionsfähiges Setup sollte man mit vier bis acht Wochen Engineering-Zeit rechnen.

Welche Risiken entstehen durch den Betrieb mehrerer Modelle gleichzeitig?

Das größte operationale Risiko ist Inkonsistenz: Verschiedene Modelle produzieren für ähnliche Eingaben unterschiedliche Ausgaben, was in Anwendungen, die auf konsistentes Verhalten angewiesen sind, zu Problemen führen kann. Dieses Risiko wird durch eine solide Evaluierungsinfrastruktur und klare Aufgabentrennung zwischen Modellen beherrschbar. Hinzu kommt der erhöhte Monitoring-Aufwand: Mehrere Modell-Endpunkte müssen überwacht, Fehler müssen modellspezifisch analysiert werden. Dieser Aufwand ist real, aber mit modernen Observability-Tools wie LangSmith oder Helicone gut handhabbar.

Wie geht man mit unterschiedlichen Ausgabeformaten verschiedener Modelle um?

Strukturierte Ausgaben sind der Schlüssel. Wer Modelle anweist, ihre Antworten in einem definierten JSON-Schema zu liefern, und dieses Schema über alle Modelle hinweg konsistent hält, reduziert die Abhängigkeit von modellspezifischen Ausgabeformaten erheblich. Frameworks wie Instructor oder das native Structured-Output-Feature moderner Modell-APIs helfen dabei, konsistente Datenstrukturen zu erzwingen, unabhängig davon, welches Modell die Anfrage bearbeitet. Das ist eine Designentscheidung, die von Anfang an getroffen werden muss.

Wie beeinflusst ein Multi-Modell-Setup die DSGVO-Compliance?

Ein durchdachtes Multi-Modell-Setup kann die DSGVO-Compliance verbessern, nicht verschlechtern. Indem datensensitive Verarbeitungsschritte explizit auf lokale oder EU-basierte Modell-Endpunkte geroutet werden, lässt sich sicherstellen, dass personenbezogene Daten das Unternehmen oder die EU nicht verlassen. Die Routing-Logik wird damit zum Datenschutz-Enforcement-Mechanismus. Wichtig ist, dass diese Zuordnung dokumentiert und auditierbar ist, was mit modernen Observability-Tools ohne großen Mehraufwand realisierbar ist.