Baidu veröffentlicht Unlimited OCR 2: Hunderte Seiten pro Anfrage, SR-SWA und ein eigener Inferenz-Stack
Laut einem Bericht von MarkTechPost vom 26. Oktober 2026 hat Baidu Unlimited OCR 2 mit 3,34 Mrd. Parametern veröffentlicht. Die Gewichte stehen unter MIT-Lizenz. SR-SWA begrenzt die Attention auf eine feste Referenzmenge, um Hunderte Seiten pro Anfrage zu verarbeiten; Baidu meldet 77,1 Punkte auf MarathonDocBench.
Was sich geändert hat
Laut einem Bericht von MarkTechPost vom 26. Oktober 2026 hat Baidu Unlimited OCR 2 veröffentlicht, ein OCR-Vision-Language-Modell für sehr lange Dokumente. Die Gewichte wurden unter MIT-Lizenz auf Hugging Face bereitgestellt, der Code liegt auf GitHub; das Modell tritt die Nachfolge von Unlimited-OCR aus Juni 2026 an. Der Bericht nennt 3,34 Mrd. Parameter, ohne Angabe der aktivierten Parameter, und eine maximale Positionslänge von 131.072 Token. Die BF16-Gewichte umfassen rund 6,7 GB; Baidu testete auf einer einzelnen NVIDIA A800-80GB. Die Architektur folgt dem DeepSeek-OCR-Stil: ein SAM-ViT-B- plus CLIP-L-Encoder speist einen 12-schichtigen MoE-Decoder, der jedes Token an 6 von 64 Experten plus 2 gemeinsame Experten routet. Kernänderung ist SR-SWA (Sparse Reference Sliding Window Attention), das die Text-Vision-Attention auf eine feste Arbeitsreferenzmenge verdichtet; das Beispiel in der Modellkarte nennt 512 Token, die Konfiguration kombiniert ein lokales Fenster von 128 Token mit einer Top-16-Auswahl über 32-Token-Blöcke. Laut Bericht bleiben dadurch Dekodierlatenz und Speicherbedarf pro Schritt nahezu konstant, während Bildkodierung und Gesamtlaufzeit mit der Seitenzahl steigen; im Mehrseitenmodus verbraucht jede Seite 273 Bild-Token. Zu den Benchmarks heißt es, Baidu habe auf dem öffentlichen MPDocBench-Parse (433 Dokumente, 3.246 Seiten) und auf MarathonDocBench (hunderte Seiten) getestet, wobei keine öffentliche Version von MarathonDocBench gefunden wurde. Nach Baidus Ranglistengrafik erreicht Unlimited OCR 2 84,6 auf MPDocBench und 77,1 auf MarathonDocBench; Vergleichsmodelle kommen dort auf höchstens 33,7, der Vorgänger Unlimited-OCR auf 0,0. Alle Zahlen sind Eigenangaben Baidus und laut Bericht nur als ein Grafikbild dargestellt. Schwächster Teilwert ist die Überschriftenhierarchie (TEDS) mit 48,2 auf MarathonDocBench; der Tabellenwert fällt von 87,8 auf MPDocBench auf 74,8. Zur Ausführung nennt die Modellkarte Transformers für Schnelltests (infer für eine Seite, infer_multi für alle Seiten in einer Anfrage); serverseitig wird SGLang mit einem angepassten Wheel von Baidu verwendet, nicht das im Bericht erwähnte Upstream-SGLang. Das Laden erfordert trust_remote_code=True und führt Python-Code aus dem Repository aus. Der Bericht erwähnt außerdem, dass Baidus Beispiel 10 Seiten pro Fenster einplant und den KV-Schwanz des vorigen Fensters wiederverwendet, dass kleinere Fenster den Spitzen speicher senken, aber die seitenübergreifende Zusammenführung schwächen, und dass die Standard-bias-Einstellung eine 462-MiB-Allokation auslösen und so einen Out-of-Memory-Fehler verursachen kann. Welche Lizenz der GitHub-Code verwendet, wird nicht genannt.
Auswirkungen für Entwickler
Für Entwickler ergeben sich mehrere Ebenen, die meisten davon weiterhin prüfpflichtig. Erstens ändert sich die Schätzung von VRAM und Seitenobergrenze: Laut Bericht wächst der Dekodieraufwand pro Schritt durch SR-SWA nicht linear mit der Seitenzahl, sodass bei festem VRAM-Budget eher Bildkodierung, KV-Schwanz und Fensterplanung als das quadratische Attention-Wachstum die Seitenzahl pro Anfrage begrenzen. Das ist relevant für Offline-Batchverarbeitung mit vielen Seiten und wenig Interaktion, etwa Bücher, Anträge oder Jahresberichte. Gleichzeitig steigt laut Bericht die Gesamtlaufzeit weiter mit der Seitenzahl, sodass der Nutzen für Online-Szenarien mit schneller Seitenrückgabe begrenzt ist. Zweitens das Lock-in-Risiko beim Inferenz-Stack: Der Serving-Pfad nutzt SGLang mit angepasstem Wheel von Baidu, was laut Bericht nicht dem Upstream-SGLang entspricht und einen separat zu pflegenden Herstellerzweig bedeutet. Wer Images, Versionsfixierung und Rollback um gängige Frameworks herum aufgebaut hat, bekommt eine zusätzliche Abhängigkeit. Der Transformers-Pfad der Modellkarte taugt als Einstieg für Funktionstests, nicht als Produktionslösung. Drittens die Trennung von Lizenz und Sicherheit: Die MIT-Lizenz für die Gewichte ist eine permissive Lizenzierung und nicht mit bloß offenen Gewichten gleichzusetzen; für den GitHub-Code nennt der Bericht keine Lizenz, eine Codeübernahme sollte also nicht ohne Weiteres als MIT behandelt werden. MIT regelt zudem nur den Lizenzumfang, keine Sicherheitsgarantie für den mit trust_remote_code=True geladenen Code, der Python-Code im Prozess ausführt; in Umgebungen mit Audit-Anforderungen sind Codeprüfung und isolierte Ausführung meist vorab nötig. Viertens die Bewertungsbasis: Laut Bericht sind die Einzelunterschiede auf MPDocBench gering, etwa 94,8 zu 94,3 im Textwert und 89,4 zu 89,2 bei Formeln; die Abstände konzentrieren sich auf das hunderte Seiten umfassende MarathonDocBench. Die Auswahl sollte daher auf der Seitenverteilung der eigenen Dokumente beruhen, nicht auf der Gesamtrangliste. Die Schwächen Überschriftenhierarchie mit 48,2 und Tabellen in langen Dokumenten mit 74,8 betreffen direkt die Qualität nachgelagerter Kapitelbäume und Tabellenimporte und sollten an eigenen Stichproben separat gemessen werden.
Integration und Bewertung
Die folgenden Hinweise sind bedingte Empfehlungen, keine berichteten Fakten. Entscheidung eins: SR-SWA gegen Langdokument-Durchsatz abwägen. Auslöser ist, dass einzelne Aufgaben regelmäßig hunderte Seiten erreichen; liegen Dokumente meist unter zehn Seiten, sind die Einzelunterschiede auf MPDocBench laut Bericht gering und ein Wechsel kaum begründet. Konkret: eigenes Material nach Seitenzahl in zwei Gruppen teilen (unter zwanzig und über hundert Seiten), auf derselben GPU mit infer_multi laufen lassen und Spitzen-VRAM, Gesamtzeit sowie Zeit pro Seite erfassen. Steigt bei hundert Seiten die Zeit pro Seite deutlich mit der Seitenzahl, liegt der Engpass bei der Bildkodierung; dann sollte die Fensterseitenzahl angepasst werden, statt die Seiten pro Anfrage weiter zu erhöhen. Entscheidung zwei: Transformers oder angepasstes SGLang. Voraussetzung ist die Kompatibilität mit dem bestehenden Serving-Stack. Kann der Image- und Rollback-Prozess das angepasste SGLang nicht aufnehmen, zuerst mit Transformers Funktion und Genauigkeit prüfen und als Schwelle nehmen, ob die pro Zeiteinheit auf einer GPU verarbeitbaren Seiten ein Batch-Fenster füllen. Ist das angepasste Wheel akzeptabel, die im Bericht genannten Risiken gezielt testen: ausgehend von den 10 Seiten des Beispiels das Fenster schrittweise verkleinern und den Spitzen speicher beobachten sowie prüfen, ob die 462-MiB-Allokation durch die Standard-bias-Einstellung Out-of-Memory auslöst; „keine OOM-Fehler“ als harte Bedingung setzen. Entscheidung drei: Abnahmekriterien für strukturierte Ausgabe separat festlegen. Laut Bericht erreicht die Überschriftenhierarchie in langen Dokumenten nur 48,2 und der Tabellenwert fällt auf 74,8. Hängt die Weiterverarbeitung von Kapitelbäumen oder Tabellenimporten ab, zuerst eigene Stichproben mit Überschriftenhierarchie und Tabellenannotation vorbereiten, beide Werte nach Seitenzahl gestaffelt messen und dann über manuelle Nachprüfung oder Nachbearbeitungsregeln entscheiden. Entscheidung vier: trust_remote_code=True in die Vorabprüfung vor dem Produktivgang aufnehmen, den Code in isolierter Umgebung ausführen und prüfen sowie bei Baidu die Lizenzbedingungen des Repository-Codes erfragen, bevor über Produktion entschieden wird. Maßgeblich sollten die Fehler auf dem eigenen annotierten Datensatz sein, nicht die Gesamtpunktzahl des Herstellers.
Grenzen und offene Fragen
Die Leistungszahlen im Bericht stammen fast alle von Baidu selbst und liegen laut Bericht nur als ein Ranglisten-Grafikbild vor, ohne unabhängig reproduzierbare Evaluationsdetails. MarathonDocBench wird als Benchmark mit hunderten Seiten beschrieben, doch eine öffentliche Version wurde laut Bericht nicht gefunden; die 77,1 und der Vergleich mit anderen Modellen lassen sich daher extern nicht überprüfen. Die Zahl der aktivierten Parameter ist nicht angegeben, sodass sich tatsächlicher Rechenbedarf oder Durchsatz nicht ableiten lassen. Der Bericht nennt nur den Einzelkartenbetrieb in BF16 und rund 6,7 GB Gewichte, aber keine Quantisierungsvarianten; ob eine Bereitstellung auf Geräten mit weniger VRAM möglich ist, lässt sich aus den vorliegenden Informationen nicht beurteilen. Zum Zeitpunkt dieser Katalogprüfung erscheint Unlimited OCR 2 nicht im Modellkatalog von KimiSeek; die genannten Wege über Transformers und angepasstes SGLang sind Selbstbereitstellungspfade aus Modell-Repository und Herstellermaterial und bedeuten nicht, dass das Modell bei KimiSeek verfügbar ist. Der Bericht erwähnt auch keinen gehosteten Dienst und kein Preismodell. Sollte später ein gehosteter Dienst erscheinen, gelten für Verfügbarkeit und Preise dessen offizielle Dokumentation und Preisseite; Preise können sich ändern. Die Hinweise zu trust_remote_code=True, zur möglichen Out-of-Memory-Situation durch die Standard-bias-Einstellung und zum angepassten SGLang stammen aus Herstellermaterial und sind nicht durch Dritte verifiziert; auch die Lizenz des GitHub-Codes bleibt unklar. Die im Bericht genannten Vergleichsmodelle und Benchmark-Versionen sind relativ neu; dieser Text gibt nur die Eigenangaben wieder und beruht auf keinen unabhängigen Tests.