Kubernetes'te GPU Arızaları: Cihaz Arızalarını Sonsuz Bekleme Durumuna Düşmeden Yönetme
Meta
NVIDIA
2024'te Meta'nın Llama 3 405B'yi eğiten 16.384 H100'den oluşan kümesi 419 kesinti yaşadı ve bunların yüzde 58,7'si GPU'lara atfedildi. Kubernetes bu tür arızaları genellikle konteynerleri aynı ölü cihaz üzerinde yeniden başlatarak ele alır ve bu da sonsuz Pending durumlarına yol açar. Bu makale, Kubernetes 1.36'daki yeni Dinamik Kaynak Tahsisi (Dynamic Resource Allocation, DRA) özelliklerinin nihayet nasıl bir çıkış yolu sunduğunu, VK Cloud yönetilen kümesi üzerinde canlı bir demoyla açıklıyor.
Makale, Meta'nın Llama 3 405B'yi eğitme deneyimini vurguluyor; 16.384 H100 GPU'dan oluşan küme 419 kesinti yaşadı ve bunların %58,7'si GPU ile ilgiliydi. Kubernetes'in geleneksel olarak cihaz arızalarını durum bilgisi olmayan hizmet arızaları gibi ele aldığını, aynı bozuk GPU'da yeniden başlatmayı denediğini ve bunun da çökme döngüsüne yol açtığını belirtiyor. Bunu ele almak için Kubernetes 1.36 birkaç mekanizma sunuyor: DRA (Dinamik Kaynak Tahsisi) 1.34'ten beri kararlıdır ve basit bir sayaç yerine nesne tabanlı bir model sağlar; yedek cihazlar için öncelikli liste (firstAvailable); pod durumunda cihaz sağlık durumu; cihaz lekeleri ve toleransları; ve cihaz bağlama koşulları, vb. Yazar, GPU düğümü olan VK Cloud Managed Kubernetes 1.36 üzerinde bir test düzeneği kuruyor ve PCIe cihazını sıcak çıkararak bir GPU arızasını simüle ediyor. Düğümün cihazı sağlıksız olarak bildirdiğini ve tahsis edilebilir sayının düştüğünü, ancak pod'un ölü GPU'da herhangi bir yeniden planlama olmadan yeniden başlatılmaya devam ettiğini gösteriyor. Makale, Kubernetes'in CrashLoopBackOff podları için neden yerleşik bir yeniden planlama sunmadığını açıklayarak ve tüm düğümü öldüren düğüm sağlık denetleyicileri gibi DIY desenlerinden bahsederek sona eriyor; bu kaba bir araçtır.
Kaynak: Habr — хаб ML —
orijinal