triton inference server翻译之Optimization

Optimization

Triton Inference Server具有许多功能，可用于减少模型的延迟和增加吞吐量。本节讨论了这些功能并演示了如何使用它们来改善模型的性能。作为先决条件，您应该遵循快速入门，以使服务器和客户端示例与示例模型存储库一起运行。

除非您已经拥有一个适合在推论服务器上测量模型性能的客户端应用程序，否则您应该熟悉perf_client。 perf_client应用程序是优化模型性能的必要工具。

作为演示优化功能和选项的运行示例，我们将使用Caffe2 ResNet50模型，您可以通过遵循快速入门来获得该模型。作为基准，我们使用perf_client通过不启用任何性能功能的基本模型配置来确定模型的性能：

$ perf_client -m resnet50_netdef --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, 159 infer/sec, latency 6701 usec
Concurrency: 2, 204.8 infer/sec, latency 9807 usec
Concurrency: 3, 204.2 infer/sec, latency 14846 usec
Concurrency: 4, 199.6 infer/sec, latency 20499 usec

结果表明，我们的非优化模型配置提供了每秒约200个推理的吞吐量。请注意，从一个并发请求到两个并发请求，吞吐量显着增加，然后吞吐量趋于平稳。对于一个并发请求，在将响应返回给客户端并在服务器上接收到下一个请求的时间内，推理服务器处于空闲状态。由于推理服务器将一个请求的处理与另一个请求的通信重叠，因此吞吐率为2并发。因为我们在与推理服务器相同的系统上运行perf_client，所以2个请求足以完全隐藏通信延迟。

Optimization Settings

对于大多数模型，动态批处理程序是提供最大性能改进的推理服务器功能。如果您的模型不支持批处理，则可以直接跳至模型实例。

Dynamic Batcher

动态批处理程序将单个推理请求合并为一个较大的批处理，该批处理通常比独立执行单个请求要高效得多。要启用动态批处理程序停止推理服务器，请将以下行添加到resnet50_netdef的模型配置文件的末尾，然后重新启动推理服务器：

dynamic_batching {}

动态批处理程序允许推理服务器处理大量并发请求，因为这些请求被组合以进行推理。因此，以请求并发性从1到8运行perf_client：

$ perf_client -m resnet50_netdef --percentile=95 --concurrency-range 1:8
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, 154.2 infer/sec, latency 6662 usec
Concurrency: 2, 203.6 infer/sec, latency 9931 usec
Concurrency: 3, 242.4 infer/sec, latency 12421 usec
Concurrency: 4, 335.6 infer/sec, latency 12423 usec
Concurrency: 5, 335.2 infer/sec, latency 16034 usec
Concurrency: 6, 363 infer/sec, latency 19990 usec
Concurrency: 7, 369.6 infer/sec, latency 21382 usec
Concurrency: 8, 426.6 infer/sec, latency 19526 usec

与不使用动态批处理程序相比，动态批处理程序通过八个并发请求，可以使推理服务器每秒提供约425个推理，而不会增加延迟。

您还可以显式指定创建批次时希望动态批次程序首选的批次大小。例如，要表明您希望动态批处理程序更喜欢4个批次，您可以像这样修改模型配置（可以指定多个优选的大小，但在这种情况下，我们只有一个）：

dynamic_batching {preferred_batch_size：[4]}

代替让perf_client为一定范围的请求并发值收集数据，我们可以使用简单的规则，该规则通常在perf_client与推理服务器在同一系统上运行时适用。规则是，为了获得最大吞吐量，请将请求并发设置为2 * <首选批处理大小> * <模型实例计数>。我们将在下面讨论模型实例，目前我们正在处理一个模型实例。因此，对于preferred-batch-size 4，我们要以2 * 4 * 1 = 8的请求并发度运行perf_client：

$ perf_client -m resnet50_netdef --percentile=95 --concurrency-range 8
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 8, 420.2 infer/sec, latency 19524 usec

Model Instances

推理服务器使您可以指定要用于推理的每个模型的副本数。默认情况下，每个模型都有一个副本，但是您可以使用实例组在模型配置中指定任意数量的实例。通常，拥有两个模型实例将提高性能，因为它允许内存传输操作（例如，往/从GPU到CPU）与推理计算重叠。多个实例还通过允许在GPU上同时执行更多推理工作来提高GPU利用率。较小的模型可能会受益于两个以上的实例；您可以使用perf_client进行实验。

要指定resnet50_netdef模型的两个实例，请执行以下操作：停止推理服务器，删除您先前可能已添加到模型配置中的任何动态批处理设置（我们在下面讨论将动态批处理程序和多个模型实例结合在一起），将以下行添加到模型配置文件，然后重新启动推理服务器：

instance_group [ { count: 2 }]

现在，使用与基线相同的选项运行perf_client：

$ perf_client -m resnet50_netdef --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, 129.4 infer/sec, latency 8434 usec
Concurrency: 2, 257.4 infer/sec, latency 8126 usec
Concurrency: 3, 289.6 infer/sec, latency 12621 usec
Concurrency: 4, 287.8 infer/sec, latency 14296 usec

在这种情况下，与一个实例相比，具有两个模型实例将吞吐量从每秒大约200个推理增加到每秒大约290个推理。

可以同时启用动态批处理程序和多个模型实例，例如：

dynamic_batching { preferred_batch_size: [ 4 ] }
instance_group [ { count: 2 }]

当我们使用仅用于上面的动态批处理程序的相同选项运行perf_client时：

$ perf_client -m resnet50_netdef --percentile=95 --concurrency-range 8
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 8, 409.2 infer/sec, latency 24284 usec

我们看到两个实例并没有提高吞吐量或延迟。发生这种情况的原因是，对于该模型，仅动态批处理程序就能够充分利用GPU，因此添加其他模型实例不会提供任何性能优势。通常，动态批处理程序和多个实例的好处是特定于模型的，因此您应该尝试使用perf_client来确定最能满足吞吐量和延迟要求的设置。

Framework-Specific Optimization

推理服务器具有几个优化设置，这些优化设置仅适用于支持的模型框架的一部分。这些优化设置由模型配置优化策略控制。

我们将在这里探索的一种特别强大的优化方法是将TensorRT优化与TensorFlow或ONNX模型结合使用。

ONNX with TensorRT Optimization

作为应用于ONNX模型的TensorRT优化的示例，我们将使用可通过遵循快速入门获得的ONNX DenseNet模型。作为基准，我们使用perf_client通过不启用任何性能功能的基本模型配置来确定模型的性能：

$ perf_client -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

要为模型启用TensorRT优化：停止推理服务器，将以下行添加到模型配置文件的末尾，然后重新启动推理服务器：

optimization { execution_accelerators {
  gpu_execution_accelerator : [ { name : "tensorrt" } ]
}}

在推理服务器启动时，您应该检查控制台输出，并等待直到服务器打印Staring endpoints消息。启用TensorRT优化后，ONNX模型加载可能会大大减慢。现在，使用与基线相同的选项运行perf_client：

$ perf_client -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

TensorRT优化提供了2倍的吞吐量提高，同时将延迟减少了一半。 TensorRT提供的好处会因模型而异，但总的来说，它可以显着改善性能。

TensorFlow with TensorRT Optimization

应用于TensorFlow模型的TensorRT优化与上述TensorRT和ONNX相似。要启用TensorRT优化，您必须适当设置模型配置。为了优化TensorFlow模型的TensorRT，您可以启用多个选项，包括选择计算精度。例如：

optimization { execution_accelerators {
  gpu_execution_accelerator : [ {
    name : "tensorrt"
    parameters { key: "precision_mode" value: "FP16" }}]
}}

在模型配置协议的ModelOptimizationPolicy部分中详细描述了这些选项。

作为应用于TensorFlow模型的TensorRT优化的示例，我们将使用可通过遵循快速入门获得的TensorFlow Inception模型。作为基准，我们使用perf_client通过不启用任何性能功能的基本模型配置来确定模型的性能：

$ perf_client -m inception_graphdef --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, 105.6 infer/sec, latency 12865 usec
Concurrency: 2, 120.6 infer/sec, latency 20888 usec
Concurrency: 3, 122.8 infer/sec, latency 30308 usec
Concurrency: 4, 123.4 infer/sec, latency 39465 usec

要为模型启用TensorRT优化：停止推理服务器，将上方的行添加到模型配置文件的末尾，然后重新启动推理服务器。在推理服务器启动时，您应该检查控制台输出，并等待直到服务器打印Staring endpoints消息。现在，使用与基线相同的选项运行perf_client。请注意，perf_client的第一次运行可能会超时，因为TensorRT优化是在收到推理请求时执行的，可能会花费大量时间。如果发生这种情况，请再次运行perf_client：

$ perf_client -m inception_graphdef --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, 172 infer/sec, latency 6912 usec
Concurrency: 2, 265.2 infer/sec, latency 8905 usec
Concurrency: 3, 254.2 infer/sec, latency 13506 usec
Concurrency: 4, 257 infer/sec, latency 17715 usec

TensorRT优化提供了2倍的吞吐量提高，同时将延迟减少了一半。 TensorRT提供的好处会因模型而异，但总的来说，它可以显着改善性能。

perf_client

优化模型的推理性能的关键部分是能够在尝试不同的优化策略时测量性能变化。 perf_client应用程序为Triton Inference Server执行此任务。 perf_client包含在客户端示例中，这些示例可从多个来源获得。

perf_client生成对模型的推理请求，并测量这些请求的吞吐量和延迟。为了获得代表性的结果，perf_client在一个时间窗口内测量吞吐量和延迟，然后重复测量直到获得稳定值。默认情况下，perf_client使用平均延迟来确定稳定性，但是您可以使用--percentile标志基于该置信度来稳定结果。例如，如果使用--percentile = 95，则将使用第95个百分位请求延迟来稳定结果。例如：

$ perf_client -m resnet50_netdef --percentile=95
*** Measurement Settings ***
  Batch size: 1
  Measurement window: 5000 msec
  Stabilizing using p95 latency

Request concurrency: 1
  Client:
    Request count: 809
    Throughput: 161.8 infer/sec
    p50 latency: 6178 usec
    p90 latency: 6237 usec
    p95 latency: 6260 usec
    p99 latency: 6339 usec
    Avg HTTP time: 6153 usec (send/recv 72 usec + response wait 6081 usec)
  Server:
    Request count: 971
    Avg request latency: 4824 usec (overhead 10 usec + queue 39 usec + compute 4775 usec)

Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, 161.8 infer/sec, latency 6260 usec

Request Concurrency

默认情况下，perf_client使用模型上的最低负载来测量模型的延迟和吞吐量。为此，perf_client向服务器发送一个推理请求，然后等待响应。收到该响应后，perf_client立即发送另一个请求，然后在测量窗口期间重复此过程。完成的推理请求数为请求并发数，因此默认情况下，perf_client使用请求并发1。

使用--concurrency-range <start>：<end>：<step>选项，您可以让perf_client收集一系列请求并发级别的数据。使用–help选项可查看有关此选项和其他选项的完整文档。例如，要查看模型的延迟和吞吐量（请求并发值从1到4）：

$ perf_client -m resnet50_netdef --concurrency-range 1:4
*** Measurement Settings ***
  Batch size: 1
  Measurement window: 5000 msec
  Latency limit: 0 msec
  Concurrency limit: 4 concurrent requests
  Stabilizing using average latency

Request concurrency: 1
  Client:
    Request count: 804
    Throughput: 160.8 infer/sec
    Avg latency: 6207 usec (standard deviation 267 usec)
    p50 latency: 6212 usec
...
Request concurrency: 4
  Client:
    Request count: 1042
    Throughput: 208.4 infer/sec
    Avg latency: 19185 usec (standard deviation 105 usec)
    p50 latency: 19168 usec
    p90 latency: 19218 usec
    p95 latency: 19265 usec
    p99 latency: 19583 usec
    Avg HTTP time: 19156 usec (send/recv 79 usec + response wait 19077 usec)
  Server:
    Request count: 1250
    Avg request latency: 18099 usec (overhead 9 usec + queue 13314 usec + compute 4776 usec)

Inferences/Second vs. Client Average Batch Latency
Concurrency: 1, 160.8 infer/sec, latency 6207 usec
Concurrency: 2, 209.2 infer/sec, latency 9548 usec
Concurrency: 3, 207.8 infer/sec, latency 14423 usec
Concurrency: 4, 208.4 infer/sec, latency 19185 usec

Understanding The Output

对于每个请求并发级别，perf_client报告从客户端看到的延迟和吞吐量（即perf_client看到的）以及服务器上的平均请求延迟。

服务器等待时间用于衡量从服务器接收到请求到从服务器发送响应之间的总时间。由于用于实现服务器端点的HTTP和GRPC库，HTTP请求的总服务器延迟通常更准确，因为它测量从收到的第一个字节到发送的最后一个字节的时间。对于HTTP和GRPC，总的服务器延迟分为以下几部分：

queue:请求在推理调度队列中等待模型实例可用的时间；
compute: 执行实际推理所花费的平均时间，包括将数据复制到GPU或从GPU复制数据所需的任何时间；

HTTP和GRPC的客户端延迟时间进一步细分如下：

HTTP: send/recv指示客户端在发送请求和接收响应上花费的时间。响应等待指示等待服务器响应的时间。
GRPC: (un)编组请求/响应表示将请求数据编组到GRPC协议和从GRPC协议解编响应数据所花费的时间。响应等待表示将GRPC请求写入网络，等待响应以及从网络读取GRPC响应的时间。

在perf_client中使用详细(-v)选项可查看更多输出，包括针对每个请求并发级别运行的稳定化传递。

Visualizing Latency vs. Throughput

perf_client提供-f选项以生成包含结果的CSV输出的文件：

$ perf_client -m resnet50_netdef --concurrency-range 1:4 -f perf.csv
$ cat perf.csv
Concurrency,Inferences/Second,Client Send,Network+Server Send/Recv,Server Queue,Server Compute,Client Recv,p50 latency,p90 latency,p95 latency,p99 latency
1,160.8,68,1291,38,4801,7,6212,6289,6328,7407
3,207.8,70,1211,8346,4786,8,14379,14457,14536,15853
4,208.4,71,1014,13314,4776,8,19168,19218,19265,19583
2,209.2,67,1204,3511,4756,7,9545,9576,9588,9627

您可以将CSV文件导入电子表格，以帮助直观显示延迟与推理/秒的权衡关系，以及查看延迟的某些组成部分。跟着这些步骤：

打开此电子表格
从“文件”菜单“进行复制…”进行复制
打开副本
在“原始数据”选项卡上选择A1单元格
从文件菜单中选择“导入…”
选择“上传”并上传文件
选择“在选定单元格处替换数据”，然后选择“导入数据”按钮

Input Data

使用–help选项可查看所有输入数据选项的完整文档。默认情况下，perf_client将随机数据发送到模型的所有输入。您可以使用--input-data选项选择其他输入数据模式：

random ：（默认）为每个输入发送随机数据。
zero：为每个输入发送零。
directory path：该路径包含每个输入的二进制文件，名称与输入相同。每个二进制文件必须包含批处理1请求的该输入所需的数据。每个文件应包含按行优先顺序输入的原始二进制表示形式。
file path：JSON文件的路径，其中包含要与每个推理请求一起使用的数据。有关更多详细信息，请参见“实际输入数据”部分。–input-data可以使用特定的多个JSON文件的不同文件路径多次提供。

对于具有STRING数据类型的张量，在某些情况下可以使用其他选项--string-length和--string-data（有关完整文档，请参阅–help）。

对于支持批处理的模型，可以使用-b选项指示perf_client应该发送的请求的批处理大小。对于输入大小可变的模型，必须提供--shape参数，以便perf_client知道要使用的形状张量。例如，对于模型输入名为IMAGE的模型，模型的形状为[3，N，M]，其中N和M为可变尺寸，告诉perf_client发送4个形状为[3,224,224]：

$ perf_client -m mymodel -b 4 --shape IMAGE:3,224,224

Real Input Data

一些模型的性能高度依赖于所使用的数据。对于这种情况，用户可以在JSON文件中提供要与客户端提出的每个推断请求一起使用的数据。当以循环方式发送推理请求时，perf_client将使用提供的数据。

“数据”数组中的每个条目都必须指定所有输入张量，这些张量必须具有模型在单个批次中期望的确切大小。以下示例描述了模型的数据，该模型的输入名为INPUT0和INPUT1，形状为[4，4]，数据类型为INT32：

{
  "data" :
   [
      {
        "INPUT0" : [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
        "INPUT1" : [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
      },
      {
        "INPUT0" : [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
        "INPUT1" : [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
      },
      {
        "INPUT0" : [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
        "INPUT1" : [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
      },
      {
        "INPUT0" : [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
        "INPUT1" : [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
      }
      .
      .
      .
    ]
}

请注意，[4，4]张量已以行主格式展平用于输入。

除了指定显式张量之外，用户还可以为张量提供Base64编码的二进制数据。每个数据对象必须按行优先顺序列出其数据。下面的示例重点介绍了如何实现：

{
  "data" :
   [
      {
        "INPUT0" : {"b64": "YmFzZTY0IGRlY29kZXI="},
        "INPUT1" : {"b64": "YmFzZTY0IGRlY29kZXI="}
      },
      {
        "INPUT0" : {"b64": "YmFzZTY0IGRlY29kZXI="},
        "INPUT1" : {"b64": "YmFzZTY0IGRlY29kZXI="}
      },
      {
        "INPUT0" : {"b64": "YmFzZTY0IGRlY29kZXI="},
        "INPUT1" : {"b64": "YmFzZTY0IGRlY29kZXI="}
      },
      .
      .
      .
    ]
}

对于序列模型，可以在JSON文件中指定多个数据流。每个序列将获得其自己的数据流，并且客户端将确保将每个流中的数据播放到相同的关联ID。下面的示例重点介绍如何使用名为INPUT，shape [1]和数据类型STRING的单个输入为序列模型的多个流指定数据：

{
  "data" :
    [
      [
        {
          "INPUT" : ["1"]
        },
        {
          "INPUT" : ["2"]
        },
        {
          "INPUT" : ["3"]
        },
        {
          "INPUT" : ["4"]
        }
      ],
      [
        {
          "INPUT" : ["1"]
        },
        {
          "INPUT" : ["1"]
        },
        {
          "INPUT" : ["1"]
        }
      ],
      [
        {
          "INPUT" : ["1"]
        },
        {
          "INPUT" : ["1"]
        }
      ]
    ]
}

上面的示例描述了三个长度分别为4、3和2的数据流。因此，在这种情况下，perf_client将产生长度为4、3和2的序列。

用户还可以向张量提供可选的“形状”字段。这在使用可变大小张量作为输入的模型进行模型分析时特别有用。指定的形状值将被视为替代，并且客户仍希望将可变大小的输入的默认输入形状作为命令行选项提供（请参见–shape）。在没有“形状”字段的情况下，将使用提供的默认值。以下是具有单个输入“INPUT”，形状[-1，-1]和数据类型INT32的模型的示例json文件：

{
  "data" :
   [
      {
        "INPUT" :
              {
                  "content": [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
                  "shape": [2,8]
              }
      },
      {
        "INPUT" :
              {
                  "content": [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
                  "shape": [8,2]
              }
      },
      {
        "INPUT" :
              {
                  "content": [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
              }
      },
      {
        "INPUT" :
              {
                  "content": [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
                  "shape": [4,4]
              }
      }
      .
      .
      .
    ]
}

Shared Memory

B默认情况下，perf_client通过网络发送输入张量数据并接收输出张量数据。相反，您可以指示perf_client使用系统共享内存或CUDA共享内存来传递张量数据。通过使用这些选项，您可以对通过在应用程序中使用共享内存可以实现的性能进行建模。使用--shared-memory = system使用系统（CPU）共享内存，或使用--shared-memory = cuda使用CUDA共享内存。

Communication Protocol

默认情况下，perf_client使用HTTP与推理服务器进行通信。可以使用-i选项指定GRPC协议。如果选择了GRPC，还可以为GRPC流指定--streaming选项。

Server Trace

推理服务器具有为单个推理请求生成详细跟踪的功能。如果要构建自己的推理服务器，则在配置cmake时必须使用-DTRTIS_ENABLE_TRACING = ON选项。

运行tritonserver可执行文件时，可通过命令行参数启用跟踪。例如：

$ tritonserver --trace-file=/tmp/trace.json --trace-rate=100 --trace-level=MAX ...

--trace-file选项指示应将跟踪输出写入何处。 --trace-rate选项指定采样率。在此示例中，将跟踪每100个推理请求。 --trace-level选项指示应收集的跟踪详细信息的级别。使用--help选项可获得更多信息。

JSON Trace Output

跟踪输出是具有以下架构的JSON文件：

[
  {
    "model_name": $string,
    "model_version": $number,
    "id": $number
    "parent_id": $number,
    "timestamps": [
      { "name" : $string, "ns" : $number },
      ...
    ]
  },
  ...
]

每个跟踪指示模型名称和推断请求的版本，每个跟踪都分配有唯一的id。如果跟踪来自作为集成的一部分运行的模型，则parent_id将指示包含集成的id。每条迹线将具有一个或多个“时间戳”，每个时间戳均具有名称和时间戳（以纳秒（ns）为单位）。例如：

[
  {
    "model_name": "simple",
    "model_version": -1,
    "id":1,
    "timestamps" : [
      { "name": "http recv start", "ns": 2259961222771924 },
      { "name": "http recv end", "ns": 2259961222820985 },
      { "name": "request handler start", "ns": 2259961223164078 },
      { "name": "queue start", "ns": 2259961223182400 },
      { "name": "compute start", "ns": 2259961223232405 },
      { "name": "compute end", "ns": 2259961230206777 },
      { "name": "request handler end", "ns": 2259961230211887 },
      { "name": "http send start", "ns": 2259961230529606 },
      { "name": "http send end", "ns": 2259961230543930 } ]
   }
 ]

Trace Summary Tool

示例跟踪摘要工具可用于汇总从推理服务器收集的一组跟踪。基本用法是：

$ trace_summary.py <trace file>

这将为文件中的所有跟踪生成摘要报告。 HTTP和GRPC推理请求分别报告：

File: trace.json
Summary for simple (-1): trace count = 1
HTTP infer request (avg): 378us
      Receive (avg): 21us
      Send (avg): 7us
      Overhead (avg): 79us
      Handler (avg): 269us
              Overhead (avg): 11us
              Queue (avg): 15us
              Compute (avg): 242us
                      Input (avg): 18us
                      Infer (avg): 208us
                      Output (avg): 15us
Summary for simple (-1): trace count = 1
GRPC infer request (avg): 21441us
      Wait/Read (avg): 20923us
      Send (avg): 74us
      Overhead (avg): 46us
      Handler (avg): 395us
              Overhead (avg): 16us
              Queue (avg): 47us
              Compute (avg): 331us
                      Input (avg): 30us
                      Infer (avg): 286us
                      Output (avg): 14us

使用-t选项可获取文件中每个跟踪的摘要。此摘要显示了在处理推理请求时不同点之间的时间（以微秒为单位）。例如，以下输出显示从开始处理请求到将请求排入调度队列花费了15us：

$ trace_summary.py -t <trace file>
...
simple (-1):
      grpc wait/read start
              26529us
      grpc wait/read end
              39us
      request handler start
              15us
      queue start
              20us
      compute start
              266us
      compute end
              4us
      request handler end
              19us
      grpc send start
              77us
      grpc send end
...

跟踪时间戳的含义是：

GRPC Request Wait/Read: 仅针对使用GRPC协议的推理请求收集。等待请求到达服务器并读取该请求所花费的时间。因为等待时间包含在时间中，所以它不是衡量从网络读取请求所花费时间的有用方法。跟踪HTTP请求将提供读取时间的准确度量。
HTTP Request Receive: 仅针对使用HTTP协议的推理请求收集。从网络读取推理请求所需的时间。
Send:发送推理响应所需的时间。
Overhead: HTTP或GRPC终结点中需要额外的时间来处理推理请求和响应。
Handler: 处理推理请求所花费的总时间，不包括HTTP和GRPC请求/响应处理。
Queue: 推理请求在调度队列中花费的时间。
Compute: 推理请求执行实际推理所花费的时间。该时间包括复制输入和输出张量所花费的时间。如果-trace-level = MAX，则将按以下方式提供计算时间的细分：
- Input: 根据推理框架/后端的要求复制输入张量数据的时间。这包括将输入张量数据复制到GPU的时间。
- Infer: 执行模型执行推理所花费的时间。
- Output: 根据推理框架/后端要求复制输出张量数据的时间。这包括从GPU复制输出张量数据的时间。
- Overhead:队列或计算时间未涵盖请求处理所需的额外时间。