Paddle Inference和Paddle Serving
作者:互联网
部署方式
服务器端高性能部署:将模型部署在服务器上,利用服务器的高性能帮助用户处理推理业务。
模型服务化部署:将模型以线上服务的形式部署在服务器或者云端,用户通过客户端请求发送需要推理的输入内容,服务器或者云通过响应报文将推理结果返回给用户。
移动端部署:将模型部署在移动端上,例如手机或者物联网的嵌入式端。
Web端部署:将模型部署在网页上,用户通过网页完成推理业务。
第一种方式
这种方式,是整体打包,从本地移到服务器的部署,模型没有服务化,相对调用模型的函数,是本地调用的,这种方式效率快,不存在二次调度验收,但是模型不可复用,会造成一定的空间浪费。
基于Paddle Inference的单机推理部署,即在一台机器进行推理部署。相比Paddle Serving在多机多卡下进行推理部署,单机推理部署不产生多机通信与调度的时间成本,能够最大程度地利用机器的Paddle Inference算力来提高推理部署的性能。对于拥有高算力机器,已有线上业务系统服务,期望加入模型推理作为一个子模块,且对性能要求较高的用户,采用单机推理部署能够充分利用计算资源,加速部署过程。
第二种方式
这种方式,是把模型服务化,可以给其他很多任务调用,服务化一个模型即可,无需没个应用都部署一套,缺点是存在接口访问调度时间,外部应用访问的时候相当于多经过了一个接口中专。
- 启动推理服务
如图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