deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

CUDA 13.4, paylaşımlı Kubernetes iş yükleri için zorunlu kılınabilir GPU bellek sınırları getiriyor

NVIDIA'nın CUDA 13.4 sürümü, uygulamalar için şeffaf bir GPU bellek sınırının yanı sıra container başına payları zorunlu kılan açık kaynaklı bir Kubernetes operator sunuyor; KAI Scheduler bunu entegre eden ilk scheduler oldu.

CUDA 13.4, paylaşımlı Kubernetes iş yükleri için zorunlu kılınabilir GPU bellek sınırları getiriyor

NVIDIA, 27 Ekim 2026'da paylaşımlı GPU kurulumlarının eksik kaldığı bir yetenekle CUDA 13.4'ü yayımladı: uygulamanın göremediği ama platformun zorunlu kılabildiği bir bellek sınırı. NVIDIA'nın teknik blogunun dev.to üzerindeki aktarımına göre sürüm, her node'da container başına GPU paylarını uygulayan açık kaynaklı bir Kubernetes operator de içeriyor ve KAI Scheduler v0.18.0 bu mekanizmayı entegre eden ilk scheduler oldu.

Sorun: Küçük işler için bütün GPU'lar

Yazı sorunu basit bir aritmetik sorunu olarak çerçeveliyor. Bir pod bir GPU istiyor, scheduler bir GPU veriyor ve 8 GB belleğe ihtiyaç duyan bir batch işi, 80 GB'lık bir cihazı elinde tutarken geriye kalan 72 GB boşta bekliyor. NVIDIA'nın donanımı zaten bir cihazı paylaşmanın üç yolunu sunuyordu: Multi-Instance GPU (MIG) cihazı donanım düzeyinde izole edilmiş parçalara bölüyor, time-slicing süreçlerin sırayla çalışmasını sağlıyor ve Multi-Process Service (MPS) süreçleri paylaşımlı streaming multiprocessor'lar üzerinde eşzamanlı çalıştırıyor; NVIDIA bu moda sm-sharing adını veriyor. Eksik olan şey zorunlu kılınmaydı: time-slicing hiçbir bellek sınırı getirmiyordu.

Küçük bir GPU gibi davranan bir sınır

CUDA 13.4, bu paylaşım modlarının üzerine bellek zorunluluğu ekliyor. Bir iş yükü bir bellek boyutu talep ediyor ve CUDA onu orada tutuyor; böylece bu boyutun üzerindeki bir tahsis, fiziksel olarak daha küçük bir GPU'da olduğu gibi tam olarak başarısız oluyor. İş yükleri bunun yerine bir aralık da tanımlayabiliyor: garantili bir minimum ve bellek boş olduğunda büyüyebilecekleri bir maksimum. Her iş yükü cihazın belleğinin yalnızca kendi payını görüyor, böylece sınır uygulamaya şeffaf kalıyor; ayrıca her container, varsayılan time-slicing ve isteğe bağlı sm-sharing ile birlikte bir compute modu seçiyor.

Scheduler yazar, node zorunlu kılar

Kubernetes, CUDA'nın zorunluluk mekanizmasına kendi başına erişemiyor. NVIDIA'nın cevabı gpu-fractioning: KAI Scheduler organizasyonu altında barındırılan ve NVIDIA GPU Operator ile birlikte dağıtılan açık kaynaklı bir operator. Üç görevi var: her GPU node'unda MPS'yi kurmak ve çalıştırmak, her container'ın bellek sınırlarını ve compute modunu süreci başlamadan önce uygulamak ve pay başına bellek ile compute kullanımını ölçmek.

Scheduler ile node arasındaki sözleşme, nvidia.com öneki altında, container başına dört Pod annotation'ı ile taşınıyor; bunlar garantili GPU bellek talebini, maksimum bellek sınırını, compute modunu ve container'a atanmış GPU'ları kapsıyor. NVIDIA'nın belirttiği kural, bu annotation'ları yazabilen her Kubernetes scheduler'ın GPU paylarını CUDA ile zorunlu kılabileceği. Scheduler'ın kendisi de iki yükümlülüğü var: yeterince boş belleği olan bir GPU'yu seçmek ve tek bir GPU'da compute modlarını asla karıştırmamak. dev.to yazısında aktarıldığı kadarıyla NVIDIA'ya göre bu zorunluluk işi, iş yükünü yerleştiren scheduler'da değil node'da olmalı.

KAI Scheduler v0.18.0 ilk entegrasyon. Tek bir Helm bayrağıyla etkinleştirilen NvFractions adlı bir GPU-sharing modu sunuyor ve operator'ı bir bağımlılık olarak kuruyor.

Compute'u bölmenin iki yolu

Bir GPU'yu paylaşan n iş yükü, her iki modda da compute'un kabaca 1/n'ini alıyor ama zamanlama farklı işliyor. Time-slicing seri: iş yükleri bütün GPU'da sırayla çalışıyor, kullanılmayan süre diğerlerine dağıtılıyor ve her iş yükü kendi hata alanında çalışarak tam hata izolasyonu sağlıyor. SM-sharing paralel: streaming multiprocessor'lar eşzamanlı çalışan iş yükleri arasında bölünüyor, donanım SM'leri gerektiği gibi ayırıp serbest bırakıyor ve tek bir aktif iş yükü hepsini kullanabiliyor. Ödünleşim, SM-sharing iş yüklerinin tek bir hata alanını paylaşması; NVIDIA'nın önerisi, bu modu birlikte çalıştırılmasına güvenilen iş yükleri için ayırmak. Aynı node'daki farklı GPU'lar farklı modlarda çalışabilir.

Örnek senaryolar

NVIDIA, yaygın kullanım biçimlerini kapsayan iki yapılandırma sunuyor. Bir inference sunucusu dört GPU'nun her birinde garantili 40Gi, komşular boşken büyüyebileceği 60Gi sınırı ve sm-sharing talep ediyor. Bir geliştirme veya batch işi ise time-slicing kullanarak iki GPU'nun her birinin yarısını (0,5 pay ve 0,8 sınırı) istiyor; böylece bir çökme o iş yüküyle sınırlı kalıyor. Talepler cihaz başına uygulanır ve sınır belirtilmediğinde talebe eşit olur; böylece iş yükü tam istediği miktarda sınırlandırılır.

Neden önemli

Şimdiye kadar bir GPU'yu kiracılar veya inference servisleri arasında bölmek, ya MIG ile statik bölümleme ya da zorunlu kılınmayan time-slicing anlamına geliyordu; ikincisinde tek bir açgözlü tahsis cihazı paylaşan her şeyi bozabiliyordu. CUDA 13.4 bellek muhasebesi sorununu node düzeyinde çözüyor ve bu, paylaşımlı inference ile çok kiracılı GPU kümelerini önemli ölçüde daha pratik hale getiriyor. Değişiklik bilinçli olarak dar kapsamlı: bellek bant genişliği, önbellek davranışı ve hata alanları değişmiyor; bu nedenle benimseyen ekipler iş yükü başına garantili talebi ve burst sınırını doğrulamalı ve SM-sharing'i izolasyon karşılığında kazanılan bir kullanım kazanımı olarak görmeli. Scheduler'dan bağımsız annotation sözleşmesi, bu sürümün ötesinde en çok fark yaratacak kısım; çünkü her scheduler, NVIDIA'nın özel destek geliştirmesine gerek kalmadan onu benimseyebilir.

  • #nvidia
  • #cuda
  • #kubernetes
  • #gpu-sharing
  • #gpu

İlgili yazılar