Stateful Models 學習筆記
在 Triton Architecture 的文檔中，有一個令我困惑了許久的 feature：Stateful Models。如果你也看不太懂的話，並且想知道或必須知道它是什么東西的話，不妨看看這一篇學習筆記，看看能不能對你有所幫助。下面是我的一點粗淺的理解，如果有錯誤，懇請您在評論區指出，謝謝~！
鏈接：https://github.com/triton-inference-server/server/blob/main/docs/architecture.md#stateful-models
概念辨析
在 Triton 中，什么是 Stateful Model 呢？
應用場景：“a stateful model does maintain state between inference requests.” 請求和請求之間，保存了一些狀態，所以你希望可以將一連串的請求 (sequence of requests) 發送給同一個模型實例，從而使得模型的狀態可以正確的更新。
如果你學習過一些循環神經網絡模型的話，你可能會說 RNN、LSTM 等模型就是 Stateful Model。沒有錯，這些模型確實是有狀態的，只不過在 Triton 的某些語境下，Stateful Model 指的是 Stateful Backend（比如上面的那句英語）。狀態都是由 Backend 來進行管理的，所以我認為不應該叫 Stateful Model，而應該叫做 Stateful Backend。
將 Stateful Model 叫做 Stateful Backend 是更加合適的，因為一個你不可能去直接導出一個模型，然后利用現有 pytorch backend，tensorflow backend 去用上這個特性。你要用這個特性，不能只靠導出 Model，你需要自己開發一個 Backend 才行。
具體來說，為了使用上 sequence batching，你期望可以從客戶端請求那里拿到是否開始、是否結束、一個 sequence id。對於這些信息，你需要在 Custom Backend 里面去獲取出來進行處理，現有提供的幾個常用的 Backend 並沒有這些功能哦。當然你可以使用 Triton Stateful Model 來用上這個 feature。但是呢，不管怎么說，Stateful Model 是和具體的業務強相關的，真正要將這個 feature 用起來，還得自己開發一個 Backend 才行，所以才會說我們應該叫它 Stateful Backend。
用戶的 Model 在這里扮演一個什么樣的角色呢？你可以理解這個 Model 的輸入需要狀態向量、數據向量。這些輸入的狀態向量由 Backend 進行保管，在 Backend 里面，你可以獲取到 Start、End、Ready 三種和 Batch Size 等大的一維向量；你也可以拿到一連串請求 (sequence of requests) 的 request id。
Control Inputs
Triton 有四種控制輸入：Start、End、Ready、Correlation ID。
文檔中提到：“The START tensor must be 1-dimensional with size equal to the batch-size.”，后面的 End 和 Ready 也是和 Batch Size 一樣大的一維向量。在 Triton 中，每個實例會開出和 max_batch_size 一樣多的 slot，所以 Start、End、Ready 的大小和 max_batch_size 一樣多，也和一個 model instance 上的 slot 一樣多。
三者的語義分別表示，在對應的 slot 上，是否有一個 request 開始了、結束了、准備好了。對於 Start 和 End，在客戶端做請求的時候，只需要設置 infer 接口中對應的選項即可；對於 Ready，由 Triton 來控制。
對於 Correlation ID，表示一連串請求的 id，這一連串的請求都使用這同一個 id，Backend 需要使用這個 id 來找到區分請求。
例子
以官方文檔的圖為例子。在 Backend 中，我們可以拿到 START 和 READY 兩個向量。
- Req0 來了，START 為 [1, 0]，表明 Slot0 的請求是一個開始，而 Slot1 不是；READY 為 [1, 0]，表明 Slot1 的請求已經准備好了，可以開始推理了。
- Idle。沒有請求，Instance0 休息。
- 第一個序列的 Req1 來了，第二個序列的 Req0 來了。此時 START 為 [0, 1]，表明 Slot0 的請求不是開始，而 Slot1 的請求是一個開始；READY 為 [1, 1] 表明兩個請求都已經准備好了，可以組成一個 Batch 做請求了。
- ...(后面的分析相同了，略)
調度策略
direct 策略就是，一個 slot 只處理來自同一個 sequence 的請求；oldest 策略將會從 oldest requests 中形成一個 batch，但是這個 batch 不會包含多余一個來自於同一個 sequence 的 request。對比一下就是，direct 每個 slot 的 請求都是來自同一個 sequence，oldest 每個 slot 的 請求來自不同的 sequence。
這里讓我產生困惑的一點是 slot 和 batch 的關系。要明白一點，slot 構成 batch！
Direct 策略
一個 sequence 的請求都由一個 slot 處理。一個 sequence 會占用一個 slot，如果所有的 slot 占滿了，那么接下來的 sequence 會進入 backlog 進行等待。這個方法的缺點很明顯，就是 sequence 會占用 slot，如果這個 sequence 一直不繼續請求，那么這個 slot 就會浪費了。
Oldest 策略
同一個 batch 的請求，都來自不同的 sequence。請求先發送到 Sequence Batcher 排隊，Sequence Batcher 負責將請求放入到 slot 中，Oldest 策略中，每個不同的 slot 處理不同的 sequence 的請求，即一個 batch 不會有來自相同 sequence 的請求。
