Vision-Language-Modelle für OCR lokal: Rechnungen und Scans auslesen

Belege lokal auslesen statt an einen externen KI-Dienst schicken? WZ-IT baut die Auslesestrecke mit offenen Modellen und Prüfregeln auf Ihrer Infrastruktur, siehe KI-Dokumentenverarbeitung im KI-Hub. Termin vereinbaren

Seit 2025 ist eine neue Gruppe offener Modelle erschienen, die Dokumentseiten als Bild lesen und als Text, Markdown oder JSON ausgeben: olmOCR, PaddleOCR-VL, GLM-OCR, DeepSeek-OCR, LightOnOCR und allgemeine Vision-Language-Modelle wie Qwen3.8. Fast alle laufen auf einer einzelnen GPU, viele stehen unter Apache 2.0 oder MIT. Für Rechnungen, Lieferscheine und gescannte Briefe ist das eine echte Alternative zu Cloud-Diensten, bei der kein Beleg das eigene Netz verlassen muss.

Dieser Beitrag vergleicht die Modelle aus Betreibersicht: was sie leisten, unter welcher Lizenz sie stehen, wie die Benchmark-Werte auf den Modellkarten zu lesen sind, welche Hardware sie brauchen und wie sich das Risiko erfundener Zahlen begrenzen lässt. Den Gesamtprozess mit E-Rechnung, Prüfregeln, Freigabe und GoBD behandelt der Beitrag Dokumente automatisch auslesen und prüfen. Alle Angaben haben den Stand September 2026.

Inhaltsverzeichnis

1. Drei Werkzeugklassen: OCR, OCR-VLM, allgemeines VLM
2. Offene Modelle im Überblick, Stand September 2026
3. Lizenzen: nicht jedes Modell ist kommerziell nutzbar
4. Benchmarks richtig lesen
5. Das Zahlenproblem: plausibel ist nicht gelesen
6. Pipeline-Muster für Rechnungen und Scans
7. Hardware: 24 GB, 96 GB oder AI Cube
8. Deutsche Belege: Sprache, Zahlenformat, Vorlagenqualität
9. Unser Vorgehen bei WZ-IT
10. Weiterführende Guides

Drei Werkzeugklassen: OCR, OCR-VLM, allgemeines VLM

Klassisches OCR liest Zeichen, versteht aber keine Struktur. Für ein Feld wie „Rechnungsnummer" braucht es danach Regeln oder Vorlagen. OCR-VLMs sind kleine Modelle, meist zwischen 0,3 und 8 Mrd. Parametern, die darauf trainiert sind, eine Seite vollständig und in Leserichtung zu transkribieren, inklusive Tabellen. Allgemeine VLMs sind große multimodale Sprachmodelle, die Bild und Anweisung verarbeiten. Sie können gezielt Felder extrahieren, sind aber langsamer und anfälliger dafür, Lücken mit Plausiblem zu füllen.

Docling gehört in keine der drei Klassen, sondern verbindet sie: Das MIT-lizenzierte Projekt der LF AI & Data Foundation erkennt Layout, Leserichtung und Tabellenstruktur, bindet klassisches OCR für Scans ein und kann wahlweise ein VLM wie granite-docling verwenden (docling --pipeline vlm). Aktuell ist Version 2.131.0 vom 29. September 2026 (Docling Releases).

Offene Modelle im Überblick, Stand September 2026

Einordnung der Kandidaten:

• Qwen3.8-27B ist kein OCR-Spezialmodell, sondern ein allgemeines Sprachmodell mit Bildverständnis. Die Modellkarte nennt ausdrücklich Dokumente als Einsatzbereich, eine Kontextlänge von 262.144 Token und einen Denkmodus, der pro Anfrage abschaltbar ist. Für die Extraktion einzelner Felder ist das Abschalten sinnvoll, weil lange Denkketten die Antwortzeit verlängern. Eine FP8-Variante stellt Qwen selbst bereit (Qwen3.8-27B-FP8).
• olmOCR 2 ist auf die Umwandlung ganzer PDF-Seiten in Text ausgelegt und wird über das olmOCR-Toolkit mit vLLM betrieben, das Seiten rendert, dreht und bei Fehlern erneut verarbeitet. Allen AI empfiehlt die FP8-Variante für den Betrieb (Modellkarte). Das Training belohnt bestandene Unit-Tests auf Dokumenten (olmOCR 2, arXiv 2510.19817).
• PaddleOCR-VL-1.6 ist zur Version 1.5 architekturgleich und damit ohne Anpassung austauschbar. Die erste Version nannte 109 unterstützte Sprachen (PaddleOCR-VL), Version 1.5 ergänzte Stempel- und Siegelerkennung (PaddleOCR-VL-1.5).
• GLM-OCR kombiniert eine Layout-Analyse (PP-DocLayout-V3) mit paralleler Erkennung und unterstützt neben der Transkription eine Informationsextraktion, bei der der Prompt ein JSON-Schema vorgibt. Es läuft unter vLLM, SGLang und Ollama.
• LightOnOCR-2-1B listet Deutsch ausdrücklich unter den unterstützten Sprachen und wird direkt mit vllm serve betrieben.
• granite-docling-258M ist das kleinste Modell der Liste und für die Docling-Pipeline gebaut. Die Modellkarte nennt Englisch als Sprache.

Lizenzen: nicht jedes Modell ist kommerziell nutzbar

Auf Hugging Face stehen weitere OCR-Modelle mit guten Benchmark-Werten, deren Lizenz den Betrieb im Unternehmen ausschließt oder offenlässt. Zwei Beispiele:

Drei Regeln für die Prüfung:

1. Modelllizenz und Code-Lizenz trennen. Bei Chandra ist der Code Apache 2.0, die Gewichte nicht. Entscheidend für den Betrieb sind die Gewichte.
2. Basismodell prüfen. Ein Fine-Tune erbt die Bedingungen seines Basismodells. olmOCR 2 baut auf Qwen2.5-VL-7B auf, das unter Apache 2.0 steht. Bei der 3B-Variante desselben Basismodells wäre das nicht so.
3. Pipeline-Bestandteile einzeln prüfen. Docling selbst ist MIT, für die eingebundenen Modelle gelten deren eigene Lizenzen, wie das Projekt ausdrücklich festhält.

Eine ausführliche Einordnung der Lizenzmodelle offener Sprachmodelle bietet der Artikel LLM-Lizenzen für die kommerzielle Nutzung. Das ist eine technische Einordnung, keine Rechtsberatung.

Benchmarks richtig lesen

Jede Modellkarte nennt Bestwerte. Die Zahlen stammen von den Herstellern selbst und beziehen sich auf unterschiedliche Benchmarks und Versionen.

Quellen: Modellkarten von PaddleOCR-VL-1.6, GLM-OCR, PaddleOCR-VL-1.5, Qwen3.8-27B, Chandra OCR 2 und olmOCR 2.

Was die Tabelle nicht zeigt:

• Versionen sind nicht vergleichbar. OmniDocBench wurde im April 2026 auf v1.6 aktualisiert, mit 296 zusätzlichen, schwierigeren Seiten und einem neuen Abgleichverfahren, kurz danach auf v1.7. Ein Wert aus v1.5 und einer aus v1.6 messen nicht dasselbe.
• Der Gesamtwert enthält Formeln. Der Overall-Wert von OmniDocBench ist der Mittelwert aus Textgenauigkeit, Tabellenstruktur (TEDS) und Formelerkennung (CDM). Für Rechnungen sind Formeln bedeutungslos, für wissenschaftliche Artikel zentral.
• Die Dokumente sind nicht Ihre. OmniDocBench umfasst in der Basisversion 1.651 Seiten aus zehn Dokumenttypen wie Fachartikeln, Finanzberichten, Zeitungen und Lehrbüchern, mit englischen, chinesischen und gemischten Seiten. olmOCR-Bench testet unter anderem arXiv-Artikel, alte Scans, Tabellen und Kopf- und Fußzeilen. Deutsche Lieferscheine mit Stempel, Durchschlag und Kugelschreiber-Notiz sind in beiden nicht gezielt vertreten.
• Gemessen wird Transkription, nicht Extraktion. Beide Benchmarks bewerten, ob die Seite richtig in Text umgewandelt wird. Ob ein Modell aus diesem Text die richtige Rechnungsnummer und den richtigen Bruttobetrag zuordnet, ist eine zweite Frage.

Die Benchmarks helfen bei der Vorauswahl. Die Entscheidung fällt an einer Stichprobe eigener Belege, feldgenau ausgewertet.

Das Zahlenproblem: plausibel ist nicht gelesen

Klassisches OCR macht sichtbare Fehler: Aus „8" wird „B", eine Tabellenzeile zerfällt. Ein VLM macht unsichtbare Fehler. Es erzeugt Text wie ein Sprachmodell, und wo die Vorlage unleserlich ist, entsteht ein Wert, der zum Kontext passt.

Zwei Untersuchungen belegen das:

Für Rechnungen ist das der kritische Punkt. Eine IBAN, eine Rechnungsnummer oder ein Betrag hat keinen sprachlichen Zusammenhang, aus dem sich die richtige Ziffer erschließen ließe. Genau dort ist ein plausibler Wert am gefährlichsten.

Gegenmaßnahmen im Überblick:

Die Prüfregeln im Detail, inklusive VIES, eVatR und IBAN, beschreibt der Beitrag Dokumente automatisch auslesen und prüfen. Wichtig ist hier nur der Grundsatz: Das Modell liefert Kandidaten, die Regeln entscheiden.

Pipeline-Muster für Rechnungen und Scans

Vor jedem Modell steht eine Weiche: Was kommt überhaupt als Bild an?

Für den dritten Fall haben sich drei Muster etabliert:

Muster A: Transkription, dann Extraktion. Ein kleines OCR-VLM (PaddleOCR-VL, GLM-OCR, olmOCR) wandelt die Seite in Markdown mit Tabellen. Ein Sprachmodell extrahiert daraus die Felder als JSON. Vorteil: Die Transkription ist nachvollziehbar und archivierbar, die beiden Schritte lassen sich getrennt testen. Nachteil: zwei Modelle im Betrieb.

Muster B: Direkte Extraktion. Ein allgemeines VLM wie Qwen3.8-27B erhält das Seitenbild und ein JSON-Schema und liefert die Felder direkt. Vorteil: ein Modell, Zugriff auf die visuelle Anordnung, etwa welcher Betrag in der Summenzeile steht. Nachteil: größeres Modell, keine Zwischenstufe, an der sich ein Fehler zuordnen lässt.

Muster C: Docling-Pipeline mit Extraktion. Docling übernimmt Layout, Tabellen und OCR, ein Sprachmodell oder VLM extrahiert aus dem strukturierten Dokument. Das passt, wenn neben Belegen auch Verträge, Handbücher oder Berichte verarbeitet werden, etwa für eine RAG-Anwendung.

In allen drei Mustern folgen danach dieselben Prüfregeln und dieselbe Freigabe. Welches Muster passt, hängt von der Belegmenge, der Vorlagenqualität und der vorhandenen Hardware ab und wird im Test mit eigenen Belegen entschieden, nicht am Benchmark.

Hardware: 24 GB, 96 GB oder AI Cube

Für den Grafikspeicher zählen zuerst die Modellgewichte: Parameterzahl mal Byte pro Parameter, also 2 Byte in BF16, 1 Byte in FP8 und etwa 0,5 Byte bei 4-Bit-Quantisierung. Dazu kommen KV-Cache, Bild-Token und Laufzeit-Overhead. Die folgenden Werte sind diese Rechnung für die Gewichte, keine Messung.

Daraus ergeben sich zwei typische Aufteilungen. Ein OCR-VLM um 1 Mrd. Parameter läuft auf einer 24-GB-GPU mit viel Reserve für parallele Seiten, und ein mittelgroßes Sprachmodell für die Extraktion kann daneben laufen. Wer Qwen3.8-27B ohne starke Quantisierung für die direkte Extraktion einsetzen will, braucht 96 GB oder den AI Cube. Wie sich Quantisierung auf Qualität und Speicher auswirkt, erklärt der Artikel zur LLM-Quantisierung, die Rechnung inklusive KV-Cache steht in der VRAM-Dimensionierung.

Bei WZ-IT gibt es dafür zwei Betriebswege. Der Managed GPU Server läuft in einem deutschen Rechenzentrum, als GPU Server 24 mit NVIDIA RTX PRO 4000 Blackwell (24 GB GDDR7 ECC) ab 699 € netto/Monat oder als GPU Server 96 mit RTX PRO 6000 Blackwell Max-Q (96 GB GDDR7 ECC) für 1.799 € netto/Monat, jeweils zuzüglich Einrichtung. Der AI Cube steht als Appliance im eigenen Netz, kostet 6.490 € netto plus AI Cube Care für 349,90 € netto/Monat und eignet sich, wenn Belege das Gebäude nicht verlassen sollen. Für die Wahl der Inferenz-Software hilft der Vergleich vLLM, Ollama oder llama.cpp.

Deutsche Belege: Sprache, Zahlenformat, Vorlagenqualität

Die Sprachangaben auf den Modellkarten unterscheiden sich deutlich:

Eine fehlende Sprachangabe heißt nicht, dass ein Modell kein Deutsch liest; lateinische Schrift mit Umlauten wird von vielen Modellen erkannt. Sie heißt, dass der Hersteller es nicht zusagt und es im Test geprüft werden muss.

Drei Eigenheiten deutscher Belege gehören in jede Teststichprobe:

• Zahlenformat. 1.234,56 statt 1,234.56. Ein Modell, das überwiegend englische Dokumente gesehen hat, kann Tausender- und Dezimaltrenner vertauschen. Die Normalisierung gehört in den Code nach dem Modell, und die Rechenregel deckt verbliebene Fehler auf.
• Umlaute und ß in Firmennamen und Anschriften, die für den Abgleich mit dem Lieferantenstamm exakt stimmen müssen.
• Vorlagenqualität. Faxe, Durchschläge, schräg fotografierte Lieferscheine, Stempel über dem Betrag. Genau hier steigt das Risiko plausibler statt gelesener Werte. PaddleOCR-VL-1.5 wurde ausdrücklich für Schräglage, Verzerrung, Bildschirmfotos und ungünstige Beleuchtung weiterentwickelt, ein eigener Test ersetzt das nicht.

Handschrift bleibt der schwierigste Fall. Einige Modellkarten werben damit, belastbare Werte für deutsche Handschrift auf Belegen liefert keiner der genannten Benchmarks.

Unser Vorgehen bei WZ-IT

1. Stichprobe festlegen. Ein Belegtyp, 50 bis 100 repräsentative Belege einschließlich schlechter Scans, je Beleg die richtigen Werte als Referenz.
2. Weiche bauen. E-Rechnungen und digitale PDF mit Textebene getrennt behandeln, nur Bilder und Scans gehen an ein Modell.
3. Zwei bis drei Kandidaten testen. Zum Beispiel ein OCR-VLM mit nachgelagerter Extraktion gegen ein allgemeines VLM mit direkter Extraktion, Lizenz vorab geprüft, auf der Zielhardware.
4. Feldgenau auswerten. Je Feld der Anteil korrekter Werte, dazu der Anteil der Belege ohne jede Korrektur. Erfundene Werte werden gesondert gezählt.
5. Prüfregeln und Freigabe. Strukturierte Ausgabe, Rechenregeln, Prüfziffern, zweiter Leseweg, Stammdatenabgleich, Freigabe für alles, was eine Regel nicht besteht.
6. Betrieb. Modellversion festhalten, Regressionstest mit der Stichprobe vor jedem Modellwechsel, Support, Beratung und Implementierung durch WZ-IT.

Der Dokumentenverarbeitung Pilot umfasst eine Dokumentklasse mit bis zu 20 Zielfeldern und beginnt ab 17.900 € netto. Ist noch offen, welcher Prozess zuerst automatisiert werden soll, ordnet der KI-Prozesscheck Belegarten und Mengen ein. Den Betrieb von Ollama und vLLM übernimmt WZ-IT auch einzeln, siehe Ollama und vLLM.

Weiterführende Guides

• Dokumente automatisch auslesen und prüfen mit KI, der Gesamtprozess mit E-Rechnung, Prüfregeln, Freigabe und GoBD.
• Dokumente mit KI verarbeiten: von OCR zu IDP, die Grundlagen intelligenter Dokumentenverarbeitung.
• E-Mails und Tickets lokal mit KI klassifizieren, der Schritt davor: Eingänge sortieren, bevor Belege ausgelesen werden.
• Spracherkennung lokal und DSGVO-konform, dieselbe Frage für Audio statt Bild.
• Welches LLM selbst hosten, Auswahl offener Sprachmodelle für die Extraktion.
• Paperless-ngx auf Ubuntu installieren, das Archiv für ausgelesene Belege.
• KI-Lösungen von WZ-IT, der Hub mit allen Angeboten zu lokaler KI.

Welches Modell liest Ihre Belege am zuverlässigsten? Wir testen Kandidaten mit einer Stichprobe Ihrer Belege auf Ihrer Hardware und werten feldgenau aus, bevor eine Strecke gebaut wird. Termin vereinbaren

Quellen

• Qwen3.8-27B, Modellkarte
• Qwen3.8-27B-FP8, Modellkarte
• olmOCR-2-7B-1025, Modellkarte
• olmOCR-2-7B-1025-FP8, Modellkarte
• olmOCR-Toolkit auf GitHub
• olmOCR, Projektseite von Allen AI
• olmOCR 2: Unit Test Rewards for Document OCR, arXiv 2510.19817
• olmOCR-Bench, Datensatz
• PaddleOCR-VL-1.6, Modellkarte
• PaddleOCR-VL-1.5, Modellkarte
• PaddleOCR-VL, Modellkarte der ersten Version
• PaddleOCR auf GitHub
• GLM-OCR, Modellkarte
• GLM-OCR in der Ollama-Bibliothek
• LightOnOCR-2-1B, Modellkarte
• DeepSeek-OCR-2, Modellkarte
• granite-docling-258M, Modellkarte
• Docling auf GitHub
• Docling Releases
• Chandra OCR 2, Modellkarte
• Chandra OCR 2, Lizenztext
• Nanonets-OCR2-3B, Modellkarte
• Qwen2.5-VL-3B-Instruct, Qwen Research License
• OmniDocBench auf GitHub
• Seeing is Believing? Mitigating OCR Hallucinations in Multimodal Large Language Models, arXiv 2506.20168
• Visual Merit or Linguistic Crutch? A Close Look at DeepSeek-OCR, arXiv 2601.03714
• vLLM, Structured Outputs
• Ollama, Structured Outputs
• Tesseract, trainierte Modelle tessdata_best
• OCRmyPDF auf GitHub