使用 Triton 部署您训练的模型#

给定一个训练好的模型，我该如何使用 Triton Inference Server 以最佳配置大规模部署它？本文档旨在帮助解答这个问题。

对于喜欢高层次概述的读者，以下是大多数用例的常见流程。

对于希望直接开始的读者，请跳到端到端示例。

有关其他材料，请参阅Triton 概念指南教程。

概述#

  1. 我的模型与 Triton 兼容吗？

    • 如果您的模型属于 Triton 的支持的后端之一，那么我们可以简单地尝试按照快速入门指南中的描述部署模型。对于 ONNXRuntime、TensorFlow SavedModel 和 TensorRT 后端，可以使用 Triton 的自动完成功能从模型推断出最小模型配置。这意味着仍然可以提供 config.pbtxt，但除非您想显式设置某些参数，否则不是必需的。此外，通过启用详细日志记录 --log-verbose=1，您可以在服务器日志输出中看到 Triton 内部看到的完整配置。对于其他后端，请参阅入门所需的最小模型配置。

    • 如果您的模型不是来自受支持的后端，您可以查看Python 后端或编写自定义 C++ 后端来支持您的模型。Python 后端提供了一个简单的接口，可以通过通用的 python 脚本执行请求，但性能可能不如自定义 C++ 后端。根据您的用例，Python 后端的性能可能是实现简单性的充分权衡。

  2. 我可以在我服务的模型上运行推理吗？

    • 假设您能够在 Triton 上加载您的模型，下一步是验证我们是否可以运行推理请求并获得模型的基本性能基准。Triton 的Perf Analyzer 工具专门为此目的而设计。这是一个简化的输出示例，用于演示目的

    # NOTE: "my_model" represents a model currently being served by Triton
$ perf_analyzer -m my_model
...

Inferences/Second vs. Client Average Batch Latency
Concurrency: 1, throughput: 482.8 infer/sec, latency 12613 usec

    • 这为我们提供了一个健全性测试，即我们能够成功形成输入请求并接收输出响应，以通过 Triton API 与模型后端通信。

    • 如果 Perf Analyzer 无法发送请求，并且从错误中不清楚如何继续，那么您可能需要检查您的模型 config.pbtxt 输入/输出是否与模型期望的匹配。如果配置正确，请检查模型是否使用其原始框架直接成功运行。如果您没有自己的脚本或工具来执行此操作，Polygraphy 是一个有用的工具，可以通过各种框架在您的模型上运行示例推理。目前，Polygraphy 支持 ONNXRuntime、TensorRT 和 TensorFlow 1.x。

    • “表现良好”的定义因每个用例而异。一些常见的指标是吞吐量、延迟和 GPU 利用率。在您的模型配置 (config.pbtxt) 中，可以调整许多变量以获得不同的结果。

    • 随着您的模型、配置或用例的演变，Perf Analyzer 是快速验证模型功能和性能的绝佳工具。

  3. 如何提高我的模型性能？

    • 为了进一步了解您可以为您的用例提供给 Triton 的最佳模型配置，Triton 的 Model Analyzer 工具可以提供帮助。Model Analyzer 可以自动或手动搜索配置组合，以找到满足您约束的最佳 Triton 配置。在运行 Model Analyzer 找到模型/用例的最佳配置后，您可以将生成的配置文件传输到您的模型仓库。Model Analyzer 提供了一个快速入门指南，其中包含一些示例供您学习。

    • 在使用 Model Analyzer 找到的新优化配置文件服务模型并再次运行 Perf Analyzer 后，与默认配置相比，您应该期望在大多数情况下找到更好的性能数字。

    • 某些可以为模型调整的参数可能不会暴露给 Model Analyzer 的自动搜索，因为它们并非适用于所有模型。例如，后端可以公开特定于后端的配置选项，这些选项也可以进行调整。例如，ONNXRuntime 后端有几个参数会影响在模型上执行推理时的并行化程度。如果默认值不能提供足够的性能，那么这些特定于后端的选项可能值得研究。为了调整自定义参数集，Model Analyzer 支持手动配置搜索。

    • 要了解有关进一步优化模型配置的更多信息，请参阅优化文档。

其他感兴趣的领域#

  1. 我的模型在 Triton 首次加载时性能缓慢（冷启动惩罚），我该怎么办？

    • Triton 公开了在首次加载模型时运行 ModelWarmup 请求的功能，以确保模型在标记为 “READY” 以进行推理之前得到充分预热。

  2. 为什么我的模型在 GPU 上运行速度没有明显加快？

    • Triton 支持的大多数官方后端都针对 GPU 推理进行了优化，并且应该在 GPU 上开箱即用，性能良好。

    • Triton 公开了让您在 GPU 上进一步优化模型的选项。Triton 的框架特定优化深入探讨了此主题。

    • 将您的模型完全转换为针对 GPU 推理进行全面优化的后端（例如 TensorRT）可能会提供更好的结果。您可以在 TensorRT 后端中找到更多特定于 Triton 的 TensorRT 详细信息。

    • 如果以上方法都无法帮助您的模型获得足够的 GPU 加速性能，则该模型可能更适合 CPU 执行，并且 OpenVINO 后端可能有助于进一步优化您的 CPU 执行。

端到端示例#

注意 如果您以前从未使用过 Triton，您可能首先有兴趣查看快速入门示例。对 Triton 的一些基本了解可能对以下部分很有用，但此示例旨在足够简单，即使没有先前的经验也能理解。

让我们以 ONNX 模型为例，因为 ONNX 旨在成为一种可以从大多数其他框架轻松导出的格式。

  1. 创建一个模型仓库并下载我们的示例 densenet_onnx 模型到其中。

# Create model repository with placeholder for model and version 1
mkdir -p ./models/densenet_onnx/1

# Download model and place it in model repository
wget -O models/densenet_onnx/1/model.onnx
https://contentmamluswest001.blob.core.windows.net/content/14b2744cf8d6418c87ffddc3f3127242/9502630827244d60a1214f250e3bbca7/08aed7327d694b8dbaee2c97b8d0fcba/densenet121-1.2.onnx

  1. 在我们的 模型仓库 中的 ./models/densenet_onnx/config.pbtxt 中为 densenet_onnx 模型创建一个最小的模型配置。

注意 这是另一个示例配置的稍微简化版本，该示例配置利用了其他模型配置功能，这些功能对于本示例不是必需的。

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 ]
  }
]

注意 从 22.07 版本开始，Triton 和 Model Analyzer 都支持为支持自动完成的后端完全自动完成配置文件。因此，例如对于 ONNX 模型，除非您想显式设置某些参数，否则可以跳过此步骤。

  1. 启动服务器容器

为了服务我们的模型，我们将使用服务器容器，该容器预装了 tritonserver 二进制文件。

# Start server container
docker run -ti --rm --gpus=all --network=host -v $PWD:/mnt --name triton-server nvcr.io/nvidia/tritonserver:24.12-py3

# Start serving your models
tritonserver --model-repository=/mnt/models

注意 -v $PWD:/mnt 将您主机上的当前目录挂载到容器内的 /mnt 目录中。因此，如果您在 $PWD/models 中创建了模型仓库，您将在容器内的 /mnt/models 中找到它。您可以根据需要更改这些路径。有关其工作原理的更多信息，请参阅docker volume 文档。

要检查模型是否已成功加载，我们希望在先前命令的输出中看到我们的模型处于 READY 状态

...
I0802 18:11:47.100537 135 model_repository_manager.cc:1345] successfully loaded 'densenet_onnx' version 1
...
+---------------+---------+--------+
| Model         | Version | Status |
+---------------+---------+--------+
| densenet_onnx | 1       | READY  |
+---------------+---------+--------+
...

  1. 验证模型可以运行推理

为了验证我们的模型可以执行推理，我们将使用我们已经启动的 triton-client 容器，该容器预装了 perf_analyzer。

在一个单独的 shell 中，我们使用 Perf Analyzer 进行健全性检查，以确保我们可以运行推理并获得我们期望从该模型获得的性能基线。

在下面的示例中，Perf Analyzer 正在向同一机器上服务的模型发送请求（通过 --network=host 从服务器容器访问 localhost）。但是，您也可以通过设置 -u 标志来测试在 <IP>:<PORT> 远程服务的模型，例如 perf_analyzer -m densenet_onnx -u 127.0.0.1:8000。

# Start the SDK container interactively
docker run -ti --rm --gpus=all --network=host -v $PWD:/mnt --name triton-client nvcr.io/nvidia/tritonserver:24.12-py3-sdk

# Benchmark model being served from step 3
perf_analyzer -m densenet_onnx --concurrency-range 1:4

...
Inferences/Second vs. Client Average Batch Latency
Concurrency: 1, throughput: 265.147 infer/sec, latency 3769 usec
Concurrency: 2, throughput: 890.793 infer/sec, latency 2243 usec
Concurrency: 3, throughput: 937.036 infer/sec, latency 3199 usec
Concurrency: 4, throughput: 965.21 infer/sec, latency 4142 usec

  1. 运行 Model Analyzer 以找到我们模型的最佳配置

虽然 Model Analyzer 预装在 SDK（客户端）容器中，并且支持各种连接到 Triton 服务器的模式，但为了简单起见，我们将在我们的 server 容器中安装 Model Analyzer 以使用 local（默认）模式。要了解有关将 Model Analyzer 连接到正在运行的 Triton Server 的其他方法的更多信息，请参阅 --triton-launch-mode Model Analyzer 标志。

# Enter server container interactively
docker exec -ti triton-server bash

# Stop existing tritonserver process if still running
# because model-analyzer will start its own server
SERVER_PID=`ps | grep tritonserver | awk '{ printf $1 }'`
kill ${SERVER_PID}

# Install model analyzer
pip install --upgrade pip
pip install triton-model-analyzer wkhtmltopdf

# Profile the model using local (default) mode
# NOTE: This may take some time, in this example it took ~10 minutes
model-analyzer profile \
  --model-repository=/mnt/models \
  --profile-models=densenet_onnx \
  --output-model-repository-path=results

# Summarize the profiling results
model-analyzer analyze --analysis-models=densenet_onnx

Model Analyzer 输出摘要示例

在 6 个配置的 51 次测量中，densenet_onnx_config_3 提供了最佳吞吐量：323 infer/秒。

在给定的约束条件下，这比默认配置（168 infer/秒）提高了 92%。

模型配置名称

最大批处理大小

动态批处理

实例计数

p99 延迟 (毫秒)

吞吐量 (infer/秒)

最大 GPU 内存使用量 (MB)

平均 GPU 利用率 (%)

densenet_onnx_config_3

0

已启用

4/GPU

35.8

323.13

3695

58.6

densenet_onnx_config_2

0

已启用

3/GPU

59.575

295.82

3615

58.9

densenet_onnx_config_4

0

已启用

5/GPU

69.939

291.468

3966

58.2

densenet_onnx_config_default

0

已禁用

1/GPU

12.658

167.549

3116

51.3

在上表中，我们看到将我们的 GPU 实例计数设置为 4 使我们能够在此系统上实现最高的吞吐量和几乎最低的延迟。

另请注意，此 densenet_onnx 模型具有固定的批处理大小，该批处理大小在 Input/Output dims 的第一个维度中明确指定，因此 max_batch_size 参数设置为 0，如此处所述。对于支持动态批处理大小的模型，Model Analyzer 也会调整 max_batch_size 参数。

警告 这些结果特定于运行 Triton 服务器的系统，因此，例如，在较小的 GPU 上，我们可能看不到增加 GPU 实例计数带来的改进。一般来说，在具有不同硬件（CPU、GPU、RAM 等）的系统上运行相同的配置可能会提供不同的结果，因此重要的是在准确反映您将在何处为您的用例部署模型的系统上分析您的模型。

  1. 从 Model Analyzer 结果中提取最佳配置

在上面的示例中，densenet_onnx_config_3 是最佳配置。因此，让我们提取该 config.pbtxt 并将其放回我们的模型仓库以供将来使用。

# (optional) Backup our original config.pbtxt (if any) to another directory
cp /mnt/models/densenet_onnx/config.pbtxt /tmp/original_config.pbtxt

# Copy over the optimal config.pbtxt from Model Analyzer results to our model repository
cp ./results/densenet_onnx_config_3/config.pbtxt /mnt/models/densenet_onnx/

现在我们有了一个优化的模型配置，我们已准备好将我们的模型投入部署。如需进一步手动调整，请阅读模型配置和优化文档，以了解有关 Triton 完整功能集的更多信息。

在此示例中，我们恰好从同一配置中获得了最高的吞吐量和几乎最低的延迟，但在某些情况下，这必须做出权衡。某些模型或配置可能会实现更高的吞吐量，但也会反过来导致更高的延迟。值得全面检查 Model Analyzer 生成的报告，以确保您的模型性能满足您的要求。

在本页中