一、 引言
光学字符识别（OCR）是计算机视觉中最基础也最具商业价值的任务之一。从身份证识别、发票录入到文档数字化，几乎每个行业都需要"把图像里的文字变成可编辑文本"。然而传统方案常陷入两难：要么模型庞大、依赖云端 GPU，难以在边缘落地；要么精度不足，遇到倾斜、竖排、手写等场景明显退化。
百度飞桨开源的 PP-OCR 系列正是为解决这一矛盾而生。它以"超轻量"著称，整套系统可压缩到几 MB，却能在 CPU 乃至移动端跑出接近重型模型的精度。本文围绕 PP-OCR 的算法原理、典型应用场景，以及在国科环宇旗下土星云 SE110S 系列边缘设备上的部署实践展开。
二、PP-OCR 算法原理
2.1 总体架构：三段式流水线
PP-OCR 采用"检测---方向分类---识别"三段式流水线：文本检测定位图像中的文本区域，方向分类判断文本方向（0° 或 180°）并将倒置文字矫正，文本识别再把文本行图像转换为字符序列。三个环节把"在哪里""什么方向""什么字"解耦，每个模块都可独立轻量化，这是 PP-OCR 兼顾精度与效率的关键。
2.2 文本检测：基于可微二值化的 DBNet 系列
检测器采用 DBNet（可微二值化）。与传统"分割 + 固定阈值后处理"不同，DBNet 将二值化阈值作为网络可学习的参数，使分割结果更贴近文本边界，同时简化后处理，在速度与精度上双赢。
到 PP-OCRv4，检测模型升级为 DBNet++：LK-PAN 以大感受野的路径聚合网络融合多尺度特征，RSE-FPN 在特征金字塔中加入残差注意力以增强密集小文本感知，DML 则让检测与识别模型互学习以提升鲁棒性。
2.3 文本方向分类：轻量级分类器
方向分类器本质上是极轻量的图像分类网络，常用 MobileNetV3 或 SVTR-Light 骨干，把文本行判为 0° 或 180° 两类。看似简单，却在证件拍摄、票据扫描等场景中至关重要------倒置文字不矫正，识别准确率会显著下降。
2.4 文本识别：SVTR_LCNet 与 CTC
PP-OCRv4 的识别模型基于 SVTR 思想，采用 SVTR_LCNet 轻量混合架构：主干为 PP-LCNet，结合 Transformer 的全局上下文建模，兼顾局部笔画形态与全局序列语义。训练上采用 GTC 策略，用注意力解码器引导 CTC 训练，兼顾全局依赖建模与高效序列识别，尤其适合中文与长文本场景。
2.5 PP-OCRv5：五百万参数挑战十亿级模型
最新一代 PP-OCRv5 把"轻量"推向极致：整个系统仅约五百万参数，单一模型覆盖简中、繁中、英文、日文、拼音等文字类型，并增强手写、竖排、生僻字等挑战性场景。官方评测显示，其加权识别精度较同参数量上一代提升约 27 个百分点，达到十亿级视觉语言模型（VLM）的水平，而体积与推理开销却低几个数量级------这正是其适合边缘部署的根本原因。
三、典型应用场景
凭借轻量与高精度，PP-OCR 已广泛落地于多个行业：发票、银行回单、报销单据等票据自动录入，加速财务流程；身份证、护照、营业执照等证件识别核验，服务于政务与金融柜面；纸质档案、书籍、合同扫描转电子文本，配合版面分析实现文档理解；物流面单、运单、快递标签识别，可配合多路摄像头实现产线实时读取；工业场景中的产品铭牌、序列号读取支撑质量追溯；教育场景的试卷批改、手写识别与会议材料提取同样受益。
四、在土星云 SE110S 系列上的部署实践
4.1 SE110S 系列平台概览
土星云 SE110S 系列是面向智能边缘场景的工业级边缘计算设备，全密封无风扇、宽温工作，适合 7×24 小时运行。其中 SE110S-WA32 基于第三代 AI 推理芯片 BM1684X，提供 32 TOPS INT8、16 TFLOPS FP16 推理能力，配 8 核 ARM A53 与 16GB 内存；SE110S-WB16 基于 BM1688，面向更低功耗场景。
PP-OCR 的部署可直接复用开源项目 sophon-demo 的 PP-OCR 例程：支持 BM1684X、BM1688、CV186X 等平台与 FP32/FP16/INT8 精度，提供 C++（BMCV 预处理）和 Python（OpenCV）两套推理实现，支持单/多/组合 batch，灵活适配不同吞吐需求。
4.2 部署整体流程
整体分为四步：环境准备、模型获取与转换、模型编译、推理验证。
第一步，环境准备。SE110S 属于 SoC 平台，出厂时已预装 libsophon、sophon-opencv 等运行库，可直接运行；开发阶段还需一台 x86 主机用于模型编译与 C++ 交叉编译。
第二步，模型获取与转换。官方例程提供 scripts/download.sh 一键下载已编译好的 BModel 与 ICDAR-2019 测试数据集；若需自定义，可从 PaddleOCR 官方仓库获取 PP-OCRv4/v5 模型，用 paddle2onnx 导出 ONNX：
|-------------------------------------------------------------------------------------------------------------------------------------------|
| paddle2onnx --model_dir {model_dir} \ --params_filename inference.pdiparams \ --model_filename inference.json \ --save_file model.onnx |
第三步，模型编译。用 TPU-MLIR 工具链将 ONNX 编译为 BModel，例程提供 gen_fp32bmodel_mlir.sh、gen_fp16bmodel_mlir.sh 脚本，支持 BM1684X、BM1688 等平台。为兼顾吞吐与延迟，通常把 batch_size=1 与 batch_size=4 的模型合并为一个 BModel。
第四步，推理验证。运行 C++ 或 Python 例程对图片做端到端识别，再用 tools/eval_icdar.py 与 ICDAR-2019 标注计算 Precision、Recall、F-score，完成精度评估。
4.3 精度测试
官方例程以 ICDAR-2019 公开数据集作为精度评测基准。测试流程为：先用 C++（ppocr_bmcv）或 Python（ppocr_system_opencv.py）例程对测试集逐张做端到端识别，输出检测框与识别结果 JSON；再用 tools/eval_icdar.py 与官方标注文件 train_full_images_0.json 比对，计算三个指标------Precision（查准率，识别结果中正确的比例）、Recall（查全率，真实文本中被找出的比例）与 F-score（两者的调和平均，综合评价检测与识别整体精度）。
精度评估命令如下：
|-----------------------------------------------------------------------------------------------------------------------------------------|
| python3 tools/eval_icdar.py \ --gt_path datasets/train_full_images_0.json \ --result_json python/results/ppocr_system_results_b4.json |
PP-OCRv4 在不同平台、不同精度下的 F-score 实测结果如下表所示：
表 1 PP-OCRv4 精度测试结果（ICDAR-2019，F-score）
|----------------------|------------------------|----------|----------|----------|
| 测试平台 | 测试程序 | FP32 | FP16 | INT8 |
| SE110S-WA32（BM1684X） | ppocr_system_opencv.py | 0.608 | 0.608 | 0.596 |
| SE110S-WA32（BM1684X） | ppocr_bmcv.soc | 0.604 | 0.604 | 0.580 |
| SE110S-WB16（BM1688） | ppocr_system_opencv.py | 0.608 | 0.608 | 0.597 |
| SE110S-WB16（BM1688） | ppocr_bmcv.soc | 0.604 | 0.604 | 0.597 |
| SE110S-WC8（CV186X） | ppocr_bmcv.soc | 0.605 | 0.604 | --- |
从表中可以得出三点结论：其一，FP16 与 FP32 的 F-score 几乎完全一致，说明半精度推理对精度几乎无损，是精度与速度的最佳平衡点；其二，INT8 量化后 F-score 仅下降约 0.01～0.02，对该任务而言损失很小，可放心用于吞吐敏感场景；其三，同一颗 TPU 上 PCIe 与 SoC 平台、OpenCV 与 BMCV 两套例程的精度差异均在 0.01 以内，属于正常波动，SDK 版本不同也可能带来小于 0.01 的误差。
4.4 性能测试
性能测试分为两级：一是用 bmrt_test 工具测试 BModel 的纯推理理论耗时，用于评估模型在 TPU 上的算力表现；二是运行完整例程统计端到端各环节耗时，用于评估实际业务吞吐。两者结合可准确定位性能瓶颈。
bmrt_test 直接加载 BModel，测出其在各 batch 下的理论推理时间，命令如下：
|---------------------------------------------------------------|
| bmrt_test --bmodel models/BM1684X/ch_PP-OCRv4_det_fp32.bmodel |
检测、识别模型在 batch=1 下的理论推理耗时如下表所示：
表 2 检测/识别模型理论推理耗时（batch=1）
|----------------------|--------|--------------|--------------|--------------|
| 测试平台 | 模型 | FP32（ms） | FP16（ms） | INT8（ms） |
| SE110S-WA32（BM1684X） | 检测模型 | 15.50 | 3.80 | 2.86 |
| SE110S-WA32（BM1684X） | 识别模型 | 1.62 | 0.60 | 0.53 |
| SE110S-WB16（BM1688） | 检测模型 | 48.66 | 12.12 | 5.70 |
| SE110S-WB16（BM1688） | 识别模型 | 8.20 | 2.07 | 1.61 |
进一步运行例程处理完整测试集，统计平均每张图片的模型推理耗时（以 C++/BMCV 例程为例）：
表 3 端到端程序模型推理平均耗时（BMCV 例程）
|----------------------|--------|--------------|--------------|--------------|
| 测试平台 | 模型 | FP32（ms） | FP16（ms） | INT8（ms） |
| SE110S-WA32（BM1684X） | 检测模型 | 15.19 | 3.60 | 2.74 |
| SE110S-WA32（BM1684X） | 识别模型 | 1.81 | 0.56 | 0.60 |
| SE110S-WB16（BM1688） | 检测模型 | 49.08 | 12.14 | 5.74 |
| SE110S-WB16（BM1688） | 识别模型 | 10.14 | 2.34 | 1.88 |
从性能数据可归纳出四点：
其一，FP16 相对 FP32 带来约 4 倍加速，INT8 相对 FP32 再提升约 5～8 倍，可将单帧检测压缩到毫秒级；
其二，识别模型本身极轻，单次推理仅约 1～3 ms，整体瓶颈主要在检测与图像预处理环节；
其三，BM1684X（对应 SE110S-WA32）性能明显强于 BM1688（对应 SE110S-WB16），检测 FP16 分别为约 3.6 ms 与 12 ms；
其四，C++/BMCV 例程的预处理直接调用硬件加速，其解码与预处理开销远低于 Python/OpenCV 例程，对实时性要求高的场景建议采用 C++ 例程。综合来看，在 SE110S-WA32 上采用 FP16 模型即可在十几毫秒内完成单张图像的检测与识别，满足边缘实时 OCR 需求。
4.5 部署注意事项
****精度选择：****一般场景推荐 FP16，兼顾精度与速度；追求极致吞吐可量化到 INT8，精度损失通常可接受；
****内存管理：****BModel 加载与多实例并发会占用内存，16GB 机型应根据实际并发数合理规划；
****数据安全：****边缘设备离线推理，天然满足政务、金融等"数据不出域"的合规要求。
五、总结
PP-OCR 以极轻量的模型设计实现了接近重型模型的识别能力，配合土星云 SE110S 系列边缘设备，可在不依赖云端、不牺牲数据安全的前提下把票据、证件、文档等 OCR 能力下沉到一线场景，是端侧智能文字识别落地的高性价比选择。随着 PP-OCRv5 持续迭代，其精度与场景覆盖还在不断提升。