Silikon Üçgeni ve Bellek Duvarı: NVIDIA Blackwell/Rubin, Apple M5 Unified Memory ve Google TPU v7 Ironwood’un Mimari Çarpışması

Modern yapay zeka mühendisliğinin en büyük yanılsaması, donanım kapasitesini yalnızca saniyedeki kayan nokta işlemi sayısıyla (FLOPS) ölçmektir. Üretim ortamında 400 milyar parametreli bir modeli ayağa kaldırdığınızda veya yerel bir kümede çoklu ajan (multi-agent) orkestrasyonu kurguladığınızda, acımasız bir fiziksel gerçekle yüzleşirsiniz: Hesaplama ucuzdur, ancak veriyi taşımak inanılmaz derecede pahalıdır.

7nm’den 3nm üretim süreçlerine (TSMC N3P/N3E) inildikçe transistör yoğunluğu ve matris çarpım hızı üstel olarak arttı. Ancak DRAM/SRAM hücrelerinden işlem birimlerine (ALU/MAC) veri taşıyan bakır veri yollarının kapasitesi ve enerji verimliliği aynı hızda ölçeklenemedi. Literatürde "Bellek Duvarı" (Memory Wall) olarak bilinen bu fenomen, 2026 yılı itibarıyla yapay zeka donanım dünyasını üç radikal mimari kampa bölmüş durumda:

1. NVIDIA (Blackwell B200 & Vera Rubin): Devasa HBM3e/HBM4 yığınları, yerel FP4 kuantizasyon motorları ve NVLink 5/6 anahtarlama kumaşıyla desteklenen, genel amaçlı paralel SIMT + Tensor Core kaba kuvveti.
2. Apple Silicon (M5 Max & M5 Ultra): PCIe veri yolu darboğazını tamamen yok eden, CPU, GPU ve Neural Engine'i tek bir fiziksel LPDDR5X/LPDDR6 bellek havuzunda buluşturan Sıfır-Kopya Birleşik Bellek Mimarisi (Unified Memory Architecture - UMA).
3. Google (TPU v6e Trillium & TPU v7 Ironwood): Önbellek hiyerarşisini ve komut çözme (instruction decode) ek yükünü donanımdan kazıyan, 256x256 Sistolik Diziler (Systolic Arrays) ve 9.216 çipi 3D Torus topolojisinde doğrudan birbirine bağlayan ICI (Inter-Chip Interconnect) tabanlı saf ASIC yaklaşımı.

Bu makalede, pazarlama slaytlarındaki teorik PFLOPS rakamlarını bir kenara bırakıyor; Roofline Performans Modeli, silikon veri akış (dataflow) diyagramları ve çekirdek (kernel) seviyesi kodlarla bu üç mimarinin anatomisini inceliyoruz.

1. Teorik Temel: Roofline Modeli, Prefill ve Decode Dikotomisi

Üç donanım mimarisinin neden birbirinden tamamen farklı tasarlandığını anlamak için önce Transformer (veya hibrit Mamba/MoE) mimarilerinin çalışma zamanı karakteristiğini ikiye ayırmamız gerekir: Prefill (Ön-dolum) ve Decode (Üretim).

Bir LLM'e 32.000 token'lık bir bağlam (prompt) gönderdiğinizde gerçekleşen Prefill aşamasında, tüm giriş token'ları paralel olarak işlenir. Burada işlemimiz devasa bir Matris-Matris Çarpımıdır (GEMM). Aynı ağırlık matrisi binlerce token üzerinde tekrar tekrar kullanıldığı için Aritmetik Yoğunluk (Arithmetic Intensity — Byte başına düşen FLOP sayısı) çok yüksektir. Bu faz tamamen Hesaplama Darboğazlıdır (Compute-Bound).

Ancak model ilk token'ı ürettikten sonra başlayan Autoregressive Decode fazında tablo tersine döner. Her adımda yalnızca tek bir token (veya küçük bir batch) üretilir. İşlem artık Matris-Matris çarpımı değil, Matris-Vektör Çarpımıdır (GEMV).

"Mimari Not: 100 milyar parametreli (FP8 formatında ~100 GB) bir yoğun (dense) modelde, tek bir kullanıcı için sadece 1 adet yeni token üretmek adına, o 100 GB'lık ağırlığın tamamının bellekten (HBM veya UMA) okunup işlemci yazmaçlarına (registers) taşınması gerekir. Saniyede 50 token üretmek istiyorsanız, saniyede 5 Terabyte (5 TB/s) saf bellek okuma bant genişliğine ihtiyacınız vardır. İşlemcinizin 100 PFLOPS gücünde olması bu gerçeği değiştirmez; işlem birimleriniz verinin yoldan gelmesini beklerken boşta (idle) kalır."

Bu durumu matematiksel olarak simüle eden ve 2026'nın amiral gemisi donanımlarını Aritmetik Yoğunluk (FLOPs/Byte) ekseninde karşılaştıran aşağıdaki Python analiz aracını inceleyelim:

from dataclasses import dataclass
from typing import Dict

@dataclass
class AIHardwareSpec:
    name: str
    peak_fp8_tflops: float      # Teorik TFLOPS (FP8 veya eşdeğeri)
    mem_bandwidth_gbps: float   # Bellek Bant Genişliği (GB/s)
    vram_capacity_gb: int       # Maksimum Tekil Bellek Kapasitesi (GB)
    interconnect_gbps: float    # Çipler arası bağlantı hızı (GB/s)

    @property
    def ridge_point(self) -> float:
        """
        Roofline Modeli 'Ridge Point' (Tepe Noktası):
        Donanımın Memory-Bound'dan Compute-Bound'a geçtiği minimum FLOPs/Byte oranı.
        """
        return (self.peak_fp8_tflops * 1e12) / (self.mem_bandwidth_gbps * 1e9)

    def estimate_decode_tps(self, active_params_billions: float, bytes_per_param: float = 1.0, batch_size: int = 1) -> float:
        """
        Düşük batch boyutunda (Memory-Bound) teorik maksimum Token/Saniye (TPS) hesabı.
        Etkin bant genişliği kullanımı %80 varsayılmıştır.
        """
        model_footprint_gb = active_params_billions * bytes_per_param
        if model_footprint_gb > self.vram_capacity_gb:
            return 0.0  # OOM (Out of Memory) - Tek çipe sığmıyor
        
        effective_bw = self.mem_bandwidth_gbps * 0.80
        # Batch size arttıkça ağırlıklar paylaşıldığı için toplam TPS artar (Ancak tekil gecikme sabit kalır)
        tokens_per_sec_per_stream = effective_bw / model_footprint_gb
        return round(tokens_per_sec_per_stream, 2)

# 2026 Güncel Donanım Spesifikasyonları
hardware_lineup: Dict[str, AIHardwareSpec] = {
    "NVIDIA_B200": AIHardwareSpec("NVIDIA Blackwell B200", peak_fp8_tflops=4500.0, mem_bandwidth_gbps=8000.0, vram_capacity_gb=192, interconnect_gbps=1800.0),
    "NVIDIA_Rubin": AIHardwareSpec("NVIDIA Vera Rubin R200", peak_fp8_tflops=17500.0, mem_bandwidth_gbps=22000.0, vram_capacity_gb=288, interconnect_gbps=3600.0),
    "Google_TPUv7": AIHardwareSpec("Google TPU v7 (Ironwood)", peak_fp8_tflops=4614.0, mem_bandwidth_gbps=7380.0, vram_capacity_gb=192, interconnect_gbps=1200.0),
    "Apple_M5_Max": AIHardwareSpec("Apple M5 Max (Mac Studio)", peak_fp8_tflops=140.0, mem_bandwidth_gbps=614.0, vram_capacity_gb=128, interconnect_gbps=0.0),
    "Apple_M5_Ultra": AIHardwareSpec("Apple M5 Ultra (Mac Studio)", peak_fp8_tflops=280.0, mem_bandwidth_gbps=1200.0, vram_capacity_gb=512, interconnect_gbps=0.0),
}

print(f"{'Donanım':<28} | {'Ridge Point (FLOP/B)':<20} | {'70B Dense (FP8) TPS':<20} | {'400B MoE (32B Aktif) TPS'}")
print("-" * 100)
for hw in hardware_lineup.values():
    tps_70b = hw.estimate_decode_tps(active_params_billions=70.0, bytes_per_param=1.0)
    # 400B toplam parametreli (400GB) ama token başına 32B aktif parametreli dev MoE model:
    if 400.0 <= hw.vram_capacity_gb:
        tps_moe = round((hw.mem_bandwidth_gbps * 0.80) / 32.0, 2)
    else:
        tps_moe = 0.0 # Tek cihaza sığmaz, multi-node gerekir
    
    moe_str = f"{tps_moe} tok/s" if tps_moe > 0 else "OOM (Multi-Chip Şart)"
    print(f"{hw.name:<28} | {hw.ridge_point:<20.1f} | {tps_70b:<14} tok/s | {moe_str}")

Yukarıdaki kodun çıktısını zihninizde çalıştırdığınızda çok çarpıcı bir mimari gerçek ortaya çıkar:

• NVIDIA B200 ve Google TPU v7 Ironwood, ~560 - 625 FLOP/Byte gibi devasa bir Ridge Point değerine sahiptir. Yani bu çiplerin hesaplama motorlarını tam kapasite doyurabilmek için bellekten okuduğunuz her 1 Byte veri başına yaklaşık 600 işlem yapmanız (yüksek batch size veya uzun bağlamlı Prefill) gerekir.
• Buna karşılık 400 Milyar parametreli (FP8'de 400 GB yer kaplayan) ancak her token için sadece 32 Milyar parametresi aktifleşen bir MoE (Mixture-of-Experts) modelini ele alalım. 192 GB HBM belleğe sahip tek bir NVIDIA B200 veya tek bir TPU v7 bu modeli belleğine sığdıramaz (OOM); modeli çalıştırmak için en az 2-4 çipi NVLink veya ICI üzerinden birleştirmeniz gerekir.
• Oysa 512 GB Birleşik Belleğe sahip tek bir Apple M5 Ultra Mac Studio, 400 GB'lık bu dev modeli tek başına belleğine alır ve sadece aktif olan 32 GB'lık uzmanları (experts) 1.2 TB/s hızındaki belleğinden okuyarak saniyede ~30 token hızında yerel olarak koşturabilir!

İşte bu yüzden donanım savaşları tek boyutlu bir hız yarışı değil, topoloji ve bellek hiyerarşisi savaşıdır. Şimdi bu üç mimarinin kaputunun altına inelim.

2. NVIDIA Cephesi: SIMT, Tensor Core, NVFP4 ve HBM3e/HBM4 Kaba Kuvveti

NVIDIA’nın mimari başarısı, 2006'da tanıttığı SIMT (Single Instruction, Multiple Threads) yürütme modelini, yapay zekaya özel Tensor Core matris motorları ve endüstrinin en agresif bellek/ağ paketleme teknolojileriyle evrimleştirmesinde yatar.

Blackwell (B200) ve Vera Rubin (R200) Mimarisi

TSMC 4NP süreciyle üretilen Blackwell B200, aslında tek bir monolitik silikon değildir. Retikül limitlerini (reticle limit) aşmak için iki devasa GB100 zarını (die) 10 TB/s hızındaki NV-High-Speed Interface (NV-HBI) ile birleştirerek işletim sistemine ve CUDA katmanına "tek bir GPU" gibi gösterir. 208 milyar transistör barındıran B200, 8 yığın HBM3e bellekle 192 GB kapasite ve 8 TB/s bant genişliği sunar.

2026'nın ikinci yarısında veri merkezlerine girmeye başlayan Vera Rubin (R200) mimarisi ise TSMC 3nm sürecine geçerek transistör sayısını 336 milyara çıkarıyor ve bellek tarafında HBM4 devrimini başlatıyor. HBM4, arayüz genişliğini ikiye katlayarak tek bir Rubin GPU üzerinde 288 GB kapasite ve tam 22 TB/s bellek bant genişliği sağlıyor.

5. Nesil Tensor Core ve İkinci Nesil Transformer Engine (FP4)

NVIDIA, Bellek Duvarı'nı sadece HBM hızını artırarak değil, taşınan verinin boyutunu küçülterek aşıyor. Blackwell ve Rubin'deki Tensor çekirdekleri, donanım seviyesinde yerel FP4 (4-bit kayan nokta / NVFP4) aritmetiğini destekler.

Standart kuantizasyonda tüm tensörü tek bir ölçekleme faktörüyle (scaling factor) 4-bite indirdiğinizde ciddi doğruluk (perplexity) kaybı yaşarsınız. NVIDIA'nın donanımsal Microscaling (MXFP4 / NVFP4) yaklaşımı ise her 16 veya 32 elemanlık mikro-blok için ayrı bir dinamik ölçekleme faktörü (E8M0 formatında) tutar ve bu dönüşümü Tensor Core içerisindeki donanım boru hattında (pipeline) sıfır gecikmeyle gerçekleştirir. Böylece 192 GB'lık bir B200, sanki 384 GB'lık bir FP8 GPU'ymuş gibi model ağırlığı barındırabilir ve 9 PFLOPS (seyrek/sparse ile 18 PFLOPS) FP4 hesaplama gücüne ulaşır.

TMA (Tensor Memory Accelerator) ve Asenkron Veri Akışı

Hopper ve Blackwell mimarilerinde yazılımcılar artık veriyi Global HBM'den Paylaşımlı Belleğe (Shared Memory / L1) taşımak için CUDA çekirdeklerini (threads) harcamazlar. Donanımsal TMA (Tensor Memory Accelerator) birimi, çok boyutlu tensör adreslemesini işlemciden bağımsız olarak üstlenir. Aşağıda, PyTorch 2.x ve Triton/CUDA felsefesiyle TMA ve FP8/FP4 Tensor Core kullanımının altında yatan asenkron yürütme mantığını görebilirsiniz:

import torch
import torch.nn as nn

# NVIDIA Blackwell / Hopper üzerinde Transformer Engine / Torch AO ile
# Bellek bant genişliği darboğazını yarıya indiren dinamik düşük hassasiyetli yürütme
def benchmark_nvidia_tensor_core_gemm(M: int, K: int, N: int):
    if not torch.cuda.is_available():
        print("CUDA cihazı bulunamadı, simülasyon modunda çıkılıyor.")
        return

    device = torch.device("cuda:0")
    # BF16 referans tensörleri (Her eleman 2 Byte)
    A_bf16 = torch.randn((M, K), device=device, dtype=torch.bfloat16)
    B_bf16 = torch.randn((N, K), device=device, dtype=torch.bfloat16)

    # Donanımsal FP8 (E4M3) dönüşümü (Her eleman 1 Byte -> Bellek trafiği %50 azalır)
    # Blackwell üzerinde NVFP4 ile bu trafik %75 azalır.
    scale_a = torch.tensor([1.0], device=device, dtype=torch.float32)
    scale_b = torch.tensor([1.0], device=device, dtype=torch.float32)
    
    A_fp8 = A_bf16.to(torch.float8_e4m3fn)
    B_fp8 = B_bf16.to(torch.float8_e4m3fn).t() # Column-major bekleyen cuBLASLt formatı

    # torch._scaled_mm doğrudan 5. Nesil Tensor Core PTX komutlarını (tcgen05.mma / wgmma) tetikler
    # TMA birimi HBM3e'den SM (Streaming Multiprocessor) Shared Memory'ye asenkron kopyalama yapar
    output = torch._scaled_mm(
        A_fp8, B_fp8,
        scale_a=scale_a, scale_b=scale_b,
        out_dtype=torch.bfloat16,
        use_fast_accum=True # Tensor Core akümülatörlerini tam hızda koşturur
    )
    return output

3. Apple Silicon Cephesi: Sıfır-Kopya (Zero-Copy) UMA ve M5 Ultra Devrimi

Geleneksel x86 + Ayrık (Discrete) GPU mimarisinde ölümcül bir yapısal kusur vardır: Sistem RAM'i (CPU) ile VRAM (GPU) birbirinden PCIe veri yolu (PCIe Gen 5 x16 bile çift yönlü sadece ~64 GB/s hız sunar) ile ayrılmıştır. Modeliniz GPU'nun VRAM'ine sığmadığı an (örneğin 24 GB veya 80 GB sınırını aştığında), veriyi sistem RAM'inden PCIe üzerinden taşımanız gerekir ki bu da performansı 100 kat düşürür.

Apple, M5 Max (128 GB'a kadar RAM, 614 GB/s bant genişliği) ve M5 Ultra (512 GB'a kadar RAM, 1.2 TB/s bant genişliği) çiplerinde Birleşik Bellek Mimarisi (Unified Memory Architecture - UMA) ile bu ayrımı fiziksel olarak yok eder.

UMA ve UltraFusion Paketleme Teknolojisi

M5 Ultra, iki adet M5 Max zarının UltraFusion adı verilen silikon ara bağlantı köprüsüyle (interposer) 2.5 TB/s'nin üzerinde bir iç bant genişliğiyle birleştirilmesiyle oluşur. Paketin etrafına dizilen yüksek hızlı LPDDR5X/LPDDR6 bellek kanalları (1024-bit toplam veri yolu genişliği), 1.2 TB/s (1.200 GB/s) bellek bant genişliği üretir.

Buradaki en kritik mimari detay Sıfır-Kopya (Zero-Copy) erişimdir:

• CPU çekirdekleri (10 Super Core + 20 Performance Core),
• 80 çekirdekli GPU (ve donanımsal Ray-Tracing / Matris hızlandırıcıları),
• 32 çekirdekli Neural Engine (NPU),

hepsi aynı fiziksel bellek adres uzayını paylaşır ve donanımsal önbellek tutarlılığına (hardware cache coherency) sahiptir. CPU bir JSON çıktısını ayrıştırırken (parsing) veya bir RAG vektör araması yaparken, veriyi GPU'ya "kopyalamaz"; sadece bellek işaretçisini (pointer) GPU'ya devreder.

"Mimari Not: Apple M5 serisiyle birlikte GPU çekirdeklerinin içine eklenen gelişmiş donanımsal matris çarpım hızlandırıcıları (Neural Accelerators), M4 serisine kıyasla LLM Prefill (Time-to-First-Token) süresini yaklaşık 3.9 kat hızlandırmıştır. Ancak Apple'ın asıl kalesi hala devasa bellek kapasitesidir: 512 GB belleğe sahip bir Mac Studio (~300W güç tüketimiyle), bulutta on binlerce dolara kiralanan çoklu GPU sunucularının tekelindeki 405B - 671B (DeepSeek V3/V4 veya Llama 4 sınıfı) modelleri tek bir masaüstü kutusunda çalıştırabilir."

Apple MLX ile Birleşik Bellek Programlama

Apple Araştırma ekibinin geliştirdiği MLX çerçevesi, UMA mimarisini ilk sınıf vatandaş olarak kullanmak için tasarlanmıştır. PyTorch veya CUDA'daki gibi .to("cuda") veya .to("cpu") çağrıları MLX'te yoktur; bunun yerine hangi hesaplama akışının (stream) o bellek adresini işleyeceğini seçersiniz:

import mlx.core as mx
import mlx.nn as nn

def unified_memory_hybrid_pipeline(tokens: mx.array, weight_quantized: mx.array, scales: mx.array):
    """
    Apple Silicon UMA üzerinde Sıfır-Kopya (Zero-Copy) hibrit yürütme örneği.
    Veri CPU ve GPU arasında kopyalanmaz; aynı fiziksel bellek adresi farklı
    yürütme birimleri (Stream) tarafından sırayla işlenir.
    """
    # 1. Küçük ve dallanmalı (branch-heavy) ön işleme adımlarını CPU stream'inde çalıştır
    # Veri hala aynı UMA adresindedir, PCIe transferi = 0 Byte!
    with mx.stream(mx.cpu):
        token_indices = mx.argmax(tokens, axis=-1)
        routing_mask = mx.where(token_indices > 1024, 1.0, 0.5)

    # 2. Ağır 4-bit Kuantize Matris-Vektör çarpımını (Decode) doğrudan 80 çekirdekli GPU'da çalıştır
    # mx.quantized_matmul, Metal SIMD-group matrix komutlarını kullanarak 1.2 TB/s UMA'yı sömürür
    with mx.stream(mx.gpu):
        hidden_state = mx.quantized_matmul(
            routing_mask,
            weight_quantized,
            scales=scales,
            biases=None,
            transpose=True,
            group_size=64,
            bits=4
        )
    
    # Lazy Evaluation: Grafiği derle ve CPU-GPU senkronizasyonunu tek seferde yürüt
    mx.eval(hidden_state)
    return hidden_state

4. Google TPU Cephesi: Sistolik Diziler, SparseCore ve TPU v7 (Ironwood)

NVIDIA bir İsviçre çakısı (grafik, fizik simülasyonu, CUDA, AI) ve Apple bir tüketici/profesyonel iş istasyonu iken; Google'ın Tensor Processing Unit (TPU) mimarisi yalnızca tek bir görev için tasarlanmış safkan bir ASIC (Uygulamaya Özel Tümleşik Devre) mimarisidir: Devasa ölçekte matris ve tensör matematiği.

Google’ın 7. nesil TPU mimarisi olan TPU v7 (kod adı Ironwood / TPU7x), önceki nesillerin "önce eğitim (training)" odağını kırarak "Çıkarım Çağı" (Age of Inference) için sıfırdan kurgulanmıştır.

Sistolik Dizi (Systolic Array - MXU) vs. NVIDIA SIMT

Bir GPU'da her matris çarpım adımında veriler Register File'dan (Yazmaçlardan) okunur, ALU'da çarpılıp toplanır ve tekrar Register File'a yazılır. Milyarlarca işlemde bu yazmaç okuma/yazma trafiği devasa bir güç tüketimi ve kontrol mantığı (control logic) maliyeti yaratır.

Google TPU v6e (Trillium) ve TPU v7 (Ironwood) ise 256x256 boyutunda Sistolik Diziler (Matrix Multiply Unit - MXU) kullanır. Sistolik dizinin çalışma prensibi insan kalbinin kan pompalamasına benzer:

1. Ağırlıklar (Weights) 256x256'lık matris hücrelerine önceden yüklenir ve sabitlenir (Weight Stationary).
2. Aktivasyon verileri (Giriş vektörleri) sol kenardan içeri pompalanır; kısmi toplamlar (partial sums) ise yukarıdan aşağıya doğru hücreden hücreye arada hiçbir yazmaç (register) veya önbelleğe (cache) uğramadan doğrudan komşu ALU'ya akar.
3. Tek bir saat vuruşunda (clock cycle) tek bir MXU tam 65.536 adet çarpma-toplama (MAC) işlemi gerçekleştirir.

TPU v7 Ironwood’un Teknik Anatomisi

Ironwood, donanım özellikleriyle doğrudan NVIDIA Blackwell B200'ün karşısına dikilir:

• Bellek ve Bant Genişliği: Çip başına 192 GB HBM3e bellek ve 7.380 GB/s (7.38 TB/s) bellek bant genişliği (Trillium v6e'ye göre 4.5 kat artış).
• Hesaplama Gücü: Çip başına 2 adet TensorCore (her birinde çift MXU) ile yerel FP8 hassasiyetinde 4.614 TFLOPS (4.6 PFLOPS), BF16 hassasiyetinde ise 2.307 TFLOPS.
• 4x SparseCore: MoE yönlendirmeleri, dinamik seyrek (sparse) dikkat mekanizmaları ve devasa gömme (embedding) tablolarını ana matris motorunu meşgul etmeden işleyen çip başına 4 adet özel SparseCore hızlandırıcısı.
• 9.216 Çipli 3D Torus Superpod ve ICI: Google'ın NVIDIA NVLink'e cevabı ICI (Inter-Chip Interconnect) ve OCS (Optical Circuit Switching - Optik Devre Anahtarlama) teknolojisidir. Ironwood, çip başına 1.2 TB/s çift yönlü ICI bağlantısıyla tam 9.216 çipi harici pahalı Ethernet/InfiniBand switch'lerine ihtiyaç duymadan 3 boyutlu bir simit (3D Torus) topolojisinde birbirine bağlar. Tek bir Ironwood Pod'u, toplamda 42.5 ExaFLOPS FP8 gücü ve 1.77 Petabyte paylaşımlı HBM belleği tek bir sanal süper bilgisayar olarak sunar.

XLA ve Pallas ile TPU VMEM Programlama

TPU'larda donanım tarafından yönetilen L1/L2 önbellek (cache) yoktur! Bunun yerine derleyici (XLA - Accelerated Linear Algebra) tarafından yönetilen ultra hızlı VMEM (Vector Memory - Scratchpad SRAM) bulunur. Geliştiriciler JAX ve Pallas (TPU için Triton benzeri çekirdek dili) kullanarak HBM'den VMEM'e veri akışını (DMA) elle boru hattına (pipeline) sokarlar:

import jax
import jax.numpy as jnp
from jax.experimental import pallas as pl
from jax.experimental.pallas import tpu as pltpu

# Google TPU v6e / v7 (Ironwood) üzerinde Pallas ile doğrudan VMEM (Scratchpad SRAM)
# ve 256x256 MXU (Matrix Multiply Unit) hedefli özel çekirdek (kernel) tanımı
def tpu_systolic_matmul_kernel(x_vmem_ref, w_vmem_ref, out_vmem_ref):
    """
    Bu fonksiyon çalıştığında veriler DMA motoru tarafından HBM'den
    TPU'nun çekirdek içi VMEM belleğine zaten taşınmış durumdadır.
    jnp.dot çağrısı doğrudan 256x256 Sistolik Dizi (MXU) donanım komutuna derlenir.
    """
    x_block = x_vmem_ref[...]
    w_block = w_vmem_ref[...]
    # FP8 donanımsal matris çarpımı, BF16/FP32 akümülatör ile
    out_vmem_ref[...] = jnp.dot(
        x_block, w_block,
        preferred_element_type=jnp.bfloat16
    )

def execute_tpu_pallas_gemm(x: jax.Array, w: jax.Array) -> jax.Array:
    M, K = x.shape
    _, N = w.shape
    # TPU v6e ve v7 Ironwood MXU boyutu 256x256 olduğu için blokları 256'nın katları seçiyoruz
    bm, bk, bn = 256, 256, 256
    
    return pl.pallas_call(
        tpu_systolic_matmul_kernel,
        out_shape=jax.ShapeDtypeStruct((M, N), jnp.bfloat16),
        grid_spec=pltpu.PrefetchScalarGridSpec(
            num_scalar_prefetch=0,
            grid=(M // bm, N // bn),
            in_specs=[
                pl.BlockSpec((bm, bk), lambda i, j: (i, 0)),
                pl.BlockSpec((bk, bn), lambda i, j: (0, j)),
            ],
            out_specs=pl.BlockSpec((bm, bn), lambda i, j: (i, j)),
        ),
        compiler_params=pltpu.TPUCompilerParams(
            dimension_semantics=("parallel", "parallel")
        )
    )(x, w)

5. Büyük Mimari Kıyaslama: Silikon Üçgeninin Sayısal Karnesi

Üç mimarinin 2026 yılındaki amiral gemisi temsilcilerini tüm kritik mühendislik metrikleriyle yan yana koyduğumuzda, her birinin hangi fiziksel darboğazı optimize ettiği netleşir:

6. Sistem Mimarları ve Mühendisler İçin Stratejik Çıkarımlar

Altyapı bütçesi ve teknoloji yol haritası belirlenirken "En hızlı çip hangisi?" sorusu yanlıştır. Doğru soru şudur: "Çalıştırdığım iş yükünün (workload) aritmetik yoğunluğu, eşzamanlılık (concurrency) profili ve veri gizliliği gereksinimi hangi silikon felsefesiyle örtüşüyor?"

1. Ne Zaman NVIDIA (Blackwell B200 / Rubin) Seçilmeli?

Eğer dinamik kontrol akışına sahip karmaşık ajan mimarileri, sürekli değişen açık ağırlıklı modeller (DeepSeek, Llama, Qwen, Mistral) ve yüksek eşzamanlılıklı (High-Batch) üretim API'leri sunuyorsanız NVIDIA hala tartışmasız standarttır.

• Neden? NVFP4 (4-bit) yerel Tensor Core desteği, 192 GB'lık B200 üzerinde devasa modelleri yarı boyutta tutarken 8 TB/s bant genişliğini efektif olarak 16 TB/s gibi kullanmanızı sağlar. Ayrıca CUDA ve Triton ekosistemi, literatürde yeni çıkan bir dikkat (attention) veya durum uzayı (Mamba/SSM) algoritmasının ilk gün (Day-0) donanım hızlandırmalı çalışmasını garanti eder.

2. Ne Zaman Google TPU (v6e Trillium / v7 Ironwood) Seçilmeli?

Eğer standartlaşmış bir Transformer/MoE mimarisi üzerinde gezegen ölçekli çıkarım (günde milyarlarca token) yapıyor, uzun bağlamlı (1M+ context window) modelleri eğitiyor veya Watt başına düşen TCO (Toplam Sahip Olma Maliyeti) metriğini optimize ediyorsanız TPU v7 Ironwood mühendislik harikasıdır.

• Neden? 256x256 Sistolik Dizi mimarisi, komut çözme ve yazmaç erişimi için harcanan silikon alanını ve enerjiyi sıfıra indirir. Daha da önemlisi, optik anahtarlamalı (OCS) 3D Torus ICI ağı sayesinde binlerce çip üzerinde Tensor Parallelism ve Expert Parallelism yaparken NVIDIA'nın harici InfiniBand switch katmanında yaşadığı ağ darboğazlarına ve maliyetlerine takılmazsınız. vLLM'in TPU backend desteğinin olgunlaşmasıyla birlikte, JAX bilmeseniz bile PyTorch modellerini TPU üzerinde koşturmak artık çok daha zahmetsizdir.

3. Ne Zaman Apple Silicon (M5 Max / M5 Ultra) Seçilmeli?

Kurumsal veri mahremiyeti (air-gapped ortamlar), yerel Ar-Ge, otonom kodlama ajanları ve düşük batch boyutlu (1-4 eşzamanlı kullanıcı) dev MoE modelleri söz konusu olduğunda Apple Unified Memory ezber bozan bir fiyat/performans (CapEx) avantajı sunar.

• Neden? Bulutta veya kendi veri merkezinizde 400 GB VRAM havuzu oluşturmak için 4x veya 8x H100/B200 sunucusu kurmak yüz binlerce dolarlık yatırım ve özel soğutma/enerji altyapısı gerektirir. Oysa 512 GB birleşik belleğe sahip bir M5 Ultra Mac Studio, masanızın altında sessizce çalışırken, token başına sadece küçük bir uzman alt kümesini (örneğin 30B-40B aktif parametre) çalıştıran devasa MoE modellerini 1.2 TB/s bant genişliğiyle saniyede 25-40 token hızında, sıfır bulut faturasıyla koşturabilir.

Son Söz

Yapay zeka çağında yazılım ve donanım arasındaki soyutlama duvarı yıkılmıştır. İyi bir yapay zeka mühendisi artık sadece Python'da model.generate() çağıran kişi değil; yazdığı her satır kodun HBM yığınlarından Sistolik Dizilere, Birleşik Bellek kanallarından Tensor Çekirdeklerine kadar elektronları nasıl hareket ettirdiğini hesaplayabilen kişidir. Silikon savaşlarının kazananı tek bir şirket olmayacak; iş yükünü doğru silikon topolojisiyle eşleştirebilen sistem mimarları olacaktır.