glm-ocr-parse-mode: GLM-OCR parse-mode document parsing, evaluated for this platform

glm-ocr-parse-mode is this platform's name for a document-parsing capability built on GLM-OCR. GLM-OCR is a 0.9-billion-parameter multimodal OCR model released by Z.ai (Zhipu AI) on February 3, 2026. The job is page-image in, structured text out. Photographs, scans, and PDF pages become Markdown with tables, formulas, and reading order preserved. The platform has evaluated the capability and written this page. It has no listing, no rate, and no hosted lane today, and no date is promised for one. What follows is the model's identity with every number's owner named. It carries the official benchmark record, version-qualified and column-labeled. It also carries the publisher's own API surface described exactly, and the call shape that would work here the day a row lands.

Last verified: 2026-09-25

What it is

Z.ai publishes GLM-OCR three ways. It offers a hosted API on its developer platform. It offers open weights on Hugging Face under MIT, and an open-source SDK and pipeline on GitHub. The technical report (arXiv 2603.10910, March 2026) carries the full benchmark record. The identity facts, source by source:

The architecture in plain language follows. A vision encoder turns the page into tokens. A connector compresses them. A small language decoder writes the text out. The trick that makes a 0.9B model fast at OCR is multi-token prediction. Standard text models write one token per step. GLM-OCR was trained to predict ten and, at inference, emits 5.2 tokens per step on average. The report credits that with roughly half again the throughput at low memory overhead. Layout comes from a second, smaller model: PP-DocLayout-V3 finds the regions (paragraphs, tables, formulas). The OCR model reads each region, and a merge step restores reading order into Markdown and JSON.

The parse-mode law is stricter than most model pages admit. The model card currently supports exactly two prompt scenarios. Document parsing uses one of three fixed task prompts, Text Recognition, Formula Recognition, or Table Recognition. Information extraction instead sends a strict JSON schema as the prompt. It pulls named fields off invoices, certificates, and forms. The card warns the output must adhere to that schema for downstream processing to work. This is what parse-mode means on this page: the document-parsing scenario of that pair, page-image to Markdown. The name is this platform's. The publisher calls the task document parsing and wraps it, on its own API, in a tool endpoint described below.

One honest wobble in the publisher's documentation is worth recording. Z.ai's model guide says the hosted service accepts PDFs up to 50 MB with a maximum of 100 pages. Its layout-parsing API reference, describing the same endpoint, says 30 pages. Both pages were live at this page's verification date. Images are capped at 10 MB on both. If a 100-page job matters to you, split the PDF regardless of which host serves it.

Use cases

The publisher positions the model on five document jobs. Each is backed by a benchmark, a documented input, or a task prompt.

• Page-to-Markdown conversion at volume. Scanned reports, manuals, and papers become Markdown with structure intact. This is the bulk job the throughput number describes: 1.86 PDF pages per second and 0.67 images per second, publisher-measured on a single replica at single concurrency.
• Table and formula recovery. Tables come back as HTML structure and formulas as LaTeX-style text, with dedicated task prompts for each. On the publisher's benchmark table these are the model's strongest axes, and the report highlights code-heavy documents and seals as tuned-for scenarios.
• Schema-driven field extraction. Cards, certificates, receipts, and forms in, JSON out, with the schema supplied in the prompt. The technical report scores the model at 93.7 on Nanonets-KIE and 86.1 on Handwritten-KIE, publisher-run.
• Multilingual corpora. Eight languages are named on the card, and multilingual OCR is one of the report's six real-world evaluation scenarios.
• RAG and search ingestion. Clean page text with layout preserved is the input retrieval systems want, which is why the docs list RAG support as a primary usage.

What it is not for is free-form chat about a document. The card supports two task scenarios, not conversation. It is also not for audio, or for anything needing the benchmark numbers as a guarantee. Independent coverage since release argues OmniDocBench itself is saturating. It points at a long tail of documents where every top-scoring model still fails. A 94-plus headline does not exempt your pages.

Self-host, or wait for the hosted row

Nothing about this model forces a cloud. MIT weights plus a 2 GB-class download put self-hosting within reach of a laptop. That is unusual for a parser that tops a benchmark table.

The local path fits when the documents can leave your machine or you want the pipeline inside your own perimeter. The official Ollama library entry ships the model as a 2.2 GB download with a 128K context window and text-plus-image input. A 1.6 GB q8_0 build sits beside it. The entry counts 7.1 million pulls. vLLM serves it natively from 0.19.0 with multi-token-prediction speculative decoding, and SGLang from 0.5.10. llama.cpp's OCR guide runs the GGUF build on 4 GB-class GPUs, with some paths usable on CPU. The official SDK (pip install glmocr) wires the whole two-model pipeline, layout detector included, behind one command. The caveat that keeps local honest: the parse pipeline is two models. Plan memory and licensing (model MIT, PP-DocLayout-V3 Apache 2.0) for both.

The hosted route earns its rent when you would rather not own a stack. That stack means metering per call, keys you can revoke, a wallet as the spend boundary, and no layout-model upkeep. On this platform that route is written, not open. The evaluation is this page. A row would ride the chat route family with the call shape shown below, and the invite flow at the console is how to be there when it lands.

Z.ai's own service is the working option today if waiting is the problem. The publisher already serves the model behind its own API and prices it per token on its own pages. That price is set by Z.ai and metered by Z.ai, which proves the capability serves in production somewhere. No figure from those pages is carried onto this one.

API usage

A row for this capability would ride the platform's chat route family: POST /v1/chat/completions, OpenAI-compatible in shape, with a console key in the Authorization Bearer header. The page image rides in an image_url content block. The task prompt is the user text. That shape is not invented for this page. It is how the open model serves on vLLM, SGLang, and llama.cpp today. The alias glm-ocr-parse-mode answers nothing at the moment. No listing for it exists today, so the route refuses it. The tabs below show the call that works the day a row lands.

The accepted set on this route includes model, messages, stream, max_tokens and max_completion_tokens, temperature, top_p, top_k, tools, and response_format. Any key outside the accepted set triggers a parameter error right away, and nothing is relayed. Two known keys, store and service_tier, return an explicit not-supported error rather than being ignored.

Three things these tabs deliberately do not show:

1. No thinking knob. The publisher's documented control surface for this model is the task prompt itself; z.ai's hosted layout-parsing endpoint exposes no reasoning parameter, and the model card defines none. If a row here ever surfaces an additional control, it publishes with the row; asserting a mapping now would be guessing, so the tabs stay minimal and guaranteed.
2. No price, anywhere. No rate exists for this alias. Cost answers live on the pricing page once a row lands.
3. No availability claim. The examples are the shape, not an open service. Nothing on this page should be read as a launch date.

curl

curl -X POST "https://api.ironstratum.com/v1/chat/completions" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-ocr-parse-mode",
    "messages": [
      {
        "role": "user",
        "content": [
          {"type": "image_url", "image_url": {"url": "https://example.com/invoice-page-01.png"}},
          {"type": "text", "text": "Text Recognition:"}
        ]
      }
    ],
    "max_tokens": 8192
  }'

python

import os
import requests

resp = requests.post(
    "https://api.ironstratum.com/v1/chat/completions",
    headers={"Authorization": "Bearer " + os.environ["KEY"]},
    json={
        "model": "glm-ocr-parse-mode",
        "messages": [
            {
                "role": "user",
                "content": [
                    {"type": "image_url", "image_url": {"url": page_image_url}},
                    {"type": "text", "text": "Text Recognition:"},
                ],
            }
        ],
        "max_tokens": 8192,
    },
    timeout=300,
)
resp.raise_for_status()

body = resp.json()
print(body["choices"][0]["message"]["content"])
print("usage:", body["usage"])

openai-sdk

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.ironstratum.com/v1",
    api_key=os.environ["KEY"],
)

response = client.chat.completions.create(
    model="glm-ocr-parse-mode",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "image_url", "image_url": {"url": page_image_url}},
                {"type": "text", "text": "Text Recognition:"},
            ],
        }
    ],
    max_tokens=8192,
)

print(response.choices[0].message.content)

Code already written against the OpenAI SDK needs two changes to point here. Change where the client sends its requests, and change the model id. The other task prompts slot into the text block the same way: Formula Recognition: for mathematical content and Table Recognition: for tables. Your JSON schema as the text serves when the job is field extraction.

There is a second API shape in the world, and naming it prevents confusion. Z.ai's own hosted surface is a tool endpoint, POST /api/paas/v4/layout_parsing. It takes a file (URL or base64) and returns Markdown plus per-region layout details with bounding boxes, page counts, and token usage. That endpoint belongs to the publisher. It carries the publisher's pricing and the page-cap disagreement recorded above. The open model underneath serves as chat completions, which is the family a row here belongs to. Whether a hosted row here exposes the raw task prompts, the layout-wrapped form, or both is a row-landing decision. This page does not predict it.

Benchmarks

This platform has run no measurements on GLM-OCR. There is nothing to measure against, since no lane serves it. Every number below is publisher-run, dated, and traced to its source. The sources are the technical report (arXiv 2603.10910v2, March 2026), accessed 2026-09-11, and the model card.

Publisher-run document-parsing results, with the comparison columns identified. In the report's own table, the Gemini-3-Pro and GPT-5.2 columns are printed in gray as reference-only and excluded from the best-score ranking. Every other column is an evaluated competitor.

The same table's key-information-extraction rows: GLM-OCR at 93.7 on Nanonets-KIE and 86.1 on Handwritten-KIE. Only the reference-only Gemini column sits above it on both.

Read the table with three honesty notes. First, the OmniDocBench v1.5 overall figure is 94.62 at full precision, and the report's sub-metrics split the win. GLM-OCR takes both table scores outright (93.96 Table TEDS, 96.39 Table TEDS-S). PaddleOCR-VL-1.5 edges text edit distance (0.035 against 0.040, lower better) and formula CDM (94.21 against 93.90). Second, MinerU 2.5 wins PubTabNet, and the report says so itself. Third, the headline number moves with the benchmark version. Z.ai's tables report 94.62 on v1.5. The independent OmniDocBench leaderboard maintained by the benchmark's authors carries GLM-OCR at 95.22 on v1.6, with PaddleOCR-VL-1.5 at 94.93 on the same board. Any score published without its benchmark version deserves distrust by default. The deeper caveat is independent. LlamaIndex's February 2026 critique argues two things. It argues OmniDocBench is saturating and its metric rigidity penalizes better general parsers. It also argues the long tail of real documents still breaks every top model. A table like this defines the evidence; your pages decide.

Getting started

1. Join through the console's invite flow. The platform is in an invite-only beta; one invitation opens the console, and wallet, keys, catalog, and billing history all sit behind it.
2. Cut a key once your account is active. Revoking one key never touches the others, so a leaked key costs a rotation, not the account. The wallet balance is the ceiling on spend; caps per key are a roadmap item, not a shipped one.
3. Watch the pricing page. No rate exists for this alias yet. When a row lands, the pricing page carries it, rendered from the catalog, and this page's price line fills in from the same source the same day.
4. Send a page when the row lands. Put your key in KEY, take the curl tab, and push one page image through. If you need parse-mode volume sooner, the local path above is real and open.

The parsing family page maps the platform's document routes, including the archival and print OCR lanes. Both are coming soon, with no date promised. The models index shows where every row stands.