Lokale LLMs im Unternehmen: Datenhoheit behalten

Warum überhaupt ein Modell selbst betreiben?

Wenn dein Team ChatGPT, Claude oder Copilot im Browser nutzt, läuft die eigentliche Rechenarbeit auf Servern des Anbieters - irgendwo in einem Rechenzentrum, das du weder siehst noch kontrollierst. Für die meisten Anwendungsfälle ist das völlig in Ordnung: die grossen Cloud-Anbieter betreiben ordentliche Sicherheitsprogramme, bieten Unternehmensverträge mit klaren Datenverarbeitungsvereinbarungen und trainieren bei Business-Plänen in der Regel nicht mit deinen Eingaben weiter. Trotzdem gibt es drei wiederkehrende Gründe, warum Unternehmen zusätzlich oder ausschliesslich auf lokal betriebene Sprachmodelle setzen:

1. Datenhoheit. Manche Daten dürfen dein Netzwerk gar nicht erst verlassen - aus vertraglichen Gründen (Kundendaten mit strikten NDA-Klauseln), aus regulatorischen Gründen (Gesundheitsdaten, Finanzdaten, Behördendaten) oder schlicht, weil die Geschäftsleitung keine Blackbox in der Cloud will, durch die Konstruktionspläne oder Preiskalkulationen laufen. Bei einem lokal gehosteten Modell bleibt jede Anfrage und jede Antwort physisch im eigenen Netzwerk - es gibt keine Übertragung an einen Drittanbieter, über die du überhaupt eine Datenschutz-Folgenabschätzung machen müsstest. Grundlagen dazu findest du unter KI-Datenschutz-Grundlagen und DSGVO/nDSG in der IT-Praxis.

2. Offline- und Ausfallsicherheit. Ein lokales Modell funktioniert auch, wenn die Internetleitung ausfällt, wenn ein Cloud-Anbieter einen Ausfall hat oder wenn du in einer Umgebung ohne Internetzugang arbeitest (Produktionshallen, Schiffe, abgeschottete Netze). Für Werkzeuge, die im Tagesgeschäft ständig gebraucht werden - etwa ein interner Chatbot fürs Wissensmanagement - ist diese Unabhängigkeit oft unterschätzt wertvoll.

3. Kosten bei hohem, planbarem Volumen. Cloud-APIs rechnen pro Token ab (siehe Tokens & Kosten optimieren). Bei sehr hohem, gleichmässigem Nutzungsvolumen - etwa einer Anwendung, die rund um die Uhr Dokumente klassifiziert oder Log-Dateien zusammenfasst - kann eigene Hardware auf Dauer günstiger sein als laufende API-Kosten. Das ist aber eine Rechnung, die sich erst ab einem gewissen Volumen lohnt, siehe weiter unten.

Was “lokal” konkret bedeutet

Ein lokales LLM ist kein Cloud-Modell, das du “irgendwie herunterlädst” - es ist ein offen verfügbares Modell (z. B. aus der Llama-, Qwen-, Gemma- oder Mistral-Familie), dessen Gewichte du auf eigener Hardware ausführst, statt eine API eines Anbieters aufzurufen. Der Unterschied zwischen offenen und geschlossenen Modellen ist grundlegend für dieses Thema - falls dir das noch nicht klar ist, lies zuerst Open- vs. Closed-Source-Modelle.

Wichtig für die Einordnung: “Lokal” heisst nicht zwingend “auf dem Laptop einer Mitarbeiterin”. In der Praxis läuft das Modell fast immer auf einem zentralen Server oder einer Workstation im eigenen Rechenzentrum bzw. im eigenen Cloud-Tenant (z. B. eine dedizierte VM mit GPU) - und das ganze Team greift darüber via internem Netzwerk oder VPN zu. Das ist etwas anderes als “on premise” im engsten Sinn, erfüllt aber denselben Zweck: Die Daten verlassen die eigene Kontrolle nicht.

Ollama und LM Studio: die zwei gängigsten Wege

Für den Einstieg brauchst du kein eigenes ML-Team. Zwei Werkzeuge haben sich als Standard etabliert, um offene Modelle ohne tiefes Fachwissen lokal auszuführen:

Ollama

Ollama ist ein kommandozeilenbasiertes Werkzeug (mit optionaler grafischer Oberfläche), das ein Modell mit einem einzigen Befehl herunterlädt und startet. Es baut intern auf llama.cpp auf und stellt zusätzlich eine lokale REST-API bereit, über die eigene Anwendungen das Modell ansprechen können - das macht es zur ersten Wahl, wenn du ein Modell nicht nur manuell nutzen, sondern in ein internes Tool (z. B. einen firmeninternen Chat oder ein RAG-System, siehe RAG: Firmenwissen durchsuchbar machen) einbinden willst.

# Modell herunterladen und direkt im Chat starten
ollama run llama3.1

# Alternative: kleines, genügsames Modell für schwächere Hardware
ollama run gemma3:4b

# Laufende Modelle anzeigen
ollama ps

# Modell per REST-API ansprechen (z. B. aus einem eigenen Skript)
curl http://localhost:11434/api/chat -d '{
  "model": "llama3.1",
  "messages": [{"role": "user", "content": "Fasse diesen Text in drei Punkten zusammen: ..."}],
  "stream": false
}'

Ollama läuft unter Windows, macOS und Linux sowie als Docker-Container und eignet sich damit gut, um ein Modell zentral auf einem Server bereitzustellen, auf den mehrere Mitarbeitende zugreifen.

LM Studio

LM Studio ist die grafische Alternative: eine Desktop-Anwendung mit Chat-Oberfläche, Modell-Bibliothek zum Durchsuchen und Herunterladen sowie einem lokalen Server-Modus, der - ähnlich wie Ollama - eine API im OpenAI-kompatiblen Format bereitstellt. Der grosse Vorteil von LM Studio: Für Leute, die keine Kommandozeile mögen, ist die Einstiegshürde niedriger, weil Modellsuche, Download, Parametereinstellungen (Kontextlänge, GPU-Auslagerung, Temperatur) und Chat in einer Oberfläche stecken.

LM Studio unterstützt Modelle im GGUF-Format (die gängige, quantisierte Austauschform für llama.cpp-basierte Tools) und auf Apple-Silicon-Rechnern zusätzlich das MLX-Format, das dort spürbar schneller läuft.

Wie viel Hardware brauchst du wirklich?

Das ist die Frage, an der die meisten Planungen hängen bleiben. Die Faustregel: Ein Modell mit N Milliarden Parametern braucht in einer gängigen 4-Bit-Quantisierung ungefähr 0,5-0,7 GB Arbeitsspeicher (RAM oder VRAM) pro Milliarde Parameter, plus etwas Puffer für den Kontext (die Textmenge, die das Modell gerade “im Kopf” hält). Ein 8B-Modell in 4-Bit-Quantisierung braucht also grob 5-6 GB, ein 70B-Modell entsprechend 40-45 GB.

Drei Faktoren bestimmen, ob das Modell für dich brauchbar läuft:

• GPU-VRAM statt System-RAM. Läuft das Modell komplett auf einer Grafikkarte mit ausreichend VRAM, ist die Antwortgeschwindigkeit um ein Vielfaches höher als auf der CPU. Passt das Modell nicht komplett in den VRAM, lagern Ollama und LM Studio automatisch einen Teil auf die CPU/den System-RAM aus (“Offloading”) - das funktioniert, ist aber spürbar langsamer.
• Quantisierung. Modelle werden fast nie in voller Präzision (16-Bit) lokal betrieben, sondern komprimiert auf 8-Bit, 4-Bit oder noch weniger. Das spart massiv Speicher bei überschaubarem Qualitätsverlust - ein gut quantisiertes 4-Bit-Modell liegt für die meisten Alltagsaufgaben kaum spürbar hinter der Vollversion.
• Kontextlänge. Ein langer Chat-Verlauf oder ein grosses eingefügtes Dokument braucht zusätzlichen Speicher über das reine Modell hinaus - bei sehr langem Kontext kann das mehrere zusätzliche GB ausmachen.

Welche Modelle eignen sich für den lokalen Betrieb?

Der Markt an offenen Modellen ändert sich laufend - Modellnamen und Bestwerte von heute sind in einem halben Jahr oft überholt. Trotzdem gibt es stabile Modellfamilien, an denen du dich orientieren kannst (Stand: 2026-07):

• Llama-Familie (Meta) - breit unterstützt, viele Community-Varianten, gute Allround-Leistung in mehreren Grössen von wenigen Milliarden bis über 400 Milliarden Parametern.
• Qwen-Familie (Alibaba) - sehr breite Grössenpalette (von unter 1B bis 70B+), oft mit langem Kontextfenster, starke Leistung bei mehrsprachigen und Coding-Aufgaben.
• Gemma-Familie (Google) - kompakte, für Consumer-Hardware optimierte Modelle, gute Wahl für Laptops und kleinere GPUs.
• Mistral-Familie (Mistral AI) - europäischer Anbieter, effiziente Modelle mit solider Qualität pro Grösse.
• DeepSeek-Familie - insbesondere die Reasoning-Varianten haben sich für Aufgaben etabliert, bei denen das Modell “nachdenken” und Zwischenschritte zeigen soll, in Grössen von wenigen Milliarden bis mehreren hundert Milliarden Parametern.
• gpt-oss (OpenAI) - offen verfügbare Modelle des sonst primär geschlossenen Anbieters, ebenfalls über Ollama und LM Studio nutzbar.

Für Coding-lastige Anwendungsfälle gibt es zusätzlich spezialisierte Varianten (z. B. Coder-Editionen von Qwen oder DeepSeek), die bei Programmieraufgaben oft besser abschneiden als gleich grosse Allzweckmodelle.

Entscheidungshilfe: Welche Modellgrösse für welchen Zweck?

Aufgabe: Kurze Klassifikation, einfache Zusammenfassung, Testbetrieb
  -> 1-4B-Modell reicht meist aus, läuft auch auf schwacher Hardware

Aufgabe: Alltags-Chat, Textentwürfe, einfache RAG-Antworten für ein Team
  -> 7-9B-Modell auf einer Consumer-GPU (8+ GB VRAM)

Aufgabe: Anspruchsvolle Texte, komplexere Analysen, mehrere Nutzende gleichzeitig
  -> 13-32B-Modell auf dedizierter GPU (16-24 GB VRAM) oder Apple-Silicon-Mac

Aufgabe: Qualität möglichst nah an GPT-/Claude-Cloud-Niveau
  -> 70B+-Modell auf Server-Hardware - hier lohnt sich ein Realitätscheck,
     ob Cloud-Nutzung nicht wirtschaftlicher ist (siehe Abschnitt "Grenzen")

Grenzen gegenüber Cloud-Modellen

Lokale Modelle sind kein Ersatz für Cloud-KI in jedem Szenario. Vier Punkte solltest du realistisch einplanen:

Qualität bei komplexen Aufgaben. Die grössten geschlossenen Cloud-Modelle liegen bei sehr anspruchsvollen Aufgaben (komplexe Mehrschritt-Logik, tiefes Fachwissen über viele Domänen, sehr lange Dokumente mit vielen Querverweisen) tendenziell weiterhin vorne. Ein lokal betreibbares Modell in vernünftiger Grösse kommt nah heran, erreicht aber nicht in jedem Fall dasselbe Niveau - siehe auch Was KI kann und was nicht.

Wartungsaufwand. Ein Cloud-Anbieter kümmert sich um Server, Skalierung, Sicherheitspatches und Modell-Updates. Bei einem selbst betriebenen Modell übernimmst du das - Betriebssystem-Updates, Treiber, Backups der Konfiguration, Monitoring, ob der Dienst überhaupt noch läuft. Das ist ein IT-Betriebsthema, kein einmaliges Setup-Projekt.

Anfangsinvestition vs. laufende Kosten. Eine GPU-Workstation oder ein Server mit Enterprise-GPUs kostet real Geld im Voraus, während Cloud-APIs nutzungsabhängig abrechnen. Die Rechnung “lohnt sich lokal” braucht ein realistisches Nutzungsvolumen über mehrere Monate oder Jahre - nicht nur den Anschaffungspreis gegen eine einzelne Monatsrechnung. Details zur Kostenlogik unter KI-Kosten & Lizenzen im KMU.

Kein automatisches Web-Wissen, keine Werkzeuganbindung von Haus aus. Cloud-Chatbots können oft direkt im Internet suchen oder auf zahlreiche vorgefertigte Werkzeuge zugreifen. Ein lokales Modell kann das auch - aber du musst diese Anbindung (Internetsuche, Werkzeugaufrufe, Dokumentenanbindung) selbst einrichten, meist über zusätzliche Software-Schichten. Mehr dazu unter KI-Agents & Tool Use und MCP: Model Context Protocol.

Typische KMU-Szenarien

Szenario 1: Interner Wissens-Chatbot ohne Cloud-Anbindung. Ein Betrieb mit sensiblen Konstruktionsunterlagen oder Kundendaten will einen Chatbot, der Fragen zu internen Dokumenten beantwortet, ohne dass diese Dokumente je eine Cloud-API erreichen. Lösung: ein mittelgrosses Modell (7-32B) auf einem internen Server, kombiniert mit einer RAG-Anbindung an die eigene Dokumentenablage - siehe RAG: Firmenwissen durchsuchbar machen und Vektor-Datenbanken.

Szenario 2: Erste-Instanz-Klassifikation grosser Datenmengen. Ein Betrieb erhält täglich hunderte E-Mails oder Support-Tickets, die grob vorkategorisiert werden sollen, bevor ein Mensch sie sichtet. Ein kleines, günstig zu betreibendes Modell (1-8B) reicht dafür meist aus und läuft rund um die Uhr, ohne dass jede Kategorisierung Cloud-Kosten verursacht.

Szenario 3: Test- und Entwicklungsumgebung für IT-Teams. Bevor ein Unternehmen eine KI-Funktion produktiv mit einer Cloud-API baut, testet das Entwicklungsteam Prompts und Architektur lokal mit einem vergleichbaren offenen Modell - schneller, kostenlos und ohne dass Testdaten überhaupt irgendwohin übertragen werden. Mehr zur technischen Seite unter Lokale Modelle betreiben und LLM-APIs: Grundlagen.

Szenario 4: Hybridbetrieb. Viele Unternehmen fahren gar nicht “entweder-oder”, sondern gezielt gemischt: unkritische, alltägliche Anfragen laufen über eine günstige Cloud-API oder Microsoft 365 Copilot, während besonders sensible Workloads strikt lokal bleiben. Das ist meist der pragmatischste Weg, weil er weder unnötig hohe Hardwarekosten noch unnötige Datenschutzrisiken erzeugt.

Kurz zusammengefasst

• Lokale LLMs geben dir Kontrolle über Datenhoheit, Offline-Betrieb und potenziell Kosten bei hohem Volumen - sie ersetzen aber keine Sicherheitsstrategie.
• Ollama (kommandozeilenorientiert, gut für Server/Integration) und LM Studio (grafisch, gut für Einzelplatz-Tests) sind die zwei gängigsten Einstiegswerkzeuge.
• Faustregel für den Speicherbedarf: ca. 0,5-0,7 GB pro Milliarde Parameter bei 4-Bit-Quantisierung, plus Puffer für den Kontext.
• Modellfamilien wie Llama, Qwen, Gemma, Mistral, DeepSeek und gpt-oss bieten Grössen von unter 1B bis über 400B Parametern - meist reicht für den Firmenalltag ein Modell im Bereich 7-32B.
• Lokale Modelle stossen bei sehr komplexen Aufgaben, beim laufenden Wartungsaufwand und bei Werkzeuganbindung an Grenzen gegenüber Cloud-Angeboten.
• In der Praxis ist ein Hybridbetrieb - unkritisches über Cloud, Sensibles strikt lokal - für viele KMU der pragmatischste Weg.

Weiterlernen

• Ollama - offizielle Website und Modell-Bibliothek
• Ollama auf GitHub - Quellcode und Dokumentation
• LM Studio - offizielle Website
• LM Studio Systemanforderungen
• Hugging Face - Modell-Hub für offene Sprachmodelle
• KI-Datenschutz-Grundlagen im Wiki