KIGenAI & LLMsSoftware & SaaS

Offene vs. geschlossene KI-Modelle: warum die naheliegende Wahl immer wieder falsch ist

Die meisten Organisationen wählen ihre Deployment-Strategie für KI-Modelle nach einer einfachen Geschichte: Open Source ist flexibel und günstig, geschlossene APIs sind leistungsfähig und schnell. Diese Geschichte lässt genau die Punkte weg, die darüber entscheiden, ob ein Deployment gelingt oder scheitert.

🎙️

Podcast anhören

4 min

Die Debatte über offene versus geschlossene KI-Modelle gehört 2026 zu den verlässlichsten Agendapunkten auf jedem Technologieforum für Unternehmen. Auf der einen Seite: Metas Llama-Familie, die Releases von Mistral und ein wachsender Katalog an Modellen, die Sie herunterladen, fine-tunen und auf eigener Infrastruktur betreiben können. Auf der anderen: OpenAIs GPT-4o und die o-Serie, Anthropics Claude 3.5 und Nachfolger, Googles Gemini 1.5 Pro. Die Gegenüberstellung ist verführerisch, weil sie auf vertraute betriebswirtschaftliche Reflexe passt: build vs. buy, Kontrolle vs. Bequemlichkeit, Kosten vs. Leistungsfähigkeit.

Das Problem ist, dass diese Gegenüberstellung für jeden, der echte Deployment-Entscheidungen trifft, zunehmend in die Irre führt.

Die gängige Sichtweise, fair dargestellt

Die Standardposition, die durchaus ihre Berechtigung hat, lautet etwa so. Geschlossene Modelle bieten Spitzenleistung in Benchmarks, laufende Verbesserung ohne Wartungsaufwand und schnelle Time-to-Deployment über API. Sie sind die vernünftige Standardwahl für Organisationen ohne tiefes ML-Engineering. Offene Modelle bieten dagegen Datenschutz (keine Logs, die an einen Anbieter gehen), Anpassung über Fine-Tuning und langfristig geringere Kosten bei Skalierung. Sie sind sinnvoll, wenn Sie sensible Daten, spezifische Domänenanforderungen oder ausreichend Volumen haben, um die Infrastrukturinvestition zu rechtfertigen.

Das entspricht in etwa dem Rat, den Sie in McKinseys Umfragen zur Generative-AI-Adoption 2025 und in Gartners Leitlinien zum LLM-Sourcing finden. Es ist nicht falsch. Eine Anwaltskanzlei, die vertrauliche M&A-Dokumente verarbeitet, sollte vermutlich nicht jede Anfrage über eine externe API leiten. Ein Startup, das einen kundenseitigen Chatbot ohne Datensensibilität mit zwei Entwicklern baut, sollte das vermutlich schon. Der Konsens hat seinen Platz verdient, weil er reale Tradeoffs abbildet.

Wo der Konsens auseinanderfällt

Der erste blinde Fleck ist die Annahme, „offen“ bedeute „Sie haben die Kontrolle“. Llama 3.1 70B herunterzuladen und Inferenz auf Azure oder AWS laufen zu lassen, macht Sie nicht infrastrukturunabhängig. Sie haben eine Anbieterabhängigkeit gegen mehrere getauscht: den Cloud-Provider, die Schicht zur Inferenzoptimierung (oft vLLM oder TGI, jede mit eigener Wartungsfläche) und die Hardware-Lieferkette. Der operative Aufwand ist erheblich. Ein Modell mit 70B Parametern bei Produktionsdurchsatz braucht ernstzunehmende GPU-Kapazität. Wenn diese Kapazität bei einem Hyperscaler gemietet wird, beginnt Ihre Kostenstruktur dem API-Szenario zu ähneln, nur ohne die Zusagen zur Verfügbarkeit.

Der zweite Punkt ist die Annahme einer Leistungslücke, die der Konsens als fix behandelt. Mitte 2026 hat sich der Abstand zwischen geschlossenen Frontier-Modellen und den besten offenen Releases deutlich verringert. Die aktuellen Releases von Mistral und Metas Llama-3.x-Familie liefern bei einer breiten Palette von Unternehmensaufgaben konkurrenzfähige Ergebnisse. Bei strukturierter Extraktion, Klassifikation und Zusammenfassung in bestimmten Domänen schlägt ein fine-getuntes offenes Modell oft eine geschlossene Allzweck-API. Der gängige Rat entstand, als GPT-4 keine ernsthafte offene Konkurrenz hatte. Diese Zeit ist vorbei.

Drittens: Das Datenschutzargument für offene Modelle wird oft mit mehr Überzeugung vorgetragen, als die Realität hergibt. Ein selbst gehostetes Modell beseitigt das Risiko von Query-Logs beim Modellanbieter. Es beseitigt nicht die Risikofläche, die Ihr eigenes Infrastrukturteam, die Zugriffsrichtlinien Ihres Cloud-Providers oder die häufig unterbesetzten Sicherheitspraktiken rund um Modellgewichte und Fine-Tuning-Pipelines erzeugen. Anthropics Unternehmensverträge (Anthropic ist hier Anbieter, behandeln Sie die Angaben entsprechend) enthalten Auftragsverarbeitungsvereinbarungen und Zero-Retention-Optionen, die einen belastbaren vertraglichen Schutz bieten. Für viele Rechts- und Compliance-Teams ist diese vertragliche Klarheit greifbarer als die theoretische Reinheit des Self-Hosting.

Der vierte und am meisten unterschätzte Punkt sind Latenz und Zuverlässigkeit im Produktivbetrieb. Geschlossene APIs, besonders die Enterprise-Tiers von OpenAI und Anthropic, sind deutlich gereift. Selbst betriebene Inferenz-Cluster fallen auf Weisen aus, die schwerer zu debuggen und schwerer personell abzudecken sind. Das Engineering-Team, das Ihr Llama-Deployment aufgesetzt hat, wird gehen. Die Person, die die vLLM-Konfiguration verstanden hat, wechselt in eine andere Rolle. Abhängigkeiten von geschlossenen APIs sind zumindest standardisierte Ausfälle.

Was ein scharfsinniger Verantwortlicher tatsächlich tun sollte

Die praktische Antwort ist keine Entweder-oder-Entscheidung. Die meisten Organisationen, die 2026 KI im Produktivbetrieb haben, betreiben ein Portfolio, und die interessante Frage ist, wie man die Arbeit darin verteilt.

Standardisierte Aufgaben mit hohem Volumen und geringer Sensibilität, etwa Dokumentklassifikation, Zusammenfassung von Meetings oder erste Textentwürfe, sind starke Kandidaten für offene Modelle, besonders wenn Sie die Engineering-Kapazität haben, sie im Maßstab zu betreiben, und Kosteneinsparungen über die Zeit belegen können. Die Rechnung kippt bei Volumen schnell. Ein Unternehmen, das 10 Millionen Dokumente pro Jahr verarbeitet, hat starke Anreize, diese Inferenz selbst zu besitzen.

Aufgaben, die Frontier-Reasoning oder mehrstufige Planung erfordern oder bei denen Fehler teuer sind (medizinische Triage, komplexe Vertragsanalyse, Finanzberatungs-Outputs), sollten auf geschlossene Modelle setzen, mindestens solange, bis das offene Ökosystem auf diesem Niveau konsistente, prüfbare Ergebnisse liefert. Die Frage der Verantwortlichkeit zählt hier: Anbieter geschlossener Modelle haben vertragliche und reputationsbezogene Interessen an Zuverlässigkeit. Ein offenes Modell, das Sie selbst betrieben haben, nicht.

Offene Modelle auf proprietäres Wissen zu fine-tunen, bleibt wirklich wertvoll, aber nur wenn Sie eine klare Domäne, genügend gelabelte Beispiele für eine saubere Umsetzung und die Evaluations-Infrastruktur haben, um zu erkennen, ob es funktioniert hat. Ein Allzweckmodell auf ein paar hundert Beispielen zu fine-tunen und das Ergebnis ein spezialisiertes System zu nennen, ist ein verbreiteter Fehler, und es entstehen Systeme, die auf domänenspezifische Weise selbstbewusst falsch sind.

Die wichtigste Entscheidung ist oft nicht, welches Modell, sondern an welcher Stelle im Workflow das Modell sitzt. Ein geschlossenes Modell für die Synthese und ein offenes Modell für Retrieval und Filterung ist ein verbreitetes Muster, das weniger Aufmerksamkeit bekommt als die schlagzeilentaugliche Anbieterwahl.

Verteilen Sie Ihre Modelle nach tatsächlichen Aufgabenanforderungen, nicht nach Ideologie. Die Organisationen, die 2026 den größten Nutzen aus KI ziehen, haben das als Engineering- und Risikofrage behandelt und nicht als Frage der Anbietertreue. In diesem Unterschied liegt der eigentliche Unterschied in den Ergebnissen.

Mehr dazu

Die Lektionen, die diesen Artikel weiterführen, frei zugänglich.

  1. 1Kosten, Latenz und Abwägungen bei der ModellauswahlBuilding with AI
  2. 2Den richtigen Ansatz wählen: Prompt, RAG, Fine-Tuning oder AgentBuilding with AI
  3. 3Outputs bewerten: Woher wissen Sie, dass es funktioniert?Building with AI
  4. 4Privacy und vertrauliche Daten: was Sie nicht einfügen solltenVerantwortungsvolle und vertrauenswürdige KI
  5. 5Die Landschaft der KI-Tools: APIs, No-Code und VektordatenbankenBuilding with AI

Artikel gelesen?

Bestätigen Sie Ihre Lektüre, um XP zu sammeln und Ihr Radar zu füttern.