OCR 文字识别速查（CPU 服务器部署 · 文档/票据识别服务）¶

版本基线： PaddleOCR 3.7.0（2026-06-11，默认模型已切换为 PP-OCRv6；PP-OCRv5 仍可用；配套 paddlex ≥3.7 / paddlepaddle 3.3.1 CPU 版）· RapidOCR 3.9.2（2026-07-21，默认集成 PP-OCRv6 small ONNX 模型）· Tesseract 5.5.3（2026-07-24）· EasyOCR 1.7.2（2024-09，长期未更新）· Umi-OCR v2.1.5（最新 release，Windows/Linux 桌面 GUI，基于 RapidOCR/Paddle 双引擎插件，更新放缓；HTTP API :1224）· Surya 0.17.x / Surya 2（了解）· PaddleOCR 官方服务化 = PaddleX serving（paddlex --serve，FastAPI :8080，随 PaddleX 3.x 活跃迭代）· MinerU 3.4（2026-06-18，OpenDataLab/上海AI Lab；3.1.0 起 AGPL-3.0 改为基于 Apache-2.0 的 MinerU 开源许可；pipeline 后端纯 CPU 可跑，OCR 已升级 PP-OCRv6）· Docling 2.148.0（2026-11-06 核对，IBM→LF AI & Data，MIT，默认纯 CPU）· Surya OCR 2（650M 单 VLM，2026-05；代码 Apache-2.0 / 权重修改版 OpenRAIL-M）· olmOCR 0.4.27（2026-03-12，AI2，Apache-2.0，7B VLM 需 GPU）（核对日期 2026-11-11，来源：GitHub Releases / PyPI / 官网）

宿主机约束（必读）： Windows Server，2×Xeon Gold 6138（40 核 80 线程）、256GB 内存、F 盘 895G 剩 862G。无独立 GPU，纯 CPU 推理。所有服务以 Docker 容器部署，产物只存 F:\EricLiu\ 下；模型权重统一放 F:\EricLiu\labs\models\。

业务目标： 文档/票据识别 HTTP 服务（图片、扫描件、PDF → 结构化 JSON）。

1. 选型对比¶

项目	定位	中文效果	CPU 速度（40 核 Xeon，单张 A4 图）	内存	许可证	推荐场景
PaddleOCR 3.x	百度工业级 OCR + 文档解析产线（检测/识别/版面/表格）	优秀（PP-OCRv6/v5，OmniDocBench 中文 edit distance 0.055，全场最佳档）	PP-OCRv5/v6 mobile：约 0.3–1 秒/张；server 版：约 2–5 秒/张	1–2GB（OCR 产线）；PP-StructureV3 文档解析约 4–8GB	Apache-2.0（2026-11 复核仍为 Apache-2.0）	中文文档/票据主力：需要版面、表格、方向矫正时
RapidOCR 3.x	Paddle 模型的 ONNX 离线推理封装	优秀（默认即 PP-OCRv6 small ONNX，效果接近 PaddleOCR）	约 0.2–0.8 秒/张（onnxruntime CPU，比 PaddleOCR 略快）	<1GB（whl 含模型约 29.5MB）	Apache-2.0	轻量服务首选：只要文字+坐标+置信度，不要 Paddle 全家桶
Sdcb.SimdPaddleOCR	.NET 进程内 OCR（纯 C# 托管 ONNX 解释器 + 手写 SIMD Kernel，PP-OCRv6 DET/CLS/REC）	优秀（与 PP-OCRv6 small 同源，1.4.x CLS 评测 100%）	约 0.3 秒/张（tiny 档，进程内无 IPC 开销）	<500MB（模型嵌在程序集资源）	Apache-2.0（1.4.2）	.NET 应用内嵌首选：零原生依赖、xcopy/NativeAOT 可分发；仅 CPU、仅文字识别（无版面/表格）
Tesseract 5	传统引擎（LSTM），CPU 原生	差：中文 edit distance 0.551（PaddleOCR 的 10 倍）；且 270° 旋转页近乎全错（0.969）	约 1–3 秒/页，内存 <500MB	<500MB	Apache-2.0	仅干净英文印刷件；中文票据不要用，仅作对比基线
EasyOCR	PyTorch 多语场景文字	一般（中文 edit distance 0.398，落后 Paddle 一大截）	约 2–10 秒/张（CPU，PyTorch 开销大）	2–4GB	Apache-2.0	多语场景文字原型；2024 年后未更新，不推荐新项目
Umi-OCR	Windows 桌面 GUI 工具（RapidOCR 内核）	良好	桌面交互级	<1GB	GPL-3.0（主体）	个人桌面手动截图识别；不适合做服务器服务，了解即可
Surya	现代 OCR + 版面/阅读顺序/表格（0.65B 参数）	良好（中文 edit distance 0.123）	CPU 可跑但重：数秒/页，批量场景按官方建议需 GPU	2GB+	代码 Apache-2.0；权重另受 Open Rail-M 附加条款约束	多语版面/阅读顺序，商用前核查权重条款；了解即可

⚠️ 速度为 2026-11 基于公开基准（OmniDocBench CVPR 2025、各项目 README）在 Xeon Gold 6138 上的估算量级，上线前必须用真实票据样本实测（见第 6 节守则）。

1.1 整合/聚合型项目（推荐与回避）¶

推荐逻辑：服务端主力仍是 RapidOCR/PaddleOCR 直连 + 自封装（第 4 节，可控校验/耗时上报）；官方 PaddleX serving 作为"不想自写封装"时的现成替代；Umi-OCR 定位是桌面手动工具，不进服务链路。

项目	定位	维护状态	许可证	CPU 可行性	结论：推荐用/选配/回避
PaddleOCR 官方 serving（PaddleX serving）	官方现成 HTTP 服务：`paddlex --install serving` 后 `paddlex --serve --pipeline OCR`（FastAPI/Uvicorn，默认 :8080）；另有基于 Triton 的高稳定性方案	活跃（随 PaddleOCR/PaddleX 3.x，约每 2 周发版）	Apache-2.0	✅ 无 GPU 时自动回退 CPU（`--device` 可显式指定）；支持 `--use_hpip` 高性能推理	选配：需要版面/表格/PDF 全产线现成 API、不想自写封装时用；官方自述新 serving 方案性能可能不及 2.x 旧 PaddleServing，且默认端口/模型缓存需按本库规范（`labs\models\paddlex`、端口绑 127.0.0.1）调整。本库已有自封装（§4）故默认不走它
Umi-OCR v2.1.5 (hiroi-sora)	Windows/Linux 桌面 GUI（RapidOCR/Paddle 双引擎插件），带 HTTP API（默认 127.0.0.1:1224：`/api/ocr`、`/api/doc/*`、`/api/qrcode`）与命令行	更新放缓：最新 release v2.1.5（2025-03 前后），其后无新版本；~45k star	GPL-3.0	✅ 桌面端纯 CPU（Rapid 引擎版兼容性更好；Paddle 引擎版不兼容奔腾/赛扬/凌动）	桌面选配 / 服务端回避：个人手动截图/批量 PDF 识别很好用（忽略区域、双层 PDF、排版解析）；但不进服务链路——① GUI 桌面应用架构，Docker 路线（Umi-OCR_runtime_linux）非一等公民；② 官方文档明示"后端并发能力弱，不要并发调用"，偶发 ECONNREFUSED 需重试；③ 更新放缓。服务端识别走 RapidOCR/PaddleOCR（§2）

推荐结论（文档/票据服务）： - 首选 = RapidOCR 3.9.2（Python 服务，必须 pin 版本——3.8.2 曾被 PyPI yank）：轻量离线、CPU 快、默认即 PP-OCRv6 small，文字+坐标+置信度足够票据字段抽取。 - 增强首选 = PaddleOCR 3.7（PP-OCRv6）：需要版面分析、表格结构化、文档矫正、PDF→Markdown 时升级到 PP-StructureV3 产线。 - .NET 场景首选 = Sdcb.SimdPaddleOCR 1.4.2：纯 C# 零原生依赖、进程内无 IPC，随应用分发最省事（见 DotNet 分册）。 - 选配 = PaddleX serving（官方现成 HTTP 产线，不想自写封装时）/ Umi-OCR（仅桌面手动截图、批量 PDF，不进服务链路）。 - 回避 = Tesseract 做中文票据：中文 edit distance 0.551，是 PaddleOCR 的 10 倍，270° 旋转页近乎全错；只留作英文印刷件基线交叉验证。 - 整册 PDF 解析（2026-11 新增维度，详见 §1.2）= 选配 Docling（MIT，默认纯 CPU）/ 候选 MinerU 3.x pipeline（复杂版面质量更高，注意许可变迁）；olmOCR 与 Surya 2 权重路线本机回避/受限。

1.2 PDF/文档智能解析（新维度：单图 OCR vs 整册解析的分工）¶

分工一句话：本分册 §1 主表（RapidOCR/PaddleOCR）解决的是单图/单页 OCR——给"文字 + 坐标 + 置信度"，服务票据字段抽取；本小节的项目解决的是整册 PDF → Markdown/JSON 的结构化解析——版面分析、阅读顺序还原、公式转 LaTeX、表格转 HTML、跨页合并，面向 RAG/知识库喂料。两者不互替：票据走 RapidOCR/PaddleOCR，整册文档批量解析才引入本小节的重量级管线。

项目	定位	CPU 可行性	内存 / 权重体积	许可证	结论：推荐用/选配/回避
MinerU (OpenDataLab / 上海AI Lab)	PDF/图片/DOCX/PPTX/XLSX → Markdown/JSON；双后端：pipeline（DocLayout-YOLO 版面 + PaddleOCR 系 OCR + UniMERNet 公式 + 表格模型）与 VLM（MinerU2.5-Pro 1.2B 整页读图）	✅ pipeline 后端纯 CPU 可跑（离线批量，速度慢）；VLM 后端需 GPU	4-8GB / pipeline 需下载数 GB 多模型权重	许可变迁须警惕：早期 AGPL-3.0；3.1.0（2026-04）起改为基于 Apache-2.0 的 MinerU 开源许可（允许商用/修改/分发，但 MAU>1 亿或月收入 >$2000 万需另购商业授权）；不同版本模型权重许可可能不一致，下载时逐个核对	选配（复杂版面批量解析候选）：3.4（2026-06-18）起 pipeline 后端 OCR 升级 PP-OCRv6，OmniDocBench v1.6 精度 +11%、OCR 提速约 2×；双栏论文/公式/表格还原质量第一梯队；Windows 依赖坑多，建议 Docker/Linux 跑
Docling (IBM Research → LF AI & Data)	PDF/DOCX/PPTX/XLSX/HTML/EPUB/邮件/音视频 → 无损 DoclingDocument（可导出 Markdown/JSON/HTML/DocTags）；版面+阅读顺序+表格结构+公式；docling-serve 提供 HTTP API	✅✅ 默认纯 CPU 即可运行（模型首次下载后全离线）；可选 GraniteDocling-258M VLM 管线处理难页	2-4GB / 数百 MB 级模型	MIT（代码；部分可选模型如 Granite Vision/EasyOCR 权重另有许可，使用前查模型卡）	选配（许可证最干净的整册解析首选）：v2.148.0（2026-11-06 核对，每周多发版须 pin）；格式覆盖最广、原生集成 LangChain/LlamaIndex/MCP；最难扫描件的表格/公式精度略逊 MinerU
Surya 2 (Datalab，§1 主表已有旧版行，此处并入 2.x 现状)	650M 参数单 VLM 一体四任务：全页 OCR + 版面 + 阅读顺序 + 表格（olmOCR-bench 83.3%，<3B 参数最佳档；91 语种 87.2%）	⚠️ 经 llama.cpp 后端可跑 CPU/Apple Silicon（`SURYA_INFERENCE_BACKEND` 切换），吞吐远低于 vllm/GPU 路径	2-4GB / 650M ≈ 1.3GB（fp16）	代码 Apache-2.0（早期版本为 GPL，已改）；权重修改版 AI Pubs OpenRAIL-M：研究/个人/收入或融资 <$5M 免费，超出需付费商业授权	选配/商用回避：架构与 §1 主表的 0.17.x 已完全不同（0.x 是多模型流水线，2.x 是单一 VLM）；权重许可门槛 + 本机吞吐有限，商用前必须过法务
olmOCR (Allen Institute for AI)	7B VLM（Qwen2.5-VL 基，olmOCR-2-7B）PDF/图片 → Markdown；olmOCR-bench 出品方（v0.4.0 综合分 82.4）	❌ 需 GPU（FP8，~12GB 显存级，官方明示"7B VLM 需要 GPU"），纯 CPU 不可行	权重 ~15GB（7B）	Apache-2.0（代码+权重均宽松）	了解/回避本机：v0.4.27（2026-03-12）；许可最干净但硬件不匹配，仅作基准参考与云端观察

⚠️ 上述 CPU 可行性均为官方声明/公开基准推定的量级；MinerU pipeline 在本机 40 核上的页耗时、Docling 单页耗时，上线前须用真实文档实测回填（见第 6 节守则）。

2. 安装¶

2.1 PaddleOCR（CPU 版 paddlepaddle）¶

# 1) 先装飞桨 CPU 版（不要装 GPU 版，省 2GB+ CUDA 依赖）
pip install paddlepaddle==3.3.1        # CPU wheel，支持 Python 3.9–3.13
# 2) 再装 PaddleOCR
pip install paddleocr==3.7.0           # 文档解析/表格等全功能: pip install "paddleocr[all]"
# 首次运行自动下载模型；指定缓存目录
# Windows: set PADDLE_PDX_CACHE_HOME=F:\EricLiu\labs\models\paddlex
export PADDLE_PDX_CACHE_HOME=/f/EricLiu/labs/models/paddlex

PaddleOCR 3.x 要点（相对 2.x 的变化，写代码时注意）： - 底层融合 PaddleX 产线体系：paddleocr.PaddleOCR 实际是 PP-OCRv5/v6 产线入口；3.x 起统一 Python API 与 CLI。 - 默认模型：3.7.0 起为 PP-OCRv6（tiny/small/medium），此前 3.x 默认 PP-OCRv5；text_recognition_model_name 可显式指定（如 PP-OCRv5_server_rec 提升精度）。 - 新增开关：use_doc_orientation_classify / use_doc_unwarping / use_textline_orientation（默认全开，关掉可提速）。 - 旧版 2.x 写法（ocr.ocr(img)）仍兼容，但新代码统一用 predict()。

2.2 RapidOCR（onnx 离线，推荐轻量路径）¶

pip install rapidocr==3.9.2 onnxruntime
# 模型已内置在包里（PP-OCRv6 det/rec small），开箱即用、离线可跑

from rapidocr import RapidOCR
engine = RapidOCR()
result = engine("receipt.png")
print(result.txts)      # 文字行列表
print(result.boxes)     # 四点坐标
print(result.scores)    # 置信度

注意：RapidOCR 3.x 与旧包 rapidocr_onnxruntime 的教程/结果字段不兼容，网上旧示例勿直接套用；3.8.2 曾因缺配置文件被 PyPI yank，生产必须 pin 版本。

2.3 Tesseract（对比说明）¶

Windows 装 exe（UB-Mannheim 构建版）+ chi_sim 语言包；Python 仅通过 pytesseract 调用 exe。
与神经 OCR 的本质区别：无检测/识别分离的深度产线，对倾斜、拍照、复杂版面、中文都明显更差（见第 1 节实测数据），且 270° 旋转页会输出"看起来正常实为乱码"的结果。
结论：本项目仅当"多引擎交叉验证基线"，不做中文票据主力；使用时必须前置方向检测。

3. 高频用法¶

3.1 PaddleOCR（图片 / 批量 / PDF）¶

from paddleocr import PaddleOCR

ocr = PaddleOCR(
    use_doc_orientation_classify=False,  # 已知方向时关闭，提速
    use_doc_unwarping=False,
    use_textline_orientation=True,       # 行方向分类（票据可能整行倒置，建议开）
    # text_recognition_model_name="PP-OCRv5_server_rec",  # 精度优先时换 server 版
)
# 单图
result = ocr.predict("invoice.png")
for res in result:
    for text, score, box in zip(res["rec_texts"], res["rec_scores"], res["rec_boxes"]):
        print(text, round(score, 3), box.tolist())

# 批量
results = ocr.predict(["a.png", "b.png", "c.png"])

# PDF（自动逐页渲染）
results = ocr.predict("contract.pdf")

CLI：paddleocr ocr -i invoice.png --use_doc_orientation_classify False

3.2 RapidOCR（批量）¶

from rapidocr import RapidOCR
from pathlib import Path

engine = RapidOCR()
for img in Path(r"F:\EricLiu\ocr_jobs").glob("*.png"):
    r = engine(str(img))
    for txt, box, score in zip(r.txts or [], r.boxes or [], r.scores or []):
        print(img.name, txt, score)

3.3 PDF→文本（无 Paddle 重产线时）¶

RapidOCR 不直接吃 PDF，先用 pdf2image/pymupdf 转页图再喂：

import fitz  # pip install pymupdf
from rapidocr import RapidOCR
engine = RapidOCR()
doc = fitz.open("contract.pdf")
for page in doc:
    pix = page.get_pixmap(dpi=200)          # 200dpi 平衡速度与精度
    img = pix.tobytes("png")
    r = engine(img)
    print("\n".join(r.txts or []))

3.4 表格识别现状¶

表格结构化（输出行列 HTML/Excel）在 PaddleOCR 3.x 属于 PP-StructureV3 产线（paddleocr paddle_pipeline PP-StructureV3 -i doc.pdf），含版面分析+表格识别+公式+阅读顺序；CPU 上单页约 5–20 秒、内存 4–8GB，适合离线批量而非实时接口。
RapidOCR / Tesseract / EasyOCR 不做表格结构还原，只给文字+坐标，需自己按坐标聚类恢复行列。
结论：票据/合同需要表格还原时才启用 PP-StructureV3；纯字段抽取用 OCR 文字+坐标即可。

4. 服务化：FastAPI + docker-compose¶

4.1 app.py（RapidOCR 为主，图片上传返回 JSON，含 /health）¶

import time
from fastapi import FastAPI, UploadFile, File, HTTPException
from rapidocr import RapidOCR
import numpy as np

engine = RapidOCR()
app = FastAPI(title="OCR Service")

@app.get("/health")
def health():
    return {"status": "ok", "engine": "rapidocr-3.9.2", "model": "PP-OCRv6-small-onnx"}

@app.post("/ocr")
async def ocr(file: UploadFile = File(...)):
    if file.content_type not in ("image/png", "image/jpeg", "image/bmp", "image/webp"):
        raise HTTPException(415, f"unsupported type: {file.content_type}")
    data = await file.read()
    if len(data) > 20 * 1024 * 1024:
        raise HTTPException(413, "file too large (>20MB)")
    t0 = time.time()
    result = engine(np.frombuffer(data, np.uint8))
    items = []
    if result.txts:
        for txt, box, score in zip(result.txts, result.boxes, result.scores):
            items.append({"text": txt, "score": round(float(score), 4),
                          "box": [[int(p[0]), int(p[1])] for p in box]})
    return {"engine": "rapidocr", "lines": items,
            "count": len(items), "cost_ms": round((time.time() - t0) * 1000)}

PaddleOCR 版只需替换引擎两行（模型缓存挂载见 compose）：

from paddleocr import PaddleOCR
engine = PaddleOCR(use_doc_orientation_classify=False, use_doc_unwarping=False)
# 返回 res["rec_texts"] / res["rec_scores"] / res["rec_boxes"]，组 JSON 同上

4.2 Dockerfile + docker-compose.yml（放 `F:\EricLiu\labs\docker\ocr\`）¶

# RapidOCR 版（轻量，约 python-slim + opencv 依赖）
FROM python:3.11-slim
RUN apt-get update && apt-get install -y --no-install-recommends libglib2.0-0 libgl1 && rm -rf /var/lib/apt/lists/*
RUN pip install --no-cache-dir rapidocr==3.9.2 onnxruntime fastapi uvicorn python-multipart numpy
COPY app.py /app/app.py
WORKDIR /app

services:
  ocr-rapid:
    build: .
    container_name: ocr-rapidocr
    ports: ["127.0.0.1:8102:8000"]
    volumes:
      - F:\EricLiu\ocr_jobs:/data/jobs          # 产物/任务只放 F:\EricLiu
    cpus: 4
    deploy:
      resources:
        limits: { memory: 2G }
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "python", "-c", "import urllib.request as u; u.urlopen('http://127.0.0.1:8000/health')"]
      interval: 30s
      timeout: 5s

  # 需要版面/表格/PDF 解析时再启用
  ocr-paddle:
    image: python:3.11-slim                     # 先 build 含 paddlepaddle 的镜像，此处示意
    entrypoint: ["python", "/app/app.py"]
    ports: ["127.0.0.1:8103:8000"]
    environment:
      - PADDLE_PDX_CACHE_HOME=/models/paddlex   # 权重只放 labs\models
    volumes:
      - F:\EricLiu\labs\models\paddlex:/models/paddlex
      - F:\EricLiu\ocr_jobs:/data/jobs
    cpus: 8
    deploy:
      resources:
        limits: { memory: 8G }

端口只绑 127.0.0.1，对外暴露由前端/网关决定。

5. 排障¶

症状	原因	处置
中文识别差/出乱码	用了 Tesseract / 语言包没装 / 图片分辨率过低	中文一律走 PaddleOCR/RapidOCR；输入图像短边 ≥320px、150dpi 以上；`text_recognition_model_name` 换 server 版模型提升精度
倾斜/旋转识别失败	页面 90°/270° 旋转、拍照透视	PaddleOCR 开 `use_doc_orientation_classify` + `use_doc_unwarping` + `use_textline_orientation`；RapidOCR 前置自写方向检测（Tesseract 对 270° 尤其致命，见第 1 节数据）
表格线/结构丢失	只跑了普通 OCR	表格结构还原必须用 PP-StructureV3 产线；普通 OCR 结果需按 box 坐标自聚类
容器 OOM / 变慢	PP-StructureV3 内存峰值大、并发堆积	普通识别用 RapidOCR（限 2G）；文档解析独立容器限 8G；接口加并发上限（uvicorn workers 数 = 核数配额）
首次请求慢	模型冷加载	启动时顶层实例化引擎（如上文）；PaddleOCR 用 `PADDLE_PDX_CACHE_HOME` 预置权重，容器内禁在线下载
opencv 容器报错 libGL	slim 镜像缺系统库	Dockerfile 加 `apt-get install libglib2.0-0 libgl1`（见 4.2）
模型下载慢/失败	BOSC/ModelScope 网络	联网机下载→拷到 `F:\EricLiu\labs\models\paddlex\`→容器挂载并设缓存环境变量；RapidOCR 模型已内置无此问题
PDF 识别质量差	渲染 dpi 不当	pymupdf `dpi=200` 左右调优；扫描件优先要原始分辨率

6. AI 操作守则¶

先读后写：改配置/代码前先读现有文件；模型权重只放 F:\EricLiu\labs\models\，产物只写 F:\EricLiu\ 下，禁止写 C 盘/系统目录。
版本固定：生产一律 pin 版本（RapidOCR 尤其要 pin——3.8.2 曾被 yank）。升级前查 GitHub Releases changelog；PaddleOCR 3.x 大版本切换默认模型（v5→v6），升级必须重跑回归样本。
实测优先：本文 CPU 速度/内存是估算量级。每次换模型或引擎，用 ≥10 张真实票据/文档跑分（耗时、内存峰值、字段准确率），结果回填选型表。
诚实上报：/health 与响应体携带真实耗时；识别置信度低于阈值（建议 0.6）的行必须原样返回 score，由上层决定人工复核，不得静默丢弃。
离线优先：容器内禁止运行时在线拉模型；权重经联网机→labs\models\ 同步后挂载。
资源隔离：RapidOCR 容器 4 核 2G 起步；PaddleOCR/PP-StructureV3 独立容器 8 核 8G，避免互相挤占。
输入校验：接口必须校验 content_type 与大小上限（防恶意文件）；图像解码失败返回 4xx 而非 500。
破坏性操作需确认：删除模型缓存、清理 ocr_jobs、重建卷前必须向用户确认。
隐私：票据含敏感信息，上传文件处理完即删，禁止送外部 OCR 云服务。