GGUF kuantizasyonu: hangi seviyeyi kullanmalısınız?

Varsayılan olarak Q4_K_M seçin; VRAM’iniz boşta duruyorsa ve kalitenin son birkaç puanını istiyorsanız Q6_K ya da Q8_0’a geçin. GGUF kuantizasyonu, bir modelin ağırlıklarını 16 bitten aşağı sıkıştırır — Q4_K_M ağırlık başına kabaca 4.85 bit tutar; 7B bir model ~14 GB’den ~4.1 GB’a düşer ve perplexity tipik olarak orijinalin %1’inden az bozulur. “Hangi gguf quant’ını kullanmalıyım” sorusunun, internetteki dramatürlerin gizlediği sıkıcı derecede istikrarlı bir cevabı vardır. Aşağıda: kuantizasyonun ağırlıklara aslında ne yaptığı, her seviyenin kaç puan kaliteye mal olduğu, boyut matematiğini kendinizin nasıl yapacağı ve bir yabancının benchmark’ına güvenmek yerine kendi donanımınızda hasarı ölçecek tek komut.

GGUF kuantizasyonu aslında ne yapar?

Bir model 16 bit kayan noktada (FP16 ya da BF16) eğitilir: milyarlarca ağırlığın her biri 2 baytlık bir sayıdır. Kuantizasyon, her ağırlığı daha az bite sıkıştırır. Naif yol — her ağırlığı 4 bitlik tamsayıya yuvarlamak — küçük ama önemli değerleri yok eder; bu yüzden GGUF iki hile kullanır:

1. Blok ölçekleme. Ağırlıklar bloklara (genelde 32’şer) gruplanır ve her blok kendi ölçek çarpanını alır. 4 bitlik değerler, o blok içindeki ofsetlerdir; böylece geniş bir büyüklük aralığı hayatta kalır.
2. Önem duyarlı k-quant’lar. Q4_K_M’deki “K”, ölçeklerin süper-blok anlamına gelir; ayrıca attention ve feed-forward katmanlarına farklı davranır, çünkü sıkıştırmaya eşit tahammül etmezler.

“I” ailesi (IQ4_XS ve arkadaşları), görüntü sıkıştırmadan ödünç alınan bilgi-teorik codebook’larla daha da ileri gider. Aynı fikir, daha süslü kodlama: benzer kalitede ağırlık başına daha az bit; bedeli, bazı arka uçlarda biraz daha yavaş çıkarımdır.

Çoğu karışıklığı önleyen bir açıklama: kuantizasyon yalnızca saklanan ağırlıkları değiştirir. Mimariye, tokenizer’a ve context yönetimine dokunulmaz. Aynı modelin Q4 dosyası ile Q8 dosyası aynı modeldir — farklı palto giymiş halleri.

Q4 vs Q8: daha yüksek kuantizasyon daha mı iyi?

Teknik olarak evet; algıda hayır. Referans olarak llama.cpp’nin Llama modelleri üzerindeki kendi perplexity ölçümlerini baz alırsak: Q8_0, FP16’nın ~%0.02’si içinde kalır — pratik her amaç için kayıpsız. Q6_K neredeyse ayırt edilemez. Q4_K_M kabaca %1–2 perplexity kaybettirir, Q4_0 biraz daha; Q2_K ise küçük modellerde tutarlı cevapların çözülmeye başladığı yerdir.

Sayıların ima ettiği iki kural:

• Model büyüklüğü, kuantizasyon payı alır. 70B’lik bir model, Q2/Q3’e 7B’den çok daha iyi dayanır; çünkü büyük modeller daha fazla fazlalık (redundancy) taşır. 7B’yi Q2’ye indirmek uzuv kesmektir; 70B’yi Q3’e indirmek terziliktir.
• Kalite tabanı, göreve göre kayar. Sohbet Q4’ü affeder. Hassas kod üretimi, matematik ve kesin dokümanlar üzerinde RAG, kuantizasyon gürültüsünü daha çabuk ele verir. Q4 bir model sürekli ince yanlış kod yazıyorsa, modeli suçlamadan önce aynı modeli Q6_K’ta deneyin.

Seviye	Bit/ağırlık	FP16’ya göre boyut	Kalite kaybı	Ne zaman kullanın
Q2_K	~3.4	~%21	13B altında ciddi	Başka hiçbir şey sığmıyorsa, yalnızca büyük modeller
Q3_K_M	~3.9	~%25	Belirgin	Dar VRAM, ≥14B modeller
Q4_K_S	~4.6	~%29	Küçük	Q4_K_M sığmıyorsa ve fark azsa
Q4_K_M	~4.85	~%30	~%1 perplexity	Varsayılan. En iyi kalite/boyut dengesi
Q5_K_M	~5.7	~%35	~%0.5	VRAM var, kaliteye duyarlı işler
Q6_K	~6.6	~%41	Neredeyse sıfır	Kod/matematik, hâlâ rahat sığıyorsa
Q8_0	~8.5	~%53	Fiilen hiç	Referans çalıştırmalar, fine-tune tabanları
IQ4_XS	~4.3	~%27	≈Q4_K_M	Q4_K_M hafif büyükse ve arka uç i-quant destekliyorsa

Her seviye ne kadar VRAM ister?

Tabloları ezberlemek yerine boyut matematiğini kendiniz yapın — tek satır:

size_GB ≈ (bits_per_weight × params) / 8
# 8B model @ Q4_K_M: 4.85 × 8 / 8 ≈ 4.9 GB
# 8B model @ Q8_0:   8.50 × 8 / 8 ≈ 8.5 GB

Sonra formülün dışında bıraktıklarını ekleyin: KV cache (context uzunluğuyla büyür — birkaç yüz MB’den birkaç GB’ye), aktivasyonlar ve hesap tamponları. Pratik marj: “4.9 GB”lık bir model, 4k context’te 6 GB’lık bir kart ister; 16k’ta ise aynı yerde kalabilmek için flash-attention ve KV-cache kuantizasyonu gerekir. Ağırlıklar manşettir, faturanın tamamı değil.

Hangi GGUF kuantizasyonunu kullanmalısınız?

Karar sırası — ezberlenecek istisnası yok:

1. Önce context + KV bütçenizi hesaplayın, sonra ağırlıkları. Sığmayan context, ölçemediğiniz kaliteden daha kötüdür.
2. Varsayılanınız Q4_K_M olsun. Topluluğun varsayılanı bir sebeptendir — boyutun %70’i karşılığında kabaca %1 perplexity. Ollama’nınki dâhil her kayıt defteri onu taban olarak dağıtıyor.
3. Görev gürültüyü cezalandırıyorsa Q6_K’a çıkın: kod, matematik, veri ayıklama; pipeline’a denetimsizce verdiğiniz her şey.
4. Q8_0’ı yalnızca referans için kullanın — A/B testleri, kuantizasyon hasarı ölçümü ya da fine-tune tabanı. Günlük sürücü olarak çoğunlukla yalnızca VRAM sensörlerinizi ısıtır.
5. Q4’ün altına ancak zorunlu kalın, ve yalnızca büyük modellerde. Güvenmeden önce bilinen zor bir promptla test edin.

Hugging Face’te hangi dosyayı indireceğinizi seçiyorsanız, yükleyici yalnızca parçalı gönderiyorsa başka, sharded split’ler yerine tek bir Q4_K_M.gguf tercih edin — hareketli parça sayısı azdır. Ve nerede çalıştıracağınıza karar veriyorsanız, motor seçimi ayrı bir eksendir: o taraf için llama.cpp vs Ollama yazısına bakın.

Kuantizasyon hasarını kendiniz nasıl ölçersiniz?

Benchmark’lar birbirinden farklıdır; sizin prompt’ınız sabittir. llama.cpp’yi bir kez derleyin, aynı modelin iki seviyesini indirin ve hem perplexity’yi (düşük daha iyi) hem token/saniye’yi ölçün:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf 
  --local-dir models

# bir wiki-text parçasında perplexity (düşük = orijinal modele daha yakın)
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99

# ve aynı donanımda hız
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

Q4_K_M’in sayısı, Q8_0’ınkiyle arasında yalnızca virgülden sonraki birkaç basamak fark olacak ve dosya ~%40 daha küçük olacak. Aşağı akış göreviniz farkı söyleyemiyorsa — çoğu için söyleyemez — kimsenin liderlik tablosunu okumadan cevabınız hazırdır.

Kuantizasyon gizliliğe ya da “tamamen lokal” iddiasına zarar verir mi?

Hayır — ağırlıklar üzerinde aritmetiktir, tamamen çevrimdışıdır ve kuantize dosya, aynı parametrelerin daha küçük bir kapsayıcısından ibarettir. Q4_K_M’i lokalde çalıştırmak, tam hassasiyetli modeli lokalde çalıştırmak kadar (az) şey sızdırır: makineden hiçbir şey çıkmaz. Gizlilikle ilgili değişken, çıkarımın nerede çalıştığıdır; bit genişliği değil. Model menşeine dair olağan uyarılar, her quant seviyesi için eşit geçerlidir: çalınmış tabanlı Q8 bir “uncensored” fine-tune, aynı ağırlıkların Q4’ünden daha güvenli değildir. Dosya biçimi tarafı için bkz. GGUF modelleri lokalde nasıl çalıştırılır.

Hangi seviyeyi seçmelisiniz?

Q4_K_M; ve bununla ilgili forumları okumayı bırakın. VRAM izin veriyorsa hassasiyet işleri için Q6_K’a geçin, A/B karşılaştırmaları için bir tane Q8_0 elde bulundurun ve Q4 altını yalnızca büyük modeller için bir acil durum tayını olarak görün. Kaçınılması gereken tek hata simetriktir: Q4-mü-Q5-mi diye kaygılanırken context uzunluğunu görmezden gelmek — yerel kurulumları bugüne dek hiçbir quant’ın yapmadığı kadar bozan odur.