智谱 GLM-OCR：0.9B 小模型登顶 OCR 榜单，3月起还能一行代码接入 Agent

文档 OCR 领域正在经历一场参数量军备竞赛——Qwen3-VL 用 235B 参数拿到 89 分Gemini-3 Pro 拿到 90 分。但 OmniDocBench V1.5 榜单的第一名 GLM-OCR参数量只有 0.9B。就在上周3 月 11-12 日智谱连续发布了两个更新技术报告上线 arXiv揭示了 Multi-Token Prediction 每步预测 10 个 token、吞吐量提升约 50% 的机制以及全任务 GRPO 强化学习的完整设计SDK 新增 Agent Skill 模式一行代码即可将 GLM-OCR 接入 AI Agent 作为文档理解工具。本文先介绍刚上线的Agent Skill 集成方式然后深入拆解技术报告中的关键设计。一、Agent Skill让 OCR 成为 Agent 的工具AI Agent 在处理实际业务时经常需要理解文档——读合同、解析票据、提取表格数据。但 Agent 本身不擅长 OCR需要外接专门的工具来看文档。此前这意味着单独部署 OCR 服务、编写格式转换和调用胶水代码。Agent Skill 模式的价值在于把这个过程简化到一行代码Agent 传入文档GLM-OCR 返回结构化数据中间不需要额外配置。3 月 12 日的 SDK 更新v0.1.2新增了这一模式核心目标是让 GLM-OCR 可以被 AI Agent 或 MCP Server 零配置调用。最简集成方式import json import glmocr def ocr_tool(image_path: str) - str: Parse a document and return structured JSON. result glmocr.parse(image_path) return result.to_json()只需要在环境中设置GLMOCR_API_KEY不需要编写 YAML 配置文件。SDK 会自动走 MaaS 模式将请求转发到智谱云端 API 并返回结构化结果。两种运行模式模式是否需要 GPU适用场景MaaS不需要Agent 集成推荐云端处理Self-hosted需要数据敏感场景本地 vLLM/SGLang 部署当提供api_key但未指定mode时SDK 自动默认 MaaS 模式。配置优先级SDK 的配置解析遵循一个清晰的优先级链构造函数参数 环境变量 .env 文件 config.yaml 内置默认值Agent 可以通过构造函数参数覆盖各项设置不需要接触配置文件。所有环境变量使用GLMOCR_前缀如GLMOCR_API_KEY、GLMOCR_MODE。结果序列化PipelineResult提供三种输出方式方便 Agent 处理to_dict()— JSON 可序列化的 Python 字典to_json()— JSON 字符串save(output_dir)— 写入文件JSON Markdown 裁剪图片这个设计使 GLM-OCR 可以作为文档理解 Agent 的眼睛——Agent 负责决策和编排GLM-OCR 负责将文档转为结构化数据。图片来源于原论文二、模型架构CogViT GLM MTP图片来源于原论文技术报告揭示了 GLM-OCR 的完整架构设计。模型总参数量 0.9B由三个组件构成组件参数量职责CogViT 视觉编码器0.4B在数百亿级图文对上通过 MIM CLIP 双任务预训练并从更大的内部 ViT 蒸馏知识轻量跨模态连接器—token 下采样连接视觉与语言空间GLM-0.5B 语言解码器0.5B基于 ChatGLM生成 OCR 结果文本两阶段处理流水线系统分两个任务路径任务 1文档解析文档图像 → PP-DocLayout-V3版面检测 区域裁剪→ 各区域并行送入 GLM-OCR Core → 合并 后处理 → Markdown JSONPP-DocLayout-V3 将文档拆分为段落、表格、公式等区域各区域独立识别后按阅读顺序合并。并行处理降低了单次输入的复杂度也减少了幻觉风险。任务 2信息抽取KIE完整文档图像 JSON Schema 提示 → GLM-OCR Core → 结构化 JSON信息抽取跳过版面分析直接将完整图像和 JSON 格式要求一起送入模型。图片来源于原论文三、Multi-Token PredictionOCR 场景的加速策略MTP 是技术报告中最值得关注的设计。为什么 OCR 适合 MTP标准自回归解码每步只生成一个 token但 OCR 是确定性较强的任务——给定图像区域输出文本的不确定性远低于开放式对话。特别是结构化标记表格标签、Markdown 语法具有很强的局部依赖性适合一次预测多个 token。具体实现在主预测头之外附加 k 个共享参数的辅助预测头同时预测未来 k 个 token。关键设计训练时每步预测10 个 token推理时平均每步生成5.2 个 token吞吐量提升约50%内存开销辅助头共享参数额外 GPU 内存开销很低MTP 从预训练阶段引入贯穿 SFT 阶段。不只是加速技术报告指出 MTP 还有一个训练效益鼓励模型看得更远在生成结构化输出时产生更少的断裂标签和更稳定的格式。四、全任务强化学习GRPO 任务感知奖励GLM-OCR 在 SFT 之后加入了基于 GRPOGroup Relative Policy Optimization的强化学习阶段覆盖四类任务每类有专门设计的奖励函数任务准确性奖励额外约束文本识别归一化编辑距离重复惩罚公式识别CDM 分数结构有效性检查表格识别TEDS 分数标签闭合验证、结构解析信息抽取字段级 F1 分数JSON 解析验证、缺失/重复字段惩罚此外还有全局正则化重复率惩罚和结构异常惩罚。训练样本通过 SFT 模型 rollout 生成自动评估后按难度分层构建优化集。这种分层策略使 RL 训练更稳定避免在简单样本上浪费优化资源。五、Benchmark 详解OmniDocBench V1.5各维度逐项对比以下摘录 GLM-OCR 与几个关键对手在各维度上的数据模型参数量综合文本 Edit↓公式 CDM表格 TEDS阅读顺序 Edit↓GLM-OCR0.9B94.620.04093.9093.960.044PaddleOCR-VL-1.50.9B94.500.03594.2192.760.042Gemini-3 Pro—90.330.06589.1888.280.071Qwen3-VL235B89.150.06989.1888.140.068GPT-5.2—85.500.12386.1182.660.099dots.ocr3B88.410.04883.2286.780.053MinerU2.51.2B90.670.04788.4688.220.044几个值得注意的点GLM-OCR 与 PaddleOCR-VL-1.5 的竞争非常接近94.62 vs 94.50两者参数量相同0.9B但各有优劣——PaddleOCR-VL-1.5 在文本和公式上略优GLM-OCR 在表格上领先相比 Gemini-3 ProGLM-OCR 在文本、公式、表格三项均有明显优势阅读顺序接近同参数量级0.9B-3B的专用模型中GLM-OCR 综合得分最高实际场景测试除了公开基准技术报告还在内部测试集上做了评测覆盖代码文档、实际表格、手写体、多语言、印章、票据等场景场景GLM-OCRPaddleOCR-VL-1.5Gemini-3 Pro代码文档84.775.886.9实际表格91.586.190.6手写体87.087.490.0多语言69.354.886.2印章识别90.542.291.3票据 KIE94.5—97.3在印章识别上GLM-OCR90.5大幅超越 PaddleOCR-VL-1.542.2与 Gemini-3 Pro91.3接近。多语言场景支持中英法西俄德日韩 8 种语言也有较大优势。图片来源于原论文处理速度模型图片页/秒PDF页/秒GLM-OCR0.671.86PaddleOCR-VL-1.50.391.22Deepseek-OCR20.32—MinerU2.50.180.48dots.ocr0.10—GLM-OCR 的处理速度在同类模型中最快PDF 处理速度约为 PaddleOCR-VL-1.5 的 1.5 倍MinerU2.5 的 3.9 倍。六、总结与思考GLM-OCR 技术报告最有价值的两个贡献MTP 机制在 OCR 场景的验证——利用 OCR 任务的确定性特点通过共享参数的多头预测实现约 50% 的吞吐提升且不显著增加内存开销。这个思路对其他确定性较强的视觉理解任务也有参考价值。全任务 RL 的奖励设计——针对文本/公式/表格/KIE 四类任务分别设计准确性奖励和结构约束配合难度分层的训练样本构建使 RL 训练更稳定。当前局限两阶段流水线存在误差传播风险版面检测不准会影响下游识别跨页依赖和不规则多栏版面下阅读顺序重建可能不完美低分辨率、严重变形文档以及训练数据中覆盖不足的语言性能会下降作为生成模型换行和空格处理存在随机性无法完全保证格式一致性信息抽取依赖 prompt 质量复杂表单中模糊字段可能导致抽取不完整项目信息GitHubhttps://github.com/zai-org/GLM-OCR技术报告arXiv 2603.10910HuggingFacehttps://huggingface.co/zai-org/GLM-OCR协议Apache 2.0代码 MIT模型最新版本v0.1.32026-03-13API 定价0.2 元/百万 token约为传统 OCR 方案的 1/10