Open-Source-LLMs: Mythen und Realitäten im Unternehmen

Das Rauschen um offene Modelle

Wenn ein Führungsteam zum ersten Mal nach Open-Source-LLMs fragt, beginnt die Diskussion meist mit einem großen Versprechen und einem noch größeren Zweifel. Mythen verbreiten sich schneller als technische Dokumentation. Und Entscheidungen werden in vielen Fällen auf Basis von Informationen aus zweiter Hand getroffen. Dieser Artikel möchte nicht für die Einführung offener Modelle werben, sondern trennen, was überprüfbar ist, von dem, was ohne Belege wiederholt wird.

Mythos 1: „Open Source ist kostenlos»

Die Modellgewichte sind kostenlos herunterladbar. Das stimmt. Was nicht kostenlos ist, ist alles, was nötig ist, damit diese Gewichte in der Produktion stabil funktionieren. Die tatsächlichen Kosten entstehen in vier Bereichen:

• Infrastruktur: Eine GPU mit ausreichend Speicher, um ein 70B-Modell mit langem Kontext zu bedienen, ist kein Laptop. Die stundenweise Miete oder der Kauf der Hardware verursachen Kosten, die sich jeden Monat wiederholen.
• Engineering: Jemand muss den Inferenzserver aufsetzen, das Batching optimieren, Latenzen überwachen und die Modellversionen verwalten.
• Evaluierung: Jede Aktualisierung des Modells oder des Prompts erfordert eine erneute Qualitätsmessung. Ohne eine eigene Testumgebung navigiert man blind.
• Wartung: Die Repositories für Gewichte und die Inferenzbibliotheken entwickeln sich schnell weiter. Was vor sechs Monaten funktionierte, kann heute Anpassungen erfordern.

In der Praxis können die Kosten pro Token eines offenen Modells, das auf eigener Infrastruktur betrieben wird, wettbewerbsfähig oder sogar niedriger sein als die einer geschlossenen API – aber erst ab einem bestimmten nachhaltigen Volumen. Unterhalb dieser Schwelle gewinnt die API in der Regel bei den Gesamtkosten. Laut Dokumentation von Cloud-Infrastrukturanbietern übersteigt die durchschnittliche Auslastung der für Inferenz dedizierten GPUs in kleinen Unternehmen selten 30 %, was jeden bedienten Token verteuert.

Der Fehler, nur den Token-Preis zu zählen

Ein Muster, das sich in Teams wiederholt, die den Sprung wagen: Sie vergleichen den Preis pro Million Tokens der API mit dem Stundenpreis der GPU und schließen daraus, dass das offene Modell günstiger ist. Sie vergessen die Opportunitätskosten des Plattformteams, die Integrationsstunden und die Zeit, die für die Lösung von Vorfällen aufgewendet wird. Eine ehrliche Kalkulation bezieht diese Stunden mit ein, und sei es nur näherungsweise.

Mythos 2: „Wenn es offen ist, sind meine Daten standardmäßig sicher»

Das Modell auf eigener Infrastruktur auszuführen, eliminiert den Datenabfluss zu einem Dritten, macht das System aber nicht durch Zauberei sicher. Die Sicherheit hängt davon ab, wie es bereitgestellt wird, nicht nur davon, wo es läuft. Die Punkte, die in der ersten Diskussion oft außen vor bleiben:

• Die Protokolle von Prompts und Antworten. Wenn sie unkontrolliert gespeichert werden, bleiben sensible Daten exponiert, auch wenn das Modell lokal ist.
• Der Zugang zum Inferenz-Endpunkt. Ohne Authentifizierung und Nutzungslimits kann jeder innerhalb des Netzwerks das Modell mit den Berechtigungen des Dienstes abfragen.
• Die Lieferkette des Modells. Die aus einem öffentlichen Repository heruntergeladenen Gewichte müssen verifiziert werden; eine beschädigte oder manipulierte Datei ist ein realer Angriffsvektor.
• Die Inhaltsfilterung. Ein offenes Modell bringt standardmäßig nicht die Moderationsschichten mit, die ein verwalteter Anbieter in seiner API anwendet.

Der Datenschutzvorteil existiert, aber er ist eine notwendige, keine hinreichende Bedingung. Er erfordert dieselbe Data-Governance-Arbeit wie jedes andere interne System.

Mythos 3: „Sie leisten weniger als geschlossene Modelle»

Hier ist die Nuance sehr wichtig, und zu verallgemeinern ist der Fehler. Bei Aufgaben mit komplexem Reasoning, Mathematik und Code haben die geschlossenen Spitzenmodelle während eines guten Teils von 2025 und Anfang 2026 einen Vorsprung in öffentlichen Benchmarks gehalten. Bei klar abgegrenzten Aufgaben jedoch – Klassifizierung von Tickets, Extraktion von Feldern aus einem Dokument, Zusammenfassung von Gesprächen in festem Format, Generierung von Antworten aus einem abgerufenen Kontext – erreichen oder übertreffen mittelgroße offene Modelle kleine geschlossene Modelle, mit dem Vorteil, dass man sie mit den eigenen Daten feinabstimmen kann.

Ein konkretes Beispiel, das den Unterschied gut veranschaulicht: ein Versicherungsunternehmen, das Schadensmeldungen in PDF verarbeitet. Ein geschlossenes Generalistenmodell machte Fehler beim Extrahieren von Beträgen, wenn das Dokument Tabellen und Freitext vermischte. Nach dem Fine-Tuning eines offenen 8B-Modells mit 2.000 intern annotierten Beispielen stieg die Genauigkeit in diesem spezifischen Format deutlich und die Kosten pro Dokument sanken. Nicht weil das offene Modell im Allgemeinen besser war, sondern weil es auf die exakte Verteilung seiner Dokumente spezialisiert war. Das ist das Terrain, auf dem offene Modelle glänzen.

Wo sie nicht hinkommen (und das sollte man anerkennen)

Ein offenes Modell mit 7B oder 8B wird Anfragen, die Multi-Step-Reasoning über Kontexte von 200.000 Tokens mit derselben Robustheit wie ein geschlossenes High-End-Modell erfordern, nicht lösen. Es ist auch nicht die natürliche Wahl für kreative Aufgaben mit großer Reichweite, bei denen stilistische Kohärenz entscheidend ist. Wenn Ihr Anwendungsfall davon abhängt, ist das offene Modell nicht die Antwort, und es zu erzwingen erzeugt Frustration im Team und Misstrauen gegenüber der Technologie.

Mythos 4: „Es reicht, das Modell herunterzuladen, und das war’s»

Die Distanz zwischen dem Herunterladen der Gewichte und einem Service in der Produktion ist der Teil, der in einführenden Artikeln am wenigsten dokumentiert wird. Die Zwischenschritte umfassen:

• Die Wahl einer Inferenzbibliothek, die zur verfügbaren Hardware passt.
• Die Definition des Prompting-Schemas und seine Versionierung zusammen mit dem Code.
• Der Aufbau einer Retrieval-Schicht (RAG), wenn das Modell aktuelles Unternehmenswissen benötigt.
• Die Festlegung von Qualitätsmetriken und eines repräsentativen Evaluierungssatzes.
• Die Konfiguration von Nutzungslimits, Warteschlangen und kontrollierter Degradation bei Nachfragespitzen.

Laut offizieller Dokumentation der wichtigsten Serving-Bibliotheken variiert die Leistung pro GPU stark je nach Quantisierungstechnik und Batch-Größe. Ein und dasselbe Modell kann je nach Konfiguration von 10 Anfragen pro Sekunde auf 40 steigen. Dieser Unterschied erscheint nicht im Datenblatt des Modells; er zeigt sich beim Messen.

Mythos 5: „Open Source garantiert völlige Unabhängigkeit vom Anbieter»

Die Abhängigkeit von einer geschlossenen API durch die Abhängigkeit von einem GPU-Anbieter, einer bestimmten Inferenzbibliothek oder einem einzigen Gewichte-Repository zu ersetzen, ist keine Unabhängigkeit, sondern ein Wechsel der Abhängigkeit. Wahre Freiheit entsteht, wenn das Team das Modell migrieren kann, ohne die Anwendung neu zu schreiben. Das erfordert eine Abstraktionsschicht im Code, ein portables Prompt-Format und eine Testumgebung, die es ermöglicht, Kandidaten nach denselben Kriterien zu vergleichen.

Unternehmen, die diesen Schritt gut gemacht haben, verfügen in der Regel über einen internen Katalog evaluierter Modelle, nicht über ein einziges Modell. Sie können je nach Kosten, Latenz oder Qualität bei einer konkreten Aufgabe von einem zum anderen wechseln. Open Source ermöglicht diese Flexibilität; sie garantiert sie nicht.

Realität: Wann es sinnvoll ist und wann nicht

Nach mehreren Bereitstellungen ist das Entscheidungsmuster recht konsistent:

Signale dafür

• Hohes und stabiles Inferenzvolumen, das die Investition in Infrastruktur rechtfertigt.
• Daten, die aufgrund regulatorischer oder vertraglicher Anforderungen den Perimeter nicht verlassen dürfen.
• Bedarf an tiefer Spezialisierung in einer Domäne mit eigenen gelabelten Daten.
• Kritische Latenz in Umgebungen, in denen das Netzwerk zu einem externen Anbieter einen inakzeptablen zusätzlichen Sprung verursacht.
• Anforderung an Reproduzierbarkeit: genau wissen, welche Version des Modells welche Antwort gegeben hat.

Signale dagegen

• Team ohne Plattform- oder MLOps-Profil und mit engen Fristen.
• Sehr vielfältige Anwendungsfälle, die ein Generalistenmodell höchster Qualität erfordern.
• Niedrige oder intermittierende Volumina, bei denen die geschlossene API günstiger ist.
• Fehlen eigener Daten zur Spezialisierung: Ohne Fine-Tuning oder RAG konkurriert das offene Modell im Nachteil.

Eine Warnung zu Evaluierungen

Öffentliche Benchmarks sind eine nützliche Referenz, sagen aber die Leistung in Ihrem Fall nicht voraus. Ein Modell, das eine Generalisten-Tabelle anführt, kann bei der konkreten Aufgabe, die Ihnen wichtig ist, darunter liegen. Das einzige verlässliche Maß ist der Aufbau eines Evaluierungssatzes mit realen Beispielen aus Ihrem Geschäft, bei Bedarf anonymisiert, und der Vergleich von Kandidaten mit demselben Prompt und demselben Korrektheitskriterium. Ohne diese Testumgebung stützt sich jede Entscheidung über offene Modelle auf Meinungen, nicht auf Daten.

Und man sollte sich an eine Einschränkung erinnern, die nicht verschwindet: Kein Modell, ob offen oder geschlossen, garantiert Ergebnisse. Die Qualität des Systems hängt von den Daten, dem Prompt-Design, der kontinuierlichen Evaluierung und dem menschlichen Urteilsvermögen ab, das die Ausgaben an den kritischen Punkten überprüft. Open Source fügt Kontrolle und Optionen hinzu; es ersetzt nicht die Arbeit.