NVIDIA GPU kümelerinin işletim sürecini açıkladı

NVIDIA, Kubernetes tabanlı GPU kümelerinde kurulumdan iş yükü performansının doğrulanmasına, arıza takibinden yeniden doğrulamaya uzanan DSX OS işletim sürecini açıkladı.

NVIDIA, 5 Kasım'da yayımladığı teknik blog yazısında NVIDIA AI Cluster Runtime (AICR), NVIDIA Cluster Readiness Engine (NVCRE) ve NVSentinel'in görevlerini ve birlikte nasıl çalıştıklarını anlattı. DSX OS ayrı bir Linux dağıtımı değil, DSX AI Factory platformuna dahil açık kaynaklı bir yazılım katmanı.

AICR; sürücüler, ağ ve depolama gibi küme bileşenlerinin sürümlerini, bağımlılıklarını ve durum kontrol koşullarını bir yapılandırma dosyasında tanımlıyor. Operatörler bu bilgilerle kümeye uygulanacak bir reçete oluşturuyor.

AICR, reçeteyi Helm, Argo CD ve Flux gibi mevcut dağıtım araçlarının kullanabileceği çıktılara dönüştürüyor. Yapılandırma oluşturup doğrulayabiliyor ve mevcut küme yapılandırmasının referans ayarlardan sapıp sapmadığını kontrol edebiliyor. Uygulama ve değişikliklerin yönetimi ise dağıtım araçlarının sorumluluğunda.

NVCRE, GPU'ları, ağı ve depolamayı gerçek iş yükleriyle sın sın test ediyor. Birden fazla GPU arasındaki iletişimi kontrol eden NCCL testlerini ve yapay zeka eğitim işlerini çalıştırıyor; başarısız olan düğümleri ve başarısızlık nedenlerini kaydediyor.

NVIDIA, genel durum kontrollerinin birden fazla düğümün birlikte yürüttüğü eğitim işlerinin performansını doğrulamakta yetersiz kalabileceğini belirtti. Performans eşikleri varsayılan olarak sunulmuyor; operatörlerin değerlendirme ölçütlerini kendilerinin belirlemesi gerekiyor.

Bu ölçütler belirlenmezse hedef performansa ulaşamayan bir düğüm, test çalıştırıldığı için başarılı sayılabilir. Blogda verilen bant genişliği eşik değerleri bir yapılandırma örneği; gerçek bir kümede ölçülmüş performans sonucu değil.

NVCRE test sonuçlarını sunuyor, ancak düğümleri kendisi karantinaya almıyor veya durumlarını değiştirmiyor. Sonuçlara göre bir düğümün işletim durumunda değişiklik yapmak için ayrı prosedür ve yapılandırma gerekiyor.

NVSentinel; GPU durumunu, Xid hatalarını, ağ arayüzlerinin durumunu ve bulut sağlayıcılarının bakım sinyallerini izliyor. Arıza belirtilerini operatörlere bildirme görevini de üstleniyor.

NVSentinel'in varsayılan ayarı izleme modu. Hata tespit etse bile düğümü otomatik olarak karantinaya almıyor, işleri durdurmuyor veya kurtarma işlemi başlatmıyor.

Operatörler karantina kurallarını ve kurtarma özelliklerini yapılandırırsa sorunlu düğümü iş atamalarından çıkarabilir, onarımın ardından NVCRE test sonuçlarına göre yeniden devreye alabilir. Bu işlemler varsayılan olarak etkin değil; operatörlerin bunları açması gerekiyor.

Yaşam döngüsü doğrulaması etkinleştirildiğinde NVSentinel, yeni bir düğüm eklendiğinde veya onarılan bir düğüm geri döndüğünde doğrulama talep edebiliyor. Buna karşılık mevcut bir düğümün sürücüsü, operatörü veya fabric bileşeni değiştirildikten sonra operatörün düğümü iş atamalarından çıkarması ve ayrıca doğrulama talep etmesi gerekiyor.

AICR, NVCRE ve NVSentinel Apache 2.0 lisansıyla yayımlandı. NVIDIA, 21 Ekim tarihli basın açıklamasında NVCRE'yi DSX OS'nin diğer bileşenleriyle birlikte geliştirici önizlemesi olarak tanıttı.

AICR belgelerinde reçetelerin durumu 'önizleme' ve 'desteklenen' olarak ayrılıyor. NVCRE'nin açık kaynak deposunda görünen en güncel sürüm, 2 Kasım'da yayımlanan v0.10.0. Sürüm notlarında, kimlik doğrulama CRD'lerinin Kubernetes 1.29-1.33 sürümlerinde kurulmasını sağlayan bir değişiklik yer alıyor.

TokenPost, daha önce AICR ile Dynamo dağıtım ve doğrulama sürecini ve dağıtık eğitim işlerinin kesintisini algılayıp yeniden başlatmayı yöneten aracı haberleştirdi. Bu kılavuz, küme yapılandırmasını, iş yükü testlerini ve arıza sonrası düğümlerin yeniden devreye alınmasını tek bir işletim akışı içinde ele alıyor.

Teknik blog üç aracın nasıl kullanılacağını açıklıyor; ancak uygulama öncesi ve sonrası küme verimliliğinin ne ölçüde değiştiğini gösteren karşılaştırmalı veriler sunmuyor.