1. 模型的推理、落地及服务化
模型推理即深度神经网络的前向计算推理，算法工程师历经千辛万苦终于训练出来一个非常好的模型，但是这个模型真正落地应用还是有非常多的工作要做的，这就是我们常说的工程化落地部署。落地部署需要考虑的事情非常多，需要做模型文件的提取移植、模型压缩、模型加速等等。
模型落地部署的方式也有多种：
- 封装成SDK集成进应用或服务中；
- 做成端侧模型，在端侧算力下进行高效推理；
- 封装成一个web模型服务，对外暴露API接口，供外部调用。
这里主要讨论服务化，如果将模型直接放进应用或服务中，在模型数量不多、业务规模不大的时候能够从容对付，但是伴随着模型数量的增多和业务规模的扩大，会造成模型推理与业务逻辑处理的耦合，增加模型上线的成本，也会引起争抢资源的情况。模型服务化能够将深度学习模型推理过程封装成服务，解耦业务处理逻辑和模型推理，即模型服务化。因此，模型服务化是近几年伴随微服务概念被炒得越来越热门的话题，例如，谷歌在2016年就针对TensorFlow发布了对应的服务化框架TensorFlow Serving，把TensorFlow训练出来的模型封装成web服务，接收client端网络请求，进行前向推理计算并返回推理结果。
2. 模型服务化框架
下面主要总结了当前业界优秀开源的模型服务化框架，以及他们的优劣势等，如下表所示：
| 服务框架 | 支持深度学习框架 | 开发公司 | 开源地址 | 开源时间 | 支持web调用API接口的类型 | 优势 | 劣势 |
|---|---|---|---|---|---|---|---|
| TensorFlow Serving | 1. 原生支持 2. PyTorch-->onnx-->saved_model |
谷歌 | github.com/tensorflow/… | 2016 | gRPC和RESTful | 1. 支持docker部署，同时支持CPU和GPU。 2. 支持多种API通信方式，两种接口类型。 3. 挂载简单，支持热更新，框架成熟，业界经验沉淀多。 |
1. 支持PyTorch不方便，较为繁琐。 2. 无法支持OpenVino和TensorRT加速优化模型。 |
| OpenVino Model Server | 支持多数框架，只要训练出来的模型能转为openvino的IR格式。 | 英特尔 | github.com/openvinotoo… | 2019 | gRPC和RESTful | 1. 完美适配OpenVino的CPU加速方案，在CPU上能进一步提升性能。 2. 配置灵活，支持版本管理和模型热更新。 3. k8s友好，低代码化。 |
不支持NVIDIA GPU硬件部署的加速。 |
| Torch Serve | 原生支持PyTorch框架。 | AWS和FaceBook | github.com/pytorch/ser… | 2020 | gRPC和RESTful | 1. 部署简单方便。 2. 高性能、轻量化。 |
1. 整个工具还在频繁更新完善过程，改动量大。 2. 只支持PyTorch框架。 |
| Triton | 支持多种框架，TensorFlow、TensorRT、PyTorch、ONNX甚至是自定义框架。 | 英伟达 | github.com/triton-infe… | 2018 | gRPC和RESTful | 1. 推理性能高，支持TensorRT加速模型。 2. 支持框架丰富，适配性强。 3. 支持动态batch推理和单模型多实例部署。 |
不支持部署OpenVino的CPU加速模型。 |
| BentoML | 1. TensorFlow 2. PyTorch 3. ONNX |
BentoML.ai | github.com/bentoml/Ben… | 2019 | RESTful | 1. 支持框架丰富，灵活方便。 2. 容器化部署友好。 3. 支持自适应batch推理。 |
框架小众，处于发展期，参考资料少。 |
| Kubeflow | 1. TensorFlow 2. PyTorch |
谷歌 | github.com/kubeflow/ku… | 2018 | gRPC和RESTful | 1. 内部支持tf-serving和triton框架。 2. 快速成长的框架，专为容器化部署打造。 |
工业界经验沉淀少。 |