InfoForge: Offline-Wikipedia als RAG-Quelle für meine lokalen KI-Agenten

Veröffentlicht
28 August 2026
Aktualisiert
16 September 2026
Von
Jacob Lloyd — mit KI-Unterstützung geschrieben, im Nachhinein
Lesezeit
14 Min. Lesezeit

Kurz gesagt: InfoForge ist eine Kopie der gesamten englischen Wikipedia, gespeichert auf einem Computer in meinem Haus, dazu ein kleines Programm, mit dem die KI-Assistenten, die ich betreibe, darin nachschlagen können. Stellt man eine Frage, durchsucht der Assistent – statt aus dem Gedächtnis zu antworten – diese Artikel, liest die passenden und schreibt eine Antwort, die benennt, aus welchen Artikeln sie stammt. Wenn er nichts Relevantes findet, sagt er „Ich konnte es nicht finden“, anstatt sich etwas auszudenken. Es wird nichts an ein Unternehmen gesendet, niemand protokolliert die Frage, und es funktioniert weiter, wenn das Internet ausfällt.

Ich fragte ein lokales 8B-Modell, wann der Schriftsteller Natsume Sōseki geboren wurde. Es antwortete „9. Februar 1867“ und tat dann den Teil, der mir eigentlich wichtig war: Es nannte die Artikel, in denen es das nachgelesen hatte. Das Modell kennt diese Tatsache nicht. Es hat sie nachgeschlagen, in einer 52,69 GB großen Kopie der Wikipedia auf einem Rechner in meinem Haus, wobei das Internet für diesen Vorgang keine Rolle spielte.

tl;dr

  • Was es ist: die vollständige englische Wikipedia als einzelne ZIM-Datei (19,19 Millionen Einträge, Juni-2026-Dump, ohne Bilder), lokal bereitgestellt, dazu eine kleine Python-CLI, die sie in eine Retrieval-Quelle für ein lokales Modell verwandelt.
  • Was es kostet: nichts. Ein Download, ca. 53 GB Speicherplatz, kein Konto, kein API-Schlüssel, kein Abonnement.
  • Wie schnell: eine vollständige quellengestützte Antwort dauert 4–10 Sekunden, und fast alles davon ist das Sprachmodell beim Denken. Suche und Artikelabruf sind der günstige Teil (Zahlen unten).
  • Die Regel, die es nützlich macht: Wenn die Suche nichts findet, gibt das Werkzeug einen Fehler aus und beendet sich mit Code 3. Wenn die Quellen die Antwort nicht enthalten, wird das Modell angewiesen, das zu sagen. Die Agenten, die es nutzen, melden eine fehlgeschlagene Suche, anstatt aus dem Gedächtnis zu antworten.
  • Was es niemals tut: das Haus verlassen. Es gibt keinen Anbieter, keinen API-Aufruf und kein Abfrageprotokoll.

Aktualisiert am 16.09.2026: Zwei Tage nach dem ersten Verfassen dieses Textes wurde das einfache Skript zu einem ausgereiften CLI-Tool (Version 2.0.0): infoforge ask, search, serve start|stop|status|recreate, status sowie ein doctor-Befehl, der alle Verbindungen überprüft. Der unten stehende Download enthält diese neue Version – nicht das ursprüngliche Skript. Die Beispiele auf dieser Seite stammen aus v2 und wurden am 16.09.2026 ausgeführt; die bekannteste Antwort der ersten Version, betreffend den Roman *Kokoro*, findet sich nun im Abschnitt „Fallstricke“, da v2 ihn nicht mehr findet. Ich fügte echte Container-Parameter, eine Service-Einheit, ein Ablehnungs-Szenario sowie Korrekturen zur Angabe der Abrufzeit hinzu.

Warum das nötig ist – obwohl das Modell ja „Dinge weiß“

Weil es das in Wirklichkeit nicht tut; das Fehlerverhalten ist dabei äußerst problematisch. Fragt man ein kleines Modell nach einem Datum, einer chemischen Eigenschaft oder einem Ortsnamen, liefert es eine flüssige, selbstbewusste und plausibel klingende Antwort – ohne irgendeinen Hinweis darauf, ob sie stimmt. Es lügt nicht; es hat schlicht keine Möglichkeit, zwischen gespeichertem Wissen und eigenständiger Generierung zu unterscheiden. Das ist für literarische Texte in Ordnung – für Fakten jedoch katastrophal.

Eine Retrieval-Lösung behebt das Problem – doch übliche Ansätze setzen eine Cloud-Such-API voraus: Die Anfrage geht an ein Unternehmen, welches sie protokolliert; das eigene Modell hängt somit von der Verfügbarkeit und den Nutzungsbedingungen Dritter ab. In meinem Haushalt, wo KI-Systeme Fragen meiner Kinder beantworten, gefällt mir an diesem Ansatz nichts.

Wikipedia löst beide Probleme auf einen Schlag: Es ist das dichteste allgemeine Wissenskorpus überhaupt; man darf es legal komplett herunterladen – und es passt auf eine Festplatte, die weniger kostet als ein Abendessen. Das Kiwix-Projekt hat vor Jahren bereits die schwere Arbeit geleistet: Es packt ganze Wikis in das komprimierten, indexierten ZIM-Format – ideal für Schulen, Schiffe oder Orte ohne Internetanschluss. Ich leite einfach eine KI darauf hin, statt eines Browsers.

Was am Ende herauskommt

Eine Frage wird eingegeben, eine Antwort erhalten – dazu eine nummerierte Liste von Zitaten, die die genutzten Wikipedia-Artikel aufzeigen. Dies ist ein echter Testlauf vom 16.09.2026 (die Serveradresse ist Loopback):

$ infoforge ask "Wann wurde Natsume Soseki geboren?"
infoforge: Warnung: Seite zur Mehrdeutigkeit wird übersprungen: Natsume
infoforge: Warnung: Seite zur Mehrdeutigkeit wird übersprungen: Soseki
infoforge: Verknüpfung mit 5 Artikeln erfolgt
Laut den vorliegenden Quellen wurde Natsume Sōseki am 9. Februar 1867 geboren. ...

Zitate:
[1] Natsume Soseki — http://127.0.0.1:8080/content/wikipedia_en_all_nopic/Natsume_Soseki
[2] Natsume Sōseki — http://127.0.0.1:8080/content/wikipedia_en_all_nopic/Natsume_S%C5%8Dseki
[3] Beongcheon Yu — ...

Der gesamte Vorgang dauerte 4,4 Sekunden. So sieht es aus, wenn keine passenden Quellen gefunden werden:

$ infoforge search "qzxvbnm plorkwidget fnargle"
infoforge: Fehler: Für ‚qzxvbnm plorkwidget fnargle‘ wurden keine Quellen gefunden
$ echo $?
3

Kein Textabschnitt, kein „Raten“ – lediglich ein Exit-Code, den Skripte problemlos auswerten können. ask liefert denselben Code 3 sowie Hinweise, eventuell einfachere Suchbegriffe zu nutzen oder infoforge doctor auszuführen. Die vollständige Exit-Tabelle ist kurz: 0 = Erfolg; 2 = fehlerhafte Konfiguration oder falsche Nutzung; 3 = keine passenden Quellen; 4 = keine Zitate genannt (nur bei --strict); 5 = alle Modell-Endpunkte unerreichbar. Selbst im Fall von Exit-Code 5 listet das Tool die gefundenen Artikel auf – der Abruf war also nicht umsonst.

So funktioniert es

Fünf Schritte – keiner davon besonders raffiniert; ich empfehle, es auch so zu belassen.

Schlüsselwort-Extraktion: Die Frage ist nicht die eigentliche Suche. Kiwix verknüpft alle Suchbegriffe mit „UND“ – weshalb „Wer schrieb Kokoro und wann erschien es?“ kaum Treffer liefert, während Kokoro eine gute Abfrage ist. Der Kern des Extrahierers ist ein Stoppwort-Filter, der die ursprüngliche Wortreihenfolge beibehält:

def keyword_query(question: str) -> str:
    tokens = _TOKEN_RE.findall(question)
    keywords = [
        t for t in tokens
        if t.lower() not in _STOPWORDS and t.lower() not in _WEAK_VERBS
    ]
    return " ".join(keywords) if keywords else question.strip()

Version 2 ergänzt zwei Neuerungen: Zunächst werden großgeschriebene Phrasen aus der Frage als Artikeltitel versucht; anschließend werden alle Treffer neu bewertet, sodass Seiten zur Mehrdeutigkeit, reine Jahreszahlen sowie „Liste von…“-Artikel zurückfallen.

Suche: Kiwix’ Volltextsuche basiert auf einem echten Suchindex – kein einfaches grep. Sie ist der Grund, weshalb das System überhaupt funktioniert. Zu Beginn lieferte sie innerhalb von 3 bis 30 Millisekunden passende Titel aus 19,19 Millionen Einträgen. Am 16.09.2026, an einem etwas beschäftigteren Tag auf demselben Rechner, dauerte die gleiche Abfrage 90–730 ms. Ich vermute, dass der Index damals nicht mehr im Cache lag – doch im Vergleich zur Verarbeitungszeit des Modells merkt man das kaum. In diesem System gibt es weder Embeddings noch Vektor-Datenbanken oder sonstige Strukturen, die bei Update des Dumps neu aufgebaut werden müssten: Wikipedia-Redakteure haben die „Chunks“ bereits erstellt – sie nennen sie Artikel.

Abrufen und Kürzen: kiwix-serve liefert einen Artikel über Loopback in etwa 1 ms, sobald der Cache warm ist. Meine Messungen mit curl an drei zuvor gelesenen Artikeln ergaben 0,7–1,1 ms; beim ersten Abruf waren es 6–9 ms. In meinem ersten Entwurf stand „0,5 ms“ – ohne darauf hinzuweisen, dass dies nur ein Warm-Cache-Wert ist. Das Kürzen erfordert etwas Urteilsvermögen: Ein Schnitt vom Anfang entfernte oft die gesuchte Antwort, da diese meist weiter hinten in langen Artikeln steht. Daher behält jeder Artikel einen kurzen Einleitungsabschnitt (ein Viertel des Budgets) sowie ein Fenster um den Absatz, der am besten zu den seltensten Wörtern der Frage passt.

Der verankerte Prompt: Das ist das eigentliche Geheimnis – und er besteht aus nur vier Sätzen. Zuerst kommen die Regeln, dann die nummerierten Quellen, schließlich die Frage:

Du bist ein Fragen-Beantworter, der ausschließlich anhand der unten stehenden Quelltexte arbeitet.
Beantworte die Frage des Nutzers ausschließlich mit Informationen aus diesen Quellen. Falls sie nicht enthalten sind, sage das deutlich.
Wenn du Informationen aus einer Quelle nutzt, zitiere den Artikeltitel (z.B.: „laut <Titel>“).
Erfinde keine Fakten, Titel oder URLs, die in den Quellen nicht vorkommen.

Quelle 1: <Titel>
<gekürzter Artikeltext>
...
Frage: <die eingegebene Frage>

Die Temperatur-Einstellung liegt bei 0,3 statt 0; der Kommentar im Code vermerkt, dass 0,0 bei einigen lokalen Tests zu Endlosschleifen bei repetitiven Textabschnitten führte. Es handelt sich um einen Prompt – keine Garantie; daher existiert der nächste Abschnitt.

Das Modell. Ein lokales Reasoning-Modell (DeepSeek-R1 8B), das auf dem GPU-Server im Haus läuft, generiert die Antwort. Die Q4_K_M-Datei ist 5,0 GB groß; der KV-Cache verbraucht zudem etwa 0,15 GB pro 1.000 Tokens an Kontext bei f16. Somit belaufen sich die Modellgewichte sowie der Speicherbedarf für einen 32.000-Token-Kontext auf insgesamt rund 10 GB – noch vor dem eigentlichen Rechenvorgang. Vor dem Ausgeben wird der Antwort jeglicher <pre>-Text entfernt. Meine ursprüngliche Messung ergab für die gesamte Prozesskette etwa 8 Sekunden; bei drei Tests am 16.09.2026 lagen die Zeiten bei 4,4, 5,2 und 9,7 Sekunden. Die Suche ist kostenlos – das „Nachdenken“ des Modells hingegen nicht. Es gibt keinen lokalen Ersatzmechanismus mehr: Am 16.09.2026 habe ich den Modellserver auf dem Mini-PC entfernt. Falls der GPU-Server keine Antwort liefert, beendet das Tool den Prozess mit Exit-Code 5 – und gibt trotzdem die gefundenen Artikel aus.

„Grounding“ als Verweigerungsmechanismus

Dies ist die Entscheidung im Design, die ich am entschiedensten verteidigen würde – und sie ist keine rein technische Entscheidung.

Ein Prompt wie „Verwenden Sie ausschließlich diese Quellen“ ist eine Anweisung. Meist befolgen Modelle sie; manchmal ignorieren sie sie jedoch, insbesondere wenn die Quellen begrenzt sind und das Modell zufällig etwas weiß, das passt. Wenn dieser Satz die einzige Absicherung des Systems ist, bleibt „Grounding“ lediglich ein Gefühl – keine wirkliche Sicherheit.

Deshalb wird ein Teil des „Groundings“ außerhalb des Modells erzwungen – in drei Schichten:

  1. Keine Quellen, kein Modellaufruf. Falls die Suche keine Ergebnisse liefert, sendet das Tool niemals eine Anfrage an das LLM als Ersatz. Stattdessen beendet es den Prozess mit Exit-Code 3 – einem Signal, das jedes aufrufende Programm ohnehin prüft.
  2. Quellen, die keine Antwort liefern. Der Prompt weist das Modell an, dies explizit zu erwähnen; in diesem Fall gilt der Durchlauf dennoch als erfolgreich. Eine ehrliche Aussage wie „Nicht in diesen Quellen enthalten“ ist das gewünschte Verhalten des Systems.
  3. Antwort ohne Zitate. Das Tool gibt eine Warnung aus, dass die Antwort als nicht „gegroundet“ zu betrachten ist. Mit der Option --strict beendet es den Prozess stattdessen mit Exit-Code 4.

Darüber hinaus werden die Agenten, die das Tool aufrufen, angewiesen, einen fehlgeschlagenen Abruf zu melden – statt selbst eine Antwort zu erfinden. Eine Verweigerung wird somit weitergeleitet; niemand auf der darüberliegenden Ebene kann sie vertuschen.

Das Ergebnis: Ein Assistent, der ehrlich zugibt, etwas nicht gefunden zu haben. Auf einer Liste von „Schwächen“ wirkt das wie ein Nachteil – doch genau das Gegenteil ist der Fall. Ein Modell, das sagt: „Ich konnte es nicht finden“, ist wertvoller als ein größeres Modell, das sich Dinge ausdenkt. Denn auf ersterem kann man aufbauen; bei letzterem muss man jede Antwort faktengeprüft werden. Wenn man bei jeder Antwort Faktenchecks durchführen muss, hat man im Grunde keinen Zeitgewinn erzielt.

Datenschutz, den man selbst überprüfen kann

Jeder große Assistent verfügt über eine Datenschutzerklärung. Bei diesem Tool gibt es stattdessen einen rein lokalen Netzwerkpfad: Die Anfrage gelangt vom Terminal zum Suchserver auf demselben Rechner, anschließend zum Modell in meinem Heimnetz – und zurück. Niemand auf diesem Weg kann die Abfrage protokollieren; kein Schlüssel identifiziert mich, und es gibt auch keine vertraglichen Bedingungen, die sich künftig ändern könnten. Eine hier gestellte Frage ist genauso privat wie das Nachschlagen in einem Buch im Regal – denn im Grunde passiert genau das.

Niemand muss mir das glauben: Sie können es selbst überprüfen, indem Sie die Internetverbindung trennen und beobachten, dass das Tool weiterhin funktioniert.

Die unspektakulären 90 Prozent

Die Implementierung war ein angenehmes Wochenendprojekt – doch der schwierigste Teil waren drei spezifische Container-Parameter.

Der Wikipedia-Server läuft als rootloses Podman-Container auf einem Linux-Rechner mit SELinux. Jede dieser drei Voraussetzungen kostete mich einen ganzen Abend. Dies ist der funktionierende Befehl:

podman run -d --name infoforge-kiwix \
  --user root \
  -p 127.0.0.1:8080:8080 \
  -v "$HOME/zims:/data:z" \
  ghcr.io/kiwix/kiwix-serve \
  -k /data/wikipedia_en_all_nopic.zim
  • --user root. Bei rootlosem Podman wird der Root-Zugriff im Container auf Ihren eigenen, unprivilegierten Benutzer abgebildet. Der Standardbenutzer des Images landet in einem Sub-UID-Bereich, kann nicht auf Ihr Home-Verzeichnis zugreifen und erhält bei /data eine „Permission denied“-Fehlermeldung.
  • :z beim Volume. Auf einem SELinux-System muss der Bind-Mount neu gelabelt werden; andernfalls verweigert das Kernel den Lesezugriff – selbst für den Container-Root. Der Fehler wirkt wie ein fehlendes Datei-Problem, was einen in die völlig falsche Richtung führt.
  • Explizite ZIM-Pfade (plus -k). Ohne Angabe der Datei startet das Startskript des Images kiwix-serve ohne jegliche ZIM-Datei – mit dem Fehler „Arguments did not match expected patterns“. Das Flag -k (--skipInvalid) erlaubt es dem Server, auch dann zu starten, wenn eine Datei noch heruntergeladen wird.

Auf einem Docker-Host ohne SELinux oder rootlose Benutzerverwaltung benötigen Sie vermutlich nichts davon. Die Bindung an 127.0.0.1 ist eine Änderung in Version 2; die erste Version hörte auf dem gesamten LAN zu – was für einen Wissensserver ohne Authentifizierung unnötig ist.

Drei Parameter beanspruchten etwa 90 Prozent der Entwicklungszeit. So sieht die Realität bei fast allen Selbst-Hosting-Projekten aus – doch genau diese Phase wird in den meisten Beschreibungen verschwiegen. Deswegen glauben viele, sie seien darin schlecht – dabei machen sie es einfach zum ersten Mal alleine, vor sich die gleichen drei Parameter.

Dann fiel es aus – und niemand bemerkte es

Es funktionierte einwandfrei; war schnell. Ich testete es, notierte die Ergebnisse – und widmete mich anderen Dingen.

Eine Woche später wollte ich es erneut nutzen – doch es war verschwunden. Irgendwann hatte sich der Rechner neu gestartet; der Container war nicht wieder hochgefahren. Niemand informierte mich, weil es weder eine Service-Einheit noch Monitoring oder Health-Checks gab. Schlimmer noch: Die „Skill-Datei“, die meinen KI-Agenten mitteilen sollte, dass das Tool existiert, war lediglich als Entwurf vorhanden – und nie installiert worden. Ganze sieben Tage lang antworteten alle Agenten im Haus aus dem Gedächtnis, obwohl sie hätten suchen können – ohne zu wissen, dass es eine Alternative gab.

Die Lektion ist kurz:

Eine Funktion, die weder automatisch startet noch von irgendjemandem bekannt ist, unterscheidet sich in nichts von einer Funktion, die man nie implementiert hat.

Die Lösung bestand aus einem 12-zeiligen User-Service (Kommentare hier gekürzt) sowie einer einseitigen Skill-Datei:

[Unit]
Description=InfoForge kiwix-serve (Offline-Wissensbasis für „gegroundete“ Antworten)
After=default.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=%h/.local/bin/infoforge serve start
ExecStop=%h/.local/bin/infoforge serve stop
ExecReload=%h/.local/bin/infoforge serve recreate
TimeoutStartSec=180

[Install]
WantedBy=default.target

„oneshot“ in Kombination mit „RemainAfterExit=yes“ ist beabsichtigt: serve start meldet sofort, dass der Container hochgefahren ist – doch das Service sollte solange als „aktiv“ gelten, wie der Container läuft; daher kann man es per systemctl --user stop auch wieder beenden. Aktivieren lässt es sich mit systemctl --user enable --now infoforge.service. Da serve start idempotent ist, reicht ein Reload aus, um den Container bei Änderungen im ZIM-Ordner neu zu erstellen.

Die Skill-Datei ist eine gemeinsame Information, die meine Agenten lesen, um zu wissen, was sie dürfen. Sie enthält drei Punkte: Das Tool existiert, hier ist der Befehl – und eine „gegroundete“ Antwort muss ihre Quellen angeben.

Der gewünschte Health-Check heißt mittlerweile infoforge doctor. Er prüft nacheinander Konfiguration, ZIM-Ordner, Container, HTTP-Verbindung, Testsuche sowie jeden Modell-Endpunkt und meldet für jede Stufe „PASS“ oder „FAIL“ (Ausgabe gekürzt):

$ infoforge doctor
  [PASS] config          parsed <config path>
  [PASS] zims            1 enabled: wikipedia_en_all_nopic.zim
  [PASS] container       infoforge-kiwix: running, serving wikipedia_en_all_nopic.zim
  [PASS] kiwix http      http://127.0.0.1:8080 responds
  [PASS] search          3 hit(s) for 'water' in wikipedia_en_all_nopic
  [PASS] llm primary     <GPU-Server>/v1 reachable, model ...DeepSeek-R1-0528-Qwen3-8B... (model listed)

doctor: all checks passed

Die erste Version bestand aus einem Python-Skript mit etwa 700 Zeilen – und war die „gute Geschichte“. Erst der Service sowie die Skill-Datei machten das Tool wirklich nutzbar; daran erinnere ich mich immer wieder.

In den Agenten-Stack integriert

InfoForge ist nun ein gemeinsames Werkzeug für die lokalen Agenten, keine bloße Skriptdatei, die man sich merken muss. Ein Agent, der Fakten benötigt, ruft infoforge ask auf (oder --json für eine maschinenlesbare Antwort), erhält eine Antwort mit Zitaten – und leitet beides weiter. Die Zitate sind wichtiger, als es scheint: Wenn ein Agent den Artikeltitel nennt, kann ich ihn per Klick überprüfen; diese Überprüfbarkeit macht einen glaubwürdigen Assistenten erst nutzbar.

Fallstricke

  • Genügend Festplattenspeicher vor dem Download. Die „Bilder-freie“ Version ist ca. 53 GB groß; die Variante mit Bildern doppelt so viel. Prüfen Sie den freien Speicherplatz – ein halb heruntergeladener ZIM-File ist keine gute Lektion dafür.
  • Das Dump hat ein Datum. Mein Exemplar stammt vom Juni 2026; Wikipedia wird ja weiterentwickelt. Für dieses System existieren alles, was danach hinzukam, nicht – was in Ordnung ist, solange man es im Kopf behält; ansonsten eine Falle.
  • Die Suchqualität hängt von Ihrer Schlüsselwort-Extraktion ab. In der ersten Version beantwortete das Tool „Wer schrieb Kokoro und wann erschien es?“ mit „Natsume Sōseki, 1914“ – inklusive Artikelzitat. Bei v2 (16.09.2026) landete der Titel bei einem Album namens KoKoro; der Roman kam nicht unter die Top-5. Das Modell reagierte korrekt: Es listete alle „Kokoros“ auf und fragte nach, welches ich meinte. Bei „Wer schrieb den Roman Kokoro?“ antwortete es, dass die Quellen keine Antwort enthielten. Keine Halluzination – aber auch keine Antwort. Fast alle schlechten Antworten resultieren aus schlechten Abfragen, nicht aus einem schlechten Modell; verbessern Sie also zuerst die Suche, bevor Sie ein größeres Modell wählen.
  • Das Kürzen des Kontexts ist eine bewusste Entscheidung. Zu wenig Kontext – und die Antwort fehlt; zu viel – und das Modell weicht von der Anweisung ab. Optimieren Sie es anhand echter Fragen, nicht künstlicher Testfälle.
  • Testen Sie absichtlich den Fehlerpfad. Fragen Sie nach etwas, wozu Wikipedia keinen Artikel hat – und prüfen Sie, ob Exit-Code 3 kommt statt eines flüssigen Absatzes. Wer nur funktionierende Fragen testet, hat nur die „leichte“ Hälfte abgedeckt.
  • Erstellen Sie den Service am ersten Tag. Siehe oben.

Was das für mich bedeutet

Mein Haus verfügt nun über eine offline verfügbare Enzyklopädie mit Suchindex – und über eine KI, die nur aus diesen Quellen antworten darf. Der Aufwand bestand lediglich aus einem Download und einem Wochenende. Das System funktioniert auch bei Ausfall der Internetverbindung; es kann nicht mehr abgeschaltet werden – und es gibt keinerlei Geschäftsmodell, das mich betrifft.

Nächstes Ziel: Weitere ZIM-Dateien in dieselbe Struktur einzubinden (medizinische und technische Sammlungen von Kiwix sowie ein paar eigene Wikis); der Suchlayer ist ja unabhängig vom Inhalt. Version 2 bietet bereits den Befehl zimify, um Ordner mit Dokumenten in ZIM-Dateien zu konvertieren. Der andere Punkt ist der oben beschriebene „Kokoro-Fehler“ – ein Problem bei der Titelzuordnung, kein Modellproblem.

Verwandt: mein lokaler KI-Agenten-Stack, StudioForge (der GPU-Server, auf dem das Modell läuft), der Mini-PC, der InfoForge hostet sowie was die Agenten tatsächlich kosten (InfoForge selbst ist kostenlos).

Downloads

Kostenlos für die private Nutzung. Wenn es dir einen Nachmittag erspart, ist der Kaffee-Button gleich in der Nähe.


← Mehr KI & lokale LLMs