本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
Networking
提示
注册
对于具有高 Inter-Node 通信能力的应用程序,可以考虑使用更高的网络带宽或弹性结构适配器
对于节点间通信需求高的 Amazon EKS 上的分布式训练工作负载,可以考虑选择具有更高网络带宽的实例或 Elastic Fabric Adapter (EFA)。网络性能不足会阻碍数据传输,减慢分布式多 GPU 训练等机器学习任务的速度。请注意,推理工作负载通常不具有较高的节点间通信。
确保您的容器映像包含 NCCL 和 aws-ofi-nccl 插件
EFA 工作负载的节点配置注意事项
配置 EFA-capable 节点时,需要通信的实例必须位于同一个可用区内(硬性要求)。此外,AWS 建议启动集群置放群组中的所有 EFA-enabled 实例,以最大限度地缩短它们在该单个可用区内的物理距离,从而尽可能降低延迟。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,放置是通过 UltraClusters 自动处理的,无需手动置放群组。请注意,在这种情况下,AZ 已被锁定,因此不需要额外的 Pod-level 或 NodePool-level AZ 限制。
-
防止中断多节点训练作业。在训练舱上使用 PDB 或
karpenter.sh/do-not-disrupt: "true"注释。否则,Karpenter 的整合可能会试图在工作中取代或移动 EFA 工作负载,从而中断整个分布式训练运行。设置consolidationPolicy: WhenEmpty为 NodePool 可防止合并被占用的节点。expireAfter在此处查看这些标签与terminationGracePeriod和之间的相互作用。 -
设置适当的到期时间。将配置
expireAfterNodePool 为比最长训练任务更长的值,或者将其禁用以 NodePools 完全训练。训练中期到期的节点会终止作业。 -
使用正确的 EFA 设备插件版本。EFA 设备插件以可调
度 vpc.amazonaws.com/efa资源的形式公开。 -
配置安全组。所有 EFA 实例必须位于同一个安全组中,且具有允许所有流量 to/from 本身的自引用规则。否则,EFA 流量将静默失效。
利用 EFA 托管了解竞价型实例风险
Amazon EC2 竞价型实例可为训练工作负载节省大量成本(有关使用 GPU 的通用竞价最佳实践,请参阅本节)。但是,EFA 要求所有通信节点位于同一个可用区内,AWS 建议将它们放置在集群置放群组中以获得最佳延迟。这种共存带来了相关的中断风险:实例在同一个可用区内共享底层物理基础架构(在置放群组中更是如此),因此单个容量回收事件可能会同时影响多个实例——可能会同时中断整个多节点训练作业,而不是单个节点。
这与没有 EFA 限制的 Spot 使用有根本的不同,后者节点可以分布在 AZ 中,中断在统计上是独立的。按照 EFA 的相同可用区要求,单个容量事件可以在您的训练集群中级联。
如果您希望节省 GPU 训练工作负载的成本,请确保在购买 Spot 之前已经评估了所有可用的购买选项。预留实例、On-Demand 容量预留 (ODCR)、储蓄计划和机器学习容量区块都可以在保证容量可用性的同时提供大幅折扣,从而避免 Spot 在 EFA 托管限制下固有的相关中断风险。
规划大型 GPU 实例的 IP 地址消耗
默认情况下,Amazon VPC CNI 插件会预先分配 IP 地址以确保可以快速调度 pod,同时保持一个完整的备用 ENI 连接并填充 IP。在大型实例上,即使只有几个 Pod 在运行,这也可能导致每个节点预留数十个 IP。
这种不匹配在每个节点的 pod 密度较低的训练和推理工作负载中很常见。在集群规模上,尤其是在启动许多 GPU 节点且每个节点很少 Pod 的自动扩展事件中,即使实际 IP 利用率很低,这也可能导致子网 IP 耗尽。
要缓解这种情况,请调整WARM_IP_TARGETMINIMUM_IP_TARGET、和WARM_ENI_TARGET变量以匹配您的实际豆荚密度。有关 VPC CNI 的 ENI 和 IP 目标设置
有关优化 IP 消耗的完整指南,请参阅优化 IP 地址利用率。