GLM-OCR is a multimodal OCR model for complex document understanding, built on the GLM-V encoder–decoder architecture. It introduces Multi-Token Prediction (MTP) loss and stable full-task reinforcement learning to improve training efficiency, recognition accuracy, and generalization. The model integrates the CogViT visual encoder pre-trained on large-scale image–text data, a lightweight cross-modal connector with efficient token downsampling, and a GLM-0.5B language decoder. Combined with a two-stage pipeline of layout analysis and parallel recognition based on PP-DocLayout-V3, GLM-OCR delivers robust and high-quality OCR performance across diverse document layouts.
Key Features
State-of-the-Art Performance: Achieves a score of 94.62 on OmniDocBench V1.5, ranking #1 overall, and delivers state-of-the-art results across major document understanding benchmarks, including formula recognition, table recognition, and information extraction.
Optimized for Real-World Scenarios: Designed and optimized for practical business use cases, maintaining robust performance on complex tables, code-heavy documents, seals, and other challenging real-world layouts.
Efficient Inference: With only 0.9B parameters, GLM-OCR supports deployment via vLLM, SGLang, and Ollama, significantly reducing inference latency and compute cost, making it ideal for high-concurrency services and edge deployments.
Easy to Use: Fully open-sourced and equipped with a comprehensive SDK and inference toolchain, offering simple installation, one-line invocation, and smooth integration into existing production pipelines.
News & Updates
[2026.3.12] GLM-OCR SDK now supports agent-friendly Skill mode — just pip install glmocr + set API key, ready to use via CLI or Python with no GPU or YAML config needed. See: GLM-OCR Skill
Option 1: Zhipu MaaS API (Recommended for Quick Start)
Use the hosted cloud API – no GPU needed. The cloud service runs the complete GLM-OCR pipeline internally, so the SDK simply forwards your request and returns the result.
That's it! When maas.enabled=true, the SDK acts as a thin wrapper that:
Forwards your documents to the Zhipu cloud API
Returns the results directly (Markdown + JSON layout details)
No local processing, no GPU required
Input note (MaaS): the upstream API accepts file as a URL or a data:<mime>;base64,... data URI.
If you have raw base64 without the data: prefix, wrap it as a data URI (recommended). The SDK will
auto-wrap local file paths / bytes / raw base64 into a data URI when calling MaaS.
Deploy the GLM-OCR model locally for full control. The SDK provides the complete pipeline: layout detection, parallel region OCR, and result formatting.
Deploy the SDK Server on a GPU machine, then use any machine as a client — no GPU needed on the client side. The client connects via the MaaS-compatible protocol, pointing api_url at your self-hosted server.
# Client config.yaml
pipeline:
maas:
enabled: true
api_url: http://<SERVER_IP>:5002/glmocr/parse
api_key: any-string # self-hosted server does not validate keys
verify_ssl: false
After launching the service, configure config.yaml:
pipeline:
maas:
enabled: false # Disable MaaS mode (default)
ocr_api:
api_host: localhost # or your vLLM/SGLang server address
api_port: 8080
SDK Usage Guide
CLI
# Parse a single image
glmocr parse examples/source/code.png
# Parse a directory
glmocr parse examples/source/
# Set output directory
glmocr parse examples/source/code.png --output ./results/
# Use a custom config
glmocr parse examples/source/code.png --config my_config.yaml
# Enable debug logging with profiling
glmocr parse examples/source/code.png --log-level DEBUG
# Run layout detection on CPU (keep GPU free for OCR model)
glmocr parse examples/source/code.png --layout-device cpu
# Run layout detection on a specific GPU
glmocr parse examples/source/code.png --layout-device cuda:1
# Override any config value via --set (dotted path, repeatable)
glmocr parse examples/source/code.png --set pipeline.ocr_api.api_port 8080
glmocr parse examples/source/ --set pipeline.layout.use_polygon true --set logging.level DEBUG
Python API
from glmocr import GlmOcr, parse
# Simple function
result = parse("image.png")
result = parse(["img1.png", "img2.jpg"])
result = parse("https://example.com/image.png")
result.save(output_dir="./results")
# Note: a list is treated as pages of a single document.
# Class-based API
with GlmOcr() as parser:
result = parser.parse("image.png")
print(result.json_result)
result.save()
# Place layout model on CPU (useful when GPU is reserved for OCR)
with GlmOcr(layout_device="cpu") as parser:
result = parser.parse("image.png")
# Place layout model on a specific GPU
with GlmOcr(layout_device="cuda:1") as parser:
result = parser.parse("image.png")
Flask Service
Install the optional server dependency first:
pip install "glmocr[server]"
# Start service
python -m glmocr.server
# With debug logging
python -m glmocr.server --log-level DEBUG
# Call API
curl -X POST http://localhost:5002/glmocr/parse \
-H "Content-Type: application/json" \
-d '{"images": ["./example/source/code.png"]}'
Semantics:
images can be a string or a list.
A list is treated as pages of a single document.
For multiple independent documents, call the endpoint multiple times (one document per request).
Modular Architecture
GLM-OCR uses composable modules for easy customization:
Component
Description
PageLoader
Preprocessing and image encoding
OCRClient
Calls the GLM-OCR model service
PPDocLayoutDetector
PP-DocLayout layout detection
ResultFormatter
Post-processing, outputs JSON/Markdown
You can extend the behavior by creating custom pipelines:
from glmocr.dataloader import PageLoader
from glmocr.ocr_client import OCRClient
from glmocr.postprocess import ResultFormatter
class MyPipeline:
def __init__(self, config):
self.page_loader = PageLoader(config)
self.ocr_client = OCRClient(config)
self.formatter = ResultFormatter(config)
def process(self, request_data):
# Implement your own processing logic
pass
Star History
Acknowledgement
This project is inspired by the excellent work of the following projects and communities:
The Code of this repo is under Apache License 2.0.
The GLM-OCR model is released under the MIT License.
The complete OCR pipeline integrates PP-DocLayoutV3 for document layout analysis, which is licensed under the Apache License 2.0. Users should comply with both licenses when using this project.
Citation
If you find GLM-OCR useful in your research, please cite our technical report:
@misc{duan2026glmocrtechnicalreport,
title={GLM-OCR Technical Report},
author={Shuaiqi Duan and Yadong Xue and Weihan Wang and Zhe Su and Huan Liu and Sheng Yang and Guobing Gan and Guo Wang and Zihan Wang and Shengdong Yan and Dexin Jin and Yuxuan Zhang and Guohong Wen and Yanfeng Wang and Yutao Zhang and Xiaohan Zhang and Wenyi Hong and Yukuo Cen and Da Yin and Bin Chen and Wenmeng Yu and Xiaotao Gu and Jie Tang},
year={2026},
eprint={2603.10910},
archivePrefix={arXiv},
primaryClass={cs.CL},
url={https://arxiv.org/abs/2603.10910},
}
What is this?GLM-OCR is a multimodal OCR model for complex document understanding, built on a GLM-V encoder-decoder architecture with a lightweight SDK and inference toolchain around it.
Is this just a model, or a full toolkit?It is both: a 0.9B-parameter OCR model plus a Python SDK offering CLI, Python API, and Flask service entry points, with modular components for layout detection and result formatting.
How do I get it running?Install the SDK with pip install glmocr, then either call Zhipu's hosted MaaS cloud API with an API key for a quick start, or self-host the model with vLLM or SGLang for full local control.
Do I need to tune anything for large images or PDFs?Yes, when self-hosting you should set vLLM's --max-model-len and --gpu-memory-utilization, or SGLang's --context-len and --mem-fraction-static, according to your machine to handle large image/PDF inputs.
Can I run this on a Mac without a dedicated GPU?Yes, there are Apple Silicon-specific deployment guides using mlx-vlm, as well as a simple local deployment path through Ollama.
How accurate is GLM-OCR compared to other OCR models?It scores 94.62 on OmniDocBench V1.5, ranking #1 overall and achieving state-of-the-art results in formula recognition, table recognition, and information extraction.
Why is it described as fast despite running a full document pipeline?At only 0.9B parameters, GLM-OCR keeps inference latency and compute cost low enough for high-concurrency services and edge deployments.
Can GLM-OCR be used as an agent skill?Yes, the SDK supports an agent-friendly Skill mode: pip install glmocr plus an API key gives immediate CLI/Python access with no GPU or YAML config needed.
How is the OCR pipeline structured internally?It's modular: PageLoader handles preprocessing, PPDocLayoutDetector performs layout detection, OCRClient calls the GLM-OCR model, and ResultFormatter outputs JSON/Markdown — each piece can be swapped for custom pipelines.
GLM-OCR is a multimodal OCR model for complex document understanding, built on a GLM-V encoder-decoder architecture with a lightweight SDK and inference toolchain around it.