0.9B，在千亿参数扎堆的大模型时代，几乎是个「玩具级」的数字。可就是这样一个不足十亿参数的小模型，在文档解析基准 OmniDocBench v1.5 的厂商自报成绩里拿下了 94.62 的总分，高于 Gemini-3 Pro 的 90.33 和 GPT-4o 的 75.02，而官方给出的成本约为传统 OCR 方案的十分之一。它就是智谱在 2026 年 2 月 3 日宣布发布并开源的 GLM-OCR，定位「小尺寸、高精度」，GitHub 仓库见 zai-org/GLM-OCR。仓库地址：github.com/zai-org/GLM-OCR。
小模型登顶，成色几何？这篇深评把许可证、架构、性能口径、短板和上手路径逐一拆开来看。
先交代本批分工：OCR 三篇同批发布，横评篇负责六款开源 OCR 的选型对比（见六款开源 OCR 横评：怎么选），SOP 篇负责 DeepSeek-OCR 的装机实操（见DeepSeek-OCR 本地部署实操），本文专注 GLM-OCR 单体深评——它为什么是当下最热开源 OCR、登顶成色如何、短板在哪、怎么用起来。想先横向比一遍再做决定的读者，可以搭配另两篇一起看。
一、发布与仓库：小尺寸、高精度
按官方口径，GLM-OCR 的目标很直接：把文档解析的精度做到第一梯队，同时把部署与推理成本压到传统 OCR 方案的约十分之一。发布当天即开源：模型权重放在 Hugging Face 的 zai-org/GLM-OCR（BF16 精度），国内用户可以在魔搭社区的 ZhipuAI/GLM-OCR 下载；技术报告以 arXiv 2603.10910（v1，2026 年 3 月 11 日）的形式放出。
顺手给一组热度参考（均为二手口径）：HF 下载量 2026 年 2 月底已超过 145 万，到 2026 年 8 月口径月均下载约 380 万；Ollama 侧约半年累计 650 万次拉取，进入全库 Top25；GitHub stars 截至 2026 年 8 月约 7.2k。对一个 0.9B 的垂直模型来说，这个起量速度相当罕见——也解释了为什么「当下最热开源 OCR」这个头衔它接得住。
二、许可证：一份仓库，三张许可
这是很多二手报道写错的地方。不少媒体在转载时只标了一个「MIT」，但按官方 README 的逐字表述，GLM-OCR 的许可是三方拆分：仓库代码采用 Apache License 2.0；GLM-OCR 模型权重采用 MIT License；布局组件 PP-DocLayoutV3 采用 Apache License 2.0——而且用户须同时遵守两者。
换句话说，你用这个模型时，权重侧的 MIT、代码侧的 Apache 2.0、布局组件那一份 Apache 2.0 同时在列，缺一条都不算合规。好消息是三张许可全部宽松，没有营收门槛、没有附加限制，商用基本无忧；只是接入前最好把三份 LICENSE 原文都过一遍，别只看二手媒体的一句「MIT 协议」。想系统了解各家开源权重许可证差异的，可以看站内旧文开源权重许可证横评。
三、架构：0.4B 的眼睛，0.5B 的大脑，加一条快车道
GLM-OCR 的 0.9B 总参数由三部分组成：0.4B 的 CogViT 视觉编码器、一个带 token 降采样的轻量跨模态连接器，以及 0.5B 的 GLM 语言解码器。视觉侧负责「看」，语言侧负责把看到的内容转成结构化文本，中间的连接器负责压缩视觉 token 的数量。
识别流程走的是两阶段流水线：先用 PP-DocLayout-V3 做版面分析，把整页切成标题、正文、表格、公式等区域，再对各区域并行识别。这和整页从左到右「一条龙」式的识别路线不同——先切后认的好处是表格、公式这类结构化内容不会被当成普通文本串着读，结构还原更稳；代价则是多一道版面分析工序，错误会在区域切分阶段向下传导。
速度上有个关键设计：MTP 多 token 预测。训练时每步预测 10 个 token，推理时平均每步 5.2 个，官方口径吞吐较标准自回归提升约 50%。训练分四阶段：先是 MIM 加 CLIP 的预训练，随后引入 MTP，再做 SFT，最后用 GRPO 做强化学习——奖励信号用的是编辑距离、CDM、TEDS 和字段级 F1，全部直接对齐 OCR 的评价指标。小模型能把分数做上去，很大程度靠的就是这套「用评测指标当奖励」的对齐方式。
使用模式上有三种识别：Text（纯文本）、Formula（输出 LaTeX）、Table（输出 Markdown 或 HTML），外加按 JSON schema 定义字段做信息抽取。文档解析的高频诉求基本都覆盖了：论文里的公式想进 LaTeX 编辑器，报表想进下游数据库，杂乱的合同想按字段抽成结构化数据，都对应得上。
把三个部分放回参数预算里看，这个分配思路其实很「抠」：0.4B 给视觉，0.5B 给语言，连接器几乎不计参数——每一段参数都花在 OCR 真正需要的环节，没有一个通用大模型那种「什么都会一点」的冗余。这也意味着它放弃了很多能力来换取部署密度：单张消费级显卡可以同时塞下多个副本，批处理场景的单位页成本能压得非常低。
四、性能：94.62 的成色与三条裁决
先上表。下表数字出自 GLM-OCR 官方技术报告（arXiv 2603.10910）的 Table 4，基准为 OmniDocBench v1.5，注意表内所有成绩均为各厂商自报口径：
| 模型 | OmniDocBench v1.5 总分 |
|---|---|
| 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 自身的分项：Text Edit 0.040、Formula CDM 93.90、Table TEDS 93.96、TEDS-S 96.39、Reading Order Edit 0.044。这里要提一句指标方向：Edit 越低越好（0.040 意味着文本错误率约 4%），CDM、TEDS 越高越好。在这张表内，GLM-OCR 的总分和两项表格指标（TEDS 与 TEDS-S）都是最高；不过 PaddleOCR-VL-1.5 的 Text 与 Formula 分项略优于 GLM-OCR，胜负并非一边倒。
表里还有一个值得驻足的对比：GLM-OCR 只有 0.9B 参数，而表中的 Qwen3-VL-235B 是两千多亿参数的通用视觉大模型——参数差了两百多倍，分数反倒是 94.62 对 89.15。这个反差是「专用小模型 vs 通用大模型」在垂直任务上的典型剧本，也是榜单效应争议的核心：专用模型针对性优化评测任务，天然占便宜，但这并不等于它在你的真实数据上也占便宜。
三个容易踩坑的口径问题，必须说清楚：
其一，「开源最高」「登顶」这类说法，必须限定在「发布时点加 OmniDocBench v1.5 榜」之内。2026 年 5 月百度已发布 PaddleOCR-VL-1.6，自报总分 96.33（出自 v1.6 榜），不同版本的榜单分数不可直接对比，所以「GLM-OCR 至今仍是开源第一」并不成立。
其二，HunyuanOCR（自报 94.10）与 DeepSeek-OCR 2（自报 91.09）的成绩是各厂商自行报告的，并不在上述同一张表内，不构成同版本对照，不能写成「GLM-OCR 同尺寸超越了它们」。
其三，一个有意思的口径矛盾：官方宣传语说 GLM-OCR「性能接近 Gemini-3-Pro」，但按官方自己给出的表格，94.62 明显高于 Gemini-3 Pro 的 90.33——明明是反超，宣传却用了「接近」。反过来的保守话术在这个行业里不多见，也算给这份榜单的可信度加了点分。
五、吞吐与资源：快，而且跑得动
吞吐方面，官方口径为相同硬件、单副本单并发（未披露 GPU 型号）：PDF 解析 1.86 页/秒，单张图片 0.67 张/秒；作为对照，PaddleOCR-VL-1.5 在同口径下为 1.22 页/秒与 0.39 张/秒。两项都领先，PDF 场景优势更明显。换算成生产语言：1.86 页/秒意味着单副本一小时约 6700 页，处理一个十万页的档案库大约 15 个小时；同样的量给 PaddleOCR-VL-1.5 要接近 23 个小时。当然，这是官方口径的实验室数字，真实批量任务的吞吐会受预处理、IO 和后处理拖累，实际值要自己压测。
显存方面，官方 README 与技术报告均未公布最低显存要求，这一点要如实说。社区实测口径不一：有「4GB 显卡跑起来还有余量」的说法，也有「BF16 精度最小 8GB」「量化版 4GB」的实测。综合下来可以记为：官方未公布，社区实测约 4 至 8GB，视精度与上下文长度而定。上下文长度同样存在两说——66K（TheRouter）与 128K（Ollama 库页），官方未明确，此处并列，不替读者裁决。
六、短板与批评：榜单之外的部分
先说任务面：GLM-OCR 只做文档解析和信息抽取，不是通用视觉语言模型。看图问答、图像理解、截图转代码这类需求，别指望它。
再说精度短板。第三方博主 lilting.ch 的复测（二手口径）给出了一组更细的分项：表头页脚 95.8%、票据关键信息抽取 94.5%、印章 90.5%、手写 87.0%、代码文档 84.7%、多栏 76.7%，而老旧扫描件只有 37.6%，多语言场景 69.3——博主对多语言能力的自述是「仍让我不安」。把这份复测和官方榜单放在一起看，结论很清晰：规整的现代印刷文档是它的主场，老旧扫描件和冷门语种是明显的坑，生产环境里遇到这两类素材务必先抽样验证。
社区质疑也值得记录。Hacker News 上的讨论集中在两点：一是小模型「超越 Gemini 3」是否存在榜单效应——OmniDocBench 主要覆盖规整文档，各家自报成绩的预处理与后处理口径并不统一，分数差异未必全部来自模型能力；二是从架构推断（注意，这是推断而非官方结论），0.5B 的语言解码器自带语言先验，对中文和表格的语义还原有利，但这恰恰也是幻觉风险的来源——模型可能「脑补」出图里并不存在的内容，对准确率要求极高的票据、合同场景要留后验校验。
另有一条实操建议来自 HN 用户 philipkglass：官方后处理会融合、改写版面数据。如果你要调试布局，建议保存原始输出、自己写后处理逻辑，而不是直接信任封装后的结果。
把这些短板收拢成一句选型判断：GLM-OCR 适合的是「现代印刷文档、中文为主、追求结构与版面还原」的主力解析场景；如果你的语料是几十年前的破损扫描件，或者以小语种为主，它当前的分数并不能给你足够的信心，先跑自有样本再定，别只看总分。
七、上手指南与生态
官方 SDK 的最小调用只需三行，以 pip install glmocr 安装：
from glmocr import parse
result = parse("document.pdf")
result.save(output_dir="./results")自建服务的话，主流推理框架都已经跟上：vLLM 从 v0.19.0 起支持，MTP 走 speculative 配置；SGLang 从 v0.5.10 起支持，投机采样用 NEXTN。vLLM 的启动命令如下（官方 README 逐字）：
vllm serve zai-org/GLM-OCR --port 8080 --speculative-config '{"method": "mtp", "num_speculative_tokens": 3}' --served-model-name glm-ocrSGLang 对应的启动命令：
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-ocr最省事的路径是 Ollama：模型体积 2.2GB，q8_0 量化版约 1.6GB，一条命令拉起（注意需要较新版本）：
ollama run glm-ocr一个二手实测踩过的坑：视觉请求建议走 Ollama 原生的 /api/generate 端点，而不是 OpenAI 兼容端点。此外，mlx-vlm 让 Apple Silicon 用户可以本地跑；llama.cpp 与 LM Studio 也有社区转换的 ggml-org/GLM-OCR-GGUF 可用。
四条路径怎么选：本机试用、个人小批量，用 Ollama 或 SDK 直连最省心；要进生产流水线、讲究吞吐与并发，vLLM 和 SGLang 二选一，两者都吃到了 MTP 投机采样的加速红利；Mac 用户本地玩，走 mlx-vlm。
不想自己部署的话，官方 API 定价为输入输出同价 0.2 元/百万 tokens（官方通稿口径），小规模使用成本几乎可以忽略不计。
八、和 DeepSeek-OCR 怎么选
GLM-OCR 与 DeepSeek-OCR 2（约 3B，采用 Visual Causal Flow）代表了开源 OCR 的两条技术路线。后者走「压缩路线」：把整页压成极少的视觉 token 换吞吐，适合海量 PDF 转 Markdown 的流水线；GLM-OCR 走「切区域并行识别」：保住结构与版面的还原精度，代价是 token 消耗更高。一句话选型：吞吐优先选 DeepSeek-OCR，结构还原优先选 GLM-OCR；如果两者都重，最直接的办法是拿各自的原始输出跑一遍自己的样本集，用字段级准确率说话。两者装机的具体差异和坑，可以对照本批 SOP 篇的实测。
FAQ
Q1：GLM-OCR 需要多少显存？
官方未公布最低显存；社区实测约 4 至 8GB，视精度与上下文长度而定，量化版有 4GB 跑通的实测反馈。
Q2：GLM-OCR 用什么许可证，能商用吗？
三方拆分：仓库代码 Apache License 2.0、模型权重 MIT、布局组件 PP-DocLayoutV3 Apache License 2.0，用户须同时遵守；三份许可全部宽松、无营收门槛，可商用。
Q3：GLM-OCR 真的超越了 Gemini-3-Pro 吗？
在官方自报的 OmniDocBench v1.5 表内，GLM-OCR 总分 94.62 高于 Gemini-3 Pro 的 90.33，实际是超越而非「接近」；但表内均为厂商自报口径，且不同版本的榜单分数不可直接对比。
Q4：GLM-OCR 支持哪些任务？
三种识别模式（Text 纯文本、Formula 转 LaTeX、Table 转 Markdown 或 HTML），外加按 JSON schema 的信息抽取；仅覆盖文档解析与信息抽取，不是通用视觉模型，看图问答这类需求需要另找通用 VLM。
Q5：GLM-OCR 和 DeepSeek-OCR 该选哪个？
重吞吐、大批量 PDF 转 Markdown 选 DeepSeek-OCR 的压缩路线；重结构还原、表格与版面精度选 GLM-OCR 的切区域识别。