NVIDIA SHARP: Kolektif MPI İşlemlerini Ağın İçinde Toplamak

Dağıtık derin öğrenme eğitiminde GPU’lar ne kadar hızlanırsa hızlansın, her adımda gradyanların toplanması gerekir. Bu toplama işlemi — MPI_Allreduce veya NCCL tarafında ncclAllReduce — ölçek büyüdükçe toplam sürenin belirleyici kalemi hâline gelir. SHARP, bu işlemin bir kısmını sunuculardan alıp switch’in içine taşır.

Problem: all-reduce neden ölçeklenmez?

Klasik bir all-reduce işleminde her düğüm verisini komşularına gönderir, gelen veriyle birleştirir ve sonucu tekrar dağıtır. Ring-allreduce gibi verimli algoritmalarda bile taşınan toplam veri miktarı düğüm sayısıyla birlikte artar ve her düğüm aynı veriyi birden fazla kez görür.

Sonuç şudur: 8 düğümde ihmal edilebilir olan iletişim payı, 256 düğümde adım süresinin yarısını yiyebilir. GPU’ları daha hızlı olanlarla değiştirmek bu tabloyu düzeltmez — tam tersine, hesaplama hızlandıkça iletişimin oransal payı büyür.

SHARP ne yapar?

SHARP (Scalable Hierarchical Aggregation and Reduction Protocol), indirgeme işlemini fabric topolojisi üzerine kurulu bir ağaç hâlinde organize eder. Yaprak düğümlerden gelen veriler leaf switch üzerinde toplanır, kısmi sonuçlar bir üst katmana çıkar, tepede nihai sonuç oluşur ve aynı ağaç üzerinden geri dağıtılır.

Kritik fark: toplama işlemi switch ASIC’i içinde, hat hızında yapılır. Veri, uç noktalar arasında defalarca dolaşmak yerine bir kez yukarı çıkar, bir kez aşağı iner.

Pratik sonuçları:

• Taşınan veri miktarı düşer. Aynı sonucu üretmek için fabric üzerinde daha az bayt hareket eder.
• Atlama sayısı sabitlenir. İndirgeme süresi düğüm sayısıyla doğrusal değil, ağaç derinliğiyle — yani logaritmik olarak — büyür.
• CPU ve GPU serbest kalır. İndirgeme aritmetiği uç noktada değil ağda yapıldığı için hesaplama kaynakları asıl işe ayrılır.

Nesiller: SHARPv1’den SHARPv4’e

Buradaki en önemli kırılma SHARPv2’dir: küçük mesajlarda bariyer hızlandırmanın ötesine geçilip büyük vektörlerin hat hızında toplanması mümkün hâle geldi. Gradyan senkronizasyonu tam olarak bu profile girer, bu yüzden SHARP’ın makine öğrenmesiyle anılması bu sürümle başlar.

SHARPv3’ün çoklu ağaç desteği ise paylaşımlı kümelerde önemlidir: aynı fabric üzerinde farklı işler kendi indirgeme ağaçlarını kurar ve birbirlerini beklemez.

Neye ihtiyaç var?

SHARP, tek bir ayar değil bir yığın gereksinimidir:

1. Destekleyen switch. NVIDIA Quantum, Quantum-2 veya Quantum-X800 ailesi. HDR neslinde QM8700/QM8790, NDR’de QM9700/QM9790, XDR’de Q3400-RA/Q3200-RA.
2. Aggregation Manager. SHARP ağaçlarını kuran ve yöneten servis. Yönetilebilir switch üzerinde veya küme içindeki bir sunucuda çalışır.
3. Subnet Manager ile uyum. Ağaç topolojisi fabric’in gerçek topolojisine göre kurulduğu için SM’nin sağlıklı ve tutarlı olması şarttır.
4. Uygulama tarafı destek. NCCL ve HPC-X/Open MPI, SHARP’ı arka planda kullanabilir. Uygulama kodunda değişiklik gerekmez; iş, kütüphane katmanında halledilir.

Etkinleştirme ve doğrulama

Kurulum sırası kabaca şudur: Aggregation Manager servisi ayağa kaldırılır, fabric taranır ve ağaçlar oluşturulur, ardından kolektif kütüphanesi SHARP kullanacak şekilde yapılandırılır.

NCCL tarafında ilgili eklentinin yüklü olması ve etkinleştirilmesi gerekir. Doğrulamanın en pratik yolu NCCL’in hata ayıklama çıktısını açıp kolektif işlemin hangi algoritmayı seçtiğine bakmaktır — SHARP devredeyse bu çıktıda görünür.

# NCCL hangi algoritmayı seçiyor?
export NCCL_DEBUG=INFO
export NCCL_DEBUG_SUBSYS=INIT,COLL
mpirun -np 16 ./all_reduce_perf -b 8 -e 2G -f 2 -g 1

nccl-tests içindeki all_reduce_perf, SHARP kazancını ölçmenin standart yoludur. Ölçümü iki kez çalıştırın: bir kez SHARP kapalı, bir kez açık. Karşılaştırmayı aynı düğüm kümesinde ve aynı mesaj boyutu aralığında yapın; aksi hâlde sonuç yanıltıcı olur.

Kazanç ne kadar? Dürüst cevap

SHARP’ın kazancı sabit bir yüzde değildir. Belirleyen üç faktör var:

Ölçek. 8 düğümde fark genelde gürültü seviyesindedir. Kazanç düğüm sayısı arttıkça belirginleşir — SHARP’ın varlık sebebi zaten budur.

Mesaj boyutu. Çok küçük mesajlarda gecikme baskındır ve kazanç sınırlıdır. Çok büyük mesajlarda bant genişliği baskın olur. En belirgin fayda genellikle aradaki geniş bantta görülür.

İletişim payı. Adım süresinin %10’u iletişimse, iletişimi yarıya indirmek toplam süreyi en fazla %5 kısaltır. Amdahl yasası burada da geçerlidir.

Bu yüzden “SHARP %30 hızlandırır” gibi genel cümlelere ihtiyatla yaklaşın. Doğru yaklaşım, kendi iş yükünüzde nccl-tests ile A/B ölçümü yapmak ve kararı kendi sayılarınızla vermektir.

Sık karşılaşılan sorunlar

SHARP devrede görünmüyor. En yaygın sebep, Aggregation Manager’ın çalışmaması veya fabric’i tarayamamasıdır. İkinci sıklıkta: NCCL eklentisinin yüklü olmaması.

Ağaç kurulamıyor. Topoloji SHARP’ın beklediği yapıya uymuyorsa ağaç oluşmaz. Karışık hız katmanlı veya düzensiz fat-tree’lerde bu sorun görülebilir.

Bazı işlerde çalışıyor, bazılarında çalışmıyor. Paylaşımlı kümelerde eş zamanlı ağaç sayısı sınırlıdır. SHARPv3 öncesi nesillerde bu sınır daha dardır.

Ölçümde fark yok. Çoğu zaman gerçek bir sorun değildir: iş yükünüzün iletişim payı düşüktür ya da ölçek SHARP’ın fark yaratacağı seviyenin altındadır.

Mevasis fabric tasarım ve devreye alma

SHARP, doğru topoloji ve sağlıklı bir subnet manager üzerine kurulur; switch satın almakla otomatik olarak gelmez. Mevasis, InfiniBand switch tedarikinin yanı sıra fabric topolojisinin SHARP’a uygun planlanmasını, Aggregation Manager kurulumunu ve nccl-tests ile öncesi/sonrası ölçüm raporunu devreye alma kapsamında sunar.

Kümenizin ölçeğini ve iş yükü profilini paylaşın, SHARP’ın sizin durumunuzda anlamlı bir kazanç üretip üretmeyeceğini birlikte değerlendirelim — iletişime geçin.

Sıkça Sorulan Sorular

SHARP için uygulama kodumu değiştirmem gerekir mi? Hayır. NCCL ve HPC-X/Open MPI, SHARP’ı kolektif işlem katmanında şeffaf biçimde kullanır. Uygulama MPI_Allreduce veya ncclAllReduce çağırmaya devam eder.

Yönetilemez switch (QM8790, QM9790) ile SHARP çalışır mı? Switch donanımı destekler, ancak Aggregation Manager’ın bir yerde çalışması gerekir. Yönetilebilir switch yoksa bu servis küme içindeki bir sunucuda çalıştırılır.

SHARP ile uyarlamalı yönlendirme birlikte kullanılabilir mi? Evet, ikisi farklı katmanlarda çalışır. Uyarlamalı yönlendirme noktadan noktaya trafiği dağıtır, SHARP kolektif işlemleri ağaç üzerinde toplar.

Tek düğümde çok GPU’lu eğitimde SHARP fark yaratır mı? Hayır. Düğüm içi iletişim NVLink üzerinden gider ve fabric’e çıkmaz. SHARP’ın devreye girdiği yer düğümler arası kolektif trafiktir.