Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Red
**sugerencia**
[Inscríbase en ](https://events.eksworkshop.com/workshops/genai/) los próximos AI/ML talleres de Amazon EKS.
## Considere la posibilidad de utilizar un ancho de banda de red más elevado o un adaptador de tejido elástico para aplicaciones con un alto nivel de Inter-Node comunicación
Para cargas de trabajo de entrenamiento distribuidas en Amazon EKS con altas exigencias de comunicación entre nodos, considere la posibilidad de seleccionar instancias con un ancho de banda de red más alto o un adaptador [ Elastic Fabric ](https://docs.aws.amazon.com/eks/latest/userguide/node-efa.html) (EFA). Un rendimiento insuficiente de la red puede obstaculizar la transferencia de datos y ralentizar las tareas de aprendizaje automático, como el entrenamiento con varias GPU distribuidas. Tenga en cuenta que las cargas de trabajo de inferencia no suelen tener una alta comunicación entre nodos.
Asegúrese de que la imagen de su contenedor incluya NCCL y el complemento [https://github.com/aws/aws-ofi-nccl](https://github.com/aws/aws-ofi-nccl) aws-ofi-nccl (que permite a NCCL usar EFA a través de libfabric). El MPI también puede ser necesario en función del lanzador de tu marco de entrenamiento.
### Consideraciones sobre el aprovisionamiento de nodos para las cargas de trabajo de EFA
Al aprovisionar EFA-capable nodos, las instancias que necesitan comunicarse deben estar en la misma zona de disponibilidad (requisito obligatorio). Además, AWS recomienda lanzar todas las EFA-enabled instancias en un grupo de ubicación en [ clústeres ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) para minimizar la distancia física entre ellas dentro de esa zona de disponibilidad única, lo que proporciona la latencia más baja posible. No es necesario contar con un grupo de ubicación para que EFA funcione, pero se recomienda encarecidamente para lograr un rendimiento óptimo.
Las siguientes consideraciones se aplican a cualquier implementación de formación EFA-based distribuida en EKS. A continuación, hacemos referencia a las anotaciones de Karpenter como ejemplo, pero las mismas consideraciones se pueden aplicar tanto a las implementaciones de grupos gestionados como a las de grupos de Self-managed nodos.
+ **Fija un pin a una AZ. ** La EFA requiere que todos los nodos de comunicación estén en la misma zona de disponibilidad, por lo que, por ejemplo, los nodos que participan en la misma tarea de formación distribuida no deben estar repartidos entre zonas. Para hacer cumplir esta regla, puedes fijar el pod a una zona de disponibilidad con la opción «`nodeSelector`o» con la afinidad del pod activada. `topology.kubernetes.io/zone` Seleccione la zona de disponibilidad en la que su tipo de instancia de destino tenga la mejor disponibilidad o en la que esté reservado su bloque de capacidad. Tenga en cuenta que, si bien la ubicación conjunta en la misma zona de disponibilidad mejora la latencia entre nodos, también aumenta el radio de expansión de una falla. AZ-level En el caso de las cargas de trabajo de formación de larga duración, una sola interrupción de la disponibilidad o interrupción de la capacidad en la zona de servicio puede acabar con horas de progreso de formación acumuladas, lo que supone una pérdida cara. Tenga esto en cuenta en su estrategia de control y en la planificación de la duración de los trabajos.
+ **Configure el grupo de colocación en clústeres (recomendado). ** Especifique el grupo de ubicación en EC2NodeClass. Karpenter lo aprovisiona automáticamente. Esto se recomienda para una latencia óptima, pero no es estrictamente necesario para que EFA funcione. En el [ caso de Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html), la colocación se gestiona automáticamente UltraClusters , sin necesidad de un grupo de colocación manual. Tenga en cuenta que, en este caso, la AZ ya está bloqueada y, por lo tanto, no se necesitan restricciones adicionales Pod-level o NodePool-level AZ.
+ **Evite la interrupción de las tareas ** de formación de varios nodos. Usa PDB o `karpenter.sh/do-not-disrupt: "true"` anotaciones en los módulos de entrenamiento. Sin esto, la consolidación de Karpenter podría intentar reemplazar o trasladar las cargas de trabajo de EFA a mitad de la fase de trabajo, lo que interrumpiría toda la formación distribuida. `consolidationPolicy: WhenEmpty`Configúrela en para evitar la consolidación de los nodos NodePool ocupados. Revise la interacción entre estas etiquetas `terminationGracePeriod` y `expireAfter` [ aquí](https://karpenter.sh/docs/concepts/disruption/).
+ **Establezca la fecha de caducidad adecuada**. `expireAfter`Configúralo NodePool con un valor superior al de tu trabajo de formación más largo o desactívalo para que se entrene NodePools por completo. Un nodo que caduca a mitad del entrenamiento finaliza el trabajo.
+ **Utilice la versión correcta del complemento de dispositivo EFA. ** El complemento de dispositivos [ EFA se ](https://github.com/aws/eks-charts/tree/master/stable/aws-efa-k8s-device-plugin) presenta `vpc.amazonaws.com/efa` como un recurso programable.
+ **Configure los grupos de seguridad. ** Todas las instancias de EFA deben estar en el mismo grupo de seguridad con una regla de autorreferencia que permita TODO el tráfico en sí. to/from Sin esto, el tráfico de EFA falla de forma silenciosa.
### Comprenda los riesgos de las instancias puntuales con la ubicación conjunta de EFA
Las instancias puntuales de Amazon EC2 ofrecen importantes ahorros de costos para las cargas de trabajo de capacitación (consulte [ esta sección ](aiml-compute.md#spot-gpus-karpenter) para conocer las prácticas recomendadas generales de Spot con las GPU). Sin embargo, EFA exige que todos los nodos de comunicación residan en la misma zona de disponibilidad, y AWS recomienda colocarlos en un grupo de ubicación en clústeres para lograr una latencia óptima. Esta ubicación conjunta presenta un riesgo de interrupción * correlacionado*: las instancias comparten la infraestructura física subyacente dentro de la misma zona de disponibilidad (y más aún dentro de un grupo de ubicación), por lo que un solo evento de recuperación de capacidad puede afectar a varias instancias simultáneamente, lo que podría interrumpir todo el trabajo de formación multinodo de una sola vez en lugar de hacerlo en un solo nodo.
Esto es fundamentalmente diferente del uso puntual sin restricciones de EFA, en el que los nodos se pueden repartir entre zonas de disponibilidad y las interrupciones son estadísticamente independientes. Con el requisito de que EFA sea la misma zona de disponibilidad, un único evento de capacidad puede afectar a todo el grupo de formación.
Si quieres ahorrar costes en las cargas de trabajo de entrenamiento con GPU, asegúrate de haber evaluado todas las opciones de compra disponibles antes de decidirte por Spot. [Las instancias reservadas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html), las reservas de [ On-Demand capacidad ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) (ODCR), los planes de [ ahorro y los bloques de [ capacidad para el aprendizaje automático ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) pueden ofrecer importantes descuentos y](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html), al mismo tiempo, garantizar la disponibilidad de la capacidad, lo que evita el riesgo de interrupción asociado a las restricciones de ubicación conjunta de Spot y EFA.
## Planificación del consumo de direcciones IP en instancias de GPU de gran tamaño
De forma predeterminada, el complemento CNI de Amazon VPC preasigna las direcciones IP para garantizar que los pods se puedan programar rápidamente, manteniendo un ENI completo de repuesto adjunto y lleno de IP. En instancias grandes, esto puede provocar que se reserven docenas de IP por nodo, incluso cuando solo se estén ejecutando unos pocos pods.
Este desajuste es habitual en las cargas de trabajo de entrenamiento e inferencia, donde la densidad de pods por nodo es baja. A escala de clústeres, especialmente durante los eventos de escalado automático que activan muchos nodos de GPU con pocos pods cada uno, esto puede provocar el agotamiento de la IP de la subred, aunque la utilización real de la IP sea baja.
Para mitigar este problema, ajusta las `WARM_ENI_TARGET` variables `WARM_IP_TARGET``MINIMUM_IP_TARGET`, y para que coincidan con la densidad real de los pods. Más información en la configuración de objetivos de IP y ENI de [ VPC CNI. ](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/eni-and-ip-target.md)
Para obtener una guía completa sobre cómo optimizar el consumo de IP, consulte [ Optimización del uso de direcciones IP. ](https://docs.aws.amazon.com/eks/latest/best-practices/ip-opt.html)