2026年3月，智谱AI联合清华大学在arXiv上挂出了一篇技术报告，主角叫GLM-OCR，一个文档解析模型，参数量0.9B。
PDF链接：https://arxiv.org/pdf/2603.10910v2
0.9B是什么概念。Qwen3-VL，235B参数。GLM-OCR大概是它的两百六十分之一。就这个体格，GLM-OCR在OmniDocBench v1.5上拿了94.62分。作为参照，235B的Qwen3-VL是89.15分，差了5.47分。
先看看它到底考了什么。
先说OmniDocBench v1.5这个榜单。它是目前文档解析领域最权威的综合评测基准之一，1651页真实文档，覆盖10种文档类型、5种页面布局、5种语言。不是那种实验室里精心清洗过的数据集，是贴近真实场景的硬骨头。论文里一共拉了34个模型同场竞技，从几B到几百B参数的都有，GLM-OCR总分排第一。
更关键的是，GLM-OCR在表格重建这个子项上的表现也很突出，TEDS得分93.96，TEDS-S得分96.39。
很多朋友可能不知道，表格重建是文档解析里最难的子任务之一。不光要识别表格里的文字，还得还原表格的结构，哪行哪列怎么合并，边框在哪里，跨页表格怎么接。这个维度的分数高，说明GLM-OCR不只是文字识别强，对文档结构的理解也很到位。
这是论文里的Table 4，34个模型的完整对比数据。感兴趣的可以放大看看各维度的具体分数。
好，OmniDocBench的情况就是这样。但只有一个榜单，说服力还不太够。其他数据集表现怎么样？
其实GLM-OCR在公开benchmark上的表现也挺全面的。论文里测了7个公开数据集，涵盖文本识别、公式识别、表格识别、信息提取等核心任务。
坦率的讲，我看数据的时候专门留意了一下。7个数据集里，GLM-OCR拿了5个第一、1个第二。OCRBench上94.0分，Nanonets-KIE上93.7分，Handwritten-KIE上86.1分。这些不是什么野鸡数据集，都是各自细分领域有头有脸的评测基准。
这是Table 3的完整数据。整体来看，各维度的分数都比较均衡。
不过话说回来，光看分数，读者可能还有个疑问没解开。0.9B的小模型，是怎么做到这些成绩的？数据摆在这里了，但背后的原因是什么？
这个问题才是这篇报告真正有意思的地方。
GLM-OCR能做到这些，靠的不只是模型本身的参数，还有两个关键设计。一个是MTP ，多Token预测。一个是两阶段流水线架构。咱先说MTP。
传统的大语言模型解码，是一个Token一个Token往外蹦的。生成了一个Token，才能生成下一个。这就像你打字，一个字一个字地敲，速度上限就在那里。
MTP干的事情，是让模型一次预测多个Token。不是一个个蹦，而是一把抓。论文里说，这个机制能带来大约50%的解码加速。
50%的加速不是个小数字。反映到实际吞吐量上，差距更直观。论文Table 6里测了吞吐量，GLM-OCR每秒能处理1.86页文档。PaddleOCR是1.22页，MinerU是0.48页。
GLM-OCR的吞吐量是MinerU的接近4倍。如果是大规模文档处理场景，这个差距直接体现为服务器成本和响应时间。
回到主线，MTP解决了快的问题。但光快还不够，还得准。这就涉及到架构选择了。
GLM-OCR没有走端到端的路线，而是用了两阶段流水线。
怎么说呢，文档解析领域一直有两条技术路线。一条是端到端，把图片喂进去，直接出结果，一个模型搞定一切。另一条是流水线，先把文档拆成块，再分别识别，最后合并输出。
GLM-OCR选了后者。第一阶段用PP-DocLayout-V3做版面分析，把一页文档拆成文本区域、表格区域、图片区域等。第二阶段对这些区域做并行识别，最后合并输出。
其实吧，流水线方案有个天然好处。每个阶段可以单独优化，版面分析用好用的版面分析模型，识别用好的识别模型，各司其职。而且并行识别能把速度拉起来，配合MTP的加速，吞吐量自然就上去了。
但流水线也有代价，这个后面再说。
接下来是训练。一个0.9B的模型，是怎么训练出来的？
论文里把训练分成了四个阶段。
第一阶段训练视觉编码器，先把模型的「眼睛」练好，让它能看懂图片里的文字和结构。
第二阶段预训练，用大规模文档数据让模型建立基础识别能力。第三阶段SFT，监督微调，用高质量标注数据精调。第四阶段RL，强化学习，用GRPO算法驱动模型在结构化输出上进一步改进。
GRPO的细节咱就不展开了，它是个通用的强化学习算法，不是这篇论文的独创。你只需要知道，这个阶段让模型在表格重建、公式识别这些结构化任务上有了质的提升。四个阶段走完，一个0.9B的模型就有了不错的底子。
但训练配方只告诉你怎么练出来的，真正在业务场景里好不好用，还得看实际表现。
论文里有个in-house benchmark，测了6项真实业务场景任务。这一段是我觉得整篇报告里最有意思的部分。
印章识别，GLM-OCR拿到90.5分。
你想想看，其他模型在这个项目上最高也就42.2分。90.5和42.2，差距确实很大。印章这东西，红圈圈里面几个字，变形、遮挡、颜色干扰，一直是OCR领域的难题。GLM-OCR能在这个项目上拿到90.5，说明它不只是会读印刷体，对复杂视觉场景的理解也很到位。
多语言文本识别，69.3分。PaddleOCR-VL-1.5是54.8分，差了14.5分。代码文档84.7分，真实表格91.5分。
这是Table 5的完整数据。
顺便提一下，论文里还介绍了结构化文档处理的两种用法。一种是SDK模式，版面解析、多模态识别、结构化输出三步走，适合需要完整文档解析的场景。另一种是直接调基础模型，按文本识别、表格识别、公式识别、KIE这四类任务分别调用，适合只需要某一类功能的场景。感兴趣的话可以翻翻论文第5节。
反正我觉得，in-house benchmark的成绩比公开榜单更能说明问题。因为公开榜单的数据集再怎么贴近真实，也有一定的考试导向。而in-house是团队自己搭的业务场景测试，更接近实际使用中会遇到的文档类型。
分数看完了，机制也清楚了，业务场景的表现也不错。那这是不是意味着GLM-OCR就完美了呢？
当然不是。GLM-OCR也有局限性。
手写文本识别，GLM-OCR落后Gemini-3 Pro大约3分。多语言识别，落后Gemini-3 Pro大约17分。KIE任务，落后8.4分。
3分可能还能接受，但17分和8.4分，就是实打实的差距了。。。
这一点其实也不意外。0.9B的参数量，能覆盖的语料和场景本身就有限。大模型靠参数量堆出来的泛化能力，不是小模型靠架构优化就能完全弥补的。在需要强泛化的手写、多语言、KIE这些场景上，Gemini-3 Pro这种顶级大模型还是有优势。
还有一个架构层面的局限。前面说了，GLM-OCR用的是两阶段流水线。流水线的天然问题是误差传播，第一阶段版面分析出了错，第二阶段的识别就会跟着错。端到端模型不存在这个问题，因为它是一步到位的。这是GLM-OCR选择流水线路线必须承担的代价。
所以GLM-OCR的优势，是有边界的。在印刷体文档、表格重建、印章识别这些场景上，它确实做到了小模型打出好成绩。但在需要强泛化的手写、多语言、KIE场景上，差距还在。
还有一层时间上的边界得说一下。GLM-OCR这篇报告是2026年3月发的，到今天4个月过去了，OCR这个赛道又冒出了不少新东西。比如百度6月开源的Unlimited OCR，基准也升级到了v1.6。GLM-OCR的94.62分是论文里v1.5榜单上的成绩，后续被刷新也是正常的事。
最后说几个实用信息。GLM-OCR已经在GitHub和HuggingFace上开源了，可以直接拉下来用。MaaS API的定价是0.2元每百万Token，算下来一块钱能处理大约2000页A4文档。智谱AI和清华大学联合出品，国产自研，从头到尾都是自己的技术栈。
我自己的感受是，GLM-OCR这篇报告的价值不在于证明小模型一定能超越大模型，而在于证明了，在特定任务上，选对架构、用对训练方法、把工程做到位，小模型完全可以打出超出参数量级别的表现。
0.9B不是终点，但它至少告诉我们，文档解析这个赛道，不一定非得靠堆参数。
感谢阅读。点个关注，不迷路，我们后续会持续跟进文档解析、OCR领域的前沿技术动态，第一时间为你解读。