-
什么是model repositry?
是在宿主机上的一个文件夹,用于存放模型定义文件,其典型结构如下图所示
-
如何创建model repository?
每一个在repository中的模型都必须有一个配置文件
可以在Triton中配置多个模型,每个模型可以有一个对应的模型配置文件(pbtxt格式)。然而,Triton本身有一个主配置文件,通常是以YAML格式编写的,用于定义Triton推理服务的整体配置,包括多个模型的配置。主配置文件示例:
# 主配置文件示例
# 定义模型1
model1:
name: model1
platform: pytorch
max_batch_size: 1
model_config: |
version: "1"
builder:
... # 定义模型构建器
signature: ... # 定义模型签名
inputs: ... # 定义输入张量定义
outputs: ... # 定义输出张量定义
file_name: path/to/model1.pbtxt
# 定义模型2
model2:
name: model2
platform: pytorch
max_batch_size: 1
model_config: |
version: "1"
builder:
... # 定义模型构建器
signature: ... # 定义模型签名
inputs: ... # 定义输入张量定义
outputs: ... # 定义输出张量定义
file_name: path/to/model2.pbtxt
有些模型配置文件是可以自动生成的
一个最小模型配置文件需要包含平台,后端,最大批尺寸,以及输入和输出张量,示例如下
name: "densenet_onnx"
backend: "onnxruntime"
max_batch_size: 0
input: [ { name: "data_0", data_type: TYPE_FP32, dims: [ 1, 3, 224, 224] }]
output: [ { name: "prob_1", data_type: TYPE_FP32, dims: [ 1, 1000, 1, 1 ] }]
name : 模型的名称,要与目录的名称对应
platform:指定使用哪个backend进行解码
max_batch_size: 当我们使用dynamic batch scheduler时,需要指定我们的最大batch size是多少
input:指定输入参数的名称、类型和shape
output:指定输出参数的名称、类型、shape和label文件
dynamic_batching: 开启triton server的动态组装batch的能力,默认情况下triton server不会进行batch组合
instance_group:指定我们在GPU0上部署4个reset50的实例。通过增加model 的instance个数,我们可以有效提升GPU的使用率
模型配置文件中 平台platform名可选值如下
tensorrt_plan
tensorflow_graphdef
tensorflow_savedmodel
caffe2_netdef
onnxruntime_onnx
pytorch_libtorch
custom
ensemble
- 启动triton容器
docker run -ti --rm --gpus=all --network=host -v $PWD:/mnt --name triton-server nvcr.io/nvidia/tritonserver:23.06-py3
- 验证triton运行正确
要使用Ready端点验证Triton Inference Server服务器和模型是否已准备好进行推理,可以按照以下步骤进行操作:
确保已经安装并配置了Triton Inference Server,并且模型已经上传到服务器上。
在浏览器中打开Triton Inference Server的Ready端点页面。Ready端点的URL通常为http://:/ready,其中是服务器IP地址,是Triton的端口号。
在Ready端点页面上,你应该能够看到关于服务器和模型状态的详细信息。确保服务器状态显示为"健康",并且模型状态显示为"已加载"。
如果服务器和模型状态都正常,你可以尝试使用Triton Inference Server进行推理。
通过以上步骤,你可以验证Triton Inference Server服务器和模型是否已经准备好进行推理。请注意,Ready端点仅提供服务器和模型的健康状态信息,而不提供关于输入或输出的详细信息。要测试模型的推理能力,请使用其他端点(例如 /v2/infer)并发送适当的输入数据来进行测试。
- 发送推理请求
Triton Inference Server是一个开源的、可扩展的机器学习推理服务,它能够与各种模型运行时交互,支持各种不同的编程语言和模型格式。以下是如何向Triton Inference Server发送推理请求的一般步骤:
4.1. 服务部署: 首先,你需要将你的模型部署到Triton Inference Server。这可以通过使用Triton命令行工具或通过编程方式来完成。例如,使用命令行工具,你可以运行如下命令:
triton server --model-repository /path/to/your/models
4.2. 创建客户端: 然后,你需要创建一个客户端来与服务器通信。如果你使用的是Python,你可以使用Triton Python SDK来创建客户端。例如:
from triton import *
# 创建一个客户端实例
client = TritonClient()
# 连接到服务器
client.connect()
4.3. 设置输入数据: 根据你的模型的需求,你需要设置输入数据。例如,如果你的模型接受图像作为输入,你可能需要将图像数据转换为正确的格式并设置其形状和数据类型。
4.4 执行推理请求: 通过调用inference
方法来执行推理请求。例如:
# 设置输入数据...
input1 = client.create_input(InputType.IMAGE, "input1", [1, 3, 224, 224])
input1.set_data(...)
input2 = client.create_input(InputType.TENSOR, "input2", [1, 100])
input2.set_data(...)
# 执行推理请求
response = client.inference(model_name, [input1, input2])
请注意,这只是一个基本的示例。具体的步骤可能会根据你的模型和需求有所不同。你可以参考Triton的文档和示例代码来了解更多关于如何与Triton Inference Server交互的信息。
4.5. 解析输出: 根据你的模型输出类型,你可能需要解析响应数据。例如,如果你的模型输出是一个向量,你可能需要从响应中获取这个向量并解析它。
4.6. 关闭连接: 在完成所有推理请求后,记得关闭与服务器之间的连接:
client.close()
除了使用triton库向Triton Inference Server发送推理请求外,还可以使用HTTP或gRPC协议进行通信。以下是使用HTTP协议发送推理请求的步骤:
构建HTTP请求。使用HTTP请求发送推理请求,需要构造一个符合RESTful风格的HTTP请求。请求的URL应该是Triton Inference Server的推理端点,例如http://:/v2/infer,其中是服务器IP地址,是Triton的端口号。
在HTTP请求中包含必要的参数。根据你要使用的模型,你需要提供模型所需的输入参数。这些参数可以通过请求的正文(body)或查询字符串(query string)进行传递。
发送HTTP请求。使用你喜欢的HTTP客户端库(如Python的requests库)发送HTTP请求。确保在发送请求之前,你已经安装并配置了Triton Inference Server,并且模型已经上传到服务器上。
以下是一个使用Python和requests库发送HTTP推理请求的示例代码:
import requests
# 设置服务器地址和端口
server_ip = 'localhost'
port = 8000
# 设置模型名称和输入参数
model_name = 'my_model'
input_data = {'input_tensor': [1, 2, 3]}
# 构建请求URL和参数
url = f'http://{server_ip}:{port}/v2/infer'
params = {'model_name': model_name, 'input': input_data}
# 发送HTTP请求
response = requests.post(url, json=params)
# 解析响应结果
if response.status_code == 200:
output = response.json()['output']
print(output)
else:
print(f'请求失败,状态码为{response.status_code}')
-
运行模型运行分析器找到模型的最佳配置
发送请求,在另一个终端窗口中,运行Triton SDK的image_client示例,执行命令
docker run -it --rm --net=host nvcr.io/nvidia/tritonserver:22.09-py3-sdk /workspace/install/bin/image_client -m densenet_onnx -c 3 -s INCEPTION /workspace/images/mug.jpg
在image_client运行时,Triton Inference Server的perf analyzer会自动进行性能分析,并输出结果。
-
什么是backend?
就是模型执行的实现。
backend需要遵守 backend api
这些api的作用:triton使用api向backend发请求,backend使用这些api与triton通信
举例来说,对于 backend = tensorflow,platform必须等于tensorflow_savedmodel或tensorflow_graphdef
至于backend实现的形式,必须实现为shared library共享库,参见本文第一副图中custom_backend的model.so,共享库的名字必须是 triton_
任何人都可以开发Triton后端,所以我们不可能了解所有可用的后端。但是Triton项目确实提供了一组支持的后端,每个Triton版本都对其进行了测试和更新。
triton有哪些预置的backend呢?介绍如下。
TensorRT: TensorRT后端用于执行TensorRT模型。服务器repo包含后端源代码。
ONNX Runtime: ONNX Runtime后端用于执行ONNX模型。onnxruntime_backend repo包含后端文档和源代码。
TensorFlow: TensorFlow后端用于执行GraphDef和SavedModel格式的TensorFlow模型。相同的后端用于执行TensorFlow 1和TensorFlow 2模型。tensorflow_backend repo包含后端的文档和源代码。
PyTorch: PyTorch后端用于执行TorchScript模型。pytorch_backend repo包含后端文档和源代码。
OpenVINO: OpenVINO后端用于执行OpenVINO模型。openvino_backend repo包含后端文档和源代码。
Python: Python后端允许你用Python编写模型逻辑。例如,您可以使用这个后端来执行用Python编写的前后处理代码,或者直接执行PyTorch Python脚本(而不是先将其转换为TorchScript,然后使用PyTorch后端)。python_backend repo包含后端文档和源代码。
DALI: DALI是一个高度优化的构建模块和执行引擎的集合,可以加速深度学习应用程序输入数据的预处理。DALI后端允许您在Triton内执行DALI管道。dali_backend repo包含了后台的文档和源代码。
FIL: FIL (Forest Inference Library)后端用于执行各种基于树的ML模型,包括XGBoost模型、LightGBM模型、Scikit-Learn随机森林模型和cuML随机森林模型。fil_backend repo包含后端文档和源代码。
并非所有上述后端backend都支持Triton支持的每个平台platform。
Triton后端是执行模型的实现。后端可以是深度学习框架的包装,如PyTorch, TensorFlow, TensorRT, ONNX Runtime或OpenVINO。后端也可以实现您想要的任何功能,只要它遵循后端API。Triton使用这个API发送请求到后端执行,后端使用API与Triton通信。
每个模型都必须与后端相关联。模型的后端是使用后端设置在模型配置中指定的。对于使用TensorRT后端,此设置的值应该是TensorRT。同样,对于使用PyTorch, ONNX和TensorFlow后端,后端字段应分别设置为PyTorch, onnxruntime或TensorFlow。对于所有其他后端,backend必须设置为后端名称。有些后端还会检查平台设置来对模型进行分类,例如,在TensorFlow后端,根据模型的格式,平台应该设置为tensorflow_savedmodel或tensorflow_graphdef。请参考是否使用平台的特定后端存储库。
后端共享库
每个后端必须实现为共享库,共享库的名称必须为libtriton_<backend-name> so。例如,如果后端名称为“mybackend”,则模型通过将模型配置’backend’设置为“mybackend”来指示它使用后端,并且Triton查找libtriton_mybackend。作为实现后端的共享库。本教程展示了如何将后端逻辑构建到适当的共享库中的示例。
对于指定后端B的模型M, Triton按照以下顺序搜索后端共享库:
& lt; model_repository> / M / & lt; version_directory> / libtriton_B.so
& lt; model_repository> / M / libtriton_B.so
& lt; global_backend_directory> / B / libtriton_B.so
在& lt; global_backend_directory>默认为/opt/tritonserver/backends。——backend-directory标志可以用来覆盖默认值。
通常,您将把后端安装到全局后端目录中。例如,如果使用Triton Docker镜像,您可以按照Triton中不支持和自定义后端的说明进行操作。继续这个名为“mybackend”的后端示例,你将安装到Triton映像中如下:
/ opt /
tritonserver /
后端/
mybackend /
libtriton_mybackend.so
…# mybackend需要的其他文件
Triton后端API
Triton后端必须实现tritonbackend.h中定义的C接口。API使用以下抽象。
TRITONBACKEND_Backend
TRITONBACKEND_Backend对象表示后端本身。相同的后端对象在使用该后端的所有模型之间共享。相关的API,如TRITONBACKEND_BackendName,用于获取有关后端的信息,并将用户定义的状态与后端相关联。
后端可以选择实现TRITONBACKEND_Initialize和TRITONBACKEND_Finalize来获得后端对象创建和销毁的通知(更多信息参见后端生命周期)。
TRITONBACKEND_Model
TRITONBACKEND_Model对象表示一个模型。Triton加载的每个模型都与TRITONBACKEND_Model相关联。每个模型都可以使用TRITONBACKEND_ModelBackend API来获取表示模型使用的后端对象。
在该模型的所有实例之间共享相同的模型对象。相关的API,如TRITONBACKEND_ModelName,用于获取关于模型的信息,并将用户定义的状态与模型关联起来。
大多数后端将实现TRITONBACKEND_ModelInitialize和TRITONBACKEND_ModelFinalize来初始化给定模型的后端,并管理与模型相关联的用户定义状态(有关更多信息,请参阅后端生命周期)。
当实现TRITONBACKEND_ModelInitialize和TRITONBACKEND_ModelFinalize时,后端必须考虑线程问题。对于给定的模型,Triton不会同时对这些函数执行多个调用;但是,如果一个后端被多个模型使用,Triton可能会为每个模型使用不同的线程同时调用这些函数。因此,后端必须能够处理对函数的多个同时调用。后端实现的最佳实践是在这些函数中只使用函数局部和特定于模型的用户定义状态,如本教程所示。
TRITONBACKEND_ModelInstance
TRITONBACKEND_ModelInstance对象表示一个模型实例。Triton根据模型配置中指定的instance_group设置创建一个或多个模型实例。这些实例中的每一个都与TRITONBACKEND_ModelInstance对象相关联。
如何构建Triton不支持的后端和自定义后端
您可以创建和构建自己的Triton后端。该构建的结果应该是一个目录,其中包含后端共享库和后端所需的任何其他文件。假设您的后端名为“mybackend”,目录为“。/mybackend",将以下内容添加到composer .py创建的Dockerfile中,将创建一个包含所有支持的Triton后端以及您的自定义后端的Triton映像。
COPY ./mybackend /opt/tritonserver/backend /mybackend
您还需要将后端所需的任何其他依赖项安装为Dockerfile的一部分。然后使用Docker创建镜像。
$ docker build -t tritonserver_custom -f Dockerfile.compose
-
max_batchsize 参数
分成两种情况
7.1 模型支持batching
通过dynamic batcher 或者sequence batcher实现batching
7.2 模型不支持batching
该参数必须设置为0该参数对延迟和吞吐量的影响是复杂的,取决于多个因素。一般来说,增加max_batchsize参数会使吞吐量增加,但可能会对延迟产生负面影响。 吞吐量:吞吐量通常是指单位时间内可以处理多少个样本。增加max_batchsize通常会增加吞吐量,因为每次推理可以处理更多的样本。然而,这并不是绝对的,如果max_batchsize设置得过大,超过了硬件资源的限制(例如GPU内存),可能会导致推理速度变慢,反而降低吞吐量。因此,需要根据具体的硬件配置和模型来选择合适的max_batchsize。 延迟:延迟是指处理一个样本需要的时间。减小max_batchsize通常会降低延迟,因为可以更快地处理单个样本。但是,如果max_batchsize设置得过小,可能会导致GPU等硬件资源的利用率不足,反而增加平均处理时间,提高延迟。因此,需要找到一个平衡点,使得max_batchsize既能充分利用硬件资源提高吞吐量,又能降低单个样本的处理时间,降低延迟。
-
输入和输出
每一个输入和输出都必须指定一个名称,数据类型,以及形状 输入和输出张量的名称必须和模型指定的名称匹配。
-
Triton Inference Server 的自定义后端(backends)如何实现?
Triton Inference Server 的自定义后端(backends)通常需要以共享库(SO库)的形式实现,这是因为 Triton 使用插件架构,可以加载和卸载这些库以实现不同的模型后端。这种设计使得 Triton 能够支持多种不同的模型运行时,包括 TensorFlow、PyTorch、ONNX 等。
模型仓库(Model Repository)是存放模型的目录,其中包含了用于推理的模型文件和元数据。这些模型文件可以是直接由模型开发人员提供的,也可以是通过转换工具从其他模型格式转换过来的。模型仓库中的模型文件通常是已经在 Triton 上训练和优化过的,可以直接用于推理服务。
总的来说,自定义后端和模型仓库中的模型有一些区别:
自定义后端是实现特定模型运行时的代码库,通常以共享库的形式提供。它们允许 Triton 支持更多种类的模型和框架。
模型仓库中的模型是已经训练和优化过的模型文件,可以直接用于推理服务。
在实践中,自定义后端的开发者和模型开发人员可能需要合作,以确保自定义后端能够正确地加载和处理模型仓库中的模型。
- triton inference server中 对于多个模型串联的组合模型,如何衔接各个模型?
在Triton Inference Server中,串联多个模型可以通过以下两种方式实现:
使用Triton的模型链(Model Chaining)功能。该功能允许你将多个模型连接在一起,形成一个组合模型。在这种情况下,你不需要手动确保每个模型的输出张量形状与下一个模型的输入张量形状相同,因为Triton会自动处理形状匹配和转换。
要在Triton中创建模型链,你可以使用add_model_chain方法,其中需要指定要连接的模型名称以及它们之间的连接方式。每个模型的输出张量名称和下一个模型的输入张量名称需要在模型配置中进行匹配。
手动将多个模型进行串联。在这种情况下,你需要确保每个模型的输出张量形状与下一个模型的输入张量形状匹配。你可以在模型配置中指定输出张量名称和形状,并在下一个模型的输入张量配置中提供相应的名称和形状。
无论使用哪种方式,都需要确保每个模型的输出张量形状与下一个模型的输入张量形状匹配,以便正确地进行数据传递和推理。