Zurück zum Blog

Optimaler PDF-zu-Markdown-Workflow in Open WebUI

Alle acht Extraction Engines von Open WebUI im direkten Vergleich — von pypdf bis Marker und Mistral OCR. Mit konkreten Konfigurationen für die RTX 3090, GPU-Tuning-Tipps für Docling und MinerU sowie dem zweistufigen Workflow für maximale Markdown-Qualität.

• stagl • 5 Min. Lesezeit
LLM AI Self-Hosting

Die höchste Extraktionsqualität für gemischte PDFs in Open WebUI erreicht man mit Marker (LLM-Modus) oder Docling (GPU) als Extraction Engine — kombiniert mit dem „Full Document”-Toggle, der den gesamten Text ungechunkt an ein Modell mit großem Kontextfenster sendet.

Open WebUI unterstützt seit Version 0.6.x acht verschiedene Extraction Engines, die sich in Qualität, Geschwindigkeit und Infrastruktur-Anforderungen drastisch unterscheiden. Für eine RTX 3090 mit 24 GB VRAM stehen mit Docling und MinerU zwei leistungstarke GPU-beschleunigte Self-Hosting-Optionen zur Verfügung. Wer API-Zugang akzeptiert, erzielt mit DataLab Marker (Gemini-unterstützt) oder Mistral OCR aktuell die besten Ergebnisse.

Der entscheidende zweite Schritt ist die korrekte Konfiguration von Open WebUI, damit der extrahierte Markdown-Text vollständig im Kontextfenster landet — nicht als zerstückelte RAG-Chunks.

Die acht Extraction Engines im direkten Vergleich

Open WebUI (v0.6.x, Stand Anfang 2026) bietet über die Umgebungsvariable CONTENT_EXTRACTION_ENGINE acht Backends. Die Konfiguration erfolgt wahlweise per ENV-Variable oder im Admin Panel → Settings → Documents.

EngineTypMarkdown-OutputScanned PDFsTabellenFormelnGeschwindigkeit
Default (pypdf)Lokal, built-in❌ Plain text❌ Versagt❌ Keine Struktur❌ Nein⚡ Schnell
TikaSelf-hosted Container❌ Plain text⚠️ Basic (Tesseract)❌ Keine Struktur❌ Nein⚡ Sehr schnell
DoclingSelf-hosted, GPU✅ Strukturiert✅ Multi-Engine OCR✅ TableFormer (93.6%)⚠️ Schwach🐢 Langsam
MinerUSelf-hosted, GPU✅ Strukturiert✅ 109 Sprachen✅ HTML-Tabellen✅ UniMERNet LaTeX⚡ Schnellste GPU
Marker (DataLab)Cloud API✅ Exzellent✅ Surya OCR✅ Exzellent mit LLM✅ Gut mit LLM⚡ Schnell
Mistral OCRCloud API✅ Exzellent✅ 25+ Sprachen✅ HTML/Markdown✅ Exzellent (LaTeX)⚡ 2000 S./min
Azure Doc IntelligenceCloud API✅ Gut✅ Stark✅ Stark⚠️ Begrenzt⚠️ Moderat
ExternalCustom APIVariabelVariabelVariabelVariabelVariabel

Die Community-Konsens-Rangliste für Markdown-Qualität lautet: Marker (mit LLM) ≈ Mistral OCR 3 > Docling (GPU) > MinerU > Tika > Default.

Ein Entwickler, der Marker in Open WebUI integrierte, berichtet: „Marker ist der leistungsfähigste Open-Source-PDF-Parser auf dem Markt. Er schlägt sogar Mistral OCR in meinen Tests.” Mistral OCR bietet laut User-Berichten „signifikant bessere Ergebnisse als Apache Tika, besonders bei Dokumenten mit komplexen Layouts wie Tabellen und mehrspaltigem wissenschaftlichem Text.”

Docling auf der RTX 3090 optimal konfigurieren

Docling ist die beste voll lokale Option für strukturierten Markdown-Output. Die Architektur besteht aus Layout-Analyse (DocLayNet), OCR, TableFormer für Tabellen und einem Code/Formel-Modell — alles GPU-beschleunigbar.

Docker-Compose für RTX 3090:

services:
  docling-serve:
    image: quay.io/docling-project/docling-serve-cu128:latest
    container_name: docling-serve
    ports:
      - "5001:5001"
    environment:
      - DOCLING_SERVE_ENABLE_UI=true
      - DOCLING_SERVE_ENABLE_REMOTE_SERVICES=true
      - DOCLING_SERVE_MAX_SYNC_WAIT=600
      - UVICORN_WORKERS=1   # Zwingend 1, sonst "Task Not Found"-Fehler
      - OMP_NUM_THREADS=4
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

In Open WebUI: CONTENT_EXTRACTION_ENGINE=docling und DOCLING_SERVER_URL=http://docling-serve:5001. Die DOCLING_PARAMS steuern das Verhalten granular:

{
  "do_ocr": true,
  "force_full_page_ocr": true,
  "pdf_backend": "dlparse_v4",
  "table_mode": "accurate",
  "ocr_engine": "easyocr",
  "ocr_lang": ["eng", "deu"]
}

GPU-Speedups auf der RTX 3090 sind erheblich:

  • Layout-Analyse: 14× Beschleunigung gegenüber CPU
  • OCR: 8× Beschleunigung
  • Tabellenstruktur: 4,3× Beschleunigung

Die Batch-Sizes sollten auf der RTX 3090 auf 32–64 erhöht werden (Standard ist nur 4). Für volle GPU-Nutzung muss bei manchen Images onnxruntime durch onnxruntime-gpu ersetzt werden — ein bekanntes Problem, das sich per Custom-Dockerfile lösen lässt.

Beim OCR-Backend gilt:

  • EasyOCR — schnellste GPU-Option
  • RapidOCR mit Torch-Backend — neuer Default seit Docling v2.56
  • Tesseract — höchste Genauigkeit, läuft aber nur auf CPU

Für gescannte PDFs auf Deutsch empfiehlt sich EasyOCR mit force_full_page_ocr=true, damit auch gemischte PDFs komplett durch OCR laufen.

Eine spannende Alternative ist die VLM-Pipeline mit Granite-Docling-258M — ein winziges 258M-Parameter-Modell, das Layout-Analyse, OCR, Tabellenerkennung und Formelerkennung in einem Durchgang erledigt. Per vLLM auf der RTX 3090 gehostet, lässt es massiv VRAM-Headroom und erreicht 2–3 Seiten/Sekunde.

MinerU und Marker als starke Alternativen

MinerU

MinerU (54k GitHub Stars, AGPL-3.0) ist nativ in Open WebUI integriert (CONTENT_EXTRACTION_ENGINE=mineru). Version 2.5 bringt einen Hybrid-Backend, das VLM und klassische Pipeline kombiniert: Text-basierte PDFs werden direkt extrahiert (weniger Halluzinationen), gescannte PDFs durchlaufen OCR in 109 Sprachen.

Auf GPU ist MinerU mit 0,21 Sekunden pro Seite die schnellste Engine — doppelt so schnell wie Docling (0,49 s/Seite). Der VRAM-Bedarf liegt bei 8–25 GB; die RTX 3090 reicht komfortabel. MinerU glänzt besonders bei akademischen Papern, LaTeX-Formeln (via UniMERNet) und komplexen Layouts.

Einschränkung: In Open WebUI werden nur PDFs unterstützt — keine Office-Dokumente.

Marker

Marker (31k GitHub Stars, GPL-3.0) ist über CONTENT_EXTRACTION_ENGINE=datalab_marker angebunden und benötigt einen DataLab-API-Key. Der entscheidende Qualitätssprung kommt durch den use_llm-Modus: Marker nutzt dann Gemini 2.0 Flash als Backend, um Tabellen seitenübergreifend zusammenzuführen, Inline-Mathematik korrekt zu formatieren und OCR-Fehler zu korrigieren.

In Markers eigenen Benchmarks erreicht er einen Heuristic Score von 95,67 gegenüber Doclings 86,71. Marker unterstützt die breiteste Formatpalette (PDF, DOCX, PPTX, XLSX, HTML, EPUB, Bilder) und verbraucht nur 3–5 GB VRAM pro Worker — auf der RTX 3090 können 4–5 parallele Worker laufen.

Für Self-Hosting kann marker_server --port 8001 lokal gestartet werden, allerdings verlangt Open WebUI aktuell einen API-Key zum Speichern der Einstellungen (GitHub Issue #18617). Als Workaround dient die external-Engine, die auf den lokalen Marker-Endpunkt zeigt.

Mistral OCR und Azure als API-Optionen

Mistral OCR 3

Mistral OCR 3 (Dezember 2025, Modell mistral-ocr-2512) ist ein spezialisiertes VLM für Dokumentenparsing — nicht identisch mit Pixtral. Die Kosten: 2 $ pro 1.000 Seiten (1 $ im Batch-Modus). In Open WebUI: CONTENT_EXTRACTION_ENGINE=mistral_ocr plus MISTRAL_OCR_API_KEY.

Mistral OCR liefert exzellenten Markdown mit LaTeX-Formeln, HTML-Tabellen und extrahierten Bildern. In Mistrals eigenen Benchmarks erreicht es 96,6 % bei Tabellen (vs. AWS Textract 84,8 %) und 88,9 % bei Handschrift (vs. Azure 78,2 %).

Einschränkung: Cloud-only, keine Textformatierung (Fett/Kursiv) wird erhalten. Bei größeren PDFs wurden in Open WebUI gelegentlich unvollständige Extraktionen berichtet.

Azure Document Intelligence

Azure Document Intelligence bleibt der „sichere Standard” für Formulare und gedruckte Geschäftsdokumente. Konfiguration: CONTENT_EXTRACTION_ENGINE=document_intelligence plus Azure-Endpoint und Key. Preislich bei 1,50 $/1.000 Seiten für Basic-OCR wettbewerbsfähig, aber bis zu 30 $/1.000 Seiten für Custom Extraction deutlich teurer.

Vision-Modell-Ansatz als mächtiger Alternativweg

Statt einer dedizierten Extraction Engine kann jede PDF-Seite als Bild an ein Vision-Modell gesendet werden. Dieser Ansatz versteht Kontext, Layout und Zusammenhänge — nicht nur Pixel.

Top-Modelle für Dokument-OCR:

  • Qwen2.5-VL-72B/32B (128K Kontext) — Spitzenreiter auf OCRBench_v2 und DocVQA. Die 7B-Variante läuft komfortabel auf der RTX 3090, die 32B-Version quantisiert.
  • Gemini 2.5 Flash (1M+ Kontext) — Kann dutzende Seiten in einem Durchgang verarbeiten. Wird von Marker als LLM-Backend genutzt.
  • MiniCPM-o 2.6 (8B) — Schlägt GPT-4o auf OCRBench, extrem effizient mit 640 Tokens pro 1,8MP-Bild.
  • Spezialisierte OCR-Modelle — OlmOCR-2 (7B), dots.ocr (3B, 100+ Sprachen), DeepSeek-OCR (3B, 97 % bei 10× Kompression), GOT-OCR 2.0.

In Open WebUI lässt sich dies über mehrere Wege umsetzen. Die Community-Function „Multimodal Reasoning Pipe V1” implementiert genau diesen Workflow: Ein Vision-Modell (z. B. Gemma 3 12B) extrahiert OCR-Text aus Bildern, der dann an ein Reasoning-Modell weitergereicht wird. Alternativ können PDF-Seiten manuell als Bilder exportiert und direkt in den Chat mit einem Vision-Modell hochgeladen werden.

Der optimale zweistufige Workflow

Ein Zwei-Stufen-Ansatz liefert nachweislich bessere Ergebnisse als jede Einzelmethode. Markers Entwickler bestätigt: „use_llm-Modus bietet höhere Genauigkeit als Marker oder Gemini allein.”

Der optimale Workflow für die RTX 3090:

Stufe 1 — Strukturierte Extraktion

Docling (lokal, GPU) oder Marker (API mit use_llm) extrahiert Layout, Tabellen, Formeln und Lesereihenfolge als strukturierten Markdown. Docling bietet mit force_full_page_ocr=true und table_mode=accurate die zuverlässigste lokale Extraktion. MinerU 2.5 im Hybrid-Modus ist die schnellste Alternative.

Stufe 2 — VLM-Korrektur und -Optimierung

Der extrahierte Markdown wird zusammen mit den Originalseiten als Bilder an ein starkes VLM gesendet (z. B. Qwen2.5-VL-7B lokal oder Gemini 2.5 Flash via API), das OCR-Fehler korrigiert, fehlende Inhalte ergänzt und die Formatierung verfeinert. In Open WebUI lässt sich dies über die „Multimodal Reasoning Pipe”-Function oder eine Custom-Pipeline realisieren.

Für den pragmatischsten Weg ohne mehrstufigen Aufbau: DataLab Marker mit use_llm=true als Open WebUI Extraction Engine vereint beide Stufen bereits intern — Markers Layout-Analyse plus Gemini Flash für OCR-Korrektur.

Volltext statt RAG-Chunks im Kontext nutzen

Open WebUI chunked standardmäßig jeden Upload, erstellt Embeddings und führt Vektor-Retrieval durch. Für die Nutzung des vollen Dokumenttexts gibt es drei Methoden:

Methode 1 — Per-File-Toggle (empfohlen)

Beim Upload einer Datei in den Chat erscheint auf dem Datei-Attachment ein Toggle. Von „Focused Retrieval” auf „Full Document” umschalten. Dies sendet den gesamten extrahierten Text an das Modell — pro Datei steuerbar, ohne globale Einstellungen zu ändern.

Methode 2 — Globale Einstellung

Unter Admin Panel → Settings → Documents die Option „Bypass Embedding and Retrieval” aktivieren. Dokumente werden dann weder geembeddet noch gechunkt, sondern der volle Text wird direkt übergeben.

Achtung: Dies gilt global für alle Uploads inklusive Knowledge Bases.

Methode 3 — Große Chunk-Size als Workaround

Chunk Size auf z. B. 1.000.000 setzen, sodass de facto ein einziger „Chunk” pro Dokument entsteht. Die RAG-Infrastruktur bleibt erhalten, aber der Effekt ist quasi identisch zu Methode 2.

Kritisch wichtig ist die Konfiguration der Kontextlänge: Ollamas Default liegt bei nur 2.048 Tokens — viel zu wenig für ganze Dokumente. Dies muss unter Admin Panel → Models → Settings → Advanced Parameters angepasst werden:

ModellMax. KontextEmpfehlung
Qwen2.5 (7B–72B)128K Tokens✅ Bestes lokales Modell für Volltext
Gemma 3 (12B/27B)128K Tokens✅ Gute lokale Alternative
Gemini 2.5 Flash (API)1M+ Tokens✅ Ideal für sehr große Dokumente
Claude 3.5/4 (API)200K Tokens✅ Exzellente Analyse
GPT-4o (API)128K Tokens✅ Solide Baseline

Empfehlung: Ollama-Kontextlänge auf mindestens 32.768, besser 65.536–131.072 setzen. Die Umgebungsvariable RAG_SYSTEM_CONTEXT=True platziert den Dokumenttext ins System-Prompt, was KV-Cache-Wiederverwendung bei Folgefragen ermöglicht.

Konkrete Empfehlung für die RTX 3090

Für maximale Markdown-Qualität auf einer RTX 3090 mit 24 GB VRAM empfehle ich folgenden Setup:

Primäre Extraction Engine: DataLab Marker mit use_llm=true

Setzt man CONTENT_EXTRACTION_ENGINE=datalab_marker und aktiviert den LLM-Modus, erhält man die aktuell höchste Markdown-Qualität direkt in Open WebUI. Dies erfordert einen kostenlosen DataLab-API-Key und nutzt Gemini Flash für OCR-Korrektur. Für datenschutzsensible Dokumente alternativ Docling mit GPU (docling-serve-cu128, EasyOCR, force_full_page_ocr=true, table_mode=accurate).

Kontextkonfiguration:

  • Per-File-Toggle auf „Full Document” umschalten
  • Ollama-Kontextlänge auf 131.072 setzen
  • RAG_SYSTEM_CONTEXT=True aktivieren
  • Als Chat-Modell: Qwen2.5-32B-Q4 (passt in 24 GB VRAM bei 128K Kontext) oder Gemini 2.5 Flash via API (1M Kontext für sehr große Dokumente)

Für Spezialfälle:

  • Wissenschaftliche Paper mit vielen Formeln → MinerU 2.5 Hybrid (beste LaTeX-Konvertierung)
  • Gescannte Dokumente auf Deutsch → Docling mit Tesseract (ocr_lang: ["deu"]) oder Mistral OCR
  • Sehr große Dokumente (500+ Seiten) → Gemini 2.5 Flash mit 1M-Token-Fenster

Zusammenfassung der Konfiguration

# Open WebUI ENV-Variablen
CONTENT_EXTRACTION_ENGINE=datalab_marker   # oder: docling, mineru, mistral_ocr
DATALAB_MARKER_API_KEY=your_key
DATALAB_MARKER_USE_LLM=true
RAG_SYSTEM_CONTEXT=True

# Für Docling stattdessen:
# DOCLING_SERVER_URL=http://docling-serve:5001
# DOCLING_PARAMS={"do_ocr":true,"force_full_page_ocr":true,"table_mode":"accurate","ocr_engine":"easyocr"}

# Für MinerU stattdessen:
# MINERU_API_BASE=http://mineru-server:8000
# MINERU_API_MODE=local

Die Wahl zwischen diesen Engines ist letztlich ein Dreieck aus Qualität (Marker LLM ≈ Mistral OCR > Docling > MinerU), Geschwindigkeit (MinerU > Marker > Tika > Docling) und Datenschutz (Docling = MinerU > External > Cloud APIs).

Für die allermeisten Anwendungsfälle liefert Marker mit LLM-Modus das beste Gesamtergebnis — und lässt sich in Open WebUI mit drei Umgebungsvariablen aktivieren.

Share: