Paylaşımlı Şirket İçi Yapay Zeka Altyapısı İçin GPU Sanallaştırma

Kurumsal Yapay Zekada GPU Kullanım Sorunu

Çoğu kurumsal şirket içi GPU kümesi şaşırtıcı derecede düşük ortalama kullanımla çalışır. Bireysel ekipler iş yükleri için ayrılmış GPU'lar talep eder, bu GPU'lar çıkarım patlamaları veya eğitim çalıştırmaları arasında boşta kalır ve kuruluş zamanının çoğunu hiçbir şey yapmayarak geçiren pahalı donanım için ödeme yapar. Sanallaştırma olmayan ortamlarda %15-30 kullanım oranları yaygındır.

GPU sanallaştırma, birden fazla iş yükünün tek bir fiziksel GPU'yu güvenli bir şekilde paylaşmasına olanak tanıyarak bu sorunu çözer; bir ekibin iş yükünün diğerinin performansını etkilemesini veya bellek alanına erişmesini önleyen izolasyon garantileriyle. Teknoloji önemli ölçüde olgunlaşmıştır ve modern NVIDIA GPU'lar, izolasyon gereksinimlerinize, iş yükü özelliklerinize ve donanım nesillerine bağlı olarak birden fazla yaklaşım sunar.

Doğru sanallaştırma stratejisini seçmek, izolasyon gücü, zamanlama esnekliği ve performans yükü arasındaki dengeleri anlamayı gerektirir. Tek bir en iyi yaklaşım yoktur; çoğu üretim ortamı, farklı iş yükü türleriyle eşleştirilmiş tekniklerin bir kombinasyonunu kullanır.

Multi-Instance GPU (MIG): Donanım Seviyesinde Bölümleme

NVIDIA A100, A30, H100 ve daha yeni mimarilerde kullanılabilen Multi-Instance GPU, tek bir fiziksel GPU'yu donanım seviyesinde yedi bağımsız örneğe kadar böler. Her örnek ayrılmış hesaplama birimleri, bellek bant genişliği ve L2 önbellek alır. Bir örnekteki arıza diğerini etkileyemez çünkü izolasyon GPU donanımının kendisi tarafından sağlanır.

MIG, garantili performans gerektiren ancak tam bir GPU'ya ihtiyaç duymayan çıkarım iş yükleri için idealdir. Tek bir H100, her biri diğer bölümlerin ne yaptığından etkilenmeyen öngörülebilir gecikme özelliklerine sahip yedi farklı modele aynı anda hizmet verecek şekilde bölünebilir. Bu, MIG'i gecikme tutarlılığının ham verimden daha önemli olduğu SLA'ya bağlı üretim çıkarımı için çok uygun kılar.

Dezavantajı katılıktır. MIG bölümleri statik olarak yapılandırılmalıdır ve GPU üzerindeki tüm iş yükleri durdurulmadan yeniden boyutlandırılamaz. Bölüm boyutları sabit profilleri takip eder (H100'de 1g, 2g, 3g, 4g, 7g), bu nedenle keyfi bölmeler oluşturamazsınız. MIG tahsislerini planlamak, iş yükü bellek ve hesaplama gereksinimlerinizi önceden anlamayı gerektirir.

Pratikte, MIG profillerini önceki dönemden gelen iş yükü talep kalıplarına dayalı olarak bakım pencereleri sırasında yapılandırın. Gecikmeye duyarlı üretim modelleri için daha büyük profiller (3g veya 4g) ayırın ve geliştirme, test veya düşük trafikli dahili hizmetler için daha küçük profiller (1g veya 2g) kullanın.

vGPU: Hipervizör Aracılı Paylaşım

NVIDIA vGPU (Sanal GPU), sanal makinelere sanal GPU cihazları sunmak için bir hipervizör katmanı kullanır. Her VM ayrılmış bir GPU gibi görünen bir şey görür, ancak fiziksel GPU, NVIDIA vGPU yazılımı tarafından yönetilen zaman bölümlü çoğullama yoluyla birden fazla VM arasında paylaşılır.

vGPU'nun birincil avantajı mevcut sanallaştırma altyapısıyla entegrasyondur. Kuruluşunuz zaten VMware vSphere, KVM veya Citrix Hypervisor çalıştırıyorsa, vGPU aynı yönetim paradigmasını GPU kaynaklarına genişletir. BT ekipleri tanıdık araçlar aracılığıyla GPU kapasitesini tahsis edebilir, aynı güvenlik politikalarını uygulayabilir ve GPU kaynaklarını birleşik orkestrasyonda CPU ve bellekle birlikte yönetebilir.

Yük ölçülebilirdir: iş yükü özelliklerine ve çekişme seviyelerine bağlı olarak bare-metal erişime kıyasla %5-15 performans düşüşü bekleyin. Çıkarım iş yükleri için bu yük genellikle kabul edilebilir. Mevcut her FLOP'a ihtiyaç duyan büyük ölçekli eğitim çalıştırmaları için vGPU, orantılı fayda olmadan maliyet ekler.

vGPU lisanslaması donanımın ötesinde operasyonel maliyet ekler. Bunu toplam sahip olma maliyeti hesaplamalarınıza dahil edin. Saf yapay zeka çıkarım kümeleri için MIG veya zaman dilimi paylaşımı daha maliyet etkin olabilir. vGPU, GPU iş yüklerinin geleneksel sanallaştırılmış altyapıyla bir arada bulunduğu ve birleşik yönetimin öncelikli olduğu durumlarda en mantıklıdır.

Zaman Dilimi Paylaşımı: Kubernetes-Native GPU Paylaşımı

Zaman dilimi paylaşımı, GPU paylaşımının en basit biçimidir ve özel donanım özellikleri gerektirmez. Kubernetes için NVIDIA cihaz eklentisi, tek bir GPU'yu birden fazla sanal cihaz olarak sunabilir ve GPU zamanlayıcısı zamansal çoğullama kullanarak iş yükleri arasında döner. Her iş yükü periyodik olarak tam GPU'ya özel erişim elde eder.

Zaman dilimi paylaşımının cazibesi basitlik ve esnekliktir. Herhangi bir NVIDIA GPU'da çalışır, cihaz eklentisinde yalnızca bir yapılandırma değişikliği gerektirir ve Kubernetes kaynak talepleriyle yerel olarak entegre olur. Bir GPU'yu herhangi bir faktörle aşırı abone edebilirsiniz, on veya yirmi pod'un tek bir cihazı paylaşmasına izin verebilirsiniz.

Önemli dezavantajı bellek izolasyonunun olmamasıdır. Zaman dilimli bir GPU'yu paylaşan tüm iş yükleri aynı bellek alanını paylaşır. Aşırı GPU belleği tahsis eden bir iş yükü, diğer kiracılar için bellek yetersizliği hatalarına neden olur. Performans izolasyonu da yoktur: hesaplama yoğun bir iş yükü diğer iş yüklerini zaman dilimlerinden mahrum bırakır.

Zaman dilimi paylaşımı, ekiplerin deneme için ara sıra GPU erişimine ihtiyaç duyduğu ve müdahalenin sonuçlarının düşük olduğu geliştirme ve test ortamları için iyi çalışır. SLA gereksinimleri olan üretim çıkarımı için uygun değildir. Orantısız kaynak tüketen iş yüklerini tespit etmek ve çıkarmak için zaman dilimi paylaşımını kaynak kotaları ve izleme ile eşleştirin.

Çok Katmanlı Sanallaştırma Stratejisi Tasarlama

Üretim ortamları, bu yaklaşımları katmanlı bir mimaride birleştirmekten fayda görür. Katman 1, katı gecikme SLA'larına sahip üretim çıkarım iş yükleri için MIG kullanır. Katman 2, hazırlık ve üretim öncesi doğrulama için vGPU veya MIG kullanır. Katman 3, geliştirme, deneme ve toplu işleme için zaman dilimi paylaşımı kullanır.

Bunu Kubernetes node havuzları veya etiketleri aracılığıyla uygulayın. GPU düğümlerini sanallaştırma katmanlarıyla etiketleyin ve iş yüklerini uygun şekilde zamanlamak için düğüm yakınlık kurallarını kullanın. Bir üretim çıkarım dağıtımı MIG bölümlenmiş düğümleri hedeflerken, bir geliştiricinin notebook sunucusu zaman dilimli düğümlerde zamanlanır.

Sanallaştırma ile kapasite planlaması önemli ölçüde değişir. Fiziksel GPU'ları saymak yerine, katman başına kullanılabilir etkili GPU-kesirleri cinsinden planlayın. 4g profillerle MIG'e sahip sekiz H100 GPU kümesi, Katman 1'de 16 etkili çıkarım yuvası sağlar. Aynı sekiz GPU 4x aşırı abonelikle zaman dilimli olarak Katman 3'te 32 geliştirme yuvası sağlar. Bu aritmetik, donanım tedarik kararlarını yönlendirir.

Kullanımı fiziksel GPU seviyesinde değil, bölüm seviyesinde izleyin. Genel olarak %60 kullanım gösteren bir GPU, bir MIG bölümü %95'te ve diğeri %25'te olabilir. Bölüm seviyesinde metrikler yeniden dengeleme kararlarını yönlendirir ve profillerinizin gerçek iş yükü gereksinimleriyle eşleşip eşleşmediğini ortaya koyar.

Operasyonel Değerlendirmeler ve Yönetişim

GPU sanallaştırma, politika ve araçlar yoluyla ele alınması gereken yönetişim zorlukları getirir. Net bir tahsis modeli tanımlayın: hangi ekiplerin garantili MIG bölümleri alacağı, zaman dilimi önceliklerinin nasıl yönetileceği ve talebin kapasiteyi aştığında ne olacağı.

Ekiplerin GPU gereksinimlerini (bellek, hesaplama, izolasyon seviyesi, süre) beyan ettiği ve bir platform ekibinin veya otomatik bir sistemin talepleri uygun sanallaştırma katmanlarıyla eşleştirdiği bir talep iş akışı uygulayın. Bu, her ekibin "her ihtimale karşı" ayrılmış GPU'lar talep ettiği ve kullanımın çöktüğü yaygın başarısızlık modunu önler.

Bölüm seviyesinde gerçek tüketime dayalı geri ödeme veya maliyet gösterimi ayarlayın. Ekipler ayrılmış MIG bölümlerinin maliyetini gerçek kullanımlarına karşı gördüğünde, davranış değişir. Boşta rezervasyonlar serbest bırakılır, toplu işler yoğun olmayan saatlerde zamanlanır ve kuruluş aynı donanımdan daha fazla değer elde eder.

GPU sürücü ve ürün yazılımı güncellemelerini dikkatli planlayın. MIG yeniden yapılandırması bir GPU üzerindeki tüm bölümlerin boşaltılmasını gerektirir ve vGPU güncellemeleri VM geçişi veya kesinti gerektirebilir. Bu bakım operasyonlarını değişiklik yönetimi sürecinize dahil edin ve bireysel GPU'ların hizmet etkisi olmadan çevrimdışı alınabilmesi için yeterli yedek kapasiteyi koruyun.

Featured image by Andrey Matveev on Unsplash.