Was ist Qianfan-OCR?
Qianfan-OCR ist ein Dokumentmodell des Qianfan-Teams bei Baidu, veröffentlicht im März 2026 unter Apache 2.0 mit einem technischen Bericht vom 11. März. Es kombiniert Baidus Vision-Encoder Qianfan-ViT mit einem Sprachmodell Qwen3-4B, insgesamt 4,74 Milliarden Parameter, und wandelt ein Seitenbild direkt in Markdown um, ohne separates Layoutmodell. Dieselben Gewichte übernehmen Tabellen- und Formelerkennung, die Extraktion von Schlüsselinformationen, Fragen zu Diagrammen und Dokumenten sowie OCR in 192 Sprachen.
Sein besonderes Merkmal ist Layout-as-Thought. Mit eingeschaltetem Thinking schreibt das Modell zuerst Bounding Boxes, Elementtypen aus 25 Kategorien und die Lesereihenfolge aus und dann den endgültigen Text. So liefert ein einziges Modell Layoutdaten, die Pipeline-Systeme von einem Detektor bekommen.
Es ist eine eigene Linie neben Baidus PaddleOCR-VL und Unlimited-OCR, die von anderen Baidu-Teams stammen. Auf Hugging Face kam es im vergangenen Monat auf 34.433 Downloads und 1.217 Likes.
Lohnt sich Qianfan-OCR?
Qianfan-OCR tauscht Genauigkeit beim Parsen von Seiten gegen Vielseitigkeit, und die unabhängigen Zahlen zeigen den Tausch deutlich. Die Rangliste OmniDocBench v1.6 von OpenDataLab führt es mit 93,90, hinter GLM-OCR mit 95,22 und OvisOCR2 mit 96,47, die beide weniger als ein Drittel so groß sind. Baidus Schlagzeile von 93,12 und Platz eins unter den End-to-End-Modellen bezieht sich auf das ältere v1.5, wo auch Baidus eigene Tabelle das Pipeline-Modell PaddleOCR-VL 1.5 mit 94,50 vorn zeigt.
Vorn liegt es bei der Arbeit, die auf das Parsen folgt. Baidu meldet einen Mittelwert von 87,9 über fünf Benchmarks zur Extraktion von Schlüsselinformationen, gegenüber 84,2 für Qwen3-VL-235B-A22B und 79,2 für Gemini-3.1-Pro, und 85,2 bei den Reasoning-Fragen von CharXiv, wo Qwen3-VL-4B auf 48,5 kommt. Es erreicht 880 auf OCRBench und deckt 192 Sprachen ab, gegenüber 109 für PaddleOCR-VL-1.6 und acht für GLM-OCR. Alle diese Werte sind selbst gemeldet, wobei die Vergleichsmodelle Allzweckmodelle sind und nicht auf Dokumente abgestimmt.
Layout-as-Thought ist nützlich, aber kein Gewinn zum Nulltarif. Baidus eigene Zahlen zeigen, dass der Thinking-Modus den Gesamtwert auf OmniDocBench v1.5 von 93,12 auf 92,64 senkt, und die Empfehlung lautet, ihn nur für gemischte Seiten wie Prüfungsbögen und Zeitungen einzuschalten. Sein Wert liegt darin, Boxen und Lesereihenfolge ohne Detektor zu bekommen, nicht in besserem Text.
Die Größe ist der Hauptpreis. Mit 4,74 Milliarden Parametern erreicht es auf einer A100 nur mit W8A8-Quantisierung 1,024 Seiten pro Sekunde und bei voller Präzision 0,503, während MinerU 2.5 in derselben Tabelle 1,057 schafft. Baidus Abschnitt zu den Einschränkungen sagt, dass der Platzbedarf Edge-Geräte und reine CPU-Server ausschließt, und nennt Video, gekrümmten Text und stilisierte Handschrift als Schwachstellen.
Unser Fazit: Qianfan-OCR verdient seinen Platz, wenn die Ausgabe in eine Entscheidung einfließt, etwa beim Lesen einer Rechnungssumme oder eines Diagrammtrends, statt in ein Archiv. Teams, die nur sauberes Markdown brauchen, bekommen von GLM-OCR oder PaddleOCR-VL-1.6 mehr Genauigkeit pro GPU.
Wo es sich lohnt
Ein Team in der Kreditorenbuchhaltung eines multinationalen Konzerns, das Rechnungen in einem Dutzend Sprachen erhält
Lieferant, Summe und Steuerfelder ohne separaten OCR-Schritt aus Rechnungen extrahieren
Frag die Felder auf einem vLLM-Server direkt aus dem Seitenbild ab. Baidu meldet 86,5 F1 auf Nanonets KIE; die Abdeckung von 192 Sprachen zählt hier mehr als der Markdown-Wert.
Das Datenteam eines Aktienanalysten, das Broker-Berichte verarbeitet
Diagrammwerte und Trends lesen, die reines Text-OCR verwirft
Stelle Fragen zu Diagrammen anhand des Seitenbilds. Baidu merkt an, dass Systeme aus OCR und anschließendem LLM auf CharXiv 0,0 erreichen, weil die Diagrammstruktur verloren geht; Qianfan-OCR meldet bei den beschreibenden Fragen 94,0.
Ein Engineer für Dokument-KI, der einen Stack aus Layoutdetektor und Erkenner ablöst
Bounding Boxes, Elementtypen und Lesereihenfolge aus einem Modell bekommen
Schalte Thinking bei gemischten Seiten wie Prüfungsbögen ein, um zuerst die Layoutausgabe zu bekommen, und lass es bei einspaltigen Dokumenten aus, wo die Ergebnisse laut Baidu ohne Thinking besser und schneller sind.
Bevor du dich festlegst
- Einrichtung
- baidu/Qianfan-OCR mit AutoModelForImageTextToText aus Transformers in BF16 laden, oder vllm serve mit --trust-remote-code und einem Flag hf-overrides ausführen, das es auf die Architektur InternVLChatModel abbildet.
- Integrationen
- Transformers und vLLM; Community-Builds in GGUF für llama.cpp und MLX für Apple Silicon; die Plattform Qianfan von Baidu AI Cloud; ein Agent Skill in Baidus Skills-Repository.
- Daten und Datenschutz
- Apache 2.0, einige mitgelieferte Quelldateien unter MIT. Selbst gehostet bleiben Dokumente auf deiner Hardware; die Aufbewahrungsbedingungen der Plattform Qianfan stehen nicht in der Model Card.
- Kosten im großen Maßstab
- Der BF16-Checkpoint ist etwa 9,5 GB groß. Baidu meldet auf einer A100 1,024 Seiten pro Sekunde mit W8A8 und 0,503 mit W16A16, rund 3.700 und 1.800 Seiten pro Stunde und Karte.
- Grenzen
- Visuelle Eingabe bis 4.096 Tokens pro Bild in Kacheln zu 448 Pixeln; standardmäßig 32K Kontext. Layout-as-Thought ist nur für das Parsen auf OmniDocBench v1.5 geprüft, nicht für Extraktion oder Fragen; zu groß für Edge-Geräte oder reine CPU-Server.
Was gut ist
- Mittelwert von 87,9 über fünf Benchmarks zur Extraktion von Schlüsselinformationen (selbst gemeldet)
- Fragen zu Diagrammen und Dokumenten im selben Modell
- Optionale Layoutausgabe mit 25 Elementtypen, ohne separaten Detektor
- OCR in 192 Sprachen; Apache 2.0
Was nicht
- 93,90 auf OmniDocBench v1.6, hinter viel kleineren Parsern
- 4,74B Parameter; etwa 1 Seite pro Sekunde auf einer A100 nur mit Quantisierung
- Thinking-Modus senkt den Gesamtwert beim Parsen
- vLLM braucht eine Überschreibung der Architektur; gehosteter Preis nicht veröffentlicht
Am besten für
Teams, die Feldextraktion, das Lesen von Diagrammen und mehrsprachiges OCR aus einem selbst gehosteten Modell brauchen und eine Rechenzentrums-GPU erübrigen können.
Alternativen zu Qianfan-OCR
Qianfan-OCR: häufige Fragen
- Lohnt sich Qianfan-OCR?
- Qianfan-OCR ist das Modell der Wahl, wenn eine Seite in einem Aufruf gelesen und verstanden werden muss; für die einfache Umwandlung in Markdown sind kleinere Parser genauer. Wir bewerten es mit 4.0 von 5.
- Was kostet Qianfan-OCR?
- Kostenlos unter Apache 2.0. Auch auf der Plattform Qianfan von Baidu AI Cloud angeboten; der gehostete Preis steht nicht in der Model Card.
- Welche Nachteile hat Qianfan-OCR?
- 93,90 auf OmniDocBench v1.6, hinter viel kleineren Parsern; 4,74B Parameter; etwa 1 Seite pro Sekunde auf einer A100 nur mit Quantisierung; Thinking-Modus senkt den Gesamtwert beim Parsen; vLLM braucht eine Überschreibung der Architektur; gehosteter Preis nicht veröffentlicht.
- Für wen eignet sich Qianfan-OCR?
- Teams, die Feldextraktion, das Lesen von Diagrammen und mehrsprachiges OCR aus einem selbst gehosteten Modell brauchen und eine Rechenzentrums-GPU erübrigen können.
- Was kostet Qianfan-OCR für ein Team oder im Produktivbetrieb?
- Der BF16-Checkpoint ist etwa 9,5 GB groß. Baidu meldet auf einer A100 1,024 Seiten pro Sekunde mit W8A8 und 0,503 mit W16A16, rund 3.700 und 1.800 Seiten pro Stunde und Karte.
- Ist Qianfan-OCR sicher für Firmendaten?
- Apache 2.0, einige mitgelieferte Quelldateien unter MIT. Selbst gehostet bleiben Dokumente auf deiner Hardware; die Aufbewahrungsbedingungen der Plattform Qianfan stehen nicht in der Model Card.
- Was sind die besten Alternativen zu Qianfan-OCR?
- Die nächsten Alternativen, die wir getestet haben, sind GLM-OCR, PaddleOCR-VL-1.6, Unlimited-OCR 2 und Infinity-Parser2-Flash.
Antworten geprüft am 2. Nov. 2026.
Du entwickelst Qianfan-OCR? Zeig diese Bewertung auf deiner Website
