A 0.9-billion-parameter model is toy scale by the standards of an era where everyone ships hundred-billion-parameter giants. Yet that is exactly the size of GLM-OCR, released and open-sourced by Zhipu on February 3, 2026, which posted an overall score of 94.62 on the OmniDocBench v1.5 document-parsing benchmark — per vendor self-reported numbers — above Gemini-3 Pro at 90.33 and GPT-4o at 75.02, while official materials claim a cost of roughly one-tenth of traditional OCR pipelines. The GitHub repository is zai-org/GLM-OCR. Repository address: github.com/zai-org/GLM-OCR.
A small model at the top of the leaderboard: how real is it? This deep dive takes the license terms, architecture, benchmark caveats, weaknesses, and getting-started paths apart one by one.
First, the scope of this batch: three OCR pieces were published together. The comparison review covers six open-source OCR models head-to-head (see Six Open-Source OCR Models Compared), the SOP covers hands-on DeepSeek-OCR local deployment (see DeepSeek-OCR Local Deployment), and this article is the single-model deep dive on GLM-OCR — why it is the hottest open-source OCR right now, how solid its top score actually is, where it falls short, and how to run it.
The Release: Small Size, High Accuracy
By the official framing, GLM-OCR's positioning is "small size, high accuracy," and the goal is blunt: push document-parsing accuracy into the top tier while cutting deployment and inference cost to roughly one-tenth of traditional OCR solutions. It was open-sourced on release day. Model weights live on Hugging Face at zai-org/GLM-OCR (BF16 precision), with a mirror on ModelScope at ZhipuAI/GLM-OCR for users in China; the technical report is available as arXiv 2603.10910 (v1, March 11, 2026).
For a sense of traction (all second-hand figures): HF downloads passed 1.45 million by the end of February 2026, averaging around 3.8 million per month as of August 2026; Ollama logged roughly 6.5 million pulls in about six months, placing the model in the library-wide top 25; GitHub stars stood at about 7.2k as of August 2026. For a 0.9B vertical model, that uptake curve is genuinely unusual.
Licensing: One Repo, Three Licenses
This is where many second-hand reports get it wrong. Plenty of coverage tags the release with a single "MIT," but per the official README, the licensing is a three-way split: the repository code is under Apache License 2.0; the GLM-OCR model weights are under the MIT License; and the layout component PP-DocLayoutV3 is under Apache License 2.0 — and users must comply with both applicable terms.
In other words, all three apply at once — the MIT on the weights, the Apache 2.0 on the code, and the Apache 2.0 on the layout component — and skipping any one of them is not compliant. The good news: all three are permissive licenses with no revenue threshold and no extra restrictions, so commercial use is straightforward — but read all three LICENSE files before shipping rather than trusting a one-line repost. For a systematic look at how open-weight licenses differ, see the site's earlier open-weight license comparison.
Architecture: A 0.4B Eye, a 0.5B Brain, and an MTP Fast Lane
GLM-OCR's 0.9B total breaks into three parts: a 0.4B CogViT vision encoder, a lightweight cross-modal connector with token downsampling, and a 0.5B GLM language decoder. The vision side "looks," the language side turns what is seen into structured text, and the connector compresses the number of visual tokens flowing between them.
Recognition runs as a two-stage pipeline: PP-DocLayout-V3 first performs layout analysis, cutting the page into regions — titles, body text, tables, formulas — and each region is then recognized in parallel. That differs from whole-page, left-to-right sequential decoding: recognizing after splitting means tables and formulas are not read as ordinary running text, so structural fidelity is better. The trade-off is an extra layout-analysis stage, and errors introduced there propagate downstream.
The key speed design is MTP, multi-token prediction: the model learns to predict 10 tokens per step during training and averages 5.2 tokens per step at inference, which the official report credits with roughly a 50 percent throughput gain over standard autoregressive decoding. Training ran in four stages: MIM plus CLIP pretraining, then MTP introduction, then SFT, then GRPO reinforcement learning — where the reward signals are edit distance, CDM, TEDS, and field-level F1, all direct alignments with OCR evaluation metrics. Part of why a small model scores this high is precisely this use-the-benchmark-as-reward alignment strategy.
On the usage side there are three recognition modes — Text (plain text), Formula (LaTeX output), and Table (Markdown or HTML) — plus information extraction driven by a JSON schema: define the fields, and the model fills them in. The high-frequency needs of document parsing are covered: papers go to LaTeX editors, reports go to downstream databases, and messy contracts become structured records.
The upside of such a tight allocation — none of the redundancy of a general-purpose model — is deployment density: a single consumer GPU can host multiple replicas, and per-page batch cost drops accordingly.
Benchmarks: What 94.62 Actually Means
The numbers first. The table below comes from Table 4 of the official technical report (arXiv 2603.10910), on OmniDocBench v1.5 — and note that every score in it is vendor self-reported:
| Model | OmniDocBench v1.5 Overall |
|---|---|
| GLM-OCR (0.9B) | 94.62 |
| PaddleOCR-VL-1.5 | 94.50 |
| MinerU2.5 | 90.67 |
| Gemini-3 Pro | 90.33 |
| Qwen3-VL-235B | 89.15 |
| DeepSeek-OCR (3B) | 87.01 |
| GPT-4o | 75.02 |
GLM-OCR's own sub-scores: Text Edit 0.040, Formula CDM 93.90, Table TEDS 93.96, TEDS-S 96.39, Reading Order Edit 0.044. One note on metric direction: edit distance is lower-is-better (0.040 means roughly a 4 percent text error rate), while CDM and TEDS are higher-is-better. Within this table, GLM-OCR posts the highest overall score and the highest marks on both table metrics (TEDS and TEDS-S); however, PaddleOCR-VL-1.5 is slightly better on the Text and Formula sub-scores, so it is not a clean sweep.
One comparison in the table deserves a pause: GLM-OCR has 0.9B parameters while Qwen3-VL-235B is a general-purpose vision-language model at over two hundred billion — a gap of more than two hundred times — yet the scores run 94.62 versus 89.15. It is the core of the leaderboard-effect debate: a benchmark-tuned specialist enjoys a structural advantage that may not transfer to your real-world data.
Three caveats need to be spelled out, because this is where most coverage goes wrong:
First, claims like "highest-scoring open-source model" or "topping the chart" must be qualified as "at release time, on the OmniDocBench v1.5 board." In May 2026, Baidu shipped PaddleOCR-VL-1.6 with a self-reported 96.33 — on the v1.6 board. Scores across different benchmark versions are not directly comparable, so "GLM-OCR is still the open-source number one" is not a defensible claim.
Second, HunyuanOCR (self-reported at 94.10) and DeepSeek-OCR 2 (self-reported at 91.09) come from each vendor's own reporting and do not appear in the same table above, so they do not constitute a same-version comparison — writing that GLM-OCR "beat them at a fraction of the size" overstates the evidence.
Third, a curious contradiction in messaging: the official tagline says GLM-OCR "approaches Gemini-3-Pro" performance, yet the official table shows 94.62 against Gemini-3 Pro's 90.33 — that is an exceed, not an approach. Conservative wording like this is rare in the industry — and it arguably adds a little credibility to the benchmark claims.
Throughput and Resource Footprint
On throughput, the official figures — same hardware, single replica, single concurrency, GPU model undisclosed — are 1.86 PDF pages per second and 0.67 images per second; for comparison, PaddleOCR-VL-1.5 posts 1.22 and 0.39 under the same terms. GLM-OCR leads on both, with the PDF gap the wider one. Translated into operations language: 1.86 pages per second is roughly 6,700 pages per hour on a single replica, so a 100,000-page archive takes about 15 hours versus nearly 23 hours on PaddleOCR-VL-1.5. These are lab numbers — real batch throughput will be dragged down by preprocessing, IO, and post-processing.
On memory, neither the official README nor the technical report publishes a minimum VRAM requirement. Community measurements vary: some report "a 4GB card runs it with headroom," others cite "8GB minimum at BF16" or "4GB for the quantized build." A fair summary: officially undisclosed, community-tested at roughly 4 to 8GB depending on precision and context length. Context length has two competing figures in circulation — 66K (TheRouter) and 128K (the Ollama library page) — with no official clarification, so both are listed here without a verdict.
Weaknesses and Criticism
The task surface first: GLM-OCR only does document parsing and information extraction. It is not a general vision-language model — do not expect visual question answering or general image understanding.
Then the accuracy gaps. A third-party retest by the blogger at lilting.ch (second-hand figures) breaks the picture down: headers and footers 95.8 percent, receipt key-information extraction 94.5 percent, stamps 90.5 percent, handwriting 87.0 percent, code documentation 84.7 percent, multi-column layouts 76.7 percent — and just 37.6 percent on aged scanned documents, with 69.3 on multilingual material. The blogger's own words on the multilingual result: "still unsettling." Read the retest against the official leaderboard and the conclusion is clear: clean, modern printed documents are its home turf; aged scans and less-common languages are its weak spots. In production, sample-test those two categories before committing, and do not trust the headline score alone.
Community criticism is also worth recording. Hacker News discussion centered on two points. One: whether a small model "beating Gemini 3" reflects leaderboard effect — OmniDocBench mostly covers clean documents, and vendors' pre- and post-processing pipelines are not standardized, so score gaps do not all come from model capability. Two — and note this is architectural inference, not an official statement — the 0.5B language decoder's built-in language prior helps semantic restoration for Chinese and tables, but that same prior is exactly where hallucination risk lives: the model may fill in content that is not in the image. For receipts and contracts where accuracy is non-negotiable, plan for downstream validation.
One practical tip from HN user philipkglass: the official post-processing merges and rewrites layout data. If you are debugging layouts, save the raw output and write your own post-processing rather than trusting the packaged result.
Pulling it into one selection guideline: GLM-OCR fits "modern printed documents, Chinese-heavy, structural fidelity matters." If your corpus is decades-old damaged scans or mostly minor languages, run your own samples first — the headline score alone does not inspire confidence.
Getting Started and Ecosystem
The official SDK needs three lines, after installing with pip install glmocr:
from glmocr import parse
result = parse("document.pdf")
result.save(output_dir="./results")For self-hosting, the mainstream inference frameworks are already on board: vLLM supports it from v0.19.0 with MTP exposed through the speculative config, and SGLang supports it from v0.5.10 using NEXTN speculative decoding. The vLLM launch command, verbatim from the official README:
vllm serve zai-org/GLM-OCR --port 8080 --speculative-config '{"method": "mtp", "num_speculative_tokens": 3}' --served-model-name glm-ocrAnd the SGLang equivalent:
SGLANG_ENABLE_SPEC_V2=1 sglang serve --model-path zai-org/GLM-OCR --port 8080 --speculative-algorithm NEXTN --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4 --served-model-name glm-ocrThe easiest path is Ollama: the model weighs 2.2GB, the q8_0 quantized build about 1.6GB, and one command brings it up (a recent version is required):
ollama run glm-ocrOne pitfall from second-hand testing: route vision requests through Ollama's native /api/generate endpoint rather than the OpenAI-compatible one. Beyond that, mlx-vlm runs it locally on Apple Silicon, and llama.cpp and LM Studio users can pick up the community-converted ggml-org/GLM-OCR-GGUF.
How to choose among the four paths: for local trials and small personal batches, Ollama or the SDK is the least friction; for production pipelines where throughput and concurrency matter, pick vLLM or SGLang — both capture the MTP speculative-decoding speedup; Mac users who want it local go with mlx-vlm.
If you would rather not deploy at all, the hosted API is priced at 0.2 CNY per million tokens with identical input and output rates (official announcement), so small-scale use costs effectively nothing.
GLM-OCR or DeepSeek-OCR?
GLM-OCR and DeepSeek-OCR 2 (about 3B, using Visual Causal Flow) represent two technical routes in open-source OCR. The latter takes the compression route: squeeze a whole page into very few visual tokens in exchange for throughput, a fit for massive PDF-to-Markdown pipelines. GLM-OCR takes region-split parallel recognition: it preserves structural and layout fidelity at the cost of higher token consumption. One-line selection: throughput first, choose DeepSeek-OCR; structural fidelity first, choose GLM-OCR. When both matter, the most direct answer is to run each model's raw output over your own sample set and let field-level accuracy decide. For hands-on installation details and pitfalls of the DeepSeek side, see this batch's SOP piece.
FAQ
Q1: How much VRAM does GLM-OCR need?
Officially undisclosed. Community tests land around 4 to 8GB depending on precision and context length, with working reports at 4GB on the quantized build.
Q2: What license does GLM-OCR use — can I use it commercially?
A three-way split: repository code under Apache License 2.0, model weights under MIT, layout component PP-DocLayoutV3 under Apache License 2.0, and users must comply with all applicable terms. All three are permissive with no revenue threshold, so commercial use is fine.
Q3: Did GLM-OCR really beat Gemini-3-Pro?
Within the official self-reported OmniDocBench v1.5 table, GLM-OCR's 94.62 is above Gemini-3 Pro's 90.33 — an exceed, not merely "approaching." But all scores there are vendor self-reported, and numbers across different benchmark versions cannot be compared directly.
Q4: What tasks does GLM-OCR support?
Three recognition modes (Text, Formula to LaTeX, Table to Markdown or HTML) plus JSON-schema-driven information extraction. It covers document parsing and extraction only — not a general vision-language model.
Q5: GLM-OCR or DeepSeek-OCR — which should I pick?
For throughput and massive PDF-to-Markdown batches, DeepSeek-OCR's compression route; for structural fidelity in tables and layouts, GLM-OCR's region-split recognition.
Related reading