Quantization Nedir? GGUF, AWQ ve GPTQ ile LLM Modellerini Küçültme

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

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 varyant
• Q5_K_S → 5-bit, K-quant, Small varyant
• Q8_0 → 8-bit, group-wise quantization, varyant 0
• Q2_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:

1. Küçük bir calibration dataset (genellikle birkaç yüz örnek) modelden geçiriliyor.
2. 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.
3. 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:

1. Taban model, 4-bit NF4 ile quantize edilmiş halde yükleniyor (bellek küçük kalıyor).
2. Fine-tuning sırasında yalnızca LoRA adaptörleri float16’da eğitiliyor.
3. Çı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?

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 → GPTQ
• TheBloke/Llama-2-13B-GGUF → GGUF (içinde birden fazla .gguf dosyası)
• bartowski/Llama-3.2-8B-Instruct-GGUF → GGUF

GGUF reposunun içindeki dosyalar arasından hangisini indireceğinize karar verirken şu kıstasları kullanabilirsiniz:

1. Yeterli VRAM varsa: Q5_K_M veya Q6_K. İyi kalite, orta boyut.
2. VRAM sınırlıysa: Q4_K_M. Çoğu kullanım durumu için dengeli seçim.
3. Minimum ayak izi: Q3_K_S veya Q2_K. Kalite düşer, ama kısıtlı donanımlarda çalışır.
4. Yalnızca CPU kullanıyorsanız: Q4_K_M ya da Q5_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.

llama.cpp ile GGUF Model Çalıştırmak: Adım Adım

Ollama’nın arkasındaki motoru doğrudan kullanmak istiyorsanız — daha fazla kontrol, özel parametreler veya Ollama’nın desteklemediği modeller için — llama.cpp’yi doğrudan çalıştırmak mantıklı.

Derleme

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build --config Release

Apple Silicon için Metal GPU hızlandırması otomatik aktif olur. NVIDIA kullanıcıları -DGGML_CUDA=ON ekleyin:

cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release

Model İndirme ve Çalıştırma

HuggingFace’ten istediğiniz .gguf dosyasını indirin:

wget https://huggingface.co/bartowski/Meta-Llama-3.1-8B-Instruct-GGUF/resolve/main/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf

Çalıştırın:

./build/bin/llama-cli \
  -m Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  --n-ctx 4096 \
  --threads 8 \
  --n-gpu-layers 33 \
  -p "Model kuantizasyonu nedir, kısaca açıkla:"

• --n-ctx: Bağlam penceresi token sayısı. 2048 güvenli, 4096 standart.
• --threads: Mantıksal çekirdek sayınızın yarısından başlayın.
• --n-gpu-layers: 7B model için ~32-33 katman. 99 yazarsanız tamamını GPU’ya almaya çalışır; VRAM yetmezse otomatik geri düşer.

Sıkça Sorulan Sorular

GGUF ve GGML arasındaki fark nedir?

GGML, llama.cpp’nin 2023 başında kullandığı eski formattır. GGUF, Ağustos 2023’te onu tamamen değiştirdi: daha iyi metadata desteği, genişletilebilirlik ve geriye dönük uyumluluk garantisi sunuyor. Bugün yeni model indiriyorsanız GGUF kullanın — GGML artık aktif desteklenmiyor.

4-bit kuantizasyon ne kadar kalite kaybına yol açar?

Q4_K_M gibi kaliteli bir 4-bit format için pratik kalite kaybı çoğu görevde fark edilemeyecek kadar düşüktür. Perplexity ölçütüyle float16 bazına kıyasla yaklaşık %2-3 sapma var. Kod üretimi veya hassas matematiksel akıl yürütme gerektiren görevlerde Q6_K veya Q8_0’a geçmek mantıklı.

GPTQ’yu CPU üzerinde çalıştırabilir miyim?

Teorik olarak evet, pratikte hayır. GPTQ’nun optimize çalışma zamanı CUDA (NVIDIA GPU) üzerine kurulu. CPU’da çalıştırmak mümkün ama GPU versiyonuna kıyasla 20-50 kat yavaş olabilir. CPU çıkarımı için GGUF her zaman doğru tercih.

Ollama hangi kuantizasyon formatını kullanıyor?

Ollama, arka planda GGUF formatını kullanır. ollama pull ile model indirdiğinizde diskinize .gguf dosyası yazılır. Belirli bir kuantizasyon seviyesi istiyorsanız ollama run llama3.1:8b-instruct-q8_0 gibi açıkça belirtin.

7B model için en iyi GGUF kuantizasyon seviyesi hangisi?

Çoğu kullanım için Q4_K_M ideal başlangıç: 4-5 GB disk alanı, 8 GB RAM ile çalışır, kalite kaybı minimal. 16 GB+ RAM varsa Q6_K veya Q8_0 daha iyi sonuç verir. 8 GB veya altı RAM’de Q3_K_M kabul edilebilir bir uzlaşı; Q2_K’dan kaçının — kalite düşüşü belirgindir.

• vLLM nedir? Açık kaynak LLM çıkarım motoru rehberi
• Ollama ile yerel LLM kurulumu
• LoRA fine-tuning rehberi — Unsloth ile Türkçe LLM