Belleğe Sığdı Ama Yine de Kullanılamadı — Önce Bant Genişliği Aritmetiğini Yapın

Yanlış Soruyla Başlamak

Yerel yapay zeka ve LLM dağıtımlarında en sık sorulan soru "Bu model donanımımıza sığar mı?" olur. Yanıtlaması maliyetsiz olduğu için herkes ilk olarak buna bakar: Model ya belleğe yüklenir ya da yüklenmez. Oysa iş çıkarma hızı (throughput), gerçek bir ölçüm ve analiz gerektirir. Kapasite testi geçildiğinde karar verilmiş gibi hissedilir; fakat asıl performans darboğazı tam bu noktada başlar.

Yapılan Ölçüm

Deney, 24 GB birleşik belleğe ve ~120 GB/s bellek bant genişliğine sahip bir Mac Mini M4 üzerinde gerçekleştirildi:

Model: 27B parametreli, IQ4_XS ile kuantize edilmiş, diskte 15 GB yer kaplayan model.
Kapasite testi: Başarılı. Metal çalışma kümesi 17.76 GB sınırı içinde, model 15 GB ve GPU doluluğu %100. Bellek takası (swap) veya taşma yok.
Üretim hızı: Saniyede 5.6 token.

Bu hız, etkileşimli bir asistan için kullanışsız, arka plan toplu işleri (batch) içinse sınırda bir değerdir. Üstelik yalın kapasite kontrolü bu darboğaza dair en ufak bir uyarı vermemiştir.

Önceden Uyaran Basit Aritmetik

Otoragresif üretim sürecinde, üretilen her bir token için model ağırlıklarının tamamı bellekten bir kez okunur. Dolayısıyla ulaşılabilecek teorik tavan hız:

$$\text{Tavan Hız} \approx \frac{\text{Bellek Bant Genişliği}}{\text{İşlem Başına Okunan Veri}} = \frac{120 \text{ GB/s}}{15 \text{ GB}} = 8 \text{ token/s}$$

Ölçülen 5.6 token/s, teorik tavan olan 8 değerinin %70'idir (oran: 0.70). Ölçülen hız tavanın büyük bir dilimini kaplıyorsa sistem bant genişliği sınırlıdır (bandwidth-bound). Darboğaz yapılandırmada veya ısınmada değil; verinin veri yolundan akış hızındadır.

Geliştiriciler için temel kural: Oran $\ge$ 0.5 ise sistem bant genişliğine takılmıştır ve model boyutunu küçültmeye dayalı çözümler tükenmiştir.

Neden "Daha Fazla Kuantize Etmek" İşe Yaramaz?

Kapasite yetmediğinde ilk refleks modeli daha da küçültmektir (daha sert kuantizasyon, daha küçük batch). Ancak bant genişliği sınırındayken bu yaklaşım pratik fayda sağlamaz. Örneğin modeli 13.8 GB boyutundaki Q3_K_M seviyesine indirdiğimizde:

$$120 \div 13.8 = 8.7 \text{ token/s}$$

Elde edilen hız artışı %9'un altındadır. Buna karşılık çıktı kalitesindeki düşüş oldukça belirgindir; çünkü kuantizasyon kaynaklı kalite kaybı bant genişliği gibi doğrusal ölçeklenmez. Kapasite (bellekteki bayt miktarı) ile verim (veri yolundaki bayt/saniye hızı) farklı kaynaklarca yönetilir.

Doğru Darboğazı Adlandırmak

Darboğazın bellek bant genişliği olduğunu bilmek, donanım seçimini doğrudan netleştirir:

Donanım	Bellek Bant Genişliği	15 GB Model İçin Teorik Tavan
M4	~120 GB/s	8 token/s
M4 Pro	~273 GB/s	18 token/s
M4 Max	~546 GB/s	36 token/s

"Bu model çok yavaş" ifadesi yanıltıcıdır; doğru teşhis "Bu model 120 GB/s bant genişliğinde çok yavaş" olmalıdır. Kısıt doğru tanımlandığında hangi iyileştirmenin işe yarayacağı açıkça görülür.

Yapılan Anti-Desenler

"Belleğe sığdı, o halde rahatça kullanabiliriz": Çıkarım hızını ve bant genişliği sınırını hesaplamadan yalnızca VRAM/RAM kapasitesine güvenmek, üretim aşamasında performans sorunlarına yol açan temel bir yanılgıdır.

Orijinal kaynağa buradan ulaşabilirsiniz.

Bu konuyu derinlemesine öğrenmek isterseniz: Ölçeklendirme ve Optimizasyon modülüne göz atın.