GPU Cluster Kurulum Rehberi: Mimari, Uygulama ve En İyi Pratikler

Büyük dil modeli (LLM) eğitimi, hesaplamalı akışkanlar dinamiği simülasyonu ya da yüksek hacimli inference servisleri gibi iş yükleri tek bir GPU’nun kapasitesini çoktan aşmıştır. Bu noktada devreye giren GPU cluster altyapısı, birden fazla GPU’yu yüksek hızlı bir ağ üzerinde birleştirerek ölçeklenebilir bir hesaplama havuzu oluşturur. Bu rehberde GPU cluster’ın temel bileşenlerini, kurulum sürecini, sık karşılaşılan sorunları ve en iyi pratikleri ele alıyoruz.

GPU Cluster Mimarisinin Temel Katmanları

Bir GPU cluster üç ana katmandan oluşur: donanım, ağ ve yazılım.

Donanım katmanında NVIDIA DGX H100/H200 ve HGX H100 en yaygın tercih edilen platformlardır. DGX H100, NVLink ile birbirine bağlı 8 adet H100 GPU barındırır ve tek node’da 640 GB toplam GPU belleği sunar. HGX H100 ise OEM sunucu üreticilerinin DGX’e alternatif çözümüdür. Daha karma iş yükleri için geniş CPU belleği ve ağ bant genişliği gerektiren durumlarda PCIe GPU sunucuları tercih edilebilir.

Ağ katmanı, cluster performansını doğrudan etkileyen kritik bileşendir. NVIDIA InfiniBand NDR (400 Gbps) en düşük gecikmeyi sunarken özellikle MPI tabanlı iş yükleri için tercih edilir. RoCE v2 ise Ethernet altyapısını kullanan daha ekonomik büyük ölçekli dağıtımlar için uygundur. Tipik bir kurulumda node’lar çift raylı ağ tasarımıyla hem hesaplama hem de depolama ağlarına ayrı bağlantılarla bağlanır.

Depolama katmanında darboğaz çoğunlukla hesaplama değil, veri okuma hızıdır. Eğitim veri setlerini GPU’lara beslemek için paralel dosya sistemleri kullanılır: BeeGFS esnek ve ölçeklenebilir yapısıyla yaygın tercih iken Lustre büyük HPC kurulumlarında kanıtlanmış bir çözümdür. Ultra düşük gecikme gerektiren senaryolarda NVMe-oF (NVMe over Fabrics) tercih edilebilir.

Paralelleştirme Stratejileri

GPU cluster kurulumunda yalnızca donanımı bir araya getirmek yetmez; iş yükünü GPU’lara nasıl dağıtacağınızı da planlamanız gerekir.

• Veri paralelliği: Her GPU aynı modeli farklı veri minigrupleriyle çalıştırır. Küçük ve orta ölçekli modeller ile büyük veri setleri için uygundur.
• Model paralelliği: Model katmanları farklı GPU’lara bölünür. Tek GPU belleğine sığmayan büyük modeller için zorunludur.
• Pipeline paralelliği: Model aşamaları sıralı GPU gruplarına atanır. Çok büyük modellerde maksimum verimlilik için kullanılır.
• Tensor paralelliği: Bireysel matris işlemleri GPU’lar arasında bölünür. Transformer dikkat katmanlarında etkin bir yaklaşımdır.

Modern LLM eğitiminde bu stratejilerin kombinasyonu (3D paralellik) uygulanır.

İş Zamanlayıcısı Seçimi: SLURM mu, Kubernetes mu?

SLURM, geleneksel HPC ve araştırma iş yükleri için olgun ve yaygın bir çözümdür. Örnek bir SLURM betiği:

#!/bin/bash
#SBATCH --job-name=llm-train
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=8
#SBATCH --gres=gpu:8
#SBATCH --time=48:00:00

srun torchrun \
  --nnodes=4 \
  --nproc_per_node=8 \
  train.py --model llama3-70b --batch-size 256

Kubernetes + GPU Operator ise konteyner tabanlı, çoklu kiracılı ortamlar için ve MLOps pipeline’larıyla entegrasyon gerektiren senaryolarda tercih edilir. Hangi seçeneğin daha uygun olduğu iş yükü profilinize ve ekibinizin altyapı kültürüne bağlıdır.

Sık Karşılaşılan Sorunlar ve Çözümleri

Ağ darboğazı: Node’lar arası bant genişliği yetersizse all-reduce operasyonları yavaşlar ve GPU’lar boşta bekler. Çözüm: InfiniBand topolojisini doğru yapılandırmak ve NCCL parametrelerini (örneğin NCCL_IB_HCA, NCCL_SOCKET_IFNAME) optimize etmek.

Depolama G/Ç tıkanıklığı: Eğitim sırasında veri yükleme CPU’yu ya da depolama ağını doyurabilir. Çözüm: Veri ön işlemeyi paralel hale getirmek, DataLoader işçi sayısını artırmak ve gerekirse NVMe-oF ile doğrudan depolama erişimi sağlamak.

GPU bellek taşması (OOM): Model boyutu ya da batch size GPU belleğini aşabilir. Çözüm: Gradient checkpointing etkinleştirmek, mixed precision (BF16/FP16) eğitim kullanmak veya model paralelliğine geçmek.

Termal kısıtlama (Thermal Throttling): Yoğun iş yüklerinde GPU’lar maksimum ısı sınırına ulaşarak hız kısıtlamasına gidebilir. Çözüm: Veri merkezinde yeterli soğutma kapasitesi sağlamak ve DCGM ile sıcaklık metriklerini sürekli izlemek.

Kurulum Sonrası Doğrulama: Benchmark Testleri

Cluster’ı üretime almadan önce şu benchmark’ları çalıştırmanızı öneririz:

• NCCL all-reduce benchmark: Node’lar arası iletişim bant genişliğini ve gecikmeyi ölçer.
• HPL (LINPACK): Teorik zirve FP64 hesap gücüne ne kadar yaklaşıldığını gösterir.
• MPI bant genişliği ve gecikme testi (OSU Micro-Benchmarks): Ağ katmanının doğrulanması için kullanılır.

Elde edilen sonuçları teorik maksimumla karşılaştırın. Verimliliğin %80’in altında kalması bir yapılandırma sorununa ya da donanım arızasına işaret edebilir.

En İyi Pratikler

• Node’lar arasında yazılım ve sürücü sürümlerini (CUDA, cuDNN, NCCL, MPI) eşzamanlı tutmak için konfigürasyon yönetimi araçları (Ansible, Salt) kullanın.
• GPU sıcaklık, kullanım oranı, bellek bant genişliği ve güç tüketimini Prometheus + Grafana yığınıyla sürekli izleyin.
• Uzun süreli eğitim işleri için periyodik checkpoint kaydetme alışkanlığı edinin; donanım arızası durumunda sıfırdan başlamak büyük zaman kaybına yol açar.
• Çok kiracılı ortamlarda GPU kotası ve öncelik politikalarını baştan net biçimde tanımlayın.

Sonuç

GPU cluster kurulumu; doğru donanım seçimi, yüksek hızlı ağ tasarımı, paralel depolama altyapısı ve uygun iş zamanlayıcısının bir arada optimize edilmesini gerektiren çok katmanlı bir süreçtir. Bu sürecin her adımında alınan kararlar hem kısa vadeli performansı hem de uzun vadeli ölçeklenebilirliği doğrudan etkiler.

GPU cluster altyapısı kurmayı ya da mevcut yapınızı optimize etmeyi düşünüyorsanız GPU Cluster Çözümü sayfamızda Mevasis’in sunduğu uçtan uca hizmetleri inceleyebilir, gereksinimlerinizi paylaşmak için iletişim sayfamızı ziyaret edebilirsiniz.