Docker ve Özel İmajlarla Bulut GPU Sağlayıcıları

GPU kiraladığınızda “Docker desteği” aslında ne anlama gelir

Bir bulut GPU sağlayıcısı Docker desteği sunduğunu reklam ettiğinde, bu, iş yükünüzü konteyner imajı içinde çalıştırabileceğiniz anlamına gelir; böylece ana işletim sistemi, sürücü yığını ve kütüphanelere bağlı kalmazsınız. Pratikte bu, bir GPU örneğinin yeniden üretilebilir olmasını sağlar: taze bir kutuya SSH ile bağlanıp CUDA, cuDNN, PyTorch ve bir düzine Python paketini elle kurmak yerine, örneği ihtiyacınız olan tam sürümleri içeren bir imaja yönlendirirsiniz ve her seferinde bilinen iyi bir ortamda başlatılır.

GPU’lara özgü önemli bir nüans vardır. Bir konteyner GPU’nun kendisini sanallaştırmaz — ana makine hala NVIDIA sürücüsüne sahiptir ve donanımı NVIDIA Container Toolkit aracılığıyla konteynere sunar. Bu, imajın CUDA çalışma zamanı, cuDNN ve framework’lerinizi taşıdığı, ana makinenin ise çekirdek sürücüsünü taşıdığı anlamına gelir. İkisinin sadece uyumlu olması gerekir, aynı olması gerekmez; çünkü CUDA belirli bir aralıkta ileriye dönük uyumluluk sunar. Bu yüzden iyi hazırlanmış bir imaj, yukarıdaki listede farklı zamanlarda ve biraz farklı sürücü sürümleriyle sağlanmış birçok farklı ana makinede değişmeden çalışabilir.

Yukarıdaki karşılaştırmadaki sağlayıcılar bu yeteneği birkaç farklı şekilde sunar ve bu fark önemlidir:

• Kendi imajını getir: bir kayıt URL’si (genel veya özel imaj) sağlarsınız ve platform bunu çekip örneğin kök ortamı olarak başlatır.
• Temel imaj içinde çalıştır: zaten satıcı tarafından yönetilen bir CUDA konteyneri içinde yaşayan bir SSH veya Jupyter oturumu alırsınız ve kodunuzu üzerine katmanlarsınız.
• Tam root Docker daemon: örnekte gerçek docker (veya rootless eşdeğeri) erişimi elde edersiniz, böylece birden çok konteyneri kendiniz oluşturabilir, çekebilir ve çalıştırabilirsiniz.

Gerçek GPU iş yükleri için konteynerlerin önemi

Yeniden üretilebilirlik en önemli fayda olsa da, Docker desteği kiralık donanımda günlük ekonomik durumu birkaç somut şekilde değiştirir.

• Hızlı, öngörülebilir başlatma: spot veya kesintili kapasitede bir örnek kaybolabilir ve başka yerde yeniden başlatılır. Önceden hazırlanmış bir imaj, tüm ortamı yeniden kurmak yerine birkaç dakika içinde çalışan bir eğitimciye dönmenizi sağlar, bu da doğrudan faturalandırılabilir boşa geçen zamanı azaltır.
• Sürüm sabitleme: AI yığınları CUDA, framework ve FlashAttention veya bitsandbytes gibi özel çekirdekler arasındaki uyumsuzluklara karşı son derece hassastır. Tam sürümleri imaja dahil etmek, ana makineler arasında geçiş yaparken “benim makinemde çalışıyor” hatalarını ortadan kaldırır.
• Sağlayıcılar arasında taşınabilirlik: aynı imaj, yukarıdaki listede o gün en ucuz veya stokta olan ana makinede çalışır, böylece tek bir satıcının önceden yüklenmiş yazılımına bağlı kalmazsınız.
• İzolasyon: paylaşılan temel işletim sisteminde çakışacak bağımlılıklar, ayrı imajlarda temizce bir arada bulunabilir; bu, bir düğümün birden fazla model veya deneye hizmet ettiği durumlarda faydalıdır.

En çok fayda sağlayan iş akışları yinelemeli eğitim ve ince ayar çalışmaları, gerçek GPU’larda model kodunu test eden CI boru hatları ve dağıtmayı planladığınız çıkarım servisleridir — çünkü test ettiğiniz konteyner byte byte dağıttığınız konteynerdir. Bir defaya mahsus etkileşimli bir deney için avantaj daha küçüktür, çünkü satıcı tabanlı imaj zaten yaygın durumu kapsar.

Dikkat edilmesi gereken ödünler

Konteynerler kiralık GPU’larda sürtünmesiz değildir. Büyük imajlar — çok gigabaytlık CUDA tabanları ve model ağırlıkları — ilk başlatmada çekmek zaman alır ve indirilirken örnek için ödeme yaparsınız. Önbellek katmanları kullanmak, tam geliştirme imajları yerine daha ince çalışma zamanı tabanları kullanmak ve ağırlıkları imaj içinde değil, bağlanmış bir hacimde depolamak yardımcı olur. Ayrıca, daha yeni bir CUDA araç seti ile oluşturulmuş bir imajın daha eski sürücüye sahip bir ana makinede çalışmayı reddetmesi gibi gerçek bir hata durumu vardır; uzun bir çalışmaya başlamadan önce sürücü/CUDA eşlemesini kontrol etmek sürpriz bir çöküşü önler.

Kiralamadan önce bu boyutta ne kontrol edilmeli

İki örnek Docker desteği olduğunu iddia edebilir ama çok farklı davranabilir. Yukarıdaki karşılaştırmayı okurken basit evet’in ötesine bakın ve detayları doğrulayın:

• Özel imaj mı yoksa sadece temel imaj mı: kendi kaydınızdan rastgele bir imaj itebilir misiniz yoksa sağlayıcının seçilmiş tabanlarıyla mı sınırlısınız? Özel imaj desteği daha esnek ve taşınabilir bir seçenektir.
• Root mu rootless Docker mı: konteynerleri oluşturup çalıştırmak için gerçekten docker daemonuna mı erişiyorsunuz yoksa sadece konteynerize edilmiş bir ortam mı var? Kutuda imaj oluşturmak için ilki gerekir.
• Özel kayıt doğrulaması: özel bir kayıt defterinden kimlik bilgileriyle çekebilir misiniz, bu da özel kod ve ağırlıklar için önemlidir?
• GPU geçiş bayrakları: platformun NVIDIA Container Toolkit’i bağladığını doğrulayın, böylece konteyner GPU’yu görür; yoksa konteyner içinde nvidia-smi başarısız olur.
• Ana makinedeki sürücü ve CUDA sürümü: uyumlu bir CUDA tabanı hedefleyebilmek ve sürüm uyumsuzluğu hatalarını önlemek için yüklü sürücüyü kontrol edin.
• Kalıcı hacimler: veri setleri, kontrol noktaları ve imaj önbellekleri için yeniden başlatma sonrası da kalan depolamayı bağlayabildiğinizi doğrulayın, böylece her kesintiden sonra her şeyi yeniden çekmek zorunda kalmazsınız.
• Çoklu konteyner ve Compose: iş yükünüz bir model sunucusu artı bir veritabanı veya vektör deposu gerektiriyorsa, sadece bir değil birden çok konteyner çalıştırıp çalıştıramayacağınızı doğrulayın.

İyi kullanıldığında, Docker desteği kiralık GPU’yu elle yapılandırılmış bir evcil hayvandan atılabilir, yeniden üretilebilir bir çalışma zamanına dönüştürür — bu, kapasite kesintiye uğrayabilir ve saniye bazında ödeme yapıyorsanız tam da istediğiniz şeydir.

Sıkça sorulan sorular

Docker desteği, Docker daemonuna tam root erişimi aldığım anlamına mı geliyor?

Her zaman değil. Bazı platformlar oturumunuzu önceden yapılandırılmış bir CUDA konteyneri içinde çalıştırırken, diğerleri konteynerleri kendiniz oluşturup çalıştırabilmeniz için gerçek root erişimi verir. Kutuda imaj oluşturmanız veya birden çok konteyner çalıştırmanız gerekiyorsa, listelemenin sadece konteynerize edilmiş bir temel ortam değil, tam daemon erişimi sunduğunu doğrulayın.

GPU sürücüsünü Docker imajımın içine koymam gerekiyor mu?

Hayır. Ana makine çekirdek seviyesinde NVIDIA sürücüsüne sahiptir ve GPU, NVIDIA Container Toolkit aracılığıyla konteynere sunulur. İmajınız CUDA çalışma zamanı, cuDNN ve framework’lerinizi içermeli, ancak sürücüyü içermemelidir. Sadece imajın CUDA sürümünün ana makinenin sürücüsüyle uyumlu olması gerekir; bu yüzden uzun bir çalışmaya başlamadan önce ana makinenin sürücü sürümünü kontrol etmek faydalıdır.

Özel imajım yeni bir GPU örneğinde anında başlar mı?

İlk başlatmada imaj çekilmek zorundadır ve çok gigabaytlık CUDA imajlarının indirilmesi zaman alır — bu süre için ücretlendirilirsiniz. Sonrasında önbelleğe alınmış katmanlar sonraki başlatmaları çok daha hızlı yapar. İmajları hafif tutmak, tam geliştirme tabanları yerine çalışma zamanı tabanları kullanmak ve büyük model ağırlıklarını imaja dahil etmek yerine kalıcı depolamadan bağlamak başlatmayı kısaltır.

Aynı imajı yukarıdaki farklı sağlayıcılarda çalıştırabilir miyim?

Genellikle evet ve bu taşınabilirlik konteynerleştirmenin başlıca nedenlerinden biridir. Uygun şekilde oluşturulmuş bir imaj, uyumlu sürücü olan her yerde değişmeden çalışır, böylece ortamınızı yeniden oluşturmak zorunda kalmadan sağlayıcılar arasında en ucuz kapasiteyi takip edebilirsiniz. Ana uyarı CUDA ile sürücü uyumluluğudur; bu yüzden her ana makinenin sürücüsünün imajınızın CUDA sürümünü desteklediğini doğrulayın.