ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

Paddle Inference和Paddle Serving

2021-10-10 18:02:41  阅读:276  来源: 互联网

标签:Serving Inference 部署 模型 Paddle RPC 推理 服务端


在这里插入图片描述

部署方式

服务器端高性能部署:将模型部署在服务器上,利用服务器的高性能帮助用户处理推理业务。
模型服务化部署:将模型以线上服务的形式部署在服务器或者云端,用户通过客户端请求发送需要推理的输入内容,服务器或者云通过响应报文将推理结果返回给用户。
移动端部署:将模型部署在移动端上,例如手机或者物联网的嵌入式端。
Web端部署:将模型部署在网页上,用户通过网页完成推理业务。

第一种方式

这种方式,是整体打包,从本地移到服务器的部署,模型没有服务化,相对调用模型的函数,是本地调用的,这种方式效率快,不存在二次调度验收,但是模型不可复用,会造成一定的空间浪费。
基于Paddle Inference的单机推理部署,即在一台机器进行推理部署。相比Paddle Serving在多机多卡下进行推理部署,单机推理部署不产生多机通信与调度的时间成本,能够最大程度地利用机器的Paddle Inference算力来提高推理部署的性能。对于拥有高算力机器,已有线上业务系统服务,期望加入模型推理作为一个子模块,且对性能要求较高的用户,采用单机推理部署能够充分利用计算资源,加速部署过程。

第二种方式

这种方式,是把模型服务化,可以给其他很多任务调用,服务化一个模型即可,无需没个应用都部署一套,缺点是存在接口访问调度时间,外部应用访问的时候相当于多经过了一个接口中专。

  1. 启动推理服务
    如图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的内置预处理模块完成数据预处理操作。
在这里插入图片描述
也可以,直接访问,但是需要内置的服务端完成预处理工作

标签:Serving,Inference,部署,模型,Paddle,RPC,推理,服务端
来源: https://blog.csdn.net/qq_15821487/article/details/120688806

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有