View a markdown version of this page

聯網 - Amazon EKS
對於具有高節點間通訊的應用程式，請考慮較高的網路頻寬或彈性布料轉接器在大型 GPU 執行個體上規劃 IP 地址使用

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

聯網

提示

註冊即將舉行的 Amazon EKS AI/ML 研討會。

對於具有高節點間通訊的應用程式，請考慮較高的網路頻寬或彈性布料轉接器

對於 Amazon EKS 上具有高節點間通訊需求的分散式訓練工作負載，請考慮選取具有較高網路頻寬或 Elastic Fabric Adapter (EFA) 的執行個體。網路效能不足會造成資料傳輸的瓶頸，從而減緩分散式多 GPU 訓練等機器學習任務。請注意，推論工作負載通常不會有高節點間通訊。

確保您的容器映像包含 NCCL 和 aws-ofi-nccl 外掛程式 （這可讓 NCCL 透過 libfabric 使用 EFA)。視訓練架構的啟動器而定，也可能需要 MPI。

EFA 工作負載的節點佈建考量事項

佈建具備 EFA 功能的節點時，需要通訊的執行個體必須位於相同的可用區域 （硬性需求）。此外，AWS 建議在叢集置放群組中啟動所有啟用 EFA 的執行個體，以將它們之間的實體距離降至最低，從而為您提供最低的延遲。置放群組並非 EFA 運作的必要項目，但強烈建議您使用，以獲得最佳效能。

下列考量適用於 EKS 上任何以 EFA 為基礎的分散式訓練部署。以下我們將 Karpenter 註釋做為範例，但相同的考量也適用於受管和自我管理節點群組實作。

  • 釘選至 AZ。EFA 要求所有通訊節點都位於相同的可用區域中，因此，參與相同分散式訓練任務的節點不得分散到各個區域。您可以在 上使用 nodeSelector或 Pod 親和性，將 Pod 固定到 AZ 來強制執行此操作topology.kubernetes.io/zone。選取目標執行個體類型具有最佳可用性，或容量區塊預留位置的可用區域。請注意，雖然相同可用區共置可改善節點間延遲，但也會增加可用區域層級故障的爆量半徑。對於長時間執行的訓練工作負載，單一 AZ 中斷或容量事件可以清除累積的訓練進度時數，這是代價高昂的損失。將此納入檢查點策略和任務持續時間規劃。

  • 設定叢集置放群組 （建議）。在 EC2NodeClass 中指定置放群組。Karpenter 會自動佈建至其中。建議這樣做是為了獲得最佳延遲，但不需要嚴格地讓 EFA 運作。對於 ML 的容量區塊，置放會透過 UltraClusters 自動處理，不需要手動置放群組。請注意，在此情況下，AZ 已經鎖定，因此不需要額外的 Pod 層級或 NodePool 層級 AZ 限制。

  • 防止多節點訓練任務中斷。在訓練 Pod 上使用 PDBs 或karpenter.sh/do-not-disrupt: "true"註釋。如果沒有這種情況，Karpenter 的整合可能會嘗試在工作中取代或移動 EFA 工作負載，中斷整個分散式訓練執行。在 NodePool consolidationPolicy: WhenEmpty上設定 以防止佔用的節點整合。expireAfter 在此處檢閱這些標籤與 terminationGracePeriod和 之間的互動。

  • 設定適當的過期時間。在 NodePool expireAfter上將 設定為比最長訓練任務更長的值，或將其完全停用以進行訓練 NodePools。即將到期的節點訓練中期會終止任務。

  • 使用正確的 EFA 裝置外掛程式版本。EFA 裝置外掛程式公開vpc.amazonaws.com/efa為可排程的資源。

  • 設定安全群組。所有 EFA 執行個體都必須位於具有自我參考規則的相同安全群組中，允許所有進出本身的流量。如果沒有這樣做，EFA 流量會無提示地失敗。

了解 EFA 共同位置的 Spot 執行個體風險

Amazon EC2 Spot 執行個體可大幅節省訓練工作負載的成本 （如需 GPUs 的一般 Spot 最佳實務，請參閱本節)。不過，EFA 要求所有通訊節點都位於相同的可用區域，AWS 建議將這些節點放置在叢集置放群組中，以獲得最佳延遲。此主機代管帶來相互關聯的中斷風險：執行個體在相同可用區域內共用基礎實體基礎設施 （甚至在置放群組中），因此單一容量回收事件可以同時影響多個執行個體，可能會一次中斷整個多節點訓練任務，而不是單一節點。

這與沒有 EFA 限制的 Spot 用量基本上不同，其中節點可以分散到 AZs，而且中斷在統計上是獨立的。透過 EFA 的相同可用區域需求，單一容量事件可以串聯到訓練叢集。

如果您正在為 GPU 訓練工作負載節省成本，請確定您已評估所有可用的購買選項，然後再遞交給 Spot。預留執行個體、隨需容量預留 (ODCRs)、Savings Plans 和 ML 的容量區塊都可以提供大幅折扣，同時保證容量可用性 — 避免 Spot 固有的關聯中斷風險與 EFA 託管限制。

在大型 GPU 執行個體上規劃 IP 地址使用

根據預設，Amazon VPC CNI 外掛程式會預先配置 IP 地址，以確保可以快速排程 Pod，保持連接一個完整的備用 ENI，並填入 IPs。在大型執行個體上，這可能會導致每個節點預留數十個 IPs，即使只有幾個 Pod 執行中。

此不相符項目常見於訓練和推論工作負載，其中每個節點的 Pod 密度較低。在叢集擴展時，特別是在啟動多個 GPU 節點且每個 GPU 節點各有幾個 Pod 的自動擴展事件期間，這可能會導致子網路 IP 耗盡，即使實際 IP 使用率很低。

若要緩解這種情況，請調校 WARM_IP_TARGET、 MINIMUM_IP_TARGET和 WARM_ENI_TARGET變數，以符合您的實際 Pod 密度。VPC CNI 的 ENI 和 IP 目標設定的詳細資訊。

如需最佳化 IP 消耗的完整指南，請參閱最佳化 IP 地址使用率。