【我不会用 Triton 系列】Triton Inference Server 简介

【我不会用 Triton 系列】Triton Inference Server 简介

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...

上一篇:SpringBoot整合Druid


下一篇:Canal Adapter com.alibaba.druid.pool.DruidDataSource cannot be cast to com.alibaba.druid.pool.DruidD