**協助改進此頁面** 

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 在 Amazon EKS 上執行 AI/ML 推論工作負載
<a name="ml-inference"></a>

**提示**  
 [註冊](https://events.eksworkshop.com/workshops/genai/)即將舉行的 Amazon EKS AI/ML 研討會。

推論是執行訓練 AI 模型的程序，以從輸入資料產生預測或輸出。這包括提供產生文字或程式碼的大型語言模型 (LLMs)、產生影像的擴散模型、用於語音合成和轉錄的語音模型，以及用於即時分析或生成的影片模型。Amazon EKS 提供可擴展的可攜式解決方案，可讓您使用 NVIDIA GPUs 或 AWS Trainium 加速器部署這些推論工作負載、動態擴展，以及與更廣泛的 Kubernetes 和工具和服務的 AWS 領域整合。

## 為什麼使用 Amazon EKS 進行推論
<a name="_why_use_amazon_eks_for_inference"></a>

Amazon EKS 結合了 Kubernetes 協同運作與 AWS 基礎設施，以解決大規模執行推論的主要挑戰：
+  **動態 GPU 擴展** — Karpenter 根據 Pod 資源請求隨需佈建適當大小的 GPU 執行個體，在閒置時從零擴展，並在流量增加時增加容量。這可避免過度佈建昂貴的 GPU 資源。
+  **快速冷啟動** — SOCI （可擴展的 OCI) 平行提取下載並同時解壓縮大型容器映像層，將映像提取時間從幾分鐘縮短到幾秒鐘。結合直接從 Amazon S3 到 GPU 記憶體的模型串流，Pod 可以在兩分鐘內開始提供服務。
+  **自動 GPU 故障復原** — EKS 節點監控代理程式會偵測 GPU 硬體故障，並觸發自動節點替換，將停機時間降至最低，無需手動介入。
+  **成本最佳化** – 具有隨需備用的 Spot 執行個體、適當大小的執行個體選擇，以及scale-to-zero的行為，可降低 GPU 成本。預留容量 ODCRs) 可為穩定狀態工作負載提供額外節省。
+  **開放標準和可攜性** — 使用 vLLM 或 SGLang 等開放原始碼模型伺服器，在標準 Kubernetes APIs （部署、服務、HPAs) 上執行推論工作負載，提供跨環境的可攜性。
+  **整合式監控**：來自 vLLM 或 SGLang 和 NVIDIA DCGM Exporter 的 Prometheus 指標可透過 Grafana 儀表板提供請求延遲、字符輸送量、GPU 使用率和記憶體用量的可見性。

## 詞彙表
<a name="_glossary"></a>

本節使用下列術語：
+  **推論** — 執行訓練模型以從輸入資料產生輸出 （文字、內嵌、分類） 的程序。
+  **模型伺服器** — 容器化服務，可將模型載入記憶體、接收推論請求，以及傳回預測。範例包括 [vLLM](https://docs.vllm.ai/en/latest/)、[SGLang](https://github.com/sgl-project/sglang)、[Triton 推論伺服器](https://github.com/triton-inference-server/server)和[文字產生推論 (TGI)](https://github.com/huggingface/text-generation-inference)。
+  **模型權重** — 訓練模型的學習參數，儲存為模型伺服器載入 GPU 記憶體的檔案 （通常為 SafeTensors 或 GGUF 格式）。
+  **加速**器 – 特殊硬體，例如 NVIDIA GPUs 或 AWS Trainium/Inferentia 晶片，可加速推論所需的矩陣操作。
+  **Tensor 平行處理** — 在相同節點上跨多個 GPUs 分割模型，以提供超過單一 GPU 記憶體的模型。
+  **KV 快取** — 記憶體緩衝區，可在文字產生期間存放先前計算的鍵值對，避免對每個新字符進行備援運算。

## Amazon EKS 上的推論如何運作
<a name="_how_inference_on_amazon_eks_works"></a>

在高層級上，在 Amazon EKS 上部署推論工作負載需要以下步驟：


| 步驟 | 說明 | 
| --- | --- | 
|  **設定叢集**  | 使用啟用 GPU 的節點、監控和儲存來建立 EKS 叢集。請參閱 AI/ML on EKS 文件中的[叢集設定](ml-cluster-setup.md)。 | 
|  **存放模型權重**  | 從模型登錄檔 （例如 Hugging Face) 下載模型權重，並將其存放在 Amazon S3 中，以便在冷啟動或擴展事件期間快速載入模型。 | 
|  **部署模型伺服器**  | 建立在 GPU 節點上執行模型伺服器的 Kubernetes 部署 （例如 vLLM)。模型伺服器會將權重從 S3 串流到 GPU 記憶體，並公開與 OpenAI 相容的 API。 | 
|  **公開推論端點**  | 建立 Kubernetes 服務以提供穩定的網路端點。使用連接埠轉送進行測試，或使用負載平衡器，例如生產流量的 AWS Application Load Balancer (ALB)。 | 
|  **監控和擴展**  | 使用 Prometheus 指標 （請求率、字符輸送量、延遲、KV 快取使用率） 來監控效能並設定自動擴展。 | 

## 推論效能指標
<a name="_inference_performance_metrics"></a>

了解推論效能需要跨延遲和輸送量追蹤指標：

 **延遲指標** 
+  **到第一個權杖的時間 (TTFT)** — 從請求到達到第一個產生的權杖的時間。對互動式應用程式至關重要。
+  **每個輸出字符的時間 (TPOT)** — 在第一個字符之後產生每個後續字符的平均時間。
+  **End-to-end請求延遲** — 從提交請求到完成完整回應的總時間。

 **輸送量指標** 
+  **每秒請求**數 — 所有複本每秒提供的推論請求總數。
+  **每秒輸出字符** — 字符產生率，以總輸出字符除以經過時間來衡量。
+  **GPU 使用率** — 主動用於推論的 GPU 運算週期百分比。
+  **KV 快取使用率** — 配置使用中 KV 快取記憶體的百分比，指出伺服器與容量的接近程度。

## 縮短冷啟動時間
<a name="_reducing_cold_start_time"></a>

大型推論容器 (8-15 GB) 和模型權重 (10-100\+ GB) 可能會導致 Pod 啟動緩慢。下列技術可將冷啟動延遲降至最低：
+  **SOCI 平行提取** — 同時下載和解壓縮容器映像層，而不是循序執行。根據預設，GPU 執行個體的 EKS 自動模式已啟用。
+  **從 S3 的模型串流** — [Run：ai Model Streamer](https://github.com/run-ai/runai-model-streamer) 等工具會將模型權重直接從 Amazon S3 串流到 GPU 記憶體，繞過本機磁碟並將載入時間從幾分鐘縮短到幾秒鐘。
+  **將映像儲存在 Amazon ECR** 中 — 透過 VPC 端點從區域 ECR 儲存庫提取可避免大型容器映像的網際網路延遲。
+  **執行個體存放區快取** — 具有本機 NVMe 磁碟的 G 系列執行個體可以快取容器層和模型成品，加速對相同節點的後續提取。

## 您將部署的內容
<a name="_what_youll_deploy"></a>

Load [& Serve 模型](ml-inference-load-serve-model.md)演練會引導您部署end-to-end推論應用程式：

1.  **下載模型權重** — Kubernetes 任務會從 Hugging Face 下載 Ministral-3-8B-Instruct 模型，並將其上傳至 S3 儲存貯體。

1.  **部署 vLLM** — 部署使用 Run：ai Model Streamer 執行 vLLM，將權重從 S3 直接串流到 GPU 記憶體，提供與 OpenAI 相容的 API。

1.  **使用 Grafana 進行監控** — ServiceMonitor 將 vLLM Prometheus 指標連接到即時儀表板的監控堆疊。

1.  **部署聊天前端** — Open WebUI 提供連線至 vLLM 端點的瀏覽器型聊天介面。

演練使用 [為 AI/ML 工作負載設定 Amazon EKS 叢集](ml-cluster-setup.md)區段中的叢集基礎設施，並使用 EKS Auto Mode 和自我管理 Karpenter 路徑。