AI Altyapısı: GPU, TPU, Edge ve Dağıtık Eğitim Terimleri (Bütçe Rehberi)

Bu rehber kimler için, neyi çözer?

“Yapay zeka donanımı ve altyapı” araması yapan pek çok kişi aynı soruya takılıyor: GPU mu, TPU mu, edge mi, yoksa dağıtık eğitim mi? Bu sorunun tek bir doğru cevabı yok; çünkü doğru seçim iş yüküne (model türü, veri boyutu, gecikme hedefi, güvenlik/uyum gereksinimleri) ve bütçe modelinize (CapEx/OpEx, ekip yetkinliği, tedarik hızı) bağlı.

Bu yazı, terimleri netleştirir, bütçe planlarken gözden kaçan kalemleri listeler ve “denemeden satın alma” riskini azaltmak için pratik bir karar akışı verir. Resmi dokümantasyon ve endüstri benchmark’larına dayalı genel ilkeleri kullanır; fiyat ve performans rakamları tedarikçiye, bölgeye ve konfigürasyona göre değiştiği için burada sayısal vaatler yerine yöntem sunar.

Hızlı sözlük: Temel terimler (pratik tanım)

GPU (Graphics Processing Unit)

GPU, paralel hesaplama için tasarlanmış genel amaçlı bir hızlandırıcıdır. Derin öğrenmede yaygın olmasının nedeni; olgun yazılım ekosistemi ve farklı model tiplerinde esnek çalışabilmesidir. Veri merkezi GPU’ları, eğitim (training) ve çıkarım (inference) için güçlü seçeneklerdir. NVIDIA’nın H100 gibi veri merkezi GPU’larında çoklu örnekleme (MIG gibi) ve veri merkezi kullanımına yönelik özellikler bulunur (ayrıntılar için: NVIDIA H100 MIG dokümantasyonu).

TPU (Tensor Processing Unit)

TPU, tensör işlemlerini hızlandırmak için tasarlanmış bir ASIC ailesidir. Google Cloud üzerinde “Cloud TPU” olarak sağlanır ve belirli eğitim/çalıştırma senaryolarında verimlilik hedefler (bkz. Google Cloud TPU dokümantasyonu). Pratikte TPU seçimi; kullandığınız framework/derleyici akışı, model mimarisi ve ekibinizin operasyon alışkanlıklarıyla yakından ilişkilidir.

Edge AI (Kenar Yapay Zeka) ve Edge Inference

Edge AI, modelin bulutta değil cihaz üzerinde (telefon, kamera, IoT cihazı, endüstriyel PC vb.) çalıştırılmasıdır. Amaç genellikle düşük gecikme, bağlantı bağımsızlığı ve verinin yerinde kalmasıdır. Bunun karşılığında model boyutu, hassasiyet (quantization) ve donanım/çerçeve uyumluluğu kısıtları daha belirgin olabilir.

MLPerf gibi benchmark’lar, edge ve veri merkezi senaryolarında performans/enerji gibi ölçümlere dair tekrar üretilebilir bir referans noktası sunar (bkz. MLPerf Inference v5.0 sonuçları). Önemli uyarı: Benchmark sonuçları; model, precision (örn. FP16/INT8), batch size, derleyici/çalışma zamanı ve sunum (submission) ayarlarına çok duyarlıdır. Bu nedenle yalnızca benzer konfigürasyonları kıyaslayın ve nihai karar için kendi iş yükünüzle PoC çalıştırın.

Training (Eğitim) vs Inference (Çıkarım)

• Eğitim: Modelin ağırlıklarının öğrenildiği, genellikle çok daha pahalı ve uzun süren süreç.
• Çıkarım: Eğitilmiş modelin yeni veriler üzerinde tahmin yaptığı süreç. Üretimde toplam maliyeti çoğu zaman çıkarım belirler (yüksek trafik, 7/24 çalışma).

Distributed Training (Dağıtık Eğitim)

Tek bir cihaz/tek bir sunucu yerine birden çok GPU/TPU düğümüyle eğitimi ölçeklemektir. Dağıtık eğitim performansı yalnızca hızlandırıcıya değil; ağ altyapısına, paralellik stratejisine ve yazılım optimizasyonlarına da bağlıdır. DeepSpeed gibi araçlar; bellek verimliliği (ZeRO) ve paralellik yaklaşımlarıyla büyük modelleri daha az kaynakla eğitmeye yardımcı olur (bkz. DeepSpeed Getting Started).

GPU vs TPU vs Edge: “Hangisi daha iyi?” sorusunu doğru sormak

Doğru soru şudur: Benim iş yükümde, benim kısıtlarımla en iyi toplam sonucu (maliyet + hız + risk) hangisi verir? MLPerf gibi benchmark’lar, farklı donanımların farklı senaryolarda farklı sonuçlar üretebildiğini gösterir; bu nedenle kendi iş yükünüze yakın bir test planlamak en güvenli yaklaşımdır (bkz. MLPerf Inference v5.0).

Karar matrisini basitleştiren 6 soru

1. İş yükü eğitim mi çıkarım mı? Eğitim ağırlıklıysanız bellek ve ölçekleme stratejileri öne çıkar; çıkarım ağırlıklıysanız gecikme, batch stratejisi ve maliyet/istek (cost per request) kritiktir.
2. Gecikme hedefiniz nedir? Gerçek zamanlı (ör. canlı altyazı, çağrı merkezi asistanı) uygulamalar edge veya düşük gecikmeli veri merkezi çıkarımı ister.
3. Model boyutu ve bağlam ihtiyacı nedir? Büyük LLM’lerde bellek/iletişim maliyeti belirleyici olur; küçük modeller edge’de daha rahat çalışır.
4. Hassasiyet/quantization kullanacak mısınız? Daha düşük hassasiyet; maliyeti ve gecikmeyi azaltabilir, ancak doğruluk etkisini ölçmek gerekir.
5. Ekibiniz hangi ekosistemde daha hızlı ilerler? Operasyonel alışkanlıklar (sürücüler, izleme, dağıtım) toplam sahip olma maliyetini ciddi etkiler.
6. Veri yerleşimi ve uyum gereksinimleri var mı? Verinin nerede işlendiği (bulut, on-prem, cihaz) kararınızı kısıtlayabilir.

Özet karşılaştırma tablosu (sayısal iddia içermeyen)

Bütçe dili: CapEx vs OpEx ve “gizli” maliyet kalemleri

AI altyapısı bütçesi çoğu kurumda iki ana kutuya ayrılır:

• CapEx: Donanımı satın alma (sunucu, hızlandırıcı, ağ, raf/enerji/soğutma yatırımı). Muhasebe yaklaşımı kuruma göre değişir.
• OpEx: Kiralama/abonelik (bulut instance’ları, yönetilen servisler), operasyon (SRE/DevOps zamanı), veri transferi ve izleme gibi devam eden maliyetler.

Genel ilke: Bulut, başlangıç bariyerini düşürür ve hızlı deneme sağlar; ancak sürekli ve yüksek hacimli işlerde OpEx birikebilir. Tersi yönde, on-prem yatırım daha çok ön maliyet ister; fakat uzun vadede kullanım sabitse avantajlı olabilir. Net karar için kendi kullanım profilinizle TCO çalışması yapmak gerekir.

TCO (Toplam Sahip Olma Maliyeti) için pratik kontrol listesi

• Hesaplama: Hızlandırıcı saatleri (GPU/TPU), CPU, RAM
• Depolama: Eğitim veri seti, checkpoint’ler, model registry
• Ağ: Dağıtık eğitimde yüksek bant genişliği; bulutta veri çıkış ücretleri
• Operasyon: İzleme, güvenlik yamaları, sürücü/kitaplık yönetimi, incident maliyeti
• Verimlilik: Boşta kalan kapasite (özellikle sabit cluster’larda)
• Zaman-to-train: Modeli daha hızlı eğitmek, ürüne çıkışı hızlandırarak dolaylı değer yaratabilir

Inference cost (çıkarım maliyeti) nasıl düşünülür?

Çıkarım maliyetini “tek birim”e indirgemek, karar vermeyi kolaylaştırır. Birim tanımı senaryoya göre değişir:

• Sohbet botu: istek başı maliyet veya 1.000 token başı maliyet
• Görsel sınıflandırma: görüntü başı maliyet
• Ses: dakika başı maliyet

Bu maliyeti etkileyen başlıklar:

• Batching: Daha yüksek throughput genelde daha düşük birim maliyet, ama gecikmeye etkisi olur.
• Model optimizasyonu: Quantization, pruning, derleme/graph optimizasyonu.
• Önbellekleme: Tekrarlı isteklerde maliyeti azaltabilir (özellikle LLM uygulamalarında).
• Donanım uyumu: Her model her hızlandırıcıda aynı verimle çalışmayabilir; benchmark sonuçlarını yalnızca benzer ayarlarla kıyaslayın (bkz. MLPerf).

Dağıtık eğitim: Hızlandırıcı seçimi kadar ağ ve yazılım da bütçedir

Bir modeli daha çok hızlandırıcıyla ölçeklemek “doğrusal hızlanma” sağlamayabilir. Bunun nedeni, cihazlar arası iletişim ve senkronizasyon maliyetidir. Bu yüzden dağıtık eğitim bütçesinde aşağıdakiler birlikte düşünülür:

1) Paralellik stratejileri (kavramsal)

• Data parallelism: Veriyi bölüp aynı modeli farklı parçalarda çalıştırma. Basit başlangıç, ama iletişim maliyeti artabilir.
• Tensor parallelism: Katman içi hesaplamayı bölme. Büyük modellerde yaygın, uygulaması daha karmaşık.
• Pipeline parallelism: Katmanları aşamalara bölme. Gecikme/boru hattı dengelemesi önemlidir.

2) Bellek optimizasyonu: “Daha az GPU ile daha büyük model” yaklaşımı

DeepSpeed gibi çözümler, özellikle büyük modellerde bellek kullanımını azaltmaya odaklanır. ZeRO yaklaşımı; optimizer state/gradient gibi bileşenleri daha verimli yönetmeye yardımcı olur (bkz. DeepSpeed dokümantasyonu). Bu tip optimizasyonlar, satın almanız veya kiralamanız gereken toplam hızlandırıcı sayısını etkileyebileceği için doğrudan bütçe konusudur.

3) Ağ altyapısı: “Ucuz hızlandırıcı + zayıf ağ” genelde pahalıya gelir

Dağıtık eğitimde ağ bant genişliği ve gecikme, ölçek verimliliğini belirler. Bu nedenle karar verirken şu soruları sorun:

• Düğüm içi ve düğümler arası bağlantı (interconnect) kapasiteniz, hedef paralellik türünü destekliyor mu?
• Bulut seçeneğinde, seçtiğiniz instance tipi ve cluster yerleşimi (placement) yüksek performanslı iletişim sunuyor mu?
• İletişim darboğazını ölçmek için profil çıkarma araçlarınız var mı?

GPU seçerken pratik notlar: Esneklik, çoklu kullanım ve izolasyon

GPU’lar genellikle “tek donanımla çok iş” ihtiyacında güçlüdür. Özellikle kurum içinde farklı ekiplerin farklı modelleri denediği eğitim ortamlarında esneklik değer yaratır. Bazı veri merkezi GPU’larında, tek bir fiziksel GPU’yu birden çok bağımsız örneğe bölmeye yarayan yaklaşımlar bulunur (ör. MIG). Bu, aynı donanım üzerinde farklı iş yüklerini daha kontrollü paylaştırmaya yardımcı olabilir (bkz. NVIDIA H100 MIG).

Ne zaman GPU daha mantıklı olabilir?

• Model çeşitliliğiniz yüksekse (görsel, metin, ses, çoklu modalite).
• Ekibinizin araç zinciri GPU ekosisteminde oturmuşsa.
• Farklı framework’lerde hızlı prototipleme yapmanız gerekiyorsa.

GPU maliyetini etkileyen operasyonel detaylar

• Kapasite planlama: Eğitim işleri uzun sürebilir; yanlış planlama boşta kalma yaratır.
• Önceliklendirme: Aynı cluster’da Ar-Ge denemeleri ile üretim çıkarımını karıştırmak maliyet ve güvenilirlik riskini artırabilir.
• Gözlemlenebilirlik: GPU kullanım metrikleri, bellek taşmaları ve I/O darboğazları erken yakalanmazsa saatler boşa gidebilir.

TPU seçerken pratik notlar: Yönetilen deneyim ve uyumluluk

TPU, Google Cloud’un sağladığı bir hızlandırıcı seçeneğidir ve dokümantasyonda çeşitli kullanım modelleri ve konfigürasyonlar anlatılır (bkz. Cloud TPU docs). TPU’nun avantajları; bazı iş yüklerinde verimlilik ve yönetilen ortam hedefleriyle ilişkilendirilir. Ancak pratikte başarı; modelinizin TPU akışına ne kadar iyi oturduğu ve ekibin debug/izleme sürecini ne kadar iyi yönettiğiyle belirlenir.

TPU değerlendirme soruları

• Hedef framework ve sürümünüz TPU üzerinde üretim olgunluğunda mı?
• Modelinizin katmanları ve operasyonları TPU dostu mu (desteklenmeyen op riski)?
• Taşınabilirlik önemli mi? (Örneğin çoklu bulut veya on-prem planı)

Benchmark okurken nasıl temkinli olmalı?

MLPerf sonuçları, donanımlar arası kıyas için değerli bir başlangıçtır; fakat konfigürasyon, hassasiyet, batch ve yazılım yığını sonuçları belirgin biçimde etkiler. Bu yüzden sonuçları “nihai hüküm” yerine kendi PoC planınızı şekillendiren işaretler olarak kullanın (bkz. MLPerf Inference v5.0).

Edge AI bütçesi: Donanımdan çok “dağıtım ve yaşam döngüsü” maliyeti

Edge senaryolarında hızlandırıcı maliyeti sadece başlangıçtır. Asıl soru şudur: Modeli binlerce cihaza nasıl güvenli dağıtacak, izleyecek ve güncelleyeceksiniz?

Edge için bütçe kalemleri

• Model paketleme: Cihaz çeşitliliği (farklı SoC’ler) için derleme ve test matrisi
• Güncelleme: OTA güncellemeleri, geri alma (rollback) stratejisi
• Gizlilik ve veri yönetimi: Cihazda veri kalıyorsa bile telemetri ve hata ayıklama için plan gerekir
• Performans hedefleri: Gecikme, enerji tüketimi, ısıl kısıtlar

Edge mi, bulut çıkarımı mı? Basit bir kural

Bağlantı kesintisi kabul edilemiyorsa, gecikme çok kritikse veya verinin cihazdan çıkmaması gerekiyorsa edge ağır basar. Diğer durumlarda bulut çıkarımı, operasyonel kolaylık ve daha hızlı iterasyon sunabilir. Net karar için pilot test yapın ve birim maliyetinizi ölçün.

Satın alma öncesi 2 haftalık PoC (kanıtlama) planı

“GPU vs TPU” gibi kararlar, kısa bir PoC ile çok daha sağlıklı hale gelir. Aşağıdaki planı küçük bir ekiple 1–2 haftada uygulayabilirsiniz:

Gün 1–2: İş yükünü netleştirin

• Hedef model(ler) ve veri boyutu
• Başarı metriği: doğruluk, gecikme (p95/p99), throughput, maliyet/birim
• Hassasiyet hedefi: FP32/FP16/BF16/INT8 gibi (ürün gereksinimine göre)

Gün 3–6: Tek düğüm testleri (baseline)

• 1 GPU veya 1 TPU konfigürasyonunda baseline eğitim/çıkarım ölçümü
• Profil çıkarma: darboğaz CPU mu, bellek mi, I/O mu?

Gün 7–10: Ölçekleme denemeleri

• Dağıtık eğitim gerekiyorsa DeepSpeed gibi bir araçla ölçekleme denemesi yapın (bkz. DeepSpeed).
• İletişim maliyetini gözlemleyin; ağın ölçek verimliliğine etkisini not edin.

Gün 11–14: Bütçe özetini çıkarın

• Birim maliyet: istek/1.000 token/görüntü başına
• Operasyon maliyeti: kurulum, izleme, hata ayıklama zamanı
• Riskler: taşınabilirlik, tedarik esnekliği, ekip yetkinliği

Bu çıktılar, satın alma ya da uzun vadeli rezervasyon gibi büyük kararları daha az belirsizlikle vermenizi sağlar.

Sonuç: Terimlerden karara

GPU, TPU, edge ve dağıtık eğitim; birbirinin alternatifi olduğu kadar çoğu zaman birbirini tamamlayan seçeneklerdir. En doğru yaklaşım, önce iş yükünü ve başarı metriğini netleştirmek; sonra MLPerf gibi genel benchmark’lardan yön alıp kendi PoC’nizle doğrulamaktır (bkz. MLPerf). Dağıtık eğitimde yazılım optimizasyonlarının ve ağ altyapısının maliyete etkisini özellikle ciddiye alın (bkz. DeepSpeed).

Bir sonraki adım olarak, kurumunuzun hedef modeli ve trafik profilini (eğitim sıklığı + günlük çıkarım hacmi) çıkarıp yukarıdaki PoC planını uygulayın. Sonra CapEx/OpEx seçeneklerini, aynı ölçüm metodolojisiyle kıyaslayın.