微信扫码
添加专属顾问
我要投稿
GLM-OCR技术报告重磅发布,揭秘这款高效多模态模型如何以0.9B参数实现SOTA文档理解能力。核心内容: 1. GLM-OCR的架构设计与核心创新点 2. 在复杂文档场景中的领先性能表现 3. 面向生产环境的部署优势与实践案例
自 2 月初开源以来,GLM-OCR 受到了全球开发者、企业的广泛喜爱与集成,目前已在 Hugging Face 上获得 360 万下载,同时也衍生出了一些 Skills 和 App。
今天,我们正式发布 GLM-OCR 技术报告,将模型「SOTA 文档理解能力」背后的技术细节,一一公开分享。欢迎大家广泛测试与集成。
技术报告:https://arxiv.org/pdf/2603.10910
Hugging Face:https://github.com/zai-org/GLM-OCR
GitHub:https://huggingface.co/zai-org/GLM-OCR
体验地址:https://ocr.z.ai/
GLM-OCR 是一款高效的 0.9B 参数紧凑型多模态模型,专为真实场景下的文档理解而设计,兼具强大识别性能、高吞吐和低延迟推理,在代码文档、真实场景表格、手写体、多语言、印章识别、票据提取等众多真实场景中均取得领先性能。
值得一提的是,紧凑的架构和结构化生成能力,也使得 GLM-OCR 既适用于边缘端部署,也适用于大规模生产系统。
文档理解是现代信息系统的核心能力,支持从金融报告、科学文章、合同和发票等视觉丰富、版面密集的文档中提取和结构化知识。
传统 OCR 系统主要专注于纯文本转录,依赖多阶段流水线和手工规则进行版面解析与下游信息提取。这些方法在简单场景下虽然有效,但在面对复杂版面、多样化文档格式和真实生产需求时往往表现较差。
近年来,多模态大语言模型(MLLMs)将视觉感知与语言理解统一在单一框架内,显著提升了文档理解性能。然而,其庞大的模型尺寸和自回归解码方法导致计算成本高、推理速度慢、内存消耗大,在高并发或边缘环境下进行大规模部署面临较大挑战。
在实际生产系统中,文档智能解决方案必须同时满足:
(1)具备处理对表格、公式、代码和印章等复杂内容的强大性能;(2)高吞吐、低延迟的推理性能;(3)灵活集成与领域适应性。
GLM-OCR 正是为了在统一的多模态框架内满足上述系统级需求而开发的。
图|GLM-OCR 框架的整体架构与工作流程。该系统支持两项主要任务。文档解析:结合版面检测与区域裁剪,生成结构化的 Markdown 和 JSON 输出;关键信息提取:根据输入的视觉提示,直接提取结构化的 JSON 数据。
接下来,我们将详细介绍 GLM-OCR 框架(涵盖架构组件、任务表述与训练策略)的整体设计,涉及以下方面:
为全面理解 GLM-OCR 的架构,我们首先阐述 GLM-OCR 背后的主要设计理念,随后详细描述模型结构及其在不同任务中的执行方式。
1)设计动机
在文档理解方面,我们的架构设计遵循三项基本观察与目标:
2)架构 我们的系统以 GLM-OCR Core 为中心,遵循视觉-语言生成范式。核心模型包括:
编码器生成的视觉特征被投影至语言嵌入空间,并作为前缀 token 输入解码器。在解码过程中,模型以自回归方式预测结构化输出。
为提升解码效率和结构一致性,我们引入了多 token 预测(MTP)机制。除主预测头外,我们附加了 k 个共享参数的辅助预测头,用于同时预测后续 k 个 token。这些预测头共享相同参数,但被训练为对不同的未来偏移量进行建模。在推理时,模型每步可生成多个 token,在降低延迟的同时促进更好的局部结构一致性。
该框架在统一的生成式表述下支持两项主要任务:
任务1:文档解析。给定一张文档图像,流水线首先使用 PP-DocLayout-V3 执行版面分析,将文档分解为语义连贯的区域(如段落、表格、公式)。每个区域由 GLM-OCR 核心独立处理,生成的区域级输出随后由合并与后处理模块进行聚合,恢复阅读顺序并生成 Markdown 和 JSON 格式的结构化输出。这种模块化设计降低了幻觉风险,提升了对复杂版面的鲁棒性,并支持文档区域的并行处理。
任务2:关键信息提取。对于关键信息提取,完整的文档图像连同任务特定的文本提示(如指示模型以 JSON 格式提取发票字段)直接输入 GLM-OCR Core。与文档解析不同,该任务不依赖显式的版面裁剪,而是让模型在提示引导下隐式地关注相关视觉区域。
两项任务被统一为条件结构化生成问题,仅在预处理策略和提示规范上有所差异。
GLM-OCR 的训练过程分为若干独立阶段,系统性地从视觉-语言对齐逐步推进至任务特定精炼与强化学习,各阶段所使用的主要数据类型见下表。
表|GLM-OCR 各阶段训练数据。
第一阶段:视觉编码器训练。我们首先使用大规模图像-文本和 grounding 数据对视觉编码器进行训练,以建立强大的视觉表征能力。在此阶段,模型在规模达数百亿图像-文本对的数据集上进行训练,采用 MIM 与 CLIP 的双重目标函数。此外,我们还利用内部更大参数量的 ViT 进行知识蒸馏,以进一步增强编码器的特征提取能力。
第二阶段:视觉-语言预训练。我们首先将 ViT 接入 GLM-0.5B,并在图像-文本、文档解析、grounding 和视觉问答数据上对完整模型进行联合预训练,以对齐多模态表征;随后引入 MTP 目标,使解码器适应高效的结构化生成。
第三阶段:监督微调(SFT)。我们在精心整理的OCR数据集上对模型进行微调,涵盖文本识别、公式转录、表格结构还原和关键信息提取等任务,旨在使模型在真实文档分布下专注于高精度结构化输出。MTP 保持启用状态,以确保训练与推理的一致性。数据混合经过平衡处理,以防止对任何单一子任务过拟合,同时保持跨任务泛化能力。
第四阶段:强化学习(RL)。我们采用 GRPO 算法来提升结构化输出的可靠性和任务特定准确率。训练样本通过对 SFT 模型进行 rollout 生成,经自动评估后按难度分层,构建梯度优化集。奖励函数具有任务感知能力,综合了基于准确率的指标与结构验证信号,具体设计如下表。
表|第四阶段强化学习训练中的奖励函数设计。
我们将 GLM-OCR 的性能与当前 SOTA 流水线工具、通用视觉-语言模型(VLMs)及专业 OCR 视觉-语言模型进行了对比评估。为提供全面的评估结果,评估分为标准公开基准测试和自定义内部基准测试两部分。
我们首先在主流公开数据集上对 GLM-OCR 进行了评估,涉及文档解析、关键信息提取等任务。
整体基准性能。如下表所示,GLM-OCR 在大多数标准数据集上展现出 SOTA 性能。在文档解析方面,模型在 OmniDocBench v1.5(94.6)、OCRBench Text(94.0)、UniMERNet(96.5)和 TEDS_TEST(86.0)上均取得最高分数,在 PubTabNet(85.2)上也排名第二位。此外,GLM-OCR 在关键信息提取领域实现了新的 SOTA 水平,在 Nanonets-KIE(93.7)和 Handwritten-KIE(86.1)上超越所有其他开源模型,缩小了与 Gemini-3-Pro 等闭源模型之间的差距。
表|各 OCR 模型性能对比。Gemini-3-Pro 和 GPT-5.2-2025-12-11 的结果以灰色显示,仅供参考,不纳入最优分数排名。评估模型中的最佳结果以粗体标注。
OmniDocBench v1.5 分析。为更深入地理解模型的文档解析能力,我们对 OmniDocBench v1.5 的结果进行了细粒度分解,对比了流水线工具、不同规模的通用 VLM 以及专业 VLM。
值得注意的是,尽管 GLM-OCR 仅有 0.9B 参数,却取得了最高的综合得分(94.62),不仅超越了 PaddleOCR-VL-1.5(94.50)和 MinerU2.5(90.67)等专业模型,还超过了 Qwen3-VL-235B(89.15)和 Gemini-3 Pro(90.33)等大规模通用 VLM。
表|与流水线工具、通用 VLM 及专业 VLM 在 OmniDocBench v1.5 上的性能对比。
子指标分解结果显示,模型在表格结构还原方面表现突出,在表格识别上取得绝对最优成绩,在 Table TEDS 上得分 93.96,在 Table TEDS-S 上得分 96.39。尽管 PaddleOCR-VL-1.5 在 TextEdit 和 Formula CDM 上略领先于 GLM-OCR,但 GLM-OCR 的出色表格解析能力使其整体最优,证明了专业化、参数高效的架构在复杂文档解析中可以媲美甚至超越依赖大规模参数的模型。
为评估 GLM-OCR 在高度复杂的真实工业场景中的鲁棒性,我们在一套自定义内部基准测试上进行了评估,涵盖代码文档解析、真实场景表格提取、手写文字识别、多语言文本处理、印章识别和票据关键信息提取。
表|在自定义真实场景下的性能对比。Gemini-3-Pro 和 GPT-5.2-2025-12-11 的结果以灰色显示,仅供参考,不纳入最优分数排名。评估模型中的最佳结果以粗体标注。
如上表所示,GLM-OCR 在与开放权重模型的对比中,在 6 项评估类别中的 5 项取得 SOTA 分数。更为值得关注的是,GLM-OCR 在极具挑战性的细分领域中展现出了明显优势:
尽管 PaddleOCR-VL-1.5 在手写文字识别上略占优势,但 GLM-OCR 十分高效。尤为关键的是,在票据关键信息提取等实际应用任务中,GLM-OCR(94.5)甚至超越了 GPT-5.2(83.5)等商业专有模型。
这些内部测试结果验证了 GLM-OCR 并非仅针对学术数据集进行优化,而是具备在真实 OCR 部署中应对噪声多变条件的强大泛化能力。
了解更多细节及典型应用场景,请查看:
我们还对 GLM-OCR 在本地化推理和资源受限环境下进行了高度优化,支持在 vLLM、SGLang 和 Ollama 等主流框架上高效部署。为便于无缝集成,我们提供了一套完整的 SDK,支持端到端的文档解析工作流。
为评估运营效率,我们对多种 OCR 流水线进行了吞吐量对比分析。在相同硬件配置和测试条件下,我们评估了图像和 PDF 输入的解析速度与 Markdown 导出速度。如下表所示,GLM-OCR 性能优于同类方法,PDF文档吞吐量达到 1.86 页/秒,独立图像文件吞吐量可达 0.67 张/秒。
表|不同 OCR 模型在图像与 PDF 输入下的吞吐量对比。
在云端部署方面,大家可以通过 MaaS API 访问 GLM-OCR。
我们对输入和输出 token 采用高度经济实惠的统一定价模式,每百万 token 仅需 0.2 元,1 元即可处理约 2000 张 A4 尺寸扫描图像或 200 份简单版面 PDF(每份 10 页),处理成本约为传统 OCR 方案的 1/10。
详情参考:https://docs.bigmodel.cn/cn/guide/models/vlm/glm-ocr
在需要特定领域适配或提升任务性能的场景中,GLM-OCR 支持通过 LLaMA-Factory 框架直接进行微调。微调完整教程和配置指南已发布于官方代码仓库中。
仓库链接:https://github.com/zai-org/GLM-OCR/blob/main/examples/finetune/README.md
尽管 GLM-OCR 在多种基准测试和实际场景中展现出强大性能,但依然存在一些局限性。
例如,当前由版面分析与区域级识别组成的两阶段流水线可能引入误差传播。在版面检测不准确的情况下,下游识别性能可能随之下降。此外,涉及跨页依赖或不规则多栏结构的复杂版面,可能导致阅读顺序重建不够完善。
同时,模型性能也受训练数据分布和多样性的影响。在极低分辨率或严重失真的文档、高度复杂的数学表达式、密集或不规则的表格结构和训练语料中代表性不足的语言等场景中可能出现性能下降。
而且,作为生成式模型,GLM-OCR 在格式化行为上可能表现出轻微的随机波动,尤其体现在换行与空白符处理方面。尽管强化学习和结构化监督在一定程度上缓解了这一问题,但仍无法完全保证严格的格式一致性。
此外,尽管模型支持基于提示的关键信息提取(KIE),但提取准确率依赖于提示的规范程度和模式定义的清晰度。在字段边界隐含或模糊的复杂表单中,可能出现输出不完整或冗余的情况。
在未来的研究工作中,我们将聚焦于提升在极端版面复杂度下的鲁棒性、增强多语言覆盖范围等工作,以及强化结构化输出一致性,从而进一步降低下游集成成本。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-03-18
Midjourney V8 正式上线:高清模式、文字无错、生成速度提升5倍
2026-03-15
我复刻了 Claude 刚发布的生成式 UI 交互!
2026-03-12
Gemini Embedding 2把多模态信息整合同一向量空间了,还需要多向量列吗?
2026-03-11
Gemini Embedding 2:首个原生五模态 embedding 模型
2026-03-11
Google 发布首个全模态 Embedding 2 模型,文本图片音视频 PDF 统一到一个向量空间
2026-03-11
谷歌首个原生多模态向量模型发布:Agent 可以用文字搜图片、用图片搜视频了...
2026-03-05
零帧起手 Codex × Figma 双向工作流实操
2026-02-27
NanoBanana 2.0 来了, 对比前一代和即梦 5.0 lite,它依旧强的离谱
2026-01-10
2026-01-05
2026-02-12
2026-01-16
2026-01-27
2026-02-12
2025-12-31
2026-01-22
2026-02-27
2026-03-11
2026-03-12
2025-12-31
2025-08-04
2025-05-26
2025-05-13
2025-04-08
2025-04-05
2025-03-30