Open-Source-LLMs im Unternehmen: Einsatzfelder, Grenzen, Betrieb

Irgendwann fällt in jedem Projekt der Satz: Wir nehmen einfach ein offenes Modell, dann sind wir unabhängig und die Daten bleiben bei uns. Der Satz klingt gut, und er ist nicht falsch. Er ist nur unvollständig. Open-Source-LLMs im Unternehmen einzusetzen ist weder die billige Abkürzung, für die Einkäufer sie halten, noch die Spielerei, für die Skeptiker sie halten. Es ist eine Architekturentscheidung mit klaren Stärken, klaren Grenzen und einem Betriebsaufwand, den man vorher kennen sollte.

Die offenen Modellfamilien haben in den letzten Jahren einen erstaunlichen Weg zurückgelegt. Für viele eng umrissene Aufgaben liefern sie Ergebnisse, die sich vor den großen kommerziellen Modellen nicht verstecken müssen, bei einem Bruchteil der laufenden Kosten und mit voller Kontrolle über den Datenfluss. Gleichzeitig gibt es Aufgabenklassen, bei denen der Abstand zu den Frontier-Modellen deutlich bleibt. Die Kunst liegt darin, die Grenze zwischen beiden Welten für den eigenen Anwendungsfall zu finden, und zwar mit Messwerten statt mit Überzeugungen.

Wo offene Modelle stark sind

Offene Modelle spielen ihre Stärken bei Aufgaben aus, die drei Eigenschaften teilen: Sie sind eng definiert, sie fallen in hoher Stückzahl an, und ihre Qualität lässt sich objektiv prüfen. Typische Einsatzfelder:

• Klassifikation: Tickets nach Kategorie sortieren, Dokumente einem Typ zuordnen, Anfragen an die richtige Abteilung routen. Enger Ausgaberaum, leicht zu evaluieren, hohes Volumen.
• Extraktion: definierte Felder aus Rechnungen, Lieferscheinen oder Formularen ziehen. Das Schema ist fix, die Erwartung ist eindeutig, ein Fehler fällt im Abgleich auf.
• PII-Vorfilterung: personenbezogene Angaben erkennen und maskieren, bevor ein Text das Haus in Richtung einer Cloud-API verlässt. Gerade hier ist ein lokal laufendes Modell konzeptionell die sauberste Lösung.
• Embeddings und Reranking: Bausteine für Suche und Retrieval, bei denen offene Modelle seit langem etabliert sind.

Gemeinsam ist diesen Feldern: Das Modell muss nicht brillant sein, es muss zuverlässig und günstig sein. Offene Modelle in kleinen und mittleren Größen erfüllen das oft besser als ein großes Modell, das für dieselbe Aufgabe überqualifiziert und überteuert ist.

Open Weights ist nicht Open Source

Beim Lizenzthema lohnt Genauigkeit. Die meisten frei verfügbaren Modelle sind streng genommen keine Open-Source-Software, sondern Open Weights: Die Gewichte sind abrufbar, aber die Lizenz ist ein eigener Vertragstext mit eigenen Bedingungen. Verbreitet sind Nutzungsbeschränkungen für bestimmte Anwendungsfelder, Auflagen zur Namensnennung, Regeln für abgeleitete Modelle und teils Klauseln, die ab einer bestimmten Unternehmensgröße oder Nutzerzahl greifen. Manche Lizenzen behalten sich Änderungen für künftige Versionen vor.

Für den Praxiseinsatz heißt das: Die Lizenz des konkreten Modells in der konkreten Version lesen, bevor es in ein Produkt wandert, und bei Unklarheiten rechtlichen Rat einholen. Das ist kein Grund zur Abschreckung, die meisten Lizenzen sind für gewöhnliche Unternehmensnutzung unproblematisch. Aber die Annahme, offen bedeute frei von Pflichten, hat schon mehr als ein Projekt kurz vor dem Go-live gebremst.

Serving-Optionen: vom eigenen Inferenz-Server bis Managed Hosting

Ein offenes Modell zu betreiben heißt, eine Serving-Entscheidung zu treffen. Drei Kategorien decken die Praxis ab:

Option	Stärke	Grenze
Produktions-Inferenz-Server auf eigener GPU	Volle Kontrolle, hoher Durchsatz durch Batching	GPU-Beschaffung, Betrieb, Know-how nötig
Lokale Runtime am Arbeitsrechner	In Minuten startklar, ideal zum Experimentieren	Nicht für Mehrbenutzer-Produktivbetrieb gedacht
Managed Hosting offener Modelle	Offene Gewichte ohne eigene Hardware, API-Komfort	Daten verlassen wieder das Haus, Anbieterbindung light

Die lokale Runtime auf dem Entwickler-Notebook ist der richtige Einstieg, um Modelle zu sichten und Prompts zu erproben. Für den Produktivbetrieb braucht es einen echten Inferenz-Server mit kontinuierlichem Batching, Warteschlangenverwaltung und Monitoring, sonst bricht der Durchsatz unter parallelen Anfragen ein. Managed Hosting offener Modelle ist der oft übersehene Mittelweg: Man gewinnt die Modellfreiheit und die Preisstruktur offener Gewichte, ohne GPUs zu beschaffen. Wer On-Premise nur aus Kostengründen erwog, findet hier häufig die pragmatischere Lösung. Wer es aus Datenschutzgründen erwog, muss den Anbieter genauso prüfen wie jeden anderen Cloud-Dienst.

Qualitäts- und Wartungsrealität im Zusammenspiel mit Frontier-Modellen

Bei komplexen Aufgaben, also mehrstufigem Schlussfolgern, langen agentischen Abläufen, heiklem Instruction Following über viele Regeln hinweg, liegt zwischen offenen Modellen und den Frontier-Modellen weiterhin ein spürbarer Abstand. Der lässt sich mit Fine-Tuning und sorgfältigem Prompting verkleinern, aber selten schließen. Wer diesen Abstand ignoriert, bezahlt ihn später mit Engineering-Aufwand: mehr Zerlegung in Teilschritte, mehr Nachbearbeitung, mehr Sonderfälle.

Das bewährte Muster ist deshalb kein Entweder-oder, sondern ein Routing: Frontier-Modell über API für die anspruchsvollen, seltenen Schritte, offenes Modell für die engen, häufigen. Die Zuordnung trifft nicht die Ideologie, sondern das Eval-Set. Wenn das offene Modell auf den eigenen Prüffällen die definierte Schwelle erreicht, übernimmt es die Aufgabe, sonst nicht.

Zur Ehrlichkeit gehört auch die Wartungsseite. Ein API-Anbieter verbessert sein Modell, patcht seine Infrastruktur und trägt den Betrieb. Beim selbst gehosteten Modell liegt all das im eigenen Haus: neue Modellversionen sichten, Evals dagegen laufen lassen, den Inferenz-Server aktuell halten, GPU-Auslastung überwachen, Kapazität planen. Das ist gut machbar, aber es ist eine dauerhafte Aufgabe mit dauerhaften Personalkosten, kein einmaliges Aufsetzen.

Fazit

Offene Modelle haben im Unternehmen einen festen Platz, aber einen bestimmten: enge, häufige, gut messbare Aufgaben wie Klassifikation, Extraktion und PII-Vorfilterung, bei denen Kostenkontrolle und Datenhoheit mehr zählen als maximale Modellintelligenz. Die Lizenz gehört pro Modell und Version geprüft, denn Open Weights ist ein Vertragstext, keine Freigabe. Beim Serving führt der Weg vom Experiment auf dem Notebook zum Produktions-Inferenz-Server oder zum Managed Hosting, je nachdem, ob Datenfluss oder Betriebsaufwand die knappere Ressource ist. Und im Zusammenspiel mit Frontier-Modellen entscheidet ein Eval-Set über die Arbeitsteilung. Wer so vorgeht, bekommt das Beste beider Welten und erspart sich die Enttäuschung derer, die von einem offenen Modell die Leistung eines Frontier-Modells zum Nulltarif erwartet haben.