“Volcano Scheduler ile GPU Fragmentasyonunu Önlemek için Pratik İpuçları”

NVIDIA olarak, karmaşık altyapı sorunlarını hassasiyet ve yenilikle çözme konusunda gurur duyuyoruz. Volcano, NVIDIA DGX Cloud ile sağlanan Kubernetes kümesinde GPU’ların yeterince kullanılmadığına dair bir sorunla karşılaştığında, beklentileri aşan bir çözüm sunmak için göreve başladık.

Gelişmiş planlama tekniklerini ve dağıtılmış iş yüklerine dair derin bir anlayışı bir araya getirerek, %90 GPU kullanım oranına ulaştık ki bu, sözleşmesel hedefimiz olan %80’in oldukça üzerindeydi. İşte sorunun detayları, yaklaşımımız ve elde edilen sonuçlar.

Problemler: GPU Parçalanması ve Planlama Verimsizlikleri

DGX Cloud Kubernetes kümesi, her biri birden fazla NVIDIA L40S GPU ile donatılmış binlerce GPU’dan oluşuyordu. Küme, çeşitli iş yüklerini destekliyordu:

Birden fazla düğüm ve GPU ile dağıtık eğitim görevleri
Yüksek verimli AI modelleri için toplu çıkarım
GPU destekli veri işleme hatları
Geliştirme ve analiz için etkileşimli defterler

Her ne kadar güçlü bir donanım mevcut olsa da, küme GPU parçalanması yaşıyordu; bu, daha büyük işler için kullanılamayacak biçimde düğümlerin kısmi olarak işgal edilmesine neden oluyordu. Bu durum, Volcano Scheduler‘ın gang planlama algoritmasını kullanma alışkanlığı ile daha da kötüleşti.

Müdahale olmadan, en az %80 GPU kullanımını sürdürme konusundaki sözleşmemizi ihlal etme riskiyle karşı karşıya kaldık. Bu, kullanılmayan kaynakların başka ekipler için geri alınmasına yol açarak küme kapasitesinin düşmesine neden olabilecekti.

Karşılaşılan Ana Zorluklar

Bu çözümü uygulamak, iki ana engeli aşmayı gerektiriyordu:

Gang planlamanın tüm veya hiç yaklaşımı: Birden fazla GPU gerektiren dağıtık işler, gereken tüm kaynaklar aynı anda mevcut olmadıkça, sonsuz süreyle kuyruğa alınıyordu. Bu, darboğazlara neden oluyor ve görevlerin icrasını geciktiriyordu.
Rasgele yerleştirme nedeniyle parçalanma: İş yükleri, basit sezgisel yöntemler veya rastgele seçimle düğümlere atanıyordu; bu durum, GPU’ların düğümler arasında parçalanmış halde kalmasına yol açıyordu.

Çözüm: Gang Planlama ile Kutucuk Doldurma Algoritmasının Entegrasyonu

Bu zorlukları aşmak için, Volcano Scheduler’a bir kutucuk doldurma algoritması entegre ettik. Bu yaklaşım, iş yüklerini konsolide ederek düğüm kullanımını maksimize etmeye odaklandı ve diğer düğümlerin büyük işler için tamamen serbest kalmasını sağladı.

Teknik Uygulama

GPU parçalanmasını çözmek için geliştirdiğimiz yaklaşım, üç ana bileşene dayanıyordu:

İş yükü önceliklendirmesi:
- Kaynaklar, önem sırasına göre derecelendirildi: GPU, CPU ve bellek.
- Gelen iş yükleri için uygun düğümler, kaynak gereksinimlerine göre kısa listeye alındı.
Kutucuk doldurma ile optimize edilmiş yerleştirme:
- Kısmen işgal edilmiş düğümler mevcut kullanım seviyelerine göre sıralandı.
- İş yükleri, en az boş kaynağa sahip düğümlere yerleştirilerek diğer düğümlere geçildi.
Gang planlama entegrasyonu:
- Geliştirilmiş planlayıcı, gang planlamanın tüm veya hiç ilkesini korudu fakat kaynak konsolidasyonuna göre iş yükü yerleştirmeyi önceliklendirmek için zeka ekledi.

Bu noktalar, etkin iş yükü yerleştirmenin ve düğüm kullanımını önceliklendirmenin sağlanmasına olanak tanıyan Volcano Scheduler yapılandırması sayesinde mümkün oldu.

Örnek Senaryo

Çözümümüzün etkinliğini göstermek için aşağıdaki senaryoyu ele alalım:

Başlangıç Durumu

İki düğüm – Düğüm A, iki GPU ile işgal edilmiş, Düğüm B ise boş – yeni bir iş yükü almaktadır ve bu iş yükü iki GPU gerektirmektedir.

A flow diagram shows that a new GPU workload request arrives in the Kubernetes cluster, which has both partially and fully free GPU nodes. — *Şekil 1. İki düğümlü bir Kubernetes kümesi*

Varsayılan Gang Planlama

İş yükü rastgele bir şekilde, örneğin Düğüm B’ye yerleştirilmektedir ve bu durum her iki düğümün de kısmen işgal edilmesine neden olmaktadır.

A flow diagram shows that a Kubernetes cluster with two nodes, A and B, and partially occupied GPUs receives a new workload requiring two GPUs and places them on Node B using the default gang scheduling mechanism, lowering the capacity on both nodes. — *Şekil 2. Volcano Planlayıcıda GPU parçalanması*

Sonuç olarak, kümede daha fazla kısmen işgal edilmiş düğüm bulunuyordu. Şekil 3’te, yalnızca 18 tamamen boş düğümün bulunduğu, ancak dört GPU’ya ihtiyaç duyan bir eğitim işi için kullanılamayan yaklaşık 115 düğüm olduğu görülmektedir.

A graph shows the fragmented nodes in action, where there are only 18 nodes and four free GPUs to use. — *Şekil 3. 18 düğüm ve dört GPU’nun mevcut olduğu Kubernetes kümesi*

Bu parçalanmanın etkisi, kısmen işgal edilmiş düğümlerin dağılımına baktığımızda daha da belirgin hale geliyor.

A graph shows the fragmented nodes in action, where there are a large number of partially occupied nodes. A training task that requires four GPUs per node cannot use partially occupied nodes. — *Şekil 4. 115 düğüm ve üç boş GPU bulunan Kubernetes kümesi*

Çözüm

İş yükü, tamamen kullanılan dört GPU’su olan Düğüm A’ya yerleştirilmekte ve Düğüm B tamamen serbest kalmaktadır.

A flow diagram shows the optimal approach for node selection to mitigate GPU fragmentation in Volcano Scheduler. — *Şekil 5. İki optimize edilmiş düğümün bulunduğu Kubernetes kümesi*

Şekil 5’te, Düğüm A ve B’nin, kısmen işgal edilmiş GPU’ları ile yeni bir iş yükü aldığında varsayılan gang planlama mekanizması kullanılarak Düğüm B’ye yerleştirildiği görülmektedir.

Sonuç olarak, kümede daha fazla serbest düğüm bulunuyordu. Şekil 6’da, dört GPU’yu tamamen kullanabilen 214 düğüm olduğu ve bir eğitim işi için rahatça kullanılabildiği gösterilmektedir.

The graph shows the mitigated GPU fragmentation issue, in which there are a large number of fully available GPU nodes for consumption. — *Şekil 6. 214 düğüm ve tüm GPU’ların mevcut olduğu Kubernetes kümesi*

Şekil 7’de, ortalama dokuz düğümde üç boş GPU olduğu görülmektedir.

The graph shows that the GPU fragmentation issue was significantly mitigated. As a result, the cluster only had nine nodes and three free GPUs. — *Şekil 7. Azalan GPU parçalanma sorunu*

Bu stratejik yerleştirme, parçalanmayı önemli ölçüde azaltmış ve büyük eğitim işlerine kaynak erişilebilirliğini artırmıştır.

Elde Edilen Sonuçlar

Kutucuk doldurma algoritmasının Volcano Scheduler’a entegrasyonu, GPU kümesinin performansını değiştirdi:

Kaynak erişilebilirliğinin artırılması: Tamamen serbest düğümlerin sayısı arttı, bu da büyük ölçekli eğitim işlerinin kesintisiz planlanmasını sağladı.
GPU kullanımının iyileştirilmesi: Ortalama GPU kullanımı %90’a yükseldi, bu da %80’lik sözleşme gereksiniminin çok üstündeydi.
Maliyet verimliliğinin artırılması: Kaynak kullanımının optimize edilmesi, kapasitelerin azaltılmasını önledi ve ek maliyetler olmadan tahsis edilen küme kaynaklarına tam erişim sağladı.
İş yüklerinde ölçeklenebilirlik: Çözüm, yalnızca dağıtık eğitim işleri için değil, aynı zamanda toplu çıkarım ve GPU destekli veri işleme görevleri için de etkili oldu.

Sonuç olarak, tüm küme ortalaması %90 civarında oldu ki bu, Kaynak Yönetim Ekibi’nin kriteri olan %80’in oldukça üzerindeydi.

A line graph shows that, after resolving the GPU fragmentation issue, the GPU occupancy hovered around 90%. — *Şekil 8. DGX Cloud kümesinin GPU kullanımı %90 civarında*

Dağıtık Sistemler İçin Geniş Etkiler

Bu yazı, düşünceli planlama stratejilerinin çok düğümlü ve çok GPU’lu kümelerde yaygın sorunları nasıl çözebileceğini vurgulamaktadır.

Proaktif kaynak yönetimi darboğazları önler: Parçalanma sorunlarını önceden tahmin ederek ve optimize edilmiş yerleştirme algoritmalarıyla ele alarak, kuruluşlar maliyetli gecikmelerin ve yetersiz kullanımın önüne geçebilir.
Maliyet odaklı mühendislik ROI’yi artırır: Mevcut altyapının verimli kullanımı, ek donanım yatırımlarına ihtiyaç duymadan performansı artırır.
Esnek planlama çeşitli iş yüklerini karşılar: Kutucuk doldurma algoritmalarının entegrasyonu, Volcano gibi planlayıcıların belirli iş yükü gereksinimlerini karşılamak için mevcut sistemleri baştan tasarlamadan uyum sağlama yeteneğini göstermektedir.

İlgili Kaynaklar

TechBlog: NVIDIA NeMo Özelleştiricisi ile LLM’leri Kolayca İyileştirin
TechBlog: Ekstra Kod Değişimi Olmadan NVIDIA GPU’ları ile Apache Spark ML’i Hızlandırın
TechBlog: LLM Tekniklerini Usta Olmak: LLMOps
Forum: Hızlandırılmış hesaplama ve optimizasyon yaklaşımlarıyla ilgili konulara derinlemesine dalış yapabileceğiniz GPU Cloud forumuna göz atın.