简介

triton-inference-server是英伟达开源的推理服务，支持多种推理引擎、支持多模型多版本，同时支持自定义后端，方便用户拓展。

环境搭建及使用

镜像构建

triton是使用cmake构建的服务，本身有多个代码库组成：

core 服务核心代码
common 公共使用的工具(proto)
backend 推理引擎接口
server 服务代码
third_party 一些魔改后的三方库
xxx_backend 使用backend接口封装的各个推理引擎

server这个二进制会静态链接core、common、backend的代码，形如xxx_backend都是以动态链接库的形式。

server提供了build.py脚本，用于构建，主要的内容包括，根据入参生成编译脚本和对应dockerfile，然后启动镜像进行编译。
这里的参数包括，需要的引擎、需要开启的功能等。

执行./build.py -v –enable-all –dryrun，只生成脚本，并不实际执行，生成的文件包括:

Build/cmake_build 基于cmake构建组件的脚本
Build/docker_build 构建docker镜像的脚本
Build/Dockerfile 运行镜像
Build/Dockerfile.buildbase 构建镜像
Build/Dckerfile.cibase 流水线镜像

例如cpu版本的构建命令如下:

./build.py -v \
--enable-logging \
--enable-stats \
--enable-metrics \
--enable-tracing  \
--backend=identity \
--backend=repeat \
--backend=ensemble \
--backend=square \
--backend=tensorflow2 \
--backend=onnxruntime \
--backend=openvino \
--backend=pytorch \
--backend=python \
--repoagent=checksum \
--endpoint=grpc \
--endpoint=http \
--extra-backend-cmake-arg=tensorflow:TRITON_TENSORFLOW_INSTALL_EXTRA_DEPS=ON

gpu版本的构建命令如下:

1
2
3

./build.py -v --enable-logging --enable-stats --enable-metrics --enable-gpu-metrics \
--enable-tracing --enable-nvtx --enable-gpu --backend=tensorflow1 --backend=tensorflow2 \
--repoagent=checksum --endpoint=grpc --endpoint=http

事实上，如果要在内部维护triton，直接使用build.py是远远不够的，服务需要一定的改造来适应现有的基础设施。
通常我们需要这些dockerfile文件:

base.Dockerfile 安装了各种三方库的镜像文件
build.Dockerfile 继承base.Dockerfile，并安装了common、core、backend库的镜像文件
xxx_backend.Dockerfile 继承build.Dockerfile，用于编译各个backend的镜像
server.Dockerfile 构建server，并融合各个backend的镜像文件

除了镜像外，需要将common、core、backend、server的代码放到代码库中，根据不同的Dockerfile来编译不同的代码。
不同的backend放到不同的代码库中，一般还是会改一改的。

服务配置

todo: 服务配置说明

模型配置

triton支持多种文件存储，包括s3、as、gs和本地存储，通常能满足实际需要。

triton的模型目录要求如下:

模型数据根目录
- A模型目录
  - config.pbtxt文件
  - 版本A1目录
    - 各种模型的数据文件
  - 版本A2目录
  - …
- B模型目录
  - config.pbtxt文件
  - 版本B1目录
  - 版本B2目录
  - …

config.pbtxt是模型的配置文件。
在triton中一个模型可以拥有多个版本，但是输入输出都是固定的，并且使用的引擎也是固定的，即一个模型可以有多个版本，一个引擎可以有多个模型。

模型的具体配置可以在triton的model_repository文档里看到，
这里简单介绍一下。

模型的配置分为必填配置和选填配置两种：

必填配置
- 模型名、推理引擎、引擎库路径
- 响应模式(一对一还是一对多)
- batch容量
- 模型的输入输出定义
选填配置
- 版本控制策略
- 模型实例分组策略
- 调度器策略
- 优化策略
- 预热配置

todo: 展开介绍

模型管理

通常公司会有一个模型管理平台，triton模型加载机制需要与这个平台适配，从而能够更好的管理。
当服务的实例较多时，直接从s3、as、gs或者hdfs上获取模型的方式，可能不太适用。
毕竟这些对象存储的作用是存储数据，而不是支撑大流量读取。
这时，需要基于p2p搭建一套模型订阅推送的机制，保障模型正常发布的同时，减轻集中存储的压力。

要实现这个功能，通常每个Node上部署一个p2p实例pod，同时进行目录挂载，将模型目录分别挂载到triton的pod和p2p的pod。

triton在服务启动时根据配置向平台注册，并获取到需要的模型机器版本。
然后triton与p2p的pod交互，让其拉去相应的模型数据，并获得拉去任务的状态，进行模型加载。
并且定时上传心跳及从平台获取模型的最新版本情况，以此决定是否需要拉去最新的版本。

p2p的服务可以基于dragonfly或者bbts改造，模型平台也需要提供获取模型版本信息的接口。
triton扫目录获取模型版本的逻辑也需要改成从模型平台接口获取。

自定义后端

todo:

源码阅读

todo: