服务化部署框架Paddle Serving
服務化部署框架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.com/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 !wget https://paddle-serving.bj.bcebos.com/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:LDL?IBRARYP?ATH!wgethttps://paddle?serving.bj.bcebos.com/aistudio/cuda?9.0?aistudio?env.tar.gz!tarxfcuda?9.0?aistudio?env.tar.gz!exportLDL?IBRARYP?ATH=/home/aistudio/env/cuda?9.0/lib64:LD_LIBRARY_PATH
–2021-01-30 12:43:57-- https://paddle-serving.bj.bcebos.com/aistudio/cuda-9.0-aistudio-env.tar.gz
Resolving paddle-serving.bj.bcebos.com (paddle-serving.bj.bcebos.com)… 182.61.200.195, 182.61.200.229, 2409:8c00:6c21:10ad:0:ff:b00e:67d
Connecting to paddle-serving.bj.bcebos.com (paddle-serving.bj.bcebos.com)|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.com/paddlepaddle/serving:0.4.1-devel
? 基于Dockerfile構建鏡像。建立新目錄，復制Dockerfile內容到該目錄下Dockerfile文件。
docker build -t hub.baidubce.com/paddlepaddle/serving:0.4.1-devel .
2. 創建容器并進入
docker run -p 9292:9292 --name test -dit hub.baidubce.com/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.cn/simple
啟動 GPU Docker
GPU版本與CPU版本基本一致，只有部分接口命名的差別（GPU版本需要在GPU機器上安裝nvidia-docker）。
- 獲取鏡像
可以通過兩種方式獲取鏡像。
? 直接拉取鏡像。
nvidia-docker pull hub.baidubce.com/paddlepaddle/serving:TAG?基于Dockerfile構建鏡像。建立新目錄，復制Dockerfile.gpu內容到該目錄下Dockerfile文件。nvidia?dockerbuild?thub.baidubce.com/paddlepaddle/serving:{TAG} ? 基于Dockerfile構建鏡像。建立新目錄，復制Dockerfile.gpu內容到該目錄下Dockerfile文件。 nvidia-docker build -t hub.baidubce.com/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.com/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.cn/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.com/whl/paddle_serving_client-0.0.0-cp37-none-any.whl
pip install https://paddle-serving.bj.bcebos.com/whl/paddle_serving_app-0.0.0-py3-none-any.whl
pip install https://paddle-serving.bj.bcebos.com/whl/paddle_serving_server_gpu-0.0.0.post9-py3-none-any.whl
pip install -r python/requirements.txt
git clone https://hub.fastgit.org/PaddlePaddle/Serving -b v0.4.1
!pip install https://paddle-serving.bj.bcebos.com/whl/paddle_serving_client-0.0.0-cp37-none-any.whl
!pip install https://paddle-serving.bj.bcebos.com/whl/paddle_serving_app-0.0.0-py3-none-any.whl
!pip install https://paddle-serving.bj.bcebos.com/whl/paddle_serving_server_gpu-0.0.0.post9-py3-none-any.whl
!pip install -r python/requirements.txt
!git clone https://hub.fastgit.org/PaddlePaddle/Serving -b v0.4.1
Looking in indexes: https://mirror.baidu.com/pypi/simple/
Collecting paddle-serving-client0.0.0 from https://paddle-serving.bj.bcebos.com/whl/paddle_serving_client-0.0.0-cp37-none-any.whl
Downloading https://paddle-serving.bj.bcebos.com/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.com/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.com/pypi/simple/
Collecting paddle-serving-app0.0.0 from https://paddle-serving.bj.bcebos.com/whl/paddle_serving_app-0.0.0-py3-none-any.whl
Downloading https://paddle-serving.bj.bcebos.com/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.com/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.com/pypi/simple/
Collecting paddle-serving-server-gpu0.0.0.post9 from https://paddle-serving.bj.bcebos.com/whl/paddle_serving_server_gpu-0.0.0.post9-py3-none-any.whl
Downloading https://paddle-serving.bj.bcebos.com/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.com/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.cn/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.com/pddet_demo/faster_rcnn_model.tar.gz
wget --no-check-certificate https://paddle-serving.bj.bcebos.com/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，源自DetOpdt_boxes = input_dict["dt_boxes"] #取dt_boxes，源自DetOpdt_boxes = self.sorted_boxes(dt_boxes)feed_list = []img_list = []max_wh_ratio = 0for 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 / hmax_wh_ratio = max(max_wh_ratio, wh_ratio)_, w, h = self.ocr_reader.resize_norm_img(img_list[0],max_wh_ratio).shapeimgs = 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_imgfeed = {"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的全部內容，希望文章能夠幫你解決所遇到的問題。
