Lokale Sprachmodelle betreiben: Hardware, Modellwahl, Betrieb, Datenschutz

Lokale Sprachmodelle sind KI-Modelle mit herunterladbaren Gewichten, die auf eigener Hardware statt in der Cloud eines Anbieters laufen. Wer sie im Unternehmen einsetzen will, muss vier Fragen beantworten: Welche Hardware reicht, welches Modell passt, mit welcher Software läuft es – und was bleibt datenschutzrechtlich zu tun.

Ein Sprachmodell auf eigener Hardware zu betreiben, ist 2026 kein Forschungsprojekt mehr. Offene Modellgewichte stehen in großer Zahl bereit, die Software zum Ausführen ist ausgereift, und viele Werkzeuge sprechen dieselbe Programmierschnittstelle wie die großen Cloud-Anbieter. Trotzdem scheitern Pilotprojekte häufig an denselben Stellen: zu wenig Grafikspeicher, ein Modell mit unpassender Lizenz, ein Betrieb ohne klare Zuständigkeit. Dieser Leitfaden geht die vier Entscheidungen der Reihe nach durch.

Teil 1: Hardware – der Grafikspeicher entscheidet

Bei lokalen Sprachmodellen ist selten die Rechenleistung der Engpass, sondern der Speicher. Ein Modell besteht aus Milliarden von Parametern („Gewichten“), die beim Ausführen vollständig oder größtenteils im schnellen Speicher liegen müssen – idealerweise im VRAM, dem Speicher der Grafikkarte.

Faustregel für den Speicherbedarf

Der Bedarf ergibt sich grob aus Parameterzahl mal Bytes pro Parameter. Die folgenden Werte sind Näherungen, keine Herstellerangaben, und gelten nur für die Gewichte selbst:

Hinzu kommt Speicher für den sogenannten KV-Cache – den Zwischenspeicher, in dem das Modell den bisherigen Gesprächs- oder Dokumentkontext vorhält. Er wächst mit der Kontextlänge und der Zahl gleichzeitiger Anfragen. Planen Sie als grobe Orientierung einen Aufschlag von 20 bis 50 Prozent auf die Gewichte ein; bei sehr langen Kontexten oder vielen parallelen Nutzern kann es deutlich mehr sein.

Quantisierung

Quantisierung bedeutet, die Gewichte mit geringerer Genauigkeit zu speichern – etwa mit 4 statt 16 Bit. Das reduziert den Speicherbedarf erheblich und beschleunigt die Ausführung, kostet aber etwas Qualität. Wie viel, hängt vom Modell, vom Verfahren und von der Aufgabe ab. In der Praxis sind 4- bis 8-Bit-Varianten für viele Büroaufgaben (Zusammenfassen, Umformulieren, Fragen zu Dokumenten) gut brauchbar. Für anspruchsvolle Aufgaben wie Code oder mehrstufige Analysen lohnt ein eigener Vergleich mit Ihren echten Daten, bevor Sie sich festlegen.

Verbreitete Formate sind GGUF (das Format von llama.cpp und Ollama) sowie Verfahren wie GPTQ oder AWQ, die vor allem in GPU-Servern eingesetzt werden.

CPU oder GPU?

• GPU (Grafikkarte): Der Standard für produktiven Einsatz. Entscheidend sind VRAM-Größe und Speicherbandbreite. Consumer-Karten bieten typischerweise 16 bis 32 GB, Rechenzentrumskarten ein Vielfaches – zu einem Vielfachen des Preises.
• CPU mit viel Arbeitsspeicher: Funktioniert, ist aber deutlich langsamer, weil normaler Arbeitsspeicher eine geringere Bandbreite hat. Für Experimente, Batch-Verarbeitung über Nacht oder sehr kleine Modelle kann das genügen.
• Systeme mit gemeinsamem Speicher: Rechner, bei denen CPU und GPU einen gemeinsamen, schnellen Arbeitsspeicher nutzen (etwa Apple-Silicon-Macs), können größere Modelle laden als eine einzelne Consumer-Grafikkarte, sind aber bei vielen parallelen Anfragen meist langsamer als dedizierte GPU-Server.
• Mischbetrieb: llama.cpp und Ollama können einen Teil der Schichten auf die GPU legen und den Rest auf der CPU rechnen. Das macht größere Modelle möglich, bremst aber spürbar.

Faustregel (Näherung): Für ein Team, das gelegentlich chattet und Dokumente befragt, reicht oft eine Workstation mit einer Grafikkarte im Bereich von 24 bis 32 GB und einem quantisierten Modell mittlerer Größe. Sobald Dutzende Personen gleichzeitig arbeiten sollen, wird ein Server mit mehreren GPUs und einer auf Durchsatz optimierten Software (siehe Teil 3) nötig.

Teil 2: Modellwahl – Leistung ist nicht alles

Unter „Open-Weight“-Modellen versteht man Modelle, deren trainierte Gewichte zum Herunterladen bereitstehen. Das heißt nicht automatisch, dass sie Open Source im klassischen Sinn sind – die Unterschiede erklären wir ausführlich in Open Weight oder Open Source?. Für die Auswahl im Unternehmen zählen drei Kriterien: Eignung für Ihre Aufgaben, Größe im Verhältnis zur Hardware und – oft unterschätzt – die Lizenz.

Die großen Familien und ihre Lizenzen (Stand Ende Oktober 2026)

• Gemma (Google): Mit Gemma 4 ist Google im April 2026 auf die Apache-2.0-Lizenz umgestiegen. Ältere Gemma-Generationen stehen weiterhin unter Googles eigenen Gemma-Nutzungsbedingungen.
• Qwen (Alibaba): Die Qwen3-Modelle wurden 2025 unter Apache 2.0 veröffentlicht. Bei einzelnen Varianten und späteren Versionen sollten Sie die Lizenz auf der jeweiligen Modellkarte prüfen.
• Mistral (Mistral AI, Frankreich): Nach Angaben des Unternehmens stehen die meisten offenen Modelle unter Apache 2.0. Einige Modelle nutzen eine modifizierte MIT-Lizenz, die Unternehmen mit mehr als 20 Millionen US-Dollar Monatsumsatz eine kommerzielle Lizenz abverlangt.
• Llama (Meta): Die Llama-4-Modelle stehen unter der „Llama 4 Community License“. Sie erlaubt kommerzielle Nutzung, enthält aber Auflagen: eine Acceptable Use Policy, die Pflicht zum Hinweis „Built with Llama“, das Präfix „Llama“ im Namen abgeleiteter Modelle und eine Sonderregel für Anbieter mit mehr als 700 Millionen monatlich aktiven Nutzern.

Apache 2.0 ist für Unternehmen die unkomplizierteste Variante: Nutzung, Veränderung und Weitergabe sind ohne Zweckbindung erlaubt, solange Lizenz- und Urheberhinweise erhalten bleiben. Eigene Community-Lizenzen sind nicht per se ein Ausschlussgrund, sie gehören aber in die Rechtsprüfung – vor allem, wenn Sie ein Modell feinjustieren und an Kunden weitergeben wollen.

Praktische Auswahlhilfe

1. Aufgaben definieren: Zusammenfassen, Übersetzen, Dokumentensuche (RAG), Code, Klassifikation. Für viele dieser Aufgaben reicht ein kleineres Modell.
2. Deutschkenntnisse testen: Die Qualität im Deutschen schwankt zwischen Modellen stärker als im Englischen.
3. Mit eigenen Beispielen vergleichen: Öffentliche Ranglisten sind ein Anhaltspunkt, ersetzen aber keinen Test mit 20 bis 50 echten, anonymisierten Fällen aus Ihrem Alltag.
4. Lizenz dokumentieren: Halten Sie Modellname, Version, Quelle und Lizenz fest – das brauchen Sie später auch für die KI-Verordnung.

Teil 3: Betrieb – drei Werkzeuge, eine gemeinsame Schnittstelle

Ollama

Ollama ist der einfachste Einstieg: ein Programm, das Modelle herunterlädt, verwaltet und als lokalen Dienst bereitstellt. Es baut auf llama.cpp auf und eignet sich für Arbeitsplatzrechner, Entwicklerteams und kleinere Server.

llama.cpp

llama.cpp ist die zugrunde liegende C/C++-Bibliothek, die Modelle effizient auf CPU, GPU und gemischter Hardware ausführt. Mit llama-server bringt sie einen eigenen HTTP-Server mit. Wer maximale Kontrolle über Quantisierung und Ressourcen will oder auf schwacher Hardware arbeitet, landet oft hier.

vLLM

vLLM ist auf hohen Durchsatz in GPU-Servern ausgelegt: Es verarbeitet viele gleichzeitige Anfragen effizient und ist damit die typische Wahl, wenn ein Modell für eine ganze Abteilung oder als interner Dienst für mehrere Anwendungen laufen soll. Gestartet wird es mit vllm serve <modell>.

Die OpenAI-kompatible Schnittstelle

Alle drei Werkzeuge bieten Endpunkte an, die der Programmierschnittstelle von OpenAI nachgebildet sind, etwa /v1/chat/completions und /v1/embeddings. Ollama lauscht standardmäßig unter http://localhost:11434/v1/. Der praktische Nutzen: Viele bestehende Anwendungen, Bibliotheken und Plug-ins lassen sich auf das lokale Modell umstellen, indem man nur die Basis-URL ändert. Das senkt die Wechselkosten – und ist ein wichtiger Baustein jeder Exit-Strategie gegen Lock-in. Beachten Sie aber: Ollama unterstützt nach eigener Dokumentation nur eine Teilmenge der OpenAI-API. Testen Sie die Funktionen, die Ihre Anwendungen tatsächlich nutzen.

Open WebUI als Oberfläche

Für Mitarbeitende ohne Programmierkenntnisse braucht es eine Chat-Oberfläche. Open WebUI ist eine verbreitete selbst gehostete Lösung, die sich an Ollama oder jede OpenAI-kompatible Schnittstelle anbinden lässt und Benutzerverwaltung sowie Dokumenten-Upload mitbringt. Ein Detail für die Lizenzprüfung: Seit Version 0.6.6 (April 2025) steht Open WebUI unter einer eigenen Lizenz mit Branding-Klausel. Das Entfernen des Open-WebUI-Brandings ist demnach nur bei höchstens 50 Nutzern in 30 Tagen, mit Erlaubnis der Maintainer oder mit Enterprise-Lizenz zulässig; das Projekt selbst bezeichnet diese Lizenz als nicht OSI-zertifiziert.

Betrieb ist Daueraufgabe

Planen Sie von Anfang an: Wer aktualisiert Modelle und Software? Wer überwacht Auslastung und Fehler? Wie werden Zugänge vergeben (Single Sign-on, Rollen)? Werden Eingaben protokolliert – und wenn ja, wie lange? Ein lokales Modell ohne Verantwortlichen ist ein Sicherheitsrisiko wie jeder andere ungepflegte Server.

Teil 4: Datenschutz – Vorteile und verbleibende Pflichten

Was der lokale Betrieb vereinfacht

Wenn Modell und Daten auf eigener Infrastruktur in der EU bleiben, entfallen typische Fragen der Cloud-Nutzung: kein Auftragsverarbeitungsvertrag mit einem KI-Anbieter, keine Übermittlung in Drittländer nach Kapitel V DSGVO, keine Unsicherheit darüber, ob Eingaben zum Training fremder Modelle verwendet werden. Die Hintergründe zu US-Diensten beleuchtet unser Beitrag DSGVO und US-Cloud.

Was bleibt

Lokal heißt nicht pflichtenfrei. Sobald personenbezogene Daten verarbeitet werden, gilt die DSGVO vollständig:

• Rechtsgrundlage und Zweckbindung (Art. 5, 6 DSGVO): Auch das interne Zusammenfassen von Kundenmails ist eine Verarbeitung, die eine Rechtsgrundlage braucht.
• Verzeichnis von Verarbeitungstätigkeiten (Art. 30): Der KI-Einsatz gehört hinein.
• Sicherheit der Verarbeitung (Art. 32): Zugriffskontrolle, Verschlüsselung, Patch-Management, Protokollierung.
• Datenschutz-Folgenabschätzung (Art. 35): Bei Verarbeitungen mit voraussichtlich hohem Risiko – etwa bei der Auswertung von Beschäftigtendaten – zu prüfen.
• Betroffenenrechte: Wenn Chatverläufe oder Dokumentenindizes gespeichert werden, müssen Auskunft und Löschung möglich sein.
• Ergebnisqualität: Sprachmodelle können plausibel klingende Falschaussagen erzeugen. Entscheidungen über Personen sollten nicht ungeprüft auf Modellausgaben beruhen.

Bei gehosteten Servern in einem Rechenzentrum bleibt der Hoster in der Regel Auftragsverarbeiter – der Vertrag mit ihm ist also weiter nötig.

Nächste Schritte

1. Anwendungsfall festlegen: Ein bis zwei konkrete Aufgaben, kein „KI für alles“.
2. Klein starten: Eine Workstation mit Ollama und Open WebUI genügt für einen Pilot mit einem kleinen Team.
3. Modelle vergleichen: Zwei oder drei Kandidaten mit eigenen Testfällen und dokumentierter Lizenz.
4. Skalierung planen: Bei vielen gleichzeitigen Nutzern auf GPU-Server mit vLLM wechseln; die OpenAI-kompatible Schnittstelle bleibt dieselbe.
5. Pflichten klären: Datenschutz-Dokumentation, Zuständigkeiten, und die Anforderungen der KI-Verordnung – siehe EU AI Act für Betreiber.

Wo Ihr Unternehmen insgesamt bei der digitalen Unabhängigkeit steht, können Sie mit dem Souveränitäts-Check einschätzen.