关于pytorch:TorchServe-详解5-步将模型部署到生产环境

4次阅读

共计 2596 个字符，预计需要花费 7 分钟才能阅读完成。

内容导读
TorchServe 自 2020 年 4 月推出至今，经验了 2 年多的倒退，变得愈发成熟和稳固，本文将对 TorchServe 进行全面介绍。

TorchServe 是 PyTorch 中将模型部署到生产环境的首选解决方案。它是一个性能良好且可扩大的工具，用 HTTP 或 HTTPS API 封装模型。
TorchServe 的前端是用 Java 实现的，能够解决多种工作，包含为部署模型调配 workers、负责客户端和服务器之间通信等。其 Python 后端次要负责解决 inference service。

![https://tva1.sinaimg.cn/large…]()
图一：TorchServe performance Tuning 流程总览
此外，它还反对 AB 测试、dynamic batching、logging 和 metrics 的多种 model serving 及 versioning，4 个公开 API 包含：

Inference API：监听 8080 端口，默认状况下可通过 localhost 拜访，能够在 TorchServe configuration 中进行配置，并反对从模型中获取 predictions。
Explanation API：在 hood 下应用 Captum 提供正在部署的模型的阐明，并监听 8080 端口。
Management API：容许注册或勾销注册并形容模型。它还容许用户减少或缩小部署模型的 workers 的数量。
Metrics API：在默认状况下监听 8082 端口，使用户能够监测正在部署的模型。

TorchServe 通过反对 batch inference 及部署模型的多个 workers，使得用户得以扩大模型部署并解决峰值流量。这种扩大可通过 Management API 及 configuration file 中的设置来实现。此外，Metrics API 能够通过默认及自定义 metrics 来监测模型部署。
其余高级设置，如接管申请的队列长度、a batch of inputs 的最大期待时长以及其余属性，都能够通过 config file（启动时能够传递到 TorchServe）进行配置。
用 TorchServe 部署模型的步骤包含：
1、装置 TorchServe、model archiver 及其它依赖
2、抉择一个适合的默认 handler（如图像分类等）或创立一个自定义 handler
3、应用 Torcharchive 将 model artifacts 和 handler 打包成一个 .mar 文件，并将其放入 model store
4、开始部署模型
5、运行推理

TorchServe 我的项目地址：
https://github.com/pytorch/se…

TorchServe 后端应用一个 handler 来加载模型、预处理接管到的数据、运行推理和对 response 进行 post process。TorchServe 中的 handler 是一个 Python script，所有模型初始化、预处理、推理和 post process 逻辑都蕴含在其中。
TorchServe 还提供了一个开箱即用的 handler，可用于图像分类、宰割、指标检测和文本分类等应用程序。此外，它还反对自定义 handler，以防默认 handler 不反对当下的 case。
自定义 handler 提供了很大的灵活性，这可能使 TorchServe 成为一个多框架服务工具。自定义的 handler 容许以自定义逻辑来初始化一个模型，也能让这个模型从其余框架（如 ONNX）加载模型。
TorchServe 处理程序由四个次要函数组成，functions、initialize、inference 和 preprocess，每个函数返回一个列表。

上面的代码片段是自定义 handler 的示例。自定义 handler 继承了 TorchServe 中的 BaseHandler，能够笼罩任何主函数。该示例演示了如何用 handler 加载 Detectron2 模型，解决 figure detection 问题。该模型曾经被导出至 Torchscript，并应用 mod.half() 运行 FP16 推理。
![https://tva1.sinaimg.cn/large…]()

将模型部署到生产环境中，须要重点监测其能力体现。TorchServe 定期收集零碎级 metrics，并容许增加自定义 metrics。
零碎级 metrics 包含 CPU 利用率、主机上可用及已用的磁盘空间和内存，以及不同响应代码的申请数量（例如 200-300、400-500 和 500 以上）。自定义 metrics 能够增加到 Custom Metrics API。
Custom Metrics API：
https://github.com/pytorch/se…

TorchServe 将这两组 metrics 记录到不同的 log file 中。默认状况下，metrics 收集在:
零碎 metrics：log directory/ts metrics. log
自定义 metrics：log directory/model _ metrics. log

TorchServe 的 Metrics API，默认状况下监听端口 8082，并容许用户查问和监控收集到的 metrics。默认的 metrics endpoint 返回 Prometheus formatted metrics。能够用 curl 申请查问 metrics，或者将 Prometheus Server 指向 endpoint，并将 Grafana 用于 Dashboard。
用 curl 申请查问 metrics：
curl http://127.0.0.1:8082/metrics

用 mtail 将 logged metrics 导出到 Prometheus 的示例：https://github.com/google/mtail
通过在 Bashboard 中跟踪这些 metrics，能够监督在离线 Benchmark 运行期间，偶然呈现或难以发现的 performance regressions。

以上就是对于 TorchServe 的全副介绍。在下一节中，咱们将借助一个具体案例，解说影响部署模型到生产环境中的具体因素，以及如何用 TorchServe 对 Animated Drawings APP 进行调优。