当前Agent场景下，Agent经常要处理截图、拍照、扫描件，图中文字提取仍是关键一步。和直接让多模态大模型读字相比，专用OCR通常更快、更省算力，纯读字也更稳，CPU就能部署，所以在检索、票据、截图问答这类日常链路里更常见；复杂版面、表格和公式，再交给文档解析或VLM。
*本图由AI生成，仅供示意
PaddleOCR有 PP-OCR、PP-Structure、PP-ChatOCR、 PaddleOCR-VL等产线，通用OCR：PP-OCR先定位文字再识别，模型小，CPU就能部署；PP-StructureV3在OCR之上做版面、表格、公式，适合把扫描件整理成Markdown，硬件要求和通用 OCR接近；PaddleOCR-VL-1.6换成0.9B视觉语言模型，按页做文档理解，复杂版面更强，但推理走生成，需要NPU或GPU。
本文先从PP-OCR开始实测，尝试在OpenAtom openEuler（简称：“openEuler”或“开源欧拉”）24.03 上，部署 PP-OCRv5和 PP-OCRv6，使用鲲鹏CPU，在同一套进程池、同一份数据集，测试批量吞吐和单页时延，关注PP-OCRv5和 PP-OCRv6的性能，不涉及准确率和具体环境配置细节，具体安装流程可以参考文末附带的官方教程。
指标是 pages/s（一页图一次请求，和 VL 压测的 req/s 同口径）和端到端时延。不涉及 TTFT / tok/s指标。
▐ 2.1 环境与版本
▐ 2.2 冒烟测试
▲官方 demo 图，用来确认识别链路能跑通
冒烟测试：
source /paddle_ocr/.venv_client/bin/activateexport PADDLE_PDX_DISABLE_MODEL_SOURCE_CHECK=Truepython << 'EOF'from paddleocr import PaddleOCRocr = PaddleOCR(text_detection_model_name="PP-OCRv5_server_det",text_detection_model_dir="/paddle_ocr/cpu_pipeline/models/PP-OCRv5_server_det_onnx",text_recognition_model_name="PP-OCRv5_server_rec",text_recognition_model_dir="/paddle_ocr/cpu_pipeline/models/PP-OCRv5_server_rec_onnx",engine="onnxruntime",device="cpu",cpu_threads=8,enable_mkldnn=False,use_doc_orientation_classify=False,use_doc_unwarping=False,use_textline_orientation=False,)output = ocr.predict("/paddle_ocr/demo/paddleocr_vl_demo.png")for i, res in enumerate(output):res.print()print("SMOKE_OK")EOF
跑通标志：终端打印 SMOKE_OK，并能看到识别出的文字行，实测如下：
矩阵只用 OmniDocBench 子集（全量 1651 页中抽 40 页）。一页图一次请求，warmup 2 页，请求一次打满。
并发用进程池，每进程一份识别实例。n = max(2, ceil(1.5×c))。
本文压测使用多进程的方式并发：主进程按并发 c 拉起进程池，每个子进程加载一份检测 + 识别（ONNX Runtime，CPU），直接对本地图片做 predict()。v5、v6 压力对齐：同一份 OmniDocBench subset40、同一组c / n、warmup 2 页、请求一次打满。
▐ 4.1 压测步骤
以 c=12、n=18 为例：
# PP-OCRv5：source /paddle_ocr/.venv_client/bin/activate/paddle_ocr/.venv_client/bin/python /paddle_ocr/cpu_pipeline/bench_cpu_pipeline.py \--dataset /paddle_ocr/datasets/OmniDocBench/omnidocbench_subset40.jsonl \--c 12 \--n 18 \--warmup 2 \--det-dir /paddle_ocr/cpu_pipeline/models/PP-OCRv5_server_det_onnx \--rec-dir /paddle_ocr/cpu_pipeline/models/PP-OCRv5_server_rec_onnx \--out-json /paddle_ocr/bench_results/matrix_cpu_pipeline/by_cell/c12_n18.json# PP-OCRv6：source /paddle_ocr/.venv_v6serve/bin/activate/paddle_ocr/.venv_v6serve/bin/python /paddle_ocr/v6serve/bench_v6_pipeline.py \--dataset /paddle_ocr/datasets/OmniDocBench/omnidocbench_subset40.jsonl \--c 12 \--n 18 \--warmup 2 \--det-dir /paddle_ocr/v6serve/models/PP-OCRv6_medium_det_onnx \--rec-dir /paddle_ocr/v6serve/models/PP-OCRv6_medium_rec_onnx \--out-json /paddle_ocr/bench_results/matrix_cpu_v6pipeline/by_cell/c12_n18.json
每个子进程里的识别实例等价于冒烟时的 PaddleOCR(..., engine="onnxruntime", device="cpu")，并关掉方向 / 矫正 / 行方向。cpu_threads = max(1, min(16, nproc/c))。进程用 spawn启动，避免 fork 后再加载 Paddle。
▐ 4.2 测试结果
PP-OCRv5：
PP-OCRv6：
同一台机器、同一套进程池。v6 低并发中位约 3.0s（v5 约 3.8～3.9s），吞吐在 c=12 见顶 0.70 pages/s（v5 为 0.58），大约快两成。两边都是 c=12 最好，再往上时延拉长、pages/s 回落；c≥16 时 v6 吞吐掉得更明显，批量仍宜停在 c=12 附近。
要在 openEuler 和鲲鹏 CPU 上做传统 OCR，PP-OCRv5 / v6 加 ONNX Runtime 都能跑通。同样环境、同样压法，v6 峰值更高、低并发更省时（c=12：0.70 vs 0.58 pages/s；c=1 中位约 3.0s vs 3.8s）。
批量吞吐把并发放在 c=12 附近；要单页时延低的话，把 c 留在 1～2。c≥16 两边都会掉，v6 掉得更明显。
这是检测加识别，复杂版面、公式、跨栏解析不能按 PaddleOCR-VL-1.6 的效果来预期。
下一篇文章将会基于相同环境，实测 PaddleOCR-VL-1.6 在 CPU 和 NPU 上运行的性能，以上实测数据可以作为对比。
PaddleOCR 通用 OCR：
https://www.paddleocr.ai/latest/version3.x/pipeline_usage/OCR.html
OmniDocBench：
https://huggingface.co/datasets/opendatalab/OmniDocBench
本专项聚焦 openEuler 系统 AI 北向软件生态适配与性能优化，围绕大、中、小模型全场景推理、训练需求，完成 SGLang、Ollama、vLLM、PaddleOCR 等主流 AI 框架及工具链的适配兼容与性能调优，覆盖大模型推理加速、轻量化模型部署、向量语义编码、语义重排、多场景 OCR 识别等核心AI能力。专项打通系统层与 AI 应用框架的适配壁垒，解决 openEuler 环境下 AI 模型框架部署兼容差、运行低效、适配碎片化等问题，搭建标准化、高性能、全适配的北向 AI 软件栈，充分释放系统异构算力，为开发者提供开箱即用的大模型开发、微调与部署环境，完善从底层算力到上层 AI 应用的全链路生态支撑。
-END-
供稿 | 欧阳庆
编辑 | 丘云
校审 | 赵家麒、郑振宇、刘彦飞
关注我们，了解更多
▼
