Llama.cpp, Ollama oder LM Studio – welche lokale KI passt zum eigenen Archiv?

Aktualisiert am 8. August 2026 / in Technik

Kurz gesagt

Lokale Sprachmodelle versprechen mehr Kontrolle über vertrauliche Inhalte. Für ein digitales Archiv ist die entscheidende Frage aber nicht, welches Programm die meisten Einstellmöglichkeiten bietet. Entscheidend ist, ob ein klarer Anwendungsfall besteht, ob die vorhandene Hardware genügt und ob der Versuch vom maßgeblichen Archivbestand getrennt bleibt.

Llama.cpp bietet eine sehr direkte und weitreichend steuerbare Inferenzumgebung. Ollama vereinfacht Modellverwaltung und API-Betrieb. LM Studio verbindet eine grafische Arbeitsumgebung mit lokalen Schnittstellen. Keines dieser Werkzeuge macht ein Archiv automatisch besser.

Meine aktuelle Entscheidung lautet deshalb:

Lokale KI wird getrennt und zeitlich begrenzt getestet. Sie wird nicht in die produktive Paperless-ngx-Umgebung integriert und erhält keinen ungeprüften Zugriff auf den vollständigen Dokumentenbestand. Das Archiv muss auch ohne KI vollständig verständlich, durchsuchbar und übergabefähig bleiben.

Das eigentliche Problem: Nutzen vor Installation

Eine allgemeine Installationsanleitung für Llama.cpp wäre schnell veraltet und würde die entscheidende Frage überspringen: Was soll die lokale KI im Archiv zuverlässig leisten?

Plausible Testfälle sind beispielsweise:

• lange eigene Notizen zusammenfassen,
• mögliche Schlagwörter für eine menschliche Prüfung vorschlagen,
• Fragen an einen begrenzten, kopierten Testbestand stellen,
• Texte nach einem festen Schema strukturieren,
• verschiedene Modelle anhand derselben Aufgaben vergleichen,
• vertrauliche Entwürfe verarbeiten, die nicht an einen Cloud-Dienst übertragen werden sollen.

Ungeeignet ist dagegen die unkontrollierte automatische Übernahme von Modellantworten in Dokumenttypen, Korrespondenten, Personenangaben oder dauerhafte Archivmetadaten. Ein Sprachmodell erzeugt Wahrscheinlichkeiten. Es bestätigt keine Quellen und belegt keine sachliche Richtigkeit.

Damit gilt dieselbe Grundregel wie bei KI in Paperless-ngx: Ein Vorschlag kann Arbeit vorbereiten. Die dauerhafte Zuordnung braucht nachvollziehbare Regeln oder eine menschliche Prüfung.

Drei Werkzeuge mit unterschiedlichen Schwerpunkten

Die Programme überschneiden sich, setzen aber andere Schwerpunkte. Die folgende Tabelle ist keine Rangliste, sondern eine Entscheidungshilfe.

Llama.cpp beschreibt sich selbst als C/C++-Umgebung für Inferenz auf unterschiedlichen Hardwareplattformen. Neben llama-cli stellt das Projekt mit llama-server einen HTTP-Server mit Weboberfläche und OpenAI-kompatiblen Endpunkten bereit. Das ist leistungsfähig, macht Llama.cpp aber noch nicht zu einer fertigen Archiv- oder Dokumentenanwendung.

Ollama stellt nach der Installation eine lokale API bereit und verwaltet heruntergeladene Modelle. LM Studio kann ebenfalls als lokaler Server arbeiten und unter anderem OpenAI-kompatible Endpunkte anbieten. Eine kompatible Schnittstelle erleichtert Tests und spätere Werkzeugwechsel. Sie ist jedoch kein Sicherheitsmerkmal und kein Beleg für gleiche Modellqualität.

GGUF und Quantisierung verständlich erklärt

Llama.cpp arbeitet typischerweise mit Modellen im GGUF-Format. Eine GGUF-Datei enthält das Modell und technische Angaben, die für seine Ausführung benötigt werden. Das Dateiformat sagt noch nichts darüber aus, ob das Modell für deutsche Archivtexte geeignet, rechtlich unproblematisch oder fachlich zuverlässig ist.

Quantisierung reduziert die Genauigkeit, mit der Modellgewichte gespeichert werden. Dadurch sinken gewöhnlich Speicherbedarf und Rechenaufwand. Kleinere quantisierte Modelle lassen sich eher auf vorhandener Hardware ausführen. Der Preis kann eine geringere Ausgabequalität sein. Wie stark dieser Unterschied ausfällt, hängt von Modell, Quantisierung und Aufgabe ab und muss mit eigenen Testfällen gemessen werden.

Für die Praxis bedeutet das:

1. Zuerst eine klar begrenzte Aufgabe festlegen.
2. Ein Modell mit nachvollziehbarer Herkunft und Lizenz auswählen.
3. Eine zur vorhandenen Hardware passende Variante verwenden.
4. Geschwindigkeit, Speicherbedarf und Ergebnisqualität protokollieren.
5. Erst danach entscheiden, ob ein größerer Kontext oder ein anderes Modell wirklich nötig ist.

Die größte verfügbare Datei ist nicht automatisch die beste Wahl. Ein kleineres Modell, das eine enge Aufgabe reproduzierbar erfüllt, ist für einen Archivtest oft wertvoller als ein großes Modell, das den Rechner blockiert.

Hardware realistisch bewerten

Lokale KI beansprucht Arbeitsspeicher, gegebenenfalls Grafikspeicher, CPU- oder GPU-Leistung und zusätzlichen Speicherplatz für Modelle. Modellgröße und Kontextfenster wirken sich direkt auf diese Anforderungen aus. CPU-/GPU-Hybridbetrieb kann helfen, beseitigt physische Grenzen aber nicht.

Ein älterer Arbeitsplatzrechner mit 32 GB RAM und einer Grafikkarte mit begrenztem Grafikspeicher kann für kleinere quantisierte Modelle und technische Versuche ausreichen. Er ist deshalb noch keine moderne KI-Workstation. Lange Kontexte, große Modelle oder mehrere gleichzeitige Anfragen können schnell zu langen Antwortzeiten oder Speichermangel führen.

Ein kleiner Server mit 8 GB RAM, der bereits Paperless-ngx, OCR und weitere produktive Dienste trägt, ist für diesen Zweck ungeeignet. Zusätzliche Inferenz würde mit Dokumentenimport, Volltextverarbeitung, Datenbank, Sicherung und Fehleranalyse um dieselben Ressourcen konkurrieren.

Auch NAS, Domänenserver und Sicherungssysteme sollten ihre eigentlichen Aufgaben behalten. Ein Experiment ist kein Grund, Datenhaltung und Archivbetrieb mit einer weiteren fehleranfälligen Daueraufgabe zu belasten.

Warum der Paperless-Server keine KI-Plattform wird

Paperless-ngx ist eine produktive Arbeits- und Rechercheoberfläche für Dokumente. Seine Verfügbarkeit, OCR-Verarbeitung und Sicherbarkeit sind wichtiger als ein lokales Sprachmodell.

Eine direkte KI-Integration würde zusätzliche Abhängigkeiten schaffen:

• Modell- und Laufzeitversionen müssten gepflegt werden.
• CPU, RAM und Speicher würden zwischen Archiv und Inferenz geteilt.
• Fehler wären schwerer einem Dienst zuzuordnen.
• Dokumentinhalte könnten in neue Protokolle, Caches oder Gesprächsverläufe gelangen.
• automatisch erzeugte Metadaten könnten wie bestätigte Archivangaben wirken.

Deshalb wird nicht am produktiven Dokumentenbestand ausprobiert. Für einen Test werden wenige geeignete Dokumentkopien ausgewählt, personenbezogene Angaben soweit möglich entfernt und erwartete Ergebnisse vorab festgelegt. Nach dem Versuch werden Testdaten, Protokolle und Modelle entweder bewusst dokumentiert übernommen oder vollständig aus der Testumgebung entfernt.

Lokal bedeutet nicht automatisch sicher

Eine lokale Ausführung kann verhindern, dass ein Prompt zwangsläufig an einen externen Modelldienst gesendet wird. Daraus folgt aber nicht automatisch ein sicherer Gesamtbetrieb.

Zu prüfen sind mindestens:

• Woher stammen Programm und Modell?
• Welche Lizenz gilt für Modell und beabsichtigte Nutzung?
• Speichert die Oberfläche Chatverläufe, Protokolle oder Dateikopien?
• Lauscht ein Server nur auf dem lokalen Rechner oder im Netzwerk?
• Ist eine API authentifiziert und durch eine Firewall begrenzt?
• Welche anderen Benutzer oder Programme können auf den Dienst zugreifen?
• Wie werden Testdaten und Modellstände wieder entfernt?

llama-server, Ollama und LM Studio können Schnittstellen für andere Programme bereitstellen. Das ist für Tests praktisch, erweitert aber die Angriffsfläche. Ein Dienst sollte zunächst ausschließlich lokal erreichbar sein. Eine Freigabe im LAN oder gar Internet benötigt eine bewusste Netz-, Authentifizierungs- und Protokollierungsentscheidung.

Auch lokal erzeugte Antworten können vertrauliche Inhalte wiederholen oder falsch zusammenführen. Die ausführlichere Einordnung steht in Meine Daten gehören mir – KI, Sicherheit und Datenschutz.

Ein sicherer Testablauf

Ein lokaler KI-Versuch lässt sich wie ein kleines Prüfprojekt behandeln:

1. Frage definieren: Eine konkrete Aufgabe und messbare Erfolgskriterien festlegen.
2. System trennen: Einen Arbeitsplatzrechner statt produktiver Server verwenden.
3. Testdaten kopieren: Nur wenige freigegebene Kopien bereitstellen; Originale bleiben unberührt.
4. Netzgrenze setzen: Dienst zunächst nur lokal erreichbar machen.
5. Modell dokumentieren: Herkunft, Lizenz, Dateiname, Quantisierung und Prüfsumme festhalten.
6. Ergebnisse prüfen: Sachliche Fehler, Auslassungen, erfundene Angaben und Laufzeit dokumentieren.
7. Keine automatische Rückschreibung: Resultate nicht direkt in Paperless, WDB oder Archivmetadaten übernehmen.
8. Aufräumen oder übernehmen: Testdaten, Logs und Modelle gezielt löschen oder den erfolgreichen Versuch nachvollziehbar dokumentieren.

Dieser Ablauf hält die Rollen klar: Das Archiv liefert kontrollierte Testkopien. Das Modell erzeugt Vorschläge. Der Mensch bewertet das Ergebnis. Erst eine bestätigte Information darf in einen dauerhaften Bestand zurückkehren.

Wann welches Werkzeug sinnvoll ist

Llama.cpp ist sinnvoll, wenn technische Kontrolle selbst Teil des Tests ist: etwa Vergleich von Quantisierungen, Kontextgrößen, GPU-Auslagerung oder direkter Serverparameter. Es verlangt die größte Bereitschaft, den Ablauf selbst zu verstehen und zu dokumentieren.

Ollama ist sinnvoll, wenn ein lokaler Dienst mit einfacher Modellverwaltung für ein vorhandenes Programm oder ein kleines Skript benötigt wird. Die geringere Einstiegshürde ersetzt trotzdem keine Prüfung von Modell, API-Reichweite und Datenfluss.

LM Studio ist sinnvoll, wenn Modelle zunächst visuell geladen, verglichen und interaktiv getestet werden sollen. Die Desktopoberfläche erleichtert den Einstieg. Für einen dauerhaften Dienst müssen dennoch Servereinstellungen, Protokolle, Modellstände und Zugriffsgrenzen dokumentiert werden.

Wer noch keinen klaren Anwendungsfall hat, benötigt keines der drei Werkzeuge. Das ist keine verpasste Chance, sondern eine sinnvolle Betriebsentscheidung.

Aktuelle Entscheidung

Llama.cpp wird nicht in die bestehende Paperless-ngx-Umgebung integriert. Ein zeitlich begrenzter Versuch auf einem getrennten Windows-Arbeitsplatz ist denkbar, sobald eine konkrete Aufgabe mit erwartbarem Nutzen vorliegt. Eine neue KI-Workstation oder zusätzliche Grafikkarte wird dafür derzeit nicht beschafft.

Diese Entscheidung kann sich mit Hardware, Modellen und Anforderungen ändern. Der archivische Maßstab bleibt jedoch stabil:

Programme und Modelle sind austauschbare Arbeitsebenen. Maßgeblich bleiben verständliche Dateien, bestätigte Metadaten, dokumentierte Entscheidungen und geprüfte Sicherungen.

Wie eine solche Werkzeugtrennung praktisch in den Arbeitsalltag passt, erläutert KI in der IT-Praxis. Für die langfristige Perspektive gilt zusätzlich: Das digitale Archiv muss ohne mich funktionieren – und ebenso ohne ein bestimmtes Sprachmodell.