應用程式擴展和效能 - Amazon EKS
管理 ML 成品、服務架構和啟動最佳化預先快取容器映像將 NVMe 用於 kubelet 和容器儲存

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

應用程式擴展和效能

管理 ML 成品、服務架構和啟動最佳化

在 Amazon EKS 上部署機器學習 (ML) 模型需要考慮模型如何整合到容器映像和執行期環境。這可確保可擴展性、可重複性和高效的資源使用率。本主題說明處理 ML 模型成品、選取服務架構，以及透過預先快取等技術最佳化容器啟動時間的不同方法，所有方法都專為縮短容器啟動時間而量身打造。

減少容器映像大小

在啟動期間減少容器映像的大小是使映像變小的另一種方式。您可以在容器映像建置程序的每個步驟進行減少。若要開始，請選擇包含所需最少數量相依性的基礎映像。在映像建置期間，僅包含必要的基本程式庫和成品。建置映像時，請嘗試結合多個 RUN或 COPY命令來建立較少數量的較大層。對於 AI/ML 架構，請使用多階段建置來分隔建置和執行時間、僅複製必要的成品 （例如，透過 COPY —from=用於登錄檔或本機內容），以及選取變體，例如僅限執行時間的影像 （例如，pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime3.03 GB 與 6.66 GB 的 Devel)。若要進一步了解，請參閱《AI on EKS 研討會》中的減少容器映像大小。

在 部署中處理 ML 模型成品

關鍵決策是如何處理 ML 模型成品 （例如權重和組態）。選擇會影響影像大小、部署速度、模型更新頻率和操作額外負荷。請注意，當參考儲存「模型」時，我們指的是模型成品 （例如訓練過的參數和模型權重）。有不同的方法來處理 Amazon EKS 上的 ML 模型成品。每個 都有其權衡，最佳權衡取決於模型的大小、更新節奏和基礎設施需求。從最低到最高建議考慮以下方法：

  • 將模型製作到容器映像中：在映像建置期間，將模型檔案 （例如 .safetensors、.pth、.h5) 複製到容器映像 （例如 Dockerfile)。模型是不可變影像的一部分。對於不常更新的小型模型，我們建議使用此方法。這可確保一致性和可重現性、提供無載入延遲，並簡化相依性管理，但會導致更大的映像大小、降低建置和推送速度、需要重建和重新部署模型更新，而且由於登錄提取輸送量，不適合大型模型。

  • 在執行時間下載模型：在容器啟動時，應用程式會透過初始化容器或進入點中的指令碼，從外部儲存體 （例如，由 S3 CRT 支援的 Amazon S3，以最佳化高輸送量傳輸，使用 Mountpoint for S3 CSI 驅動程式、AWS S3 CLI 或 s5cmd OSS CLI) 下載模型。對於經常更新的大型模型，我們建議您從此方法開始。這可讓容器映像專注於程式碼/執行時間、無需重建即可輕鬆進行模型更新、支援透過儲存中繼資料進行版本控制，但會導致潛在的網路故障 （需要重試邏輯）、需要身分驗證和快取。

若要進一步了解，請參閱 AI on EKS 研討會中的加速提取程序。

提供 ML 模型

在 Amazon EKS 上部署和提供機器學習 (ML) 模型需要選擇適當的模型服務方法，以最佳化延遲、輸送量、可擴展性和操作簡單性。選擇取決於您的模型類型 （例如語言、視覺模型）、工作負載需求 （例如即時推論） 和團隊專業知識。常見的方法包括用於原型建構的 Python 型設定、用於生產級功能的專用模型伺服器，以及用於高效能和效率的專用推論引擎。每個方法都涉及設定複雜性、效能和資源使用率的權衡。請注意，由於相依性，服務架構可能會增加容器映像大小 （多個 GBs)，這可能會影響啟動時間，請考慮使用成品處理技術進行解耦來緩解這種情況。選項從最低到最高建議列出：

使用 Python 架構 （例如 FastAPI、HuggingFace 轉換器與 PyTorch) 在容器化節點設定中，使用 Python 架構、內嵌模型檔案 （權重、組態、權杖化工具） 開發自訂應用程式。

  • Pros：易於原型設計，僅 Python，無需額外的基礎設施，相容於所有 HuggingFace 模型，簡單的 Kubernetes 部署。

  • Cons：限制為單一請求/簡單批次處理、權杖產生緩慢 （沒有最佳化的核心）、記憶體效率低下、缺少擴展/監控，以及涉及較長的啟動時間。

  • 建議：用於需要自訂邏輯整合的初始原型或單一節點任務。

使用專用模型服務架構 （例如 TensorRT-LLM、TGI) 採用 TensorRT-LLM 或 TGI 等特殊伺服器進行 ML 推論、管理模型載入、路由和最佳化。這些支援安全張量等格式，具有選用的編譯或外掛程式。

  • 優點：提供批次處理 （靜態/傳輸中或連續）、量化 (INT8、FP8、GPTQ)、硬體最佳化 (NVIDIA、AMD、Intel、Inferentia) 和多 GPU 支援 （張量/管道平行處理）。TensorRT-LLM 支援各種模型 (LLMs、Encoder-Decoder)，而 TGI 則利用 HuggingFace 整合。

  • Cons：TensorRT-LLM 需要編譯且僅限 NVIDIA；TGI 的批次處理效率可能較低；兩者都會增加組態額外負荷，而且可能不符合所有模型類型 （例如非轉換器）。

  • 建議：適用於需要生產功能的 PyTorch/TensorFlow 模型，例如 A/B 測試或具有相容硬體的高輸送量。

使用專門的高輸送量推論引擎 （例如 vLLM) 利用 vLLM 等進階推論引擎、使用 PagedAttention 最佳化 LLM 服務、傳輸中批次處理和量化 (INT8、FP8-KV、AWQ)，可與 EKS Autoscaling 整合。

  • 優點：高輸送量和記憶體效率 （節省 40-60% VRAM)、動態請求處理、字符串流、單節點 Tensor 平行多 GPU 支援，以及廣泛的硬體相容性。

  • Cons：針對僅限解碼器的轉換器 （例如 LLaMA) 最佳化，對於非轉換器模型效率較低，需要相容的硬體 （例如 NVIDIA GPUs) 和設定工作。

  • 建議：EKS 上大量、低延遲 LLM 推論的首選，可最大化可擴展性和效能。

預先快取容器映像

大型容器映像 （例如包含 PyTorch 等模型的映像） 可能會導致冷啟動延遲，進而影響延遲。對於延遲敏感工作負載，例如水平擴展的即時推論工作負載和快速 Pod 啟動至關重要，我們建議預先載入容器映像，以將初始化延遲降至最低。從最低到最高建議考慮以下方法：

使用 SOCI 快照器預先提取影像

對於您無法輕鬆最小化的超大型映像，您可以使用在平行提取和解壓縮模式中設定的開放原始碼 Seekable OCI (SOCI) 快照器。此解決方案可讓您使用現有的映像，而無需重建或修改建置管道。此選項在將具有非常大型映像的工作負載部署到高效能 EC2 運算執行個體時特別有效。它適用於高輸送量聯網和高效能儲存組態，如同擴展 AI/ML 工作負載一般。

SOCI 平行提取/解壓縮模式透過可設定的平行化策略改善end-to-end映像提取效能。更快的映像提取和準備會直接影響部署新工作負載和有效率地擴展叢集的速度。影像提取有兩個主要階段：

1。從登錄檔擷取層到節點

對於圖層擷取最佳化，SOCI 會為每個圖層建立多個並行 HTTP 連線，將下載輸送量乘以超過單一連線限制。它會將大型分層分割為區塊，並在多個連線中同時下載它們。此方法有助於飽和您的可用網路頻寬，並大幅縮短下載時間。這對 AI/ML 工作負載來說特別重要，其中單一 layer 可以是數 GB。

2. 解壓縮和準備這些層以建立容器

為了進行 layer unpacking 最佳化，SOCI 會同時處理多個 layer。它會使用您可用的 CPU 核心來同時解壓縮和擷取多個層，而不是等待每個層完全解壓縮，再開始下一個層。此平行處理會將傳統 I/O 繫結的解壓縮階段轉換為 CPU 最佳化操作，以隨您可用的核心進行擴展。系統會仔細協調此平行化，以維持檔案系統一致性，同時最大化輸送量。

SOCI 平行提取模式使用雙閾值控制系統搭配可設定的參數，用於下載並行和解壓縮平行處理。此精細控制可讓您微調 SOCI 的行為，以符合您的特定效能需求和環境條件。了解這些參數可協助您最佳化執行時間，以獲得最佳提取效能。

參考

使用 EBS 快照預先提取映像

您可以拍攝快取容器映像的 Amazon Elastic Block Store (EBS) 快照，並為 EKS 工作者節點重複使用此快照。這可確保在節點啟動時在本機預先擷取映像，從而縮短 Pod 初始化時間。如需針對受管節點群組使用 Karpenter 和 EKS Terraform 藍圖的詳細資訊，請參閱使用 Bottlerocket 資料磁碟區縮短 Amazon EKS 上的容器啟動時間。

若要進一步了解，請參閱 AI on EKS 研討會中的使用容器化快照器和將容器映像預先載入 Bottlerocket 資料磁碟區與 EBS 快照。 https://awslabs.github.io/ai-on-eks/docs/guidance/container-startup-time/accelerate-pull-process/prefecthing-images-on-br

使用容器執行期快取來預先提取映像

您可以使用 Kubernetes 資源 （例如 DaemonSet 或 Deployment) 將容器映像預先提取至節點，以填入節點的容器執行期快取。容器執行期快取是由容器執行期管理的本機儲存體 （例如，從登錄檔提取影像後存放影像的容器。 預先提取可確保映像可在本機使用，避免在 Pod 啟動期間發生下載延遲。 當映像經常變更 （例如頻繁更新）、EBS 快照未預先設定、建置 EBS 磁碟區比直接從容器登錄檔提取更耗時，或節點已在叢集中且需要使用多個可能映像之一隨需啟動 Pod 時，這種方法特別有用。

預先提取所有變體可確保快速啟動時間，無論需要哪個映像。例如，在需要 100，000 個使用 10 種不同技術建置之小型模型的大規模平行 ML 工作負載中，透過大型叢集 （例如數千個節點） 的 DaemonSet 預先提取 10 個映像，可將 Pod 啟動時間降至最低，避免隨需提取在 10 秒內完成。使用容器執行期快取方法不需要管理 EBS 快照， 可確保您一律使用 DaemonSets 取得最新的容器映像版本，但對於節點擴展/擴展的即時推論工作負載，Cluster Autoscaler 等工具新增的新節點可能會在預先提取 DaemonSet 完成映像提取之前排程工作負載 Pod。這可能會導致新節點上的初始 Pod 觸發提取，進而可能延遲啟動並影響低延遲需求。此外，當磁碟用量超過特定閾值，或超過設定的最長未使用存留期時，kubelet 映像廢棄收集可以透過移除未使用的映像來影響預先提取的映像。在向內擴展/向外擴展模式中，這可能會移出閒置節點上的映像，這需要在後續擴展期間重新提取，並降低高載工作負載的快取可靠性。

如需將映像預先提取至容器執行期快取的範例，請參閱 AWS GitHub 儲存庫。

將 NVMe 用於 kubelet 和容器儲存

請考慮設定 kubelet和 containerd 以使用暫時性 NVMe 執行個體儲存磁碟，以提高磁碟效能。容器提取程序涉及從登錄檔下載容器映像，並將其層解壓縮為可用的格式。若要在解壓縮期間最佳化 I/O 操作，您應該評估為容器主機執行個體類型提供更高水準的 I/O 效能和輸送量：具有本機儲存體的 NVMe 後端執行個體與 EBS 磁碟區 IOPS/輸送量。對於具有 NVMe 本機儲存的 EC2 執行個體，請考慮為 kubelet (/var/lib/kubelet)、 containerd (/var/lib/containerd) 和 Pod 日誌 (/var/log/pods) 設定節點的基礎檔案系統，以使用暫時性 NVMe 執行個體儲存磁碟以獲得更高層級的 I/O 效能和輸送量。

節點的暫時性儲存可以在請求暫時性儲存的 Pod 之間共用，以及請求下載到節點的容器映像。如果將 Karpenter 與 Bottlerocket 或 AL2023 EKS Optimized AMIs 搭配使用，這可以透過將 instanceStorePolicy 設定為 RAID0，或在 NodeConfig 中將 localStoragePolicy 設定為使用者資料的一部分，在 EC2NodeClass 中設定。