PaddleOCR on 海光 Z100 DCU · 兼容性、性能与生产复现报告

1. 最终结论

PaddleOCR 3.7.0 的 Transformers/PyTorch 路线已在昆山 Z100 上完成端到端功能验证。 实际使用的是用户态 glibc 2.28 loader、GCC 12.2、DTK 26.04，以及海光适配的 Torch 2.7.1，不依赖 PaddlePaddle DCU wheel。

通过设备枚举：1 × Device 66a1 / gfx906

0.2546 s单图稳定态端到端 OCR（v2.1 测试图）

0.49 页/s23 页 Mooncake PDF，稳定态 OCR

0端到端退出码

适用定位：PaddleOCR 是高吞吐文本检测/识别引擎；MinerU 是文档解析 pipeline。两者不应只按“识别字符数”直接判定替代关系。

测试环境与软件配置

层次	验证值	备注
硬件	海光 Z100 / gfx906 / Device 66a1	作业申请 1 张 DCU
系统	CentOS 7.6 / 系统 glibc 2.17	通过用户态 glibc 2.28 绕过 wheel ABI 限制
工具链	GCC 12.2 + DTK 26.04	DTK 提供 HIP/数学库，GCC 提供新版 libstdc++
Python	3.10.14	只读复用已有 Python 基础解释器
Torch	2.7.1+das.opt1.dtk2604 / HIP 6.3.26093	海光适配版，不能用 PyPI 通用 Torch 替换
Transformers	5.17.0 / Hub 1.5.0 / Tokenizers 0.23.1	独立 PaddleOCR 目录内版本
应用	PaddleOCR 3.7.0 / PaddleX 3.7.2	独立 package tree，未改动 MinerU venv

推理后端选择依据

昆山 module 中可用的 DCU Torch 主要停留在 Python 3.7/Torch 1.10；PaddleOCR 3.7/PaddleX 3.7 使用 Python 3.8 语法和现代 Transformers API，直接强装到 Python 3.7 会触发位置参数语法、walrus 表达式和 typing/importlib API 错误。

MinerU 报告中已经验证了更合适的用户态闭包：Python 3.10、Torch 2.7.1、DTK 26.04、用户态 glibc 2.28。本文在不修改 MinerU 的前提下，只读复用其 Torch/运行库，在独立目录安装 PaddleOCR/PaddleX。

计算节点无外网，因此模型在登录节点从 BOS 下载到新 cache；计算节点只设置 HF_HUB_OFFLINE=1、TRANSFORMERS_OFFLINE=1，避免运行时 DNS 超时。

4. 兼容性验证

探针	结果
`torch.cuda.is_available()`	True
设备名 / 架构	Device 66a1 / gfx906:sramecc-:xnack-
GPU 矩阵乘法	cuda:0 上完成并同步
PaddleOCR/PaddleX 导入	3.7.0 / 3.7.2
PP-OCRv5 mobile det	模型加载、检测框输出成功
PP-OCRv5 mobile rec	模型加载、16 行文本识别成功
完整 OCR	`PADDLEOCR_TRANSFORMERS_E2E_OK`，退出码 0

架构边界：gfx906 没有匹配的 HIPBLASLt Tensile kernel；Flash Attention 不可用，Transformers 回退到 Torch native math attention。功能通过，性能不是硬件最优上限。

PaddleOCR 性能测试结果

5.1 单张图片稳定态

指标	实测值
模型冷加载	67.6–80.1 s
首次 warmup	约 14–21.5 s
5 次唯一输入平均	0.2546 s/张
P50 / P95	0.2430 / 0.3013 s
稳定态吞吐	约 3.93 张/s
每次识别行数	16
推理阶段显存	0.212 GB allocated / 0.281 GB reserved

Mooncake-v3 23 页 PDF 测试

阶段	实测值
PDF 渲染（pypdfium2，scale=2.0）	0.7254 s
模型加载	80.0806 s
OCR warmup	21.5097 s
23 页稳定态 OCR	46.9364 s
稳定态平均	2.0404 s/页
P50 / P95	1.9419 / 3.0614 s/页
稳定态吞吐	0.49 页/s
冷启动含 warmup 总耗时	约 149.3 s

与 MinerU 的同文档比较

输入为同一份脱敏后仍保留在集群上的 Mooncake-v3.pdf，23 页、约 0.58 MB。 MinerU 数字来自对应构建报告；PaddleOCR 数字来自本文同一 PDF 的现场复测。

维度	MinerU pipeline	PaddleOCR Transformers
冷启动	146.8 s	约 149.3 s
稳定态	90.5 s / 23 页	46.94 s / 23 页
稳定态单页	3.93 s/页	2.04 s/页
文本字符数	81,072 Markdown 字符	81,550 OCR 字符
结构	标题、表格、图片、公式、middle.json、layout PDF	文本框、文本、置信度
公式/表格	17 行内公式、3 个表格	不提供结构化恢复
图片	23 引用 / 26 文件	不负责图片抽取

结论：纯 OCR 稳态 PaddleOCR 约快 1.9 倍；但 MinerU 是文档解析 pipeline，负责版面、表格、公式和图片。字符数相近不等于精度相同，也不代表 PaddleOCR 能替代 MinerU。

7. 质量与精度边界

本次没有人工标注的逐字符 ground truth，因此不把字符数差异冒充准确率。PaddleOCR 平均置信度为 0.9636，但同一输出抽查仍能看到：

Mooncacke
diversifi ed
work- loads
2O24

MinerU 报告中已核验标题层级、署名、表格数值、公式和图片落盘。对于论文、合同、表格和 PDF 转 Markdown 场景，MinerU 的结构化质量更重要；对于批量纯文字识别、局部重识别和低延迟 OCR，PaddleOCR 更合适。

部署方案

8.1 统一 launcher

系统 glibc 2.17 不能直接承载新 Torch wheel。生产进程必须通过用户态 glibc 2.28 loader，闭包包含 GCC 12.2、DTK 26.04、dcc/gcvm 和 rocm_smi。

<PADDLEOCR_ROOT>/bin/dcu-python your_worker.py

不要直接调用裸 python。不要让 Python 的 spawn 子进程回到裸 sys.executable；独立目录中的 sitecustomize.py 已设置 multiprocessing.set_executable()。

8.2 常驻 worker

每张 DCU 启动一个常驻 PaddleOCR worker。
模型只加载一次，稳定态再接收请求。
队列层限制同一 worker 的并发，避免模型线程安全和显存争用。
worker 健康检查必须包含设备枚举、模型加载、单张图片推理和退出码。
所有模型固定到本地 cache，生产进程设置离线变量，禁止请求路径隐式下载。

8.3 生产验收

torch.cuda.device_count() == 1
torch.cuda.get_device_properties(0).gcnArchName startswith("gfx906")
PADDLEOCR_TRANSFORMERS_E2E_OK
PADDLEOCR_EXIT_RC=0
summary.json exists and chars/lines > 0

9. 复现入口

本报告同目录提供：

文件	用途
`paddleocr_z100_launcher.sh`	用户态 glibc 2.28 + GCC/DTK loader 模板
`paddleocr_z100_benchmark.py`	PDF 渲染、模型加载、warmup、逐页 OCR、显存和文本统计
`paddleocr_z100.slurm`	单卡 Z100 Slurm 作业模板
`README.md`	安装、模型 cache、离线运行和生产建议

module purge
module load compiler/gcc/12.2.0 compiler/dtk/26.04
export PADDLE_PDX_CACHE_HOME=<PADDLEOCR_ROOT>/cache
export PADDLE_PDX_MODEL_SOURCE=BOS
export HF_HUB_OFFLINE=1 TRANSFORMERS_OFFLINE=1

<PADDLEOCR_ROOT>/bin/dcu-python \
  paddleocr_z100_benchmark.py \
  <INPUT_PDF> <OUTPUT_DIR>

测试结果与验收

验收项	结果
独立目录	通过；未修改 MinerU venv
模型离线 cache	PP-OCRv5 mobile det/rec safetensors
真实 Z100	1 张 Device 66a1 / gfx906
端到端 OCR	16 行测试图文本；退出码 0
同文档 23 页	23 页完成；1,513 行、81,550 字符
性能统计	summary.json 已生成

报告公开版不包含账号、主机、节点、作业号、真实绝对目录和内部服务地址。实际复现时由部署者在本地 launcher 和 Slurm 模板中填入占位符。

11. 已知限制与后续建议

精度：当前没有正式 OCR ground truth。生产上线前应补充业务数据集的字符级、行级或字段级评测。

性能：当前 gfx906 的 attention/BLAS 路径存在架构回退；升级 DTK 或 Torch 后需要重新 benchmark。

模型：本文固定 PP-OCRv5 mobile det/rec。PP-OCRv6 默认路径需要另外下载模型，不能在计算节点临时访问外网。

并发：当前只测单卡单 worker。多卡生产建议每卡一个进程，先做 1/2/4 卡吞吐和稳定性测试。

文档解析：如果需求包括表格、公式、图片和 Markdown 结构，继续使用 MinerU；PaddleOCR 作为 OCR 子服务更合理。

环境漂移：loader、模型 cache、module、Torch、Transformers 任何一项移动或升级，都要重新执行 §9 复现。