Yüksek performanslı GPU kümeleri üzerinde AI modellerini eğitmek, model oluşturucular için önemli zorluklar sunmaktadır. İşlerin ölçeği arttıkça manuel müdahalelerin pratik olmaktan çıktığı bu süreçte, otomasyon yüksek GPU kullanımını ve eğitimin verimliliğini korumak için kritik bir rol oynamaktadır. **Mükemmel bir eğitim deneyimi**, düşük gecikmeli hata atfı ve kök neden analizi temellinde otomatik hata kurtarma süreçlerine ihtiyaç duyar.
Otomasyon yeni bir kavram değil. Sağlık kontrolü, ön kontrol, sistem günlükleri (syslogs) ve telemetri gibi çeşitli donanım ve yazılım bileşenleri için mevcut araçlar bulunmaktadır. Ancak, çoğu zaman bu araçlar son kullanıcılar için **kapsamlı bir şekilde erişilemez** ve ilk müdahale aracı olarak kullanılmaları zor olmaktadır.
Birçok durumda, model oluşturucular eğitimin herhangi bir aşamasında sorunlarla en önce karşılaşan kişiler olmaktadır. Hataları değerlendirmek için gereken verileri toplamak üzere altyapı ve operasyon ekipleri ile iletişime geçmek zorunda kalmaktadırlar; örneğin, bir hatanın donanım veya yazılım kaynaklı olup olmadığını ya da **geçici mi yoksa kalıcı mı** olduğunu anlayabilmek için.
Bu pahalı manuel müdahale süreci, genel geliştirme döngülerini yavaşlatmakta ve hızlı deneyler yapma yeteneğini engellemektedir. Araştırmacılar deneyimlerini ölçeklendirdikçe, sistemler arasındaki karmaşık ilişki bu durumu daha da zorlaştırmaktadır. Bu yazıda, NVIDIA DGX Cloud üzerinde büyük dil modellerinin (LLM’ler) güvenilir ve verimli bir şekilde eğitilmesi üzerindeki bazı zorlukları ele alacağız. Ayrıca, daha dayanıklı bir eğitim sağlama fırsatlarını vurgulayacak ve DGX Cloud’un 2K-10K GPU ölçeğindeki eğitim süreçlerinde %1’in altında donanım kesintisi yaşama başarısını elde etmenin bazı yollarını göstereceğiz.
Kesintiyi Azaltmak
Bir model oluşturucu olarak eğitim sırasında bir hata ile karşılaştığınızda, temel zorluk nedenin belirlenmesi, sorunun yerinin bulunması ve işi ilerletmek için bir yol bulmaktır. Bu gecikme, mühendis müdahalesinin gerektiği ortamlarda daha da artmakta, genellikle sorunları belirleme ve düzeltme süreçleri saatler alabilmektedir. **Bu müdahaleler ve gecikmeler**, verimlilik üzerinde önemli bir etki yarattığı için eğitim sürecine tekrar dönebilmek için zamanınızı ölçen bir metrik olması kritik öneme sahiptir.
Geleneksel metrikler, donanım kullanımını temsil eden **MFU** (Maaş Kullanım Oranı) ve ortalama arıza süresini ölçen **MTTF** (Arıza Arası Ortalama Süre) gibi istatistikler, altyapı verimliliğine odaklanmaktadır. Ancak, bunlar yaşanan sorunların, kaybedilen işin ve yeniden başlatma gibi vakaların doğru bir yansımasını sağlamamaktadır.
Gerçek dünya maliyetlerini ve sorunları yakalamak için, **kesinti** üzerinde durmak gerekmektedir; yani, model oluşturucunun bakış açısına göre toplam verimsiz eğitim süresi. Bu kesinti aşağıdakileri içerir:
- Kontrol zamanları: Eğitim döngüsü kontrol kaydetmek için engellenir.
- Kaybolan iş: Son kontrol noktasından sonra kapanma ile kaybedilen iterasyonlar.
- Kapatma zamanı: Son iterasyondan sistem durana kadar geçen süre.
- Yeniden başlatma zamanı: İşin başlatılmasından üretken eğitimin yeniden başladığı ana kadar geçen süre.
Bu unsurlar, bir donanım veya altyapı arızası gerçekleştiğinde etkilenmektedir. Bu nedenle, geliştirici deneyimini iyileştirmeye çalışırken kesinti en önemli metrik olmalıdır.
Kesintileri azaltmak için, eğitim süresince hem reaktif hem de proaktif sistemlere ihtiyaç vardır. **Büyük ölçeklerde**, hatalar kaçınılmazdır ve tespit ve kurtarma süresinin hızı son derece kritik öneme sahiptir. Uygulama ve donanım arızaları için hata atfedilmesi temel noktadır.
Hata Atfı
Hata atfı konusunda, araştırmacıların karşılaştığı hata türlerini genel olarak şu şekilde sınıflandırabiliriz:
- Anlık çöküşler: Donanım arızalarından kaynaklanır; örneğin, BIOS, güç kaynağı veya ısınma sorunları, düzeltilmesi mümkün olmayan ECC hataları, sessiz veri bozulmaları (örneğin, geçici sonuçlarda NaN’lar) veya ağ kararsızlıkları (bağlantı kopmaları).
- İletişim kütüphanelerinde durmalar: Genellikle PyTorch NCCL gözlemci hataları ve Transformer Motoru iletişim problemleri olarak kendini gösterir. İletişim durmaları sıklıkla dosya sisteminden (örneğin, giriş verisi) ve tensörlerden (örneğin, gradyanlar, ara aktivasyonlar vb.) veri transferindeki bağımlılıklardan kaynaklanır. Bu durum, kütüphaneler ve uygulamalarda sağlam hata toleransı, içerme ve erken algılama mekanizmalarının önemini vurgular.
- Hız regresyonları: Geçici yavaşlama (örneğin, geçici ağ ya da depolama sorunları) ve kalıcı darboğazlar (örneğin, büyük bir kümede sürekli yavaş çalışan bir GPU) içerir. Bu regresyonlar, genel eğitim hızını ve verimliliği önemli ölçüde etkileyebilir.
Bunlar gibi arızalar, kaynağı donanım, altyapı veya yazılım sorunlarından kaynaklansa da, genellikle **eğitim süreci** sırasında ani kesintiler veya belirgin yavaşlamalar şeklinde hissedilmektedir. Bu yaygın hata türlerini tanımlayarak, araştırmacıların isteklerini sürdürmelerini sağlamak amacıyla daha iyi çözümler ve süreçler geliştirilebilir.
Küme Telemetri Verileri
Bu telemetri, depolama sunucularını, veri yönetimi ve okuma/yazma işlemlerini kapsamaktadır. Bir düğümdeki bir arıza, iletişim çağrıları yoluyla diğer düğümlere yayılabileceğinden, bu ölçümler son derece önemlidir.
Örneğin, bir işleme aşırı metadata işlemleri üreten tek bir iş, diğer işlerin veya düğümlerin performansında sorunlar yaratabilir.
Düğüm Telemetri Verileri
Düğüm seviyesinde düzenli yapılan sağlık kontrolleri, GPU’lar, CPU’lar, bellek, ağ, depolama ve hizmetler gibi kritik donanım ve yazılım bileşenlerinin düzgün çalıştığını doğrulamak için önemlidir. İş başlamadan önce yapılan ön kontroller, donanım durumunu doğrulamak, yazılım bağımlılıklarını kesinleştirmek ve göreve uygun ortamı yapılandırmak amacıyla gerçekleştirilir.
Bu tür sorunların erken tespit edilmesi, hata ayıklama süresini azaltmakta ve genel güvenilirliği artırmaktadır.
Uygulama Günlükleri
Uygulamalar, kritik kontrol noktaları, duraksamaları ve ilerleme ölçümlerine yönelik önemli bilgilere sahiptir. Bu günlükler, hata atfındaki en güçlü sinyallerden birini sağlamakta, zamanla tekrar eden hataları tespit etmek için merkezi bir veri havuzuyla korele edildiğinde etkili sonuçlar ortaya çıkarmaktadır.
Örneğin, bu günlükler, eğer içerisinde gecikmeler, duraklamalar ya da hataların sürekliliği varsa, belirlenmesine yardımcı olmaktadır. NaN hatası gibi belirli hatalar, aynı iterasyonda ve aynı randevuda farklı fiziksel düğümlerde beliriyorsa, genellikle bir uygulama hatasıdır. Ancak, böyle bir kalıbı olmayan bir düğüm üzerindeki yeniden ortaya çıkan bir hata, daha ciddi bir donanım arızasını gösterebilir.
Birleşik Telemetri
Bu verilerin, hem iş içi (single-job) hem de işler arası (multiple-job) bağlamlarda analiz edilmesi, tekrar eden sorunların belirlenmesine, kalıpların tespit edilmesine ve proaktif önlemlerin alınmasına yardımcı olur.
Bu birleşik telemetri, hem operasyon ekiplerine hem de araştırmacılara öneriler, uyarılar ve görselleştirmeler aracılığıyla sunulmakta; her iki grubun da sistem davranışları ve hata kalıpları hakkında ortak bir görünüm elde etmesini sağlamaktadır.
Bu şekilde elde edilen verimlilik, daha az müdahaleyle sorunların çözülmesini sağlarken, altyapı verilerinin kullanımıyla da hata ayıklamayı geliştirmektedir.
Kesintiler büyük ölçek ile orantılıdır; ancak, 10K GPU’ların altında yapılan eğitim koşullarında, bu teknikler sayesinde %1’in altında donanım kesintisi oranı elde edilmiştir. Sonuçlarımız, 2024-2025 yılları arasında Nemotron model ailesinin eğitim süreçlerinde NVIDIA DGX Cloud üzerinde gerçekleştirilmiştir.
Sonuç
Elde edilen sonuçlar, uçtan uca dayanıklılığın bütünsel bir görüş gerektirdiğini ortaya koymaktadır. Yüksek uptime, hem altyapıyı hem de geliştirici deneyimini kapsayan kapsamlı bir yaklaşım ile mümkündür.
Bu yaklaşım, uygulama ve altyapı arasında bir köprü kurarak, hata ayıklama süresini ve doğruluğunu artırmakta ve daha proaktif bir sistemin kurulmasına olanak tanımaktadır. Araştırmacıların, hata durumunda hızlı bir şekilde sorunları çözmelerini sağlarken, tekrar eden problemleri tespit etme sürecini de azaltmaktadır.
Model oluşturucular için etkili otomasyon imkanı oluşturan sağlam bir hata atfı sistemi, bu tür eğitim sürelerinde sürekli izleme gereksinimini ortadan kaldırmaktadır. **Daha yüksek GPU verimliliği sağlamakla kalmaz**, aynı zamanda araştırmacıların esas olarak üzerlerinde çalışması gereken şeylere odaklanmalarını sağlayarak **bilimleri ilerletmelerine** imkan tanır.
Daha fazla bilgi için DGX Cloud’daki eğitim dayanıklılığı hizmetleri hakkında Eğitim Dayanıklılığı ve Aşırı Ölçekte Verimlilik Sağlama başlıklı GTC oturumuna kaydolabilirsiniz. Eğitim öncesi ve sonrası iş yüklerinizi hızlandırma yöntemleri için ise bizimle iletişime geçebilirsiniz.
