GLM-OCR: The 0.9B Model That Made Local OCR Actually Good

Quick verdict

If you have a folder of PDFs, scans, or screenshots you want as clean Markdown — papers into Obsidian, invoices into a database, textbook pages into notes — GLM-OCR is the local tool to reach for first. It occupies the same slot for documents that Whisper occupies for audio: a small, free, category-leading utility model that quietly beats paid cloud APIs at its one job. Whisper made local transcription a solved problem; GLM-OCR is doing the same for document parsing, and its 6.5M Ollama pulls in about six months say the crowd has noticed.

What it is not: a vision chatbot. The language decoder inside is GLM-0.5B — it transcribes and structures what it sees, it doesn't discuss it. If you want to ask questions about an image or document, pair it with a general VLM — our GLM-4.5V local setup guide covers the same lab's chat-capable vision model.

Specs at a glance

How the two-stage pipeline works

GLM-OCR's trick is that the 0.9B model never has to understand a whole page at once. Per the official repo, the full pipeline runs in two stages:

• 1.Layout analysis. PP-DocLayout-V3 (an Apache-2.0 layout-detection model, integrated into the pipeline) carves each page into regions: text blocks, tables, formulas, figures, headers.
• 2.Parallel recognition. Each region goes through GLM-OCR independently — the CogViT encoder reads the crop, a lightweight connector downsamples the visual tokens, and the GLM-0.5B decoder writes it out as Markdown, LaTeX, or structured table text. Regions run in parallel, which is why PDF throughput is higher than you'd guess for a sequential model.

This division of labor is why a sub-1B model tops a benchmark full of heavyweight pipelines: layout detection is a solved vision problem that doesn't need an LLM, and per-region transcription is a narrow task a small decoder can be trained to do extremely well. It also explains a quirk in the published speed numbers below — PDFs process faster per page than standalone images.

Ollama setup (and its two gotchas)

The happy path is three commands — but two gotchas catch a lot of people, so here they are up front.

Gotcha 1: you need a current Ollama build

I tried the pull on a Mac still running Ollama 0.12.3 (installed late 2025) and got a hard refusal: Error: pull model manifest: 412: The model you are attempting to pull requires a newer version of Ollama. Update from ollama.com/download (or brew upgrade ollama on macOS) before filing bug reports.

ollama pull glm-ocr
ollama run glm-ocr "Text Recognition: ./page.png"
ollama run glm-ocr "Table Recognition: ./table.png"
ollama run glm-ocr "Figure Recognition: ./chart.png"

Those three prompt prefixes — Text, Table, Figure Recognition — are the documented interface on the Ollama model page, not free-form chat. Use them.

Gotcha 2: use the native /api/generate endpoint

The official deployment guide is explicit about this: "due to limitations in Ollama's OpenAI-compatible API for vision requests, we recommend using Ollama's native /api/generate endpoint." So if you point an OpenAI-flavored client at :11434/v1 and get empty or mangled output, that's why. Calling the native API directly:

curl http://localhost:11434/api/generate -d '{
  "model": "glm-ocr:latest",
  "prompt": "Text Recognition:",
  "images": ["<base64-encoded page image>"],
  "stream": false,
  "options": { "num_ctx": 16384 }
}'

The num_ctx bump is my recommendation, not an official requirement: a dense page of tables can decode into thousands of Markdown tokens, and Ollama's default context is stingy — give it headroom so long pages don't truncate mid-table. The model itself supports 128K, so 16384 costs you nothing at this parameter count.

PDF to Markdown with the glmocr SDK

For real documents — multi-page PDFs, batches, anything with layout — skip raw Ollama prompting and use the official Python SDK, which runs the whole two-stage pipeline and writes Markdown plus JSON layout:

pip install glmocr
glmocr parse report.pdf        # CLI
# or in Python:
# from glmocr import parse
# result = parse("report.pdf"); result.save()

By default the SDK can call Z.ai's cloud API — for a fully local run, point it at your Ollama server in the config (this block is straight from the repo's Ollama deployment guide):

ocr_api:
  api_host: localhost
  api_port: 11434
  api_path: /api/generate
  model: glm-ocr:latest
  api_mode: ollama_generate

With that in place, nothing leaves your machine — the same privacy argument that makes local Whisper transcription the default for sensitive audio applies to your contracts, medical records, and financial statements here. The SDK also supports structured extraction against a JSON schema (per the model card), which is the feature to reach for if you're parsing invoices or forms into a database rather than into prose.

vLLM / SGLang for batch jobs

The deployment guide itself positions Ollama as the testing/personal-use route and recommends vLLM or SGLang for production throughput. The official serve commands, verbatim from the repo:

# vLLM
vllm serve zai-org/GLM-OCR --port 8080 \
  --speculative-config '{"method": "mtp", "num_speculative_tokens": 3}'

# SGLang
sglang serve --model-path zai-org/GLM-OCR --port 8080 \
  --speculative-algorithm NEXTN --speculative-num-steps 3

Note the speculative-decoding flags in both — the model ships with an MTP head, and Z.ai's commands enable it by default. Add --max-model-len and --gpu-memory-utilization to taste; the repo deliberately leaves those machine-dependent. On any 8GB+ card this is a trivially light serve — if you're sizing a box for it plus bigger models, our VRAM calculator does the math.

Benchmarks

Headline result: 94.62 on OmniDocBench V1.5, #1 overall — Z.ai's published claim, repeated on the Ollama library page, with state-of-the-art results reported across formula recognition, table recognition, and information extraction. All figures below are Z.ai's own published numbers, not our measurements.

Two honest notes. First, PDFs outrun single images because the pipeline batches page regions in parallel; one screenshot can't be parallelized the same way. Second, Z.ai doesn't disclose the GPU behind those throughput numbers, so treat them as relative, not as a promise for your laptop — on small CPU-only machines expect a few seconds per page, not two pages a second.

Honest limitations

• •It reads documents; it doesn't reason about them. The decoder is a 0.5B GLM. Ask it to summarize, answer questions, or interpret a chart's meaning and you've left its competence zone — chain it with a real LLM for that (see which local vision task needs which model).
• •Fluent errors on bad scans. Like every neural OCR model, when the input is blurry or degraded it can produce confident, grammatical, wrong text instead of visible garbage. For archival or legal work, spot-check against the source.
• •The Ollama route is a convenience, not the product. Raw ollama run does single-image recognition with fixed prompt prefixes; the layout-aware PDF pipeline lives in the glmocr SDK. People who judge the model on a bare Ollama prompt against a full page are underselling it.
• •OpenAI-compatible endpoints misbehave. Tools that only speak :11434/v1 (some chat UIs) may fail on vision requests with this model — the official guide steers you to native /api/generate.
• •No official VRAM/hardware guidance. Fine in practice at this size, but the throughput figures come with no disclosed GPU, so benchmark on your own hardware before promising SLAs.

Frequently asked questions