Unlimited-OCR von Baidu: Langdokumente in einem Durchlauf parsen
Unbegrenzte OCR analysiert lange Dokumente und Bilder in einem Durchgang und erstellt strukturierten Text für Dokument- und KI-Workflows.
Auf einen Blick
- Was ist das?
- Ein Vision-Sprachmodell für Dokumentparsen unter MIT-Lizenz, das lange Dokumente und Bilder einmalig in strukturierten Text umwandelt und per Transformers, vLLM oder SGLang läuft.
- Für wen ist es gedacht?
- Unlimited-OCR passt zu Teams mit NVIDIA-GPUs, die lange Dokumente als strukturierten Text für Dokument- oder KI-Workflows brauchen und eine self-hosted Alternative zu Cloud-OCR suchen. Weniger geeignet ist es ohne GPU-Infrastruktur oder mit Anspruch auf Support-Verträge, denn das Projekt hat noch keine Releases.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 49 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
One-shot Long-horizon Parsing: welches Problem Unlimited-OCR löst
Klassische OCR-Pipelines zerlegen lange Dokumente in Einzelbilder, erkennen Textzeilen und setzen die Fragmente mühsam wieder zusammen. Das Modell baidu/Unlimited-OCR verfolgt laut README den Ansatz des One-shot Long-horizon Parsing: Lange Dokumente und Bilder werden in einem Durchlauf verarbeitet und als strukturierter Text für Dokument- und KI-Workflows ausgegeben. Das Projekt positioniert sich damit ausdrücklich als Weiterführung der Arbeit von DeepSeek-OCR, dessen Autoren im Acknowledgement-Abschnitt gedankt werden, gemeinsam mit DeepSeek-OCR-2 und PaddleOCR.
Hinter dem Modell steht ein wissenschaftlicher Beitrag: Die Arbeit Unlimited OCR Works ist auf arXiv unter der Nummer 2606.23050 dokumentiert, die Autorenliste führt Youyang Yin und Huanhuan Liu als erste Namen. Die Repository-Metadaten weisen rund 24.703 Sterne aus, der Code ist in Python geschrieben und steht unter der MIT-Lizenz. Die Gewichtung der Modellparameter ist auf Hugging Face unter der Kennung baidu/Unlimited-OCR verfügbar.
Ökosystem-Raser von Juni bis Juli 2026: arXiv, vLLM, ModelScope und Baidu Cloud
Die Release-Notizen im README zeigen ein Projekt mit hoher Anfangsgeschwindigkeit. Am 22. Juni 2026 erschien Unlimited-OCR als Vorstellung, einen Tag später folgten das arXiv-Papier und die Verfügbarkeit auf ModelScope unter PaddlePaddle/Unlimited-OCR. Am 24. Juni richtete die Community eine Demo auf Hugging Face Spaces ein, am 28. Juni meldete das Team vLLM-Unterstützung dank Beitrag aus der vLLM-Community.
Im Juli kamen zwei Vertriebs- und Trainingswege dazu. Seit dem 3. Juli 2026 ist das Modell laut README auf Baidu Cloud verfügbar, seit dem 21. Juli 2026 unterstützt die Trainingsumgebung ms-swift aus der ModelScope-Familie das Feintunen des Modells. Diese Sequenz zeigt, auf welchen drei Beinen der Betrieb steht: Rohinferenz mit Transformers, produktionsnahe Server über vLLM und SGLang sowie Feintuning über ms-swift. Eine GitHub-Releases-Liste mit getagten Versionen fehlt dagegen bis zur Materialaufnahme vollständig.
Inference mit Transformers: die gundam-Konfiguration gegen den base-Modus
Der einfachste Weg läuft über Huggingface Transformers auf NVIDIA-GPUs. Das README nennt als getestete Umgebung Python 3.12.3 mit CUDA 12.9 und pinnt die Abhängigkeiten exakt: torch==2.10.0, torchvision==0.25.0, transformers==4.57.1, pymupdf==1.27.2.2 und weitere Pakete. Das Modell wird mit AutoModel.from_pretrained(model_name, trust_remote_code=True, use_safetensors=True, torch_dtype=torch.bfloat16) geladen und mit model.eval().cuda() in den Auswertungsmodus gesetzt.
Für einzelne Bilder gibt es laut README zwei Konfigurationen. Der gundam-Modus arbeitet mit base_size=1024, image_size=640 und crop_mode=True, der base-Modus mit base_size=1024, image_size=1024 und crop_mode=False. Der Aufruf model.infer(tokenizer, prompt) nimmt dann einen Prompt mit Bildreferenz entgegen. Welche Konfiguration für welche Dokumentklasse besser passt, sagt das README nicht; hier bleibt nur der Vergleich beider Modi am eigenen Material.
Deployment über vLLM: Docker-Images unlimited-ocr und unlimited-ocr-cu129
Für den Serverbetrieb verweist das README auf ein Rezept unter recipes.vllm.ai/baidu/Unlimited-OCR und stellt zwei Docker-Images bereit. Das Standard-Image zieht man mit docker pull vllm/vllm-openai:unlimited-ocr und basiert auf CUDA 13.0. Für Hopper-GPUs gibt es das Tag vllm/vllm-openai:unlimited-ocr-cu129 mit CUDA 12.9. Die Aufteilung nach GPU-Generation zeigt, dass die Infrastruktur-Voraussetzungen ernst zu nehmen sind.
Das vLLM-Deployment stellt eine OpenAI-kompatible API bereit, an die sich Streaming-Anfragen richten. Damit lässt sich das Modell in bestehende LLM-Stacks einfügen, ohne eigenen Client-Code zu schreiben. Das README verzichtet allerdings auf Angaben zu Durchsatz, Latenz oder empfohlener GPU-Ausstattung für diesen Weg; solche Zahlen stehen allenfalls im vLLM-Rezept, nicht im Repository selbst.
SGLang-Server mit sglang.launch_server und Batch-Läufe über infer.py
Der dritte Betriebsweg nutzt SGLang mit einer uv-verwalteten Virtualenv: uv venv --python 3.12, dann Installation eines lokalen SGLang-Wheels und von pymupdf==1.27.2.2 für die PDF-zu-Bild-Wandlung. Der Server startet über python -m sglang.launch_server mit Flags wie --attention-backend fa3, --page-size 1, --mem-fraction-static 0.8, --context-length 32768 und lauscht auf --port 10000. Auffällig ist eine Inkonsistenz im README: Der Text bittet, kernels==0.9.0 zu pinnen, der Befehl daneben installiert kernels==0.11.7.
Für Serienverarbeitung startet infer.py laut README den SGLang-Server selbst und sendet parallele Anfragen, etwa python infer.py --image_dir ./examples/images --output_dir ./outputs --concurrency 8 --image_mode gundam oder mit --pdf für ein Dokument. Optionen wie --model_dir, --gpu und --server_log steuern Modellpfad, GPU-Auswahl und Protokollierung. Für die OmniDocBench-Bewertung beschreibt das README eine Nachbearbeitung, die Auszeichnungen der Form <|det|>Typ [bbox]<|/det|> aus der Rohausgabe filtert und Blöcke mit doppelten Zeilenumbrüchen trennt.
Grenzen ohne Releases und die Alternative PaddleOCR aus dem Acknowledgement
Zwei Einschränkungen fallen bei der Quellendurchsicht auf. Erstens existiert keine GitHub-Releases-Liste, es gibt also weder getagte Versionen noch Änderungsprotokolle; Versionierung heißt hier konkret, den Commit auf dem main-Zweig festzuhalten. Zweitens nennt das README keine Leistungswerte, keine Kompatibilitätsmatrix für GPUs und keine Aussagen zum Verhalten bei gescannten oder handschriftlichen Dokumenten, die über die OmniDocBench-Erwähnung hinausgehen. Die Abhängigkeit von exakt gepinnten Versionen wie transformers==4.57.1 verlangt zudem Disziplin beim Environment-Management.
Als konkrete Alternative bietet sich PaddleOCR an, das im Acknowledgement des Projekts selbst genannt wird. Es verfolgt den klassischen Segmentierungs- und Erkennungsansatz, läuft ressourcenschonender und auf breiterer Hardware, verlangt aber den Aufbau einer Pipeline um die Erkennung herum. Wer lange Dokumente in einem Durchlauf als strukturierten Text will und GPUs vorhält, kann Unlimited-OCR direkt einsetzen; wer auf CPUs oder Edge-Geräten arbeitet, fährt mit PaddleOCR realistischer.
Redaktionelles Fazit
Unlimited-OCR passt zu Teams mit NVIDIA-GPUs, die lange Dokumente als strukturierten Text für Dokument- oder KI-Workflows brauchen und eine self-hosted Alternative zu Cloud-OCR suchen. Weniger geeignet ist es ohne GPU-Infrastruktur oder mit Anspruch auf Support-Verträge, denn das Projekt hat noch keine Releases. Wer startet, zieht das Docker-Image vllm/vllm-openai:unlimited-ocr, spielt Beispieldokumente durch und vergleicht die Ausgabe mit eigenen Referenzdaten.
Community-Notizen