PaddleOCR PaddleServing 预测功能测试指南：基于 TIPC 的 Python/C++ 服务化部署验证

PaddleOCR PaddleServing 预测功能测试指南基于 TIPC 的 Python/C 服务化部署验证【免费下载链接】PaddleOCRTurn any PDF or image document into structured data for your AI. A powerful, lightweight OCR toolkit that bridges the gap between images/PDFs and LLMs. Supports 100 languages.项目地址: https://gitcode.com/GitHub_Trending/pa/PaddleOCRPaddleOCR 的 TIPCTest Infrastructure for PaddlePaddle体系中test_tipc/docs/test_serving.md系统性地规定了 PaddleServing 服务化部署的预测功能测试方法。本文围绕该文档展开结合仓库内的测试脚本test_serving_infer_python.sh、test_serving_infer_cpp.sh、配置模板serving_python 配置、serving_cpp 配置与环境准备文档install.md完整还原 Serving 部署的测试矩阵、执行流程与结果判定方法帮助你在提交代码前快速验证 PaddleServing 部署链路可用性。1. 测试范围四类模型 × 双端 Serving 的结论矩阵PaddleServing 预测功能测试的主程序为test_serving_infer_python.sh与test_serving_infer_cpp.sh分别覆盖基于 PaddleServing 的Python 服务化部署与C 服务化部署两大能力。根据训练阶段是否使用量化测试模型被划分为正常模型与量化模型两类。两类模型在 CPU/GPU 两种设备上的 Serving 预测能力汇总如下即文档中的测试结论矩阵模型类型devicebatchsizetensorrtmkldnncpu多线程正常模型GPU1/6fp32/fp16--正常模型CPU1/6-fp32支持量化模型GPU1/6int8--量化模型CPU1/6-int8支持从矩阵可以提炼出两条测试边界GPU 场景正常模型验证 TensorRT 的 fp32/fp16 精度量化模型验证 TensorRT 的 int8 精度CPU 多线程与 MKLDNN 不在 GPU 场景测试CPU 场景正常模型验证 MKLDNN fp32 与多线程量化模型验证 MKLDNN int8 与多线程TensorRT 不在 CPU 场景测试。这一矩阵在脚本中也有对应的组合过滤逻辑见 test_serving_infer_python.sh当配置精度为 fp16/int8 但use_trtFalse时跳过当_flag_quantTrue且use_trtFalse或精度含 int8 时跳过从而保证正常模型不跑 int8、量化模型只跑 int8的约束被自动执行。2. 环境准备运行 TIPC Serving 测试的前置条件运行 Serving 功能测试前需先按 test_tipc/docs/install.md 搭建 TIPC 运行环境。核心要点如下推荐硬件/软件组合CUDA 10.1/10.2、CUDNN 7.6/8.1、TensorRT 6.1.0.5/7.1/7.2Docker 镜像安装推荐将当前目录映射到容器内/paddle并安装带 TRT 的 Paddle 预编译包例如nvidia-docker run --name paddle -it -v $PWD:/paddle paddlepaddle/paddle:latest-dev-cuda10.1-cudnn7-gcc82 /bin/bash cd /paddle pip3.7 install https://paddle-wheel.bj.bcebos.com/with-trt/2.1.3/linux-gpu-cuda10.1-cudnn7-mkl-gcc8.2-trt6-avx/paddlepaddle_gpu-2.1.3.post101-cp37-cp37m-linux_x86_64.whlPython 环境构建非 Docker文档给出三组推荐组合CUDA10.1CUDNN7.6TRT6、CUDA10.2CUDNN8.1TRT7、CUDA11.1CUDNN8.1TRT7并包含 CUDNN 的 deb 安装与mnistCUDNN验证步骤、TensorRT 环境变量配置等。除 Paddle 本体外Serving 测试还依赖 PaddleServing 系列组件。这些依赖由 prepare.sh 在serving_infer模式下自动安装${python_name} -m pip install paddle-serving-server-gpu ${python_name} -m pip install paddle_serving_client ${python_name} -m pip install paddle-serving-app ${python_name} -m pip install https://paddleocr.bj.bcebos.com/libs/auto_log-1.2.0-py3-none-any.whl其中auto_log用于采集推理耗时等指标是后续日志统计的基础。3. 测试流程总览prepare 与 infer 两阶段整个 Serving 功能测试遵循 TIPC 统一的准备—执行两阶段模式准备阶段运行 prepare.shMODE 传serving_infer负责安装 Serving 依赖、下载并解压对应的推理模型与测试数据不同模型名称会命中不同的下载分支如ch_PP-OCRv2、ch_PP-OCRv3、量化/蒸馏模型等见 prepare.sh同时下载ch_det_data_50与rec_inference测试图片数据执行阶段分别运行test_serving_infer_python.shPython Serving或test_serving_infer_cpp.shC Serving启动服务端、调用客户端、汇总测试状态最终在test_tipc/output/{model_name}/serving_infer/目录下产出日志。4. Python Serving 功能测试4.1 执行命令先准备数据与模型再运行 Python Serving 测试bash test_tipc/prepare.sh ./test_tipc/configs/ch_PP-OCRv2/model_linux_gpu_normal_normal_serving_python_linux_gpu_cpu.txt serving_infer # 用法: bash test_tipc/test_serving_infer_python.sh ./test_tipc/configs/ch_PP-OCRv2/model_linux_gpu_normal_normal_serving_python_linux_gpu_cpu.txt serving_infer执行后在test_tipc/output/{model_name}/serving_infer/python目录下生成python_*.log后缀的日志文件。4.2 配置模板字段解读Python Serving 的测试参数全部来自配置文件以 ch_PP-OCRv2 serving_python 配置 为例配置项示例值含义model_namech_PP-OCRv2被测模型名称决定日志目录与模型下载分支pythonpython3.7测试所用 Python 解释器trans_model-m paddle_serving_client.convert将普通推理模型转换为 Serving 模型的转换命令--det_dirname./inference/ch_PP-OCRv2_det_infer/检测模型inference 格式目录--model_filename/--params_filenameinference.pdmodel/inference.pdiparams模型结构与参数文件名--det_serving_server/--det_serving_client./deploy/pdserving/ppocr_det_v2_serving/等检测模型转换后的 Serving server/client 输出目录--rec_dirname./inference/ch_PP-OCRv2_rec_infer/识别模型目录--rec_serving_server/--rec_serving_client./deploy/pdserving/ppocr_rec_v2_serving/等识别模型转换后的 Serving 输出目录serving_dir./deploy/pdservingServing 部署目录web_service 与客户端脚本所在位置web_serviceweb_service.py --configconfig.yml --opt op.det.concurrency1 op.rec.concurrency1服务端启动脚本及默认--opt参数op.det.local_service_conf.devicesgpu\|null服务端设备列表脚本据此拆分 CPU/GPU 两组用例op.det.local_service_conf.use_mkldnnFalse是否启用 MKLDNNop.det.local_service_conf.thread_num6CPU 推理线程数op.det.local_service_conf.use_trtFalse是否启用 TensorRTop.det.local_service_conf.precisionfp32推理精度fp32/fp16/int8op.det.local_service_conf.model_config空由脚本回填服务端实际加载的模型配置目录piplinepipeline_http_client.py客户端脚本Pipeline HTTP 模式--image_dir../../doc/imgs/1.jpg客户端请求的测试图片路径需要特别说明的是model_config字段脚本在运行时通过func_parser_model_configtest_serving_infer_python.sh从--det_serving_server/--rec_serving_server路径中提取末尾目录名再通过--opt op.det.local_service_conf.model_config...动态回填到启动命令中实现了配置模板与具体模型解耦。4.3 脚本执行链路源码级test_serving_infer_python.sh 的执行链路可分为四步参数解析读取配置前 23 行awk NR1, NR23{print}借助 common_func.sh 中的func_parser_value/func_parser_key逐行拆解键值对模型转换根据model_name分支判断对 det/rec 分别执行paddle_serving_client.convert--dirname --model_filename --params_filename --serving_server --serving_client转换日志分别写入python_trans_model_det.log/python_trans_model_rec.log服务端启动与客户端请求遍历devicesgpu|null、use_mkldnn、thread_num、use_trt、precision的组合用nohup ... web_service.py ... 后台拉起服务sleep 2 秒后运行pipeline_http_client.py --image_dir...发起请求状态汇总与清理每条命令经status_check判定成败并追加写入results_python_serving.log一组用例结束后通过ps ux | grep -E web_service | awk {print $2} | xargs kill -s 9回收服务进程。典型启动命令形如nohup python3.7 web_service.py --configconfig.yml --opt op.det.concurrency1 op.rec.concurrency1 \ op.det.local_service_conf.devices op.det.local_service_conf.use_mkldnnFalse \ op.det.local_service_conf.thread_num6 op.rec.local_service_conf.model_configppocr_rec_v2_serving \ ./test_tipc/output/ch_PP-OCRv2_rec/serving_infer/python/python_server_cpu_usemkldnn_False_threads_6.log 21 客户端命令形如python3.7 pipeline_http_client.py --detFalse --image_dir../../inference/rec_inference \ ./test_tipc/output/ch_PP-OCRv2_rec/serving_infer/python/python_client_cpu_pipeline_http_usemkldnn_False_threads_6_batchsize_1.log 21日志命名即用例身份卡如python_server_cpu_usemkldnn_False_threads_6.log表明这是 CPU、禁用 MKLDNN、6 线程的服务端日志python_client_gpu_usetrt_True_precision_fp16_batchsize_1.log表明这是 GPU、开启 TensorRT、fp16 精度的客户端日志。5. C Serving 功能测试5.1 执行命令bash test_tipc/prepare.sh ./test_tipc/configs/ch_PP-OCRv2/model_linux_gpu_normal_normal_serving_cpp_linux_gpu_cpu.txt serving_infer # 用法: bash test_tipc/test_serving_infer_cpp.sh ./test_tipc/configs/ch_PP-OCRv2/model_linux_gpu_normal_normal_serving_cpp_linux_gpu_cpu.txt serving_infer执行后在test_tipc/output/{model_name}/serving_infer/cpp目录下生成cpp_*.log后缀的日志文件。5.2 配置模板字段解读C Serving 的配置与 Python 版同源但服务端换用 C serve 入口、客户端换用专用 C 客户端脚本见 serving_cpp 配置配置项示例值含义web_service-m paddle_serving_server.serveC 服务端启动方式模块方式--opGeneralDetectionOp GeneralInferOp服务端算子列表--port8181服务监听端口--gpu_id0\|nullGPU 卡号列表null代表 CPU 用例cpp_clientocr_cpp_client.pyC 客户端脚本--image_dir../../doc/imgs/1.jpg客户端请求图片路径其余det/rec 模型目录、serving_server/client 目录、model_filename/params_filename等字段与 Python 版一致此处不再赘述。5.3 脚本执行链路源码级test_serving_infer_cpp.sh 与 Python 版的主要差异体现在服务端不同使用nohup ${python} -m paddle_serving_server.serve --model ${det_server} ${rec_server} --op GeneralDetectionOp GeneralInferOp --port 8181 [--gpu_id 0]启动CPU/GPU 分支仅差一个--gpu_id参数客户端不同运行ocr_cpp_client.py ${det_client_value} ${rec_client_value}发起请求服务端需先 sleep 5 秒等待就绪停止方式不同不再用 kill 进程而是通过${python} -m paddle_serving_server.serve stop优雅停止服务额外拷贝步骤模型转换后会执行cp deploy/pdserving/serving_client_conf.prototxt ${det_serving_client_value}为 C 客户端补齐服务协议配置文件。6. 运行结果与日志解读各测试的运行情况会打印在test_tipc/output/{model_name}/serving_infer/python(cpp)/results_python(cpp)_serving.log中。运行成功时输出形如Run successfully with command - ch_PP-OCRv2_rec - nohup python3.7 web_service_rec.py --configconfig.yml --opt op.rec.concurrency1 op.det.local_service_conf.devices op.det.local_service_conf.use_mkldnnFalse op.det.local_service_conf.thread_num6 op.rec.local_service_conf.model_configppocr_rec_v2_serving ./test_tipc/output/ch_PP-OCRv2_rec/serving_infer/python/python_server_cpu_usemkldnn_False_threads_6.log 21 ! Run successfully with command - ch_PP-OCRv2_rec - python3.7 pipeline_http_client.py --detFalse --image_dir../../inference/rec_inference ./test_tipc/output/ch_PP-OCRv2_rec/serving_infer/python/python_client_cpu_pipeline_http_usemkldnn_False_threads_6_batchsize_1.log 21 ! ...运行失败时输出形如Run failed with command - ch_PP-OCRv2_rec - nohup python3.7 web_service_rec.py --configconfig.yml --opt op.rec.concurrency1 op.det.local_service_conf.devices op.det.local_service_conf.use_mkldnnFalse op.det.local_service_conf.thread_num6 op.rec.local_service_conf.model_configppocr_rec_v2_serving ./test_tipc/output/ch_PP-OCRv2_rec/serving_infer/python/python_server_cpu_usemkldnn_False_threads_6.log 21 ! Run failed with command - ch_PP-OCRv2_rec - python3.7 pipeline_http_client.py --detFalse --image_dir../../inference/rec_inference ./test_tipc/output/ch_PP-OCRv2_rec/serving_infer/python/python_client_cpu_pipeline_http_usemkldnn_False_threads_6_batchsize_1.log 21 ! ...这两类输出均由status_check定义于 common_func.sh根据命令退出码写入results_*_serving.log因此成功/失败结论以 results 汇总日志为准而单条命令的详细报错则需进入对应的python_server_*.log/python_client_*.log/cpp_server_*.log/cpp_client_*.log排查。详细的预测结果如检测框、识别文本等同样保存在test_tipc/output/{model_name}/serving_infer/python(cpp)/文件夹下可用于与期望结果比对、判断预测正确性。7. 小结与延伸阅读PaddleServing 预测功能测试是 TIPC 中部署可用性的关键一环它用统一脚本 声明式配置的方式自动完成了模型转换 → 服务端拉起 → 客户端请求 → 结果判定 → 进程清理的完整闭环覆盖 CPU/GPU、MKLDNN/TensorRT、fp32/fp16/int8、多线程等多种部署组合让 Serving 链路的质量回归变得可重复、可追踪。除本测试文档外TIPC 还配套提供了 train/inference 联合测试、C 推理测试、Paddle2ONNX 测试、PTQ 量化推理测试 等系列文档共同构成 PaddleOCR 的训练—推理—部署全链路质量保障体系。如需了解 Serving 本身的详细使用教程pipeline 配置、HTTP/gRPC 调用、多模型串联等可结合仓库 deploy 目录下的服务化部署资源继续深入并对照本测试文档中的配置文件理解各字段在生产部署中的实际含义。【免费下载链接】PaddleOCRTurn any PDF or image document into structured data for your AI. A powerful, lightweight OCR toolkit that bridges the gap between images/PDFs and LLMs. Supports 100 languages.项目地址: https://gitcode.com/GitHub_Trending/pa/PaddleOCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考