1. 从一次票据识别翻车说起GLM-OCR 到底解决了什么上周帮朋友处理一批增值税发票用某传统 OCR 引擎跑出来的结果让人头大金额和税额串行、表格线被识别成乱码、手写备注直接丢失。换用通用多模态大模型重跑精度上来了但一张图要等好几秒200 张发票跑完天都黑了成本也肉疼。这个场景其实很典型——文档解析这件事传统 OCR 精度不够通用大模型又太贵太慢。智谱 AI 最近发布的 GLM-OCR 就是冲着这个夹缝来的。它是一个参数规模仅 0.9B 的轻量级专业 OCR 模型在 OmniDocBench V1.5 综合评测上拿到 94.6 分官方称达到 SOTA 水平细分任务上对标甚至超越 PaddleOCR-VL-1.5接近 Gemini-3-Pro 的表现。核心卖点可以概括成三句话小尺寸、高精度、低部署成本。它专门针对手写体、复杂表格、编程代码、印章图像、多语言混排这些传统 OCR 的老大难场景做了优化输出格式支持纯文本、HTML 表格代码和结构化 JSON。这篇文章适合谁看如果你正在做 RAG 知识库、票据信息抽取、合同文档结构化或者单纯想找一个能本地跑、API 调用又便宜的 OCR 方案那这篇的实测对比和可复制配置就是写给你的。我会先把 GLM-OCR 和 PaddleOCR-VL-1.5 在文档解析、表格识别上的差异讲清楚再给出一套能直接跑的 API 调用骨架最后把多场景验证步骤和踩坑记录一并奉上。2. GLM-OCR 与 PaddleOCR-VL-1.5 的能力边界对比在动手写代码之前先把两个模型的定位差异理清楚否则很容易选错工具。GLM-OCR 采用经典的编码器-解码器架构视觉部分用自研的 CogViT 视觉编码器在数十亿级图文数据上预训练过。它的处理流程是版面分析 → 并行识别两阶段先分析文档结构再对不同区域并行识别兼顾精度和速度。训练上引入了多 Tokens 预测损失策略增强训练信号。参数量 0.9B其中视觉编码器约 400M语言解码器约 0.5B支持 vLLM、SGLang、Ollama 等主流推理框架。PaddleOCR-VL-1.5 的定位是高精度、鲁棒的多任务文档解析在中文文档场景积累深厚生态成熟工具链完整。两者在综合榜单上的差距其实不大真正的差异体现在具体场景里。对比维度GLM-OCRPaddleOCR-VL-1.5参数量0.9B相对更大综合评测OmniDocBench V1.5 94.6 分同榜单接近水平表格输出直接输出 HTML 表格代码结构化输出需后处理手写体专项优化支持复杂手写略弱部署框架vLLM/SGLang/OllamaPaddle 生态为主API 成本0.2 元/百万 Tokens视方案而定吞吐量1.86 页/秒PDF同量级实测下来GLM-OCR 的优势集中在三块一是复杂表格直接吐 HTML省掉二次制表二是手写体和印章这类非标准内容识别更稳三是小参数量带来的部署灵活性和 API 成本优势。PaddleOCR-VL-1.5 则在中文印刷体、标准版式文档上依然非常能打生态工具更成熟。注意榜单分数只能作为参考真实业务里的版式分布、扫描质量、语言混排情况千差万别一定要用你自己的样本跑一遍再下结论。3. 前置准备通过 TaoToken 获取调用凭证要复现后面的评测你需要一个能稳定调用 GLM-OCR 的入口。这里我用 TaoToken 作为统一接入层它把模型调用、API Key 管理、用量查看集中在一个控制台里省去分别对接各家 SDK 的麻烦。第一步打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册并登录。进入控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 后在左侧找到 API Keys 管理页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 创建一个新的 Key。创建时建议按项目命名比如glm-ocr-test方便后续区分用量。拿到 Key 之后先别急着写代码可以去模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 手动传一张发票或表格截图直观感受一下 GLM-OCR 的输出格式。这一步能帮你快速判断它是否适合你的场景比直接写代码调试高效得多。如果你后续要做长期的文档批处理或 Agent 集成可以关注 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 它在高频调用场景下成本更可控。接入细节和参数说明统一看文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite API 基础地址是 https://taotoken.net/api 注意这个地址不带 UTM 参数。4. 可复制的 API 调用配置骨架下面这套骨架我按最小可运行来写你替换掉 Key 和图片路径就能跑。先装依赖pip install requests pillow然后是核心调用脚本。GLM-OCR 的输入支持图片、扫描件、PDF输出可以是文本、HTML 表格或结构化 JSON这里用图片做演示import base64 import requests API_BASE https://taotoken.net/api API_KEY 你的_TaoToken_API_Key def encode_image(image_path): with open(image_path, rb) as f: return base64.b64encode(f.read()).decode(utf-8) def ocr_image(image_path, output_formathtml): output_format: text / html / json payload { model: glm-ocr, messages: [ { role: user, content: [ { type: image_url, image_url: { url: fdata:image/png;base64,{encode_image(image_path)} } }, { type: text, text: f请识别图中内容以 {output_format} 格式输出。 } ] } ], temperature: 0.0 } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } resp requests.post( f{API_BASE}/v1/chat/completions, jsonpayload, headersheaders, timeout60 ) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: result ocr_image(./invoice_sample.png, output_formatjson) print(result)几个关键参数说明。temperature设成 0.0 是为了让 OCR 输出稳定避免模型自由发挥output_format控制返回结构做表格时用html做字段抽取时用json纯文本场景用text。如果你要批量处理 PDF建议先用 PyMuPDF 把每页转成图片再逐页调用这样比直接传 PDF 更容易控制并发和重试。批量处理的骨架可以这样写import concurrent.futures def batch_ocr(image_paths, max_workers4): results {} with concurrent.futures.ThreadPoolExecutor(max_workersmax_workers) as executor: future_map { executor.submit(ocr_image, p, html): p for p in image_paths } for future in concurrent.futures.as_completed(future_map): path future_map[future] try: results[path] future.result() except Exception as e: results[path] fERROR: {e} return results并发数别一上来就拉满GLM-OCR 单副本单并发下 PDF 吞吐能到 1.86 页/秒但并发过高反而会触发限流。建议从 4 开始根据返回延迟逐步调整。5. 多场景验证从表格识别到结构化抽取配置跑通后重点来了——用真实场景验证它到底行不行。我按三个典型场景分别给验证步骤和预期结果。场景一复杂表格识别。找一张带合并单元格、多层表头的财务报表截图用output_formathtml调用。GLM-OCR 会直接返回table标签的 HTML 代码合并单元格用rowspan/colspan表达。你可以把返回的 HTML 存成.html文件用浏览器打开肉眼比对结构是否还原。实测多层表头的还原度明显好于传统 OCR基本不需要人工二次制表。场景二发票字段抽取。用output_formatjson并在 prompt 里明确字段名比如提取发票号码、开票日期、金额、税额输出 JSON。返回结果可以直接json.loads()后入库。这里有个技巧字段名用中文还是英文要统一否则下游解析容易出错。我一般要求模型输出英文 key避免编码问题。场景三手写体与印章。这类内容传统 OCR 经常直接丢字。GLM-OCR 对手写体做了专项优化印章文字也能识别。验证时建议准备几张不同书写风格的手写单据观察漏字率和错字率。如果印章遮挡了正文可以在 prompt 里说明忽略印章只识别正文减少干扰。场景四RAG 数据准备。把识别结果按段落切分后写入向量库。GLM-OCR 输出的 HTML 表格和结构化 JSON 格式规整切分时比纯文本更容易保留语义边界。这一步的验证方式是拿几个已知答案的问题去检索看召回内容是否准确。提示验证时一定要建一个自己的小测试集至少覆盖你业务里最常见的 3 到 5 种版式。榜单分数再高也不如你自己的样本有说服力。6. 常见报错与排查清单跑的过程中大概率会遇到下面几类问题我把排查路径整理出来。401 未授权。最常见的原因是 Key 复制时带了空格或者请求头里Bearer后面漏了空格。检查Authorization: Bearer sk-xxx这个格式注意Bearer和 Key 之间必须有一个空格。413 请求体过大。图片 base64 编码后体积会膨胀约 33%如果原图超过几 MB很容易触发限制。解决办法是先压缩图片长边控制在 2000 像素以内或者改用图片 URL 方式传参。返回内容被截断。复杂表格的 HTML 代码可能很长如果max_tokens设得太小会被截断。建议把max_tokens设到 4096 以上或者在 prompt 里要求只输出表格不要额外解释。表格结构错乱。如果返回的 HTML 表格行列对不上先检查原图是否倾斜或模糊。GLM-OCR 对图像质量有一定要求扫描件建议先做去噪和二值化预处理。另外 prompt 里明确保持原始表格结构会有帮助。并发限流。批量调用时如果返回 429说明并发过高。降低max_workers或者加一个简单的退避重试import time def ocr_with_retry(image_path, retries3): for i in range(retries): try: return ocr_image(image_path) except requests.HTTPError as e: if e.response.status_code 429: time.sleep(2 ** i) else: raise raise RuntimeError(重试次数耗尽)中文乱码。如果返回的 JSON 里中文显示为转义字符这是正常的json.loads()后会自动还原。如果直接 print 看到\uXXXX用print(result.encode().decode(unicode_escape))转换一下即可。7. 选型建议与后续接入路径回到最初的问题GLM-OCR 超越 PaddleOCR-VL-1.5 了吗我的结论是——在复杂表格、手写体、印章、多语言混排这些场景上GLM-OCR 确实有优势尤其是直接输出 HTML 表格和结构化 JSON 这一点省掉了大量后处理工作。但在标准中文印刷体文档上PaddleOCR-VL-1.5 依然稳生态工具也更成熟。选型的关键不是看榜单排名而是看你的业务版式分布。成本方面GLM-OCR 通过 API 调用是 0.2 元/百万 Tokens官方说法是 1 元约可处理 2000 张 A4 扫描图或 200 份 10 页简单 PDF这个量级对中小规模文档处理来说压力不大。加上模型开源、支持 vLLM/SGLang/Ollama 部署资源受限的边缘设备也能跑。如果你准备把它接进现有系统建议按这个顺序推进先在模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 用真实样本快速验证效果确认可行后到 API Keys 页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 建正式 Key再对照接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 把参数和错误码过一遍。长期做文档批处理或 Agent 集成的可以看下 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 的成本结构。API 基础地址统一用 https://taotoken.net/api 这个不带 UTM。最后分享一个我踩过的坑一开始我图省事直接把 PDF 整个丢给模型结果大文件经常超时。后来改成先转图片、压缩、再并发调用稳定性和速度都上来了。OCR 这件事预处理做得好模型效果能提升一大截。 GLM-OCR 发布：性能 SOTA，超越 PaddleOCR-VL-1.5？
1. 从一次票据识别翻车说起GLM-OCR 到底解决了什么上周帮朋友处理一批增值税发票用某传统 OCR 引擎跑出来的结果让人头大金额和税额串行、表格线被识别成乱码、手写备注直接丢失。换用通用多模态大模型重跑精度上来了但一张图要等好几秒200 张发票跑完天都黑了成本也肉疼。这个场景其实很典型——文档解析这件事传统 OCR 精度不够通用大模型又太贵太慢。智谱 AI 最近发布的 GLM-OCR 就是冲着这个夹缝来的。它是一个参数规模仅 0.9B 的轻量级专业 OCR 模型在 OmniDocBench V1.5 综合评测上拿到 94.6 分官方称达到 SOTA 水平细分任务上对标甚至超越 PaddleOCR-VL-1.5接近 Gemini-3-Pro 的表现。核心卖点可以概括成三句话小尺寸、高精度、低部署成本。它专门针对手写体、复杂表格、编程代码、印章图像、多语言混排这些传统 OCR 的老大难场景做了优化输出格式支持纯文本、HTML 表格代码和结构化 JSON。这篇文章适合谁看如果你正在做 RAG 知识库、票据信息抽取、合同文档结构化或者单纯想找一个能本地跑、API 调用又便宜的 OCR 方案那这篇的实测对比和可复制配置就是写给你的。我会先把 GLM-OCR 和 PaddleOCR-VL-1.5 在文档解析、表格识别上的差异讲清楚再给出一套能直接跑的 API 调用骨架最后把多场景验证步骤和踩坑记录一并奉上。2. GLM-OCR 与 PaddleOCR-VL-1.5 的能力边界对比在动手写代码之前先把两个模型的定位差异理清楚否则很容易选错工具。GLM-OCR 采用经典的编码器-解码器架构视觉部分用自研的 CogViT 视觉编码器在数十亿级图文数据上预训练过。它的处理流程是版面分析 → 并行识别两阶段先分析文档结构再对不同区域并行识别兼顾精度和速度。训练上引入了多 Tokens 预测损失策略增强训练信号。参数量 0.9B其中视觉编码器约 400M语言解码器约 0.5B支持 vLLM、SGLang、Ollama 等主流推理框架。PaddleOCR-VL-1.5 的定位是高精度、鲁棒的多任务文档解析在中文文档场景积累深厚生态成熟工具链完整。两者在综合榜单上的差距其实不大真正的差异体现在具体场景里。对比维度GLM-OCRPaddleOCR-VL-1.5参数量0.9B相对更大综合评测OmniDocBench V1.5 94.6 分同榜单接近水平表格输出直接输出 HTML 表格代码结构化输出需后处理手写体专项优化支持复杂手写略弱部署框架vLLM/SGLang/OllamaPaddle 生态为主API 成本0.2 元/百万 Tokens视方案而定吞吐量1.86 页/秒PDF同量级实测下来GLM-OCR 的优势集中在三块一是复杂表格直接吐 HTML省掉二次制表二是手写体和印章这类非标准内容识别更稳三是小参数量带来的部署灵活性和 API 成本优势。PaddleOCR-VL-1.5 则在中文印刷体、标准版式文档上依然非常能打生态工具更成熟。注意榜单分数只能作为参考真实业务里的版式分布、扫描质量、语言混排情况千差万别一定要用你自己的样本跑一遍再下结论。3. 前置准备通过 TaoToken 获取调用凭证要复现后面的评测你需要一个能稳定调用 GLM-OCR 的入口。这里我用 TaoToken 作为统一接入层它把模型调用、API Key 管理、用量查看集中在一个控制台里省去分别对接各家 SDK 的麻烦。第一步打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册并登录。进入控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 后在左侧找到 API Keys 管理页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 创建一个新的 Key。创建时建议按项目命名比如glm-ocr-test方便后续区分用量。拿到 Key 之后先别急着写代码可以去模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 手动传一张发票或表格截图直观感受一下 GLM-OCR 的输出格式。这一步能帮你快速判断它是否适合你的场景比直接写代码调试高效得多。如果你后续要做长期的文档批处理或 Agent 集成可以关注 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 它在高频调用场景下成本更可控。接入细节和参数说明统一看文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite API 基础地址是 https://taotoken.net/api 注意这个地址不带 UTM 参数。4. 可复制的 API 调用配置骨架下面这套骨架我按最小可运行来写你替换掉 Key 和图片路径就能跑。先装依赖pip install requests pillow然后是核心调用脚本。GLM-OCR 的输入支持图片、扫描件、PDF输出可以是文本、HTML 表格或结构化 JSON这里用图片做演示import base64 import requests API_BASE https://taotoken.net/api API_KEY 你的_TaoToken_API_Key def encode_image(image_path): with open(image_path, rb) as f: return base64.b64encode(f.read()).decode(utf-8) def ocr_image(image_path, output_formathtml): output_format: text / html / json payload { model: glm-ocr, messages: [ { role: user, content: [ { type: image_url, image_url: { url: fdata:image/png;base64,{encode_image(image_path)} } }, { type: text, text: f请识别图中内容以 {output_format} 格式输出。 } ] } ], temperature: 0.0 } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } resp requests.post( f{API_BASE}/v1/chat/completions, jsonpayload, headersheaders, timeout60 ) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: result ocr_image(./invoice_sample.png, output_formatjson) print(result)几个关键参数说明。temperature设成 0.0 是为了让 OCR 输出稳定避免模型自由发挥output_format控制返回结构做表格时用html做字段抽取时用json纯文本场景用text。如果你要批量处理 PDF建议先用 PyMuPDF 把每页转成图片再逐页调用这样比直接传 PDF 更容易控制并发和重试。批量处理的骨架可以这样写import concurrent.futures def batch_ocr(image_paths, max_workers4): results {} with concurrent.futures.ThreadPoolExecutor(max_workersmax_workers) as executor: future_map { executor.submit(ocr_image, p, html): p for p in image_paths } for future in concurrent.futures.as_completed(future_map): path future_map[future] try: results[path] future.result() except Exception as e: results[path] fERROR: {e} return results并发数别一上来就拉满GLM-OCR 单副本单并发下 PDF 吞吐能到 1.86 页/秒但并发过高反而会触发限流。建议从 4 开始根据返回延迟逐步调整。5. 多场景验证从表格识别到结构化抽取配置跑通后重点来了——用真实场景验证它到底行不行。我按三个典型场景分别给验证步骤和预期结果。场景一复杂表格识别。找一张带合并单元格、多层表头的财务报表截图用output_formathtml调用。GLM-OCR 会直接返回table标签的 HTML 代码合并单元格用rowspan/colspan表达。你可以把返回的 HTML 存成.html文件用浏览器打开肉眼比对结构是否还原。实测多层表头的还原度明显好于传统 OCR基本不需要人工二次制表。场景二发票字段抽取。用output_formatjson并在 prompt 里明确字段名比如提取发票号码、开票日期、金额、税额输出 JSON。返回结果可以直接json.loads()后入库。这里有个技巧字段名用中文还是英文要统一否则下游解析容易出错。我一般要求模型输出英文 key避免编码问题。场景三手写体与印章。这类内容传统 OCR 经常直接丢字。GLM-OCR 对手写体做了专项优化印章文字也能识别。验证时建议准备几张不同书写风格的手写单据观察漏字率和错字率。如果印章遮挡了正文可以在 prompt 里说明忽略印章只识别正文减少干扰。场景四RAG 数据准备。把识别结果按段落切分后写入向量库。GLM-OCR 输出的 HTML 表格和结构化 JSON 格式规整切分时比纯文本更容易保留语义边界。这一步的验证方式是拿几个已知答案的问题去检索看召回内容是否准确。提示验证时一定要建一个自己的小测试集至少覆盖你业务里最常见的 3 到 5 种版式。榜单分数再高也不如你自己的样本有说服力。6. 常见报错与排查清单跑的过程中大概率会遇到下面几类问题我把排查路径整理出来。401 未授权。最常见的原因是 Key 复制时带了空格或者请求头里Bearer后面漏了空格。检查Authorization: Bearer sk-xxx这个格式注意Bearer和 Key 之间必须有一个空格。413 请求体过大。图片 base64 编码后体积会膨胀约 33%如果原图超过几 MB很容易触发限制。解决办法是先压缩图片长边控制在 2000 像素以内或者改用图片 URL 方式传参。返回内容被截断。复杂表格的 HTML 代码可能很长如果max_tokens设得太小会被截断。建议把max_tokens设到 4096 以上或者在 prompt 里要求只输出表格不要额外解释。表格结构错乱。如果返回的 HTML 表格行列对不上先检查原图是否倾斜或模糊。GLM-OCR 对图像质量有一定要求扫描件建议先做去噪和二值化预处理。另外 prompt 里明确保持原始表格结构会有帮助。并发限流。批量调用时如果返回 429说明并发过高。降低max_workers或者加一个简单的退避重试import time def ocr_with_retry(image_path, retries3): for i in range(retries): try: return ocr_image(image_path) except requests.HTTPError as e: if e.response.status_code 429: time.sleep(2 ** i) else: raise raise RuntimeError(重试次数耗尽)中文乱码。如果返回的 JSON 里中文显示为转义字符这是正常的json.loads()后会自动还原。如果直接 print 看到\uXXXX用print(result.encode().decode(unicode_escape))转换一下即可。7. 选型建议与后续接入路径回到最初的问题GLM-OCR 超越 PaddleOCR-VL-1.5 了吗我的结论是——在复杂表格、手写体、印章、多语言混排这些场景上GLM-OCR 确实有优势尤其是直接输出 HTML 表格和结构化 JSON 这一点省掉了大量后处理工作。但在标准中文印刷体文档上PaddleOCR-VL-1.5 依然稳生态工具也更成熟。选型的关键不是看榜单排名而是看你的业务版式分布。成本方面GLM-OCR 通过 API 调用是 0.2 元/百万 Tokens官方说法是 1 元约可处理 2000 张 A4 扫描图或 200 份 10 页简单 PDF这个量级对中小规模文档处理来说压力不大。加上模型开源、支持 vLLM/SGLang/Ollama 部署资源受限的边缘设备也能跑。如果你准备把它接进现有系统建议按这个顺序推进先在模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 用真实样本快速验证效果确认可行后到 API Keys 页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 建正式 Key再对照接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 把参数和错误码过一遍。长期做文档批处理或 Agent 集成的可以看下 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 的成本结构。API 基础地址统一用 https://taotoken.net/api 这个不带 UTM。最后分享一个我踩过的坑一开始我图省事直接把 PDF 整个丢给模型结果大文件经常超时。后来改成先转图片、压缩、再并发调用稳定性和速度都上来了。OCR 这件事预处理做得好模型效果能提升一大截。