Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Jaringan
**Tip**
[Daftar ](https://events.eksworkshop.com/workshops/genai/) untuk AI/ML lokakarya Amazon EKS mendatang.
## Pertimbangkan Bandwidth Jaringan yang Lebih Tinggi atau Adaptor Kain Elastis Untuk Aplikasi dengan Inter-Node Komunikasi Tinggi
Untuk beban kerja pelatihan terdistribusi di Amazon EKS dengan tuntutan komunikasi antar-node yang tinggi, pertimbangkan untuk memilih instans dengan bandwidth jaringan yang lebih tinggi atau Adaptor Fabric [ Elastic ](https://docs.aws.amazon.com/eks/latest/userguide/node-efa.html) (EFA). Kinerja jaringan yang tidak mencukupi dapat menghambat transfer data, memperlambat tugas pembelajaran mesin seperti pelatihan multi-GPU terdistribusi. Perhatikan bahwa beban kerja inferensi biasanya tidak memiliki komunikasi antar-node yang tinggi.
Pastikan gambar kontainer Anda menyertakan NCCL dan plugin [ aws-ofi-nccl ](https://github.com/aws/aws-ofi-nccl) (yang memungkinkan NCCL menggunakan EFA melalui libfabric). MPI mungkin juga diperlukan tergantung pada peluncur kerangka pelatihan Anda.
### Pertimbangan penyediaan node untuk beban kerja EFA
Saat menyediakan EFA-capable node, instans yang perlu berkomunikasi harus berada di Availability Zone yang sama (persyaratan keras). Selain itu, AWS merekomendasikan meluncurkan semua EFA-enabled instans dalam grup penempatan [ cluster ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) untuk meminimalkan jarak fisik di antara mereka dalam AZ tunggal itu, yang memberi Anda latensi serendah mungkin. Grup penempatan tidak diperlukan agar EFA berfungsi, tetapi sangat disarankan untuk kinerja yang optimal.
Pertimbangan berikut berlaku untuk penye EFA-based baran pelatihan terdistribusi di EKS. Di bawah ini kami merujuk pada anotasi Karpenter sebagai contoh, tetapi pertimbangan yang sama dapat diterapkan pada implementasi Kelola dan Grup Self-managed Node juga.
+ **Sematkan ke AZ**. EFA mengharuskan semua node komunikasi berada di AZ yang sama, jadi misalnya, node yang berpartisipasi dalam pekerjaan pelatihan terdistribusi yang sama tidak boleh tersebar di seluruh zona. Anda dapat menerapkan ini dengan menyematkan Pod ke AZ menggunakan afinitas a `nodeSelector` atau pod aktif. `topology.kubernetes.io/zone` Pilih AZ tempat jenis instans target Anda memiliki ketersediaan terbaik, atau tempat Blok Kapasitas Anda dicadangkan. Ketahuilah bahwa sementara co-location Same-AZ meningkatkan latensi antar-node, itu juga meningkatkan radius ledakan kegagalan. AZ-level Untuk beban kerja pelatihan yang berjalan lama, satu pemadaman AZ atau peristiwa kapasitas dapat menghapus berjam-jam kemajuan pelatihan yang terakumulasi — kerugian yang mahal. Faktor ini ke dalam strategi checkpointing dan perencanaan durasi pekerjaan Anda.
+ **Konfigurasikan grup penempatan cluster (disarankan)**. Tentukan grup penempatan di EC2NodeClass. Karpenter menyediakan ke dalamnya secara otomatis. Ini direkomendasikan untuk latensi optimal tetapi tidak sepenuhnya diperlukan agar EFA berfungsi. Untuk Blo [ k Kapasitas untuk ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html), penempatan ditangani secara otomatis melalui UltraClusters — tidak diperlukan grup penempatan manual. Perhatikan bahwa, dalam hal ini, AZ sudah terkunci dan oleh karena itu, pembatasan tambahan Pod-level atau NodePool-level AZ tidak diperlukan.
+ **Mencegah gangguan pekerjaan ** pelatihan multi-node. Gunakan PDB atau `karpenter.sh/do-not-disrupt: "true"` anotasi pada pod pelatihan. Tanpa ini, konsolidasi Karpenter dapat mencoba mengganti atau memindahkan beban kerja EFA di tengah pekerjaan, mengganggu seluruh proses pelatihan terdistribusi. A `consolidationPolicy: WhenEmpty` tur NodePool untuk mencegah konsolidasi node yang diduduki. Tinjau interaksi antara label ini dan `terminationGracePeriod` dan `expireAfter` [ di sini](https://karpenter.sh/docs/concepts/disruption/).
+ **Tetapkan kedaluwarsa yang sesuai**. Konfigur `expireAfter` asikan NodePool ke nilai yang lebih panjang dari pekerjaan pelatihan terpanjang Anda, atau nonaktifkan untuk pelatihan NodePools sepenuhnya. Node yang kedaluwarsa di tengah pelatihan mengakhiri pekerjaan.
+ **Gunakan versi ** plugin perangkat EFA yang benar. Plugin perangkat [ EFA mengekspos `vpc.amazonaws.com/efa` sebagai ](https://github.com/aws/eks-charts/tree/master/stable/aws-efa-k8s-device-plugin) sumber daya yang dapat dijadwalkan.
+ **Konfigurasikan grup keamanan**. Semua instans EFA harus berada dalam grup keamanan yang sama dengan aturan referensi diri yang memungkinkan SEMUA lalu lintas itu sendiri. to/from Tanpa ini, lalu lintas EFA gagal secara diam-diam.
### Memahami risiko instans Spot dengan co-location EFA
Instans Spot Amazon EC2 menawarkan penghematan biaya yang signifikan untuk beban kerja pelatihan (lihat bagian [ ini ](aiml-compute.md#spot-gpus-karpenter) untuk praktik terbaik Spot umum dengan GPU). Namun, EFA mengharuskan semua node yang berkomunikasi berada di Zona Ketersediaan yang sama, dan AWS merekomendasikan menempatkannya dalam grup penempatan cluster untuk latensi optimal. Ko-lokasi ini memperkenalkan risiko gangguan yang * berkorelasi*: instans berbagi infrastruktur fisik yang mendasarinya dalam AZ yang sama (dan terlebih lagi dalam grup penempatan), sehingga peristiwa reklamasi kapasitas tunggal dapat memengaruhi beberapa instans secara bersamaan — berpotensi mengganggu seluruh pekerjaan pelatihan multi-node Anda sekaligus, bukan satu node.
Ini pada dasarnya berbeda dari penggunaan Spot tanpa batasan EFA, di mana node dapat disebarkan di seluruh AZ dan interupsi secara statistik independen. Dengan persyaratan Same-AZ EFA, acara kapasitas tunggal dapat mengalir di seluruh cluster pelatihan Anda.
Jika Anda mengejar penghematan biaya untuk beban kerja pelatihan GPU, pastikan Anda telah mengevaluasi semua opsi pembelian yang tersedia sebelum berkomitmen ke Spot. [Instans Cad ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html) angan, [ On-Demand Reservasi Kapasitas ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) (ODCR), Paket Tab [ ungan](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html), dan Blok [ Kapasitas untuk ML semuanya ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) dapat memberikan diskon signifikan sambil menjamin ketersediaan kapasitas — menghindari risiko gangguan terkait yang melekat pada Spot dengan kendala ko-lokasi EFA.
## Merencanakan Konsumsi Alamat IP pada Instans GPU Besar
Secara default, plugin Amazon VPC CNI melakukan pra-alokasi alamat IP untuk memastikan pod dapat dijadwalkan dengan cepat, menjaga satu ENI cadangan penuh terpasang dan diisi dengan IP. Pada instans besar, ini dapat mengakibatkan lusinan IP dicadangkan per node bahkan ketika hanya beberapa pod yang berjalan.
Ketidakcocokan ini umum terjadi pada beban kerja pelatihan dan inferensi di mana kepadatan pod per node rendah. Pada skala cluster, terutama selama peristiwa penskalaan otomatis yang memutar banyak node GPU dengan masing-masing beberapa pod, ini dapat menyebabkan kehabisan IP subnet meskipun pemanfaatan IP sebenarnya rendah.
Untuk mengurangi ini, setel `WARM_ENI_TARGET` variabel`WARM_IP_TARGET`,`MINIMUM_IP_TARGET`, dan agar sesuai dengan kepadatan pod Anda yang sebenarnya. Info lebih lanjut di [ pengaturan target ENI dan IP VPC CNI. ](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/eni-and-ip-target.md)
Untuk panduan lengkap tentang mengoptimalkan konsumsi IP, lihat Meng [ optimalkan Pemanfaatan Alamat IP](https://docs.aws.amazon.com/eks/latest/best-practices/ip-opt.html).