PaddleInference和PaddleServing

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

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

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

2. 启动推理服务
   如图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的内置预处理模块完成数据预处理操作。

也可以，直接访问，但是需要内置的服务端完成预处理工作