
Ollama’ya bir model indirmeye çalışırken “11 GB indirilecek” uyarısıyla karşılaştınız mı? Ya da HuggingFace’te aynı modelin Q4_K_M, Q5_K_S, Q8_0, -AWQ, -GPTQ etiketli beş farklı versiyonunu görüp hangisini seçeceğinizi bilemediyseniz, bu rehber tam size göre.
Bu etiketlerin tümü quantization tekniğinden kaynaklanıyor: modelin ağırlıklarını orijinal 32-bit ya da 16-bit hassasiyetten daha düşük bit sayısına indirgeyen bir yöntem. Model boyutunu küçültüyor, bellek ihtiyacını azaltıyor ve kimi zaman çıkarım hızını artırıyor. Kalite kaybı var, ama çoğu kullanım senaryosunda pratik olarak görmezden gelebileceğiniz düzeyde kalıyor.
Neden Bir LLM 70 GB Yer Kaplar?
Bir modelin “70 milyar parametre” içerdiğini söylediğinizde kastettiğiniz şey şu: 70.000.000.000 adet sayı. Eğitim sırasında öğrenilen bu sayılar, modelin dili anlamak ve üretmek için kullandığı ağırlıklardır.
Her parametre bir sayı, ama kaç bayt kaplar kullandığınız veri tipine göre değişir:
- float32 (tam hassasiyet): parametre başına 4 bayt → 70B × 4 = 280 GB
- float16 / bfloat16: parametre başına 2 bayt → 70B × 2 = 140 GB
- int8 (8-bit): parametre başına 1 bayt → 70B × 1 = 70 GB
- int4 (4-bit): parametre başına 0,5 bayt → 70B × 0,5 = 35 GB
Yüksek kaliteli tüketici GPU’larının belleği genellikle 24-80 GB arasında. Ev kullanıcısının elindeki RTX 4090’ın 24 GB VRAM’i var. Bu sayılarla bakıldığında, float16’da 70B modeli tek bir tüketici GPU’suyla çalıştırmak mümkün değil. 4-bit quantization uygulandığında ise aynı model 35 GB’a iniyor ve iki GPU ya da CPU offload kombinasyonuyla çalıştırılabilir hale geliyor.
Bu boyut farkı olmadan quantization’ın neden var olduğunu kavramak güç.
Quantization’ın Mantığı
Bir fotoğraf düzenleme programında renk paletini düşünün. “24-bit renk” derken her piksel için kırmızı, yeşil ve mavi kanallarının her biri 8-bit, yani 256 farklı değer alabiliyor. Bu paleti 4-bit’e düşürseniz her kanal yalnızca 16 farklı değer taşıyabilir; görüntü bozulmaya başlar, ama genel hatlar hâlâ okunabilir.
Model ağırlıkları için de benzer bir şey geçerli. Her ağırlık, orijinalde float32 ya da float16 ile ifade edilen bir ondalık sayı. Quantization bu sayıyı, bir ölçekleme katsayısı aracılığıyla daha az bitle temsil edilebilecek bir tamsayıya dönüştürür.
Kalite kaybı perplexity (modelin metni ne kadar iyi tahmin ettiğinin tersi) metrikiyle ölçülür. Model ne kadar az bitle çalışırsa perplexity o kadar artar. 16-bit’ten 8-bit’e geçişte bu fark genellikle yüzde birden az kalır; 4-bit’te fark biraz büyür ama pratikte anlamlı çıktılar üretmek için yeterli kalite korunur. 2-bit’te ise bozulma ciddi boyutlara ulaşır.
Önemli bir nokta: quantization modeli yeniden eğitmez, mevcut ağırlıkları yeniden temsil eder. Bu yüzden post-training quantization (PTQ) adıyla da anılır.
Bit Derinliği Karşılaştırması: 2b / 4b / 8b / 16b

| Bit Derinliği | 70B Model Boyutu | Perplexity Artışı | Önerilen Senaryo |
|---|---|---|---|
| 16-bit (float16) | ~140 GB | Referans (%0) | Araştırma, fine-tuning |
| 8-bit (int8) | ~70 GB | <%1 | Yüksek kalite gerektiren üretim |
| 4-bit (int4) | ~35 GB | %1-3 | Ev kullanımı, lokal çalıştırma |
| 2-bit (int2) | ~18 GB | >%10 | Deneysel, çok küçük modeller |
4-bit neden standart haline geldi? İki nedeni var. Birincisi, 4-bit ile 8-bit arasındaki kalite farkı çoğu görev için ihmal edilebilir düzeyde. İkincisi, 4-bit’in getirdiği bellek tasarrufu çok daha büyük modelleri tüketici donanımında çalıştırmayı mümkün kılıyor. 4B parametreli küçük bir modeli 16-bit’te tutmak yerine 70B parametreli büyük bir modeli 4-bit’te çalıştırmak, çoğu kullanım durumunda daha iyi çıktı üretiyor.
GGUF Formatı: llama.cpp Ekosistemi
GGUF, 2023’te GGML’nin yerini alan bir dosya formatıdır. Georgi Gerganov ve ekibinin geliştirdiği llama.cpp kütüphanesi etrafında şekillendi.
GGML’nin temel problemi şuydu: model mimarisindeki değişikliklere adapte olmak zordu ve her yeni model tipi format güncellemesi gerektiriyordu, geriye dönük uyumluluk kırılıyordu. GGUF bu sorunları tek dosya yapısı ve kapsamlı metadata alanlarıyla çözdü.
Bir .gguf dosyasının içinde şunlar bulunur:
- Model mimarisini tanımlayan metadata (katman sayısı, attention head sayısı, vocab boyutu…)
- Tokenizer sözlüğü ve özel token’lar
- Her transformer katmanının quantized ağırlıkları

Ollama, GGUF üzerine kurulu. ollama run llama3.2 komutunu çalıştırdığınızda, arka planda bir .gguf dosyası indirilip llama.cpp motoru tarafından çalıştırılıyor.
HuggingFace’teki GGUF etiketleri şu şemayı izliyor:
Q4_K_M→ 4-bit, K-quant ailesi, Medium varyantQ5_K_S→ 5-bit, K-quant, Small varyantQ8_0→ 8-bit, group-wise quantization, varyant 0Q2_K→ 2-bit, K-quant (düşük kalite, küçük boyut)
K-quants nedir? Standart quantization tüm katmanlara aynı bit derinliğini uygular. K-quant yaklaşımı ise kritik katmanları (özellikle attention ve output katmanları) daha yüksek bitte, daha az önemli katmanları daha düşük bitte tutar. Bu karma stratejinin sonucu: aynı ortalama bit derinliğinde daha iyi perplexity.
K_S (Small), K_M (Medium) ve K_L (Large) varyantları, yüksek-öncelikli katmanlara ne kadar bütçe ayrıldığına göre ayrışıyor. Çoğu kullanım durumu için Q4_K_M makul bir başlangıç noktası.
AWQ: Aktivasyona Duyarlı Ağırlık Quantization’ı
AWQ (Activation-aware Weight Quantization), Lin ve ark. tarafından 2023’te yayımlanan bir yöntemden geliyor. Çıkış noktası da oldukça somut: bir modelin tüm ağırlıkları çıkarım kalitesi açısından eşit öneme sahip değil.
Araştırmacılar, yalnızca ağırlıkların küçük bir kısmının (yaklaşık %1) çıkarım kalitesini büyük ölçüde etkilediğini gözlemledi. Bu “salience” (kritiklik) değeri aktivasyon istatistiklerinden türetiliyor; bir ağırlık ne kadar büyük aktivasyonlara yol açıyorsa o kadar önemli sayılıyor.
AWQ bu bilgiyi kullanarak kritik ağırlıkları korurken daha az önemli ağırlıkları agresif biçimde sıkıştırıyor. Aynı bit derinliğinde GPTQ’dan genellikle daha iyi perplexity elde ediliyor.
AWQ’nun pratik avantajı vLLM ve HuggingFace TGI gibi yüksek verimli çıkarım kütüphaneleriyle tam uyumlu olması. Birden fazla kullanıcıya aynı anda yanıt vermesi gereken API servisleri için AWQ tercih edilen format haline geldi. Ayrıca AWQ’nun calibration adımı, dataset gerektirse de GPTQ’ya kıyasla daha hızlı tamamlanıyor.
GPTQ: Post-Training Quantization
GPTQ (Generalized Post-Training Quantization), Frantar ve ark. tarafından 2022’de geliştirilen Hessian tabanlı bir yöntemdir. Katman katman ilerleyerek, her katmandaki quantization hatasını minimize eden optimal ağırlık temsilini buluyor.
Süreç şöyle işliyor:
- Küçük bir calibration dataset (genellikle birkaç yüz örnek) modelden geçiriliyor.
- Her katman için Hessian matrisi hesaplanıyor; bu matris hangi ağırlık değişikliklerinin çıktıyı en çok etkilediğini gösteriyor.
- Ağırlıklar 4-bit’e indirgeniyor ve quantization hatası sonraki ağırlıklara dağıtılıyor (OBS yöntemi).
AutoGPTQ ile pratik kullanım örneği:
from transformers import AutoTokenizer
from auto_gptq import AutoGPTQForCausalLM
model_name = "TheBloke/Llama-2-7B-GPTQ"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoGPTQForCausalLM.from_quantized(
model_name,
use_safetensors=True,
device="cuda:0"
)
GPTQ’nun önemli bir kısıtı var: yöntem CUDA’ya bağımlı. CPU’da GPTQ modeli çalıştırmak ya mümkün değil ya da aşırı yavaş. GPU’nuz yoksa GGUF çok daha pratik bir tercih.
bitsandbytes ve QLoRA Bağlantısı
Tim Dettmers tarafından geliştirilen bitsandbytes kütüphanesi, farklı bir quantization yaklaşımı sunuyor: NF4 (Normal Float 4).
Normal Float 4’ün ayırt edici özelliği ağırlık değerlerinin istatistiksel dağılımını hesaba katması. Normal dağılıma sahip ağırlıklar için NF4, standart int4’e kıyasla daha az bilgi kaybıyla çalışıyor. Üstüne bir de double quantization eklenince (ölçekleme katsayılarının da quantize edilmesi) bellek tasarrufu daha da artıyor.
Bu temel, QLoRA tekniğinin omurgasını oluşturuyor. QLoRA’da:
- Taban model, 4-bit NF4 ile quantize edilmiş halde yükleniyor (bellek küçük kalıyor).
- Fine-tuning sırasında yalnızca LoRA adaptörleri float16’da eğitiliyor.
- Çıkarım aşamasında taban model 4-bit’te kalıyor, LoRA ağırlıkları üstüne uygulanıyor.
Bu yaklaşım, 7B parametreli bir modeli 24 GB VRAM’de fine-tune etmeyi gerçekçi hale getiriyor. LoRA ve fine-tuning konularını daha ayrıntılı görmek isteyenler için LoRA fine-tuning rehberimize bakabilirsiniz.
Hangi Format Ne Zaman?
| Özellik | GGUF | AWQ | GPTQ | bitsandbytes |
|---|---|---|---|---|
| CPU desteği | Tam | Hayır | Hayır | Kısmi |
| GPU desteği | Evet | CUDA | CUDA | CUDA |
| Ollama entegrasyonu | Yerel | Hayır | Hayır | Hayır |
| vLLM / TGI | Hayır | Evet | Evet | Hayır |
| Fine-tuning (QLoRA) | Hayır | Hayır | Hayır | Evet |
| Calibration gerekir | Hayır | Evet | Evet | Hayır |
| Önerilen senaryo | Lokal çalıştırma | API servisi | API servisi | Fine-tuning |
Kararı basitleştirmek için birkaç pratik kural:
- GPU’nuz yoksa ya da Ollama kullanıyorsanız: GGUF tek pratik seçenek.
- GPU’nuz var, model API olarak sunacaksanız: AWQ genellikle GPTQ’dan daha iyi verim veriyor.
- Fine-tuning yapacaksanız: bitsandbytes + QLoRA.
- Birden fazla format mevcutsa kalite sıralaması: AWQ > GPTQ > GGUF, ancak fark çoğu senaryoda küçük.
Ollama ile Quantized Model Çalıştırmak
Ollama, GGUF’u otomatik olarak hallediyor. Ama hangi varyantı indireceğinizi bilmek önemli. Model adını belirli bir tag ile çalıştırabilirsiniz:
# Varsayılan (Ollama en uygun quantization'ı seçer)
ollama run llama3.2:8b
# Belirli quantization varyantı
ollama run llama3.2:8b-instruct-q4_K_M
# Daha yüksek kalite, daha büyük boyut
ollama run llama3.2:8b-instruct-q8_0
VRAM tüketimini önceden tahmin etmek için basit bir formül:
Tahmini VRAM (GB) = (N_params × bit_derinliği / 8) × 1.2
Örnek: llama3.2:8b-instruct-q4_K_M için hesaplarsak → (8 × 10⁹ × 4 / 8) × 1.2 = 4,8 GB VRAM.
Formüldeki 1,2 katsayısı, KV cache ve aktivasyon belleği için eklenen bir tampon. Gerçek tüketim donanıma ve girdi uzunluğuna göre hafifçe değişebilir.
Bir modeli indirmeden önce boyutunu kontrol etmek için:
ollama show llama3.2:8b-instruct-q4_K_M --verbose
Kurulum adımlarının tamamına Ollama kurulum rehberimizden ulaşabilirsiniz.
HuggingFace’te Model Seçerken Etiket Okuma
HuggingFace’te quantized modeller için en bilinen iki kaynak TheBloke ve bartowski kullanıcı hesapları. Her ikisi de aynı orijinal modeli farklı quantization varyantlarıyla paylaşıyor.
Repo ismine bakarak formatı anlayabilirsiniz:
TheBloke/Llama-2-13B-GPTQ→ GPTQTheBloke/Llama-2-13B-GGUF→ GGUF (içinde birden fazla.ggufdosyası)bartowski/Llama-3.2-8B-Instruct-GGUF→ GGUF
GGUF reposunun içindeki dosyalar arasından hangisini indireceğinize karar verirken şu kıstasları kullanabilirsiniz:
- Yeterli VRAM varsa:
Q5_K_MveyaQ6_K. İyi kalite, orta boyut. - VRAM sınırlıysa:
Q4_K_M. Çoğu kullanım durumu için dengeli seçim. - Minimum ayak izi:
Q3_K_SveyaQ2_K. Kalite düşer, ama kısıtlı donanımlarda çalışır. - Yalnızca CPU kullanıyorsanız:
Q4_K_Mya daQ5_K_M. CPU çıkarımında K-quant varyantları daha kararlı çalışıyor.
Model card’da perplexity değerlerine de göz atabilirsiniz. Float16 referans modeline göre perplexity artışı %2’nin altındaysa, pratik kullanım açısından yeterli sayılır.
Formatlar arasındaki seçim ilk bakışta karmaşık görünüyor, ama kullanım senaryonuz netleştikçe tablo kendiliğinden basitleşiyor. GPU yoksa GGUF, API servisi kuruyorsanız AWQ, fine-tuning yapıyorsanız bitsandbytes. Hangi boyuttaki modeli hangi VRAM’de çalıştırabileceğinizi formülle önceden hesaplarsanız, indirmeden önce hayal kırıklığı yaşamazsınız. Ve genel kural şu: elinizin altındaki VRAM’e göre en büyük modeli seçin, mükemmel quantization’ı değil.