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

# 聯網
<a name="aiml-networking"></a>

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

## 對於具有高節點間通訊的應用程式，請考慮較高的網路頻寬或彈性布料轉接器
<a name="_consider_higher_network_bandwidth_or_elastic_fabric_adapter_for_applications_with_high_inter_node_communication"></a>

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

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

### EFA 工作負載的節點佈建考量事項
<a name="_node_provisioning_considerations_for_efa_workloads"></a>

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

下列考量適用於 EKS 上任何以 EFA 為基礎的分散式訓練部署。以下我們將 Karpenter 註釋做為範例，但相同的考量也適用於受管和自我管理節點群組實作。
+  **釘選至 AZ**。EFA 要求所有通訊節點都位於相同的可用區域中，因此，參與相同分散式訓練任務的節點不得分散到各個區域。您可以在 上使用 `nodeSelector`或 Pod 親和性，將 Pod 固定到 AZ 來強制執行此操作`topology.kubernetes.io/zone`。選取目標執行個體類型具有最佳可用性，或容量區塊預留位置的可用區域。請注意，雖然相同可用區共置可改善節點間延遲，但也會增加可用區域層級故障的爆量半徑。對於長時間執行的訓練工作負載，單一 AZ 中斷或容量事件可以清除累積的訓練進度時數，這是代價高昂的損失。將此納入檢查點策略和任務持續時間規劃。
+  **設定叢集置放群組 （建議）**。在 EC2NodeClass 中指定置放群組。Karpenter 會自動佈建至其中。建議這樣做是為了獲得最佳延遲，但不需要嚴格地讓 EFA 運作。對於 [ML 的容量區塊](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)，置放會透過 UltraClusters 自動處理，不需要手動置放群組。請注意，在此情況下，AZ 已經鎖定，因此不需要額外的 Pod 層級或 NodePool 層級 AZ 限制。
+  **防止多節點訓練任務中斷**。在訓練 Pod 上使用 PDBs 或`karpenter.sh/do-not-disrupt: "true"`註釋。如果沒有這種情況，Karpenter 的整合可能會嘗試在工作中取代或移動 EFA 工作負載，中斷整個分散式訓練執行。在 NodePool `consolidationPolicy: WhenEmpty`上設定 以防止佔用的節點整合。`expireAfter` [在此處](https://karpenter.sh/docs/concepts/disruption/)檢閱這些標籤與 `terminationGracePeriod`和 之間的互動。
+  **設定適當的過期**時間。在 NodePool `expireAfter`上將 設定為比最長訓練任務更長的值，或將其完全停用以進行訓練 NodePools。即將到期的節點訓練中期會終止任務。
+  **使用正確的 EFA 裝置外掛程式版本**。[EFA 裝置外掛程式](https://github.com/aws/eks-charts/tree/master/stable/aws-efa-k8s-device-plugin)公開`vpc.amazonaws.com/efa`為可排程的資源。
+  **設定安全群組**。所有 EFA 執行個體都必須位於具有自我參考規則的相同安全群組中，允許所有進出本身的流量。如果沒有這樣做，EFA 流量會無提示地失敗。

### 了解 EFA 共同位置的 Spot 執行個體風險
<a name="_understand_spot_instance_risks_with_efa_co_location"></a>

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

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

如果您正在為 GPU 訓練工作負載節省成本，請確定您已評估所有可用的購買選項，然後再遞交給 Spot。[預留執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html)、[隨需容量預留](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) (ODCRs)、[Savings Plans](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html) 和 [ML 的容量區塊](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)都可以提供大幅折扣，同時保證容量可用性 — 避免 Spot 固有的關聯中斷風險與 EFA 託管限制。

## 在大型 GPU 執行個體上規劃 IP 地址使用
<a name="_planning_for_ip_address_consumption_on_large_gpu_instances"></a>

根據預設，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 目標設定](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/eni-and-ip-target.md)的詳細資訊。

如需最佳化 IP 消耗的完整指南，請參閱[最佳化 IP 地址使用率](https://docs.aws.amazon.com/eks/latest/best-practices/ip-opt.html)。