Lokales LLM: Definition, Vorteile und Grenzen

Beispiel aus der Praxis

Szenario zur Veranschaulichung: Ein Unternehmen möchte eingehende Lieferscheine automatisch auslesen, darf die Dokumente aber nicht an einen Cloud-Dienst schicken. Ein n8n-Workflow nimmt die Dokumente entgegen, wandelt sie in Text um und schickt ihn an ein lokales LLM, das auf einem Server im eigenen Netz mit Ollama läuft.

Ollama nimmt dafür über das Feld format ein JSON-Schema entgegen und erzwingt damit die Struktur der Antwort (Ollama-Dokumentation, Structured Outputs). Das Modell liefert also Lieferant, Datum und Positionen in festen Feldern, die der Workflow prüft und in das Warenwirtschaftssystem schreibt. Bei fehlenden Pflichtfeldern geht das Dokument an einen Menschen zur Kontrolle.

Der Unterschied zu einer Cloud-Lösung liegt nicht im Ablauf, sondern im Ort der Verarbeitung. Ollama hält dazu fest: „Ollama runs locally. We don't see your prompts or data when you run locally“ (Ollama FAQ). Der Preis dafür sind eigene Hardware, eigener Betrieb und die Aufgabe, ein Modell zu finden, das die Extraktion zuverlässig genug erledigt.

Wie funktioniert ein lokales LLM?

Ein lokales LLM besteht aus zwei Teilen: den Modellgewichten, also einer großen Datei mit den trainierten Parametern, und einer Laufzeitumgebung, die das Modell lädt und Anfragen beantwortet. Die Gewichte werden einmal heruntergeladen, danach läuft die Verarbeitung ohne Verbindung zum Modellanbieter.

Die Laufzeitumgebung stellt meist eine Programmierschnittstelle bereit, über die andere Anwendungen das Modell ansprechen. Ollama bietet dafür eine REST-API, etwa den Endpunkt /api/chat, und bindet standardmäßig an 127.0.0.1 auf Port 11434 (Ollama-Dokumentation; Ollama FAQ). Damit ist der Dienst zunächst nur auf dem eigenen Rechner erreichbar.

Werkzeuge wie n8n, Chat-Oberflächen oder eigene Skripte schicken ihre Anfragen dann an diese lokale Adresse statt an die API eines Cloud-Anbieters. Für die Anwendung sieht ein lokales Modell deshalb oft ähnlich aus wie ein Cloud-Modell.

Lokales LLM vs. Cloud-LLM: Was ist der Unterschied?

Merkmal	Lokales LLM	Cloud-LLM
Ort der Verarbeitung	Eigene Hardware im eigenen Netz	Rechenzentrum des Anbieters
Datenfluss	Daten verlassen das Netz nicht	Daten gehen an den Anbieter, geregelt per Vertrag
Kosten	Hardware, Strom, Betrieb	Nutzungsabhängige Gebühren
Modellauswahl	Frei verfügbare Modelle	Auch die proprietären Modelle der Anbieter
Wartung	Updates, Monitoring und Ausfallsicherheit selbst	Übernimmt der Anbieter
Skalierung	Begrenzt durch eigene Hardware	Weitgehend durch den Anbieter abgedeckt

Die Entscheidung ist selten grundsätzlich. Viele Architekturen kombinieren beides: sensible Schritte lokal, allgemeine Aufgaben über eine Cloud-API.

Was sind Open-Weight-Modelle?

Open-Weight-Modelle sind Sprachmodelle, deren trainierte Gewichte veröffentlicht werden. Man kann sie herunterladen und selbst betreiben. Ollama nennt auf seiner Projektseite unter anderem Modellfamilien wie Gemma, Qwen, DeepSeek und gpt-oss (Ollama auf GitHub, Stand: Oktober 2026).

Open-Weight ist nicht automatisch Open Source. Oft sind nur die Gewichte frei, nicht aber Trainingsdaten oder Trainingscode, und die Lizenzen unterscheiden sich. Vor dem Einsatz im Unternehmen lohnt deshalb ein Blick in die Lizenz des jeweiligen Modells, besonders bei kommerzieller Nutzung.

Was ist Quantisierung bei lokalen LLMs?

Quantisierung speichert die Gewichte eines Modells mit geringerer Genauigkeit. Hugging Face beschreibt sie als Verfahren, das den Speicherbedarf beim Laden und Nutzen eines Modells senkt und dabei möglichst viel Genauigkeit erhalten soll (Hugging Face, Quantization Overview).

Statt mit 32-Bit-Gleitkommazahlen werden die Gewichte dann etwa mit 16 Bit oder als Ganzzahlen mit 8 oder 4 Bit gespeichert (Hugging Face, Quantization Overview). Dadurch passt ein Modell auf Hardware, die für die volle Genauigkeit zu klein wäre.

Für lokale Modelle ist das Format GGUF verbreitet, das aus dem Projekt llama.cpp stammt (Hugging Face, Quantization Overview). Wie stark die Qualität sinkt, hängt von Modell, Verfahren und Aufgabe ab und sollte mit eigenen Beispielen geprüft werden.

Was muss man beim Betrieb eines lokalen LLM beachten?

Lokal heißt nicht automatisch sicher. Wird die Programmierschnittstelle über das eigene Netz freigegeben, braucht sie dieselben Schutzmaßnahmen wie jeder andere interne Dienst: Zugriffskontrolle, verschlüsselte Verbindungen und Protokollierung. Der Standard von Ollama, nur an 127.0.0.1 zu binden, schränkt den Zugriff zunächst auf den eigenen Rechner ein (Ollama FAQ).

Ein zweiter Punkt ist das Kontextfenster. Ollama nutzt laut eigener Dokumentation standardmäßig ein Kontextfenster von 4.096 Tokens, das sich über OLLAMA_CONTEXT_LENGTH oder den Parameter num_ctx erhöhen lässt (Ollama FAQ, Stand: Oktober 2026). Lange Dokumente werden sonst unbemerkt abgeschnitten.

Auch lokale Modelle sind anfällig für Prompt Injection und können falsche Angaben erzeugen. Guardrails, feste Ausgabeformate über Structured Output und eine Freigabe per Human-in-the-Loop gelten deshalb genauso wie in der Cloud.

Für welche Aufgaben eignet sich ein lokales LLM?

Gut geeignet sind klar abgegrenzte Aufgaben mit sensiblen Daten: Informationen aus Dokumenten extrahieren, Texte zusammenfassen, Anfragen nach festen Kategorien einordnen. Hier zählt ein zuverlässiges Format mehr als breites Weltwissen.

Auch für Embeddings ist der lokale Betrieb eine Option. Ollama bietet mit /api/embed einen Endpunkt, der aus Text Vektoren erzeugt (Ollama-Dokumentation). Damit lässt sich die Suche eines RAG-Systems betreiben, ohne Dokumente an einen Cloud-Dienst zu schicken; mehr dazu unter Embeddings.

Weniger geeignet sind Aufgaben, bei denen die stärksten verfügbaren Modelle einen deutlichen Unterschied machen, etwa lange Agentenläufe mit vielen Tools. Ob ein lokales Modell reicht, zeigt am verlässlichsten ein Vergleich mit echten Beispielen aus dem eigenen Prozess.