InsightFace ArcFace Paddle PaddleServing 服务化预测功能测试全解析：TIPC test_serving 流程、配置与日志解读

InsightFace ArcFace Paddle PaddleServing 服务化预测功能测试全解析：TIPC test_serving 流程、配置与日志解读

【免费下载链接】insightfaceState-of-the-art 2D and 3D Face Analysis Project项目地址: https://gitcode.com/GitHub_Trending/in/insightface

导读

本文围绕 recognition/arcface_paddle 中基于 PaddleServing 的服务化部署功能测试展开，系统讲解飞桨训推一体认证（TIPC）中test_serving.sh主程序的完整测试链路：从环境与数据准备（prepare.sh）、测试配置文件解析、服务端模型转换与启动，到 HTTP/RPC 客户端请求与结果日志解读。读完本文，你将掌握 ArcFace 动态图模型在 PaddleServing 下 CPU/GPU 两种硬件、mkldnn/TensorRT 多种加速组合的自动化验证方法，并能自行读懂server_infer_*.log中的特征输出与results_serving.log中的成败判定。

1. 测试定位：TIPC 中的 Serving 预测验证

飞桨训推一体认证（Training and Inference Pipeline Certification，TIPC）为 PaddlePaddle 模型提供"训练—推理—部署"全链路打通情况的标准化测试工具。在 test_tipc/readme.md 的汇总表中，ms1mv2_mobileface模型在"其他预测部署"一栏登记为Paddle Serving: Python，意味着其服务化部署可通过本工具一键测试。

test_serving.md所描述的正是这一项部署能力的验证主程序，其核心职责是：

• 将训练产出的 inference 模型（.pdmodel/.pdiparams）通过paddle_serving_client.convert转换为 Serving 可加载的 server/client 模型；
• 在deploy/pdserving目录下以 pipeline 模式启动web_service.py；
• 用pipeline_http_client.py发送真实图片请求，验证特征提取结果并落盘日志；
• 自动遍历配置文件里声明的 CPU（mkldnn + 多线程）与 GPU（TensorRT + 精度）参数组合，产出可审计的测试报告。

整个测试由三个脚本协作完成：test_serving.sh（测试主程序）、prepare.sh（环境与数据准备）、common_func.sh（通用解析与状态检查函数）。

2. 测试结论汇总

由于本仓库未提供量化训练，因此只测试正常模型。对应的 PaddleServing 预测功能支持情况如下（与test_serving.md原表一致）：

解读这张矩阵：GPU 场景验证use_trt=True/False与precision=fp32的组合；CPU 场景验证use_mkldnn=True与thread_num=1/6的多线程组合。这里1/6取自 serving 配置中thread_num:1|6的枚举值，批大小固定为 1（pipeline 客户端逐张图片发送）。

3. 测试流程总览

整个 Serving 功能测试分为两步：先运行prepare.sh准备数据和模型，再运行test_serving.sh执行测试，最终在test_tipc/output目录下生成serving_infer_*.log后缀的日志文件。

# 第一步：准备 serving 测试所需环境与模型 bash test_tipc/prepare.sh ./test_tipc/configs/ms1mv2_mobileface/model_linux_gpu_normal_normal_serving_python_linux_gpu_cpu.txt "serving_infer" # 第二步：运行 serving 预测功能测试 bash test_tipc/test_serving.sh ./test_tipc/configs/ms1mv2_mobileface/model_linux_gpu_normal_normal_serving_python_linux_gpu_cpu.txt

prepare.sh的第二个参数MODE支持lite_train_infer与serving_infer两种模式，serving_infer分支会完成以下动作：

1. 下载并安装 GPU 版 serving server：paddle_serving_server_gpu-0.0.0.post101-py3-none-any.whl；
2. 安装配套客户端与依赖：paddle_serving_client==0.6.3、paddle-serving-app==0.6.3、werkzeug==2.0.2；
3. 下载 ArcFace inference 模型mobileface_v1.0_infer.tar并解压到./inference/目录。

test_serving.sh还支持第二个可选参数GPUID（即bash test_serving.sh <config> 0），脚本会通过export CUDA_VISIBLE_DEVICES=${GPUID}指定可见 GPU；不传时不做设备限定。

4. 测试配置文件逐项解析

Serving 测试的全部参数都声明在配置文件 model_linux_gpu_normal_normal_serving_python_linux_gpu_cpu.txt 中，test_serving.sh只读取该文件的前 18 行并逐项解析：

===========================serving_params=========================== model_name:arcfae_mobileface python:python3.7 trans_model:-m paddle_serving_client.convert --dirname:./inference/ --model_filename:inference.pdmodel --params_filename:inference.pdiparams --serving_server:./deploy/pdserving/MobileFaceNet_128_serving/ --serving_client:./deploy/pdserving/MobileFaceNet_128_client/ serving_dir:./deploy/pdserving web_service:web_service.py --config=config.yml --opt op.ArcFace.concurrency=1 op.ArcFace.local_service_conf.devices:null|0 op.ArcFace.local_service_conf.use_mkldnn:True|False op.ArcFace.local_service_conf.thread_num:1|6 op.ArcFace.local_service_conf.use_trt:False|True op.ArcFace.local_service_conf.precision:fp32 pipline:pipeline_http_client.py --image_dir=./imgs

各字段含义与作用如下：

以|分隔的字段是枚举列表，脚本会按笛卡尔积遍历所有组合。这些op.ArcFace.local_service_conf.*键会以--opt参数的形式追加到web_service.py启动命令末尾，从而覆盖 config.yml 中的对应配置项。

5. 测试脚本实现原理

test_serving.sh 通过source test_tipc/common_func.sh引入 common_func.sh 中定义的函数，按key:value行格式解析配置：

• func_parser_key/func_parser_value：以:为分隔符拆分每行，取出键与值；
• func_set_params：拼接--key=value形式的命令行参数，遇null或空值则跳过；
• status_check：依据上一条命令退出码将Run successfully / Run failed with command - ...追加写入结果日志。

5.1 模型转换

脚本首先执行模型转换，将 inference 模型转为 Serving 可部署格式：

python3.7 -m paddle_serving_client.convert \ --dirname=./inference/ \ --model_filename=inference.pdmodel \ --params_filename=inference.pdiparams \ --serving_server=./deploy/pdserving/MobileFaceNet_128_serving/ \ --serving_client=./deploy/pdserving/MobileFaceNet_128_client/

转换完成后，deploy/pdserving下会出现两类目录：

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

随后脚本cd到serving_dir（./deploy/pdserving）并unset https_proxy、unset http_proxy，避免代理干扰本地服务通信。

5.2 CPU 与 GPU 双路径遍历

脚本对每个python解释器执行func_serving，按设备枚举分支：

• CPU 路径（use_gpu=null）：遍历use_mkldnn（跳过False）与thread_num，启动命令形如python web_service.py --config=config.yml --opt op.ArcFace.concurrency=1 op.ArcFace.local_service_conf.devices=null op.ArcFace.local_service_conf.use_mkldnn=True op.ArcFace.local_service_conf.thread_num=1 &；
• GPU 路径（use_gpu=0）：遍历use_trt与precision，并做组合合法性过滤——int8精度仅在启用 TensorRT 且存在量化模型时才允许，本仓库无量化模型，因此只落到fp32；
• 其余use_gpu取值打印Does not support hardware other than CPU and GPU Currently!。

服务启动后sleep 2s等待就绪，再运行pipeline_http_client.py --image_dir=./imgs，将输出重定向到按组合命名的日志：

• CPU：server_infer_cpu_${pipeline%_client*}_usemkldnn_${use_mkldnn}_threads_${threads}_batchsize_1.log，例如server_infer_cpu_usemkldnn_True_threads_1_batchsize_1.log；
• GPU：server_infer_gpu_${pipeline%_client*}_usetrt_${use_trt}_precision_${precision}_batchsize_1.log，例如server_infer_gpu_usetrt_True_precision_fp32_batchsize_1.log。

每轮组合结束后，脚本通过ps ux | grep -E 'web_service|pipeline' | awk '{print $2}' | xargs kill -s 9清理残留进程，保证下一组测试环境干净。

6. 运行结果与日志解读

所有组合的成败汇总写入test_tipc/output/results_serving.log。运行成功时输出：

Run successfully with command - python3.7 pipeline_http_client.py --image_dir=./imgs > ../../test_tipc/output/server_infer_cpu_usemkldnn_True_threads_1_batchsize_1.log 2>&1 ! Run successfully with command - xxxxx ...

运行失败时输出：

Run failed with command - python3.7 pipeline_http_client.py --image_dir=./imgs > ../../test_tipc/output/server_infer_cpu_usemkldnn_True_threads_1_batchsize_1.log 2>&1 ! Run failed with command - xxxxx ...

每个组合的详细预测结果保存在对应日志中。以server_infer_gpu_usetrt_True_precision_fp32_batchsize_1.log为例，返回的是 JSON 结构的服务响应，value字段携带人脸特征向量（float32 数组），err_no: 0表示推理成功：

{'err_no': 0, 'err_msg': '', 'key': ['out'], 'value': ['array([[ 1.36603206e-01, -2.12395296e-01, -3.94680113e-01, -3.14380080e-01, -9.66617092e-03, 1.87318385e-01, ... -1.75076187e-01, -1.13026705e-04, 2.48254672e-01, 3.72678041e-01, -4.53566402e-01, 6.30904138e-02, 5.19643247e-01, -1.70341924e-01, -5.24724603e-01, ...]], dtype=float32)']}

该特征向量可直接用于后续的人脸比对（余弦相似度等）验证，是确认服务化部署精度与训练/推理结果是否对齐的关键证据。

7. 服务端与客户端实现细节

7.1 服务端：web_service.py 与 config.yml

服务端入口是 web_service.py，它基于 PaddleServing 的WebService与Op基类实现 pipeline 编排：ArcFaceService.get_pipeline_response将读取算子与ArcFaceOp串成一条 DAG，随后prepare_pipeline_config("config.yml")加载配置并run_service()启动服务。

ArcFaceOp的preprocess完整复刻了 ArcFace 动态图推理的前处理流程，与 deploy/pdserving 目录下的客户端严格对齐：

1. base64.b64decode解码客户端上传的图片字节流；
2. cv2.imdecode还原为 BGR 图像并cv2.resize到112x112；
3. 归一化：img = (img - 127.5) * 0.00784313725（等价于减 127.5 再除以 127.5，映射到[-1, 1]）；
4. BGR2RGB通道翻转、transpose((2, 0, 1))转为 CHW、expand_dims(0)增加 batch 维，输出 float32 张量x。

postprocess从fetch_dict["save_infer_model/scale_0.tmp_1"]取出特征并包装为{"out": out}返回。

服务端口等参数由 config.yml 控制，关键项包括：

7.2 客户端：pipeline_http_client.py

pipeline_http_client.py 是 HTTP 方式请求脚本，核心逻辑为：遍历--image_dir目录下所有图片，base64编码后构造{"key": ["image"], "value": [image]}载荷，POST 到http://127.0.0.1:9998/ArcFace/prediction，逐张打印服务端 JSON 响应，最后输出==> total number of test imgs: N统计测试图片数。仓库同时提供 pipeline_rpc_client.py 支持 RPC 方式请求，二者覆盖了 PaddleServing 的两种主流通信协议。

7.3 手动部署与性能观测

除自动化测试外，也可以按 基于 PaddleServing 的服务部署教程 手动完成全流程：安装paddle-serving-server(-gpu)==0.6.3（GPU 环境需按 CUDA 版本选择post101/post11等变体）、paddle_serving_client==0.6.3、paddle-serving-app==0.6.3，随后下载模型、执行paddle_serving_client.convert转换，再依次运行：

# 启动服务，日志写入 log.txt python3 web_service.py &>log.txt & # 发送请求 python3 pipeline_http_client.py

预测性能数据会自动写入PipelineServingLogs/pipeline.tracer文件。据该教程记录，在 V100 GPU 上对 700 张真实图片测试，QPS 均值约 57（Query count[573]、QPS[57.3 q/s]、平均延迟约 11.5ms），可供压测与调优参考——调整config.yml中op.ArcFace.concurrency可进一步优化吞吐。

8. 常见问题

Q1：发送请求后没有结果返回，或提示输出解码报错？

A1：启动服务和发送请求时不要设置代理。PaddleServing 的本地 pipeline 通信会被代理劫持，导致请求无法到达服务端。关闭代理即可：

unset https_proxy unset http_proxy

该注意事项同时体现在test_serving.sh启动服务前的处理逻辑中，属于自动化测试与手动部署共通的排障要点。

9. 更多教程

test_serving.md为功能测试文档，更完整的 Serving 部署细节（环境安装、模型转换、性能调优、FAQ）请参阅 ArcFace 服务化部署教程；训练与推理侧的同类 TIPC 验证可参考 test_train_inference_python 使用文档 与 TIPC 环境安装文档，它们共同构成了 ArcFace Paddle 模型从训练、推理到服务化部署的完整认证链路。

【免费下载链接】insightfaceState-of-the-art 2D and 3D Face Analysis Project项目地址: https://gitcode.com/GitHub_Trending/in/insightface