Yapay zekâda “doğru donanım” neden tek bir cevap değil?

GPU, TPU ve bulut hızlandırıcıları (ör. AWS Trainium ailesi gibi) arasında seçim yaparken tek bir “en iyi” seçenekten çok, iş yükünüzün karakteristiğine göre değişen bir optimum vardır. Aynı model bile; kullanılan sayısal hassasiyet (BF16/FP16/FP8 gibi), batch boyutu, hedef gecikme, veri hattı, paralelleştirme stratejisi ve hatta bulut bölgesindeki kapasite durumuna göre çok farklı sonuçlar üretebilir.

Bu yüzden en sağlıklı yaklaşım: (1) gereksinimleri netleştirmek, (2) kıyaslama verisini doğru okumak, (3) kısa bir POC ile kendi metriklerinizi ölçmektir. Bağımsız karşılaştırmalar için MLPerf Inference ve MLPerf Training sonuçları iyi bir başlangıç sinyali verir; ancak birebir maliyet çıkarımı yapmak için tek başına yeterli olmayabilir.

Önce kavramlar: Eğitim (training) ve çıkarım (inference) farklı problemler

Eğitim (training) neyi zorlar?

  • Hesaplama yoğunluğu: Geri yayılım (backprop) ve optimizasyon adımları daha ağırdır.
  • Bellek ve iletişim: Büyük modellerde aktivasyonlar, optimizer state ve gradient iletişimi darboğaz olabilir (çoklu hızlandırıcı, NVLink/NVSwitch gibi).
  • Ölçek: Tek karttan çoklu düğüme (cluster) çıkınca ağ topolojisi ve yazılım yığını kritikleşir.

Çıkarım (inference) neyi zorlar?

  • Gecikme (latency) vs throughput dengesi: Gerçek zamanlı sohbet/arama farklı; toplu (batch) işleme farklıdır.
  • Maliyet/istek: Üretimde en çok konuşulan metrik çoğu zaman “istek başı maliyet”tir.
  • Kararlılık: Trafik dalgalanması, ölçekleme, kuyruk yönetimi, soğuk başlangıç etkileri.

Seçenekler: GPU, TPU ve bulut hızlandırıcıları (Trainium gibi)

GPU (özellikle NVIDIA ekosistemi) ne zaman öne çıkar?

GPU’lar geniş çerçeve desteği (CUDA tabanlı ekosistem), araç zinciri olgunluğu ve pek çok model/kitaplıkla uyumluluğu nedeniyle hem eğitimde hem çıkarımda en yaygın tercihlerden biridir. Yeni nesil veri merkezi GPU mimarilerinin (ör. Hopper) eğitim/çıkarım için getirdiği özellikler, üretici teknik anlatımlarında detaylandırılır (NVIDIA Hopper Architecture In-Depth).

Bulutta GPU seçerken instance düzeyindeki ayrıntılar önemlidir. Örneğin Azure, H100 tabanlı seçeneklerini belirli seri/konfigürasyonlarla sunar ve bunların bağlantı/topoloji özellikleri (NVLink vb.) dokümantasyonda açıklanır (Azure ND H100 v5).

GPU seçiminin güçlü yanları

  • Ekosistem uyumu: Eğitim ve çıkarım çerçevelerinde yaygın destek.
  • Çok amaçlı kullanım: Aynı altyapıyla farklı model türleri (LLM, görüntü, öneri sistemleri) arasında geçiş kolaylığı.
  • Benchmark görünürlüğü: MLPerf sonuçlarında geniş sistem çeşitliliğiyle temsil.

TPU (Google Cloud) ne zaman anlamlı olabilir?

TPU’lar Google’ın yapay zekâ iş yükleri için tasarladığı hızlandırıcı ailesidir. Cloud TPU v5e gibi nesillerin hedefi; belirli ölçekleme desenlerinde maliyet/performans ve verimliliktir. Google’ın resmi dokümantasyonu; v5e’nin nasıl konumlandığını, eğitim ve çıkarım senaryolarında nasıl çalıştırılacağını ve pratik operasyon ayrıntılarını sunar (TPU v5e | Google Cloud Documentation).

TPU seçiminin güçlü yanları

  • Belirli iş yüklerinde verimlilik odağı: Bazı büyük ölçekli çıkarım ve eğitim desenlerinde avantaj hedefi.
  • Yönetilen deneyim: TPU’ya özgü çalışma biçimleri ve araçlar (kurulum/operasyon kalıbı) daha standart hale gelebilir.

AWS Trainium (ve AWS ekosistemi) ne zaman uygun?

AWS, eğitim odaklı Trainium ailesini (ve çıkarıma dönük Inferentia ailesini) AWS içinde maliyet-etkin ölçek için konumlandırır. Resmi ürün sayfası, hedef kullanım alanlarını ve AWS Neuron yazılım yığınını genel hatlarıyla açıklar (AWS Trainium).

Trainium seçiminin güçlü yanları

  • AWS’e “yakın” mimari: AWS üzerinde çalışan ekipler için ağ, depolama, izleme, güvenlik araçlarıyla uyumlu bir yol haritası.
  • Maliyet hedefi: Ürün konumlandırması, eğitim/inference maliyetlerini azaltma yönündedir (sonuçlar iş yüküne bağlıdır).

Karar kriterleri: Seçimi gerçekten belirleyen 7 soru

1) Modelinizin boyutu ve mimarisi nedir?

LLM gibi büyük transformer modelleri ile CNN tabanlı görüntü modelleri; bellek, iletişim ve çekirdek verimliliği açısından farklı davranır. Büyük modellerde çoklu hızlandırıcı ölçeklemesi ve iletişim topolojisi daha erken kritik hale gelir.

2) Hedefiniz eğitim mi, fine-tuning mi, çıkarım mı?

Eğitimde saatler/günler süren büyük işler için verimlilik ve ölçeklenebilirlik; çıkarımda ise gecikme, throughput ve istek başı maliyet baskın olur. Bu ayrımı netleştirmek, “tek bir platformla her şeyi yapma” ısrarından daha sağlıklı kararlar doğurur.

3) Hassasiyet (precision) ve doğruluk gereksinimi nedir?

BF16/FP16/FP8 gibi seçenekler, performans ve maliyeti etkiler. Ancak her model her hassasiyetle aynı şekilde davranmaz; bazen kaliteyi korumak için ek teknikler gerekebilir (ör. kayıp ölçekleme, kalibrasyon vb.). Bu nedenle donanım seçiminden önce hedef kalite kriterlerinizi (ör. doğruluk, BLEU, ROUGE, task score) ve kabul edilebilir sapmayı belirleyin.

4) Gecikme mi throughput mu öncelikli?

  • Gerçek zamanlı: Kullanıcıya yanıt veren uygulamalarda p95/p99 gecikme hedefi ve kuyruk yönetimi kritik.
  • Toplu çıkarım: Raporlama, indeksleme, offline scoring gibi işlerde throughput ve toplam maliyet öne çıkar.

MLPerf Inference sonuçları, çeşitli senaryolarda sistemlerin nasıl konumlandığına dair bir çerçeve sağlar; yine de kendi modeliniz ve servis şeklinizle birebir eşleşmeyebilir (MLPerf Inference v5.0).

5) Yazılım yığını ve ekip becerisi ne kadar belirleyici?

GPU tarafında CUDA ekosistemi ve araçlar, TPU tarafında XLA/TPU akışı, AWS Trainium tarafında Neuron yığını gibi farklı “öğrenme eğrileri” vardır. Donanım maliyetinden bağımsız olarak, mühendislik zamanı ve hata ayıklama/optimizasyon döngüsü toplam maliyeti ciddi etkileyebilir.

6) Bulut erişilebilirliği ve kapasite riski var mı?

Seçtiğiniz bölge, instance bulunabilirliği ve kota/kapasite durumları (özellikle popüler GPU tiplerinde) projeyi yavaşlatabilir. Bu nedenle mimariyi tek bir tipe kilitlemeden, en azından alternatif bir “B planı” tasarlamak mantıklıdır.

7) Toplam sahip olma maliyetini (TCO) neye göre ölçeceksiniz?

Yalnızca saatlik instance ücreti değil; aşağıdaki kalemlerle birlikte ölçün:

  • Depolama ve veri aktarımı (özellikle çok bölgeli ve yüksek hacimli durumlar)
  • Model servis katmanı (otomatik ölçekleme, gözlemlenebilirlik, A/B, güvenlik)
  • Optimizasyon zamanı (profiling, kernel/graph optimizasyonu, quantization denemeleri)
  • İş sürekliliği (yeniden deneme, checkpoint, kesinti planı)

GPU vs TPU vs Trainium: Pratik karşılaştırma tablosu

Aşağıdaki tablo, “hangi durumda hangisine bakılır?” sorusuna hızlı bir çerçeve sunar. Son kararı vermeden önce mutlaka POC ile doğrulama yapın.

Kriter GPU (genel) TPU (Cloud TPU) AWS Trainium
Ekosistem olgunluğu Geniş ve yaygın TPU odaklı akış; öğrenme eğrisi olabilir AWS Neuron odaklı; AWS içinde güçlü
Benchmark görünürlüğü MLPerf’te geniş temsil (Training, Inference) Belirli konfigürasyonlarla karşılaştırılır; sonuçlar senaryoya bağlı Karşılaştırmalar iş yüküne ve entegrasyona bağlı
Ölçekleme/cluster Topoloji (NVLink/NVSwitch) kritik; bulutta modele göre değişir TPU topolojileri ve çalışma modeli dokümantasyonla yönlendirilir (TPU v5e) AWS instance ailesine göre; AWS servisleriyle entegrasyon avantajı
Operasyon pratikleri Geniş örnekler, araçlar; ancak yapılandırma çeşitliliği yüksek Belirli kalıplar daha standart olabilir AWS içinde standardizasyon; Neuron araçlarına yatırım gerekir
Ne zaman ilk bakış adayı? Çok çeşitli model/çerçeve, hızlı prototipleme, geniş taşınabilirlik Ölçekli TPU iş akışlarına uygun senaryolar, belirli maliyet/perf hedefleri AWS merkezli mimari, maliyet odaklı eğitim/servisleme hedefi

MLPerf sonuçlarını doğru okumak: Nelere dikkat etmeli?

MLPerf raporları, endüstride kabul gören bir karşılaştırma çerçevesi sunar (MLPerf Inference v5.0, MLPerf Training v5.1). Yine de kararınızı tek bir grafiğe dayandırmamak için şu kontrol listesini kullanın:

  • İş yükü benzer mi? Sizin modeliniz/servis şekliniz benchmark senaryosuna ne kadar yakın?
  • Hassasiyet/optimizasyonlar neler? Sonuçlar hangi hassasiyet ve hangi optimizasyonlarla elde edilmiş?
  • Sistem bileşenleri? CPU, bellek, ağ, sürücüler ve yazılım sürümleri performansı etkiler.
  • Throughput vs latency modu? Bazı sonuçlar throughput’u, bazıları sıkı gecikme hedeflerini önceler.

Özetle: MLPerf “hangi sınıf sistemlerin güçlü olabileceğini” gösterir; sizin ortamınızda kaç dolar/kaç token edeceğini görmek için POC gerekir.

Adım adım seçim yöntemi: 2 haftalık POC planı (uygulanabilir)

Adım 1: Hedef metrikleri yazın

  • Eğitim: epoch süresi, hedef kalite metriği, kesinti toleransı
  • Çıkarım: p95/p99 gecikme, throughput, hata oranı, ölçekleme davranışı
  • Maliyet: iş başı maliyet (ör. 1M token başına), aylık tavan bütçe (varsa)

Adım 2: Temsili bir “mini iş yükü” seçin

Tüm modeli taşımak yerine, karar verdiren darboğazı temsil eden küçük bir test oluşturun: ör. sınırlı veriyle fine-tuning, ya da gerçek uç noktadan geçen tipik istek dağılımı.

Adım 3: Üç aday platform belirleyin

  • GPU tabanlı bir seçenek (ör. bulutta H100 sınıfı)
  • TPU seçeneği (Cloud TPU v5e gibi)
  • AWS odaklıysanız Trainium (veya organizasyonunuzun kullandığı alternatif hızlandırıcı)

Adım 4: Kurulum ve gözlemlenebilirliği standardize edin

Aynı ölçüm yöntemiyle karşılaştırın: aynı batch/sequence uzunluğu, aynı pre/post-processing, aynı loglama. Aksi halde kıyas “kurulum farkı” ölçer.

Adım 5: En az iki senaryo ölçün

  • İyimser (yüksek batch/throughput odaklı)
  • Gerçekçi (gerçek trafik dağılımı ve gecikme hedefi)

Adım 6: Maliyet hesabına operasyon kalemlerini ekleyin

Salt hızlandırıcı maliyetine değil; veri aktarımı, depolama, servis katmanı ve mühendislik zamanına da “etiket” koyun. Bu, çoğu ekipte sonucu değiştirir.

Adım 7: Taşınabilirlik ve kilitlenme riskini tartın

Bir platformu seçmek, aynı zamanda araç zinciri ve operasyon alışkanlığı seçmektir. “Gerektiğinde başka buluta geçebilir miyim?” sorusunu erken sorun.

Örnek senaryolar: Hangi yaklaşım ne zaman mantıklı?

Senaryo A: Küçük ekip, hızlı prototip ve ürünleşme

Hızlı iterasyon, hazır kütüphaneler, hata ayıklama kolaylığı önemlidir. Bu tür ekiplerde GPU ekosistemi pratik olabilir; ancak bütçe baskınsa, bulut sağlayıcınızın maliyet odaklı hızlandırıcı seçeneklerini POC ile denemek anlamlıdır.

Senaryo B: Büyük ölçekli eğitim (çoklu düğüm) ve tekrar eden işler

Burada ağ topolojisi, küme yönetimi, checkpoint stratejisi ve uzun süreli kaynak garantisi önem kazanır. Azure gibi sağlayıcıların belirli yüksek ölçekli GPU serileri için yayınladığı teknik detaylar (bağlantı/topoloji notları) kararın parçası olmalıdır (Azure ND H100 v5).

Senaryo C: Çıkarım maliyeti kritik, trafik dalgalı

Auto-scaling ve kapasite yönetimi, ham hız kadar önemlidir. Modeli optimize ederek (ör. uygun quantization stratejileri) aynı donanımda daha fazla throughput almak mümkün olabilir; ama hangi optimizasyonların güvenli olduğuna modeliniz karar verir. Kıyas için MLPerf Inference raporlarını referans alıp kendi servis hedeflerinizle eşleştirin (MLPerf Inference v5.0).

Sonuç: Seçimi basitleştiren “tek sayfa” kontrol listesi

  • İş yükünü isimlendirin: Eğitim mi, fine-tuning mi, çıkarım mı?
  • Metrikleri sabitleyin: Latency/throughput/kalite ve maliyet hedefleri.
  • Yazılım uygunluğunu doğrulayın: Kütüphane, çerçeve, derleyici ve izleme araçları.
  • MLPerf’ten yön bulun: Trendleri görün, ama sonucu POC ile onaylayın (Training, Inference).
  • Resmi dokümanlarla sınırları bilin: TPU v5e ve Trainium gibi platformların “nasıl çalıştırılır” ayrıntıları kurulum süresini belirler (TPU v5e, AWS Trainium).
  • 2 haftalık POC yapın: Kendi modelinizle kendi metriklerinizi ölçmeden karar vermeyin.

Not: Bu içerik genel bilgilendirme amaçlıdır. Bulut fiyatları, bölgeye ve satın alma modeline göre değişebilir; nihai karar için güncel sağlayıcı fiyatlandırması ve POC ölçümlerini birlikte değerlendirin.