Target:
-
理解triton的架构和工作过程
-
overview
-
design basic，并非软件库，偏应用型的软件
-
辅助功能
-
上手材料 **
-
大厂自研推理框架 vs Triton
1 快速认识triton
triton inference server架构原理
推理系统架构
整体上推理服务分为客户端、服务端，对应图中client、server。这里主要分析服务端架构。 推理服务系统必须是一个k8s集群，原因是推理服务系统中每个小服务需要生命周期管理、弹性扩容、自动运维（运维、编排）。
1 推理服务是基于k8s集群（k8s集群提供容器的管理系统能力，方便运维、编排） 2 推理服务组成：负载均衡、模型仓库、metric sevice、inferenc server
前端负载均衡：inference局部服务会启动很多个，LB负责有效分配请求到inference服务 模型仓库：管理模型 metric sevice：观测数据，驾驶舱 inferenc server：；支持异构：cpu、gpu、tpu等；支持多框架：tensorrt engine、pytorch等 负责单节点上推理服务 K8S Cluster: 推理系统，多节点多卡的推理服务概念 Triton: 单节点推理服务（单卡或多卡, typically within one container as a service） TensorRT: 加速库，library
Triton架构
基本功能：
- 支持多推理框架（TensorFlow、Pytorch、TensorRT、OnnxRT、custom backends）
- 支持异构 CPU、GPU、multi-gpu
- 并行推理（CPU角度）
- http、grpc APIs
- 能集成到k8s集群，监控、自动伸缩
- 模型管理，加载、卸载、更新
- 使用友好，NGC容器镜像仓库
scheduler模块：推理服务请求队列调度（不是进程、线程调度）
2 设计原则
从推理生命周期，推理服务的设计思路 支持多框架-> backends概念 基本功能： backend管理 模型管理 多线程并行推理，多instance 请求队列分发、调度 推理生命周期管理 （请求+响应） grpc相关
从模型角度，设计思路：
- 单一模型
- 有状态模型
- 模型组，pipline
Triton doc
- stateless
- CV
- 调度方式：Default scheduler，dynamic batch
- statefull
- NLP
- 基于序列调度方式，Sequence batch（Direct、Oldest）
- ensemble
- pipline models
- pipline内部模型的调度
Triton VS In-house inference server 1 开源BSD licencse，友好
- community，重构风险小
- core members来自NV，对GPU适配最好
- 各个大厂贡献backends，可以互相借鉴
- 利用最新特性，提issus 2 支持多种框架 3 已被多个公司采用，成熟 4 customer backends 5 支持多实例，基于GRPC、CUDA等优化，相比in-house自研推理服务性能更好 6 支持指标监控
3 开发手册
user-guide
docs.nvidia.com/deeplearnin…
ngc container
github repo github.com/triton-infe…
github.com/NVIDIA/Deep… examples:
- CV
- NLP
- Automatic Speech Recognition
- Text to Speech
- Recommendation Systems
developer blogs
4 Trition entry-level
-
准备模型
-
配置servered model
-
发起Triton sever
docker run -it --gpus all -v ${PWD}:/workspace nvcr.io/nvidia/pytorch:22.04-py3
docker run --gpus=all -it --shm-size=256m --rm -p8000:8000 -p8001:8001 -p8002:8002 -v $(pwd)/model_repository:/models nvcr.io/nvidia/tritonserver:22.08-py3
