本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Networking
<a name="aiml-networking"></a>

**提示**  
 [注册](https://events.eksworkshop.com/workshops/genai/)参加即将举行的亚马逊 EKS AI/ML 研讨会。

## 对于具有高 Inter-Node 通信能力的应用程序，可以考虑使用更高的网络带宽或弹性结构适配器
<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-capable 节点时，需要通信的实例必须位于同一个可用区内（硬性要求）。此外，AWS 建议启动[集群置放群组中的所有 EFA-enabled 实例，](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)以最大限度地缩短它们在该单个可用区内的物理距离，从而尽可能降低延迟。EFA 不需要置放群组即可运行，但强烈建议使用置放群组以获得最佳性能。

以下注意事项适用于 EKS 上的任何 EFA-based 分布式训练部署。下面我们以 Karpenter 注解为例，但同样的注意事项也可以应用于托管组和 Self-managed 节点组的实现。
+  **固定到 AZ **。EFA 要求所有通信节点位于同一个可用区中，因此，例如，参与同一个分布式训练任务的节点不得分散在各个区域。您可以通过使用`nodeSelector`或 pod 关联将 Pod 固定到可用区来强制执行此操作。`topology.kubernetes.io/zone`选择目标实例类型可用性最高的可用区，或者预留容量块的可用区。请注意，虽然同一个可用区共置可以改善节点间延迟，但它也会增加故障的爆炸半径。 AZ-level 对于长时间运行的训练工作负载，单个 AZ 中断或容量事件可能会使数小时的累积训练进度化为乌有，这是一种代价高昂的损失。将此考虑在检查点策略和工作期限规划中。
+  **配置集群置放群组（推荐）**。在中指定置放群组 EC2NodeClass。Karpenter 会自动向其中进行补给。为实现最佳延迟，建议使用此方法，但不严格要求 EFA 才能正常运行。对于 [ ML 的 Capacity Blocks](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)，放置是通过 UltraClusters 自动处理的，无需手动置放群组。请注意，在这种情况下，AZ 已被锁定，因此不需要额外的 Pod-level 或 NodePool-level AZ 限制。
+  **防止中断多节点训练作业**。在训练舱上使用 PDB 或`karpenter.sh/do-not-disrupt: "true"`注释。否则，Karpenter 的整合可能会试图在工作中取代或移动 EFA 工作负载，从而中断整个分布式训练运行。设置`consolidationPolicy: WhenEmpty`为 NodePool 可防止合并被占用的节点。`expireAfter`[在此处查看这些标签与`terminationGracePeriod`和之间的相互作用](https://karpenter.sh/docs/concepts/disruption/)。
+  **设置适当的到期时间**。将配置`expireAfter` NodePool 为比最长训练任务更长的值，或者将其禁用以 NodePools 完全训练。训练中期到期的节点会终止作业。
+  **使用正确的 EFA 设备插件版本**。[EFA 设备插件以可调](https://github.com/aws/eks-charts/tree/master/stable/aws-efa-k8s-device-plugin)度`vpc.amazonaws.com/efa`资源的形式公开。
+  **配置安全组**。所有 EFA 实例必须位于同一个安全组中，且具有允许所有流量 to/from 本身的自引用规则。否则，EFA 流量将静默失效。

### 利用 EFA 托管了解竞价型实例风险
<a name="_understand_spot_instance_risks_with_efa_co_location"></a>

Amazon EC2 竞价型实例可为训练工作负载节省大量成本（有关使用 GPU [ 的通用竞价最佳实践，请参阅](aiml-compute.md#spot-gpus-karpenter)本节）。但是，EFA 要求所有通信节点位于同一个可用区内，AWS 建议将它们放置在集群置放群组中以获得最佳延迟。这种共存带来了*相关的中断风险*：实例在同一个可用区内共享底层物理基础架构（在置放群组中更是如此），因此单个容量回收事件可能会同时影响多个实例——可能会同时中断整个多节点训练作业，而不是单个节点。

这与没有 EFA 限制的 Spot 使用有根本的不同，后者节点可以分布在 AZ 中，中断在统计上是独立的。按照 EFA 的相同可用区要求，单个容量事件可以在您的训练集群中级联。

如果您希望节省 GPU 训练工作负载的成本，请确保在购买 Spot 之前已经评估了所有可用的购买选项。[预留实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html)、[On-Demand 容量预留 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) (ODCR)、[储蓄计划](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html)和机器学习[容量区块都](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 连接并填充 IP。在大型实例上，即使只有几个 Pod 在运行，这也可能导致每个节点预留数十个 IP。

这种不匹配在每个节点的 pod 密度较低的训练和推理工作负载中很常见。在集群规模上，尤其是在启动许多 GPU 节点且每个节点很少 Pod 的自动扩展事件中，即使实际 IP 利用率很低，这也可能导致子网 IP 耗尽。

要缓解这种情况，请调整`WARM_IP_TARGET``MINIMUM_IP_TARGET`、和`WARM_ENI_TARGET`变量以匹配您的实际豆荚密度。有关 [ 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)。