NVIDIA Kolektif İletişim Kütüphanesi (NCCL), AI uygulamalarında hızlı GPU’dan GPU’ya iletişim için kritik öneme sahiptir ve performansı artırmak için çeşitli optimizasyonlar ve ayarlar kullanır.
Ancak, platform çeşitliliği arttıkça, varsayılan NCCL ayarları her zaman en iyi sonuçları sunmayabilir. Bu yazıda, ayarlamanın önemini ve kullanıcıların özel tuner eklentileri ile nasıl performansı artırabileceklerini ele alacağız. Ayrıca, başarılara ulaşmış bir yeniden ayar örneği de sunacağız.
İşlemci Ayarlama Genel Görünümü
NCCL’e bir işlem hazırlandığında, doğru değerleri seçmesi gereken bazı değişkenler bulunur:
- Kullanılan CTA sayısı
- Protokol
- Algoritma
- Parça boyutlandırması
NCCL, bu kararları vermek için şu girdileri dikkate alır:
- Kolektif işlem türü
- Mesaj boyutu
- İletimci boyutları
- Bir
ncclGroupiçindeki eşzamanlı işlem sayısı - Sunulan belgenin kaydedilip kaydedilmediği
- Topoloji ve grafik bilgisi
NCCL, bu girdileri analiz ederek içsel bir maliyet modeli ve dinamik bir zamanlayıcı aracılığıyla algılanan optimal çıktıyı hesaplar.
NCCL Maliyet Modeli
NCCL’in maliyet modeli, varsayılan ayar kararlarının temelini oluşturur. Bu model, toplu işlemlerin maliyetini zaman açısından değerlendirir. Amaç, doğru protokol ve algoritmanın seçilmesidir. Maliyet modeli, GPU, topoloji, ağ ve algoritmik özellikler gibi birçok faktörü dikkate alır.
NCCL ekibi, kullanıcılara en iyi otomatik ayarlanmış sonuçları sağlamak için maliyet modelini sürekli optimize etmektedir. Daha fazla detay için NCCL belgelerine göz atabilirsiniz.
Dinamik Zamanlayıcı
İşlemler kuyruklandığında, parça boyutu ve Cooperative Thread Array (CTA) miktarı ayrı bir dinamik zamanlama algoritması tarafından belirlenir. Daha fazla CTA, maksimum bant genişliğini sağlamak için gereklidir. Daha küçük parçalar ve daha az CTA, daha iyi boru hattı ve gecikme için küçük mesaj boyutları için daha uygun olabilir.
Ayrıca, NCCL Group Callsema ile aynı anda birden fazla çalışmayı ilerletirken, o işlemler, paralel yürütülme için daha az CTA ile planlanmalıdır.
Platform Ayarlama Varyasyonları
NCCL’in varsayılan ayarları her zaman en iyi kararı vermeye çalışır, ancak bazen ağ anahtarı tedarikçisi, sanallaştırma, CPU veya PCI yapılandırması gibi çeşitli faktörlere bağlı olarak ayarların elden geçirilmesi gerekebilir. Bu durumlarda, NCCL’in varsayılan ayarlarını geçersiz kılmak performansı optimize etmeye yardımcı olabilir. Bu gibi hallerde, önerilen çözüm tuner eklentileridir.
Tuner Eklentileri
Tuner eklentileri, herhangi bir platformda ayarlamaları kısa süre içinde düzeltmek için önerilen yöntemdir. Kütüphanenin varsayılan tunlama kararlarını, bir eklenti modeli aracılığıyla geçersiz kılma mekanizması sunarlar. Yüksek esneklik sayesinde, herhangi bir boyut veya toplu işlem türü için özelleştirme imkanı tanırlar.
Genellikle, kümelerin yöneticileri veya platform sağlayıcıları, kullanıcılarının kütüphanenin en iyi tunlama parametrelerini seçebilmesi için bir tuner eklentisi geliştirir ve bunu kullanıcılarına bir tarif ile sunar. Tuner eklentileri, uygulamalar içinde iyi çalışır çünkü iş yüküne şeffaftır.
Bir tuner eklentisi yüklendiğinde, NCCL boyutlarını, sıralarını ve çoklu iletişimcileri belirlemek için kullanılacak bir bağlam nesnesi alır. Tuner’nin ana işlevi ise getCollInfo‘dur. Bu, işlemlerin maliyetlerinin geçersiz kılındığı noktadır.
getCollInfo, NCCL maliyet modeli tahminleri ile beslenen bir ipucu niteliğindedir ve tuner eklentisi varsayılanları korumayı seçebilir. Bu, belirli bir algoritma ve protokolün uyumlu ya da mevcut topolojide çalışmadığı durumlar için önemlidir. Bu durumda, o değerler -1.0 olarak ayarlanır.
NCCL’i Aşırı Tunlama Yapmaktan Kaçınmak
NCCL’in varsayılan CTA sayıları ve bellek boyutları, uçtan uca iş yükü performansını en üst düzeye çıkarmak için dikkatlice seçilmiştir. Bu değerlerin artırılması genelde iletişim testlerinde daha iyi sonuçlar doğurur.
Bununla birlikte, NCCL’i izole bir şekilde optimize etmek, uçtan uca iş yükünü optimize etmekten çok farklıdır. NCCL, bir seferde 64 CTA’ya kadar iletişim işlemleri gerçekleştirebilir. NCCL CTA sayısını artırmak genellikle işlem performansını iyileştirirken, iş yükü performansına olumsuz etkileyebilir.
Kaynaklar üzerindeki müdahale ve CTA açlığı gibi etkiler, uçtan uca performansı olumsuz etkileyebilir. Bu yüzden NCCL‘in tasarım felsefesi, büyük mesaj boyutlarında mevcut taşıma hızını doyurmak için ihtiyaç duyulan kadar CTA kullanmaktır.
Ayarlama Sorunlarını Ele Almak
Tunlamanın, belirli bir uygulama için bir sorun olup olmadığını dikkatlice düşünmek önemlidir ve elle düzeltme işlemin fayda sağlayıp sağlamayacağını değerlendirmek gerekir. Bunun yararı, ayarlama hatasının derecesine ve bu hatanın uçtan uca iş yükü süresini ne kadar etkilediğine bağlıdır.
Herhangi bir ayarlama geçersiz kılma durumu, bakım yükü yaratır ve gelecekte NCCL ayarlamaları ile birlikte iyileştirmelerin iş yükünüze yansımasını engelleyebilir. Bu nedenle, herhangi bir varsayılan seçim, geçersiz kılmalar dışında kalır.
Ayarlama Geçersiz Kılma Seçenekleri
Bu bölüm, ayarları geçersiz kılma yöntemlerini açıklar.
Tuner Eklentileri
Önceki bölümde açıklandığı gibi, treek eklentileri, ayarları geçersiz kılmanın önerilen yoludur.
Çevre Değişkenleri
NCCL, kullanıcıların yapılandırma yapmalarını sağlamak için çevre değişkenlerinden geniş ölçüde yararlanır. Kütüphanenin ayarlarını zorla uygulamak için özel çevre değişkenleri bulunmaktadır.
Bunları ayarlarken dikkatli olmak önemlidir. Genellikle bunun bir değerinin değiştirilmesi spesifik bir performans sorununu giderebilirken, bu değişikliğin yanlış kopyalanıp diğer değerlerle birleştirilmesi, NCCL’in varsayılanlarını kullanamamasına yol açabilir.
Eğer bu değişkenler iş yükü yapılandırmalarınızda kullanılıyorsa, düzenli olarak bunların ayarlanıp ayarlanmadığını yeniden gözden geçirmeniz gerekir. Zamanla, iş yükünüze, yeni NCCL sürümlerine veya diğer sistem yapılandırması güncellemelerine bağlı değişiklikler meydana gelebilir.
Bu değişkenlerin global ayarlar olduğu ve bir süreç içinde tüm NCCL iletişimcileri için geçerli olacağı da unutulmamalıdır. Değiştirilen değerler, NCCL tarafından (bir süreç süresince) önbelleğe alınabilir, bu nedenle belirli bir değeri ayarlayıp daha sonra değiştirerek etkili olamayabilir. Genel olarak, bunlar deneysel çalışmalar için önerilmektedir.
ncclCommInitRankConfig
NCCL, kullanıcılara iletişimcilerine göre yapılandırmaları geçersiz kılma olanağı sunar. Daha fazla bilgi için NCCL belgelerine başvurabilirsiniz.
Bu, CTA ayarlama gibi çeşitli ayarları içerir ancak protokol veya algoritma ayarlamalarını desteklemez. Bu seçenek, uygulamanızın NCCL katmanına erişim sağlaması halinde kullanılabilir ve çevre değişkenlerinde olduğu gibi yapılandırma yönetiminde sorunlar yaratabilir.
Temel Performansı Sağlamak
NCCL ve sisteminizin doğru bir şekilde ayarlandığından emin olmak, iyi performans elde etmenin anahtarıdır. Tuning seçimleri, temelde düzgün performans sağlanmadığında fayda sağlanamaz. Yaygın sorunlar hakkında bilgi almak için NCCL belgeleme bölümüne göz atın.
Örnek Çalışma: Varsayılan Ayarlama Düzeltmesi
Bu bölüm, örnek bir senaryoda, yanlış algoritma ve protokol seçimlerini düzeltmek için örnek tuner eklentisi kullanımını ele alır.
S-Eğrilerini Analiz Etme
Örnek NCCL S-eğrisi, rapor edilen hat bus bant genişliği veya genel donanım bant genişliği kullanım oranının mesaj boyutuna karşı bir grafiğidir.
Bu, iyi ayarlanmış, temiz bir S-eğrisidir. Bu platformun maksimum 200 GB/s donanım bağlantı hızına ulaşması hedeflenmiştir ve bu hız doygunluğa ulaşmaktadır. Çok küçük mesaj boyutlarında performans gecikmeden etkilenmektedir. Mesaj boyutları arttıkça, bant genişliği kullanımı artar ve sonunda donanımın limitinde düzleşir.
Şekil 2, iyi ayarlanmış bir S-eğrisini, alt optimizasyonlu bir S-eğrisi ile karşılaştırmaktadır.
Mesaj boyutu 2 MB’den 4 MB’ye geçerken performansta net bir düşüş gözlemlenmektedir. Eğer mesaj boyutunu artırdığınızda performansta bir düşüş görüyorsanız, bu ayarlama işlemlerinde kötü bir geçiş noktasının göstergesi olabilir. Ayrıca, 4 MB ile 8 MB arasında ve 128 MB ile 256 MB arasında bant genişliği platoları da gözlemlenmektedir. İyi bir çerçeve içinde, böyle bir durum yaşanmaması beklenir.
Bu tür veriler, NCCL’in belirli mesaj boyutlarında yanlış algoritma ve protokol seçimleri yaptığının güçlü bir işareti olabilir.
Bu sorunu çözmek için öncelikle tunlamanın aslında bir sorun olup olmadığını onaylayın, temel performans kaynaklı bir problem olmadığından emin olun. Sıklıkla NCCL Testleri ile NCCL performansını belirlemek için ilgili çevre değişkenleri ile birlikte bir benchmark yapmalısınız.
Bu grafiklerde, platform performansının bir kök neden olmadığı anlaşılmalıdır. Farklı tunlama parametrelerinin sonuçları da beklenildiği gibi görünmektedir. Bu durumda, muhtemel nedenin yanlış NCCL ayarları olduğu belirlenmiştir.
Sorunu daha iyi anlamak için varsayılan ayar kararlarını plotlayarak genel bir tablo çizebilirsiniz.
Her mesaj boyutunda, NCCL’in en iyi performansı sunan protokolleri ve algoritmaları seçmesini umuyoruz.
Bir Tuner Eklentisi Kullanarak Düzeltme Nasıl Yapılır
Bu ayarları düzeltmek için bir tuner eklentisi kullanmanız gerekir. Tek bir protokol veya algoritma zorlamak herhangi bir şeyi düzeltmeyecektir; çünkü mesaj boyutlarına göre seçim yapmak gereklidir. Dolayısıyla eklenti, en uygun çözüm olacaktır.
Bu örnek, GitHub üzerinde mevcut olan örnek tuner eklentisi kullanılarak gösterilecektir. Eklenti, ayarı bulunan bir CSV tabanlı yapılandırma dosyasından ayar okumaya yarayan bir referans uygulamasıdır. Bu dosya, hedeflemeden her mesaj boyutuna, ölçeğe veya işlemlere yönelik geçersiz kılma sağlanarak eklentinin derlenmesine gerek kalmadan sonuçlar alır.
İlk olarak, ham tunlama verilerini, eklentinin anlayacağı formata dönüştürmelisiniz. Neyse ki, bu eklentinin ham tuning verilerinin CSV geçersiz kılma formatına dönüştürülmesine yardımcı olan bir yapım komutu bulunmaktadır.
make optimize-config CSV_FILE=my_raw_data.csv OUTPUT=my_new_tunings.conf METRIC=latency_us
Auto-ranging enabled: will create one bucket per unique size in data
Loaded 180 performance data points
Dimension 4 nodes, 32 ranks: 30 size ranges from 30 unique sizes:
Range 1: 0 - 12 bytes (6 data points, sizes: 8)
Range 2: 13 - 24 bytes (6 data points, sizes: 16)
Range 3: 25 - 48 bytes (6 data points, sizes: 32)
Range 4: 49 - 96 bytes (6 data points, sizes: 64)
Range 5: 97 - 192 bytes (6 data points, sizes: 128)
Range 6: 193 - 384 bytes (6 data points, sizes: 256)
Range 7: 385 - 768 bytes (6 data points, sizes: 512
...
Combined 30 ranges into 4 ranges (reduced by 26)
Optimal for allreduce [0-98304] nodes=4 ranks=32: tree/ll channels=-1 (latency_us=49.130)
Optimal for allreduce [98305-12582912] nodes=4 ranks=32: tree/ll128 channels=-1 (latency_us=101.400)
Optimal for allreduce [12582913-100663296] nodes=4 ranks=32: ring/ll128 channels=-1 (latency_us=634.800)
Optimal for allreduce [100663297-4294967296] nodes=4 ranks=32: ring/simple channels=-1 (latency_us=2967.600)
...
Creating new file: my_new_tunings.conf
Created my_new_tunings.conf with 30 optimized configurations
Yükleme ve Tunlama Sonuçları
Ardından, oluşturulmuş optimizasyon CSV dosyası ile NCCL’i yeniden çalıştırmalısınız. Tekrar bir all_reduce_perf benchmark’ı yaparak, oluşturulan eklentinin başarıyla yüklendiğini göreceksiniz.
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/Plugin: Plugin name set by env to libnccl-tuner-example.so
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/Plugin: Using tuner plugin Example
f1d6821f5ab3:1075:1081 [0] NCCL INFO Initializing tuner for 4 nodes, 32 ranks
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/ExamplePlugin: Loaded config: allreduce [0-98304] tree/ll channels=-1 nodes=4 ranks=32 pipeOps=any regBuff=any
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/ExamplePlugin: Loaded config: allreduce [98305-12582912] tree/ll128 channels=-1 nodes=4 ranks=32 pipeOps=any regBuff=any
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/ExamplePlugin: Loaded config: allreduce [12582913-100663296] ring/ll128 channels=-1 nodes=32 ranks=8 pipeOps=any regBuff=any
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/ExamplePlugin: Loaded config: allreduce [100663297-4294967296] ring/simple channels=-1 nodes=32 ranks=8 pipeOps=any regBuff=any
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/ExamplePlugin: Loaded 4 tuning configurations from my_new_tunings.conf
Sonuçlar
Şekil 5, ayarlardan sonra her şeyin yoluna girdiğini göstermektedir. Bu, uygulama veya kütüphane kodunu değiştirmeden çözüme ulaşmak isteyen kullanıcılar için iyi bir haberdir.
NCCL Ayarlamaya Başlayın
NCCL ayarlamaları, donanım performansını maksimize etmek ve AI ile HPC iş yüklerinde mesaj boyutları ve görev boyutları arasında bağlantı sağlamak açısından önemlidir. Tuner eklentilerinin avantajlarından faydalanarak, varsayılan ayarların sınırlamalarını aşabilirsiniz.
Bu yazıda sunulan örnek çalışma, örnek tuner eklentisi ile karşılaşabileceğiniz herhangi bir ayarlama sorununu gidermek için bir yol sunar.
Daha fazla bilgi almak için NCCL üzerine, NCCL belgelerini okuyabilir, NCCL yazılımını indirerek deneyimleyebilir ve bu konuyu NVIDIA Geliştirici Forumu’nda tartışabilirsiniz.
İlgili diğer yazılar için:
- NVIDIA Kolektif İletişim Kütüphanesi 2.22 ile Bellek Verimliliği, Daha Hızlı Başlangıç ve Maliyet Tahmini
- NVIDIA Kolektif İletişim Kütüphanesi 2.23 ile Yeni Ölçekleme Algoritması ve Başlatma
- NVIDIA Kolektif İletişim Kütüphanesi 2.24 ile Ağa Bağlı Güvenilirlik ve Gözlemlenebilirlik
- NVIDIA Kolektif İletişim Kütüphanesi 2.26 ile Geliştirilmiş Performans ve İzleme Özellikleri
- NVIDIA Kolektif İletişim Kütüphanesi 2.27 ile Hızlı Çıkış ve Dayanıklı Eğitim İmkanları
