效能 - Amazon EKS
應用程式擴展和效能

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

效能

應用程式擴展和效能

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

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

減少容器映像大小

  • 在啟動期間減少容器映像的大小是使映像變小的另一種方式。您可以在容器映像建置程序的每個步驟進行減少。若要開始，請選擇包含所需最少數量相依性的基礎映像。在映像建置期間，僅包含必要的基本程式庫和成品。建置映像時，請嘗試合併多個 RUN 或 COPY 命令，以建立較少數量的較大層。建置較小的映像具有下列優缺點：

  • 專業人員：

    • 影像提取速度更快，整體而言需要的儲存空間較少。

    • 較小的影像具有較少的攻擊向量。

  • Cons：

    • 隨著容器映像的簡化，您將需要建立多個映像，以滿足在不同環境中執行的需求。

    • 結合命令來節省大小有時可忽略，因此您應該測試不同的建置方法，以查看什麼能帶來最佳結果。對於 AI/ML 架構，請選取僅限執行時間映像 （例如 3pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime.03 GB 和 6.66 GB 的 Devel) 等變體，但由於較小的映像，基準工作負載可能會略過 JIT 編譯，導致程式碼路徑變慢。使用多階段組建來分隔組建和執行時間，僅複製必要的成品 （例如，透過 COPY —from= 用於登錄檔或本機內容）。在組裝階段中結合 COPY 來使用層最佳化，減少層數，但可降低快取效率並延長建置時間。

在 部署中處理 ML 模型成品

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

將模型複製到容器映像 在映像建置期間將模型檔案 （例如 .safetensors、.pth、.h5) 複製到容器映像 （例如 Dockerfile)。模型是不可變影像的一部分。我們建議針對不常更新的小型模型使用此方法。

  • 優點：確保一致性和可重現性、沒有載入延遲，簡化相依性管理。

  • Cons：導致影像大小變大、建置和推送速度變慢、需要重建和重新部署模型更新，由於登錄提取輸送量，因此不適合大型模型。此外，由於設定更複雜，這可能會導致實驗、偵錯和測試的回饋迴圈更長，如果在不同映像之間共置，可能會增加儲存成本。

在容器啟動時下載模型 在容器啟動時，應用程式會透過啟動容器或進入點中的指令碼，從外部儲存體 （例如，由 S3 CRT 支援的 Amazon S3，以使用 Mountpoint for S3 CSI 驅動程式、AWS S3 CLI 或 s5cmd OSS CLI 等方法進行最佳化的高輸送量傳輸） 下載模型。對於經常更新的大型模型，我們建議您從此方法開始。

  • 優點：保持容器映像專注於程式碼/執行時間，無需重建即可輕鬆進行模型更新，支援透過儲存中繼資料進行版本控制。它還允許在不增加容器映像大小的情況下進行 A/B 測試、熱交換或復原模型，並提供在不同應用程式之間共用模型的能力，而無需將其封裝到所有容器映像中。此外，它會對 ML 或應用程式團隊的工作流程引入最少的變更，並啟用更快速的容器建置，以協助實驗和測試。使用 AWS CLI、s5cmd 或掛載點 S3 CSI 驅動程式等 S3 CRT 支援的工具，可以大幅降低大型檔案的下載延遲並改善效能，相較於從 ECR 等登錄檔提取大型封裝容器映像，通常可縮短整體 Pod 啟動時間。

  • Cons：引入潛在的網路故障 （需要重試邏輯），它需要身分驗證和快取。處理下載程序會產生額外的操作複雜性，包括重試、錯誤處理和退避，以及複寫 ECR 功能的額外儲存和清除管理。

透過持久性磁碟區掛載模型 將模型存放在外部儲存體 （例如 Amazon EFS、EBS、FSx for NetApp ONTAP、FSx for Lustre、FSx for OpenZFS 或 S3 透過掛載點 S3 CSI 驅動程式），並將其掛載為 Kubernetes PersistentVolume (PV)。這些是在模型訓練程序期間產生的檔案和資料，允許其進行預測或推論。我們建議針對跨 Pod 或叢集的共用模型使用此方法。

  • 優點：將模型與映像分離以進行共用存取、促進更新而不重新啟動 （如果您的架構支援）、有效率地處理大型資料集。它還透過複製、共用和快照等功能啟用 Kubernetes 驅動的佈建和存取控制，減少複製模型和建立新操作的需求。模型的 POSIX 型存取控制是可行的，而且能夠與應用程式分開更新模型版本，而無需重建容器映像，以及更快的容器建置以進行實驗和測試。對於將成品讀取到記憶體的 AI/ML 推論應用程式，這允許直接從外部檔案系統載入資料，而不需要將其儲存在節點本機磁碟的中繼位置，從而提高載入效能。此外，為了大規模儲存大型模型，FSx for NetApp ONTAP、FSx for Lustre 等服務提供儲存最佳化技術 （例如重複資料刪除、壓縮、精簡佈建）、透過快照進行版本控制，以及支援重複使用相同的檔案，而不會浪費儲存空間。其他服務，例如 S3，提供原生版本控制。根據複寫組態 （例如，FSx 中的非同步複寫或 S3 和 EFS 中的跨區域複寫），此方法也可以跨叢集和潛在區域進行。

  • Cons：如果連接網路、需要儲存佈建和存取控制，則可能會新增 I/O 延遲，如果儲存是叢集特定的，則可能較不方便攜帶 （例如 EBS)。權衡包括 CI/CD 變更和維護載入器程序的額外操作複雜性、需要自訂 TTL/保留機制來降低儲存成本，以及更複雜的跨區域複寫。模型成品的讀取效能應根據容器映像下載時間進行測量。

提供 ML 模型

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

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

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

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

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

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

  • Pros：提供批次處理 （靜態/傳輸中或連續）、量化 (INT8、FP8、GPTQ)、硬體最佳化 (NVIDIA、AMD、Intel、Inferentia) 和多 GPU 支援 (Tensor/Pipeline 平行處理）。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 啟動至關重要，我們建議預先載入容器映像，以將初始化延遲降至最低。從最低到最高建議考慮以下方法：

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

  • 您可以使用 Kubernetes 資源 （例如 DaemonSet 或 Deployment) 將容器映像預先提取至節點，以填入節點的容器執行期快取。容器執行期快取是由容器執行期 （例如 【containerd】(https://containerd.io/)) 管理的本機儲存體，其中映像會在從登錄檔提取之後存放。預先提取可確保映像可在本機使用，避免在 Pod 啟動期間發生下載延遲。當 EBS 快照未預先設定或偏好映像預先提取時，此方法非常有用。如需預先提取映像的範例，請參閱 【AWS 範例 GitHub 儲存庫】(https://github.com/aws-samples/aws-do-eks/tree/main/Container-Root/eks/deployment/prepull：//)。請注意，使用 【SOCI Snapshotter】(https://github.com/awslabs/soci-snapshotter：//) （用於部分映像提取的容器化外掛程式） 延遲載入等替代方法可以補充這些方法，雖然它需要自訂設定，並且可能不適用於所有案例。使用容器執行期快取隨附下列優缺點：

  • 專業人員：

    • 不需要管理 EBS 快照。

    • 使用 DaemonSets，您一律會取得最新的容器映像版本。

    • 更靈活，因為映像無需重新建立快照即可更新。

    • 確保映像已在節點上，仍可縮短 Pod 啟動時間。

  • Cons：

    • 大型影像的初始提取仍然需要一些時間，但會提前完成。

    • 可能不像超大型映像 （超過 10 GB) 的 EBS 快照那麼有效率，因為仍然需要提取，雖然不是在 Pod 啟動時。

    • 使用 DaemonSets，映像會預先提取至 Pod 可能執行的所有節點。例如，如果 1000 個節點只執行一個 Pod 的執行個體，則所有 1000 個節點的空間只會用來在一個節點上執行一個執行個體。

    • 對於節點向內/向外擴展的即時推論工作負載，Cluster Autoscaler 等工具新增的新節點可能會在預先提取 DaemonSet 完成映像提取之前排程工作負載 Pod。這可能會導致新節點上的初始 Pod 觸發提取，進而可能延遲啟動並影響低延遲需求。

    • Kubelet 映像垃圾收集可以透過在磁碟用量超過特定閾值或超過設定的最長未使用存留期時移除未使用的映像，來影響預先提取的映像。在向內擴展/向外擴展模式中，這可能會在閒置節點上移出映像，這需要在後續擴展期間重新提取，並降低高載工作負載快取的可靠性。

使用 EBS 快照

  • 您可以拍攝快取容器映像的 Amazon Elastic Block Store (EBS) 快照，並為 EKS 工作者節點重複使用此快照。這可確保在節點啟動時在本機預先擷取映像，從而縮短 Pod 初始化時間。如需使用 Karpenter 和受管節點群組的此 EKS Terraform 藍圖的詳細資訊，請參閱使用 Bottlerocket 資料磁碟區縮短 Amazon EKS 上的容器啟動時間。 https://aws-ia.github.io/terraform-aws-eks-blueprints/patterns/machine-learning/ml-container-cache/我們建議您將建立 EBS 快照自動化為 CI/CD 管道的一部分，讓快照與最新的容器映像版本保持up-to-date狀態。使用 EBS 快照隨附下列優缺點：

  • 專業人員：

    • 無需在 Pod 啟動時提取大型容器映像，可大幅縮短啟動時間 （例如，對於大於 10 GB 的映像，從 10 到 15 分鐘到 秒）。

    • 確保映像在節點啟動時可在本機使用。

    • 特別有利於具有大型容器映像的推論工作負載。

  • Cons：

    • 需要在每次映像或版本升級時維護和更新 EBS 快照。

    • 需要額外的步驟，以確保您的所有工作負載都使用最新的容器映像版本。

    • 涉及其他操作活動來建立和管理快照。

    • 如果未正確管理，則可能包含不必要的映像，但可以使用適當的節點集區組態來緩解這種情況。

最佳化映像提取效能

我們強烈建議為執行 AI/ML 工作負載的 Amazon EKS 叢集最佳化容器映像提取效能。使用大型、未最佳化的基礎映像或低效率層排序可能會導致 Pod 啟動時間變慢、資源消耗增加，以及推論延遲降低。為了解決這個問題，請採用小型、輕量的基礎映像，並將相依性降至最低，專為您的工作負載量身打造。您也可以考慮 AWS Deep Learning Containers (DLCs)，這是預先建置的容器映像，可讓您更輕鬆地執行熱門的深度學習架構 （例如 PyTorch 和 TensorFlow)。若要進一步了解如何建置自訂映像，請參閱自訂深度學習容器。建置自訂映像時，請考慮輕量型基礎映像，並僅新增必要的程式庫以保持映像乾淨。使用多階段組建來減少圖層大小，並最佳化圖層排序以實現高效快取。如需詳細資訊，請參閱建置映像的 Docker 最佳實務。

將容器映像預先載入資料磁碟區，以減少容器啟動時間

對於需要低 Pod 啟動延遲的機器學習工作負載，例如即時推論，我們建議預先載入容器映像，以將初始化延遲降至最低。大型容器映像可能會減慢 Pod 啟動速度，尤其是在頻寬有限的節點上。除了使用最少的基礎映像、多階段建置和延遲載入技術之外，請考慮下列方法在 Amazon EKS 中預先載入映像。除了使用基本影像、多階段建置和延遲載入技術之外，請考慮下列選項：