Kaum ein Unternehmen kommt heute noch ohne KI-Sprachmodelle aus. Ob Kundensupport, interne Wissensdatenbank oder Textgenerierung: Große Sprachmodelle sind längst im Arbeitsalltag angekommen. Fast immer laufen sie dabei über die Cloud, meist über ein Abo bei OpenAI, Anthropic, Google oder einem der anderen großen Anbieter.

Ein Gegentrend gewinnt trotzdem an Fahrt. Unternehmen betreiben ihr eigenes LLM auf einem lokalen Server, statt sich auf externe APIs zu verlassen. Zwei Gründe stechen dabei besonders hervor, und beide werden im aktuellen Marktumfeld dringlicher.

Prompt Injection: ein unterschätztes Sicherheitsrisiko

Wer ein Sprachmodell mit Zugriff auf externe Inhalte einsetzt, etwa eine E-Mail, ein Dokument oder eine Website, öffnet damit eine Angriffsfläche. Prompt Injection heißt genau dieses Problem. Angreifer verstecken Anweisungen in Inhalten, die das Modell verarbeitet, und bringen es so dazu, entgegen der ursprünglichen Absicht zu handeln. Ein Support-Bot, der eine Kundenanfrage liest, kann durch geschickt platzierten Text plötzlich vertrauliche Daten preisgeben oder Aktionen ausführen, die niemand angestoßen hat.

Bei cloudbasierten Diensten kommt hinzu, dass Unternehmen kaum Einblick darin haben, wie der Anbieter mit solchen Angriffen umgeht, welche Daten dabei den eigenen Netzwerkbereich verlassen und wie die Filtermechanismen im Detail funktionieren. Man verlässt sich auf eine Blackbox.

Ein lokal betriebenes Modell löst das Problem der Prompt Injection nicht von selbst. Die Schwachstelle liegt im Verhalten des Modells, nicht im Ort, an dem es läuft. Wer aber die volle Kontrolle über die Infrastruktur hat, kann eigene Schutzmaßnahmen einziehen: klar getrennte Verarbeitungsschritte, striktes Filtern von Eingaben, Rechteeinschränkungen für angebundene Systeme und lückenlose Protokollierung. Bei einem gemieteten API-Zugang lässt sich das kaum bis gar nicht beeinflussen. Wer sensible Daten verarbeitet, etwa in der Rechtsberatung, im Gesundheitswesen oder im Finanzbereich, braucht diese Kontrolle.

Die Kostenfrage: Wie lange halten die aktuellen Abo-Preise?

Der zweite Grund ist wirtschaftlich. Die aktuellen Preise für KI-Abos wirken günstig, oft nur wenige Euro pro Monat und Nutzer für Zugang zu sehr leistungsfähigen Modellen. Diese Preise spiegeln aber nicht die tatsächlichen Kosten wider, die für Rechenleistung, Strom, Kühlung und die Entwicklung der Modelle anfallen.

Die großen Anbieter finanzieren einen Teil ihres Betriebs über Risikokapital, in der Erwartung, dass sich das Geschäft später über Skaleneffekte oder neue Erlösquellen doch noch rechnet. Für Unternehmen, die heute auf diese Dienste bauen, bedeutet das ein Risiko. Steigen die Preise deutlich, ändern sich die Nutzungsbedingungen, oder verschwindet ein Anbieter ganz vom Markt, steht man ohne Alternative da.

Ein eigenes LLM auf eigener Hardware verschiebt diese Rechnung. Die Anschaffungskosten für Server und Grafikkarten sind hoch, keine Frage. Aber sie sind einmalig und planbar, im Gegensatz zu Abopreisen, die sich jederzeit ändern können. Bei entsprechendem Nutzungsvolumen amortisiert sich die Investition, und danach fallen im Wesentlichen nur noch Strom- und Wartungskosten an. Für Unternehmen mit hohem und regelmäßigem KI-Einsatz, etwa im Kundenservice oder in der Dokumentenverarbeitung, kann das über die Jahre günstiger sein als ein Cloud-Abo pro Nutzer.

Weitere Gründe für den lokalen Betrieb

Neben Sicherheit und Kosten sprechen noch andere Punkte für die eigene Infrastruktur.

Läuft das Modell auf eigener Hardware in der EU, bleiben alle Daten im eigenen Einflussbereich. Es gibt keine Übermittlung an Server in Drittländern und keine Abhängigkeit davon, ob ein Anbieter seine Auftragsverarbeitungsverträge tatsächlich einhält. Für Unternehmen, die mit personenbezogenen oder besonders schützenswerten Daten arbeiten, ist das oft das entscheidende Argument.

Dazu kommt die Verfügbarkeit. Cloud-Dienste haben Ausfälle, Ratenbegrenzungen und Wartungsfenster, auf die man keinen Einfluss hat. Ein eigener Server läuft, solange man ihn selbst am Laufen hält.

Und schließlich die Kontrolle über das Modell selbst. Wer ein eigenes System betreibt, legt fest, welche Version wann eingesetzt wird. Bei Cloud-Diensten ändert sich das zugrunde liegende Modell mitunter über Nacht, ohne dass sich das im Detail nachvollziehen lässt. Das erschwert es, Ergebnisse konstant zu halten und Prozesse verlässlich zu testen. Offene Modelle lassen sich außerdem mit eigenen Daten weiter trainieren oder feinjustieren. Ein auf das eigene Fachgebiet zugeschnittenes Modell kann bei bestimmten Aufgaben besser abschneiden als ein allgemeines Cloud-Modell, gerade bei unternehmensspezifischer Terminologie oder bei wiederkehrenden Prozessen.

Der technische Weg zum eigenen LLM

Wer sich für den Schritt entscheidet, steht vor mehreren konkreten Fragen.

Die erste betrifft das Modell selbst. Die Basis bilden offene Modelle mit frei verfügbaren Gewichten, etwa aus den Familien Llama, Mistral, Qwen oder DeepSeek. Sie unterscheiden sich in Größe, Sprachqualität und Spezialisierung, und die Landschaft entwickelt sich schnell weiter. Wichtig ist der Blick auf die Lizenz, denn nicht jedes offene Modell darf uneingeschränkt kommerziell genutzt werden.

Die zweite Frage ist die Hardware. Entscheidend ist der Grafikspeicher, denn das Modell muss vollständig oder größtenteils dort Platz finden, um schnell zu antworten. Kleinere Modelle laufen bereits auf einer einzelnen leistungsfähigen Consumer-Grafikkarte, größere Modelle brauchen mehrere professionelle GPUs mit entsprechend viel Speicher. Durch Quantisierung, also das Verkleinern der Modellgewichte auf einen geringeren Rechengenauigkeitsgrad, lässt sich der Speicherbedarf deutlich senken, meist bei einem geringen und gut kalkulierbaren Qualitätsverlust.

Für das eigentliche Ausführen des Modells haben sich Werkzeuge wie llama.cpp, Ollama und vLLM etabliert. Sie unterscheiden sich vor allem darin, wie einfach die Einrichtung ist und wie viele gleichzeitige Anfragen sie effizient verarbeiten. Für einen einzelnen internen Anwendungsfall reicht oft eine schlanke Lösung, für viele parallele Nutzer braucht es Software, die auf hohen Durchsatz ausgelegt ist.

Dazu kommt die Frage nach dem Serverstandort. Möglich ist der Betrieb im eigenen Rechenzentrum ebenso wie auf einem gemieteten Server bei einem Anbieter mit dedizierter GPU-Hardware. Wer die Kontrolle über den physischen Zugriff behalten will, wählt die erste Variante. Wer sich die Anschaffungskosten sparen will, mietet Hardware, verliert dabei aber einen Teil der Kontrolle, die eigentlich der Ausgangspunkt der ganzen Überlegung war.

Und zuletzt die Absicherung. Ein eigener Server bringt eigene Verantwortung mit sich. Betriebssystem, Netzwerkzugriff und die Anwendung selbst müssen laufend gepflegt und abgesichert werden. Wer diesen Aufwand nicht selbst leisten kann, sollte ihn von Anfang an einplanen, etwa über einen technischen Partner.

Wo die Grenzen liegen

Ein eigenes LLM ist kein Selbstläufer. Die größten Modelle der führenden Cloud-Anbieter sind bei vielen Aufgaben nach wie vor leistungsfähiger als das, was sich wirtschaftlich sinnvoll auf eigener Hardware betreiben lässt. Der Betrieb braucht Fachwissen, das im Team vorhanden sein oder extern eingekauft werden muss. Strom- und Wartungskosten laufen weiter, auch wenn das Modell gerade nicht gebraucht wird.

Die Entscheidung für ein lokales Modell ist deshalb keine grundsätzliche Absage an Cloud-KI, sondern eine Frage der Abwägung. Wie sensibel sind die Daten, die verarbeitet werden? Wie hoch und wie konstant ist der Nutzungsbedarf? Und wie viel Kontrolle über Sicherheit, Kosten und Verfügbarkeit braucht das eigene Geschäftsmodell wirklich? Wer diese Fragen für sich beantwortet hat, hat auch die Antwort darauf, ob der Weg zum eigenen LLM der richtige ist.

Ob lokal, in der Cloud oder als vollständig geschlossenes Fachsystem: Welche Bauform zu welchem Anwendungsfall passt, ordnet der Beitrag LLM, lokal betrieben oder ganz geschlossen: Was wofür passt ein.