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:隊列或計算時間未涵蓋請求處理所需的額外時間。

triton inference server翻譯之Optimization

Optimization

Optimization Settings

Dynamic Batcher

Model Instances

Framework-Specific Optimization

ONNX with TensorRT Optimization

TensorFlow with TensorRT Optimization

perf_client

Request Concurrency

Understanding The Output

Visualizing Latency vs. Throughput

Input Data

Real Input Data

Shared Memory

Communication Protocol

Server Trace

JSON Trace Output

Trace Summary Tool

triton inference server翻譯之Optimization

triton inference server翻譯之Quickstart

triton inference server翻譯之Models And Schedulers

triton inference server翻譯之user guide

triton inference server翻譯之Model Configuration

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結