Zhipu AI GLM OCR (0.9B) — document parser for PDF/image to structured Markdown text extraction.
GLM-OCR is a 0.9B-parameter multimodal OCR model released by Z.AI (formerly Zhipu AI) on February 3, 2026, under the MIT license. It pairs a 0.4B CogViT visual encoder — pre-trained on large-scale image–text data — with a lightweight cross-modal connector and a 0.5B GLM language decoder. The model is purpose-built for document understanding rather than being a general-purpose vision-language model adapted to OCR: it delivers structured Markdown, JSON, and LaTeX outputs from scanned PDFs, images, tables, mathematical formulas, code blocks, seals, and handwritten text.
Architecturally, GLM-OCR uses Multi-Token Prediction (MTP) — trained to predict 10 tokens per step and achieving 5.2 tokens per step at inference on average — delivering roughly 50% higher throughput than standard autoregressive decoding. At the system level it follows a two-stage pipeline: PP-DocLayout-V3 first analyses page layout and identifies structured regions, then GLM-OCR processes those regions in parallel for recognition and structured output. This makes it meaningfully different from flat left-to-right page readers and more robust on complex layouts. On OmniDocBench V1.5 it scores 94.62, ranking #1 overall among models at time of release, while fitting on hardware with as little as 4 GB of VRAM.
| Type | Rate |
|---|---|
| Input | $0.0324 / 1M tokens |
| Output | $0.0324 / 1M tokens |
| Release date | 2026-02-03huggingface.co ↗ | verified |
| License | MIThuggingface.co ↗ | verified |
| Total parameters | 0.9B (0.4B CogViT encoder + 0.5B GLM decoder)arxiv.org ↗ | verified |
| Minimum GPU VRAM | 4 GBpasqualepillitteri.it ↗ | to verify |
| PDF throughput (single concurrency) | 1.86 pages/sechuggingface.co ↗ | verified |
| Image throughput (single concurrency) | 0.67 images/sechuggingface.co ↗ | verified |
| MTP decoding speed | 5.2 tokens/step average (trained for 10)arxiv.org ↗ | verified |
| Training cutoff | Not publicly disclosed | unknown |
| Benchmark | Distribution | Score | Source |
|---|---|---|---|
OmniDocBench V1.5 | 94.62score | huggingface.co ↗ |
Use the global api.therouter.ai endpoint shown below for new integrations; the legacy China accelerated endpoint is retired.
curl https://api.therouter.ai/v1/chat/completions -H "Content-Type: application/json" -H "Authorization: Bearer $THE_ROUTER_API_KEY" -d '{
"model": "zhipu/glm-ocr",
"messages": [
{"role": "user", "content": "Summarize the key points from this input."}
]
}'curl https://api.therouter.ai/v1/chat/completions \
-H "Authorization: Bearer $THEROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "zhipu/glm-ocr",
"messages": [
{
"role": "user",
"content": [
{
"type": "image_url",
"image_url": { "url": "https://therouter.ai/assets/vision-sample.png" }
},
{
"type": "text",
"text": "Convert this document to structured Markdown. Preserve tables, headings, and list structure exactly."
}
]
}
]
}'Z.AI published the full technical report (arXiv 2603.10910) describing GLM-OCR's architecture: CogViT encoder, MTP decoding, PP-DocLayout-V3 two-stage pipeline, and the KIE task path. The report includes ablation results showing ~50% throughput gain from MTP versus standard autoregressive decoding and the OmniDocBench V1.5 #1 ranking.
Yes. The model is explicitly optimized for real-world business document scenarios including handwritten text, seals, code-heavy documents, and complex table layouts — not just clean printed pages. The OmniDocBench V1.5 #1 ranking covers these mixed-content benchmarks.
Z.AI recommends the official SDK (github.com/zai-org/GLM-OCR) for document parsing tasks because it integrates PP-DocLayout-V3 for layout pre-processing, which improves accuracy on complex multi-column or multi-region documents. Calling the raw API endpoint directly is simpler but skips the layout analysis stage — it works well for single-page images or when you are already handling layout detection yourself. For KIE tasks, the SDK is not currently needed; call the model directly with a JSON extraction prompt.
Yes. GLM-OCR ships as an open-weight MIT-licensed model (zai-org/GLM-OCR on HuggingFace) and supports local deployment via vLLM, SGLang, and Ollama. The minimum reported VRAM requirement is 4 GB, making it accessible on mid-range consumer GPUs. Via TheRouter you can call it without any local setup and pay per token.
| source | URL | retrieved | |
|---|---|---|---|
| Release date | huggingface.co ↗ | 2026-06-09 | verified |
| License | huggingface.co ↗ | 2026-06-09 | verified |
| Total parameters | arxiv.org ↗ | 2026-06-09 | verified |
| Minimum GPU VRAM | pasqualepillitteri.it ↗ | 2026-06-09 | to verify |
| PDF throughput (single concurrency) | huggingface.co ↗ | 2026-06-09 | verified |
| Image throughput (single concurrency) | huggingface.co ↗ | 2026-06-09 | verified |
| MTP decoding speed | arxiv.org ↗ | 2026-06-09 | verified |
| Training cutoff | — | — | unknown |
| OmniDocBench V1.5 | huggingface.co ↗ | 2026-06-09 | verified |
| GLM-OCR technical paper published on arXiv | arxiv.org ↗ | 2026-06-09 | verified |
| Does GLM-OCR handle handwritten text and stamps? | huggingface.co ↗ | 2026-06-09 | to verify |
| Should I use the API directly or the GLM-OCR SDK for document parsing? | huggingface.co ↗ | 2026-06-09 | to verify |
| Can GLM-OCR run locally, and what are the hardware requirements? | huggingface.co ↗ | 2026-06-09 | to verify |