除非您已经有适合测量的客户端应用程序 您的模型在 Triton 上的性能，您应该熟悉 自己使用性能分析器。 性能分析器是优化模型 性能。
作为演示优化功能的运行示例和 选项，我们将使用您可以获得的 TensorFlow Inception 模型 按照快速入门进行操作。作为基线，我们使用 perf_analyzer使用基本 不支持任何性能的模型配置 功能。
$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, throughput: 62.6 infer/sec, latency 21371 usec
Concurrency: 2, throughput: 73.2 infer/sec, latency 34381 usec
Concurrency: 3, throughput: 73.2 infer/sec, latency 50298 usec
Concurrency: 4, throughput: 73.4 infer/sec, latency 65569 usec
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell0"></button>结果表明，我们的非优化模型配置给出了 每秒约 73 个推理的吞吐量。注意如何有一个 吞吐量显著提高，从一个并发请求到 两个并发请求，然后吞吐量趋于平稳。用一个 并发请求 Triton 在响应期间处于空闲状态 返回到客户端，并在 服务器。吞吐量随着并发性而增加，因为 Triton 将一个请求的处理与 其他。因为我们perf_analyzer在与 Triton，两个请求足以完全隐藏通信延迟。
优化设置
对于大多数型号，Triton 功能可提供最大的 性能改进是动态的 批处理。此示例更阐明了概念细节。如果您的模型没有 支持批处理，然后您可以跳到模型 实例。
动态配料机
动态批处理器将单个推理请求组合成 更大的批处理，通常执行效率比 独立执行各个请求。启用动态 配料机停止Triton，将以下行添加到模型的末尾 的配置文件 inception_graphdef， ，然后重新启动海卫一。
dynamic_batching { }
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell1"></button>动态配料机允许Triton处理更多数量的 并发请求，因为这些请求合并为 推理。若要查看此运行perf_analyzer，请求并发来自 1 至 8。
$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 1:8
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, throughput: 66.8 infer/sec, latency 19785 usec
Concurrency: 2, throughput: 80.8 infer/sec, latency 30732 usec
Concurrency: 3, throughput: 118 infer/sec, latency 32968 usec
Concurrency: 4, throughput: 165.2 infer/sec, latency 32974 usec
Concurrency: 5, throughput: 194.4 infer/sec, latency 33035 usec
Concurrency: 6, throughput: 217.6 infer/sec, latency 34258 usec
Concurrency: 7, throughput: 249.8 infer/sec, latency 34522 usec
Concurrency: 8, throughput: 272 infer/sec, latency 35988 usec
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell2"></button>通过八个并发请求，动态批处理器允许 Triton 每秒提供 272 个推理，而不会增加延迟 与不使用动态批处理器相比。
而不是让perf_analyzer为一系列请求收集数据 并发值我们可以改用几个简单的规则 通常适用于 perf_analyzer 在同一系统上运行时 氚核。第一条规则是，对于最小延迟，设置请求 并发为 1 并禁用动态批处理器并仅使用 1 个模型 实例。第二条规则是最大值 吞吐量 将请求并发设置为 。我们将讨论模型 下面的实例，目前我们使用一个模型 实例。因此，对于最大批次大小 4，我们希望运行perf_analyzer 请求并发性为 。2 * <maximum batch size> * <model instance count>2 * 4 * 1 = 8
$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 8
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 8, throughput: 267.8 infer/sec, latency 35590 usec
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell3"></button>模型实例
Triton 允许您指定每个模型的副本数量 可用于推理。默认情况下，您将获得每个副本的一个副本 模型，但您可以在模型中指定任意数量的实例 使用实例进行配置 组。通常，有两个 模型的实例将提高性能，因为它允许 内存传输操作的重叠（例如，CPU 与 GPU 之间的传输操作） 使用推理计算。多个实例也改进了 GPU 通过允许执行更多推理工作来利用 同时在 GPU 上。较小的型号可能会受益于 两个实例;您可以使用perf_analyzer进行试验。
要指定inception_graphdef模型的两个实例：停止 Triton， 删除之前可能已添加到的任何动态批处理设置 模型配置（我们讨论将动态批处理器和 下面的多个模型实例），将以下行添加到 模型配置 文件，以及 然后重新启动海卫一。
instance_group [ { count: 2 }]
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell4"></button>现在，使用与基线相同的选项运行perf_analyzer。
$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, throughput: 70.6 infer/sec, latency 19547 usec
Concurrency: 2, throughput: 106.6 infer/sec, latency 23532 usec
Concurrency: 3, throughput: 110.2 infer/sec, latency 36649 usec
Concurrency: 4, throughput: 108.6 infer/sec, latency 43588 usec
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell5"></button>在这种情况下，具有模型的两个实例会增加吞吐量 从每秒约 73 次推理到每秒约 110 次推理 与一个实例相比。
可以同时启用动态配料机和多模型 实例，例如，更改模型配置文件以包含 以下。
dynamic_batching { }
instance_group [ { count: 2 }]
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell6"></button>当我们perf_analyzer使用仅用于 上面的动态配料器。
$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 16
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 16, throughput: 289.6 infer/sec, latency 59817 usec
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell7"></button>我们看到两个实例并没有提高吞吐量，而 与仅使用动态批处理器相比，延迟增加，并且 一个实例。发生这种情况是因为对于此模型，动态批处理器 单独能够充分利用 GPU，因此添加额外的 模型实例不提供任何性能优势。通常 动态批处理器和多个实例的好处是模型 具体，因此您应该尝试使用perf_analyzer来确定 最能满足吞吐量和延迟要求的设置。
特定于框架的优化
Triton 有几个优化设置，仅适用于一个子集 支持的模型框架。这些优化设置是 由模型配置优化控制 政策。访问本指南进行端到端讨论。
ONNX with TensorRT Optimization （ORT-TRT）
一个特别强大的优化是在 与 ONNX 模型结合使用。作为 TensorRT 优化的示例 应用于 ONNX 模型，我们将使用 ONNX DenseNet 模型，即 可以通过以下快速入门获取。作为基线，我们 使用 perf_analyzer 使用不启用任何性能的基本模型配置来确定模型的性能 功能。
$ perf_analyzer -m densenet_onnx --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, 113.2 infer/sec, latency 8939 usec
Concurrency: 2, 138.2 infer/sec, latency 14548 usec
Concurrency: 3, 137.2 infer/sec, latency 21947 usec
Concurrency: 4, 136.8 infer/sec, latency 29661 usec
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell8"></button>要为模型启用 TensorRT 优化：停止 Triton，添加 以下行到模型配置文件的末尾，然后 重新启动海卫一。
optimization { execution_accelerators {
gpu_execution_accelerator : [ {
name : "tensorrt"
parameters { key: "precision_mode" value: "FP16" }
parameters { key: "max_workspace_size_bytes" value: "1073741824" }
}]
}}
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell9"></button>当Triton启动时，您应该检查控制台输出并等待 Triton 打印“凝视端点”消息。ONNX 模型加载可以 启用 TensorRT 优化时会明显变慢。在 生产 您可以使用模型预热来避免此模型启动/优化速度减慢。现在 使用与基线相同的选项运行perf_analyzer。
$ perf_analyzer -m densenet_onnx --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, 190.6 infer/sec, latency 5384 usec
Concurrency: 2, 273.8 infer/sec, latency 7347 usec
Concurrency: 3, 272.2 infer/sec, latency 11046 usec
Concurrency: 4, 266.8 infer/sec, latency 15089 usec
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell10"></button>TensorRT 优化提供了 2 倍的吞吐量提升，同时 将延迟减半。TensorRT提供的好处会有所不同 基于模型，但总的来说它可以提供显着 性能改进。
具有OpenVINO优化的ONNX
在CPU上运行的ONNX模型也可以通过使用OpenVINO来加速。自 为 ONNX 模型启用 OpenVINO 优化，添加以下内容 行到模型配置文件的末尾。
optimization { execution_accelerators {
cpu_execution_accelerator : [ {
name : "openvino"
}]
}}
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell11"></button>TensorFlow with TensorRT Optimization （TF-TRT）
应用于 TensorFlow 模型的 TensorRT 优化的工作方式类似于 上面描述的TensorRT和ONNX。要启用 TensorRT 优化，您需要 必须正确设置模型配置。对于张量RT 优化 TensorFlow 模型有几个选项，您可以 可以启用，包括选择计算精度。
optimization { execution_accelerators {
gpu_execution_accelerator : [ {
name : "tensorrt"
parameters { key: "precision_mode" value: "FP16" }}]
}}
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell12"></button>这些选项在模型配置 protobuf 的 ModelOptimizationPolicy 部分中进行了详细说明。
作为应用于TensorFlow模型的TensorRT优化的示例， 我们将使用一个 TensorFlow Inception 模型，您可以通过以下方式获得该模型 按照快速入门进行操作。作为基线，我们使用 perf_analyzer使用基本 不支持任何性能的模型配置 功能。
$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, throughput: 62.6 infer/sec, latency 21371 usec
Concurrency: 2, throughput: 73.2 infer/sec, latency 34381 usec
Concurrency: 3, throughput: 73.2 infer/sec, latency 50298 usec
Concurrency: 4, throughput: 73.4 infer/sec, latency 65569 usec
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell13"></button>要为模型启用 TensorRT 优化：停止 Triton，添加 从上方到模型配置文件末尾的行，然后 重新启动海卫一。当Triton启动时，您应该检查控制台输出 并等待服务器打印“凝视端点”消息。现在 使用与基线相同的选项运行perf_analyzer。注意 第一次运行perf_analyzer可能会超时，因为 TensorRT 在收到推理请求时执行优化，并且 可能需要很长时间。在生产中，您可以使用模型 预热以避免此模型 启动/优化速度减慢。现在，如果发生这种情况，只需运行 又perf_analyzer。
$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, throughput: 140 infer/sec, latency 8987 usec
Concurrency: 2, throughput: 195.6 infer/sec, latency 12583 usec
Concurrency: 3, throughput: 189 infer/sec, latency 19020 usec
Concurrency: 4, throughput: 191.6 infer/sec, latency 24622 usec
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell14"></button>TensorRT 优化提供了 2.5 倍的吞吐量提升，而 将延迟减少一半以上。TensorRT提供的好处 会因型号而异，但总的来说它可以提供 显著的性能改进。
TensorFlow JIT Graph Optimizations
Tensorflow允许其用户指定优化级别 同时通过全局JitLevel设置运行模型图。 有关更多信息，请参阅 config.proto。运行时 Triton中的TensorFlow模型，用户可以提供此设置 通过提供如下所示的图形级别：
optimization {
graph { level: 1
}}
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell15"></button>用户还可以通过在启动前设置环境变量来利用XLA优化 氚核。使用 GPU 和 CPU 自动集群启动 Triton 的示例：TF_XLA_FLAGS
$ TF_XLA_FLAGS="--tf_xla_auto_jit=2 --tf_xla_cpu_global_jit" tritonserver --model-repository=...
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell16"></button>与上面的 TensorRT 优化一样，这些优化 在运行第一个推理请求时发生。为了缓解 模型启动速度变慢 在生产系统中，可以使用模型预热。
张量流自动 FP16 优化
TensorFlow有一个选项来提供FP16优化，它可以 在模型配置中启用。与 TensorRT 优化一样 如上所述，您可以使用 gpu_execution_accelerator财产。
optimization { execution_accelerators {
gpu_execution_accelerator : [
{ name : "auto_mixed_precision" }
]
}}
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell17"></button>这些选项在模型配置 protobuf 的 ModelOptimizationPolicy 部分中进行了详细说明。
您可以按照上述 TensorRT 的步骤查看这是如何 自动 FP16 优化通过使用perf_analyzer使模型受益 评估有和没有优化的模型性能。
NUMA 优化
许多现代 CPU 由多个内核、内存和互连组成，这些内核、内存和互连 根据线程和 数据已分配。 Triton 允许您设置主机策略来描述此 NUMA 配置： 您的系统，然后将模型实例分配给不同的主机策略 以利用这些 NUMA 属性。
主机策略
Triton 允许您指定与策略名称关联的主机策略 启动。如果模型实例是 使用实例中的主机策略字段指定相同的策略名称 组。请注意，如果未指定， 主机策略字段将根据实例设置为默认名称 财产。
要指定主机策略，可以在命令行选项中指定以下内容：
--host-policy=<policy_name>,<setting>=<value>
<button class="copybtn o-tooltip--left" data-tooltip="Copy" data-clipboard-target="#codecell18"></button>目前，支持的设置如下：
-
numa-node：主机策略将绑定到的 NUMA 节点 ID，即 主机策略将内存分配限制为指定的节点。
-
CPU 核心：要在其上运行的 CPU 核心，具有此主机策略的实例 set 将在其中一个 CPU 内核上运行。
假设系统配置为将 GPU 0 与具有 NUMA 节点 0 的 NUMA 节点绑定 CPU 内核从 0 到 15，下面显示了设置 numa 节点和 CPU 内核 “gpu_0”政策
$ tritonserver --host-policy=gpu_0,numa-node=0 --host-policy=gpu_0,cpu-cores=0-15 ...
