服务化部署框架Paddle Serving
概述
常见的深度学习模型开发流程需要经过问题定义、数据准备、特征提取、建模、训练过程，以及最后一个环——将训练出来的模型部署应用到实际业务中。如图1所示，当前用户在训练出一个可用的模型后，可以选择如下四种部署应用方式：
• 服务器端高性能部署：将模型部署在服务器上，利用服务器的高性能帮助用户处理推理业务。
• 模型服务化部署：将模型以线上服务的形式部署在服务器或者云端，用户通过客户端，请求发送需要推理的输入内容，服务器或者云通过响应报文将推理结果返回给用户。
• 移动端部署：将模型部署在移动端上，例如手机或者物联网的嵌入式端。
• Web端部署：将模型部署在网页上，用户通过网页完成推理业务。
图1 部署的四种方式
本文介绍的Paddle Serving就是第二种部署方式，这种方式与其它方式相比，对于使用者来说，最大的特点就是“独乐乐不如众乐乐”。也就是说，在模型部署成功后，不同用户都可以通过客户端，以发送网络请求的方式获得推理服务。如图2所示，通过建模、训练获得的模型在部署到云端后形成云服务，例如百度云，百度云会和负载均衡的模块连接，其中负载均衡模块的作用是防止访问流量过大。用户可以通过手机、电脑等设备访问云上的推理服务。
图2 在线推理服务工作流程
此外在实际应用中，部署的场景可能会非常复杂。如图3所示，在某些用户的业务中，需要将多个模型分阶段、联合使用，例如某些个性化推荐场景，其中就需要部署召回、排序、融合等多种模型，且模型间会形成上下游关系，相互配合实现业务相关推理功能。如何能将模型成功部署到硬件环境上已成为用户普遍关注的问题，这个如同长跑的冲刺阶段，模型是否能被应用到实际业务中就在此一举。而Paddle Serving作为飞桨（PaddlePaddle）开源的在线服务框架，长期目标就是围绕着人工智能落地的最后一公里提供越来越专业、可靠、易用的服务。
图3 多模型应用示意图
Paddle Serving具有三大优势：
• 简单易用：为了让使用Paddle的用户能够以极低的成本部署模型，PaddleServing设计了一套与Paddle训练框架无缝打通的预测部署API，普通模型可以使用一行命令进行服务部署。完全采用Python语音的开发接口，适合广大开发者学习和调用。
• 工业级实践：为了达到工业级深度学习模型在线部署的要求， Paddle Serving提供很多大规模场景需要的部署功能。
o 多模型串联流水线部署
o 异构部署，支持ARM，XPU等设备
o 多语言多平台支持
• 二次开发：方便Web应用的开发者在不用写代码的情况下快速调用推理服务。此外Paddle Serving支持多语言的的客户端，未来也会面向不同类型的客户新增多种语言的客户端，方便使用不同语言系统的开发者通过客户端调用服务。 【占位，放一张异构部署的图片】
环境安装
在使用Paddle Serving之前，用户需要完成如下任务：
- 安装python3.7及3.7以上版本，具体安装方法请参见Python官方网站。
- 安装paddlepaddle 1.8版本，具体安装方法请参见快速安装章节。
- 安装CUDA 9.0版本。并设置环境变量设，由于Paddle Serving目前官方包支持CUDA-9.0因此需要设置环境变量。
操作步骤
wget https://paddle-serving.bj.bcebos/aistudio/cuda-9.0-aistudio-env.tar.gz
tar xf cuda-9.0-aistudio-env.tar.gz
export LD_LIBRARY_PATH=/home/aistudio/env/cuda-9.0/lib64: L D L I B R A R Y P A T H ! w g e t h t t p s : / / p a d d l e − s e r v i n g . b j . b c e b o s . c o m / a i s t u d i o / c u d a − 9.0 − a i s t u d i o − e n v . t a r . g z ! t a r x f c u d a − 9.0 − a i s t u d i o − e n v . t a r . g z ! e x p o r t L D L I B R A R Y P A T H = / h o m e / a i s t u d i o / e n v / c u d a − 9.0 / l i b 64 : LD_LIBRARY_PATH !wget https://paddle-serving.bj.bcebos/aistudio/cuda-9.0-aistudio-env.tar.gz !tar xf cuda-9.0-aistudio-env.tar.gz !export LD_LIBRARY_PATH=/home/aistudio/env/cuda-9.0/lib64: LDLIBRARYPATH!wgethttps://paddle−serving.bj.bcebos.com/aistudio/cuda−9.0−aistudio−env.tar.gz!tarxfcuda−9.0−aistudio−env.tar.gz!exportLDLIBRARYPATH=/home/aistudio/env/cuda−9.0/lib64:LD_LIBRARY_PATH
–2021-01-30 12:43:57-- https://paddle-serving.bj.bcebos/aistudio/cuda-9.0-aistudio-env.tar.gz
Resolving paddle-serving.bj.bcebos (paddle-serving.bj.bcebos)… 182.61.200.195, 182.61.200.229, 2409:8c00:6c21:10ad:0:ff:b00e:67d
Connecting to paddle-serving.bj.bcebos (paddle-serving.bj.bcebos)|182.61.200.195|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 2329036800 (2.2G) [application/x-gzip]
Saving to: ‘cuda-9.0-aistudio-env.tar.gz’
cuda-9.0-aistudio-e 100%[===================>] 2.17G 89.7MB/s in 27s
2021-01-30 12:44:24 (82.8 MB/s) - ‘cuda-9.0-aistudio-env.tar.gz’ saved [2329036800/2329036800]
- 安装Paddle Serving。用户可以选择Docker或者PIP安装方式。当前在AI Studio上仅能使用pip安装方式，但是在实际环境中，推荐使用Docker方式进行安装，因为使用Docker方式安装Paddle Serving时，一些必须的组件或插件也会被同时安装，确保用户正常使用Paddle Serving。
Docker安装方式
注：本文有关Docker的操作需要在支持Docker的服务器上操作，本AIStudio笔记本上的操作请忽略Docker相关的介绍
启动 CPU Docker
1.获取镜像
可以通过如下两种方式获取镜像：
• 直接拉取镜像
docker pull hub.baidubce/paddlepaddle/serving:0.4.1-devel
• 基于Dockerfile构建镜像。建立新目录，复制Dockerfile内容到该目录下Dockerfile文件。
docker build -t hub.baidubce/paddlepaddle/serving:0.4.1-devel .
2. 创建容器并进入
docker run -p 9292:9292 --name test -dit hub.baidubce/paddlepaddle/serving:0.4.1-devel
docker exec -it test bash
其中-p选项是为了将容器的9292端口映射到宿主机的9292端口。
3. 安装PaddleServing
为了减小镜像的体积，镜像中没有安装Serving包，要执行下面命令进行安装。
pip install paddle-serving-server
如果下载速度缓慢，您可以使用国内镜像源（例如清华源）来提高下载速度。
pip install paddle-serving-server -i https://pypi.tuna.tsinghua.edu/simple
启动 GPU Docker
GPU版本与CPU版本基本一致，只有部分接口命名的差别（GPU版本需要在GPU机器上安装nvidia-docker）。
- 获取镜像
可以通过两种方式获取镜像。
• 直接拉取镜像。
nvidia-docker pull hub.baidubce/paddlepaddle/serving: T A G • 基 于 D o c k e r f i l e 构 建 镜 像 。 建 立 新 目 录 ， 复 制 D o c k e r f i l e . g p u 内 容 到 该 目 录 下 D o c k e r f i l e 文 件 。 n v i d i a − d o c k e r b u i l d − t h u b . b a i d u b c e . c o m / p a d d l e p a d d l e / s e r v i n g : {TAG} • 基于Dockerfile构建镜像。建立新目录，复制Dockerfile.gpu内容到该目录下Dockerfile文件。 nvidia-docker build -t hub.baidubce/paddlepaddle/serving: TAG•基于Dockerfile构建镜像。建立新目录，复制Dockerfile.gpu内容到该目录下Dockerfile文件。nvidia−dockerbuild−thub.baidubce.com/paddlepaddle/serving:{TAG}
${TAG}根据上面给的表格，确定好自己的环境平台替换上来即可。 - 创建容器并进入
nvidia-docker run -p 9292:9292 --name test -dit hub.baidubce/paddlepaddle/serving:${TAG}
nvidia-docker exec -it test bash
-p选项是为了将容器的9292端口映射到宿主机的9292端口。 - 安装PaddleServing
为了减小镜像的体积，镜像中没有安装Serving包，要执行下面命令进行安装。
pip install paddle-serving-server-gpu
如果下载速度缓慢，可以使用国内镜像源（例如清华源）来提高下载速度。
pip install paddle-serving-server-gpu -i https://pypi.tuna.tsinghua.edu/simple
PIP安装方式
根据硬件环境与角色选择如下pip命令安装Paddle Serving。
• 安装客户端：pip install paddle-serving-client
• 安装服务器端：
o 安装CPU服务端：pip install paddle-serving-server
o 安装GPU服务端：pip install paddle-serving-server-gpu
• 安装工具组件：pip install paddle-serving-app
本例中推荐使用GPU环境作为服务端，因此请执行如下命令安装Paddle Serving。
• 因为Paddle Serving 0.4.1版本还在测试，因此在这里先给出测试版本，所有测试版本请参见最新wheel包合集
操作步骤：
pip install https://paddle-serving.bj.bcebos/whl/paddle_serving_client-0.0.0-cp37-none-any.whl
pip install https://paddle-serving.bj.bcebos/whl/paddle_serving_app-0.0.0-py3-none-any.whl
pip install https://paddle-serving.bj.bcebos/whl/paddle_serving_server_gpu-0.0.0.post9-py3-none-any.whl
pip install -r python/requirements.txt
git clone https://hub.fastgit/PaddlePaddle/Serving -b v0.4.1
!pip install https://paddle-serving.bj.bcebos/whl/paddle_serving_client-0.0.0-cp37-none-any.whl
!pip install https://paddle-serving.bj.bcebos/whl/paddle_serving_app-0.0.0-py3-none-any.whl
!pip install https://paddle-serving.bj.bcebos/whl/paddle_serving_server_gpu-0.0.0.post9-py3-none-any.whl
!pip install -r python/requirements.txt
!git clone https://hub.fastgit/PaddlePaddle/Serving -b v0.4.1
Looking in indexes: https://mirror.baidu/pypi/simple/
Collecting paddle-serving-client0.0.0 from https://paddle-serving.bj.bcebos/whl/paddle_serving_client-0.0.0-cp37-none-any.whl
Downloading https://paddle-serving.bj.bcebos/whl/paddle_serving_client-0.0.0-cp37-none-any.whl (48.1MB)
|████████████████████████████████| 48.1MB 3.7MB/s eta 0:00:01
Requirement already satisfied: protobuf>=3.11.0 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-client0.0.0) (3.12.2)
Collecting grpcio-tools<=1.33.2 (from paddle-serving-client0.0.0)
Downloading https://mirror.baidu/pypi/packages/48/2d/af56365408476ddcbc9a10a6b1aa2556060ef3081b7ee676423ddc4f98cf/grpcio_tools-1.33.2-cp37-cp37m-manylinux2010_x86_64.whl (2.5MB)
|████████████████████████████████| 2.5MB 11.4MB/s eta 0:00:01
Requirement already satisfied: grpcio<=1.33.2 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-client0.0.0) (1.26.0)
Requirement already satisfied: numpy>=1.12 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-client0.0.0) (1.16.4)
Requirement already satisfied: six>=1.10.0 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-client0.0.0) (1.15.0)
Requirement already satisfied: setuptools in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from protobuf>=3.11.0->paddle-serving-client0.0.0) (41.4.0)
ERROR: grpcio-tools 1.33.2 has requirement grpcio>=1.33.2, but you’ll have grpcio 1.26.0 which is incompatible.
Installing collected packages: grpcio-tools, paddle-serving-client
Successfully installed grpcio-tools-1.33.2 paddle-serving-client-0.0.0
Looking in indexes: https://mirror.baidu/pypi/simple/
Collecting paddle-serving-app0.0.0 from https://paddle-serving.bj.bcebos/whl/paddle_serving_app-0.0.0-py3-none-any.whl
Downloading https://paddle-serving.bj.bcebos/whl/paddle_serving_app-0.0.0-py3-none-any.whl (49kB)
|████████████████████████████████| 51kB 2.5MB/s eta 0:00:01
Requirement already satisfied: opencv-python in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-app0.0.0) (4.1.1.26)
Requirement already satisfied: pillow in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-app0.0.0) (7.1.2)
Requirement already satisfied: sentencepiece in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-app0.0.0) (0.1.85)
Requirement already satisfied: six>=1.10.0 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-app0.0.0) (1.15.0)
Collecting pyclipper (from paddle-serving-app0.0.0)
Downloading https://mirror.baidu/pypi/packages/69/5b/92df65d3e1e5c5623e67feeac92a18d28b0bf11bdd44d200245611b0fbb8/pyclipper-1.2.1-cp37-cp37m-manylinux1_x86_64.whl (126kB)
|████████████████████████████████| 133kB 17.6MB/s eta 0:00:01
Requirement already satisfied: numpy>=1.14.5 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from opencv-python->paddle-serving-app0.0.0) (1.16.4)
Installing collected packages: pyclipper, paddle-serving-app
Successfully installed paddle-serving-app-0.0.0 pyclipper-1.2.1
Looking in indexes: https://mirror.baidu/pypi/simple/
Collecting paddle-serving-server-gpu0.0.0.post9 from https://paddle-serving.bj.bcebos/whl/paddle_serving_server_gpu-0.0.0.post9-py3-none-any.whl
Downloading https://paddle-serving.bj.bcebos/whl/paddle_serving_server_gpu-0.0.0.post9-py3-none-any.whl (8.2MB)
|████████████████████████████████| 8.2MB 4.3MB/s eta 0:00:01
Collecting func-timeout (from paddle-serving-server-gpu0.0.0.post9)
Downloading https://mirror.baidu/pypi/packages/b3/0d/bf0567477f7281d9a3926c582bfef21bff7498fc0ffd3e9de21811896a0b/func_timeout-4.3.5.tar.gz (44kB)
|████████████████████████████████| 51kB 16.7MB/s eta 0:00:01
Requirement already satisfied: pyyaml in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-server-gpu0.0.0.post9) (5.1.2)
Requirement already satisfied: protobuf>=3.11.0 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-server-gpu0.0.0.post9) (3.12.2)
Requirement already satisfied: flask>=1.1.1 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-server-gpu0.0.0.post9) (1.1.1)
Requirement already satisfied: grpcio<=1.33.2 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-server-gpu0.0.0.post9) (1.26.0)
Requirement already satisfied: grpcio-tools<=1.33.2 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-server-gpu0.0.0.post9) (1.33.2)
Requirement already satisfied: six>=1.10.0 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from paddle-serving-server-gpu0.0.0.post9) (1.15.0)
Requirement already satisfied: setuptools in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from protobuf>=3.11.0->paddle-serving-server-gpu0.0.0.post9) (41.4.0)
Requirement already satisfied: Jinja2>=2.10.1 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from flask>=1.1.1->paddle-serving-server-gpu0.0.0.post9) (2.10.1)
Requirement already satisfied: click>=5.1 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from flask>=1.1.1->paddle-serving-server-gpu0.0.0.post9) (7.0)
Requirement already satisfied: itsdangerous>=0.24 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from flask>=1.1.1->paddle-serving-server-gpu0.0.0.post9) (1.1.0)
Requirement already satisfied: Werkzeug>=0.15 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from flask>=1.1.1->paddle-serving-server-gpu0.0.0.post9) (0.16.0)
Requirement already satisfied: MarkupSafe>=0.23 in /opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages (from Jinja2>=2.10.1->flask>=1.1.1->paddle-serving-server-gpu0.0.0.post9) (1.1.1)
Building wheels for collected packages: func-timeout
Building wheel for func-timeout (setup.py) … done
Created wheel for func-timeout: filename=func_timeout-4.3.5-cp37-none-any.whl size=15078 sha256=149e91a6b64aba8d61b0f24e390247c7f54d107bc9f75cfe5b4fbaef55aaeebe
Stored in directory: /home/aistudio/.cache/pip/wheels/b6/02/ef/ed29b2e7ce11e342849cf84b8a551bc3ad028b4c2e5d2172db
Successfully built func-timeout
Installing collected packages: func-timeout, paddle-serving-server-gpu
Successfully installed func-timeout-4.3.5 paddle-serving-server-gpu-0.0.0.post9
ERROR: Could not open requirements file: [Errno 2] No such file or directory: ‘python/requirements.txt’
fatal: destination path ‘Serving’ already exists and is not an empty directory.
如果下载速度缓慢，可以使用国内镜像源（例如清华源，可以在pip命令中添加-i https://pypi.tuna.tsinghua.edu/simple）来加速下载。 客户端安装包支持Centos 7和Ubuntu 18，或者可以使用HTTP服务，这种情况下不需要安装客户端。
快速体验部署在线推理服务
使用Paddle Serving部署在线推理服务的过程非常简单，主要分为3个步骤，获取可用于部署在线服务的模型、启动服务端和使用客户端访问服务端进行推理，也就是说最多3步就可以完成部署，是不是像把大象关到冰箱里一样简单？具体怎么操作，咱们以常用的波士顿房价预测模型为例，快速体验一下如何将这个模型部署到服务器上。 为了方便用户操作，本文已经把房价预测相关的模型文件，保存在fit_a_line文件夹内的uci_housing_client和uci_housing_model文件夹中，用户可以直接跳过第一步，直接使用如下命令启动在线服务。
当出现如下类型的显示信息时，并且命令一直处于运行状态，则代表服务端已经启动成功。之所以一直处于运行状态，因为服务器会一直处于监听客户端请求信息的状态。
— Running analysis [ir_graph_build_pass]
— Running analysis [ir_graph_clean_pass]
— Running analysis [ir_analysis_pass]
— Running analysis [ir_params_sync_among_devices_pass]
— Running analysis [adjust_cudnn_workspace_size_pass]
— Running analysis [inference_op_replace_pass]
— Running analysis [ir_graph_to_program_pass]
启动成功后，用户可以通过命令中name参数指定的URL名称，访问服务端使用推理服务。请在终端-1执行如下命令体验推理服务。其中"x": [0.0137, -0.1136, 0.2553, -0.0692, 0.0582, -0.0727, -0.1583, -0.0584, 0.6283, 0.4919, 0.1856, 0.0795, -0.0332]是房价预测的13个特征值。需要推理的值是"price"。
curl -H “Content-Type:application/json” -X POST -d ‘{“feed”:[{“x”: [0.0137, -0.1136, 0.2553, -0.0692, 0.0582, -0.0727, -0.1583, -0.0584, 0.6283, 0.4919, 0.1856, 0.0795, -0.0332]}], “fetch”:[“price”]}’ http://127.0.0.1:9393/uci/prediction
预期结果
{“result”:{“price”:[[18.901151657104492]]}}
• 以上过程可以说是完全0代码部署在线推理服务，当然这只是最简单的Paddle Serving的使用方式，其中服务端和客户端之间是使用的HTTP协议通信，并且用户需要推理的输入数据也不需要进行预处理操作。如果用户希望使用性能更好的通信协议，或者需要部署的模型稍微复杂一些，需要数据预处理，那么就需要使用下面的部署的进阶方案了。
说明：在执行下面的命令之前，先中断前面的启动服务端程序。
部署在线推理服务进阶流程
所谓进阶流程，其实还是那三个步骤，获取可用于部署的在线服务的模型、启动服务端和使用客户端访问服务端进行推理。只是每个步骤将会详细介绍一下，有的地方还要编写少量的代码。将逐一介绍具体过程及原理，此外为了保证读者理解上的连贯性，把启动服务端和使用客户端访问服务端，进行推理两个步骤合成一个步骤进行介绍。 - 获取可用于部署在线服务的模型
首先来看获取可用于部署在线服务的模型。有的同学可能会说：“已经有了训练好的模型了，是不是可以直接看第二步了呢？”回答是：“留步，训练好的模型未必可以直接用Paddle Serving进行部署。”通常训练过程是使用的save_inference_mode接口保存模型的，但是这样保存的模型文件中缺少Paddle Serving部署所需要的配置文件。当前Paddle Serving提供了一个save_model的API接口，用于帮助用户在训练过程中保存模型，即将Paddle Serving在部署阶段需要用到的参数与配置文件统一保存打包。相关API接口的应用示例代码如下所示，只要参考下面两行代码将训练程序中的save_inference_mode替换为save_model，就可以训练出供Paddle Serving使用的模型文件了。示例中，{“words”: data}和{“prediction”: prediction}分别指定了模型的输入和输出，“words"和"prediction"输入和输出变量的别名，设计别名的目的是为了便于开发者能够记忆自己训练模型的输入输出对应的字段。
静态图
import paddle_serving_client.io as serving_io
serving_io.save_model(“serving_model”, “client_conf”,
{“words”: data}, {“prediction”: prediction},
fluid.default_main_program())
动态图
import paddle_serving_client.io as serving_io
serving_io.save_dygraph_model(“serving_model”, “client_conf”, model)
此时可能有的用户会比较不爽，因为按照上面的方法来操作的话，就要重新训练模型。因为众所周知，训练一个模型一般都要花费比较长的时间，这相当于前功尽弃啊！别着急，这种情况也在的考虑范围之内，准备关闭手下留情，且往下看。 如果用户已使用paddlejit.save(动态图) 或者 save_inference_model接口(静态图)保存出可用于推理的模型，Paddle Serving为大家提供了paddle_serving_client.convert接口，该接口可以把已保存的模型转换成可用于Paddle Serving使用的模型文件。相关API接口的应用示例代码如下所示，
python -m paddle_serving_client.convert --dirname $MODEL_DIR --model_filename $MODEL_FILENAME --params_filename PARAMS_FILENAME --serving_server $SERVING_SERVER_DIR --serving_client $SERVING_CLIENT_DIR
其中各个参数解释如下所示：
• dirname (str) – 需要转换的模型文件存储路径，Program结构文件和参数文件均保存在此目录。
• serving_server (str, 可选) - 转换后的模型文件和配置文件的存储路径。默认值为serving_server。
• serving_client (str, 可选) - 转换后的客户端配置文件存储路径。默认值为serving_client。
• model_filename (str，可选) – 存储需要转换的模型Inference Program结构的文件名称。如果设置为None，则使用 model 作为默认的文件名。默认值为None。
• params_filename (str，可选) – 存储需要转换的模型所有参数的文件名称。当且仅当所有模型参数被保存在一个单独的二进制文件中，它才需要被指定。如果模型参数是存储在各自分离的文件中，设置它的值为None。默认值为None。
上面介绍了两种获取可用于部署在线服务的模型的方法，根据上面的两个例子，新模型保存成功后，飞桨都会按照用户指定的"serving_model和"client_conf”"生成两个目录，如下所示：
.
├── client_conf
│ ├── serving_client_conf.prototxt
│ └── serving_client_conf.stream.prototxt
└── serving_model
├── params
├── model
├── serving_server_conf.prototxt
└── serving_server_conf.stream.prototxt
其中，"serving_client_conf.prototxt"和"serving_server_conf.prototxt"是Paddle Serving的客户端和服务端需要加载的配置，“serving_client_conf.stream.prototxt"和"serving_server_conf.stream.prototxt"是配置文件的二进制形式。“serving_model"下保存的其它内容和原先的save_inference_mode接口保存的模型文件是一致的。未来会考虑在Paddle框架中直接保存可服务的配置，实现配置保存对用户无感，提升用户体验。
获取模型的方法讲完了，可以实际操作一下。进阶部署流程将以部署IMDB评论情感分析在线服务为例进行讲解。IMDB评论情感分析任务是对电影评论的内容进行推理，是一种二分类问题，即判断该评论是属于正面评论还是负面评论。IMDB评论情感分析任务相关的文件保存在imdb文件夹中，训练数据与测试数据分别保存在train_data和test_data文件夹里。以下面这条训练数据为例。这是一条英文评论样本，样本中使用|作为分隔符，分隔符之前为评论的内容，分隔符之后是样本的标签，0代表负样本，即负面评论，1代表正样本，即正面评论。
saw a trailer for this on another video, and decided to rent when it came out. boy, was i disappointed! the story is extremely boring, the acting (aside from christopher walken) is bad, and i couldn’t care less about the characters, aside from really wanting to see nora’s husband get thrashed. christopher walken’s role is such a throw-away, what a tease! | 0
imdb文件夹中的各个脚本的作用如下：
• imdb_reader.py：对于原始文本需要将它转化为神经网络可以使用的数字ID。imdb_reader.py脚本中定义了文本ID化的方法，该方法可以通过词典文件imdb.vocab将训练和测试数据中使用的文本单词映射为整数。映射之后的样本类似于以下的格式，这样神经网络就可以将转化后的文本信息作为特征值进行训练。
257 142 52 898 7 0 12899 1083 824 122 89527 134 6 65 47 48 904 89527 13 0 87 170 8 248 9 15 4 25 1365 4360 89527 702 89527 1 89527 240 3 28 89527 19 7 0 216 219 614 89527 0 84 89527 225 3 0 15 67 2356 89527 0 498 117 2 314 282 7 38 1097 89527 1 0 174 181 38 11 71 198 44 1 3110 89527 454 89527 34 37 89527 0 15 5912 80 2 9856 7748 89527 8 421 80 9 15 14 55 2218 12 4 45 6 58 25 89527 154 119 224 41 0 151 89527 871 89527 505 89527 501 89527 29 2 773 211 89527 54 307 90 0 893 89527 9 407 4 25 2 614 15 46 89527 89527 71 8 1356 35 89527 12 0 89527 89527 89 527 577 374 3 39091 22950 1 3771 48900 95 371 156 313 89527 37 154 296 4 25 2 217 169 3 2759 7 0 15 89527 0 714 580 11 2094 559 34 0 84 539 89527 1 0 330 355 3 0 15 15607 935 80 0 5369 3 0 622 89527 2 15 36 9 2291 2 7599 6968 2449 89527 1 454 37 256 2 211 113 0 480 218 1152 700 4 1684 1253 352 10 2449 89527 39 4 1819 129 1 316 462 29 0 12957 3 6 28 89527 13 0 457 8952 7 225 89527 8 2389 0 1514 89527 0
• nets.py：nets.py脚本中定义网络结构，本例中使用的CNN网络进行训练。
• local_train.py：本例的训练脚本，在训练结束后将使用paddle_serving_client.io.save_model函数来保存部署推理服务使用的模型文件和配置文件。相关代码如下所示：
#引入Paddle Serving保存模型相关的依赖
import paddle_serving_client.io as serving_io
for i in range(epochs):
exe.train_from_dataset(
program=fluid.default_main_program(), dataset=dataset, debug=False)
logger.info(“TRAIN --> pass: {}”.format(i))
if i == 64:
#在训练结束时使用Paddle Serving中的模型保存接口保存出Serving所需的模型和配置文件
serving_io.save_model(”{}_model”.format(model_name),
“{}_client_conf”.format(model_name),
{“words”: data}, {“prediction”: prediction},
fluid.default_main_program())
local_train.py脚本会调用其它脚本完成模型训练过程。用户可以执行如下命令使用local_train.py脚本体验训练并生成可用于部署的模型的过程。可用于部署的模型文件和配置文件将保存在imdb/imdb_lstm_model和imdb/imdb_lstm_client_conf文件夹中。
说明：此训练过程仅用于演示，并未训练达到最好的效果。
%cd imdb
!python local_train.py - 启动推理服务
如图4所示，Paddle Serving框架从大的方向上分为两种模式，并且为了适配工业界的实际需求衍生出了更加便携的部署方式。 如果用户需要一个纯模型预测服务，通过输入Tensor和输出Tensor与服务进行交互，可以使用RPC模式。通常这种模式用于验证模型的有效性。实际的场景往往具备较为复杂的前后处理，自然语言或者图像数据直接发送到服务端之后，需要一定的前处理转换成Tensor之后做预测
如图4所示，Paddle Serving框架支持两种推理服务方式，分别是RPC服务和Web服务，用户可以任选其一：
• RPC服务是CS架构，用户使用客户端来访问服务端获取推理结果，客户端和服务端之间的通信使用的是百度开源的一款RPC通信库来完成的。RPC具有高并发、低延时等特点，已经支持了包括百度在内上百万在线推理实例、上千个在线推理服务，稳定可靠，其整体性能要优于HTTP，但是只能适用于Linux操作系统，而且需要编写Client端的代码。如果用户的推理业务需要数据前后处理，例如训练图片的归一化，文本的ID化等等，这部分代码也需要包含在客户端中。
• Web服务是BS架构，用户可以使用浏览器或其它Web应用通过HTTP协议访问服务端。与RPC相比其优势在于可以适用于包括Linux操作系统在内的不同系统环境。此外还省去了编写客户端代码的工作量，仅需要使用服务端设定的URL就可以发送推理请求，获取推理结果。但是如果需要做预处理操作，则需要在服务端上做二次开发，由服务段使用Paddle Serving的内置预处理模块完成数据预处理操作。
图4 部署流程图
下面将分别介绍两种操作方式。
部署RPC推理服务
（1）启动服务端
请执行如下命令启动RPC推理服务。命令中参数–model 指定在之前保存的server端的模型和配置文件目录，–port指定推理服务的端口，当使用GPU版本部署GPU推理服务时可以使用–gpu_ids指定使用的GPU。命令执行完成后，即代表已成功部署了IMDB情感分析任务。
如果用户使用的是CPU环境，则可以使用如下命令。
cd Serving/python/examples/imdb
sh get_data.sh
python -m paddle_serving_server.serve --model imdb_lstm_model/ --port 9292
启动服务的命令还支持一些其它参数，如下所示：
use_xpu bool False 用昆仑芯片推理
一行命令启动RPC方式的推理服务的原理是什么呢？如下图所示，该图为RPC推理服务的流程图。Paddle Serving使用了百度开源的PRC通信库，该通信库使用可兼容多种语言的Protobuf格式的报文来封装请求或响应字段。在推理过程中，Client端把用户的输入数据，例如一条或多条电影评论，打包到Protobuf报文中并发送给服务端。服务端内部有多个算子，通过这些算子服务端在收到Protobuf报文后，可以从Protobuf报文中解析出飞桨推理库可以读取的输入数据格式，然后由推理库做推理，推理结果将被重新封装为Protobuf格式返回给客户端。显而易见，通过使用Paddle Serving，用户将不需要去了解飞桨的推理库的输入输出格式，整个从读取输入数据到返回推理结果都将由Paddle Serving服务端内部的算子完成。Paddle Serving通过paddle_serving_server_gpu.serve（paddle_serving_server.serve）这个服务模块将这些算子串联到一起，完成整个在线推理的服务流程。因此用户仅需要一条命令调用这个服务模块，并设定好推理使用的模型以及服务端口等信息，即可完成在线推理服务启动工作。
图2 Paddle Serving核心执行引擎流程图
（2）配置客户端
下面来看看如何编写RPC服务的客户端的脚本。整体上可以分为四步：
（1）声明Client类实例。
client = Client()
（2）加载配置，即加载client配置目录下的serving_client_conf.prototxt。
client.load_client_config(str)
（3）连接服务端。
client.connect(list[str])
（4）发送请求。发送请求主要使用client.predict接口，该接口有feed和fetch两个参数，其中fetch是用来指定远程预估后要获取的变量名，feed用来指定需要推理的数据。 feed支持如下三种取值形式：
• 单条数据输入，示例如下所示。其中"words"和"prediction"为上一步骤保存模型中的别名。示例如下所示：
client.predict(feed={‘words’:data}, fetch=[‘prediction’], batch=False)
• 支持利用词典数组实现批量预估。示例如下所示：
client.predict(feed=[{“words”:data}, {“words”:data}], batch=False)
• 支持使用numpy array定义输入数据。示例如下所示：
• import numpy as np
• client.predict(feed={‘words’:np.array(data)}, batch=False)
需要强调的是 predict函数当中的batch选项，表示feed字典中的tensor是否为一个batch client的具体的代码示例如下所示。值得注意的是对于像IMDB评论情感分析这类任务，输入数据是需要经过预处理的，对于RPC服务可以把预处理功能相关代码写到客户端代码中，由客户端完成相关操作。
from paddle_serving_client import Client
from paddle_serving_app.reader import IMDBDataset
import sys
client = Client()
client.load_client_config(sys.argv[1])
client.connect([“127.0.0.1:9292”])
you can define any english sentence or dataset here
This example reuses imdb reader in training, you
can define your own data preprocessing easily.
imdb_dataset = IMDBDataset()
imdb_dataset.load_resource(sys.argv[2])
for line in sys.stdin:
word_ids, label = imdb_dataset.get_words_and_label(line)
feed = {“words”: word_ids}
fetch = [“acc”, “cost”, “prediction”]
fetch_map = client.predict(feed=feed, fetch=fetch, batch=False)
print("{} {}".format(fetch_map[“prediction”][0], label[0]))
用户可以参考上述代码编写自己的客户脚本。上述代码已经保存在test_client.py脚本文件中，用户可以使用如下命令在终端-1中调用脚本启动客户端，体验在线推理服务。该命令将使用test_data/part-0文件中的前10个样本进行测试。
head test_data/part-0 | python test_client.py imdb_lstm_client_conf/serving_client_conf.prototxt imdb.vocab
预期结果
[0.5003979 0.49960202] 0
[0.50072354 0.49927655] 1
[0.50051194 0.49948803] 0
[0.50039905 0.4996009 ] 1
[0.50062656 0.49937338] 0
[0.5006046 0.49939534] 1
[0.50049865 0.49950135] 0
[0.5000268 0.49997315] 1
[0.50083774 0.49916226] 0
[0.5001417 0.49985838] 0
部署Pipeline服务
（1）启动服务端
RRC的服务非常简单易用，但是在具体的生产环境中会有如下的问题
• 难以处理多个模型以流水线的方式串联。例如推荐系统中有召回、排序等服务。这种情况RPC服务做多模型管理复杂且易错，需要更高级的模型串联管理框架。
• 难以精确管理每个模型的资源开销，精确调控每个模型的使用设备，进程数量，部署方式等等
• 难以同时提供rpc协议和rest接口，难以支持多语言和多操作系统。
为此Pipeline做了如下操作。
• 设计pipeline server可以通过DAG有向无环图的方式定义多模型串联。
• 模型服务以Op的形式呈现，通过config文件配置每个Op的资源使用。
• 通过grpc-gateway，利用自动生成的Go程序转发HTTP请求，实现同时暴露rest和rpc服务的目的。
Pipeline设计文档参见 Paddle Serving Pipeline设计文档
使用方式如下所示
from paddle_serving_server.web_service import WebService, Op
import logging
import numpy as np
import sys
class UciOp(Op):
def init_op(self):
self.separator = “,”
def preprocess(self, input_dicts, data_id, log_id):
(_, input_dict), = input_dicts.items()
_LOGGER.error("UciOp::preprocess >>> log_id:{}, input:{}".format(
log_id, input_dict))
x_value = input_dict["x"]
proc_dict = {}
if isinstance(x_value, str):
input_dict["x"] = np.array(
[float(x.strip())
for x in x_value.split(self.separator)]).reshape(1, 13)
return input_dict, False, None, ""
def postprocess(self, input_dicts, fetch_dict, log_id):
fetch_dict["price"] = str(fetch_dict["price"][0][0])
return fetch_dict, None, ""
class UciService(WebService):
def get_pipeline_response(self, read_op):
uci_op = UciOp(name=“uci”, input_ops=[read_op])
return uci_op
uci_service = UciService(name=“uci”)
uci_service.prepare_pipeline_config(“config.yml”)
uci_service.run_service()
在上述python代码中给出了房价预测的Pipeline版本，接下来是yaml配置文件
#worker_num, 最大并发数。当build_dag_each_worker=True时, 框架会创建worker_num个进程，每个进程内构建grpcSever和DAG
##当build_dag_each_worker=False时，框架会设置主线程grpc线程池的max_workers=worker_num
worker_num: 1
#http端口, rpc_port和http_port不允许同时为空。当rpc_port可用且http_port为空时，不自动生成http_port
rpc_port: 9998
http_port: 18082
dag:
#op资源类型, True, 为线程模型；False，为进程模型
is_thread_op: False
op:
uci:
#当op配置没有server_endpoints时，从local_service_conf读取本地服务配置
local_service_conf:
#并发数，is_thread_op=True时，为线程并发；否则为进程并发
concurrency: 2
#uci模型路径
model_config: uci_housing_model
#计算硬件ID，当devices为""或不写时为CPU预测；当devices为"0", "0,1,2"时为GPU预测，表示使用的GPU卡
devices: "" # "0,1"
#client类型，包括brpc, grpc和local_predictor.local_predictor不启动Serving服务，进程内预测
client_type: local_predictor
#Fetch结果列表，以client_config中fetch_var的alias_name为准
fetch_list: ["price"]
在 Serving工程的 python/examples/pipeline/simple_web_service下，
python web_service.py &
客户端访问
curl -X POST -k http://localhost:18082/uci/prediction -d ‘{“key”: [“x”], “value”: [“0.0137, -0.1136, 0.2553, -0.0692, 0.0582, -0.0727, -0.1583, -0.0584, 0.6283, 0.4919, 0.1856, 0.0795, -0.0332”]}’
可以看到通过18082端口暴露了http服务。 预期结果
curl -X POST -k http://localhost:18082/uci/prediction -d ‘{“key”: [“x”], “value”: [“0.0137, -0.1136, 0.2553, -0.0692, 0.0582, -0.0727, -0.1583, -0.0584, 0.6283, 0.4919, 0.1856, 0.0795, -0.0332”]}’
与此同时，RPC服务的端口在9998端口被暴露 客户端访问
python web_rpc_client.py
预期结果
{“err_no”:0,“err_msg”:"",“key”:[“price”],“value”:[“18.901152”]}
其它应用实例
使用Paddle Serving部署图像检测服务
本示例将使用使用图像领域中经典的COCO数据集，为方便用户使用，该数据集已经封装在了paddle_serving_app模块当中。那么什么是paddle_serving_app模块呢？在常用的推理任务中，很多模型的输入数据是需要经过预处理的，例如文本需要切词、转换为词向量，图像需要归一化，即统一大小和分辨率等，使图片形成统一的规格。如果用户没有掌握一定的领域知识，很难完成相关的预处理工作，因此Paddle Serving为用户提供了内置预处理模块paddle_serving_app，paddle_serving_app包含了各类经典任务的预处理模块，并且通过对灵活性和易用性的折中设计使其在简便易用的同时，保持了较好的性能。该预处理模块可以广泛用于NLP、CV等场景中。
内置预处理模块可以通过使用如下命令安装：
- 启动服务端
请执行如下命令启动服务端。
cd python/examples/faster_rcnn
wget --no-check-certificate https://paddle-serving.bj.bcebos/pddet_demo/faster_rcnn_model.tar.gz
wget --no-check-certificate https://paddle-serving.bj.bcebos/pddet_demo/infer_cfg.yml
tar xf faster_rcnn_model.tar.gz
mv faster_rcnn_model/pddet* .
GLOG_v=2 python -m paddle_serving_server_gpu.serve --model pddet_serving_model --port 9494 --gpu_ids 0 & - 启动客户端
在终端中启动
python test_client.py $IMAGE_NAME
为大家准备了beach.jpg和skateboard.jpg。他们会生成结果文件，一张带后处理框图的图片和json格式的文件在output文件夹下。
import sys
import numpy as np
from paddle_serving_client import Client
from paddle_serving_app.reader import *
图像预处理
preprocess = Sequential([
File2Image(), BGR2RGB(), Div(255.0),
Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225], False),
Resize(640, 640), Transpose((2, 0, 1))
])
后处理初始化
postprocess = RCNNPostprocess(“label_list.txt”, “output”)
client = Client()
客户端加载配置
client.load_client_config(
“pddet_client_conf/serving_client_conf.prototxt”)
client.connect([‘127.0.0.1:9393’])
im = preprocess(sys.argv[1])
客户端在线预测
fetch_map = client.predict(
feed={
“image”: im,
“im_info”: np.array(list(im.shape[1:]) + [1.0]),
“im_shape”: np.array(list(im.shape[1:]) + [1.0])
},
fetch=[“multiclass_nms”], batch=False) # im是三维的（C，H，W），因此batch=False（补足最高维 N，C，H，W）
fetch_map[“image”] = sys.argv[1]
图像后处理
postprocess(fetch_map)
可以看到在预处理当中做了以下事情，支持PyTorch的Image处理方式。
• Sequential：图像前处理的序列化操作
• File2Image：文件转opencv格式图片的操作，输出是numpy array
• BGR2RGB：图像编码的通道顺序转换，从原来的BGR换成RGB
• Div：图像的色彩信息从0-255的整型数转换为0-1之间的浮点数
• Normalize：将每个颜色通道做归一化处理，第一个列表参数是每个通道的中位数，第二个列表参数是每个通道的标准差。计算公式为：output[channel] = (input[channel] - mean[channel]) / std[channel]
• Resize： 调整numpy array图片的大小
• Transpose：转置矩阵，原本的图片在numpy的维度是[长，宽，RGB]，经过Transpose之后是[RGB，长，宽]
可以看到客户端在读入模型配置之后，先后做了读取文件，调整大小的操作。 所有的序列操作作为预处理callable object preprocess
接下来调用客户端的预测函数 client.predict(feed, fetch)。这个函数的就是同刚才启动的Paddle Serving Server进行交互。
在feed字典中写入模型需要的输入，在fetch列表中填入需要的输出，具体的定义在pddet_client_conf/serving_client_conf.prototxt中给出
feed_var {
name: “image”
alias_name: “image”
is_lod_tensor: false
feed_type: 1
shape: 3
shape: 640
shape: 640
}
feed_var {
name: “im_shape”
alias_name: “im_shape”
is_lod_tensor: false
feed_type: 1
shape: 3
}
feed_var {
name: “im_info”
alias_name: “im_info”
is_lod_tensor: false
feed_type: 1
shape: 3
}
fetch_var {
name: “multiclass_nms_0.tmp_0”
alias_name: “multiclass_nms”
is_lod_tensor: true
fetch_type: 1
shape: 6
}
课余看到feed_var的输入名为 image、im_shape、im_info， fetch_var的输入名为multiclass_nms_0.tmp_0。
输出结果是一个size为N*6的矩阵，给出了每个框图左上角和右下角坐标点以及分类编号和对应这个编号的分数。后处理会结合给出的label_list.txt，在原图上绘制框图以及识别到的类别名。具体参见下图
3. 结果分析
python test_client.py beach.jpg
python test_client.py skateboard.jpg
可以看到图像检测算法在图片上标注了识别到的物体及其分类名和分数
使用Paddle Serving部署OCR Pipeline在线服务
上述例子的目的是带着大家体验Paddle Serving在CV模型上的易用性，服务端是单模型RPC服务。接下来介绍一个pipeline方式的CV模型OCR。
-
启动服务端
请执行如下命令启动服务端。
python -m paddle_serving_app.package --get_model ocr_rec
tar -xzvf ocr_rec.tar.gz
python -m paddle_serving_app.package --get_model ocr_det
python web_service.py &>log.txt & -
启动客户端
在终端-1中使用如下命令启动客户端。这里直接把图片的读取放在python脚本里。
python pipeline_http_client.py
服务端是这样串联OCR的检测
class DetOp(Op):
def init_op(self): # 这是自定义的函数，可以把只执行一次（例如初始化）的操作放在这里
self.det_preprocess = Sequential([
ResizeByFactor(32, 960), Div(255),
Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]), Transpose(
(2, 0, 1))
]) # 这部分与FasterRCNN的例子相同，
self.filter_func = FilterBoxes(10, 10)
self.post_func = DBPostProcess({
“thresh”: 0.3,
“box_thresh”: 0.5,
“max_candidates”: 1000,
“unclip_ratio”: 1.5,
“min_size”: 3
})def preprocess(self, input_dicts, data_id, log_id):
(_, input_dict), = input_dicts.items()
data = base64.b64decode(input_dict[“image”].encode(‘utf8’)) #第一个Op读取字典的“image”，客户端也需要给出”image“，参见客户端代码
data = np.fromstring(data, np.uint8)
# Note: class variables(self.var) can only be used in process op mode
self.im = cv2.imdecode(data, cv2.IMREAD_COLOR)
self.ori_h, self.ori_w, _ = self.im.shape
det_img = self.det_preprocess(self.im)
_, self.new_h, self.new_w = det_img.shape
return {“image”: det_img[np.newaxis, :].copy()}, False, None, “” #分别为 feed字典，是否为batch的数据，后面可忽略，具体参见pipeline设计文档def postprocess(self, input_dicts, fetch_dict, log_id):
det_out = fetch_dict[“concat_1.tmp_0”]
ratio_list = [
float(self.new_h) / self.ori_h, float(self.new_w) / self.ori_w
]
dt_boxes_list = self.post_func(det_out, [ratio_list])
dt_boxes = self.filter_func(dt_boxes_list[0], [self.ori_h, self.ori_w])
out_dict = {“dt_boxes”: dt_boxes, “image”: self.im} #组装response字典，内含 dt_boxes和image，会被下个Op前处理使用
print(“out dict”, out_dict)
return out_dict, None, “”
class RecOp(Op):
def init_op(self):
self.ocr_reader = OCRReader()
self.get_rotate_crop_image = GetRotateCropImage()
self.sorted_boxes = SortedBoxes()
def preprocess(self, input_dicts, data_id, log_id):
(_, input_dict), = input_dicts.items()
im = input_dict["image"] # 取image，源自DetOp
dt_boxes = input_dict["dt_boxes"] #取dt_boxes，源自DetOp
dt_boxes = self.sorted_boxes(dt_boxes)
feed_list = []
img_list = []
max_wh_ratio = 0
for i, dtbox in enumerate(dt_boxes):
boximg = self.get_rotate_crop_image(im, dt_boxes[i])
img_list.append(boximg)
h, w = boximg.shape[0:2]
wh_ratio = w * 1.0 / h
max_wh_ratio = max(max_wh_ratio, wh_ratio)
_, w, h = self.ocr_reader.resize_norm_img(img_list[0],
max_wh_ratio).shape
imgs = np.zeros((len(img_list), 3, w, h)).astype('float32')
for id, img in enumerate(img_list):
norm_img = self.ocr_reader.resize_norm_img(img, max_wh_ratio)
imgs[id] = norm_img
feed = {"image": imgs.copy()}
return feed, False, None, ""
def postprocess(self, input_dicts, fetch_dict, log_id):
rec_res = self.ocr_reader.postprocess(fetch_dict, with_score=True)
res_lst = []
for res in rec_res:
res_lst.append(res[0])
res = {"res": str(res_lst)}
return res, None, ""
class OcrService(WebService):
def get_pipeline_response(self, read_op):
det_op = DetOp(name=“det”, input_ops=[read_op])
rec_op = RecOp(name=“rec”, input_ops=[det_op])
return rec_op
uci_service = OcrService(name=“ocr”)
uci_service.prepare_pipeline_config(“config.yml”)
uci_service.run_service()
然后在客户端中，
from paddle_serving_server_gpu.pipeline import PipelineClient
import numpy as np
import requests
import json
import cv2
import base64
import os
client = PipelineClient()
client.connect([‘127.0.0.1:18090’])
def cv2_to_base64(image):
return base64.b64encode(image).decode(‘utf8’) #用base64读取图片
test_img_dir = “imgs/”
for img_file in os.listdir(test_img_dir):
with open(os.path.join(test_img_dir, img_file), ‘rb’) as file:
image_data = file.read()
image = cv2_to_base64(image_data)
for i in range(1):
ret = client.predict(feed_dict={“image”: image}, fetch=[“res”]) # 给出image，被DetOp使用
print(ret)
Pipeline 客户端和 RPC客户端的异同
• 相同点： 都需要初始化一个Client/PipelineClient的对象，然后连接一个或者多个endpoint，通过数据读取组装feed dict，调用predict函数。
• 不同点：RPC客户端的feed字典严格按照 client端配置的prototxt文件定义的feed和fetch。RPC在Pipeline中以一个Op的形式出现，在Op的preprocess返回部分需要传入feed和fetch，在底层调用RPC服务。Pipeline client的feed字典只需要和Server端的第一个Op的输入和最后一个Op的输出相匹配就可以，具体的key值可以自行定义。例如OCR的例子当中，发送的feed字典的key为image，与此同时，在Pipeline Server端的第一个DetOp的preprocess函数，就可以看到对feed字典的解包，中间用到了image这个key；相似的，在RecOp当中，最后的返回值是res，也和pipeline client predict函数的fetch参数相吻合。
通过这个样例，可以感受到Pipeline的以下优势
• 多模型串联易用性，只需要定义op的串联关系，和op之间feed dict匹配，就可以用config yaml管理各个模型的资源使用和端口管理。
• 多语言多平台支持，同时暴露grpc和http服务，满足市面上想象得到的所有平台。
• 前后处理的易用性，与其他框架相比，pipeline在前后处理部分全部用python封装，用户可以直接从套件库或训练代码直接移植前后处理，不会出现在跨语言时重新实现一遍前后处理的难题。
更多推荐
服务化部署框架Paddle Serving
发布评论