InsightFace 基于 PaddleServing 的 ArcFace 人脸识别 Pipeline 在线服务部署指南【免费下载链接】insightfaceState-of-the-art 2D and 3D Face Analysis Project项目地址: https://gitcode.com/GitHub_Trending/in/insightface导读本文介绍如何在 InsightFace 仓库的Arcface-Paddle人脸识别子项目recognition/arcface_paddle中使用 PaddleServing 将 ArcFace 动态图模型部署为可对外提供服务的 pipeline 在线服务。读完本文你将掌握从环境准备、inference 模型到 Serving 模型转换、pipeline 服务端启动、HTTP/RPC 双通道请求发送到基于pipeline.tracer性能日志进行 QPS 调优的完整实战链路并理解 web_service.py 与 config.yml 的源码级工作原理。一、PaddleServing 与 Pipeline 服务模式概述PaddleServing 是 PaddlePaddle 生态的工业级服务化部署框架与 Paddle 训练流程无缝衔接绝大多数 Paddle 模型可以低成本的完成服务化改造。Arcface-Paddle 的人脸识别服务选用 PaddleServing 的Pipeline 模式其核心优势包括客户端与服务端之间支持高并发、高效通信具备工业级服务能力如模型管理、在线加载、在线 A/B 测试等支持多种编程语言C、Python、Java开发客户端。Pipeline 模式将一次推理请求拆分为由多个 Op算子构成的 DAG 工作流请求先进入DAGExecutor调度节点再流入ArcFace识别算子算子内部完成preprocess → 模型推理(midp) → postprocess最后将结果返回客户端。这一点可以从服务运行后的 tracer 日志结构Op(ArcFace)与DAGExecutor两个统计块得到印证后续性能分析一节会详细展开。二、环境准备部署前需要同时准备 ArcFace 的运行环境和 PaddleServing 的运行环境。2.1 ArcFace 运行环境Arcface-Paddle 子项目基于 PaddlePaddle 实现需要先按 recognition/arcface_paddle/install_cn.md 配置基础实验环境。根据当前环境下载对应的 paddle whl 包推荐安装 2.2 版本。该子项目提供人脸检测BlazeFace与人脸识别ArcFace / MobileFace的预训练模型本文只涉及人脸识别部分的 Serving 部署。2.2 PaddleServing 运行环境PaddleServing 侧需要安装三个组件分别承担服务端、客户端与 Pipeline 应用框架的职责1. 安装 serving用于启动服务pip3 install paddle-serving-server0.6.3 # for CPU pip3 install paddle-serving-server-gpu0.6.3 # for GPU # 其他 GPU 环境需要确认环境再选择执行如下命令 pip3 install paddle-serving-server-gpu0.6.3.post101 # GPU with CUDA10.1 TensorRT6 pip3 install paddle-serving-server-gpu0.6.3.post11 # GPU with CUDA11 TensorRT72. 安装 client用于向服务发送请求pip3 install paddle_serving_client0.6.33. 安装 serving-appPipeline 应用框架pip3 install paddle-serving-app0.6.3NoteCPU 与 GPU 版本的 serving-server 包不能混装GPU 版本需要根据 CUDA 与 TensorRT 的版本选择对应的 post 后缀。如需安装最新版本 PaddleServing请参考 PaddleServing 官方 LATEST_PACKAGES 文档。三、模型转换从 Inference 模型到 Serving 模型使用 PaddleServing 做服务化部署时需要先将训练导出的 inference 模型转换为 Serving 易于部署的模型格式。Arcface-Paddle 训练好的模型可通过 scripts/export_dynamic.sh 或tools/export.py导出为save inference model含*.pdmodel/*.pdiparams导出逻辑见 dynamic/export.py其InputSpec固定为[None, 3, 112, 112]的 float32 输入与 Serving 端预处理逻辑严格对应。3.1 下载 ArcFace Inference 模型# 下载并解压 Arcface 模型 wget -nc -P ./inference https://paddle-model-ecology.bj.bcebos.com/model/insight-face/mobileface_v1.0_infer.tar tar xf inference/mobileface_v1.0_infer.tar --strip-components 1 -C inferencemobileface_v1.0_infer.tar即 MobileFaceNet_128 backbone 训练出的 MobileFace-Paddle 预训练模型对应 recognition/arcface_paddle/README_cn.md 中轻量化模型性能表lfw 0.9952 / cfp_fp 0.9280 / agedb30 0.9612。3.2 使用 paddle_serving_client 转换模型python3 -m paddle_serving_client.convert --dirname ./inference/ \ --model_filename inference.pdmodel \ --params_filename inference.pdiparams \ --serving_server ./MobileFaceNet_128_serving/ \ --serving_client ./MobileFaceNet_128_client/转换完成后当前文件夹会多出MobileFaceNet_128_serving/和MobileFaceNet_128_client/两个目录格式如下MobileFaceNet_128_serving ├── __model__ ├── __params__ ├── serving_server_conf.prototxt └── serving_server_conf.stream.prototxt MobileFaceNet_128_client/ ├── serving_client_conf.prototxt └── serving_client_conf.stream.prototxt其中serving_server_conf.prototxt描述了服务端模型的输入输出fetch变量fetch 变量名与后续 config.yml 中fetch_list的配置必须一一对应——这是转换环节与部署环节之间的关键契约。四、Paddle Serving Pipeline 部署实战4.1 工作目录与文件清单获取 insightface 代码并进入 pdserving 工作目录若已下载可跳过 clone 步骤git clone https://github.com/deepinsight/insightface # 进入到工作目录 cd recognition/arcface_paddle/deploy/pdservingpdserving目录包含启动 pipeline 服务和发送预测请求的完整代码文件清单如下文件职责__init__.py包初始化文件config.yml启动服务的配置文件端口、并发、模型路径等pipeline_http_client.py通过 HTTP 方式发送 pipeline 预测请求的脚本pipeline_rpc_client.py通过 RPC 方式发送 pipeline 预测请求的脚本web_service.py启动 pipeline 服务端的脚本4.2 启动服务# 启动服务运行日志保存在 log.txt python3 web_service.py log.txt 成功启动服务后log.txt 中会打印类似如下日志图示为服务启动成功的标准输出包含 Serving 框架版本、pipeline 配置加载与端口监听信息服务端源码解析web_service.py 定义了三个关键要素ArcFaceOp算子继承自paddle_serving_server.web_service.Op实现 pipeline 的preprocess与postprocesspreprocess对客户端传来的 base64 图像解码cv2.imdecode→resize到 112×112 → 按(img - 127.5) * 0.00784313725归一化到 mean 0.5 / std 0.5 → BGR2RGB → 转 CHW → 增加 batch 维并转为 float32最终以{x: img}作为模型输入。该预处理与模型训练时的数据规范完全一致。postprocess从fetch_dict中取出save_infer_model/scale_0.tmp_1即 128 维人脸 embedding 输出包装为{out: out}返回。ArcFaceService服务类继承WebService在get_pipeline_response中构建 DAG——ArcFaceOp的上游是read_op框架内置的请求读取算子构成read_op → ArcFace的单算子链路。入口逻辑实例化服务、加载config.ymlprepare_pipeline_config并run_service()启动。4.3 发送服务请求方式一HTTP 请求python3 pipeline_http_client.pypipeline_http_client.py 的核心逻辑是将--image_dir默认./imgs下的每张图片读取为二进制后做 base64 编码向http://127.0.0.1:9998/ArcFace/prediction发起 POST 请求请求体为{key: [image], value: [image]}的 JSON 结构随后逐条打印r.json()返回结果。成功运行后模型预测的结果会打印在 cmd 窗口中结果示例为方式二RPC 请求pipeline_rpc_client.py 演示了 RPC 通道的用法优先从paddle_serving_server_gpu.pipeline导入PipelineClient失败时回退到paddle_serving_server.pipeline通过client.connect([127.0.0.1:18091])连接 RPC 端口再以client.predict(feed_dict{image: image}, fetch[res])发送预测。注意 RPC 客户端默认图片目录为../../doc/imgs/可用--image_dir覆盖。两个客户端脚本都支持--image_dir参数便于批量压测时指向自定义图片目录也可以同时启动多个客户端进程并发发送请求。4.4 config.yml 关键配置详解config.yml 是调优的核心逐项说明如下配置项取值示例含义与调优要点rpc_port18091RPC 端口。rpc_port和http_port不允许同时为空当 rpc_port 为空且 http_port 非空时会自动将 rpc_port 设为 http_port1http_port9998HTTP 端口。当 rpc_port 可用且 http_port 为空时不会自动生成 http_portworker_num10最大并发数。build_dag_each_workerTrue时框架创建 worker_num 个进程每进程内构建 gRPC Server 和 DAG为 False 时框架设置主线程 gRPC 线程池的max_workersworker_numbuild_dag_each_workerFalseFalse 时框架在进程内创建一条 DAGTrue 时每进程内创建多条独立 DAGdag.is_thread_opFalseOp 资源类型True 为线程模型False 为进程模型dag.retry10请求重试次数dag.use_profileTrue是否使用性能分析True 会生成 Timeline 性能数据对性能有一定影响dag.tracer.interval_s10tracer 性能统计的时间间隔秒op.ArcFace.concurrency8算子并发数is_thread_opTrue时为线程并发否则为进程并发op.ArcFace.local_service_conf.client_typelocal_predictor客户端类型包括 brpc、grpc 和 local_predictorlocal_predictor不启动 Serving 服务进程内直接预测op.ArcFace.local_service_conf.model_config./MobileFaceNet_128_serving服务端模型路径即 3.2 节转换产物op.ArcFace.local_service_conf.fetch_list[save_infer_model/scale_0.tmp_1]Fetch 结果列表以 client_config 中 fetch_var 的 alias_name 为准与 postprocess 读取的输出名一致op.ArcFace.local_service_conf.devices0计算硬件 ID为空或不写时为 CPU 预测0、0,1,2时为 GPU 预测表示使用的 GPU 卡op.ArcFace.local_service_conf.ir_optimTrue是否开启 IR 图优化4.5 性能调优与 QPS 观测调整并发数修改 config.yml 中ArcFace算子的concurrency可获得最大的 QPS。本例为单人脸识别单算子服务检测识别双算子场景下检测与识别的并发数一般建议为 2:1。ArcFace: # 并发数is_thread_opTrue 时为线程并发否则为进程并发 concurrency: 8 ...观测性能数据预测性能数据会被自动写入PipelineServingLogs/pipeline.tracer文件。该文件记录了 Op 各阶段耗时in/prep/midp/postp/out/idle、DAGExecutor 的查询数、QPS、成功率、错误请求数、延迟分位数以及 Channel 队列水位。以下是在 700 张真实图片上、V100 GPU 环境下的实测日志均值 QPS 约 57可作为调优前后的对照基准2021-11-04 13:38:52,507 Op(ArcFace): 2021-11-04 13:38:52,507 in[135.4579597902098 ms] 2021-11-04 13:38:52,507 prep[0.9921311188811189 ms] 2021-11-04 13:38:52,507 midp[3.9232132867132865 ms] 2021-11-04 13:38:52,507 postp[0.12166258741258741 ms] 2021-11-04 13:38:52,507 out[0.9898286713286714 ms] 2021-11-04 13:38:52,508 idle[0.9643989520087675] 2021-11-04 13:38:52,508 DAGExecutor: 2021-11-04 13:38:52,508 Query count[573] 2021-11-04 13:38:52,508 QPS[57.3 q/s] 2021-11-04 13:38:52,508 Succ[0.9982547993019197] 2021-11-04 13:38:52,508 Error req[394] 2021-11-04 13:38:52,508 Latency: 2021-11-04 13:38:52,508 ave[11.52941186736475 ms] 2021-11-04 13:38:52,508 .50[11.492 ms] 2021-11-04 13:38:52,508 .60[11.658 ms] 2021-11-04 13:38:52,508 .70[11.95 ms] 2021-11-04 13:38:52,508 .80[12.251 ms] 2021-11-04 13:38:52,508 .90[12.736 ms] 2021-11-04 13:38:52,508 .95[13.21 ms] 2021-11-04 13:38:52,508 .99[13.987 ms] 2021-11-04 13:38:52,509 Channel (server worker num[10]): 2021-11-04 13:38:52,509 chl0(In: [DAGExecutor], Out: [ArcFace]) size[0/0] 2021-11-04 13:38:52,509 chl1(In: [ArcFace], Out: [DAGExecutor]) size[0/0]日志解读要点Op(ArcFace)块中in为算子接收数据耗时prep为预处理耗时本示例仅约 1ms得益于 base64 解码 resize 归一化的轻量实现midp为模型推理耗时约 3.9mspostp为后处理耗时约 0.12msidle为算子空闲比例0.96 表示算子大部分时间处于空闲说明当前瓶颈不在该算子而在请求入口。DAGExecutor块中Succ[0.9982547993019197]表示请求成功率Error req[394]与Query count[573]的对比说明存在少量失败请求可结合 FAQ 排查Latency给出平均与各分位延迟。Channel块展示 DAG 节点间的队列积压size[0/0] 表示队列无积压链路健康。五、FAQQ1发送请求后没有结果返回或者提示输出解码报错。A1启动服务和发送请求时不要设置代理。可以在启动服务前和发送请求前关闭代理关闭代理的命令是unset https_proxy unset http_proxy代理环境变量会干扰 Serving 框架内部的网络通信尤其是在 base64 图像数据量较大时导致请求超时或响应体无法正常解码。此外若日志中出现大量Error req还可依次检查模型转换目录是否与 config.yml 的model_config路径一致、fetch_list中的输出别名是否与转换后serving_server_conf.prototxt一致、devices配置是否与机器实际的 GPU 卡号匹配。六、总结与延伸至此你已经走通了 Arcface-Paddle 人脸识别模型在 PaddleServing Pipeline 模式下的完整部署链路环境准备 → inference 模型下载 →paddle_serving_client.convert模型转换 →web_service.py启动服务 → HTTP/RPC 客户端发送请求 → 依据pipeline.tracer调整concurrency与worker_num进行 QPS 调优。整个部署环节的入口与源码全部位于 recognition/arcface_paddle/deploy/pdserving 目录模型训练与导出侧的完整流程可进一步参考 recognition/arcface_paddle/README_cn.md。在此基础上如需构建完整的人脸识别服务检测识别串联、人脸底库检索、可视化可以继续探索 Arcface-Paddle 的 Whl 包预测部署方案与全流程推理脚本见 recognition/arcface_paddle/README_cn.md 第 9 节将 Serving 输出的 128 维 embedding 与底库索引进行比对即可形成可上线的业务闭环。【免费下载链接】insightfaceState-of-the-art 2D and 3D Face Analysis Project项目地址: https://gitcode.com/GitHub_Trending/in/insightface创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
