Triton Inference Server

定位

在接触了一段时间的 Triton 之后，我认为它的定位在于模型服务，即它的主要职责和服务紧密相关，服务中常见的需求它需要做处理。比如 Batching，Sequence，Pipeline 等，再比如模型仓库的管理，模型后端引擎的管理等，还有性能测试工具等。至于模型部署优化，我觉得 Triton 和它的关系是不密切的。我所谓的 “模型部署优化” 指的是将训练好的模型放到目标设备上执行推理任务，这应该是模型后端引擎需要处理的事情，而非一个推理服务器要处理的事情。

功能总结

下面总结了 Triton 的一些功能，我希望后续的文章中一点一点展开。我是一个 Triton 的初学者，因为需要开发一个 Triton Backend，所以不仅需要熟练使用 Triton 的每一项功能，还必须要对 Triton 的内在原理有足够的了解。

(TL;DR

• 支持多种深度学习框架，Tensorflow，Pytorch，可以通过实现后端 API 来进行扩展。
• 模型并行执行，多个模型在同一个或多个 GPU 上执行。可配置 Instance Groups，设置在不同的设备上运行多少个实例。
• 支持 HTTP/gRPC 协议。提供 C API，可以将 Triton 和应用连接起来。
• Scheduling And Batching，可以设置 dynamic batching，preferred batch sizes，排队等待时间，是否保持请求顺序返回，排队优先级，排队策略等。
• Metrics，GPU 使用率，服务器吞吐量，服务器延时。
• 模型仓库，支持本地、云存储。
• 模型配置，设置后端、最大 batch size，输入输出，支持自动生成模型配置。
• Rate Limiter，控制请求调度到不同模型实例的频率。
• Model Warmup。避免头几次请求因为 lazy 初始化导致的延迟。
• 模型热更新，检测模型仓库。
• Repository Agent，扩展模型在加载和卸载时候的操作，比如加密、解密、转换、检测 checksum。
• Stateful Models，多个请求可以路由到同一个模型实例，从而模型的状态可以正确被更新。
• 模型 pipelines。多个模型一起完成推理任务。
• Performance Analyzer，性能分析器。
• Model Analyzer，使用 Performance Analyzer 分析测量一个模型的 GPU 内存和计算使用率。
• 共享内存，甚至显存！客户端和 Triton 之间可以共享内存，从而提高性能。

总结

最好的学习办法应该是项目驱动去走一遍模型部署流程，这样就算是熟悉了 Triton。不过，这样的缺点也比较明显，覆盖面不够，广度达不到实现一个 Backend 需要的认知；深度同样也不够，对 Triton 的线程内存管理缺少认识，亦无法清晰认识 Backend API 在什么时候干了什么。

因此，后续的几篇文章会使用一些 toy model 去做部署，尝试 Triton 的各个特性。在尝试了这些特性之后，顺带看看源代码是如何实现的。可是，这样搞下来之后，没有完善的部署流程，没有项目驱动，我不太敢说我会用 Triton。于是，这就有了这系列文章的标题：我不会 Triton...