dots.ocr-1.5: 3B OCR model from Rednote-hilab with SVG output for charts/diagrams/formulas

TL;DR

ModelScope’s announcement of dots.ocr-1.5, a 3B-parameter open OCR / document-parsing VLM from Rednote-hilab. The headline claims are SOTA-class multilingual document parsing (Elo 1089 on olmOCR-Bench, 1157 on XDocParse, both above GLM-OCR and PaddleOCR-VL-1.5), OmniDocBench text edit-distance of 0.031 (beating Qwen3-VL-235B at 0.069 and Gemini 2.5 Pro at 0.075), and — the distinctive capability flagged in Haoxiang’s note — direct SVG code output for charts, diagrams, and chemical formulas. Web parsing, scene text spotting, and object counting are listed as additional supported tasks; the model serves on a single GPU under vLLM. Released as open weights (ModelScope) with a public GitHub repo and a hosted demo.

Key claims

3B-parameter open OCR VLM from Rednote-hilab, distributed via ModelScope [tweet body].
Elo 1089 on olmOCR-Bench and 1157 on XDocParse, reported to be above GLM-OCR and PaddleOCR-VL-1.5 [tweet body].
OmniDocBench text edit-distance 0.031, beating Qwen3-VL-235B (0.069) and Gemini 2.5 Pro (0.075) [tweet body].
Outputs SVG code directly for charts, diagrams, and chemical formulas — the distinctive capability vs prior open OCR VLMs [tweet body].
Additional task coverage: web parsing, scene text spotting, object counting [tweet body].
Single-GPU inference under vLLM [tweet body].
Open release surface: ModelScope model card (modelscope.cn/models/rednote-hilab/dots.ocr-1.5), GitHub repo (github.com/rednote-hilab/dots.ocr), hosted demo at dotsocr.xiaohongshu.com [tweet body].

Method

No technical details in the tweet beyond the headline benchmarks and capability list — no architecture description, no training recipe, no paper link. The “SVG code output” capability is the only mechanically-suggestive datapoint: rather than emitting structured-JSON or LaTeX for non-text page elements (the usual outputs of e.g. DeepSeek-OCR 2 and PaddleOCR-VL), dots.ocr-1.5 emits raster→vector SVG for charts, diagrams, and chemical-formula renderings, which would let downstream consumers re-render the original element exactly. The GitHub README and ModelScope card are the documentation channels for any deeper detail.

Results

Headline numbers from the tweet:

olmOCR-Bench Elo: 1089 (claimed above GLM-OCR and PaddleOCR-VL-1.5).
XDocParse Elo: 1157 (claimed above the same baselines).
OmniDocBench text edit-distance: 0.031, vs Qwen3-VL-235B 0.069 and Gemini 2.5 Pro 0.075 — a ~2× edge over Qwen3-VL-235B at roughly 1/80 the parameter count.

No latency / throughput / VRAM numbers; no per-language or per-document-type breakdowns; no ablations. Comparison to DeepSeek-OCR 2 (which is itself benchmarked against an earlier “dots.ocr” datapoint at 88.41 OmniDocBench v1.5 Overall) is not in the tweet — XDocParse / olmOCR-Bench are different benchmarks than the OmniDocBench v1.5 metric DeepSeek-OCR 2 reports.

Why it’s interesting

dots.ocr-1.5 is the third compact open OCR-VLM datapoint on the wiki in the same window as DeepSeek-OCR 2: Visual Causal Flow (DeepSeek-OCR 2, 3B-MoE / 500M active, 91.09 OmniDocBench v1.5) and PaddleOCR-VL: Boosting Multilingual Document Parsing via a 0.9B Ultra-Compact Vision-Language Model (PaddleOCR-VL, 0.9B, 94.5 OmniDocBench v1.5) — the cluster pattern of <5B open document-parsing VLMs is now clearly established. The distinctive axis here is the SVG output format: where DeepSeek-OCR 2 emits LaTeX/structured text and PaddleOCR-VL emits JSON+markdown, dots.ocr-1.5 emits directly-renderable SVG for non-text elements — a different answer to the “how do you preserve charts and diagrams in OCR output” question, and a useful primitive for downstream document re-rendering and editing pipelines. Worth tracking against IGenBench: Benchmarking the Reliability of Text-to-Infographic Generation (text-to-infographic generation) on the inverse direction (chart code → image) as a sanity check on whether SVG-as-OCR-target and SVG-as-generation-target converge on the same intermediate representation.