概述

根据要求部署完成的任务，经过pipeline训练完成后，即可通过推理服务的方式对外提供服务。

推理服务从底层到上层所处的阶段

推理服务从底层到上层，包含服务网格，serverless，pipeline，http框架，模型计算：

• 服务网格阶段：提供代理流量的中转和管控，如分流，镜像，限流，黑白名单之类的。
• serverless阶段：提供智能化运维，如服务的激活，伸缩容，版本管理，蓝绿发布。
• pipeline阶段：提供各数据处理/推理之间的请求流转，推理的前后置处理逻辑等。
• http/grpc框架：提供客户端的请求处理，准备推理样本，推理后作出响应。
• 模型计算：提供模型在cpu/gpu上对输入样本做前向计算。

网关入口适配

采用istio的gateway的服务网格网关方案，暂时不考虑k8s ingress网关。
平台很多功能是通过外部镜像镜像实现的：

• jupyter
• vscode
• nni
• k8s-dashboard
• kfp
• 云原生服务用户自己定义的镜像
• 推理服务外部各框架镜像
• kfserving镜像
  这些服务在网关入口处基本通过url prefix或者host进行的区分代理，然后内部再加上泛化域名的能力，这样就能部署后直接访问了。

分流+流量复制

分流表示将一批流量按照一定规则分发到多个服务上去，每一个请求只会进入一个服务端，流量镜像则表示将原有的流量原封不动的复制一份到另一个服务。这两种功能在实际生产中都非常有用，在istio中可以很方便的实现流量的分发和复制。
平台规定一个模型使用一个唯一的pod，不会在一个pod中进行多个模型的推理服务，所以在服务网格中流量的复制和分流就更加简单。

推理框架

不同的训练框架，基本都有对应的推理框架：
tf/torch/onnx/tensorrt/lightgbm/paddle/sklearn/xgboost等模型提供推理服务，用户填写模型名称和版本、模型地址，会自动生成所有的配置文件，提供api的demo，自动提供域名和ip的访问。

各类型的推理框架或多或少可以代理其他训练框架的模型进行推理服务。例如tfserving也可以为onnx模型提供推理服务，所以这些框架和模型并不是唯一绑定关系。

tfserving

tfserving主要是tf模型推理服务，虽然同时也可以为其他模型提供推理服务的，比如上面说的onnx模型也是可以用tfserving提供推理服务的。
tfserving推理主要需要提供models.config、monitoring.config、platform.config等配置文件。推理服务提供了Model status API、Model Metadata API、Classify and Regress API、Predict API等类型的接口。
可以使用Model Metadata API作为模型的健康检查接口。
monitoring.config中配置的metric可以用于prometheus监控。

torchserver

torch保存模型结构和参数完成信息后，需要先使用torch-model-archiver将模型压缩为可直接推理的包，主要是将http接口封装进去。