triton inference server翻譯之Models And Schedulers

通過整合多個框架和自定義後端，Triton Inference Server支持多種模型。同時，推理服務器還支持多種調度和批處理配置，從而進一步擴展了推理服務器可以處理的模型類別。

本節描述模型的無狀態，有狀態和組合模式，以及推理服務器如何提供調度程序以支持那些模型類型。

Stateless Models

對於推理服務器的調度程序，無狀態模型（或無狀態自定義後端）不會維持推理請求之間的狀態。在無狀態模型上執行的每個推斷都獨立於使用該模型的所有其他推理。無狀態模型的示例是CNN，例如圖像分類和對象檢測。缺省調度程序或動態批處理程序可用於這些無狀態模型。

具有內部存儲器的RNN和類似模型可以是無狀態的，只要它們所維護的狀態不跨越推理請求即可。例如，如果推理請求之間未攜帶內部狀態，則推理服務器將迭代批次中所有元素的RNN視爲無狀態。缺省調度程序可用於這些無狀態模型。無法使用動態批處理程序，因爲模型通常不希望批處理代表多個推理請求。

Stateful Models

對於推理服務器的調度程序，有狀態模型（或有狀態自定義後端）會在推理請求之間保持狀態。該模型期望多個推理請求一起形成推理序列，這些推理序列必須路由到同一模型實例，以便正確更新模型所維護的狀態。此外，該模型可能要求推理服務器提供指示例如序列開始的控制信號。

序列批處理程序必須用於這些有狀態模型。因爲，序列批處理程序確保將序列中的所有推理請求都路由到同一模型實例，以便模型可以正確維護狀態。序列批處理程序還與模型通信，以指示序列何時開始，何時結束，是否已經準備好需要執行的推理請求以及序列的相關性ID。

As explained in Client API for Stateful Models, when making inference requests for a stateful model, the client application must provide the same correlation ID to all requests in a sequence, and must also mark the start and end of the sequence. The correlation ID allows the inference server to identify that the requests belong to the same sequence.

如客戶端中對有狀態模型的解釋，當對有狀態模型進行推理請求時，客戶端必須爲序列中的所有請求提供相同的相關ID，並且標記序列的開始和結束。其中，相關性ID允許推理服務器識別請求屬於同一序列。

Control Inputs

爲了使狀態模型能夠與序列批處理程序一起正確運行，模型通常必須接受一個或多個控制輸入張量，這些張量是推理服務器用來與模型進行通信的，用nvidia::inferenceserver::ModelSequenceBatching::Control部分可查看。所有控件都是可選的，以下是模型配置的一部分，顯示了所有可用控制信號的示例配置：

sequence_batching {
  control_input [
    {
      name: "START"
      control [
        {
          kind: CONTROL_SEQUENCE_START
          fp32_false_true: [ 0, 1 ]
        }
      ]
    },
    {
      name: "END"
      control [
        {
          kind: CONTROL_SEQUENCE_END
          fp32_false_true: [ 0, 1 ]
        }
      ]
    },
    {
      name: "READY"
      control [
        {
          kind: CONTROL_SEQUENCE_READY
          fp32_false_true: [ 0, 1 ]
        }
      ]
    },
    {
      name: "CORRID"
      control [
        {
          kind: CONTROL_SEQUENCE_CORRID
          data_type: TYPE_UINT64
        }
      ]
    }
  ]
}

Start
CONTROL_SEQUENCE_START標示起始輸入張量，表明該模型具有一個名爲START的輸入張量，具有32位浮點數類型。序列批處理程序將在對模型執行推斷時定義此張量。 START張量必須爲一維且大小等於batch-size。張量中的每個元素標示批處理批次相應位置的序列是否已經開始處理。示例中，fp32_false_true等於1代表開始處理，否則並未開始。
End
同理
Ready
同理
Correlation ID
同理

Scheduling Strategies

兩個調度策略

Direct
使用直接調度策略，序列批處理程序不僅可以確保將序列中的所有推理請求都路由到同一模型實例，而且還可以確保將每個序列都路由到模型實例內的專用批處理插槽。當模型需要維護每個批處理插槽的狀態，並且期望將給定序列的所有推理請求路由到同一插槽，以便正確更新狀態時，就需要此策略。

模型配置文件：

name: "direct_stateful_model"
platform: "tensorrt_plan"
max_batch_size: 2
sequence_batching {
  max_sequence_idle_microseconds: 5000000
  direct { }
  control_input [
    {
      name: "START"
      control [
        {
          kind: CONTROL_SEQUENCE_START
          fp32_false_true: [ 0, 1 ]
        }
      ]
    },
    {
      name: "READY"
      control [
        {
          kind: CONTROL_SEQUENCE_READY
          fp32_false_true: [ 0, 1 ]
        }
      ]
    }
  ]
}
input [
  {
    name: "INPUT"
    data_type: TYPE_FP32
    dims: [ 100, 100 ]
  }
]
output [
  {
    name: "OUTPUT"
    data_type: TYPE_FP32
    dims: [ 10 ]
  }
]
instance_group [
  {
    count: 2
  }
]

關鍵字mermaid sequenceDiagram_batching標示模型應使用序列批處理程序和直接調度策略。在此示例中，模型僅需要來自序列批處理程序的start和ready控制張量， instance_group標示模型的兩個實例，max_batch_size指示每個實例應執行batch-size爲2的推理。下圖顯示了此配置指定的序列批處理程序和推理資源。

每個模型實例都在維護每個批處理插槽的狀態，並期望將給定序列的所有推理請求路由到同一插槽，以便正確更新狀態。對於此示例，這意味着推理服務器可以同時執行多達四個序列的推理。

使用直接調度策略的序列批處理有如下特徵：

識別推理請求何時開始新序列併爲該序列分配批處理插槽。如果沒有批處理插槽可用於新序列，則服務器會將推理請求置於待辦事項列表（積壓）；
識別何時推理請求是具有分配的批處理插槽的序列的一部分，並將請求路由到該插槽；
識別推理請求何時是待辦事項列表中序列的一部分，並將請求放入待辦事項列表中；
識別序列中的最後一個推理請求何時完成，該序列佔用的批處理插槽將立即重新分配到積壓中的序列，如果沒有積壓，則將其釋放以供將來的序列使用。

下圖顯示瞭如何使用直接調度策略將多個序列調度到模型實例上。左圖顯示了到達推理服務器的幾個請求序列。每個序列可以由任意數量的推理請求組成，並且這些單獨的推理請求可以相對於其他序列中的推理請求以任何順序到達，除了右側所示的執行順序，序列0的第一個推理請求比序列1-5中的任何推理請求先到達，序列1的第一個推理請求比序列2-5中的任何推理請求先前到達，以此類推。

圖的右側顯示瞭如何隨時間將推理請求序列調度到模型實例上。

下圖顯示了序列批處理程序使用控制輸入張量與模型進行通信的過程。每個序列的推理請求都會隨時間到達。 START和READY行顯示用於模型的每次執行的輸入張量值。隨着時間的流逝，會發生以下情況：

第一個請求到達插槽0中的序列。假設模型實例尚未執行推理，則序列調度程序會立即調度模型實例以執行，因爲推理請求可用；
這是序列中的第一個請求，因此START張量中的相應元素設置爲1。插槽1中沒有可用的請求，因此READY張量僅顯示插槽0爲就緒；
推斷完成後，序列調度程序會發現任何批處理插槽中都沒有可用的請求，因此模型實例處於空閒狀態；
接下有兩個請求幾乎同時到達，且狀態爲可用，調度程序立即調度模型實例以執行batch-size爲2的推理，並使用START和READY顯示兩個插槽都有可用的推理請求，但是隻有slot1是新序列的開始；
對於其他推斷請求，處理以類似的方式繼續；

Oldest
With the Oldest scheduling strategy the sequence batcher ensures that all inference requests in a sequence are routed to the same model instance and then uses the dynamic batcher to batch together multiple inferences from different sequences into a batch that inferences together. With this strategy the model must typically use the CONTROL_SEQUENCE_CORRID control so that it knows which sequence each inference request in the batch belongs to. The CONTROL_SEQUENCE_READY control is typically not needed because all inferences in the batch will always be ready for inference.

使用最舊的調度策略，序列批處理程序可確保將序列中的所有推理請求都路由到同一模型實例，然後使用動態批處理程序將來自不同序列的多個推理彙總到一起進行推理。使用這種策略，模型須使用CONTROL_SEQUENCE_CORRID以便它知道批處理中每個推理請求屬於哪個序列，而不需要CONTROL_SEQUENCE_READY，因爲批處理中的所有推理將始終準備好進行推理。

示例：

name: "oldest_stateful_model"
platform: "custom"
max_batch_size: 2
sequence_batching {
  max_sequence_idle_microseconds: 5000000
  oldest
    {
      max_candidate_sequences: 4
      preferred_batch_size: [ 2 ]
    }
  control_input [
    {
      name: "START"
      control [
        {
          kind: CONTROL_SEQUENCE_START
          fp32_false_true: [ 0, 1 ]
        }
      ]
    },
    {
      name: "END"
      control [
        {
          kind: CONTROL_SEQUENCE_END
          fp32_false_true: [ 0, 1 ]
        }
      ]
    },
    {
      name: "CORRID"
      control [
        {
          kind: CONTROL_SEQUENCE_CORRID
          data_type: TYPE_UINT64
        }
      ]
    }
  ]
}
input [
  {
    name: "INPUT"
    data_type: TYPE_FP32
    dims: [ 100, 100 ]
  }
]
output [
  {
    name: "OUTPUT"
    data_type: TYPE_FP32
    dims: [ 10 ]
  }
]

sequenceDiagram_batching```標示模型使用的是序列批處理和最老調度策略， 該序列批處理程序最多維護4個活躍序列，可動態形成batch-size爲2d的批處理批次，且模型需要從開始，結束和相關ID控制張量。 下圖顯示了此配置指定的序列批處理程序和推理資源。

![dyna_sequence_example0.jpg](https://note.youdao.com/src/WEBRESOURCE88dd810dff1118cc174499216e19d83e)

特徵：  
- 識別推理請求何時開始新序列並嘗試查找具有候選序列空間的模型實例。如果沒有模型實例可容納新的候選序列，則服務器會將推理請求放置在待辦事項中；
- 識別推理請求何時是某個已爲候選序列的一部分，並將請求路由到該模型實例；
- 識別推理請求何時是待辦事項列表中序列的一部分，並將請求放入待辦事項列表中；
- 識別序列中的最後一個請求何時完成，之後，模型實例立即從待辦事項列表中刪除一個序列，並將其作爲自己的候選序列，或者記錄該模型實例空閒；

下圖顯示瞭如何將多個序列調度到上述示例配置指定的模型實例上。左圖顯示了到達推理服務器的四個請求序列。每個序列都由多個推理請求組成，如圖所示，圖的中心顯示瞭如何隨時間推移將推理請求序列批處理到模型實例上，假設每個序列的推理請求以相同的速率到達，而序列A恰好在B之前到達，而序列A恰好在C之前到達，等等。最舊的策略根據最舊的請求形成一個動態批處理，但在批處理中從不包含來自給定序列的多個請求（例如，序列D中的最後兩個推論不會一起批處理）。

![dyna_sequence_example1.jpg](https://note.youdao.com/src/WEBRESOURCE2714150aa02a48e3ec1994bd5100df00)

## Ensemble Models
集成模型表示由一個或多個模型以及彼此之間的輸入，輸出張量連接而成的管線。集成模型旨在用於封裝多個模型的處理過程，例如“數據預處理->推理->數據後處理”。爲此目的使用集成模型可以避免傳輸中間張量的開銷，並最大程度地減少必鬚髮送到推理服務器的請求數。

集成調度程序必須用於集成模型，而與集成中的模型使用的調度程序無關。關於集成調度器，集成模型不是實際模型，還有模型之間的數據流動。調度程序在每個步驟中收集輸出張量，根據規範將它們提供爲其他步驟的輸入張量。儘管如此，從外部視圖來看，集成模型仍然被視爲單個模型。[example](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/client_example.html#section-ensemble-image-classification-example)

請注意，集成模型將繼承所涉及模型的特徵，因此請求頭中的元數據必須符合集成中的模型要求。例如，如果模型之一是有狀態模型，那麼對集成模型的推理請求應包含上一節中提到的信息，該信息將由調度程序提供給有狀態模型。

示例：

name: “ensemble_model”
platform: “ensemble”
max_batch_size: 1
input [
{
name: “IMAGE”
data_type: TYPE_STRING
dims: [ 1 ]
}
]
output [
{
name: “CLASSIFICATION”
data_type: TYPE_FP32
dims: [ 1000 ]
},
{
name: “SEGMENTATION”
data_type: TYPE_FP32
dims: [ 3, 224, 224 ]
}
]
ensemble_scheduling {
step [
{
model_name: “image_preprocess_model”
model_version: -1
input_map {
key: “RAW_IMAGE”
value: “IMAGE”
}
output_map {
key: “PREPROCESSED_OUTPUT”
value: “preprocessed_image”
}
},
{
model_name: “classification_model”
model_version: -1
input_map {
key: “FORMATTED_IMAGE”
value: “preprocessed_image”
}
output_map {
key: “CLASSIFICATION_OUTPUT”
value: “CLASSIFICATION”
}
},
{
model_name: “segmentation_model”
model_version: -1
input_map {
key: “FORMATTED_IMAGE”
value: “preprocessed_image”
}
output_map {
key: “SEGMENTATION_OUTPUT”
value: “SEGMENTATION”
}
}
]
}

關鍵字```ensemble_scheduling```指出使用的是集成調度器，包含三個模型。step部分的每個元素都指定要使用的模型，以及模型的輸入，輸出及映射的張量名稱。例如，第一個元素指定應使用```image_preprocess_model```的最新版本，其輸入```RAW_IMAGE```由```IMAGE```張量提供，其輸出```PREPROCESSED_OUTPUT```的內容將映射爲```preprocessed_image```張量供以後使用。調度程序識別的張量名稱是整體輸入，整體輸出以及```input_map```和```output_map```中的所有值。

集成模型也啓用了動態批處理，因爲集成模型只是在組成模型之間路由數據，推理服務器可以將請求帶到集成模型中，而無需修改集成的配置。

假設有集成模型，預處理模型，分類模型和細分模型，則客戶端應用程序會將它們視爲可以獨立處理請求的四個不同模型。但是，集成調度器視角下的集成模型是下圖所示。

![ensemble_example0.jpg](http://note.youdao.com/yws/res/9846/WEBRESOURCE6857ce80a8adc3950c0c923077014e69)

特徵：
- 1，確認請求中的```IMAGE```張量已映射到預處理模型中的輸入```RAW_IMAGE```；
- 2，檢查集成模型，然後將內部請求發送到預處理模型，因爲所需的所有輸入張量都已準備就緒；
- 3，識別內部請求的完成，收集輸出張量，然後將內容映射到```preprocessed_image```，這是整體中已知的唯一名稱；
- 4，將新收集的張量映射到集成模型的輸入，在這種情況下，```classification_model```和```segmentation_model```的輸入將被映射並標記爲就緒；
- 5，檢查需要新收集張量的模型，並將內部請求發送到已準備好輸入的模型（此時爲分類模型和分割模型）。注意，響應將以任意順序，具體取決於各個模型的負載和計算時間；
- 6，重複步驟3-5，直到不再發送內部請求爲止，然後使用張量映射到集合輸出名稱的方式對推理請求進行響應。

triton inference server翻譯之Models And Schedulers

Stateless Models

Stateful Models

Control Inputs

Scheduling Strategies

10分鐘搞定Mysql主從部署配置

如何使用 JS 判斷用戶是否處於活躍狀態

一鍵自動化博客發佈工具,用過的人都說好(掘金篇)

「Pygors跨平臺GUI」2：安裝MinGW-w64、MSYS2還是WSL2

[轉帖]

python列出centos7內存使用前50的進程信息

「Pygors跨平臺GUI」1：Pygors跨平臺GUI應用研究

Java ThreadPoolShutdown

“她”來了，陪伴賽道鉅變！爲GPT-4o加上你的一個數字分身

京東秒送售後系統退款業務重構心得| 京東零售技術團隊

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以太網驅動總結