这个0.9B小模型GLM-OCR,本地运行识别复杂文档,开源后能成为识别领域的巅峰之作吗?
- 内容介绍
- 文章标签
- 相关推荐
说实话, 最近大模型圈子里那种“越大越好”的军备竞赛,多少让人有点审美疲劳。动辄几百亿甚至上千亿的参数, 虽然性能是强了但对于咱们普通开发者或者中小企业落地部署的成本简直让人头秃。 麻了... 就在大家都在卷算力、 卷显存的时候,智谱AI反其道而行之,搞了个大动作——直接把自家的新一代OCR模型 GLM-OCR 给开源了。
0.9B的小个子, 却有大能量
最让我惊讶的不是它开源了而是它的体量。这玩意儿走的是极致的“小而美”路线,参数量仅仅只有0.9B。你没听错,不到10亿参数。但别看它个头小, 本事可一点都不小,在业内极具权威性的 OmniDocBench V1.5 榜单上,它硬是拿下了 94.6 分的高分。这成绩, 直接在文本识别、公式解析、表格还原以及信息抽取这几个核心领域冲到了 SOTA,甚至性能直逼 Gemini-3-Pro 这种顶尖的闭源大模型。这不禁让人想问:这难道就是传说中的“开源即巅峰”,放心去做...?
不只是“识字”, 更是“看懂”
在聊 GLM-OCR 之前,咱们先得回顾一下过去。只要是经常跟文档打交道的朋友,大概率都被传统的 OCR 工具“坑”过。那种无力感,真的谁用谁知道。
就拿最让人头疼的扫描版PDF来说吧。以前我们想把一些老资料数字化, 扫描进去稍微有点模糊,或者表格刚好跨页了那出来的后来啊简直就是一场灾难。要么是缺行少列,要么就是数字错位,你还得花比重新录入还多的时间去校对。更别提那些复杂的表格了 什么合并单元格、多层表头,在传统 OCR 眼里简直就是不可逾越的天堑。识别出来往往就是一串毫无逻辑的一维文本,你想把它还原成 Excel 可用的表格?得,准备好手动调整半天吧。
还有手写体识别,这更是传统 OCR 的“滑铁卢”。不管是学生党想数字化课堂笔记,还是医生那龙飞凤舞的处方,丢给传统软件,识别率直接跳水。再说说你会发现,还不如自己手打来得快。至于理工科学生最痛恨的公式截图 好不容易拍清楚了OCR 出来的却是一堆乱码符号,想转成 LaTeX 格式?那简直是奢望。再加上中英文混排时的“串台”尴尬, 以及盖章文件里印章遮挡文字的识别难题……这些痛点,真的是一把辛酸泪,行吧...。
GLM-OCR 的“看家本领”
正是看准了这些让人抓狂的场景,GLM-OCR 应运而生。它不仅仅是一个能“识字”的工具,更像是一个能“看懂”文档的智能助手。官方这次明摆着是做了大量的调研,针对真实业务中的六大核心场景进行了深度打磨。
而且, 它的模型权重和完整工具链都是开源的,代码遵循 Apache 2.0 协议,模型权重是 MIT 协议。 这事儿我得说道说道。 这大体上就是给了大家一张“商用无限制”的通行证,个人和企业都能放心地二次开发。
公式识别, 科研党的福音
如果你是科研人员或者程序员,你会爱上这个功能的。GLM-OCR 能将手写或打印的公式截图, 准确地转换成 LaTeX 格式,上下标、分式、根号这些复杂结构统统保留。 共勉。 而在解析代码文档时它又能精准地保留缩进与语法结构,不会把代码变成一团乱麻。这对于需要构建知识库或者做 RAG 系统的开发者来说价值巨大。
表格识别, 财务的救星
对于财务、运营这些整天跟报表打交道的人GLM-OCR 简直是福音。它不再是傻傻地识别文字,而是能真正理解表格的结构。无论是合并单元格、 多层表头,还是那种让人眼花缭乱的斜线表头,它都能精准地识别,并且直接输出 HTML 表格代码。这意味着什么?意味着你不需要再二次制表,拿到的后来啊就是可以直接用的,这效率提升可不是一星半点,我心态崩了。。
印章与文本重叠?小意思
除了上面这些, 它在处理印章与文本重叠的问题上也表现不俗,能把被印章盖住的关键字段干净地提取出来。支持多语言混排,中英文、数字、符号挤在一起也不怕“串台”。 在理。 甚至还能源通过 JSON Schema 模板, 从发票、证件、报关单这些文档中自动提取关键字段,直接输出结构化的 JSON 数据,直接对接业务系统。
技术架构的秘密武器
也是没谁了... 很多人可能会好奇, 0.9B 的参数量,怎么就能吊打那些大块头?这背后的技术架构其实相当精妙。
GLM-OCR 采用了“视觉编码器 → 跨模态连接层 → 语言解码器”的三级结构。视觉侧的核心是自研的 CogViT 视觉编码器,参数量大约 400M。 太魔幻了。 这个编码器可不是简单地“看图”, 它在数十亿级的高质量图文对数据上进行了大规模预训练,还引入了 CLIP 策略,让它对图像特征的理解极其深刻。
为了把 CogViT 捕捉到的视觉信息“高精度”的秘密武器。
本地运行, 工程友好
对于注重数据隐私的企业,或者不想被云厂商绑定的开发者,本地部署绝对是首选。GLM-OCR 支持 vLLM、SGLang 和 Ollama 这些目前最火的主流推理框架。这意味着你可以在自己的服务器上,甚至是在普通显卡甚至 CPU 环境下把它跑起来。官方的测试数据显示, 单副本单并发下处理 PDF 的吞吐量相当可观,速度在同类小参数模型里非常有竞争力,哎,对!。
如果你不想折腾硬件,直接用 API 也是个极好的选择。智谱开放平台提供了标准的 API 接口,按量计费,接入门槛极低。最关键的是它便宜!官方的 API 定价非常有诚意, 几块钱大概就能处理几十张 A4 扫描图或者上百页的 PDF,成本大概是传统 OCR 方案的十分之一。这对于需要处理海量历史文档的用户账单再也不会让人心头一紧了。
快速上手,简单易用
光说不练假把式,咱们来看看怎么快速上手。GLM-OCR 提供了非常简洁的 Python SDK 和 CLI 工具,原来小丑是我。。
# Install from source
git clone github.com/zai-org/glm-ocr.git
cd glm-ocr
uv venv --python 3.10 --seed && source .venv/bin/activate
uv pip install -e .
# Install transformers from source
uv pip install git+github.com/huggingface/transformers.git
安装过程非常顺滑, 支持从源码安装:
# Parse a single image
glmocr parse examples/source/code.png
# Parse a directory
glmocr parse examples/source/
# Set output directory
glmocr parse examples/source/code.png --output ./results/
# Use a custom config
glmocr parse examples/source/code.png --config my_config.yaml
我傻了。 当然在 Python 代码里调用也很方便,支持批量处理和后来啊保存:
from glmocr import GlmOcr, parse
# Simple function
result = parse
result.save
# Class-based API
with GlmOcr as parser:
result = parser.parse
print
result.save
为什么我强烈推荐你试试 GLM-OCR?
结合我自己的使用感受,推荐它的理由其实很实在,别担心...。
性价比
0.9B 的小参数, 却在多个权威榜单上拿了顶尖成绩,真正做到“小而美”。 我傻了。 你不需要为了跑一个 OCR 去买几万块的显卡,普通设备就能驾驭。
本土化优势
盘它。 作为国产模型, GLM-OCR 在处理中文文档、票据这些本土化场景时有着天然的优势。那种对中文语境、排版习惯的理解,是很多国外模型比不了的。
对 RAG 系统的友好度
现在大家都在做知识库问答,最缺的就是高质量的文档解析器。GLM-OCR 的高精度和规整的输出格式, 非常适合作为 RAG 系统的前置文档解析模块,为上层大模型提供高质量的“燃料”。这就像给跑车加上了高标号的汽油,跑起来自然更稳。
工程化落地, 做得相当到位
除了性能强悍,GLM-OCR 在工程化落地方面也做得相当到位, 我个人认为... 真正做到“工程友好,易于集成”。
GLM-OCR 的出现, 不仅仅是一个新模型的发布,更像是文档解析技术从单一“工具”向行业通用“基础设施”演进的一个信号。 捡漏。 它用精密的模型设计与针对性的场景优化,证明了小模型也能在特定领域实现超越巨型模型的效能。
无论你是需要数字化笔记的学生, 还是需要处理复杂报表的财务,亦或是正能有一个既强大、又便宜、还开源的工具在手,谁能顶得住这种诱惑呢,我明白了。?
山水有相逢,来日皆可期。如果你对 GLM-OCR 感兴趣, 不妨去 GitHub 或者 Hugging Face 上看看,亲自跑一跑,相信你会被它的表现惊艳到。咱们下次再见,盘它。!
说实话, 最近大模型圈子里那种“越大越好”的军备竞赛,多少让人有点审美疲劳。动辄几百亿甚至上千亿的参数, 虽然性能是强了但对于咱们普通开发者或者中小企业落地部署的成本简直让人头秃。 麻了... 就在大家都在卷算力、 卷显存的时候,智谱AI反其道而行之,搞了个大动作——直接把自家的新一代OCR模型 GLM-OCR 给开源了。
0.9B的小个子, 却有大能量
最让我惊讶的不是它开源了而是它的体量。这玩意儿走的是极致的“小而美”路线,参数量仅仅只有0.9B。你没听错,不到10亿参数。但别看它个头小, 本事可一点都不小,在业内极具权威性的 OmniDocBench V1.5 榜单上,它硬是拿下了 94.6 分的高分。这成绩, 直接在文本识别、公式解析、表格还原以及信息抽取这几个核心领域冲到了 SOTA,甚至性能直逼 Gemini-3-Pro 这种顶尖的闭源大模型。这不禁让人想问:这难道就是传说中的“开源即巅峰”,放心去做...?
不只是“识字”, 更是“看懂”
在聊 GLM-OCR 之前,咱们先得回顾一下过去。只要是经常跟文档打交道的朋友,大概率都被传统的 OCR 工具“坑”过。那种无力感,真的谁用谁知道。
就拿最让人头疼的扫描版PDF来说吧。以前我们想把一些老资料数字化, 扫描进去稍微有点模糊,或者表格刚好跨页了那出来的后来啊简直就是一场灾难。要么是缺行少列,要么就是数字错位,你还得花比重新录入还多的时间去校对。更别提那些复杂的表格了 什么合并单元格、多层表头,在传统 OCR 眼里简直就是不可逾越的天堑。识别出来往往就是一串毫无逻辑的一维文本,你想把它还原成 Excel 可用的表格?得,准备好手动调整半天吧。
还有手写体识别,这更是传统 OCR 的“滑铁卢”。不管是学生党想数字化课堂笔记,还是医生那龙飞凤舞的处方,丢给传统软件,识别率直接跳水。再说说你会发现,还不如自己手打来得快。至于理工科学生最痛恨的公式截图 好不容易拍清楚了OCR 出来的却是一堆乱码符号,想转成 LaTeX 格式?那简直是奢望。再加上中英文混排时的“串台”尴尬, 以及盖章文件里印章遮挡文字的识别难题……这些痛点,真的是一把辛酸泪,行吧...。
GLM-OCR 的“看家本领”
正是看准了这些让人抓狂的场景,GLM-OCR 应运而生。它不仅仅是一个能“识字”的工具,更像是一个能“看懂”文档的智能助手。官方这次明摆着是做了大量的调研,针对真实业务中的六大核心场景进行了深度打磨。
而且, 它的模型权重和完整工具链都是开源的,代码遵循 Apache 2.0 协议,模型权重是 MIT 协议。 这事儿我得说道说道。 这大体上就是给了大家一张“商用无限制”的通行证,个人和企业都能放心地二次开发。
公式识别, 科研党的福音
如果你是科研人员或者程序员,你会爱上这个功能的。GLM-OCR 能将手写或打印的公式截图, 准确地转换成 LaTeX 格式,上下标、分式、根号这些复杂结构统统保留。 共勉。 而在解析代码文档时它又能精准地保留缩进与语法结构,不会把代码变成一团乱麻。这对于需要构建知识库或者做 RAG 系统的开发者来说价值巨大。
表格识别, 财务的救星
对于财务、运营这些整天跟报表打交道的人GLM-OCR 简直是福音。它不再是傻傻地识别文字,而是能真正理解表格的结构。无论是合并单元格、 多层表头,还是那种让人眼花缭乱的斜线表头,它都能精准地识别,并且直接输出 HTML 表格代码。这意味着什么?意味着你不需要再二次制表,拿到的后来啊就是可以直接用的,这效率提升可不是一星半点,我心态崩了。。
印章与文本重叠?小意思
除了上面这些, 它在处理印章与文本重叠的问题上也表现不俗,能把被印章盖住的关键字段干净地提取出来。支持多语言混排,中英文、数字、符号挤在一起也不怕“串台”。 在理。 甚至还能源通过 JSON Schema 模板, 从发票、证件、报关单这些文档中自动提取关键字段,直接输出结构化的 JSON 数据,直接对接业务系统。
技术架构的秘密武器
也是没谁了... 很多人可能会好奇, 0.9B 的参数量,怎么就能吊打那些大块头?这背后的技术架构其实相当精妙。
GLM-OCR 采用了“视觉编码器 → 跨模态连接层 → 语言解码器”的三级结构。视觉侧的核心是自研的 CogViT 视觉编码器,参数量大约 400M。 太魔幻了。 这个编码器可不是简单地“看图”, 它在数十亿级的高质量图文对数据上进行了大规模预训练,还引入了 CLIP 策略,让它对图像特征的理解极其深刻。
为了把 CogViT 捕捉到的视觉信息“高精度”的秘密武器。
本地运行, 工程友好
对于注重数据隐私的企业,或者不想被云厂商绑定的开发者,本地部署绝对是首选。GLM-OCR 支持 vLLM、SGLang 和 Ollama 这些目前最火的主流推理框架。这意味着你可以在自己的服务器上,甚至是在普通显卡甚至 CPU 环境下把它跑起来。官方的测试数据显示, 单副本单并发下处理 PDF 的吞吐量相当可观,速度在同类小参数模型里非常有竞争力,哎,对!。
如果你不想折腾硬件,直接用 API 也是个极好的选择。智谱开放平台提供了标准的 API 接口,按量计费,接入门槛极低。最关键的是它便宜!官方的 API 定价非常有诚意, 几块钱大概就能处理几十张 A4 扫描图或者上百页的 PDF,成本大概是传统 OCR 方案的十分之一。这对于需要处理海量历史文档的用户账单再也不会让人心头一紧了。
快速上手,简单易用
光说不练假把式,咱们来看看怎么快速上手。GLM-OCR 提供了非常简洁的 Python SDK 和 CLI 工具,原来小丑是我。。
# Install from source
git clone github.com/zai-org/glm-ocr.git
cd glm-ocr
uv venv --python 3.10 --seed && source .venv/bin/activate
uv pip install -e .
# Install transformers from source
uv pip install git+github.com/huggingface/transformers.git
安装过程非常顺滑, 支持从源码安装:
# Parse a single image
glmocr parse examples/source/code.png
# Parse a directory
glmocr parse examples/source/
# Set output directory
glmocr parse examples/source/code.png --output ./results/
# Use a custom config
glmocr parse examples/source/code.png --config my_config.yaml
我傻了。 当然在 Python 代码里调用也很方便,支持批量处理和后来啊保存:
from glmocr import GlmOcr, parse
# Simple function
result = parse
result.save
# Class-based API
with GlmOcr as parser:
result = parser.parse
print
result.save
为什么我强烈推荐你试试 GLM-OCR?
结合我自己的使用感受,推荐它的理由其实很实在,别担心...。
性价比
0.9B 的小参数, 却在多个权威榜单上拿了顶尖成绩,真正做到“小而美”。 我傻了。 你不需要为了跑一个 OCR 去买几万块的显卡,普通设备就能驾驭。
本土化优势
盘它。 作为国产模型, GLM-OCR 在处理中文文档、票据这些本土化场景时有着天然的优势。那种对中文语境、排版习惯的理解,是很多国外模型比不了的。
对 RAG 系统的友好度
现在大家都在做知识库问答,最缺的就是高质量的文档解析器。GLM-OCR 的高精度和规整的输出格式, 非常适合作为 RAG 系统的前置文档解析模块,为上层大模型提供高质量的“燃料”。这就像给跑车加上了高标号的汽油,跑起来自然更稳。
工程化落地, 做得相当到位
除了性能强悍,GLM-OCR 在工程化落地方面也做得相当到位, 我个人认为... 真正做到“工程友好,易于集成”。
GLM-OCR 的出现, 不仅仅是一个新模型的发布,更像是文档解析技术从单一“工具”向行业通用“基础设施”演进的一个信号。 捡漏。 它用精密的模型设计与针对性的场景优化,证明了小模型也能在特定领域实现超越巨型模型的效能。
无论你是需要数字化笔记的学生, 还是需要处理复杂报表的财务,亦或是正能有一个既强大、又便宜、还开源的工具在手,谁能顶得住这种诱惑呢,我明白了。?
山水有相逢,来日皆可期。如果你对 GLM-OCR 感兴趣, 不妨去 GitHub 或者 Hugging Face 上看看,亲自跑一跑,相信你会被它的表现惊艳到。咱们下次再见,盘它。!

