OCR 模型深度对比分析报告
GLM-OCR | DeepSeek-OCR-2 | PaddleOCR-VL-1.5
全方位技术调研与使用指南
2026 年 4 月
执行摘要
本报告对当前开源OCR领域最具代表性的三款模型进行了全面深入的对比分析：来自智谱AI（Z.ai）的 GLM-OCR、来自DeepSeek的 DeepSeek-OCR-2，以及来自百度飞桨的 PaddleOCR-VL-1.5。三款模型均于2025年底至2026年初密集发布，代表了当前开源OCR技术的最前沿水平。
核心发现：
- 三款模型在 OmniDocBench v1.5 权威基准上均取得了突破性表现，GLM-OCR 以 94.62% 位居第一，PaddleOCR-VL-1.5 以 94.50% 紧随其后，DeepSeek-OCR-2 以 91.09% 排名第三。
- 三款模型的参数量设计存在显著差异：GLM-OCR（0.9B）和 PaddleOCR-VL-1.5（0.9B）选择轻量化设计，而 DeepSeek-OCR-2（3B）更注重架构创新和token压缩效率。
- 在开源许可方面，GLM-OCR 采用 MIT 协议，PaddleOCR-VL-1.5 采用 Apache 2.0，均可商用；DeepSeek-OCR-2 的具体许可需查阅其 Hugging Face 仓库。
- 三款模型均支持 vLLM 推理加速，但在部署复杂度上各有侧重：GLM-OCR 提供最完善的SDK和一键部署体验，PaddleOCR-VL-1.5 的双环境部署要求较高，DeepSeek-OCR-2 则对GPU显存要求最高。
一、模型概览
1.1 基本信息对比
|---------------------|--------------------------------|-----------------------------------|--------------------------------------|
| 维度 | GLM-OCR | DeepSeek-OCR-2 | PaddleOCR-VL-1.5 |
| 开发机构 | 智谱AI / Z.ai（清华大学背景） | DeepSeek AI | 百度飞桨 PaddlePaddle |
| 发布时间 | 2026年2月 | 2026年1月27日 | 2026年1月29日 |
| 参数规模 | 0.9B | 3B（570M激活参数） | 0.9B |
| 开源协议 | MIT（模型）/ Apache 2.0（代码） | 详见HuggingFace仓库 | Apache 2.0 |
| 基础架构 | GLM-V encoder-decoder + CogViT | DeepEncoder V2（基于Qwen2-0.5B视觉编码器） | NaViT动态分辨率视觉编码器 + ERNIE-4.5-0.3B语言模型 |
| 核心创新 | MTP多token预测 + 强化学习 | Visual Causal Flow（视觉因果流） | 不规则框定位 + 多任务统一模型 |
| OmniDocBench v1.5得分 | 94.62%（第1） | 91.09%（第3） | 94.50%（第2） |
1.2 技术背景与研发定位
GLM-OCR
GLM-OCR 是智谱AI（Z.ai）专为复杂文档理解场景设计的多模态OCR模型，构建于GLM-V encoder-decoder架构之上。该模型集成了自研CogViT视觉编码器（0.4B参数），通过轻量级跨模态连接器（具备高效token降采样功能）和GLM-0.5B语言解码器构成完整系统。其核心研发目标是在保持高精度的同时，实现更低的推理延迟和计算成本，以适应边缘部署和大规模生产场景的需求。
GLM-OCR的技术报告于2026年3月12日正式发布，表明其研发过程经过了充分的学术验证。模型采用两阶段流水线：首先通过PP-DocLayout-V3进行布局分析，然后进行并行识别，从而实现对多样文档布局的鲁棒高质量OCR性能。
DeepSeek-OCR-2
DeepSeek-OCR-2 是 DeepSeek AI 对其OCR系列的重大迭代升级，于2026年1月27日发布，配套论文arXiv:2601.20552同步公开。相较于第一代主要侧重于'上下文光学压缩'（Contexts Optical Compression）的设计理念，OCR-2引入了全新的'视觉因果流'（Visual Causal Flow）架构，旨在突破传统从左到右、从上到下固定扫描顺序的限制，模拟人类阅读文档的认知过程。
DeepEncoder V2 是其核心技术突破，采用基于语言模型的编码器和可学习的因果查询（Causal Queries），实现了全局感知与结构化序列解释的结合，理论上能够更好地处理复杂布局和多列文档。
PaddleOCR-VL-1.5
PaddleOCR-VL-1.5 是百度飞桨OCR-VL系列的升级版本，于2026年1月29日发布。作为开源OCR领域历史最悠久、生态最成熟的工具套件之一，PaddleOCR具备深厚的工程积累。1.5版本在1.0版本的核心能力基础上进行了全面优化，最显著的创新在于：支持不规则形状边界框定位，即多边形检测，这使其在扫描件、倾斜、折叠、拍摄等真实场景下表现出色。同时，1.5版本还新增了印章识别和文字定位（Text Spotting）任务支持，进一步扩展了其多任务能力边界。
二、架构技术深度解析
2.1 视觉编码器设计
|--------------|-------------------------------------------|-----------------------------------------|--------------------------|
| 架构维度 | GLM-OCR | DeepSeek-OCR-2 | PaddleOCR-VL-1.5 |
| 视觉编码器 | CogViT（0.4B，大规模图文预训练） | Qwen2-0.5B + SAM风格Vision Tokenizer（80M） | NaViT风格动态分辨率视觉编码器 |
| 语言解码器 | GLM-0.5B语言解码器 | Qwen2.5系语言模型后端 | ERNIE-4.5-0.3B |
| Token策略 | 四倍下采样 + SwiGLU机制 | 256~1120可变视觉token压缩 | 动态分辨率，原生分辨率编码 |
| 跨模态连接 | 轻量级跨模态连接器（token下采样） | 可学习Query Tokens + DeepEncoder V2 | 集成视觉特征与语言特征对齐层 |
| 训练创新 | Multi-Token Prediction（MTP）Loss + 全任务强化学习 | Visual Causal Flow（视觉因果流） | 三阶段渐进训练范式（PaddleFormers） |
| 预训练数据 | 大规模图文对（规模未公开） | 3000万页PDF（100种语言） | 4600万图文对（预训练扩充自2900万） |
2.2 文档解析流水线设计
GLM-OCR 两阶段流水线
GLM-OCR采用两阶段解析流水线：第一阶段通过PP-DocLayout-V3进行页面布局分析，将文档分割为不同类型的内容区块（文字、表格、公式、图表等）；第二阶段对各内容块进行并行识别。这种设计既利用了成熟的布局检测能力，又通过并行化显著提升了吞吐量，最终达到1.86页/秒的PDF处理速度。
- 布局检测：PP-DocLayout-V3（Apache 2.0协议，开源）
- 并行识别：多内容块同步处理，提升吞吐量
- 输出格式：Markdown、HTML（表格）、LaTeX（公式）
DeepSeek-OCR-2 端到端视觉因果流
DeepSeek-OCR-2的核心创新在于抛弃了传统的固定网格扫描方式，引入'视觉因果流'架构。编码器首先获取页面的全局视图，然后通过可学习查询以结构化序列方式处理内容，允许模型根据语义关系动态重排内容块，而非受物理位置约束。这一设计理论上能够更好地处理多列布局、复杂阅读顺序等挑战性场景。
值得注意的是，学术界对这一设计存在质疑：来自东北大学和中科院的研究者发现，该方法在无语言先验支持时准确率从90%骤降至20%，表明其视觉理解可能依赖语言模式而非纯视觉特征。这是评估该模型时需要特别关注的风险点。
PaddleOCR-VL-1.5 混合流水线 + 运行时优化
PaddleOCR-VL-1.5采用两阶段混合架构：PP-DocLayout（布局检测）+ VLM（视觉语言模型）联合推理。其运行时系统实现了显著的工程创新：PDF转图片、布局分析、VLM推理三个阶段各运行在独立线程中，通过队列缓冲区连接；VLM阶段动态组建mini-batch，将多页内容块合并为单次推理调用，这是实际吞吐量显著高于理论预期的核心原因。
不规则框定位（多边形检测）是1.5版本最重要的新特性，使其成为全球首个支持不规则形状文档元素定位的文档解析模型，在倾斜、折叠、拍摄等真实场景下具有明显优势。
三、性能基准测试
3.1 OmniDocBench v1.5 综合排名
OmniDocBench v1.5 是当前最权威的文档解析综合基准，涵盖文字识别、表格解析、公式识别、阅读顺序四大维度，数据集扩展至1355页文档，中英文比例更加均衡，并更新了公式评估指标（采用CDM方法替代原有指标）。
|--------------------------|--------------------|--------------|------------------|--------------|------------------|
| 模型 | Overall得分 | 文字识别 | 公式识别 | 表格解析 | 阅读顺序 |
| GLM-OCR | 94.62%（第1） | 94.0% | 96.5%（UniMERNet） | 85.2% | 优秀 |
| PaddleOCR-VL-1.5 | 94.50%（第2） | SOTA | SOTA | SOTA | SOTA（全维度领先） |
| DeepSeek-OCR-2 | 91.09%（第3） | 良好 | 良好 | 良好 | 阅读顺序编辑距离0.057（优） |
| Gemini-3 Pro（参考） | 接近SOTA | - | - | - | 文档解析编辑距离0.115 |
| GPT-5.2（参考） | 参考基准 | - | - | - | - |
3.2 专项基准测试
|-----------------------|-----------------------|------------------------|--------------------------|---------------------|
| 基准测试 | GLM-OCR | DeepSeek-OCR-2 | PaddleOCR-VL-1.5 | 说明 |
| OCRBench（文字） | 94.0% | - | - | 通用文字识别基准 |
| UniMERNet（公式） | 96.5% | - | - | 数学公式识别基准 |
| PubTabNet（表格） | 85.2% | - | - | 学术论文表格基准 |
| TEDS_TEST（表格） | 86.0% SOTA | - | - | 表格结构评测 |
| Nanonets-KIE | 93.7% | - | - | 关键信息提取 |
| Handwritten-KIE | 86.1% | - | - | 手写关键信息提取 |
| Fox Benchmark（10x压缩） | - | 97%精度 | - | token压缩效率测试 |
| Fox Benchmark（20x压缩） | - | 60%精度 | - | 高压缩率下的精度 |
| Real5-OmniDocBench | - | - | 全场景SOTA | 真实环境鲁棒性基准 |
| MinerU 2.5（PubTabNet） | （对比：GLM 85.2 vs 88.4） | - | - | MinerU 2.5在表格上领先GLM |
3.3 推理速度与吞吐量
|--------------|-----------------|----------------------------------|--------------------------|
| 性能指标 | GLM-OCR | DeepSeek-OCR-2 | PaddleOCR-VL-1.5 |
| PDF处理速度 | 1.86页/秒（实测） | ~200k页/天（A100集群） | 高效（具体速度依批次设置） |
| 图像处理速度 | 0.67张/秒 | - | 512页批处理（单A100） |
| 测试硬件 | 单GPU（单并发） | A100 GPU集群 | 单张NVIDIA A100 |
| token效率 | 标准 | 256~1120 token/页（10x压缩） | 动态分辨率编码 |
| 并发支持 | vLLM/SGLang高并发 | vLLM原生支持（2025年10月起） | 多线程流水线 + 动态批处理 |
| 参数规模对速度影响 | 0.9B，速度最快 | 3B，需更强GPU支撑 | 0.9B，与GLM相当 |
注：GLM-OCR的1.86页/秒是在单副本、单并发条件下测得的标准化数据，实际生产环境下通过vLLM多并发可显著提升吞吐量。DeepSeek-OCR-2的200k页/天数据来自多GPU批处理管道，采用了积极的批处理和混合精度策略，不宜与GLM-OCR的单并发数据直接比较。
四、核心能力全面对比
4.1 文档类型支持能力
|-----------------------|------------------|------------------------|---------------------------|
| 文档类型 | GLM-OCR | DeepSeek-OCR-2 | PaddleOCR-VL-1.5 |
| 复杂表格（合并单元格/多层表头） | ✅ 支持，输出标准HTML | ✅ 支持 | ✅ SOTA |
| 数学公式（LaTeX） | ✅ SOTA级别 | ✅ 支持 | ✅ SOTA |
| 多栏文档/复杂布局 | ✅ PP-DocLayout加持 | ✅ 视觉因果流 | ✅ 布局分析+VLM |
| 代码块识别 | ✅ 专项优化 | ⚠️ 基本支持 | ⚠️ 基本支持 |
| 印章/Seal识别 | ✅ 专项优化 | ❌ 未提及 | ✅ 新增功能 |
| 手写文字 | ✅ KIE基准86.1% | ⚠️ 部分支持 | ⚠️ 部分支持 |
| 图表解析（Chart→HTML/JSON） | ✅ 支持 | ✅ 支持 | ✅ SOTA（11类图表） |
| 倾斜/扫描变形文档 | ⚠️ 基础支持 | ⚠️ 有改善 | ✅ 不规则框+Real5 SOTA |
| 拍照文档（屏幕拍摄） | ⚠️ 基础支持 | ⚠️ 基础支持 | ✅ Real5 SOTA |
| PDF直接处理 | ✅ 原生支持 | ✅ crop_mode支持 | ✅ 批处理512页/次 |
| 跨页表格/段落合并 | ⚠️ 需后处理 | ⚠️ 需后处理 | ✅ 自动跨页合并 |
4.2 语言支持能力
|--------------|-----------------|------------------------|--------------------------|
| 语言维度 | GLM-OCR | DeepSeek-OCR-2 | PaddleOCR-VL-1.5 |
| 支持语言数 | 中文、英文为主，多语言未明确 | 100种语言 | 109种语言（明确列出） |
| 中文支持 | ★★★★★ 优秀 | ★★★★ 良好 | ★★★★★ 优秀（含藏文） |
| 英文支持 | ★★★★★ SOTA | ★★★★★ SOTA | ★★★★★ SOTA |
| 特殊语言 | 未明确说明 | 100种语言训练数据覆盖 | 新增藏文、孟加拉语，含西里尔、阿拉伯、梵文、泰文 |
| 多语言混排 | 支持（中英混排优） | 支持（100语言） | ★★★★★ 专项优化 |
| 中文古籍/罕见字 | 一般 | 一般 | 专项改进 |
4.3 输出格式与结构化能力
|--------------|----------------------|------------------------|--------------------------|
| 输出格式 | GLM-OCR | DeepSeek-OCR-2 | PaddleOCR-VL-1.5 |
| Markdown | ✅ 主要输出格式 | ✅ grounding模式 | ✅ 推荐输出格式 |
| HTML（表格） | ✅ 标准HTML | ✅ 支持 | ✅ 支持 |
| LaTeX（公式） | ✅ 支持 | ✅ 支持 | ✅ 支持 |
| JSON结构化 | ✅ SDK支持 | ⚠️ 需后处理 | ✅ JSON输出选项 |
| 边界框坐标 | ❌ 不输出坐标 | ⚠️ 有grounding能力 | ✅ 多边形坐标+内容同步输出 |
| 自由OCR模式 | ✅ Text Recognition模式 | ✅ Free OCR prompt | ✅ ocr任务模式 |
| 文档解析模式 | ✅ Document Parsing模式 | ✅ grounding模式 | ✅ 多任务分离 |
五、部署与工程实践
5.1 硬件需求
|-----------------|------------------|------------------------|-----------------------------------------|
| 硬件配置 | GLM-OCR | DeepSeek-OCR-2 | PaddleOCR-VL-1.5 |
| 最低GPU显存 | ~8GB VRAM（0.9B） | ~16GB VRAM（3B标准） | ~8GB VRAM（0.9B） |
| 推荐GPU显存 | 16GB | 24GB（复杂文档推荐） | 16GB |
| Apple Silicon支持 | ✅ mlx-vlm方案 | ❌ 暂不支持Metal | ⚠️ 未官方支持 |
| AMD GPU支持 | ⚠️ 社区方案 | ⚠️ 社区开发中 | ✅ ROCm 7.0 Day0支持（AMD Instinct） |
| CPU推理 | ⚠️ 速度极慢 | ❌ 不建议 | ⚠️ 支持但速度慢 |
| Muxi GPU（国产芯片） | ❌ 未明确 | ❌ 未明确 | ✅ 支持沐曦GPU |
| CUDA最低版本 | CUDA 11.8+ | CUDA 11.8+ | CUDA 12.6（推荐） |
| 内存需求 | 16GB RAM | 32GB RAM（推荐） | 16GB RAM |
5.2 部署方式与工具链
|---------------------------|-----------------------------------|------------------------|--------------------------|
| 部署方式 | GLM-OCR | DeepSeek-OCR-2 | PaddleOCR-VL-1.5 |
| vLLM支持 | ✅ 官方推荐 | ✅ 2025年10月正式支持 | ✅ vLLM后端选项 |
| SGLang支持 | ✅ 投机解码优化 | ❌ 未明确 | ✅ 支持 |
| Ollama支持 | ✅ 一行命令运行 | ❌ 未明确 | ❌ 未提供 |
| Docker支持 | ✅ 容器化部署 | ✅ 提供环境配置 | ✅ 官方Docker Compose方案 |
| 官方SDK | ✅ pip install glmocr（最完善） | ❌ 无独立SDK | ✅ paddleocr Python包 |
| Hugging Face Transformers | ✅ transformers>=5.3.0 | ✅ 需trust_remote_code | ✅ transformers>=5.0.0 |
| MaaS云端API | ✅ Z.ai平台，0.2元/百万token | ❌ 无官方API | ✅ 千帆平台+免费Beta API |
| CLI命令行 | ✅ 一行调用 | ❌ 需Python脚本 | ✅ paddleocr CLI |
| Fine-tuning支持 | ✅ LLaMA-Factory教程 | ✅ 支持，86% CER降低 | ⚠️ 1.5版本微调文档不完善 |
5.3 部署复杂度与快速上手
GLM-OCR：最简化部署体验
GLM-OCR提供三种层次的部署路径，覆盖从零门槛到生产级别的全场景需求：
- Skill模式（零GPU）：pip install glmocr，设置API Key，通过CLI或Python直接调用云端API，无需本地GPU。
- Ollama本地部署：ollama run glm-ocr，支持终端拖拽图片直接识别，是个人开发者本地测试的最简方案。
- vLLM/SGLang生产级部署：支持投机解码（speculative decoding）优化，--speculative-algorithm NEXTN参数显著提升吞吐量。
- 分布式SDK模式：在GPU服务器部署SDK Server，客户端无需GPU，通过HTTP协议调用，支持横向扩展。
DeepSeek-OCR-2：工程配置要求较高
DeepSeek-OCR-2的部署需要较为复杂的环境配置，对工程能力有一定要求：
- 环境要求：CUDA 11.8 + PyTorch 2.6.0 + Flash Attention 2.7.3，需要严格版本匹配。
- 关键依赖：pip install vllm flash-attn --no-build-isolation，Flash Attention编译时间较长。
- grounding模式：需要在prompt中添加<|grounding|>标签才能启用布局保留的文档解析模式，否则默认为自由OCR模式。
- 显存要求较高：3B参数模型在复杂文档下推荐24GB VRAM，限制了在消费级GPU上的部署可行性。
PaddleOCR-VL-1.5：功能完善但环境隔离要求高
PaddleOCR-VL-1.5的双后端架构（PaddlePaddle + vLLM）带来了显著的工程挑战：
- 双环境隔离：PaddlePaddle框架与vLLM在同一Python环境中存在依赖冲突（CUDA运行时不兼容），官方推荐在两个独立虚拟环境中分别运行布局检测和VLM推理，并通过HTTP通信协调。
- 1.5版本微调文档缺失：GitHub Issue #17589（2026年1月30日提交）指出，使用标准微调脚本对1.5版本微调会导致性能不如基础模型，官方尚未提供1.5版本的微调指南。
- 容器化推荐：官方提供Docker Compose方案，可干净隔离两个环境并自动协调服务，是推荐的生产部署方式。
- AMD GPU支持亮点：通过与AMD合作，PaddleOCR-VL-1.5是三款模型中唯一提供AMD Instinct MI系列GPU Day0支持的模型，并提供Jupyter Notebook快速启动方案。
六、成本分析
6.1 API使用成本对比
|----------------|---------------------------------------|-------------------------------------------|--------------------------|
| 成本维度 | GLM-OCR | DeepSeek-OCR-2 | PaddleOCR-VL-1.5 |
| 云端API定价 | 0.2元/百万token ≈ 0.5元/1000页A4扫描 | 无官方API | 千帆平台（有免费额度） Beta免费API |
| 1000页处理成本（API） | 约0.5元人民币 | N/A（需自部署） | Beta期间免费 |
| 自托管GPU成本 | ~0.09/1000页（消费级GPU） | \~0.15-0.20/1000页（A100） | ~0.09/1000页（A100优化） |
| 商业API对比（参考） | Mistral OCR: 1/1000页 | Azure Document Intelligence: ~1-2/1000页 | GPT-5.4 OCR: \~15/1000页 |
| 相对商业API成本比 | 约商业API的1/167（自托管） | 约商业API的1/50-100 | 约商业API的1/167（自托管） |
6.2 总拥有成本（TCO）分析
对于每日百万页级别的大规模文档处理场景，三款模型的总拥有成本差异显著：
|---------------|-----------------------------------|-----------------------|---------------------|
| 场景 | 推荐方案 | 估算月成本（元） | 说明 |
| 个人开发者/小型POC | GLM-OCR API（Skill模式） | < 100元/月 | 按需付费，无基础设施成本 |
| 中型企业（10万页/天） | PaddleOCR-VL-1.5自托管 | ~2000-5000元/月（GPU租用） | Apache 2.0，无许可费 |
| 大型企业（100万页/天） | DeepSeek-OCR-2 / PaddleOCR-VL-1.5 | ~20000-50000元/月 | 需GPU集群，建议A100/H100 |
| 边缘/IoT场景 | GLM-OCR（Ollama/edge部署） | 硬件一次性投入 | 0.9B可在消费级硬件运行 |
| 需AMD GPU降本 | PaddleOCR-VL-1.5（ROCm） | 较NVIDIA方案降低30-40% | AMD Instinct MI300X |
七、适用场景与选型建议
7.1 场景适配矩阵
|----------------------|-----------------------------|---------------------------|--------------------------------|
| 应用场景 | 最优选择 | 次优选择 | 选型理由 |
| 金融文档（票据/合同/财务报表） | GLM-OCR | PaddleOCR-VL-1.5 | KIE能力93.7%，印章识别，成本低 |
| 学术论文/科技文献解析 | GLM-OCR | PaddleOCR-VL-1.5 | 公式识别96.5% SOTA，表格TEDS 86% |
| 大规模文档批量处理（token成本敏感） | DeepSeek-OCR-2 | GLM-OCR | 10x token压缩，下游LLM成本最低 |
| 移动端/拍照文档处理 | PaddleOCR-VL-1.5 | GLM-OCR | Real5-OmniDocBench SOTA，不规则框检测 |
| 扫描件/档案数字化（变形/倾斜） | PaddleOCR-VL-1.5 | GLM-OCR | 5种真实场景全部SOTA，多边形检测 |
| 多语言企业文档处理 | PaddleOCR-VL-1.5 | DeepSeek-OCR-2 | 109种语言，藏文/孟加拉语等特殊语言 |
| RAG系统文档前处理 | DeepSeek-OCR-2 | GLM-OCR | token压缩减少向量库成本，与LLM集成优 |
| Agent工作流集成 | GLM-OCR Skill模式 | PaddleOCR-VL-1.5 API | 一行调用，MaaS协议，SDK最完善 |
| 隐私敏感/私有化部署 | PaddleOCR-VL-1.5本地 | GLM-OCR本地 | Apache 2.0，无数据外传，Docker方案完善 |
| 快速原型验证 | GLM-OCR（API/Ollama） | PaddleOCR-VL-1.5 Beta API | 最低上手门槛，一行命令运行 |
| 需要AMD GPU降本部署 | PaddleOCR-VL-1.5 | 无替代方案 | 唯一支持AMD ROCm Day0的模型 |
| 微信/企业微信等中文平台集成 | GLM-OCR API | PaddleOCR-VL-1.5 API | 中文最优，Z.ai平台生态完善 |
7.2 技术风险与注意事项
GLM-OCR 已知局限
- 公式识别在PubTabNet表格基准上（85.2%）落后于MinerU 2.5（88.4%），在特定表格场景下不是最优选择。
- MinerU 2.5在PubTabNet上的88.4得分超越GLM-OCR，说明某些专业场景仍有竞争对手。
- 相比PaddleOCR-VL-1.5，对真实物理变形场景（倾斜、拍摄）的鲁棒性未经Real5-OmniDocBench系统验证。
DeepSeek-OCR-2 已知风险
- 学术界存在质疑：Tohoku大学和中科院研究者发现，无语言先验时准确率从90%骤降至20%，表明视觉理解可能依赖语言模式而非纯视觉特征，在低资源语言或纯图形文档上可能表现不稳定。
- 第一代的生产环境问题（上下文溢出导致幻觉循环，如银行流水生成'啦啦队故事'）在OCR-2中改善但需验证，重复率从6.25%降至4.17%。
- 3B参数对GPU显存要求较高，在消费级GPU（<16GB VRAM）上部署困难。
- 无官方云端API，必须自部署，对中小企业有一定工程门槛。
PaddleOCR-VL-1.5 已知局限
- 1.5版本缺乏官方微调文档（截至2026年2月，GitHub issue #17589和ms-swift issue #7997均未解决），对于需要领域适配的场景构成障碍。
- 双环境部署复杂度：PaddlePaddle与vLLM的CUDA依赖冲突需要维护两个隔离的Python环境，增加了运维复杂度。
- PaddlePaddle框架相比PyTorch/HuggingFace生态系统的社区规模较小，第三方集成和社区支持较弱。
八、生态系统与社区
8.1 开源生态与社区活跃度
|---------------------|---------------------|------------------------------|---------------------------------|
| 生态维度 | GLM-OCR | DeepSeek-OCR-2 | PaddleOCR-VL-1.5 |
| HuggingFace下载量（近1月） | 数万次（新发布） | ~124万次（极高） | 高（具体数据未公开） |
| GitHub活跃度 | 活跃（zai-org/GLM-OCR） | 活跃（deepseek-ai/DeepSeek-OCR） | 最高（PaddlePaddle/PaddleOCR，历史最久） |
| 微调模型数（社区） | 新发布，少量 | 27个微调变体，2个adapter | 成熟生态 |
| 量化版本 | Ollama支持（自动量化） | 1个社区量化版本 | 多种量化选项 |
| 社区问答支持 | WeChat + Discord | GitHub Issues | GitHub + AI Studio + 百度社区（最完善） |
| 在线Demo | ✅ glmocr.com | ✅ HuggingFace Spaces | ✅ paddleocr.ai（官方网站+API） |
| 技术报告/论文 | ✅ 正式技术报告（2026.3） | ✅ arXiv:2601.20552 | ✅ arXiv:2601.21957 |
8.2 企业级集成与平台支持
在企业生态建设方面，三款模型各有侧重：
GLM-OCR 通过 Z.ai 平台提供了最完整的企业级服务链路：云端API（MaaS协议，支持开发者以API Key形式接入）、SDK（glmocr包，pip安装）、Skill模式（零GPU调用），并计划持续扩展到更多平台。Z.ai已在香港联交所完成IPO（2026年1月），具备稳定的商业支撑。
PaddleOCR-VL-1.5 依托百度生态，通过千帆大模型平台提供API服务，并提供PaddleOCR官方网站（paddleocr.ai）作为产品展示和免费试用入口。支持与SiliconFlow、Novita AI等第三方推理平台无缝集成，并提供MCP Server支持（PP-StructureV3 MCP，与千帆平台集成）。对于中国企业级用户，百度的合规支持和本地化服务具有显著优势。
DeepSeek-OCR-2 目前在企业服务方面相对薄弱，无官方云端API，主要以开源模型形式提供，依赖社区和第三方推理服务商。但凭借DeepSeek品牌的全球影响力和极高的HuggingFace下载量（超百万次），其社区采用率极高，也有大量第三方服务商提供托管部署方案。
九、综合评分与决策框架
9.1 多维度综合评分（满分10分）
|---------------------|--------------|---------------------|------------------------|--------------------------|
| 评分维度 | 权重 | GLM-OCR | DeepSeek-OCR-2 | PaddleOCR-VL-1.5 |
| 基准性能（OmniDocBench等） | 25% | 9.5 | 8.5 | 9.5 |
| 推理速度与吞吐量 | 15% | 9.0 | 8.5（大批量） | 8.5 |
| 硬件要求（越低越好） | 10% | 9.0 | 7.0（3B需更多显存） | 8.5 |
| 部署便利性 | 15% | 9.5（最佳） | 7.0（配置复杂） | 7.5（双环境） |
| 多语言与特殊场景能力 | 10% | 8.0 | 8.5（100语言） | 9.5（109语言+物理鲁棒性） |
| 成本效益 | 10% | 9.5（API最低价） | 8.0 | 9.0 |
| 生态与社区成熟度 | 10% | 8.0 | 9.0（极高下载量） | 9.5（历史最久） |
| 企业级服务与合规 | 5% | 8.5 | 6.5 | 9.0 |
| 加权总分 | 100% | 9.05 | 8.0 | 8.90 |
9.2 一句话选型建议
|--------------------------------|-----------------------------------|
| 你的核心诉求 | 选哪款？ |
| 最高精度 + 最低成本 + 最简部署 | → GLM-OCR |
| 处理变形/拍摄/多语言真实场景文档 | → PaddleOCR-VL-1.5 |
| 下游LLM集成，需要最低token消耗 | → DeepSeek-OCR-2 |
| AMD GPU部署或需要最成熟的PaddlePaddle生态 | → PaddleOCR-VL-1.5 |
| 快速上线，最小工程投入 | → GLM-OCR（Skill模式/Ollama） |
| 学术研究，关注视觉编码前沿架构 | → DeepSeek-OCR-2（关注学术质疑） |
十、结论
2026年初，开源OCR领域迎来了历史性的转折点：GLM-OCR、DeepSeek-OCR-2和PaddleOCR-VL-1.5三款模型的集中发布，标志着开源方案在文档解析精度上已全面超越商业API（如GPT-5.4、Gemini-3 Pro等），同时将处理成本压缩至商业API的1/50至1/170。
从技术路线来看，三款模型体现了不同的工程哲学：GLM-OCR代表了'轻量高效+SDK完善'的工程化实践路线；DeepSeek-OCR-2代表了'架构创新+token效率优先'的学术研究路线；PaddleOCR-VL-1.5代表了'多任务统一+真实场景鲁棒性'的工业应用路线。
对于大多数企业用户，GLM-OCR 和 PaddleOCR-VL-1.5 是最值得优先评估的两款模型：前者以最低门槛和最低成本提供了市场第一的基准性能，后者则以最强的真实场景鲁棒性和最完善的多语言支持成为企业级复杂文档处理的首选。DeepSeek-OCR-2在token压缩和大规模批处理场景上具有独特优势，但部署复杂度和学术质疑需要在生产采用前进行充分验证。
建议实施路径：在自己的文档数据集上进行A/B测试，而非完全依赖公开基准------不同文档类型、不同语言分布、不同扫描质量下，三款模型的相对表现可能与OmniDocBench有所不同。所有模型均已开源权重，可免费在小规模数据集上完成验证再做生产决策。
报告生成日期：2026年4月10日 | 数据来源：官方技术报告、HuggingFace、GitHub及公开基准测试
本报告基于公开信息整理，模型性能可能随版本更新而变化，建议在生产部署前进行实际验证。