Open Weights oder Frontier-Modell? Die Frage ist falsch gestellt

TL;DR: Die meisten Mittelständler fragen „Welches KI-Modell ist das beste?" und meinen den oberen Rand einer Benchmark-Tabelle. Das ist die einzige Frage, die für ihren Alltag fast nie entscheidet. Die richtige lautet nicht welches, sondern was optimiere ich: rohe Spitzenfähigkeit, oder Kontrolle, Portabilität, Anpassbarkeit und Betriebskosten? An der absoluten Spitze führen proprietäre Frontier-Modelle (GPT, Claude, Gemini) — aber der Bauch der betrieblichen Last braucht sie gar nicht. Die reife Antwort ist meist kein Lager, sondern ein Router: Volumen läuft auf einem eigenen, offenen Modell, die seltene Spitzenanfrage geht raus. Unten der Entscheidungsrahmen, mit dem Sie das selbst sortieren.

---

Die unbequeme These zuerst

Viele Betriebe kaufen einen Formel-1-Motor, um damit zum Bäcker zu fahren. Sie optimieren auf die Benchmark-Spitze — und lösen ein Problem, das sie gar nicht haben. Denn 90 Prozent der KI-Aufgaben in einem normalen Unternehmen sehen so aus: E-Mails klassifizieren, Angebote zusammenfassen, Felder aus Rechnungen extrahieren, Tickets routen, Fragen aus dem eigenen Dokumentenbestand beantworten. Keine dieser Aufgaben braucht ein Frontier-Genie. Sie braucht Verlässlichkeit — und Verlässlichkeit ist keine Eigenschaft des Modells, sondern eine Eigenschaft Ihrer Kontrolle über das Modell.

Deshalb ist „Open oder proprietär" die falsche Frage. Die echte Frage ist eine Optimierungsfrage. Sortieren wir sie ehrlich, in beide Richtungen.

Die Fähigkeit — ehrlich, ohne Lager

Zwei Dinge stimmen gleichzeitig, und beide muss man aushalten.

Erste Hälfte, Richtung Open-Source-Romantiker: An der absoluten Spitze führen die proprietären Frontier-Modelle. Bei mehrstufigem Reasoning, bei anspruchsvollem Coding über große Codebasen, bei sehr langen, kohärenten Kontexten liegen GPT-5-Klasse, Claude (Opus/Sonnet) und Gemini heute vorne. Das ist messbar, kein Marketing. Wer einen Agenten baut, der eigenständig ein Refactoring über zwanzig Dateien plant, merkt den Unterschied.

Zweite Hälfte, Richtung Frontier-Optimisten: Der Abstand schrumpft schneller, als die meisten Roadmaps annehmen. DeepSeek hat gezeigt, dass starkes Reasoning nicht hinter einer geschlossenen API leben muss. Qwen ist in Extraktion und Tool-Use ernstzunehmen. Llama und Mistral sind robuste Arbeitspferde für Klassifikation, Zusammenfassung und RAG. Gemma deckt das schlanke On-Premise-Segment ab — und mit dem deutschen Teuken existiert ein auf europäische Sprachen trainiertes Modell, relevant, wenn deutschsprachige Nuance zählt und Datenhoheit kein Nachgedanke ist.

Die nicht-offensichtliche Einsicht dazwischen: Die Benchmark-Spitze und Ihre tatsächliche Arbeitslast sind zwei verschiedene Verteilungen. Die Qualität entsteht selten im letzten Fähigkeits-Prozent des Modells — sie entsteht im Drumherum: in den Daten, im Prompt, im Retrieval. Ein gut angebundenes offenes Modell mit sauberem Retrieval schlägt ein Frontier-Modell mit schlechtem Kontext jeden Tag. Für den Bauch der Mittelstands-Last ist die Spitze schlicht überdimensioniert.

Damit ist die Fähigkeitsfrage geklärt — und genau deshalb war sie nie die eigentliche Frage. Sehen wir uns die Achsen an, die wirklich entscheiden.

Achse 1: Kontrolle und Daten

Ein proprietäres Frontier-Modell ist eine fremde API. Sie mieten Intelligenz pro Token, ohne Maschinenraum, brillant ab Tag eins. Ein Open-Weights-Modell — Llama, Mistral, Qwen, Gemma, DeepSeek, Teuken — kehrt das Verhältnis um: Die Gewichte liegen bei Ihnen, das Modell läuft im eigenen Haus oder bei einem Hoster Ihrer Wahl, die Daten verlassen den Hof nicht.

Das ist kein US-Feindbild. Eine API von OpenAI ist nicht „böse". Es ist eine nüchterne Frage der Wahl: Wer Patientendaten, Konstruktionspläne oder Mandantenakten verarbeitet, will die Kontrolle vielleicht nicht abgeben. Pro-EU heißt hier Datenhoheit, nicht Protektionismus. Wo genau Ihre KI laufen sollte — On-Prem, EU-Cloud, souverän gehostet — ist eine eigene Entscheidung; wir behandeln sie im Schwesterstück Wo Mittelstands-KI laufen sollte. Hier zählt nur der Hebel: Bei offenen Gewichten entscheiden Sie, wo die Daten liegen.

Achse 2: Lock-in und Portabilität

Der oft unterschätzte Punkt — und der eigentlich strategische: Ein proprietäres Modell kann sich unter Ihnen verändern. Ein stilles Versions-Update, und ein Prompt, der gestern sauber lief, driftet heute. Das ist keine Verschwörung, das ist Produktpflege — nur dass Ihr Produkt darauf steht. Wer hier keine Evals und keine Observability fährt, merkt die Regression erst, wenn der Kunde sie meldet.

Ein heruntergeladenes Open-Weights-Modell friert ein. Qwen3 von heute ist das Qwen3 von in zwei Jahren. Es altert, aber es kippt nicht über Nacht. Sie entscheiden, wann Sie upgraden, nicht der Anbieter.

Und jetzt die Einsicht, die das Ganze trägt: Lock-in ist kein Preisproblem, es ist ein Architekturproblem. Die Abhängigkeit, die wirklich weh tut, entsteht nicht durch die Rechnung — sie entsteht, wenn Ihre Prompts, Ihre Tool-Definitionen, Ihre ganze Logik um die Eigenheiten eines Anbieters herum gewachsen sind. Dann ist „den Anbieter wechseln" kein Konfig-Flag, sondern ein Umbau. Offene Standards wie das Model Context Protocol (MCP) sind genau dagegen die Versicherung: Sie entkoppeln Werkzeuge und Daten vom konkreten Modell, sodass das Modell zur austauschbaren Komponente wird statt zum Fundament.

Achse 3: Anpassbarkeit

Open erlaubt echtes Fine-Tuning und Distillation. Sie können ein kleines Qwen auf Ihre Domäne trimmen, bis es Ihren Fachjargon besser trifft als jedes Generalisten-Frontier — oder ein großes Modell in ein schlankes, spezialisiertes destillieren, das Ihre eine Aufgabe besser kann als jedes Allround-Modell. Bei einer proprietären API endet Ihre Anpassung am Prompt-Fenster, begrenzt auf das, was der Anbieter freigibt. Wenn die Aufgabe eng und das Volumen hoch ist, lohnt sich ein kleines, spezialisiertes Modell auf eigener Hardware oft mehr als der ständige Griff zur Spitze.

Achse 4: Kostenstruktur — qualitativ

Proprietär ist reine Nutzungsabrechnung: Sie zahlen pro Token, ohne eigenen Ops-Aufwand, bequem ab Tag eins. Open verschiebt die Kosten weg von der Nutzungsabrechnung hin zu Betrieb — und je nach Setup zu Hardware: Self-Hosting auf gemieteter GPU-Infrastruktur bleibt Opex (Compute plus Personal), echtes Capex entsteht erst mit eigenem Blech. In beiden Fällen wird die Kurve bei hohem Volumen planbar statt nutzungsgetrieben.

Damit kein Missverständnis entsteht: Das ist keine Open-Source-Romantik. Open-Weights bedeutet Ops-Verantwortung, die Sie tragen müssen. Es existiert eine Schwelle, ab der sich die Logik strukturell dreht — als grober Anker: wenn dieselbe einfache Aufgabe täglich fünf- bis sechsstellig oft läuft, kippt die Rechnung typischerweise Richtung eigenem Modell. Wo genau, hängt vom Fall ab, aber dass die Schwelle existiert, ist sicher. Frontier-proprietär ist die ehrlich richtige Wahl, wenn Sie schnell starten wollen oder schlicht kein Ops-Team haben.

Die reife Antwort: ein Router, kein Lager

Selten ist die Antwort „entweder-oder". Meist ist sie ein Router. Die Masse der einfachen, datensensiblen, hochvolumigen Last läuft auf Ihrem eigenen Open-Modell — günstig im Stückbetrieb, kontrollierbar, im Haus. Die seltene Spitzenanfrage, die nachweislich mehr Fähigkeit braucht, geht an ein Frontier-Modell. So zahlen Sie Frontier-Niveau nur dort, wo es den Aufpreis verdient — statt pauschal für jede Banalität.

Ihr Entscheidungsrahmen

Zum Mitnehmen, ohne Schnörkel:

• Frontier-proprietär, wenn Sie schnell starten wollen, kein Ops-Team haben, die Volumina niedrig sind und gelegentlich echte Spitzenleistung zählt. Die Fähigkeit ist sofort da, ohne Infrastruktur.
• Open-Weights, wenn Datenhoheit kritisch ist, das Volumen hoch, Anpassung nötig — oder Sie langfristig die Kontrolle und Portabilität behalten wollen.
• Router/Hybrid, sobald Sie beides haben: viel Routine und seltene harte Fälle. Das ist für die meisten gewachsenen Betriebe der Normalfall.

Zwei Dinge gehören in beide Welten, egal wofür Sie sich entscheiden. Erstens: Evals und Observability sind Pflicht — das proprietäre Modell kann unter Ihnen driften, das offene betreiben Sie selbst; ohne Messung merken Sie eine Regression in keinem der beiden Fälle rechtzeitig. Zweitens: Wer ein Modell Werkzeuge bedienen lässt, muss es absichern — die Kontrolle über handelnde Agenten ist kein Add-on, sondern Teil der Architektur.

Die Pointe

Niemand fährt seine gesamte Logistik mit dem Rennwagen. Man hat eine Flotte — Transporter für das Volumen, den Rennwagen für die eine Strecke, wo er zählt. Die Frage war nie „Open oder proprietär". Sie lautet: Für welche Strecke spanne ich welches Pferd ein.

Und die eine Sache, die Sie nicht outsourcen sollten, ist genau diese Entscheidung — die Klarheit darüber, was Sie eigentlich optimieren. Das Modell ist austauschbar. Der Grund, warum Sie es wählen, ist es nicht.

Wir helfen Mittelständlern, genau diese Achse zu sortieren, statt Benchmarks nachzulaufen — [KI-Beratung für den Mittelstand](/ki-beratung-mittelstand) und [der azena-Weg](/the-azena-way).

Teil der Landkarte: [Souveräne KI im Mittelstand — wo, womit und wie sie läuft](/blog/souveraene-ki-mittelstand-landkarte).