前面文章介紹微軟 Teams 會議系統、微信軟體與騰訊 PCG 服務三個 Triton 推理伺服器的成功案例，讓大家對 Triton 有初步的認知，但别誤以為這個軟體隻适合在大型的服務類應用中使用，事實上 Triton 能适用于更廣泛的推理環節中，并且在越複雜的應用環境中就越能展現其執行成效。
在說明 Triton 推理伺服器的架構與功能之前，我們需要先了解一個推理伺服器所需要面對并解決的問題。
與大部分的伺服器軟體所需要的基本功能類似，一個推理伺服器也得接受來自不同使用者端所提出的各種要求（request）然後做出回應（response），并且對系統的處理進行性能優化與穩定性管理。
但是推理計算需要面對深度學習領域的各式各樣推理模型，包括圖像分類、物件檢測、語義分析、語音識别等不同應用類别，每種類别還有不同神經網絡算法與不同架構所訓練出來的模型格式等。此外，我們不能對任務進行單純的串行隊列（queue）方式處理，這會使得任務等待時間拖得很長，影響使用的體驗感，是以必須對任務進行并行化處理，這裡就存在非常複雜的任務管理技巧。
下面列出一個推理伺服器所需要面對的技術問題：
1. 支援多種模型格式：至少需要支援普及度最高的
2. TensorFlow 的 GraphDef 與 SavedMode 中一種以上格式
(1) PyTorch 的 TorchScript 格式
(2) ONNX 開放标準格式
(3) 其他：包括自定義模型格式
3. 支援多種查詢類型，包括
(1) 線上的實時查詢：盡量降低查詢的延遲（latency）時間
(2) 離線的批量處理：盡量提高查詢的通量（throughput）
(3) 流水線傳輸的識别号管理等工作
4. 支援多種部署方式：包括
(1) 企業的 GPU 或 CPU 計算裝置
(2) 公共雲或資料中心
5. 對模型進行最佳縮放處理：讓個别模型提供更好的性能
6. 優化多個 KPI：包括
(1) 硬體使用率
(2) 模型推理識别時間
(3) 總體成本（TCO）
7. 提高系統穩定性：需監控模型狀态并解決問題以防止停機
在了解推理伺服器所需要解決的關鍵問題之後，接着來看看下方的 Triton 系統高階架構圖，就能更清楚每個闆塊所負責的任務與使用的對應技術。
Triton 推理伺服器采用屬于 “主從（client-server）” 架構的系統，由圖中的四個闆塊所組成：
1. 模型倉（Model Repostory）：存放 Triton 伺服器所要使用的模型檔案與配置檔案的儲存設備，可以是本地伺服器的檔案系統，也可以使用 Google、AWS、Azure 等雲存儲空間，隻要遵循 Triton 伺服器所要求的規範就可以；
2. 用戶端應用（Client Application）：基于 Triton 使用者端 Python / C++ / Java 庫所撰寫，可以在各種作業系統與 CPU 架構上操作，對 Triton 伺服器送出任務請求，并且接受傳回的計算結果。這是整個 Triton 推理應用中代碼量最多的一部分，也是開發人員需要花費最多心思的部分，在後面會有專文講解。
3. HTTP / gPRC 通訊協定：作為使用者端與服務端互動的通訊協定，開發人員可以根據實際狀況選擇其中一種通訊協定進行操作，能透過網際網路對伺服器提出推理請求并傳回推理結果，如下圖所示：
使用這類通訊協定有以下優點：
(1) 支援實時、批處理和流式推理查詢，以獲得最佳應用程式體驗
(2) 提供高吞吐量推理，同時使用動态批處理和并發模型執行來滿足緊張的延遲預算
(3) 模型可以在現場制作中更新，而不會中斷應用程式
4. 推理伺服器（Inference Server）：這是整個 Triton 伺服器最核心且最複雜的部分，特别在 “性能”、“穩定”、“擴充” 這三大要求之間取得平衡的管理，主要包括以下幾大功能闆塊：
(1) C 開發接口：
在伺服器内的代碼屬于系統底層機制，主要由 NVIDIA 系統工程師進行維護，是以隻提供性能較好的 C 開發接口，一般應用工程師可以忽略這部分，除非您有心深入 Triton 系統底層進行改寫。
(2) 模型管理器（Model Management）：
支援多架構的檔案格式并提供自定義的擴充能力，目前已支援 TensorFlow 的 GraphDef 與 SavedModel 格式、ONNX、PyTorch TorchScript、TensorRT、用于基于樹的 RAPIDS FIL 模型、OpenVINO 等模型檔案格式，還能使用自定義的 Python / C++ 模型格式；
(3) 模型的推理隊列排程器（Per-Model Scheduler Queues）：
将推理模型用管道形式進行管理，将一個或多個模型的預處理或後處理進行邏輯排列，并管理模型之間的輸入和輸出張量的連接配接，任何的推理請求都會觸發這個模型管道。這部分還包含以下兩個重點：
- 并發模型執行（Concurrent Model Execution）：允許同一模型的多個模型和 / 或多個執行個體在同一系統上并行執行，系統可能有零個、一個或多個 GPU。
- 模型和排程程式（Models And Schedulers）：支援多種排程和批量處理算法，可為每個模型單獨選擇無狀态（stateless）、有狀态（stateful）或內建（ensemble）模式。對于給定的模型，排程器的選擇和配置是通過模型的配置檔案完成的。
(4) 計算資源的優化處理：
這是作為伺服器軟體的最重要工作之一，就是要将裝置的計算資源充分排程，并且優化總體計算性能，主要使用以下三種技術。
- 支援異構計算模式：可部署在純 x86 與 ARM CPU 的計算裝置上，也支援裝載 NVIDIA GPU 的計算裝置。
- 動态批量處理（Dynamic batching）技術：對支援批處理的模型提供多個内置的排程和批處理算法，并結合各個推理請求以提高推理吞吐量，這些排程和批量處理決策對請求推理的用戶端是透明的。
- 批量處理推理請求分為用戶端批量處理和伺服器批量處理兩種，通過将單個推理請求組合在一起來實作伺服器批處理，以提高推理吞吐量；
- 建構一個批量處理緩存區，當達到配置的延遲門檻值後便啟動處理機制；
- 排程和批處理決策對請求推斷的客戶機是透明的，并且根據模型進行配置。
c. 并發模型（Concurrent model）運作：多個模型或同一模型的多個執行個體，可以同時在一個 GPU 或多個 GPU 上運作，以滿足不同的模型管理需求。
(5) 架構後端管理器（Framework Backends）：
Triton 的後端就是執行模型的封裝代碼，每種支援的架構都有一個對應的後端作為支援，例如 tensorrt_backend 就是支援 TensorRT 模型推理所封裝的後端、openvino_backend 就是支援 openvine 模型推理所封裝的後端，目前在 Triton 開源項目裡已經提供大約 15 種後端，技術人員可以根據開發無限擴充。
要添加一個新的背景是相當複雜的過程，是以在本系列文章中并不探索，這裡主要說明以下 Triton 伺服器對各個後端的管理機制，主要是以下重點：
- 采用 KFServing 的新社群标準 gRPC 和 HTTP/REST 資料平面（data plane）v2 協定（如下圖），這是 Kubernetes 上基于各種标準的無伺服器推理架構
- 通過配置自動化和自動擴充簡化 Kubernetes 中的推理服務部署
- 透明地處理負載峰值，即使請求數量顯著增加，請求的服務也将繼續順利運作
- 可以通過定義轉換器，輕松地将标記化和後處理等預處理步驟包含在部署中
- 可以用 NGC 的 Helm 指令在 Kubernetes 中部署 Triton，也可以部署為容器微服務，為 GPU 和 CPU 上的預處理或後處理和深度學習模型提供服務，也能輕松部署在資料中心或雲平台上
- 将推理執行個體進行微服務處理，每個執行個體都可以在 Kubernetes 環境中獨立擴充，以獲得最佳性能
- 通過這種新的內建，可以輕松地在 Kubernetes 使用 Triton 部署高性能推理
以上是 Triton 推理伺服器的進階架構與主要特性的簡介，如果看完本文後仍感覺有許多不太了解的部分，這是正常的現象，因為整個 Triton 系統內建非常多最先進的技術在内，并非朝夕之間就能掌握的。
後面的内容就要進入 Triton 推理伺服器的環境安裝與調試，以及一些基礎範例的執行環節，透過這些實際的操作，逐漸體驗 Triton 系統的強大。