GPU Maliyet Optimizasyonu Rehberi (2026)

GPU Maliyetleri Neden Kontrolden Çıkıyor?

Açık konuşalım: 2026'da bulut faturanızın en can yakıcı kalemi artık sanal makineler ya da depolama değil — GPU tabanlı yapay zeka iş yükleri. State of FinOps 2026 raporuna göre FinOps ekiplerinin %98'i artık yapay zeka harcamalarını yönetiyor. İki yıl önce bu oran sadece %31'di. Bir düşünün, %31'den %98'e — bu sıradan bir artış değil.

Yapay zeka öncülüğünde hareket eden kurumlarda GPU yoğun iş yükleri toplam bulut harcamasının %18'ini oluşturuyor; 2023'te bu oran sadece %4'tü. Tek bir NVIDIA H100 GPU'nun donanım maliyeti yaklaşık 40.000 dolar, tam donanımlı bir sunucusu ise 400.000 dolara ulaşabiliyor. Bu maliyetler saatlik kiralama fiyatlarına aynen yansıyor ve kontrol mekanizması kurulmadığında faturalar inanılmaz hızla şişiyor.

Peki sorun tam olarak nerede?

Geleneksel FinOps, tahmin edilebilir ve mevsimsel kullanım kalıplarına dayalı bir yaklaşım izliyordu. Ama yapay zeka iş yükleri — özellikle LLM çıkarımı — bambaşka bir dinamik sergiliyor. Dakikadaki istek sayısı, model seçimi, çıktı uzunluğu sürekli dalgalanıyor. Aylık bütçe döngüsüne dayalı eski tahminleme modeli bu kaotik yapıyı yakalamakta yetersiz kalıyor.

Bu rehberde, AWS, Azure ve GCP üzerinde GPU maliyetlerinizi somut adımlarla nasıl düşüreceğinizi göstereceğiz. Spot instance stratejilerinden NVIDIA MIG ile GPU bölümlemeye, Karpenter ile otomatik ölçeklendirmeden model optimizasyonuna kadar — 2026'nın en güncel yöntemlerini pratik örneklerle ele alacağız.

AWS, Azure ve GCP: 2026 GPU Fiyatlandırma Karşılaştırması

Strateji belirlemeden önce mevcut tabloyu net görmek gerekiyor. H100 GPU'lar için 2026 yılı on-demand fiyatları şöyle:

AWS (P5 - H100): GPU başına yaklaşık 3,90 $/saat. AWS, Haziran 2025'te P5 instance'larında %45'e varan indirim açıkladı — ciddi bir kırılım noktası.
GCP (A3-High - H100): GPU başına yaklaşık 3,00 $/saat. Google agresif fiyatlandırmayla pazardaki konumunu güçlendirmeye devam ediyor.
Azure (ND H100 v5): GPU başına yaklaşık 6,98 $/saat. Evet, fiyat yüksek — ama Azure'un kurumsal SLA ve uyumluluk avantajlarını da göz önünde bulundurmak lazım.

Yeni nesil tarafında ise AWS'in P6-B200 instance'ları NVIDIA Blackwell B200 GPU'ları kullanıyor ve H100'lere kıyasla LLM eğitiminde 2,5 kat daha yüksek performans sunuyor. GPU başına 192 GB HBM3e belleğe sahip bu instance'lar Savings Plans kapsamına da alındı, bu da uzun vadeli planlama yapanlar için iyi haber.

Şunu unutmayın: bunlar on-demand fiyatlar. Yazının ilerleyen bölümlerinde göreceğiniz gibi spot instance'lar, rezervasyonlar ve GPU paylaşım teknikleriyle bu maliyetleri %60-90 oranında düşürmek mümkün.

Spot ve Preemptible GPU Instance'ları ile Büyük Tasarruf

GPU maliyet optimizasyonunda en hızlı kazanım spot instance kullanımından gelir. Kendi deneyimlerimize dayanarak söyleyebiliriz: doğru yapılandırıldığında spot GPU'lar gerçekten oyun değiştirici.

Üç büyük sağlayıcının spot/preemptible GPU fiyatlarına bakalım:

AWS Spot: On-demand fiyatın %60-70 altında. P5 (H100) spot fiyatı yaklaşık 2,50 $/GPU-saat.
GCP Spot/Preemptible: On-demand fiyatın %60-91 altında. A3-High (H100) spot fiyatı yaklaşık 2,25 $/GPU-saat.
Azure Spot: On-demand fiyatın %20-30 altında (GPU instance'larında). ND H100 v5 spot fiyatı yaklaşık 18 $/saat (8 GPU). Azure'da spot indirim oranları GPU'larda biraz daha muhafazakâr.

Tabii spot instance kullanmanın bir bedeli var: sağlayıcı kapasiteye ihtiyaç duyduğunda instance'ınız herhangi bir anda sonlandırılabilir. Bu yüzden spot GPU'ları yalnızca kesintiye dayanıklı iş yüklerinde kullanmanız gerekiyor — model eğitimi, batch çıkarım ve veri ön işleme gibi senaryolarda.

Checkpoint Stratejisi: Spot Kesintilerine Karşı Koruma

Spot instance ile GPU eğitimi yapıyorsanız, düzenli checkpoint kaydetmek zorunlu. Bunu ihmal etmeyin — tek bir kesintide saatlerce eğitim kaybetmek gerçekten moral bozucu. İşte PyTorch ile otomatik checkpoint yapan bir örnek:

import torch
import signal
import sys

class SpotCheckpointManager:
    def __init__(self, model, optimizer, checkpoint_dir="s3://my-bucket/checkpoints"):
        self.model = model
        self.optimizer = optimizer
        self.checkpoint_dir = checkpoint_dir
        self.epoch = 0
        self.global_step = 0
        # Spot termination sinyalini yakala (AWS 2 dakika onceden uyarir)
        signal.signal(signal.SIGTERM, self._handle_termination)

    def _handle_termination(self, signum, frame):
        print("Spot termination notice received! Saving checkpoint...")
        self.save_checkpoint(emergency=True)
        sys.exit(0)

    def save_checkpoint(self, emergency=False):
        checkpoint = {
            "model_state_dict": self.model.state_dict(),
            "optimizer_state_dict": self.optimizer.state_dict(),
            "epoch": self.epoch,
            "global_step": self.global_step,
        }
        path = f"{self.checkpoint_dir}/checkpoint_epoch{self.epoch}_step{self.global_step}.pt"
        torch.save(checkpoint, path)
        print(f"Checkpoint saved: {path}")

    def load_latest_checkpoint(self):
        # En son checkpoint dosyasini bul ve yukle
        import glob
        checkpoints = sorted(glob.glob(f"{self.checkpoint_dir}/checkpoint_*.pt"))
        if checkpoints:
            checkpoint = torch.load(checkpoints[-1])
            self.model.load_state_dict(checkpoint["model_state_dict"])
            self.optimizer.load_state_dict(checkpoint["optimizer_state_dict"])
            self.epoch = checkpoint["epoch"]
            self.global_step = checkpoint["global_step"]
            print(f"Resumed from epoch {self.epoch}, step {self.global_step}")
            return True
        return False

Bu yaklaşımla spot instance sonlandırıldığında eğitim kaldığı yerden devam eder. AWS 2 dakika, GCP ise 30 saniye önceden kesinti uyarısı gönderir — bu sürede checkpoint kaydedilir ve veri kaybı önlenir.

NVIDIA MIG ile Tek GPU'yu Birden Fazla İş Yüküne Bölme

GPU maliyetlerinin en büyük nedenlerinden biri aslında şaşırtıcı derecede basit: düşük kullanım oranı. Bir H100 GPU'ya tam kapasite ödüyorsunuz ama çoğu çıkarım iş yükü GPU kapasitesinin sadece %10-30'unu kullanıyor. Geri kalan kapasite boşa gidiyor. İşte tam bu noktada NVIDIA Multi-Instance GPU (MIG) devreye giriyor.

MIG, tek bir fiziksel GPU'yu 7'ye kadar izole instance'a bölebilir. Her instance'ın kendi hesaplama çekirdekleri, belleği ve önbelleği var — yani birden fazla iş yükü birbirini etkilemeden aynı GPU üzerinde çalışabiliyor.

Pratikte MIG nasıl bir fark yaratır? Şöyle düşünün: 4 ayrı inference modeli çalıştırmak için 4 adet A10 GPU kiralayacağınıza (Azure'da saatlik yaklaşık 15 $), tek bir H100 instance'ı MIG ile bölüp hepsini tek GPU üzerinde çalıştırabilirsiniz (yaklaşık 8 $/saat). Bu %47 tasarruf demek — ve performansta kayda değer bir düşüş yaşamadan.

Kubernetes'te MIG Yapılandırması

MIG'i Kubernetes üzerinde kullanmak için NVIDIA GPU Operator gerekiyor. Adım adım bakalım:

# 1. NVIDIA GPU Operator kurulumu (Helm ile)
helm install gpu-operator nvidia/gpu-operator \
  --namespace gpu-operator \
  --create-namespace \
  --set mig.strategy=mixed \
  --set migManager.enabled=true

# 2. Node'a MIG profili atama
kubectl label node gpu-node-01 nvidia.com/mig.config=all-balanced

# 3. MIG yapilandirma ornegi (ConfigMap)
# all-balanced profili H100 icin:
# 3x 3g.40gb + 1x 1g.10gb seklinde bolumleme yapar

Pod'larınızda belirli bir MIG dilimi talep etmek için şu şekilde bir yapılandırma kullanabilirsiniz:

apiVersion: v1
kind: Pod
metadata:
  name: inference-model-a
spec:
  containers:
  - name: vllm-server
    image: vllm/vllm-openai:latest
    resources:
      limits:
        nvidia.com/mig-3g.40gb: 1  # H100 uzerinde 3/7 dilim talep et
    env:
    - name: MODEL_NAME
      value: "meta-llama/Llama-3-8B"
---
apiVersion: v1
kind: Pod
metadata:
  name: inference-model-b
spec:
  containers:
  - name: triton-server
    image: nvcr.io/nvidia/tritonserver:24.01-py3
    resources:
      limits:
        nvidia.com/mig-1g.10gb: 1  # Daha kucuk bir dilim
    env:
    - name: MODEL_NAME
      value: "sentence-transformers/all-MiniLM-L6-v2"

Dikkat: MIG yapılandırmasını değiştirmek GPU sıfırlaması gerektirir. Bu yüzden production ortamında MIG profillerini önceden planlayın ve çalışma zamanında değiştirmekten kaçının. Ayrıca MIG yalnızca NVIDIA Ampere ve sonrası mimarilerle (A100, A30, H100) çalışır — eski nesil GPU'larda bu seçenek mevcut değil.

Karpenter ile GPU Otomatik Ölçeklendirme

Kubernetes'te GPU iş yüklerini yönetiyorsanız muhtemelen Karpenter'ı zaten duymuşsunuzdur. 2026 itibarıyla fiilen standart haline geldi diyebiliriz. Geleneksel Cluster Autoscaler'dan farklı olarak Karpenter, sabit node gruplarına bağlı kalmıyor — bekleyen pod'ların gerçek kaynak gereksinimlerine göre doğrudan EC2 Fleet API üzerinden node sağlıyor.

GPU iş yükleri için Karpenter'ın en kritik özelliği spot instance entegrasyonu. İşte kapsamlı bir NodePool yapılandırması:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-ai-workloads
spec:
  template:
    spec:
      requirements:
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values:
            - "p5.48xlarge"    # H100 - egitim icin
            - "g6.xlarge"      # L4 - inference icin
            - "g6.2xlarge"
            - "g5.xlarge"      # A10G - inference icin
            - "g5.2xlarge"
        - key: "karpenter.sh/capacity-type"
          operator: In
          values:
            - "spot"           # Oncelik spot
            - "on-demand"      # Spot bulunamazsa on-demand
        - key: "topology.kubernetes.io/zone"
          operator: In
          values:
            - "eu-west-1a"
            - "eu-west-1b"
            - "eu-west-1c"     # Tum AZ leri ekleyerek spot kapasitesini maksimize et
      nodeClassRef:
        group: karpenter.k8s.aws/v1
        kind: EC2NodeClass
        name: gpu-node-class
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    budgets:
      - nodes: "20%"          # Ayni anda en fazla %20 node disrupt edilebilir
  limits:
    cpu: "1000"
    memory: "4000Gi"
    nvidia.com/gpu: "32"       # Maksimum 32 GPU limiti (maliyet kontrolu)
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: gpu-node-class
spec:
  amiSelectorTerms:
    - alias: "bottlerocket@latest"  # GPU cold start i azaltmak icin
  blockDeviceMappings:
    - deviceName: /dev/xvdb
      ebs:
        volumeSize: 200Gi
        volumeType: gp3
        snapshotID: "snap-0abc123"  # ML imajlari on yuklu snapshot

Bu yapılandırmada dikkat etmeniz gereken birkaç nokta var:

Birden fazla instance tipi: Tek bir instance tipine bağlı kalmak spot pazarında kapasite yetersizliği hatalarına yol açar. Birden fazla tip ve AZ tanımlayarak spot başarı oranını ciddi şekilde artırırsınız.
Bottlerocket AMI: AWS'in minimal container-optimize işletim sistemi Bottlerocket, GPU cold start sürelerini gözle görülür şekilde azaltıyor. ML imajlarını önceden yüklenmiş EBS snapshot'ları ile kullanmak da başlangıç süresini kısaltır.
GPU limiti: nvidia.com/gpu: "32" satırı toplam GPU sayısını sınırlıyor — bu basit ama etkili bir maliyet güvenlik ağı. İnanın, bu limit olmazsa işler çığırından çıkabiliyor.
Disruption budget: Aynı anda en fazla %20 node'un disrupt edilmesine izin vererek AI iş yüklerinin sürekliliğini koruyorsunuz.

Rezervasyon ve Savings Plans ile Tahmin Edilebilir Tasarruf

Spot instance'lar kesintiye dayanıklı iş yükleri için harika, ama sürekli çalışan production inference servisleri için her zaman en iyi seçenek olmayabilir. Bu tür iş yüklerinde Reserved Instance'lar ve Savings Plans daha mantıklı.

2026'daki GPU rezervasyon seçenekleri şöyle:

AWS Compute Savings Plans: 1 veya 3 yıllık taahhütle on-demand fiyata göre %40-72 tasarruf. P6-B200 instance'ları da artık Savings Plans kapsamında — bu önemli bir gelişme.
Azure Reserved VM Instances: 1-3 yıllık taahhütle %30-50 indirim. GPU VM'leri için genellikle %30 civarı.
GCP Committed Use Discounts (CUD): 1-3 yıllık taahhütle %55'e varan indirim. GPU iş yükleri için de geçerli.

Optimal strateji çoğu zaman hibrit bir yaklaşımdır: tahmin edilebilir taban yük için rezervasyon, ani yoğunluklar için spot, kalan ihtiyaçlar için on-demand. Bu üçlü kombinasyonu doğru kurguladığınızda toplam GPU maliyetlerinizi %40-60 oranında düşürebilirsiniz. Kulağa iddialı geliyor ama gerçekten ulaşılabilir bir hedef.

Model Optimizasyonu ile Dolaylı GPU Maliyet Düşürme

Buraya kadar altyapı tarafını konuştuk. Ama GPU maliyetlerini düşürmenin bir de yazılım tarafı var — daha az GPU kaynağına ihtiyaç duyan, optimize edilmiş modeller kullanmak. İki temel teknik öne çıkıyor.

Quantization (Niceleme)

Model ağırlıklarını 32-bit (FP32) yerine 8-bit (INT8) veya 4-bit (INT4) hassasiyette saklayarak bellek tüketimini ve hesaplama maliyetini düşürebilirsiniz. Pratikte bu, aynı modeli 2-4 kat daha küçük GPU belleğinde çalıştırabilmek anlamına geliyor.

# vLLM ile 4-bit quantized model calistirma ornegi
# Bu yaklasim GPU bellek tuketimini ~4x azaltir
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3-70B-Instruct \
  --quantization awq \
  --dtype half \
  --max-model-len 4096 \
  --gpu-memory-utilization 0.9 \
  --tensor-parallel-size 2  # 2 GPU yeterli (quantize olmadan 4+ GPU gerekirdi)

70B parametreli bir modeli quantize ederek 4 GPU yerine 2 GPU ile çalıştırabilirsiniz. Bu doğrudan %50 GPU maliyet tasarrufu — ve çoğu durumda kalite kaybı ihmal edilebilir düzeyde.

Model Distillation (Model Damıtma)

Büyük bir modelin bilgisini daha küçük bir modele aktararak, benzer kalitede ama çok daha düşük maliyetle çalışan bir model elde edebilirsiniz. Mesela 70B parametreli bir modeli 8B parametreli bir modele damıtmak, inference maliyetini 8-10 kat düşürebilir. Bu ciddi bir fark.

FinOps Dashboard: GPU Maliyetlerini Görünür Kılma

Optimizasyonun ilk adımı her zaman görünürlüktür. Paranın nereye gittiğini göremiyorsanız, neyi optimize edeceğinizi de bilemezsiniz. GPU iş yükleri için etkili bir FinOps dashboard'u şu metrikleri içermeli:

GPU kullanım oranı (%): %50'nin altındaysa right-sizing veya MIG değerlendirmesi yapmanın zamanı gelmiştir.
Model başına maliyet: Token başına maliyet, çıkarım başına maliyet, eğitim epoch'u başına maliyet — bunları ayrı ayrı takip edin.
Takım/proje başına harcama: Etiketleme stratejisi ile her GPU harcamasının bir sahibi olmalı.
Spot vs on-demand oranı: Spot kullanım oranı ne kadar yüksekse tasarruf o kadar fazla.
Boşta kalan GPU'lar: Eğitim tamamlandıktan sonra hâlâ çalışan instance'ları tespit edin. Bunlar en sinsi maliyet sızıntılarıdır.

AWS'te GPU kullanımını izlemek için CloudWatch ile bir temel sorgu:

# GPU kullanimini izleyen CloudWatch metrikleri
aws cloudwatch get-metric-statistics \
  --namespace "AWS/EC2" \
  --metric-name GPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc123def456 \
  --start-time $(date -u -d "7 days ago" +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 3600 \
  --statistics Average Maximum \
  --output table

# Dusuk GPU kullanimli instance lari tespit etme
aws ce get-cost-and-usage \
  --time-period Start=$(date -u -d "30 days ago" +%Y-%m-%d),End=$(date -u +%Y-%m-%d) \
  --granularity DAILY \
  --metrics "UnblendedCost" \
  --filter '{"Dimensions": {"Key": "INSTANCE_TYPE_FAMILY", "Values": ["p5", "g5", "g6"]}}' \
  --group-by Type=DIMENSION,Key=INSTANCE_TYPE

Her yapay zeka iş yükünün mutlaka bir sorumlu sahibi olmalı. Etiketleme stratejiniz şu alanları kapsamalı: owner, team, environment, project, workload-type ve cost-centre. Deneysel iş yükleri için mutlaka bir son kullanma tarihi etiketi ekleyin — unutulan GPU instance'ları gördüğümüz en yaygın maliyet sızıntısı kaynağı, bunu hafife almayın.

Sıkça Sorulan Sorular

Yapay zeka iş yüklerinde bulut maliyetlerini düşürmenin en hızlı yolu nedir?

En hızlı kazanım spot/preemptible GPU instance'ları kullanmaktır — on-demand fiyata kıyasla %60-90 tasarruf sağlayabilir. Eğitim iş yüklerinde checkpoint mekanizması kurarak spot kesintilerine karşı korunabilirsiniz. İkinci en hızlı yöntem ise boşta kalan GPU instance'larını tespit edip kapatmak — bazen en etkili optimizasyon gereksiz harcamayı durdurmak kadar basittir.

GPU spot instance kullanırken eğitim verim kaybı yaşanır mı?

Düzenli checkpoint stratejisi uygulandığında verim kaybı minimumdur. AWS 2 dakika, GCP 30 saniye önceden kesinti uyarısı gönderir. Modern framework'ler (PyTorch, TensorFlow) checkpoint kaydetme ve yükleme işlemlerini saniyeler içinde tamamlar. Birden fazla instance tipi ve Availability Zone tanımlayarak kesinti olasılığını da düşürebilirsiniz.

NVIDIA MIG ile GPU time-slicing arasındaki fark nedir?

MIG, GPU'yu fiziksel olarak izole bölümlere ayırır — her bölümün kendi bellek ve hesaplama kaynağı vardır, dolayısıyla performans garantisi sunar. Time-slicing ise GPU'yu zaman dilimlerine bölerek paylaştırır ama izolasyon sunmaz; bir iş yükü diğerini etkileyebilir. Kısa cevap: production inference için MIG, geliştirme ve test ortamları için time-slicing. İkisini birlikte kullanarak MIG bölümleri içinde time-slicing uygulamak da mümkün.

GPU maliyet optimizasyonu için hangi FinOps araçlarını kullanmalıyım?

AWS için AWS Cost Explorer ve AWS Compute Optimizer GPU önerileri sunar. Multi-cloud ortamlar için Kubecost (Kubernetes GPU maliyetleri), Cast AI (otomatik GPU ölçeklendirme), CloudHealth veya Flexera FinOps platformları değerlendirilebilir. Açık kaynak tarafında OpenCost ve NVIDIA DCGM Exporter ile Prometheus/Grafana kombinasyonu öne çıkıyor.

Quantization uygulanan modelde kalite kaybı yaşanır mı?

Modern quantization teknikleri (AWQ, GPTQ) ile kalite kaybı genellikle %1-3 aralığında kalıyor ve çoğu production uygulaması için kabul edilebilir düzeyde. INT8 quantization neredeyse kayıpsız. INT4 daha agresif tasarruf sağlıyor ama belirli görevlerde kalite düşüşü gözlemlenebilir. Tavsiyemiz: quantization uygulamadan önce kendi veri setinizle mutlaka benchmark yapın.