久久国产精品99精品国产,国产精品欧美一区二区三区不卡,国产精品99久久不卡波多野结衣

在上篇文章中，已經說明了有狀態（stateful）模型的“控制輸入”與“隱式狀態管理”的使用方式，本文內容接著就繼續說明“調度策略”的使用。（續前一篇文章的編號） (3) 調度策略（Scheduling Strategies）在決定如何對分發到同一模型實例的序列進行批處理時，序列批量處理器（sequence batcher）可以采用以下兩種調度策略的其中一種：

直接（direct）策略

當模型維護每個批量處理槽的狀態，并期望給定序列的所有推理請求都分發到同一槽，以便正確更新狀態時，需要使用這個策略。此時，序列批量處理程序不僅能確保序列中的所有推理請求，都會分發到同一模型實例，并且確保每個序列都被分發至模型實例中的專用批量處理槽（batch slot）。下面示例的模型配置，是一個 TensorRT 有狀態模型，使用直接調度策略的序量批處理程序的內容：

name: "direct_stateful_model"platform: "tensorrt_plan"max_batch_size: 2sequence_batching{ max_sequence_idle_microseconds: 5000000direct { } 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_FP32dims: [ 100, 100 ]}]output [{name: "OUTPUT" data_type: TYPE_FP32dims: [ 10 ]}]instance_group [{ count: 2}]

現在簡單說明以下配置的內容：

sequence_batching 部分指示模型會使用序列調度器的 Direct 調度策略；
示例中模型只需要序列批處理程序的啟動和就緒控制輸入，因此只列出這些控制；
instance_group 表示應該實例化模型的兩個實例；
max_batch_size 表示這些實例中的每一個都應該執行批量大小為 2 的推理計算。

下圖顯示了此配置指定的序列批處理程序和推理資源的表示：

每個模型實例都在維護每個批處理槽的狀態，并期望將給定序列的所有推理請求分發到同一槽，以便正確更新狀態。對于本例，這意味著 Triton 可以同時 4 個序列進行推理。使用直接調度策略，序列批處理程序會執行以下動作：

所識別的推理請求種類	執行動作
需要啟動新序列	1. 有可用處理槽時：就為該序列分配批處理槽2. 無可用處理槽時：就將推理請求放在積壓工作中
是已分配處理槽序列的一部分	將該請求分發到該配置好的批量處理槽
是積壓工作中序列的一部分	將請求放入積壓工作中
是最后一個推理請求	1. 有積壓工作時：將處理槽分配給積壓工作的序列2. 有積壓工作：釋放該序列處理槽給其他序列使用

下圖顯示使用直接調度策略，將多個序列調度到模型實例上的執行：

圖左顯示了到達 Triton 的 5 個請求序列，每個序列可以由任意數量的推理請求組成。圖右側顯示了推理請求序列是如何隨時間安排到模型實例上的，

在實例 0 與實例 1 中各有兩個槽 0 與槽 1；
根據接收的順序，為序列 0 至序列 3 各分配一個批量處理槽，而序列 4 與序列 5 先處于排隊等候狀態；
當序列 3 的請求全部完成之后，將處理槽釋放出來給序列 4 使用；
當序列 1 的請求全部完成之后，將處理槽釋放出來給序列 5 使用；

以上是直接策略對最基本工作原理，很容易理解。接下來要進一步使用控制輸入張量與模型通信的功能，下圖是一個分配給模型實例中兩個批處理槽的兩個序列，每個序列的推理請求隨時間而到達，START 和 READY 顯示用于模型每次執行的輸入張量值：

?隨著時間的推移（從右向左），會發生以下情況：

序列中第一個請求（Req 0）到達槽 0 時，因為模型實例尚未執行推理，則序列調度器會立即安排模型實例執行，因為推理請求可用；
由于這是序列中的第一個請求，因此 START 張量中的對應元素設置為 1，但槽 1 中沒有可用的請求，因此 READY 張量僅顯示槽 0 為就緒。
推理完成后，序列調度器會發現任何批處理槽中都沒有可用的請求，因此模型實例處于空閑狀態。
接下來，兩個推理請求（上面的 Req 1 與下面的 Req 0）差不多的時間到達，序列調度器看到兩個處理槽都是可用，就立即執行批量大小為 2 的推理模型實例，使用 READY 顯示兩個槽都有可用的推理請求，但只有槽 1 是新序列的開始（START）。
對于其他推理請求，處理以類似的方式繼續。

以上就是配合控制輸入張量的工作原理。

最舊的（oldest）策略

這種調度策略能讓序列批處理器，確保序列中的所有推理請求都被分發到同一模型實例中，然后使用“動態批處理器”將來自不同序列的多個推理批量處理到一起。使用此策略，模型通常必須使用 CONTROL_SEQUENCE_CORRID 控件，才能讓批量處理清楚每個推理請求是屬于哪個序列。通常不需要 CONTROL_SEQUENCE_READY 控件，因為批處理中所有的推理都將隨時準備好進行推理。下面是一個“最舊調度策略”的配置示例，以前面一個“直接調度策略”進行修改，差異之處只有下面所列出的部分，請自行調整：

直接（direct）策略

最舊的（oldest）策略

direct {}

oldest

{

max_candidate_sequences: 4

}

在本示例中，模型需要序列批量處理的開始、結束和相關 ID 控制輸入。下圖顯示了此配置指定的序列批處理程序和推理資源的表示。

使用最舊的調度策略，序列批處理程序會執行以下工作：

所識別的推理請求種類	執行動作
需要啟動新序列	嘗試查找具有候選序列空間的模型實例，如果沒有實例可以容納新的候選序列，就將請求放在一個積壓工作中
已經是候選序列的一部分	將該請求分發到該模型實例
是積壓工作中序列的一部分	將請求放入積壓工作中
是最后一個推理請求	模型實例立即從積壓工作中刪除一個序列，并將其作為模型實例中的候選序列，或者記錄如果沒有積壓工作，模型實例可以處理未來的序列。

下圖顯示將多個序列調度到上述示例配置指定的模型實例上，左圖顯示 Triton 接收了四個請求序列，每個序列由多個推理請求組成：

這里假設每個請求的長度是相同的，那么左邊候選序列中送進右邊批量處理槽的順序，就是上圖中間的排列順序。最舊的策略從最舊的請求中形成一個動態批處理，但在一個批處理中從不包含來自給定序列的多個請求，例如上面序列 D 中的最后兩個推理不是一起批處理的。以上是關于有狀態模型的“調度策略”主要內容，剩下的“集成模型”部分，會在下篇文章中提供完整的說明。

原文標題：NVIDIA Triton 系列文章（11）：模型類別與調度器-2

文章出處：【微信公眾號：NVIDIA英偉達企業解決方案】歡迎添加關注！文章轉載請注明出處。

聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容侵權或者其他違規問題，請聯系本站處理。舉報投訴