Kubernetes GPU Operator mu, Slurm mu: GPU kümesi hangisiyle?

GPU kümeniz esas olarak modelleri birçok düğümde eğitmek için varsa Slurm kullanın; esas olarak çıkarım, API'ler ve diğer uzun süre çalışan servisler sunmak için varsa Kubernetes'i NVIDIA GPU Operator ile kullanın. Her ikisini de yapan ekipler genellikle her ikisini de çalıştırır: eğitim için bir Slurm bölümü ve sunum için depolama, kimlik ve izlemeyi paylaşan bir Kubernetes GPU havuzu. Her iş yükü için tek bir zamanlayıcı seçmek, GPU kümelerindeki en maliyetli hatadır, çünkü her araç tam olarak diğerinin güçlü olduğu yerde zayıftır.

Kubernetes ile GPU Operator ve Slurm ne yapar

Kubernetes artı NVIDIA GPU Operator

Kubernetes, asla durmaması gereken servisler için tasarlanmış bir konteyner orkestratörüdür: replikaları çalışır durumda tutar, hataları yeniden başlatır, yeni sürümleri yayınlar ve trafiği yönlendirir. Kutudan çıktığı haliyle GPU'lar hakkında hiçbir şey bilmez. NVIDIA GPU Operator, sürücüyü, konteyner araç setini, cihaz eklentisini, özellik keşfini, DCGM izlemeyi ve MIG yapılandırmasını Kubernetes kaynakları olarak kurup yöneterek bu boşluğu kapatır. Bundan sonra bir pod nvidia.com/gpu: 2 talep eder ve iki boş GPU'su olan bir düğüme yerleşir.

Bu, Kubernetes'i vLLM, TensorRT-LLM ve NVIDIA NIM çıkarım sunucuları, RAG ve ajan arka uçları, notebook'lar ve CI için doğal bir ev yapar. Varsayılan olarak eksik olan şey ise bir iş kuyruğu, grup zamanlama (gang scheduling) ve adil paylaşım muhasebesidir.

Slurm

Slurm, dünyanın en büyük HPC sistemlerinin birçoğunda kullanılan, SchedMD'den bir toplu iş zamanlayıcısı ve kaynak yöneticisidir. Kullanıcılar sbatch veya srun ile ihtiyaç duydukları düğümleri, GPU'ları ve saatleri belirterek iş gönderir; kontrolör işi kuyruğa alır, öncelikleri ve adil paylaşımı uygular, küçük işleri büyük işlerin etrafına doldurur (backfill) ve her görevi tahsis edilen her düğümde aynı anda başlatır. Muhasebe, rezervasyonlar, önceliklendirme (preemption) ve duvar-zamanı (wall-time) sınırları temel özelliklerdir.

Slurm, başlayan, tamamlanana kadar çalışan ve ardından kaynaklarını serbest bırakan işler için tasarlanmıştır; bu tam olarak bir eğitim çalıştırmasının şeklidir. Süresiz olarak istekleri yanıtlaması gereken bir servis için zayıf bir uyumdur. Kubernetes asla durmaması gereken servisleri zamanlar; Slurm birlikte başlaması gereken ve sonunda bitecek işleri zamanlar.

Kubernetes GPU Operator ile Slurm: yan yana karşılaştırma

Tablo, gerçek dağıtımlara karar veren kriterlere göre ikisini karşılaştırır; "eklentilerle" ifadesi çalıştığı ama ek bir bileşeni kurup işletmeniz gerektiği anlamına gelir.

Karşılaştırma hangi aracın daha iyi olduğuyla ilgili değildir; hangi boşlukları eklentiler ve personelle doldurmaya hazır olduğunuzla ilgilidir. Kubernetes'in Slurm'un eğitim zamanlayıcısına denk olması için üç veya dört ek projeye ihtiyacı vardır; Slurm'un ise üretimde model sunmak için ayrı bir sisteme ihtiyacı vardır.

Kubernetes, Slurm veya ikisini birden ne zaman seçmeli

GPU saatlerinin çoğunluğunu çıkarım ve servisler oluşturuyorsa, kuruluşunuz üretimde zaten Kubernetes çalıştırıyorsa ve otomatik ölçeklendirmeye, takım başına namespace'lere ve CI/CD entegrasyonuna ihtiyacınız varsa Kubernetes'i GPU Operator ile seçin. EKS, AKS ve GKE bunu destekler, bu yüzden hibrit bir strateji tutarlı kalır. Nanobase AI'ın kurduğu kümelerde, sunuma ağırlıklı bir RTX PRO 6000 veya H100 PCIe düğüm havuzu genellikle yalnızca Kubernetes çalıştırır.

Çok düğümlü eğitim baskınsa, birçok araştırmacı veya ekip bir havuza adil paylaşımlı erişime ihtiyaç duyuyorsa ve InfiniBand topolojisi otomatik ölçeklendirmeden daha önemliyse Slurm'u seçin. Ayrıca Kubernetes'ten çok Linux'u iyi bilen küçük bir operasyon ekibine de uyar, çünkü çalışan bir Slurm kümesi bir platform değil, birkaç yapılandırma dosyasıdır. 4 düğümde 8x H100 üzerinden 70B bir modele ince ayar yapmak bir Slurm işidir, bir Kubernetes Deployment'ı değil.

İkisini birden çalıştırmak: eğitim için Slurm, sunum için Kubernetes

2026 itibarıyla en yaygın kurumsal model, kümeyi Slurm altında bir eğitim havuzuna ve Kubernetes altında bir sunum havuzuna böler. Her ikisi de veri kümeleri ve kontrol noktaları (checkpoint) için paralel bir dosya sistemini veya nesne deposunu, tek bir konteyner kayıt defterini, tek bir kimlik sağlayıcıyı ve tek bir Prometheus ile Grafana yığınını paylaşır. Slurm altında eğitilen bir model, kimse dosyaları elle kopyalamadan dışa aktarılır, kaydedilir ve Kubernetes'e devreye alınır.

En entegreden en az entegreye köprüleme seçenekleri:

1. Kubernetes üzerinde Slurm: SchedMD'nin Slinky projesi (slurm-operator) ve CoreWeave'in SUNK'ı Slurm daemon'larını pod olarak çalıştırır; tek bir fiziksel katman ve araştırmacılar sbatch'i korur.
2. Kubernetes yerel toplu iş işleme: kuyruklar ve kotalar için Kueue, çok düğümlü işler için Kubeflow Trainer veya JobSet, grup zamanlama için Volcano veya KAI Scheduler; ikinci bir sistem yok, ama Slurm parça parça yeniden inşa edilir.
3. Slurm'da konteynerler: Enroot ile Pyxis veya Slurm'un yerel OCI desteği, böylece aynı imaj Slurm altında eğitir ve Kubernetes altında sunar.
4. Düğüm devri: aylık yeniden dengeleme sırasında yeniden imajlama veya yeniden etiketleme ile tüm düğümleri havuzlar arasında taşıyın. Kaba ama güvenilir ve denetlemesi kolay.

Eğitim ve sunum her biri kendi zamanlayıcısını haklı çıkaracak kadar büyükse ikisini birden çalıştırın; aksi halde baskın iş yüküne uyan aracı seçin.

Her yığının temel bileşenleri

Kubernetes GPU yığını

GPU Operator, bunları tek bir ClusterPolicy kaynağıyla yönetilen DaemonSet'ler ve kontrolörler olarak kurar:

• NVIDIA sürücüsü: host imajında veya operatör yönetimli bir konteyner olarak; düğüm havuzu başına bir sürüm.
• NVIDIA Container Toolkit: containerd veya CRI-O'yu, konteynerlerin /dev/nvidia* cihazlarını ve eşleşen kütüphaneleri almasını sağlayacak şekilde yapılandırır.
• Kubernetes cihaz eklentisi: nvidia.com/gpu ve MIG ile nvidia.com/mig-<profile> kaynaklarını ilan eder; ayrıca zaman dilimlemeyi ve MPS'i uygular.
• Node Feature Discovery ve GPU Feature Discovery: düğümleri GPU ürünü, sürücü ve CUDA sürümü ile MIG yeteneğiyle etiketler.
• DCGM exporter: kullanım, bellek, güç, sıcaklık, NVLink ve XID hataları için Prometheus metrikleri.
• MIG Manager: nvidia.com/mig.config=all-3g.40gb gibi bir etiketten düğüm başına bir MIG düzeni uygular.

RDMA için NVIDIA Network Operator'ı ekleyin. Minimal bir GPU talebi:

apiVersion: v1
kind: Pod
metadata:
  name: vllm-h100
spec:
  nodeSelector:
    nvidia.com/gpu.product: NVIDIA-H100-80GB-HBM3
  containers:
    - name: vllm
      image: vllm/vllm-openai:latest
      resources:
        limits:
          nvidia.com/gpu: 2   # or nvidia.com/mig-3g.40gb: 1 in MIG mixed strategy

Slurm yığını

Bir Slurm kümesi, birbiriyle uyumlu olması gereken daemon'lardan ve yapılandırma dosyalarından oluşturulur:

• slurmctld: idealde bir yedek ve paylaşılan durum dizinine sahip kontrolör; slurm.conf düğümleri, bölümleri ve zamanlayıcı eklentilerini tanımlar.
• Her hesaplama düğümünde slurmd, iş adımlarını slurmstepd üzerinden başlatır.
• MariaDB ile slurmdbd: sacctmgr hesapları, QOS ve TRES limitleri için muhasebe; adil paylaşım buna bağlıdır.
• cgroup.conf: ConstrainDevices=yes, bir işin yalnızca kendisine tahsis edilmiş GPU'ları görmesini sağlar; ConstrainCores ve ConstrainRAMSpace aynısını CPU ve bellek için yapar (Slurm 22.05'ten beri cgroup v2).
• gres.conf: GPU'ları tanımlar; AutoDetect=nvml, sayıyı, türü, NVLink ve CPU yakınlığını sürücüden okur. Slurm GRES rehberine bakın.

Yaygın eklentiler: konteynerler için Pyxis ve Enroot, bir REST API için slurmrestd, bir portal için Open OnDemand. Minimal bir GPU tanımı:

# gres.conf on the compute nodes
AutoDetect=nvml
NodeName=gpu[01-16] Name=gpu Type=h100 File=/dev/nvidia[0-7]

# slurm.conf on the controller (abbreviated)
GresTypes=gpu
NodeName=gpu[01-16] Gres=gpu:h100:8 State=UNKNOWN
PartitionName=train Nodes=gpu[01-16] MaxTime=2-00:00:00 State=UP

Kubernetes'te GPU yığınını operatör sizin için bir araya getirir; Slurm'da bunu siz bir araya getirirsiniz ve işlerin gerçekten izole GPU'lar alıp almadığına gres.conf artı cgroup.conf karar verir.

Ağ altyapısı: InfiniBand, NVLink ve NCCL

Bir düğümün içinde GPU'lar NVLink ve NVSwitch üzerinden konuşur: H100 ve H200 SXM'de GPU başına çift yönlü 900 GB/s, B200'de 1,8 TB/s; RTX PRO 6000 gibi PCIe kartlar ise x16 yuva başına çift yönlü yaklaşık 128 GB/s ile PCIe Gen5'e dayanır. Düğümler arasında standart, rayla optimize edilmiş bir tasarımda GPU başına bir port ile port başına 400 Gb/s InfiniBand NDR'dir, ya da 8 GPU'lu düğüm başına 3,2 Tb/s; 800 Gb/s'lik XDR, 2026 itibarıyla Blackwell nesli sistemlerle birlikte gelmektedir. Spectrum-X Ethernet üzerinde RoCE alternatiftir.

NCCL, her eğitim çerçevesinin all-reduce ve all-gather için kullandığı kütüphanedir. NVLink, InfiniBand ve GPUDirect RDMA'yı otomatik olarak algılar, ancak ağ altyapısı sürece görünmüyorsa sessizce yönetim ağı üzerinden TCP'ye geri döner. NCCL_DEBUG=INFO ile bir test işi çalıştırın, IB taşımalarını GDRDMA ile bildirdiğini doğrulayın ve kabul referansı olarak nccl-tests all-reduce sayılarını kaydedin.

Slurm'da işler host ağında çalışır, bu yüzden InfiniBand, anahtar farkındalıklı yerleştirme için topology.conf dışında hiçbir şeye ihtiyaç duymadan çalışır. Kubernetes'te pod'lar bir overlay ağında yaşar, bu yüzden RDMA; Network Operator, SR-IOV'lu veya host-device arayüzlü Multus, bir RDMA cihaz eklentisi ve GPU'ların yanında bir RDMA kaynağı talep eden pod'lar gerektirir. Ağ altyapısı her ikisinde de aynıdır; farklı olan bir konteynerin onu kullanabilmesi için gereken çalışmadır ve tamamlanmamış RDMA kurulumu, "eğitim Kubernetes'te 3 kat daha yavaş" durumunun olağan nedenidir.

Bir GPU kümesi için operasyon kontrol listesi

Bir GPU kümesini bozan nadiren zamanlayıcıdır; sürücüler, firmware, ağ altyapısı ve kota sapması bozar. Bu kontrol listesi her iki yığın için de geçerlidir.

1. İzleme: her düğümde DCGM exporter metriklerini Prometheus ve Grafana'ya gönderin. XID ve ECC hatalarında, termal kısıtlamada ve NVLink arızalarında uyarı verin ve çoğu kümedeki en büyük gizli maliyet olan, tahsis edilmiş ama atıl GPU'ları izleyin.
2. Sağlık kontrolü (health gating): önyükleme ve bakımdan sonra dcgmi diag -r 2 çalıştırın; başarısız GPU'ları olan düğümleri otomatik olarak boşaltmak için Slurm'un NHC ile HealthCheckProgram'ını veya Kubernetes node-problem-detector'ını kullanın.
3. Sürücü ve CUDA uyumluluğu: düğüm havuzu başına bir sürücü sürümü sabitleyin ve bunu NVIDIA'nın CUDA uyumluluk rehberine göre kontrol edin. İmajlar kendi CUDA çalışma zamanını getirir, ancak host sürücüsü o CUDA ana sürümü için minimumu karşılamalıdır; alt sürüm uyumluluğu ve ileriye dönük uyumluluk paketi çoğu boşluğu kapatır.
4. Yükseltmeler: Kubernetes'te önce GPU Operator'ı yükseltin, ardından düğümlerin gruplar halinde boşalması için driver.upgradePolicy ve maxParallelUpgrades ile sürücüleri kademeli olarak dağıtın. Slurm'da SchedMD'nin belgelediği sürüm penceresi içinde önce slurmdbd, sonra slurmctld, sonra slurmd'yi yükseltin. İkisini de küçük bir düğüm havuzunda kanarya olarak test edin.
5. Firmware: GPU VBIOS, ConnectX NIC firmware ve anahtar işletim sistemi sürümlerini takip edin; pencereler için Slurm bakım rezervasyonlarını veya Kubernetes cordon'larını kullanın.
6. Adalet incelemesi: proje başına kuyruk bekleme süresini ve GPU-saatini aylık olarak raporlayın; Slurm'da QOS ve GrpTRES ile veya Kubernetes'te Kueue ClusterQueue kotalarıyla limitleri uygulayın.
7. Depolama: her eğitim düğümünün kontrol noktalarını (checkpoint) tam hızda yazdığını doğrulayın; optimizer durumuyla birlikte tam bir 405B kontrol noktası birkaç terabayt olabilir. Veri kümelerini yerel NVMe'de önbelleğe alın.
8. Çalışma kitapları (runbook): bir düğümü nasıl boşaltacağınız, bir GPU'yu nasıl değiştireceğiniz, bir sürücüyü nasıl geri alacağınız ve Slurm veritabanını veya etcd'yi nasıl geri yükleyeceğiniz.

Uyumluluk ve sağlık kontrollerini otomatikleştirin; bu, çoğu GPU kümesi olayını zamanlayıcı bunları hiç görmeden önler. Düğümlerin kendisini boyutlandırmak için 70B, 405B ve DeepSeek R1 için kaç GPU gerektiğine ve şirket içi LLM dağıtım rehberine bakın.

Sık sorulan sorular

Kubernetes çok düğümlü dağıtık eğitimi çalıştırabilir mi?

Evet, ama yalnızca standart zamanlayıcıyla değil. Pod'lar arasında sıralamaları (rank) başlatmak için Kubeflow Trainer veya JobSet gibi bir iş API'sine, Volcano, KAI Scheduler veya Kueue gibi bir grup zamanlayıcıya ve NCCL'nin TCP yerine InfiniBand kullanması için RDMA ağına ihtiyacınız var. Bunlar yerindeyken verim aynı donanımda Slurm ile eşleşir; bunlar olmadan eğitim birkaç kat daha yavaş olabilir.

Slurm üretimde çıkarım uç noktalarına hizmet verebilir mi?

Bir Slurm işi vLLM'i çalıştırıp bir port açabilir, ancak Slurm'un servis keşfi, yük dengeleme, sağlık tabanlı yeniden başlatma veya kademeli güncellemesi yoktur ve her işin bir duvar-zamanı sınırı vardır. Bazı siteler, dahili demolar için uzun "sonsuz işler" çalıştırır. Müşteriye dönük herhangi bir şey için Kubernetes'te veya bir VM filosunda sunum yapın ve Slurm'un eğitime odaklanmasına izin verin.

Kubernetes'te GPU kullanmak için NVIDIA GPU Operator gerekli mi?

Hayır. Sürücüyü, konteyner araç setini ve cihaz eklentisini elle kurabilirsiniz; GKE, EKS ve AKS sürücü etkin düğüm imajları sunar. Yükseltmeleri, MIG düzenlerini, DCGM izlemeyi ve özellik keşfini tutarlı biçimde yönettiği için operatörü kullanmak yine de değerlidir. Yönetilen bulutlarda genellikle driver.enabled=false ayarlarsınız, böylece bulut sürücüyü tutar ve operatör geri kalanını yönetir.

MIG, Kubernetes'te ve Slurm'da nasıl çalışır?

MIG, bir H100, H200 veya B200'ü özel bellek ve hesaplamaya sahip yedi adede kadar izole örneğe böler. Kubernetes'te MIG Manager düğüm başına bir profil uygular ve cihaz eklentisi her dilimi nvidia.com/mig-1g.10gb gibi bir kaynak olarak ilan eder. Slurm'da AutoDetect=nvml, MIG örneklerini işlerin normal şekilde talep ettiği ayrı GPU'lar olarak sunar. Kubernetes düzenleri değiştirmeyi kolaylaştırır; Slurm muhasebeyi kolaylaştırır.

Kubernetes içinde Slurm çalıştırabilir miyim?

Evet ve 2026 itibarıyla desteklenen bir modeldir. SchedMD'nin Slinky projesi, kontrolörü ve düğüm daemon'larını pod olarak çalıştıran bir Slurm operatörü sağlar ve GPU bulutları, CoreWeave'in SUNK'ı gibi benzer yığınlar sunar. Araştırmacılar sbatch'i ve adil paylaşımı korur, platform ekibi tek bir fiziksel katmanı korur. Karşılığı, bir şeyler ters gittiğinde anlaşılması gereken iki zamanlayıcıdır.

Zaman dilimleme (time-slicing) ile MIG arasındaki fark nedir?

Zaman dilimleme, birden çok pod'un aralarında geçiş yaparak tek bir GPU'yu paylaşmasını sağlar; bellek izolasyonu eklemez, bu yüzden bir kiracı diğerleri için belleği tüketebilir; notebook'lara ve hafif çıkarıma uygundur. MIG, donanımı garantili bellek ve hesaplamaya sahip izole örneklere ayırır; çok kiracılı üretim çıkarımı için doğru seçimdir. MPS ikisinin arasındadır: daha düşük geçiş yükü, ama yine de sabit bellek sınırı yoktur.

Nanobase AI nasıl yardımcı olabilir

Nanobase AI, GPU kümelerini uçtan uca tasarlar, kurar ve işletir: H100, H200, B200 ve RTX PRO düğümleri için donanım boyutlandırma, InfiniBand ve NVLink ağ planlaması, sunum için NVIDIA GPU Operator ile Kubernetes, eğitim için Slurm ve ikisi arasındaki köprüler. MIG düzenlerini, DCGM izlemeyi, adil paylaşım kotalarını ve sürücü yükseltme hatlarını yapılandırır, ardından ekibinizin bizsiz çalıştırabileceği çalışma kitaplarını (runbook) teslim ederiz. Silikon Vadisi merkezli bir şirket ve NVIDIA Inception Programı üyesi olarak, çıkarım katmanını da vLLM ve TensorRT-LLM'den NVIDIA NIM'e kadar, şirket içinde veya AWS, Azure ve Google Cloud ile hibrit olarak devreye alırız. Tam kapsam için çözümlerimize genel bakışa göz atın.

Projenizi konuşmaya hazır mısınız? Nanobase AI ile iletişime geçin veya hello@bumu.tech adresine e-posta gönderin.