Hallo Zusammen, ich nutze Paperless schon eine ganze mit meinen 4.000 Dokumenten und immer alls schön händisch gepflegt. Paperless-AI läuft seit diesem Kurs auch super und ich möchte die Kombi aus Paperless-GPT (für OCR) und Paperless-AI für den Rest haben.
Funktioniert bisher leider nur semi gut. Ich erhalte immer wieder eine Fehlermeldung aus Paperless-GPT: GGML_ASSERT(a->ne[2] * 4 == b->ne[0]) failed
Einige Seiten werden verarbeitet, andere nicht. Es macht keinen Unterschied ob 1,2,3 oder 10 Seiten sind. Ob ich die Seiten selbst gescannt habe oder es ein Dokument direkt von einem Anbieter ist. Ganz viele Seiten werden einfach nicht verarbeitet und GPT hängt in einer Endlosschleife.
Mein Setup:
Paperless-NGX auf Synology 918+ mit 12 GB RAM
Paperless-AI und Paperless-GPT auf Mac Mini M4 mit 16 GB RAM
Ollama als Provider (0.16.2) und bereits diverse Vision Modelle ausprobiert → alles dasselbe. (aktuell: qwen2.5-vl:3b)
Hat jemand dasselbe Problem, welches er bereits gelöst hat oder weiß wie man es löst?
Hier noch ein Beispiel Logauszug.
time="2026-02-17T16:53:00Z" level=error msg="Failed to get response from vision model" error="an error was encountered while running the model: GGML_ASSERT(a->ne[2] * 4 == b->ne[0]) failed\nWARNING: Using native backtrace. Set GGML_BACKTRACE_LLDB for more info.\nWARNING: GGML_BACKTRACE_LLDB may cause native MacOS Terminal.app to crash.\nSee: https://github.com/ggml-org/llama.cpp/pull/17869" model="qwen2.5vl:3b" page=2 provider=ollama
time="2026-02-17T16:53:00Z" level=error msg="OCR processing failed: error performing OCR for document 4588, page 2: error getting response from LLM: an error was encountered while running the model: GGML_ASSERT(a->ne[2] * 4 == b->ne[0]) failed\nWARNING: Using native backtrace. Set GGML_BACKTRACE_LLDB for more info.\nWARNING: GGML_BACKTRACE_LLDB may cause native MacOS Terminal.app to crash.\nSee: https://github.com/ggml-org/llama.cpp/pull/17869" document_id=4588
time="2026-02-17T16:53:00Z" level=info msg="Processing document for OCR" document_id=4590
time="2026-02-17T16:53:00Z" level=info msg="Starting OCR processing" document_id=4590
time="2026-02-17T16:53:01Z" level=info msg="Document 4590 page 1: final image dimensions 4959x7017, size 1500460 bytes, DPI 600"
time="2026-02-17T16:53:01Z" level=info msg="Document 4590 page 0: final image dimensions 4959x7017, size 1559484 bytes, DPI 600"
time="2026-02-17T16:53:01Z" level=info msg="Using binary image format" model="qwen2.5vl:3b" page=1 provider=ollama
time="2026-02-17T16:55:01Z" level=info msg="Successfully processed image" CompletionTokens=1423 PromptTokens=2730 ThinkingContent= ThinkingTokens=0 TotalTokens=4153 content_length=2883 model="qwen2.5vl:3b" page=1 provider=ollama
time="2026-02-17T16:55:02Z" level=info msg="Using binary image format" model="qwen2.5vl:3b" page=2 provider=ollama
Korrekt. Ich habe bereits paperless-ai und das funktioniert auch sauber. Aber bei der OCR ist das eben nicht so gut.
Ja ich habe große Modell und ganz kleine Modell probiert. Immer das selbe weil es laut Gemini nicht am Modell liegt. Die Lösung habe ich aber noch nicht gefunden
Mein Ablauf:
Dokument hochladen
Es bekommt den Tag „ocr“
Vision Modell von Paperless-GPT macht das ocr für Inhalt und entfernt „ocr“ und vergibt Tag „ocr complete“
Paperless-ai startet sobald er den Tag „ocr-complete“ findet und füllt Titel, Korrespondent, usw aus und vergibt Tag „fertiggestellt“
dann kann ich es nochmals prüfen ob alles korrekt ist.
Bei bestimmt 2/3 der Dokumente tritt aber eben der Fehler auf und die Dokument hängen in einer Schleife fest, weil das ocr nicht klappt und somit der Tag „ocr-complete“ nicht vergeben wird.
Dieser Fehler ist auch bei unseren internen Tests unseres KI-OCR-Prototypen hin und wieder aufgetreten. Höchstwahrscheinlich liegt es an einzelnen Seiten selbst und zwar an der Größe (langer Kassenzettel, sehr hohe Auflösung etc.).
Kann das sein? Ich habe das Problem in den Griff bekommen, indem lange Seiten gesplittet wurden.
ich hatte anfangs genau dasselbe Problem. Die Ursache liegt meist an der Konfiguration von Paperless-GPT. Dort sind oft zwei unterschiedliche LLMs hinterlegt (z. B. eines für die Bildanalyse und eines für den Chat/Text), was Ollama zum ständigen „LLM-Swapping“ zwingt.
Ollama muss also zwischen dem Modell von „Paperless-AI“ (z. B. Qwen für Vision) und dem Hauptmodell von „Paperless-GPT“ hin- und herwechseln. Qwen allein belegt auf dem Mac Mini schon ca. 4 GB. Wenn dann durch die Config noch ein zweites, anderes LLM geladen werden muss, entsteht ein massiver Flaschenhals. Dein Mac muss die vektorsierten Bilddaten und die Modelle ständig aus dem RAM rein- und rausschieben. Das dauert zu lange, und Ollama bricht mit einem Server-500-Fehler ab.
Lösungsansatz: Überprüfe deine env-Datei bzw. die Config von Paperless-GPT:
Einheitliches Modell nutzen: Versuche, für beide Aufgaben (Vision/AI und Chat) dasselbe Modell in der Config einzutragen. Wenn nur ein Modell im Speicher bleiben muss, entfällt das Swapping.
Kleinere Modelle: Falls du zwei verschiedene brauchst, wechsle auf kleinere, stärker quantisierte Modelle (z. B. 7B-Modelle oder q4_k_m Varianten), damit beide gleichzeitig in den Arbeitsspeicher passen.
Tokeneinstellung anpassen: weniger Daten auf einmal schicken
Hier sind noch ein paar wichtige Punkte, die in deinem Post noch nicht geklärt sind (auch wenn der Videokurs von Stefan sicherlich top ist):
1. Die Hardware-Frage Worauf laufen die „KI-Container“ eigentlich – Synology oder Mac? Das ist entscheidend, denn je nach System musst du die „Arbeit“ der KI noch ordentlich in den verfügbaren freien Arbeitsspeicher (RAM) einpreisen.
2. Der Ressourcen-Hunger (Beispiel: Paperless-GPT) Um zu verstehen, warum das so viel Leistung zieht, hier mal der komplette Ablauf am Beispiel des Komplettpakets Paperless-GPT (inkl. geändertem Archivdokument):
PDF öffnen: Das Dokument wird geladen.
OCR-Vorbereitung (Tesseract): Auslesen der Koordinaten der einzelnen Wörter mittels „Textboxen“.
Bild-Konvertierung: Umwandlung des PDFs in ein hochauflösendes Bild inkl. Anpassung von Helligkeit, Kontrast, Auflösung etc. (Hinweis: Bisher kenne ich nur Mistral OCR und Google Document AI, die PDFs direkt verarbeiten können – beide laufen aber nicht lokal).
Segmentierung: Aufteilung des Bildes in Ausschnitte für das Vision-Modell (z. B. Qwen). Die Größe und Anzahl der Abschnitte variiert je nach Seite.
KI-Verarbeitung: Abschicken der einzelnen Bildabschnitte an Ollama bzw. Qwen.
Wartezeit (Timeout-Gefahr!): Hier läuft Paperless-GPT oft in ein Timeout, da Ollama auf schwächerer Hardware länger braucht als erwartet.
Rückgabe: Qwen liest die Textdaten aus den Bildabschnitten und gibt diese über Ollama an Paperless-GPT zurück.
Neuaufbau des Archiv-PDFs: Das ursprüngliche Tesseract-OCR wird koordinatengetreu durch den KI-Text ersetzt und das alte Archiv-PDF ausgetauscht.
Metadaten: Zuweisen von Tags, Korrespondenten, Titeln etc.
Wichtig: Für die OCR-Verarbeitung benötigst du lokal zwingend ein Vision-Modell.
Fazit zur Performance Wie oben zu sehen, reserviert sich Paperless-GPT für diesen Workflow einen ordentlichen Anteil am RAM. Und da reden wir noch gar nicht davon, dass Paperless-AI (oft mit einem anderen LLM) eventuell auch noch dazwischenfunkt.
Das Problem ist der Hohe DPI Wert.
Ich gehe mal davon aus das Du die Standardwerte in Paperless so gelassen hast, oder sogar erhöht.
Hierzu muss man wissen das eine PDF mit zwei DPI Werten arbeitet. Erster Wert wäre der max. Bild DPI Wert… der sollte die 200 DPI für eine Archivierung nicht übersteigen, bietet auch eine ausreichende Qualität.
Dann der Max DPI Wert für das gesamte PDF. den würde ich wenn es nicht absolut notwendig ist auf max. 300 DPI begrenzen.
Wenn Du nun einen Thermobon mit sagen wir mal in Farbe mit 600 DPI einscannst, kollidiert das mit den Vorgaben in Paperless.
Ich gehe jetzt nicht davon aus das Du Bedienungsanleitungen und solche Dinge mit einer eventuell höheren Qualität in Paperless hinterlegt hast / es willst.
Passe Deine Scans entsprechend der Notwendigkeit an und dann sollte das weg sein.
So war es bei mir
