LLM-WIKI mit Ollama und Qwen3.8-27B lokal betreiben Teil 2-2

Schritt 5: Projekt anlegen

Beim ersten Start legst du ein Projekt an. Ein Projekt ist ein Verzeichnis auf der Festplatte, das später dein Vault enthält. Wähle einen Ort, den du auch außerhalb der App erreichst, denn genau dort liegen die Markdown-Dateien.

Die App bietet Vorlagen an, etwa General, Research, Reading oder Business. Sie legen unterschiedliche Startwerte für zwei Dateien fest, die das Verhalten steuern:

purpose.md beschreibt, wozu das Wiki da ist. Ziele, Leitfragen, Themenrahmen. Das Modell liest diese Datei bei jedem Ingest und jeder Anfrage mit.

schema.md beschreibt, wie das Wiki aufgebaut ist. Welche Seitentypen es gibt, welche Felder im Frontmatter stehen, wie verlinkt wird.

Die Wahl der Vorlage ist wichtiger, als sie aussieht, denn sie bestimmt die Seitentypen des Wikis. Ich habe das auf die harte Tour gelernt: Mein erster Versuch lief mit der Vorlage Reading. Die ist auf Bücher ausgelegt und erzeugt Verzeichnisse wie chapters, characters, plot-threads und themes. Das Modell hat meine erste Magazinausgabe dann brav als Buchkapitel einsortiert. Für Sachtexte, Magazine und technische Dokumente ist General die richtige Wahl. Sie erzeugt neutrale Seitentypen wie Entitäten und Konzepte, ohne Roman-Struktur.

Beide Dateien kannst du jederzeit im Editor anpassen. Genau hier liegt der Hebel, wenn du das Wiki auf ein eigenes Thema zuschneiden willst. Für andere Zwecke definierst du eigene Seitentypen.

Da ich PDF Dateien verarbeiten möchte und ich als Grundlage die MagPi Magazine verwenden werde heißt bei mir der Ordner und das Projekt mag-pi. Als Vorlage kommt General zum Einsatz und nicht Reading da es sich nicht um ein Buch handelt sondern um ein technisches Magazin.

LLM-WIKI – project folder general

Schritt 6: Ollama als Inferencing-Service einrichten

Das ist der Schritt, um den es mir in diesem Artikel eigentlich geht. Öffne die Einstellungen und lege den Modellanbieter fest.

Als Anbieter wählst du Ollama. Und hier lauert gleich der erste Stolperstein: Das Endpoint-Feld ist mit https://localhost:11434/v1 vorbelegt. Ollama spricht aber kein HTTPS. Mit dem vorbelegten Wert scheitert jeder Verbindungstest, und die Fehlermeldung verrät nicht warum. Ändere das eine Zeichen, aus https wird http:

http://localhost:11434/v1

Läuft Ollama auf einer anderen Maschine im Netz, trägst du deren Adresse ein, bei mir:

http://192.168.2.57:11434/v1

Danach wählst du das Modell aus der Liste. Die App fragt die verfügbaren Modelle beim Server ab, du solltest also die Namen aus Schritt 1 wiederfinden.

Drei Einstellungen lohnen einen zweiten Blick.

Chat und Ingest getrennt routen. Die App erlaubt für beide Aufgaben unterschiedliche Modelle. Das ist sinnvoll, denn der Ingest profitiert von einem starken Modell mit langem Kontext, während für den Chat oft ein schnelleres reicht. Wer mehrere Ollama-Server betreibt, kann die Last damit sauber verteilen. Ich nutze für den Ingest qwen3.8:27b, das stärkste Textmodell auf meiner Karte.

Reasoning ausschalten. Die Einstellung Reasoning steht auf Off, und so sollte sie bleiben. Reasoning-Modelle geben bei strukturierten Aufgaben gern ihre Denkschritte statt der Antwort aus. Die App weist selbst darauf hin, dass strukturierte Operationen das Reasoning ohnehin unterdrücken.

Zeitlimit anheben. Lokale Modelle brauchen für den zweistufigen Ingest länger als Cloud-Dienste. Die App hat dafür eine konfigurierbare Zeitüberschreitung, bei mir steht sie auf 30 Minuten. Wer sie zu knapp lässt, sieht abgebrochene Verarbeitungen, obwohl das Modell noch rechnet.

Ein Hinweis zum Kontextfenster-Regler: Er lässt sich auf sehr große Werte stellen, aber die tatsächliche Grenze setzt Ollama. Wer dort, wie ich, die Umgebungsvariable OLLAMA_CONTEXT_LENGTH gesetzt hat, deckelt damit auch, was die App real nutzen kann.

LLM-WIKI – ollama inferencing service

Image Captioning aktivieren

Damit auch die Bilder aus den PDFs analysiert und durchsuchbar werden, aktiviere ich das Image Captioning. Es hat in den Einstellungen einen eigenen Menüpunkt mit eigener Modellwahl.

Wichtig: Hierfür braucht es zwingend ein Vision-Modell, also eines mit Bildeingang. Ein reines Textmodell wie qwen3.8:27b kann keine Bilder sehen, egal wie stark es bei Text ist. Auf meinem Server übernimmt das qwen3-vl:32b aus Schritt 1. Die kleinere 8b-Variante wäre schneller, liest aber kleine Beschriftungen und Zahlen deutlich unzuverlässiger.

Auch hier gilt die http-Falle aus dem Ollama-Setup: Wenn das Image Captioning eine eigene Endpoint-Angabe hat, muss dort ebenfalls http statt https stehen.

LLM-WIKI – ollama image captioning

Schritt 7: Erstes Dokument einlesen

Wechsle in den Bereich Sources und importiere ein Dokument. Für den ersten Versuch nimmst du am besten ein überschaubares PDF, nicht das ganze Archiv. Bei einem lokalen Modell dauert der zweistufige Ingest je nach Dokumentgröße spürbar, ein hundertseitiges Magazin ist eher ein Projekt für nebenbei als für die Kaffeepause.

Die App unterstützt neben PDF auch DOCX, PPTX, Tabellen, EPUB und MOBI, dazu Bilder und Web-Clips. Für PDFs nutzt sie standardmäßig einen eingebauten Extraktor. Bei schwierigen Layouts lässt sich wahlweise MinerU einbinden, entweder als Cloud-Dienst oder lokal.

Es gibt zwei Wege, Dokumente hineinzubekommen. Entweder über den Import in der Oberfläche, oder du legst die Dateien direkt in den Ordner raw/sources/ im Projektverzeichnis. Für den zweiten Weg muss in den Einstellungen der Source Watch aktiviert sein, dann erkennt die App von außen abgelegte Dateien automatisch.

Und dabei eine Warnung aus eigener Erfahrung: Dateien in raw/sources/ danach nicht mehr verschieben oder löschen. Der Source Watch arbeitet in beide Richtungen. Verschwindet eine Quelldatei aus dem Ordner, räumt die App per Kaskadenlöschung alle daraus entstandenen Wiki-Seiten mit ab. Bei mir hat ein gut gemeintes Aufräumen so 17 fertige Wiki-Seiten gelöscht. Wer eine Quelle nur vorübergehend beiseite legen will, kopiert sie vorher woandershin.

Im Activity Panel siehst du die Verarbeitung Schritt für Schritt. Zuerst die Analyse, dann die Erzeugung der Wiki-Seiten. Danach schaust du dir an, was entstanden ist. Der Wiki-Bereich zeigt die neuen Seiten, der Graph die Verknüpfungen. Wichtig ist der ehrliche Blick auf die Qualität: Hat das Modell sinnvolle Seiten erzeugt oder nur Zusammenfassungen? Sind die Verlinkungen inhaltlich richtig? Genau hier entscheidet sich, ob ein lokales Modell für deinen Zweck ausreicht.

LLM-WIK I – ingest run

Schritt 8: Das Vault außerhalb der App

Öffne das Projektverzeichnis im Dateimanager. Du findest eine Struktur wie diese:

mein-wiki/
  purpose.md              Ziele und Leitfragen
  schema.md               Strukturregeln
  raw/
    sources/              die importierten Dokumente
    assets/               extrahierte Bilder
  wiki/
    index.md              Inhaltsverzeichnis
    log.md                Verlauf aller Operationen
    overview.md           automatische Gesamtübersicht
    entities/  concepts/  sources/  queries/
  .obsidian/              Obsidian-Konfiguration
  .llm-wiki/              App-Konfiguration und Chatverlauf

Diese Struktur von klassischen Markdown-Dateien also für den Menschen und die Maschine gleichermase gut lesbarer Information ist der eigentliche Mehrwert dieses Ansatzes. Deine Wissensbasis besteht somit aus normalen Markdown-Dateien. Du kannst sie in Git versionieren, mit jedem Editor bearbeiten oder in Obsidian öffnen. Die App erzeugt sogar eine passende .obsidian-Konfiguration mit.

Auch die Datei wiki/log.md lohnt einen regelmäßigen Blick. Dort protokolliert die App jede Operation, jeden Ingest und auch jede Löschung. Als bei mir die 17 Seiten verschwanden, stand die Ursache dort schwarz auf weiß.

Wer Obsidian nutzt, öffnet einfach das Projektverzeichnis als Vault. Beide Werkzeuge arbeiten dann auf denselben Dateien, die App zum Aufbauen, Obsidian zum Lesen und Nachbearbeiten.

Schritt 9: Anbindung für eigene Agenten

Für alle, die mit Coding-Agenten arbeiten, ist die lokale Schnittstelle interessant. Unter Einstellungen, Abschnitt API und MCP, aktivierst du die HTTP-API und erzeugst einen Token. Der Dienst lauscht dann auf 127.0.0.1:19828, ausschließlich lokal.

Ein Funktionstest ohne Token:

Befehl: curl -s http://127.0.0.1:19828/api/v1/health

Über diese Schnittstelle können externe Werkzeuge das Wiki durchsuchen, Dateien lesen und den Graph abfragen. Für MCP-fähige Clients liefert das Projekt zusätzlich einen MCP-Server mit, und für Claude Code oder Codex gibt es eine fertige Agent-Skill zum Installieren.

Damit lässt sich das Wiki als Wissensquelle für eigene Automatisierungen nutzen, ohne die App-Oberfläche zu bemühen.

Was man wissen sollte

Vier Punkte, die in keiner Feature-Liste stehen.

Die Modellqualität entscheidet über alles. Der Ingest ist die anspruchsvollste Aufgabe im ganzen System. Das Modell muss ein Dokument verstehen, sinnvolle Seiten schneiden, Verbindungen zum Bestand erkennen und sauberes Frontmatter erzeugen. Kleine lokale Modelle liefern hier deutlich schwächere Struktur als große. Wer die Möglichkeit hat, sollte für den Ingest das stärkste verfügbare Modell einsetzen und für den Chat ein schnelleres.

Bildbeschreibungen sind Hinweise, keine Fakten. Vision-Modelle beschreiben Abbildungen flüssig und strukturiert, aber sie lesen kleine Beschriftungen und Zahlen nicht zuverlässig. In meinen Tests wurden Typenbezeichnungen falsch gelesen und plausibel klingende Maße frei ergänzt. Für die Auffindbarkeit einer Grafik reicht das, als Quelle für exakte Werte nicht.

Der Source Watch löscht mit. Wer Quelldateien aus raw/sources/ entfernt oder verschiebt, entfernt damit auch die daraus entstandenen Wiki-Seiten. Das ist konsequent gedacht, überrascht aber beim ersten Mal. Quellen bleiben liegen, sobald sie eingelesen sind.

Es ist eine Desktop-Anwendung. Sie läuft nicht als Serverdienst im Hintergrund. Wer sein Vault auf einem Server liegen haben will, braucht eine Synchronisation dazwischen, etwa Syncthing, oder betreibt die App wie ich direkt auf dem GPU-Server mit Desktop-Umgebung. Für den Einstieg ist der lokale Betrieb der einfachere Weg.

Fazit

LLM Wiki ist die erste Umsetzung des Karpathy-Musters, die ich als fertiges Werkzeug empfehlen würde. Der Aufbau ist durchdacht, die Obsidian-Kompatibilität nimmt die Angst vor dem Lock-in, und die Anbindung an Ollama funktioniert ohne Umwege, sobald man die http-Falle kennt.

Für alle, die ihre Dokumente nicht in eine Cloud geben wollen, ist besonders die Kombination interessant: eigene Hardware, eigene Modelle, eigene Dateien. Das Wissen bleibt im Haus, und am Ende steht kein undurchsichtiger Index, sondern ein Ordner mit lesbaren Markdown-Dateien.

Wie gut das Ergebnis wird, hängt am Modell. Aber genau das ist der Reiz: Man kann es ausprobieren, vergleichen und wechseln, ohne bei jedem Versuch eine Rechnung zu bekommen.

(Dieser Artikel wurde mit der Unterstützung von Generativer AI geschrieben)

Hier geht es zurück zu Teil 1/2: https://ai-box.eu/ai-pipeline/llm-wiki-mit-ollama-und-qwen3-8-27b-lokal-betreiben/2713/