PaddleDetection 模型 Python Serving 服务化部署实战基于 Paddle Serving Pipeline 框架的完整部署指南【免费下载链接】PaddleDetectionObject Detection toolkit based on PaddlePaddle. It supports object detection, instance segmentation, multiple object tracking and real-time multi-person keypoint detection.项目地址: https://gitcode.com/gh_mirrors/pa/PaddleDetection导读本文围绕 PaddleDetection 仓库中 deploy/serving/python 目录下的 Python Serving 预测部署方案展开完整讲解如何将 PaddleDetection 训练好的检测模型以yolov3_darknet53_270e_coco为例通过 Paddle Serving 的 Python Pipeline 框架部署为工业级在线推理服务。读完本文后你将掌握Paddle Serving 环境安装、带服务化配置的模型导出、服务端配置文件的每个关键参数含义、web_service.py服务端代码的完整工作流程预处理 → 推理 → 后处理 → 结果返回以及基于 HTTP 的客户端调用方式并了解如何在服务端自定义预处理与后处理逻辑以适配不同模型架构。1. 简介Python Pipeline 服务化部署方案Paddle Serving 是飞桨开源的服务化部署框架提供了 C Serving 与 Python Pipeline 两套框架C Serving 框架更倾向于追求极致性能适合对延迟和吞吐有严苛要求的场景Python Pipeline 框架则倾向于二次开发的便捷性开发者可以方便地用 Python 自定义预处理、后处理逻辑快速把新模型接入服务。本文档介绍的内容即基于 Python Pipeline 框架实现模型的服务化部署。仓库中的 Python 服务化部署样例程序位于 deploy/serving/python 目录目录结构如下deploy/ ├── serving/ │ ├── python/ # Python 服务化部署样例程序目录 │ │ ├── config.yml # 服务端模型预测相关配置文件 │ │ ├── pipeline_http_client.py # 客户端代码 │ │ ├── postprocess_ops.py # 用户自定义后处理代码 │ │ ├── preprocess_ops.py # 用户自定义预处理代码 │ │ ├── README.md # 说明文档 │ │ ├── web_service.py # 服务端代码 │ ├── cpp/ # C 服务化部署样例程序目录 │ │ ├── preprocess/ # C 自定义 OP │ │ ├── build_server.sh # C Serving 编译脚本 │ │ ├── serving_client.py # 客户端代码 │ │ └── ... │ └── ... └── ...各文件职责清晰config.yml负责服务运行参数web_service.py定义服务端推理流程preprocess_ops.py与postprocess_ops.py分别封装图像预处理算子与结果后处理算子pipeline_http_client.py是 HTTP 客户端示例。说明仓库中还提供了 C Serving 部署样例deploy/serving/cpp以及一个通用测试客户端 deploy/serving/test_client.py配合 deploy/serving/label_list.txt 使用对应 C/经典 Serving 部署方式本文聚焦 Python Pipeline 方案C 方案可参考对应 README。2. 环境准备安装 Paddle Serving 与 PaddlePaddle进行服务化部署前需要安装 Paddle Serving 的四个安装包分别是paddle-serving-serverCPU/GPU 版本二选一、paddle-serving-client、paddle-serving-app和paddlepaddleCPU/GPU 版本二选一pip install paddle-serving-client # pip install paddle-serving-server # CPU pip install paddle-serving-server-gpu # GPU 默认 CUDA10.2 TensorRT6其他环境需手动指定版本号 pip install paddle-serving-app # pip install paddlepaddle # CPU pip install paddlepaddle-gpu几点实用提示安装速度慢时可使用国内镜像源例如百度源在 pip 命令中添加-i https://mirror.baidu.com/pypi/simple加速下载GPU 版本默认对应 CUDA 10.2 TensorRT 6如果实际环境不同需要手动指定与本地 CUDA/TensorRT 匹配的版本号从仓库代码看服务端 web_service.py 通过from paddle_serving_server.web_service import WebService, Op引入 Pipeline 框架基类因此安装包版本需要与代码兼容README 对应示例基于 Serving v0.7.0 系列实际使用请以官方发布版本为准。3. 服务化部署模型导出3.1 导出命令PaddleDetection 训练得到的是包含前向与优化器参数的模型部署时只需要前向推理参数因此需要先用 tools/export_model.py 导出推理模型具体流程可参考 deploy/EXPORT_MODEL.md。与普通导出不同导出服务化部署模型需要额外添加--export_serving_model True参数示例如下python tools/export_model.py -c configs/yolov3/yolov3_darknet53_270e_coco.yml \ --export_serving_model True \ -o weightshttps://paddledet.bj.bcebos.com/models/yolov3_darknet53_270e_coco.pdparams命令中-c指定模型配置文件本例为 configs/yolov3/yolov3_darknet53_270e_coco.yml-o weights...指定权重既可以是本地权重路径也可以是预训练模型下载地址。3.2 导出产物的结构查看 tools/export_model.py 的源码可知当FLAGS.export_serving_model为真时脚本会调用paddle_serving_client.io.inference_model_to_serving以output_inference/模型名目录下的model.pdmodel与model.pdiparams为输入在该目录下额外生成serving_server与serving_client两个子目录。最终导出目录结构为output_inference │ ├── yolov3_darknet53_270e_coco │ │ ├── infer_cfg.yml │ │ ├── model.pdiparams │ │ ├── model.pdiparams.info │ │ ├── model.pdmodel │ │ ├── serving_client │ │ │ ├── serving_client_conf.prototxt │ │ │ ├── serving_client_conf.stream.prototxt │ │ ├── serving_server │ │ │ ├── __model__ │ │ │ ├── __params__ │ │ │ ├── serving_server_conf.prototxt │ │ │ ├── serving_server_conf.stream.prototxt │ │ │ ├── ...其中serving_server目录是服务端真正加载的模型目录__model__与__params__是转换后的模型文件serving_client目录是客户端配置目录serving_server_conf.prototxt详细描述了模型的输入输出信息。以 YOLOv3 为例输入为im_shape、image形状 3×608×608、scale_factor输出为 NMS 结果multiclass_nms3_0.tmp_0LoD 张量与multiclass_nms3_0.tmp_2。关于导出的输入输出约定deploy/EXPORT_MODEL.md 中说明模型输入为image[None, 3, H, W]、im_shape[None, 2]resize 后的 H、W、scale_factor[None, 2]scale_y、scale_x统一输出为bbox形状 [N, 6]每行是class_id, score, x1, y1, x2, y2、bbox_num每张图片的预测框个数若网络包含 mask 分支还会输出 mask。4. 启动服务端模型预测服务4.1 启动命令完成环境准备与模型导出后按如下命令启动模型预测服务python deploy/serving/python/web_service.py --model_dir output_inference/yolov3_darknet53_270e_coco --model_dir指向导出目录tools/export_model.py 的默认输出目录为output_inference。表示后台运行。此外 web_service.py 还支持-c/--config指定服务配置文件默认即deploy/serving/python/config.yml与-o命令行覆盖配置参数。4.2 服务端配置文件 config.yml 详解服务端模型预测相关配置在 config.yml 中修改开发者最常关注三个配置http_port服务的 http 端口、device_type计算硬件类型、devices计算硬件 ID。完整配置项及含义如下# worker_num, 最大并发数。当build_dag_each_workerTrue时, 框架会创建worker_num个进程 # 每个进程内构建grpcServer和DAG当build_dag_each_workerFalse时 # 框架会设置主线程grpc线程池的max_workersworker_num worker_num: 20 # http端口, rpc_port和http_port不允许同时为空。当rpc_port可用且http_port为空时不自动生成http_port http_port: 18093 rpc_port: 9993 dag: # op资源类型, True, 为线程模型False为进程模型 is_thread_op: False op: # op名称与web_service中DetectorService初始化name参数一致 ppdet: # 并发数is_thread_opTrue时为线程并发否则为进程并发 concurrency: 1 # 当op配置没有server_endpoints时从local_service_conf读取本地服务配置 local_service_conf: # 模型路径web_service.py 启动时会被自动改写为 --model_dir 下的 serving_server 目录 model_config: ./serving_server # 计算硬件类型: 空缺时由devices决定(CPU/GPU)0cpu, 1gpu, 2tensorRT, 3arm cpu, 4kunlun xpu device_type: # 计算硬件ID当devices为或不写时为CPU预测 # 当devices为0, 0,1,2时为GPU预测表示使用的GPU卡 devices: 0 # 0,1 # client类型包括brpc, grpc和local_predictor。 # local_predictor不启动Serving服务进程内预测 client_type: local_predictor关键参数速查表配置项位置默认值/示例含义worker_num顶层20最大并发数决定 worker 进程/线程规模http_port顶层18093HTTP 服务端口与rpc_port不能同时为空rpc_port顶层9993RPC 服务端口dag.is_thread_opdagFalseTrue 为线程模型False 为进程模型op.name.concurrencyop1OP 并发数线程并发或进程并发取决于is_thread_opop.name.local_service_conf.model_configop./serving_server服务端模型路径运行时被自动改写为导出目录下的serving_serverop.name.local_service_conf.device_typeop空0cpu、1gpu、2tensorRT、3arm cpu、4kunlun xpu空缺时由devices决定op.name.local_service_conf.devicesop0计算硬件 ID为空/不写为 CPU0或0,1,2为 GPU 卡号op.name.local_service_conf.client_typeoplocal_predictorbrpc、grpc 或 local_predictorlocal_predictor 为进程内预测注op下的键名ppdet必须与 web_service.py 中DetectorService.get_pipeline_response里DetectorOp(nameppdet, ...)的name参数保持一致同时与服务端DetectorService(nameppdet)的 name 一致否则配置无法正确关联到 OP。4.3 服务端启动流程源码解读web_service.py 的启动主流程__main__部分可以分为五步解析参数ArgsParser().parse_args()读取命令行参数若指定了-o keyvalue会通过_parse_opt将其写入 yaml 配置devices会强制转为字符串读取导出配置PredictConfig解析--model_dir下的 infer_cfg.yml即导出时随模型生成的推理配置读取arch模型架构、Preprocess预处理算子序列、label_list、use_dynamic_shape、draw_threshold、mask等字段check_model会校验arch是否在SUPPORT_MODELS集合YOLO、PPYOLOE、RCNN、SSD、Face、FCOS、SOLOv2、TTFNet、S2ANet、JDE、FairMOT、DeepSORT、GFL、PicoDet、CenterNet、TOOD、RetinaNet、StrongBaseline、STGCN、YOLOX、HRNet中不支持的架构会抛出ValueError解析模型输入输出get_model_vars将local_service_conf.model_config改写为model_dir/serving_server并解析serving_server_conf.prototxt得到feed_vars与fetch_vars后续用它们过滤预处理输入、定位推理输出构建服务DetectorService(nameppdet)继承自WebService其get_pipeline_response将DetectorOp(nameppdet, input_ops[read_op])接入 Pipeline DAG启动prepare_pipeline_config加载 yml 配置后调用run_service()正式对外提供服务。5. 启动客户端访问服务当模型预测服务成功启动后另开终端执行python deploy/serving/python/pipeline_http_client.py --image_file demo/000000014439.jpg客户端代码 pipeline_http_client.py 支持的参数包括参数默认值含义--image_file无单张图片路径优先级高于--image_dir--image_dir无图片目录会递归收集jpg/jpeg/png/bmp含大写图片--http_port18093与服务端config.yml中http_port一致--service_nameppdet与服务端 OP 名称一致客户端请求流程为拼接请求 URLhttp://127.0.0.1:{http_port}/{service_name}/prediction读取图片字节流进行base64 编码构造{key: [image_0], value: [image], logid: logid}的 JSON 数据通过requests.post发送到服务端打印服务端返回的 JSON 结果。对应地服务端 DetectorOp.preprocess 会做镜像处理对收到的 value 执行base64.b64decode还原字节流再用PIL.Image打开并转为 RGB送入预处理流水线。6. 服务端处理流程与自定义 OP 机制6.1 一条请求的完整生命周期以yolov3_darknet53_270e_coco为例请求在服务端的处理链路如下预处理DetectorOp.init_op中通过Compose(GLOBAL_VAR[preprocess_ops])构建预处理流水线其中preprocess_ops正是从导出模型infer_cfg.yml的Preprocess字段解析出来的算子序列preprocess对 base64 图片解码后逐个调用算子collate_inputs只保留feed_vars中的输入项并np.stack成 batch推理local_predictor进程内预测直接以 batch 化的image、im_shape、scale_factor喂入模型后处理postprocess根据架构分流——HRNet 类走parse_keypoint_result关键点解析其余检测类模型走parse_detection_result结果返回parse_detection_result按bboxes_num切分每个 batch 样本的预测框过滤掉低于draw_threshold默认 0.5的框输出格式为class_id score x1 y1 x2 y2的字符串列表若无目标则返回No object detected!。6.2 预处理算子preprocess_ops.pypreprocess_ops.py 中的算子与训练/推理时使用的数据变换一一对应Compose会根据infer_cfg.yml中每个算子的type字段动态实例化eval(op_type)(**new_op_info)因此换用不同模型时无需修改服务端代码只需重新导出模型预处理流水线会自动匹配。主要算子包括decode_image将PIL.Image转为np.ndarray初始化im_shape与scale_factor信息Resize按target_size等比/非等比缩放keep_ratioTrue时短边对齐目标尺寸并限制长边不超过max(target_size)同时更新im_shape与scale_factorNormalizeImageis_scale控制是否除以 255norm_typemean_std时执行(im - mean) / stdPermute将 HWC 转 CHWPadStride将图像 padding 到最粗 stride如 FPN 网络的 32的整数倍LetterBoxResizeYOLO 系模型常用的 letterbox 缩放按min(ratio_h, ratio_w)等比缩放后以(127.5,127.5,127.5)填充到目标尺寸Padpadding 到指定尺寸填充值默认为[114, 114, 114]WarpAffine与TopDownEvalAffineCenterNet 等中心点检测与 HRNet 关键点模型使用的仿射变换含get_affine_transform等工具函数。6.3 后处理算子postprocess_ops.pypostprocess_ops.py 中实现了HRNetPostProcess关键点后处理包含get_max_preds从 heatmap 取最大响应位置、gaussian_blur高斯模糊、dark_postprocess/dark_parseDarkPose 亚像素精修use_darkTrue时启用、get_final_preds通过get_affine_transform(..., inv1)将预测坐标逆变换回原图以及transform_preds/affine_transform。检测类模型YOLO/RCNN 等的 NMS 与坐标解析则由导出的预测程序内完成fetch_vars直接取 NMS 输出服务端只做阈值过滤与格式整理这正是 Python Pipeline 二次开发便捷性的体现——开发者可在此自由扩展自己的后处理。7. 验证部署链路可选经典 Serving 测试方式除了 Python Pipeline 客户端仓库还提供了基于 Serving C 风格的通用测试客户端 deploy/serving/test_client.py其处理流程与pipeline_http_client.py不同使用paddle_serving_client.Client直连 RPC 端口 9393预处理使用paddle_serving_app.reader.Sequential可作为链路验证的补充参考。测试方式对应 deploy/serving/README.mdcd output_inference/yolov3_darknet53_270e_coco/ python -m paddle_serving_server.serve --model serving_server --port 9393 --gpu_ids 0 # GPU # python -m paddle_serving_server.serve --model serving_server --port 9393 # CPU python ../../deploy/serving/test_client.py ../../deploy/serving/label_list.txt ../../demo/000000014439.jpg测试代码会自动创建output文件夹并在其中生成bbox.json与带检测框的可视化图片000000014439.jpg。8. 常见问题与注意事项端口冲突与配置一致性http_port/rpc_port不能同时为空客户端--http_port必须与服务端config.yml中的http_port一致--service_name必须与服务端 OP 名称默认ppdet一致模型目录结构--model_dir必须指向包含infer_cfg.yml、model.pdmodel、model.pdiparams以及serving_server子目录的导出目录web_service.py启动时会校验并解析serving_server_conf.prototxt硬件配置devices为空/不写时走 CPU 预测0表示使用 0 号 GPUdevice_type空缺时由devices推断TensorRT 推理需将device_type设为 2 并确保环境安装对应版本模型架构支持范围SUPPORT_MODELS中列出了服务端内置支持的架构导出模型的arch不在集合内会直接报错遇到不支持的架构需自行扩展 OP 逻辑图像输入约定客户端发送的图片需 base64 编码后放入value字段服务端用 PIL 解码并转为 RGB因此本地测试图片请使用常见格式jpg/jpeg/png/bmp后台运行与日志启动命令末尾的将服务放入后台建议在正式环境中结合 nohup 与日志重定向运行并通过http_port的健康检查确认服务就绪后再发起客户端请求。【免费下载链接】PaddleDetectionObject Detection toolkit based on PaddlePaddle. It supports object detection, instance segmentation, multiple object tracking and real-time multi-person keypoint detection.项目地址: https://gitcode.com/gh_mirrors/pa/PaddleDetection创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PaddleDetection 模型 Python Serving 服务化部署实战：基于 Paddle Serving Pipeline 框架的完整部署指南
PaddleDetection 模型 Python Serving 服务化部署实战基于 Paddle Serving Pipeline 框架的完整部署指南【免费下载链接】PaddleDetectionObject Detection toolkit based on PaddlePaddle. It supports object detection, instance segmentation, multiple object tracking and real-time multi-person keypoint detection.项目地址: https://gitcode.com/gh_mirrors/pa/PaddleDetection导读本文围绕 PaddleDetection 仓库中 deploy/serving/python 目录下的 Python Serving 预测部署方案展开完整讲解如何将 PaddleDetection 训练好的检测模型以yolov3_darknet53_270e_coco为例通过 Paddle Serving 的 Python Pipeline 框架部署为工业级在线推理服务。读完本文后你将掌握Paddle Serving 环境安装、带服务化配置的模型导出、服务端配置文件的每个关键参数含义、web_service.py服务端代码的完整工作流程预处理 → 推理 → 后处理 → 结果返回以及基于 HTTP 的客户端调用方式并了解如何在服务端自定义预处理与后处理逻辑以适配不同模型架构。1. 简介Python Pipeline 服务化部署方案Paddle Serving 是飞桨开源的服务化部署框架提供了 C Serving 与 Python Pipeline 两套框架C Serving 框架更倾向于追求极致性能适合对延迟和吞吐有严苛要求的场景Python Pipeline 框架则倾向于二次开发的便捷性开发者可以方便地用 Python 自定义预处理、后处理逻辑快速把新模型接入服务。本文档介绍的内容即基于 Python Pipeline 框架实现模型的服务化部署。仓库中的 Python 服务化部署样例程序位于 deploy/serving/python 目录目录结构如下deploy/ ├── serving/ │ ├── python/ # Python 服务化部署样例程序目录 │ │ ├── config.yml # 服务端模型预测相关配置文件 │ │ ├── pipeline_http_client.py # 客户端代码 │ │ ├── postprocess_ops.py # 用户自定义后处理代码 │ │ ├── preprocess_ops.py # 用户自定义预处理代码 │ │ ├── README.md # 说明文档 │ │ ├── web_service.py # 服务端代码 │ ├── cpp/ # C 服务化部署样例程序目录 │ │ ├── preprocess/ # C 自定义 OP │ │ ├── build_server.sh # C Serving 编译脚本 │ │ ├── serving_client.py # 客户端代码 │ │ └── ... │ └── ... └── ...各文件职责清晰config.yml负责服务运行参数web_service.py定义服务端推理流程preprocess_ops.py与postprocess_ops.py分别封装图像预处理算子与结果后处理算子pipeline_http_client.py是 HTTP 客户端示例。说明仓库中还提供了 C Serving 部署样例deploy/serving/cpp以及一个通用测试客户端 deploy/serving/test_client.py配合 deploy/serving/label_list.txt 使用对应 C/经典 Serving 部署方式本文聚焦 Python Pipeline 方案C 方案可参考对应 README。2. 环境准备安装 Paddle Serving 与 PaddlePaddle进行服务化部署前需要安装 Paddle Serving 的四个安装包分别是paddle-serving-serverCPU/GPU 版本二选一、paddle-serving-client、paddle-serving-app和paddlepaddleCPU/GPU 版本二选一pip install paddle-serving-client # pip install paddle-serving-server # CPU pip install paddle-serving-server-gpu # GPU 默认 CUDA10.2 TensorRT6其他环境需手动指定版本号 pip install paddle-serving-app # pip install paddlepaddle # CPU pip install paddlepaddle-gpu几点实用提示安装速度慢时可使用国内镜像源例如百度源在 pip 命令中添加-i https://mirror.baidu.com/pypi/simple加速下载GPU 版本默认对应 CUDA 10.2 TensorRT 6如果实际环境不同需要手动指定与本地 CUDA/TensorRT 匹配的版本号从仓库代码看服务端 web_service.py 通过from paddle_serving_server.web_service import WebService, Op引入 Pipeline 框架基类因此安装包版本需要与代码兼容README 对应示例基于 Serving v0.7.0 系列实际使用请以官方发布版本为准。3. 服务化部署模型导出3.1 导出命令PaddleDetection 训练得到的是包含前向与优化器参数的模型部署时只需要前向推理参数因此需要先用 tools/export_model.py 导出推理模型具体流程可参考 deploy/EXPORT_MODEL.md。与普通导出不同导出服务化部署模型需要额外添加--export_serving_model True参数示例如下python tools/export_model.py -c configs/yolov3/yolov3_darknet53_270e_coco.yml \ --export_serving_model True \ -o weightshttps://paddledet.bj.bcebos.com/models/yolov3_darknet53_270e_coco.pdparams命令中-c指定模型配置文件本例为 configs/yolov3/yolov3_darknet53_270e_coco.yml-o weights...指定权重既可以是本地权重路径也可以是预训练模型下载地址。3.2 导出产物的结构查看 tools/export_model.py 的源码可知当FLAGS.export_serving_model为真时脚本会调用paddle_serving_client.io.inference_model_to_serving以output_inference/模型名目录下的model.pdmodel与model.pdiparams为输入在该目录下额外生成serving_server与serving_client两个子目录。最终导出目录结构为output_inference │ ├── yolov3_darknet53_270e_coco │ │ ├── infer_cfg.yml │ │ ├── model.pdiparams │ │ ├── model.pdiparams.info │ │ ├── model.pdmodel │ │ ├── serving_client │ │ │ ├── serving_client_conf.prototxt │ │ │ ├── serving_client_conf.stream.prototxt │ │ ├── serving_server │ │ │ ├── __model__ │ │ │ ├── __params__ │ │ │ ├── serving_server_conf.prototxt │ │ │ ├── serving_server_conf.stream.prototxt │ │ │ ├── ...其中serving_server目录是服务端真正加载的模型目录__model__与__params__是转换后的模型文件serving_client目录是客户端配置目录serving_server_conf.prototxt详细描述了模型的输入输出信息。以 YOLOv3 为例输入为im_shape、image形状 3×608×608、scale_factor输出为 NMS 结果multiclass_nms3_0.tmp_0LoD 张量与multiclass_nms3_0.tmp_2。关于导出的输入输出约定deploy/EXPORT_MODEL.md 中说明模型输入为image[None, 3, H, W]、im_shape[None, 2]resize 后的 H、W、scale_factor[None, 2]scale_y、scale_x统一输出为bbox形状 [N, 6]每行是class_id, score, x1, y1, x2, y2、bbox_num每张图片的预测框个数若网络包含 mask 分支还会输出 mask。4. 启动服务端模型预测服务4.1 启动命令完成环境准备与模型导出后按如下命令启动模型预测服务python deploy/serving/python/web_service.py --model_dir output_inference/yolov3_darknet53_270e_coco --model_dir指向导出目录tools/export_model.py 的默认输出目录为output_inference。表示后台运行。此外 web_service.py 还支持-c/--config指定服务配置文件默认即deploy/serving/python/config.yml与-o命令行覆盖配置参数。4.2 服务端配置文件 config.yml 详解服务端模型预测相关配置在 config.yml 中修改开发者最常关注三个配置http_port服务的 http 端口、device_type计算硬件类型、devices计算硬件 ID。完整配置项及含义如下# worker_num, 最大并发数。当build_dag_each_workerTrue时, 框架会创建worker_num个进程 # 每个进程内构建grpcServer和DAG当build_dag_each_workerFalse时 # 框架会设置主线程grpc线程池的max_workersworker_num worker_num: 20 # http端口, rpc_port和http_port不允许同时为空。当rpc_port可用且http_port为空时不自动生成http_port http_port: 18093 rpc_port: 9993 dag: # op资源类型, True, 为线程模型False为进程模型 is_thread_op: False op: # op名称与web_service中DetectorService初始化name参数一致 ppdet: # 并发数is_thread_opTrue时为线程并发否则为进程并发 concurrency: 1 # 当op配置没有server_endpoints时从local_service_conf读取本地服务配置 local_service_conf: # 模型路径web_service.py 启动时会被自动改写为 --model_dir 下的 serving_server 目录 model_config: ./serving_server # 计算硬件类型: 空缺时由devices决定(CPU/GPU)0cpu, 1gpu, 2tensorRT, 3arm cpu, 4kunlun xpu device_type: # 计算硬件ID当devices为或不写时为CPU预测 # 当devices为0, 0,1,2时为GPU预测表示使用的GPU卡 devices: 0 # 0,1 # client类型包括brpc, grpc和local_predictor。 # local_predictor不启动Serving服务进程内预测 client_type: local_predictor关键参数速查表配置项位置默认值/示例含义worker_num顶层20最大并发数决定 worker 进程/线程规模http_port顶层18093HTTP 服务端口与rpc_port不能同时为空rpc_port顶层9993RPC 服务端口dag.is_thread_opdagFalseTrue 为线程模型False 为进程模型op.name.concurrencyop1OP 并发数线程并发或进程并发取决于is_thread_opop.name.local_service_conf.model_configop./serving_server服务端模型路径运行时被自动改写为导出目录下的serving_serverop.name.local_service_conf.device_typeop空0cpu、1gpu、2tensorRT、3arm cpu、4kunlun xpu空缺时由devices决定op.name.local_service_conf.devicesop0计算硬件 ID为空/不写为 CPU0或0,1,2为 GPU 卡号op.name.local_service_conf.client_typeoplocal_predictorbrpc、grpc 或 local_predictorlocal_predictor 为进程内预测注op下的键名ppdet必须与 web_service.py 中DetectorService.get_pipeline_response里DetectorOp(nameppdet, ...)的name参数保持一致同时与服务端DetectorService(nameppdet)的 name 一致否则配置无法正确关联到 OP。4.3 服务端启动流程源码解读web_service.py 的启动主流程__main__部分可以分为五步解析参数ArgsParser().parse_args()读取命令行参数若指定了-o keyvalue会通过_parse_opt将其写入 yaml 配置devices会强制转为字符串读取导出配置PredictConfig解析--model_dir下的 infer_cfg.yml即导出时随模型生成的推理配置读取arch模型架构、Preprocess预处理算子序列、label_list、use_dynamic_shape、draw_threshold、mask等字段check_model会校验arch是否在SUPPORT_MODELS集合YOLO、PPYOLOE、RCNN、SSD、Face、FCOS、SOLOv2、TTFNet、S2ANet、JDE、FairMOT、DeepSORT、GFL、PicoDet、CenterNet、TOOD、RetinaNet、StrongBaseline、STGCN、YOLOX、HRNet中不支持的架构会抛出ValueError解析模型输入输出get_model_vars将local_service_conf.model_config改写为model_dir/serving_server并解析serving_server_conf.prototxt得到feed_vars与fetch_vars后续用它们过滤预处理输入、定位推理输出构建服务DetectorService(nameppdet)继承自WebService其get_pipeline_response将DetectorOp(nameppdet, input_ops[read_op])接入 Pipeline DAG启动prepare_pipeline_config加载 yml 配置后调用run_service()正式对外提供服务。5. 启动客户端访问服务当模型预测服务成功启动后另开终端执行python deploy/serving/python/pipeline_http_client.py --image_file demo/000000014439.jpg客户端代码 pipeline_http_client.py 支持的参数包括参数默认值含义--image_file无单张图片路径优先级高于--image_dir--image_dir无图片目录会递归收集jpg/jpeg/png/bmp含大写图片--http_port18093与服务端config.yml中http_port一致--service_nameppdet与服务端 OP 名称一致客户端请求流程为拼接请求 URLhttp://127.0.0.1:{http_port}/{service_name}/prediction读取图片字节流进行base64 编码构造{key: [image_0], value: [image], logid: logid}的 JSON 数据通过requests.post发送到服务端打印服务端返回的 JSON 结果。对应地服务端 DetectorOp.preprocess 会做镜像处理对收到的 value 执行base64.b64decode还原字节流再用PIL.Image打开并转为 RGB送入预处理流水线。6. 服务端处理流程与自定义 OP 机制6.1 一条请求的完整生命周期以yolov3_darknet53_270e_coco为例请求在服务端的处理链路如下预处理DetectorOp.init_op中通过Compose(GLOBAL_VAR[preprocess_ops])构建预处理流水线其中preprocess_ops正是从导出模型infer_cfg.yml的Preprocess字段解析出来的算子序列preprocess对 base64 图片解码后逐个调用算子collate_inputs只保留feed_vars中的输入项并np.stack成 batch推理local_predictor进程内预测直接以 batch 化的image、im_shape、scale_factor喂入模型后处理postprocess根据架构分流——HRNet 类走parse_keypoint_result关键点解析其余检测类模型走parse_detection_result结果返回parse_detection_result按bboxes_num切分每个 batch 样本的预测框过滤掉低于draw_threshold默认 0.5的框输出格式为class_id score x1 y1 x2 y2的字符串列表若无目标则返回No object detected!。6.2 预处理算子preprocess_ops.pypreprocess_ops.py 中的算子与训练/推理时使用的数据变换一一对应Compose会根据infer_cfg.yml中每个算子的type字段动态实例化eval(op_type)(**new_op_info)因此换用不同模型时无需修改服务端代码只需重新导出模型预处理流水线会自动匹配。主要算子包括decode_image将PIL.Image转为np.ndarray初始化im_shape与scale_factor信息Resize按target_size等比/非等比缩放keep_ratioTrue时短边对齐目标尺寸并限制长边不超过max(target_size)同时更新im_shape与scale_factorNormalizeImageis_scale控制是否除以 255norm_typemean_std时执行(im - mean) / stdPermute将 HWC 转 CHWPadStride将图像 padding 到最粗 stride如 FPN 网络的 32的整数倍LetterBoxResizeYOLO 系模型常用的 letterbox 缩放按min(ratio_h, ratio_w)等比缩放后以(127.5,127.5,127.5)填充到目标尺寸Padpadding 到指定尺寸填充值默认为[114, 114, 114]WarpAffine与TopDownEvalAffineCenterNet 等中心点检测与 HRNet 关键点模型使用的仿射变换含get_affine_transform等工具函数。6.3 后处理算子postprocess_ops.pypostprocess_ops.py 中实现了HRNetPostProcess关键点后处理包含get_max_preds从 heatmap 取最大响应位置、gaussian_blur高斯模糊、dark_postprocess/dark_parseDarkPose 亚像素精修use_darkTrue时启用、get_final_preds通过get_affine_transform(..., inv1)将预测坐标逆变换回原图以及transform_preds/affine_transform。检测类模型YOLO/RCNN 等的 NMS 与坐标解析则由导出的预测程序内完成fetch_vars直接取 NMS 输出服务端只做阈值过滤与格式整理这正是 Python Pipeline 二次开发便捷性的体现——开发者可在此自由扩展自己的后处理。7. 验证部署链路可选经典 Serving 测试方式除了 Python Pipeline 客户端仓库还提供了基于 Serving C 风格的通用测试客户端 deploy/serving/test_client.py其处理流程与pipeline_http_client.py不同使用paddle_serving_client.Client直连 RPC 端口 9393预处理使用paddle_serving_app.reader.Sequential可作为链路验证的补充参考。测试方式对应 deploy/serving/README.mdcd output_inference/yolov3_darknet53_270e_coco/ python -m paddle_serving_server.serve --model serving_server --port 9393 --gpu_ids 0 # GPU # python -m paddle_serving_server.serve --model serving_server --port 9393 # CPU python ../../deploy/serving/test_client.py ../../deploy/serving/label_list.txt ../../demo/000000014439.jpg测试代码会自动创建output文件夹并在其中生成bbox.json与带检测框的可视化图片000000014439.jpg。8. 常见问题与注意事项端口冲突与配置一致性http_port/rpc_port不能同时为空客户端--http_port必须与服务端config.yml中的http_port一致--service_name必须与服务端 OP 名称默认ppdet一致模型目录结构--model_dir必须指向包含infer_cfg.yml、model.pdmodel、model.pdiparams以及serving_server子目录的导出目录web_service.py启动时会校验并解析serving_server_conf.prototxt硬件配置devices为空/不写时走 CPU 预测0表示使用 0 号 GPUdevice_type空缺时由devices推断TensorRT 推理需将device_type设为 2 并确保环境安装对应版本模型架构支持范围SUPPORT_MODELS中列出了服务端内置支持的架构导出模型的arch不在集合内会直接报错遇到不支持的架构需自行扩展 OP 逻辑图像输入约定客户端发送的图片需 base64 编码后放入value字段服务端用 PIL 解码并转为 RGB因此本地测试图片请使用常见格式jpg/jpeg/png/bmp后台运行与日志启动命令末尾的将服务放入后台建议在正式环境中结合 nohup 与日志重定向运行并通过http_port的健康检查确认服务就绪后再发起客户端请求。【免费下载链接】PaddleDetectionObject Detection toolkit based on PaddlePaddle. It supports object detection, instance segmentation, multiple object tracking and real-time multi-person keypoint detection.项目地址: https://gitcode.com/gh_mirrors/pa/PaddleDetection创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考