Vision-Language-Modelle für Dokumenten-KI: GPUs für OCR, Rechnungen und Verträge On-Premise

Was ein Vision-Language-Modell für Dokumente von der GPU braucht

Welche GPU ein Vision-Language-Modell für die Dokumentenverarbeitung mit KI on-premise braucht, hängt von seinen Gewichten und von den Bild-Token jeder laufenden Seite ab. Ein Vision-Language-Modell (VLM) wandelt jedes Seitenbild mit einem Vision-Encoder in Bild-Token um, und sein Sprachmodell schreibt daraus den Text, das Markdown oder die Felder. Der GPU-Speicher hält deshalb die Gewichte einschließlich des Encoders sowie einen Cache für die Bild-Token und den erzeugten Text jeder laufenden Seite. Auf Dokumente spezialisierte OCR-Modelle mit 0,9B bis 8,3B Parametern passen auf eine Karte mit 24 GB wie die L4 oder die RTX PRO 4000. Allgemeine VLMs wie Qwen3.8-27B oder Gemma 4 31B brauchen eine RTX PRO 6000 mit 96 GB oder eine H200 NVL mit 141 GB, sobald viele Seiten gleichzeitig laufen.

Die Angaben zu den Modellen unten stammen aus den Model Cards und Dateien auf Hugging Face und aus der Dokumentation von vLLM, abgerufen am 10. Oktober 2026. Die Konfigurationen sind unsere Schätzungen, die Methode legen wir offen. Für reine Textmodelle zeigen unsere LLM-Hardware-Anforderungen je Modell dieselbe Rechnung.

Bild-Token je Seite, wie jedes Modell sie zählt

Was eine Seite kostet, hängt davon ab, wie viele Token der Encoder aus ihr macht, und jede Modellfamilie zählt anders.

Qwen3.8-27B, das Qwens Model Card als „ein natives Vision-Language-Modell, das Bilder und Videos versteht“ beschreibt, nutzt den Prozessor von Qwen3-VL. Seine preprocessor_config.json setzt eine Patch-Größe von 16 und eine Merge-Größe von 2, sodass ein Token einen Block von 32 × 32 Pixeln abdeckt. Dieselbe Datei erlaubt 65.536 bis 16.777.216 Pixel je Bild, also 64 bis 16.384 Token. Eine A4-Seite, mit 150 dpi gerendert (1.240 × 1.754 Pixel), kommt nach unserer Rechnung auf etwa 2.145 Token, mit 200 dpi auf etwa 3.796. Die Render-Auflösung, die Sie wählen, ist deshalb die zentrale Einstellung für die Kosten je Seite.

Gemma 4 nutzt stattdessen feste Budgets. Laut seiner Model Card sind die unterstützten Token-Budgets 70, 140, 280, 560 und 1120, und für Aufgaben wie OCR, Dokument-Parsing oder das Lesen kleiner Schrift empfiehlt sie höhere Budgets. DeepSeek-OCR-2 erzeugt 256 Token für eine Übersicht von 1.024 × 1.024 Pixeln plus 144 für jeden von bis zu sechs Ausschnitten von 768 × 768, also 256 bis 1.120 je Seite. olmOCR-2 rendert Seiten so, dass „die längste Kante 1288 Pixel beträgt“, und sein Prozessor von Qwen2.5-VL (Patch 14, Merge 2) macht aus einer A4-Seite nach unserer Rechnung etwa 1.500 Token.

Model Cards auf Hugging Face, preprocessor_config.json-Dateien und die safetensors-Parameterzahlen jedes Repositorys, abgerufen am 10. Oktober 2026; Gewichte aus den Parametern je Datentyp berechnet. Größen von Qwen3.8-27B und Gemma 4 wie in unseren Leitfäden zu Qwen und Gemma.

NVIDIAs Nemotron Nano 12B v2 VL, veröffentlicht am 28. Oktober 2025, ist ein allgemeines VLM, das Hugging Face mit 13B Parametern führt. Seine Model Card nennt 85,4 Prozent auf OCRBench für die FP8-Version und gibt die H100 SXM 80GB als getestete Hardware an. Mistrals Modellübersicht führt OCR 4.1 und OCR 3 als Premier-Modelle ohne offene Lizenz, deshalb lassen wir sie beim On-Premise-Sizing weg.

Vision-Encoder, Bild-Cache und laufende Seiten

Der Vision-Encoder gehört zu den Gewichten und ist klein im Vergleich zum Sprachmodell. Googles Model Card nennt etwa 550M Parameter für den Encoder von Gemma 4 31B und 26B A4B und etwa 150M für E2B und E4B.

vLLM plant Speicher für Bilder an drei Stellen. Seine Dokumentation, aktualisiert am 9. Oktober 2026, hält fest: „Die Größe des Encoder-Caches wird zur Laufzeit durch die tatsächlichen Eingaben bestimmt.“ limit_mm_per_prompt legt fest, wie viele Bilder oder Videos eine Anfrage enthalten darf, und bei einem Dienst nur für Bilder „muss kein Speicher für Videos reserviert werden“. Ein Prozessor-Cache im Hauptspeicher des Hosts, gesetzt mit mm_processor_cache_gb und standardmäßig 4 GiB groß, hält verarbeitete Eingaben; die vLLM-Rezepte für DeepSeek-OCR und Unlimited-OCR setzen ihn auf 0 und schalten Prefix Caching ab, was das Rezept für DeepSeek-OCR empfiehlt, „um unnötiges Hashing und Caching zu vermeiden“. Für Qwen2-VL-Modelle zeigt die Dokumentation eine Einstellung max_pixels in mm_processor_kwargs, die die Token je Bild begrenzt.

Der KV-Cache hält dann die Bild-Token und den erzeugten Text jeder laufenden Seite. Unser Qwen-Hardware-Leitfaden setzt Qwen3.8-27B mit 64 KiB je Token in 16 Bit plus festen 144 MiB je Sequenz an. Eine Seite mit 2.145 Bild-Token plus angenommenen 1.500 Ausgabe-Token, unserer Schätzung für eine dichte Textseite in Markdown, belegt etwa 0,36 GiB. Mit den FP8-Gewichten auf einer RTX PRO 6000 ist das Platz für etwa 150 laufende Seiten. Qwen3.8 arbeitet standardmäßig im Thinking-Modus; schalten Sie Thinking für die Transkription ab, sonst kommen die Reasoning-Token zu jeder Seite hinzu.

Gemma 4 31B hält in seinen Layern mit voller Attention 80 KiB je Token und in seinen Sliding-Window-Layern feste 0,78 GiB, wie unser Gemma-Hardware-Leitfaden darlegt. Eine Seite beim Budget von 1.120 Token mit derselben Ausgabe belegt etwa 1 GiB, deshalb fasst eine RTX PRO 6000 nach unserer Schätzung etwa 25 Seiten mit BF16-Gewichten und etwa 53 mit FP8-Gewichten, beide Male mit einem Cache in 16 Bit. Die kleinen OCR-Modelle brauchen weit weniger, und eine Karte mit 24 GB fasst ihre Gewichte mit Platz für viele Seiten.

Veröffentlichter Durchsatz in Seiten pro Sekunde

Nur wenige Modellautoren veröffentlichen Seiten pro Sekunde, und keiner der Werte, die wir gefunden haben, nennt eine Karte, die wir liefern.

Die Model Card von Datalab für chandra-ocr-2 berichtet 1,44 Seiten pro Sekunde auf einer H100 80GB mit vLLM und 96 gleichzeitigen Sequenzen, mit Dokumenten aus dem Benchmark-Satz von olmOCR. Sie ergänzt eine Schätzung von etwa 2 Seiten pro Sekunde für typische Dokumente, da dieser Satz langsamer ist. Sie nennt weder die Version der H100, SXM oder PCIe, noch die vLLM-Version oder ein Datum der Messung. Die Model Card von Z.ai hält fest, dass GLM-OCR „einen Durchsatz von 1,86 Seiten/Sekunde für PDF-Dokumente und 0,67 Bildern/Sekunde für Bilder erreicht“, bei einer Nebenläufigkeit von eins, ohne die GPU zu nennen. Das Repository von DeepSeek führt etwa 2.500 Token pro Sekunde für das PDF-Skript von DeepSeek-OCR auf einer A100-40G.

Stand 10. Oktober 2026 haben wir für Qwen3.8-27B, Gemma 4 und Nemotron Parse 2.0 keinen veröffentlichten Wert in Seiten pro Sekunde gefunden. Messen Sie Ihre eigenen Dokumente in einem Pilotprojekt, bevor Sie mehr als einen Server auslegen.

GPUs für 1.000, 10.000 und 100.000 Seiten am Tag

Unsere Methode hat drei Schritte. Teilen Sie die Seiten pro Tag durch das Verarbeitungsfenster, 8 Stunden (28.800 Sekunden) oder 24 Stunden, um die Rate zu erhalten, die der Server halten muss. Skalieren Sie die 1,44 Seiten pro Sekunde von Datalab auf jede Karte mit dem kleineren von zwei Verhältnissen zur H100: der Speicherbandbreite, die das Schreiben des Textes begrenzt, und dem BF16-Durchsatz der Tensor Cores, der das Lesen der Bild-Token begrenzt. Datalab gibt nicht an, welche H100 80GB es verwendet hat, deshalb setzen wir die SXM-Version mit 3,35 TB/s und 1.979 BF16-TeraFLOPS mit Sparsity an, was die niedrigeren Schätzungen ergibt. Für ein 27B-VLM auf jeder Seite teilen wir das Ergebnis durch fünf, das Verhältnis der Parameter zu den 5,3B von chandra-ocr-2.

Nach dieser Methode schafft eine L4 mit einem 5B-OCR-Modell etwa 0,13 Seiten pro Sekunde und eine RTX PRO 6000 Server Edition etwa 0,69, beide begrenzt durch die Speicherbandbreite. Die RTX PRO 5000 und die H200 NVL sind durch die Rechenleistung begrenzt. NVIDIA nennt für die H200 NVL 1.671 BF16-TeraFLOPS mit Sparsity, weniger als die H100 SXM, deshalb kommt sie trotz ihrer 4,8 TB/s auf etwa 1,2 Seiten pro Sekunde und die RTX PRO 5000 auf etwa 0,38. Mit Qwen3.8-27B schafft eine RTX PRO 6000 etwa 0,14 Seiten pro Sekunde und eine H200 NVL etwa 0,24.

Unsere Schätzungen, keine Messungen: 1,44 Seiten pro Sekunde von chandra-ocr-2 auf einer H100 80GB (Model Card von Datalab, undatiert), skaliert mit dem kleineren der Verhältnisse von Speicherbandbreite und BF16-Rechenleistung zur H100 SXM, nach NVIDIAs Produktseiten und Datenblättern, abgerufen am 10. Oktober 2026; eine Kopie des Modells je Karte, RTX PRO 6000 Server Edition, DGX Spark (128 GB); planen Sie Reserve für Spitzen und erneute Verarbeitung ein.

Kleine OCR-Modelle skalieren als eine Kopie je Karte hinter einer Warteschlange, sodass zusätzliche Karten Durchsatz bringen, ohne ein Modell aufzuteilen. Ein DGX Spark (273 GB/s) eignet sich für einen Entwickler, der Modelle an Beispieldokumenten vergleicht, mit etwa 0,12 Seiten pro Sekunde bei einem 5B-Modell nach derselben Methode. Diese Schätzungen betreffen den Durchsatz und nicht die Genauigkeit, und ein Modell, das bei Rechnungen schnell ist, kann an Handschrift oder Tabellen scheitern; testen Sie also jeden Dokumenttyp.

Wir liefern diese Karten für Server, die Sie bereits betreiben, oder in nach Auftrag gebauten KI-Servern mit 2 bis 8 GPUs. Schicken Sie uns Ihre Seiten pro Tag, das Verarbeitungsfenster und die Dokumenttypen über das Formular unten, und Sie erhalten eine Konfiguration und ein Angebot.

Rechnungsextraktion und Verträge: erst OCR, dann Felder

Für die Extraktion von Rechnungsdaten arbeitet ein verbreitetes Design in zwei Stufen. Ein OCR-Modell wandelt jede Seite in Markdown oder Text mit Tabellen um, und ein Text-LLM extrahiert danach die Felder in ein festes Schema. vLLM unterstützt das mit Structured Outputs, bei denen mit der Option json „die Ausgabe dem JSON-Schema folgt“. Die OCR-Stufe trägt das Seitenvolumen auf kleinen Karten, und das Textmodell sieht statt des Bildes einige tausend Token je Rechnung.

Ein allgemeines VLM, das das Seitenbild liest und die Felder in einem Schritt zurückgibt, eignet sich für geringe Volumen und schwierige Layouts wie Stempel, Handschrift oder gescannte Formulare. Bei hohem Volumen kostet es nach unserer Methode oben etwa die fünffache Rechenleistung je Seite; geben Sie ihm deshalb nur die Seiten, die die OCR-Stufe nicht mit ausreichender Sicherheit verarbeiten kann.

Verträge umfassen viele Seiten, und die Fragen betreffen Klauseln auf verschiedenen Seiten. Wandeln Sie den ganzen Vertrag zuerst mit der OCR-Stufe um und geben Sie den Text dann an ein LLM mit langem Kontext, oder indexieren Sie ihn für Retrieval. Unser Artikel zu RAG auf Unternehmensdaten behandelt den Index.

Die Bereitstellung offener Modelle mit vLLM, mit Prozessautomatisierung darauf, gehört zu unserer Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO. Beschreiben Sie Ihre Dokumenttypen, Sprachen und die Felder, die Sie extrahieren im Formular unten. Das erste Gespräch ist kostenlos.

Lizenzen und Datenschutz für Dokumentmodelle

Die Lizenzbedingungen gehören zu jedem Checkpoint und unterscheiden sich je Modell. GLM-OCR und Unlimited-OCR sind unter MIT veröffentlicht. DeepSeek-OCR-2, olmOCR-2, Qwen3.8-27B und Gemma 4 stehen unter Apache 2.0. Nemotron Parse 2.0 steht unter dem OpenMDW License Agreement 1.1. Die Gewichte von chandra-ocr-2 nutzen eine modifizierte OpenRAIL-M-Lizenz, die die Nutzung ohne gesonderte Lizenz für „Forschung, persönliche Nutzung und Startups unter“ einer Finanzierungs- oder Umsatzschwelle erlaubt, die ihre Model Card nennt, und die Model Card ergänzt, sie „dürfen nicht im Wettbewerb mit unserer API genutzt werden“.

Llama 4 ist ein nativ multimodales Modell, dessen Acceptable Use Policy Unternehmen mit Hauptgeschäftssitz in der EU von den Rechten nach Abschnitt 1(a) für seine multimodalen Modelle ausnimmt, mit einer Ausnahme für Endnutzer. Unser Llama-4-Hardware-Leitfaden zitiert die Klausel. Ob eine Klausel Ihr Unternehmen betrifft, ist eine rechtliche Bewertung für Ihre Rechtsabteilung.

Rechnungen, Verträge und Personalakten enthalten in der Regel personenbezogene Daten, deshalb gilt für ihre Verarbeitung die DSGVO, wo auch immer das Modell läuft. Auf Ihren eigenen Servern bleiben die Seitenbilder und der extrahierte Text in Ihrem Netzwerk.

Was wir liefern

Wir liefern die GPUs für Dokumenten-KI über diese ganze Bandbreite, von der L4 und der RTX PRO 4000 für ein OCR-Modell in einem vorhandenen Server bis zur RTX PRO 6000 Server Edition und zur H200 NVL in nach Auftrag gebauten KI-Servern. Jede Karte kommt mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung, und wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Aus Ihren Seiten pro Tag und Dokumenttypen erstellen wir innerhalb eines Werktages eine Konfiguration und ein Angebot. Die Bereitstellung der Modelle On-Premise, mit RAG und MLOps darauf, ist unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ