Llama 3.1 70B’nin ağırlıkları 140 GB; elinizdeki en iyi oyun kartında 24 GB var. Buna rağmen insanlar bu modeli evde çalıştırıyor. Bu yazıda quantization’ın ne olduğunu dört sayıyı elle yuvarlayarak göreceğiz, “4-bit” kelimesinin arkasındaki üç ayrı kararı ayıracağız ve modeli küçültürken neyi kaybettiğimizi ölçümlerle konuşacağız.
ChatGPT’ye ya da Claude’a soru yazdığınızda cevap bir sohbet kutusundan geliyor; ama o kutunun arkasındaki model aslında sayı dolu devasa bir dosya. Bu sayılara parametre ya da ağırlık (weight) deniyor; eğitim sırasında milyarlarca kez ayarlanıyor, eğitim bitince donuyor. Model çalışırken bu sayıların tamamının GPU belleğinde (VRAM) durması gerekiyor, çünkü üretilen her token için hepsi baştan sona bir kez okunuyor.
Quantization (nicemleme) tek cümle: aynı sayıları daha az byte ile saklamak. Geri kalan her şey bunu modeli bozmadan nasıl yapacağımızın mühendisliği.
1. Rakamlarla Başlayalım: 70 Milyar × 2 Byte
Açık ağırlıklı (open weights) dünyanın 2026’daki ağır topları Qwen3, DeepSeek-V3 ve Kimi K3. Hesabı yine de Meta’nın Llama 3.1 70B’si üzerinden yapacağım: dense (yoğun) bir model olduğu için çarpma dipnot istemiyor ve 6. bölümde alıntılayacağım kalite ölçümleri bu modelle yapılmış[7]. Model BF16 formatında yayımlandı, yani parametre başına 2 byte:
70 milyar × 2 byte = 140 GB. Sadece ağırlıklar; KV cache bunun üstüne geliyor.
Bir H100’de 80 GB var, RTX 4090’da 24 GB. Aynı modelleri farklı hassasiyetlerde (precision) yan yana koyunca quantization’ın neden bu kadar konuşulduğu görülüyor:
| Model | Parametre | BF16 (2 byte) | INT8 / FP8 (1 byte) | 4-bit (~0.5 byte) |
|---|---|---|---|---|
| Llama 3.1 8B | 8 Milyar | 16 GB — RTX 4090’a ancak | 8 GB | 4.6 GB — 8 GB’lık dizüstü kartına[11] |
| Llama 3.1 70B | 70 Milyar | 140 GB — 2× H100 | 70 GB — tek H100 | ~38 GB — 2× RTX 4090 |
| Qwen3-235B-A22B | 235 Milyar | 470 GB — 8× H100 node’unun neredeyse tamamı | 235 GB | ~120 GB — 2× H100 |
| DeepSeek-V3 / R1 | 671 Milyar | 1.34 TB | 671 GB — FP8’de yayımlandı | ~340 GB |
| Kimi K3 | 2.8 Trilyon | 5.6 TB — hiç yayımlanmadı | — | ~1.5 TB — doğrudan MXFP4’te çıktı[22] |
MoE modellerde token başına parametrelerin küçük bir kısmı çalışıyor ama hepsi bellekte durmak zorunda; bellek hesabı toplam parametre üzerinden. Son satıra dikkat: en büyük modeller artık BF16’da çıkıp sonra küçültülmüyor, sağlayıcı en baştan 4-bit veriyor.
Fikir 2022’de LLM’lere geldi: Tim Dettmers ve arkadaşlarının LLM.int8() çalışması 175 milyar parametrelik OPT’yi kalite kaybı olmadan 8-bit’e indirdi[1]; aynı yıl GPTQ 3–4 bit’e inip 175B’yi tek GPU’ya sığdırdı[3]. 2023’te Meta Llama’yı yayımladı, Georgi Gerganov’un llama.cpp’si bu modelleri MacBook’larda çalıştırdı[14]. O günden beri “lokal LLM” dediğimiz şeyin altyapısı quantization. GPTQ — GPT modelleri için post-training quantization; adı GPT + Quantization’dan geliyor (resmi bir açılımı yok, makale başlığı “Accurate Post-Training Quantization for Generative Pre-trained Transformers”)
2. Sayıları Nasıl Küçültüyoruz? Elle Yapalım
Quantization’ın özü yuvarlama, ama biraz akıllı bir yuvarlama. En basit haliyle absmax quantization[18][19]: bir grup ağırlığın mutlak değeri en büyük olanını bul; o değer hedef formatın en büyük tam sayısına (INT8 için 127, INT4 için 7) denk gelecek şekilde bir ölçek (scale) hesapla; her ağırlığı ölçeğe böl, en yakın tam sayıya yuvarla. Diske yazılan şey bu küçük tam sayılar + tek bir ölçek. Çalıştırırken tersini yaparsın: tam sayı × ölçek (dequantization).
Dört ağırlıkla deneyelim: [0.90, −1.20, 0.05, 2.40].
INT8 sütununda dört sayı da neredeyse kayıpsız geri okunuyor; hata binde 7. INT4’te ise elimizde −8 ile 7 arasında 16 kutu var ve 0.05 gibi küçük bir ağırlık sıfıra düşüyor: model o ağırlığı öğrenmek için emek harcamıştı, biz yuvarlayarak sildik. Yazının geri kalanının iskeleti bu iki gözlem: 8-bit neredeyse bedava; 4-bit ve altı akıl ister.
Alttaki kırmızı kutu ise quantization’ın gerçek düşmanını gösteriyor. Dettmers’in bulgusu şuydu: ~6.7 milyar parametreden itibaren Transformer’ların birkaç boyutunda diğerlerinden 20–60 kat büyük değerler (outlier) beliriyor[2]. Tek ölçekle quantize ettiğinizde bu birkaç sayı ölçeği öyle büyütüyor ki geri kalan on binlerce normal değer sıfıra yuvarlanıyor. Çözümü basit: ölçeği bütün matrise değil, her 32–128 ağırlıklık gruba ayrı ver (group quantization). Bir outlier artık sadece komşularını etkiliyor. Bedeli, grup başına fazladan bir ölçek saklamak; bu yüzden “4-bit” modeller aslında ağırlık başına 4.5–5 bit tutar[11].
3. “4-bit” Tek Bir Şey Değil: Üç Ayrı Karar
Hugging Face’te Llama-3.1-8B-AWQ-INT4 ile Llama-3.1-8B-Q4_K_M.gguf yan yana duruyor; ikisi de “4-bit” ama üç farklı kararın sonucu[20][21]. AWQ — Activation-aware Weight Quantization. GGML Universal File (GGML = Gerganov’un tensor kütüphanesi)
Karar 1 — Sayı formatı: kaç bit, nasıl temsil?
Bit sayısı aynı olsa da temsil farklı olabiliyor; INT8 ile FP8 aynı şey değil. Bilmeniz gerekenler:
| Format | Ne | Nerede |
|---|---|---|
| BF16 (bfloat16, “brain floating point”) | 16 bit; modellerin yayımlandığı hal | Referans |
| FP8 (8-bit floating point) | 8-bit float; H100 ve sonrası donanımda doğrudan çarpıyor | Prod serving’in 2026 standardı[7] |
| INT8 (8-bit integer) | −128…127 tam sayı + ölçek; A100’de de tensor core desteği var | FP8’siz kartlarda |
| INT4 (4-bit integer) / NF4 (NormalFloat4) | 16 seviye + grup ölçeği; GPTQ, AWQ ve QLoRA (Quantized Low-Rank Adaptation)’nın çıktısı | Bellek sığdırma, tek kullanıcılı hız |
| MXFP4 (Microscaling FP4) / NVFP4 (NVIDIA FP4) | 4-bit float + blok ölçeği; Blackwell doğrudan hesaplıyor | gpt-oss, Kimi K3, B200’de serving[15] |
| Q4_K_M, Q8_0, IQ2_XS… | llama.cpp’nin kendi blok formatları | GGUF dosyaları[11] |
Kritik nokta son sütun: bir format ancak donanım onu doğrudan çarpabiliyorsa hız kazandırıyor. H100 FP8’i tensor core’da çarpıyor, A100 çarpamıyor; Blackwell FP4’ü doğrudan hesaplıyor, H100 INT4’ü önce BF16’ya çevirip öyle çarpıyor. NVIDIA’nın ölçümünde NVFP4, FP8’e göre 1.8× az bellekle DeepSeek-R1’de %1’in altında kayıp veriyor[15]; ama o rakam Blackwell’de geçerli, A100’e aynı dosyayı atarsanız ne o hızı ne o kernel’i bulursunuz.
Karar 2 — Yöntem: bozmadan nasıl indiriyoruz?
Şekil 1’deki düz yuvarlama (RTN – round-to-nearest) 8-bit’te yeterli; 4-bit’te büyük modellerde idare ediyor, küçüklerde kaliteyi düşürüyor. Bunun için daha akıllı yöntemler var; çoğu birkaç yüz örnek metinle (kalibrasyon verisi) dakikalar içinde çalışıyor:
- GPTQ (2022): Ağırlıkları sütun sütun quantize et, her sütundaki yuvarlama hatasını henüz quantize edilmemiş sütunları güncelleyerek telafi et. 175B modeli 4 GPU saatinde 3–4 bit’e indiriyor[3]. vLLM’de gördüğünüz INT4 modellerin çoğu bu yöntemle üretilmiş.
- AWQ (2023): MIT’nin gözlemi: ağırlıkların sadece ~%1’i kritik ve bunlar büyük aktivasyonlarla çarpılanlar. AWQ o kanalları quantize etmeden önce bir katsayıyla büyütüyor (aktivasyonu aynı oranda küçültüyor, çarpım değişmiyor); büyütülen ağırlık yuvarlamada daha az hata alıyor[4].
- SmoothQuant (2022): Ağırlık değil, aktivasyon quantization’ı için. Outlier’lı aktivasyon sütunlarını bir katsayıya bölüp aynı katsayıyı ağırlıklara çarpıyor; zorluk “quantize edilmesi kolay” tarafa taşınıyor. Sonuç W8A8: ağırlık da aktivasyon da 8-bit[5].
- k-quants + imatrix (llama.cpp): İki seviyeli blok ölçekleri + bir kalibrasyon metni üzerinden hangi ağırlıkların önemli olduğunu ölçen importance matrix[11][13].
- QAT (quantization-aware training): Yukarıdakiler eğitimden sonra yapılıyor (PTQ – post-training quantization). QAT (quantization-aware training)’ta model eğitim sırasında 4-bit’e indirileceğini bilerek eğitiliyor. Google, Gemma 3’ü böyle çıkardı: 5.000 adımlık ek eğitimle 4-bit’teki kaybı yarıya indirdi, 27B’nin VRAM’i 54 GB’tan 14 GB’a düştü[16]. En iyi sonuç, ama eğitim gerektiriyor; sağlayıcının işi.
W4A16, W8A8 ne demek? W = ağırlık (weight) bit’i, A = aktivasyon bit’i. W4A16: ağırlık 4-bit saklanıyor, hesap 16-bit’te yapılıyor; çarpmadan önce dequantize ediliyor. W8A8: ikisi de 8-bit, çarpma doğrudan 8-bit tensor core’da. İlki yalnızca bellek, ikincisi bellek + hesap kazandırıyor. Bu fark 5. bölümde önemli olacak.
Karar 3 — Dosya formatı: diske nasıl yazıyoruz?
GPU serving dünyası (vLLM, transformers) modeli klasör olarak tutuyor: safetensors dosyaları + config’de yöntemin adı ve grup boyu. Lokal dünyanın formatı GGUF: llama.cpp’nin tek dosyalık formatı; ağırlıklar, tokenizer, chat template ve her tensörün hangi tipte olduğu hepsi içinde, dosya mmap ile doğrudan belleğe haritalanıyor[12][13]. İndirip Ollama’ya ya da LM Studio’ya vermeniz yeterli[25]. Video için MP4 neyse, lokal LLM için GGUF o.
Q4_K_M gibi isimleri okumak için: Q4 = ~4 bit; _K = k-quants blok yapısı; _M = medium karışım, yani hassas olduğu bilinen katmanlar (attention çıkışı, FFN down projeksiyonu) bir üst hassasiyette tutuluyor. Q4_K_M’in varsayılan tavsiye olmasının sebebi bu dengeyi iyi tutturması. llama.cpp’nin kendi tablosunda Llama 3.1 8B: F16 14.96 GiB / 29 token/s → Q8_0 7.95 GiB / 51 token/s → Q4_K_M 4.58 GiB / 72 token/s[11]. Q8_0’da kalite kaybı ölçülemeyecek kadar küçük; Q2_K’ya inince belirginleşiyor.
4. Modeli Kim Quantize Etmeli?
Modeli çalıştıracak olan. Çünkü bu iş “dosyayı küçült” değil, üç soruya cevap vermeyi gerektiriyor: Hangi donanımda koşacak? (H100’de FP8, A100’de INT8/INT4, Blackwell’de NVFP4, MacBook’ta GGUF.) Hangi runtime çalıştıracak? (vLLM, llama.cpp ve TensorRT-LLM’in her biri kendi formatını hızlı çalıştırıyor, diğerini ya açmıyor ya yavaş açıyor.) Sizin görevde kalite düşüyor mu? (Genel benchmark’lar iyimser; sizin RAG pipeline’ınızdaki Türkçe soru-cevapta ne olduğunu ancak siz ölçebilirsiniz.)
Pratikte üç oyuncu var. Model sağlayıcıları işi giderek üstleniyor: Gemma QAT ile, gpt-oss ve Kimi K3 doğrudan MXFP4 ile çıktı[16][22]. Inference ekipleri (Red Hat / Neural Magic, NVIDIA) kalibre edilmiş, ölçülmüş sürümleri Hugging Face’e koyuyor[7]. Topluluk her yeni modelin GGUF’larını saatler içinde çıkarıyor. Kendiniz quantize etmeniz gereken durum genelde kendi fine-tune ettiğiniz model.
5. “4-bit Daha Hızlı” Cümlesi Ne Zaman Doğru?
En çok yanlış anlaşılan şey bu: quantization belleği kesin küçültür; hızı bazen artırır. Tek kullanıcı için token üretirken GPU şunu yapıyor: 16 GB ağırlığı bellekten okuyor, her biriyle bir çarpma yapıyor, bir token üretiyor, başa dönüyor. Okuma devasa, hesap komik; H100’ün tensor core’ları tam verim için byte başına ~295 çarpma isterken tek kullanıcılı decode’da byte başına 1 çarpma düşüyor[17]. GPU zamanının neredeyse tamamında bellek okumasını bekliyor. Ağırlığı 4-bit’e indirince okunacak veri dörtte bire düşüyor ve decode neredeyse 4× hızlanıyor.
Sorun kullanıcı sayısı artınca başlıyor. vLLM 64 isteği batch’leyip her ağırlığı bir kez okuyup 64 token için kullanıyor; okuma maliyeti 64’e bölünüyor ve darboğaz bellekten hesaba geçiyor. H100’de INT4 için bu geçiş ~74 eşzamanlı istekte oluyor[17]. Ondan sonra 4-bit ağırlığın hız katkısı sıfır; üstüne her çarpmadan önce INT4→BF16 dönüşümü kritik yola giriyor. Prefill (prompt’un işlenmesi) zaten hep hesap darboğazında. Bu yüzden prod’da resim şu:
| Senaryo | Darboğaz | Doğru seçim |
|---|---|---|
| Tek kullanıcı, dizüstü / tek GPU | Bellek okuması | W4A16 — GGUF Q4_K_M, AWQ, GPTQ: okuma 4× azaldı, hız ~3× arttı |
| Prod serving, H100/H200, yüksek trafik | Hesap | W8A8-FP8 — tensor core doğrudan çarpıyor, dequantize yok, throughput ~2×[7] |
| Prod serving, Blackwell | Hesap | NVFP4 — 4-bit float doğrudan hesaplanıyor[15] |
| 405B gibi devler, gecikme öncelikli | Sığmıyor | W4A16 — yarı sayıda GPU, 5–7× maliyet düşüşü[7] |
6. Ne Kadar Kaybediyoruz?
Bu konuda en kapsamlı çalışma Red Hat / Neural Magic ekibinin ACL 2025’teki “Give Me BF16 or Give Me Death?” makalesi: Llama 3.1’in 8B, 70B ve 405B’sini üç formatta quantize edip 500.000’den fazla değerlendirme çalıştırdılar[7].
Özet: doğru yöntemle FP8 %99.75, INT4 %99.36, INT8 %99.31 geri kazanım; zor görevlerde (MMLU-Pro, GPQA, MATH) bile hiçbir görev %96’nın altına inmiyor. Daha önce raporlanan %10’luk INT8 kayıplarının sebebi format değil, kötü kalibrasyonmuş. Büyük modeller daha dayanıklı: 405B’de INT4 ile 5–7× maliyet düşüşü alırken kalite %99’da kalıyor[7][23].
Üç köşeye dikkat:
- Uzun context. 4K–64K arasında INT4 %99’un üstünde; 128K’da geri kazanım 8B’de %85’e, 70B’de %88’e düşüyor[8]. Uzun belge özetliyorsanız kendi ölçümünüzü yapın.
- Reasoning modelleri. DeepSeek-R1-Distill, QwQ ve Qwen3 üzerinde: W8A8 ve W4A16 kayıpsız; daha düşük bit’lerde kayıp ciddi, küçük modellerde ve zor görevlerde daha ciddi[9][10]. Uzun düşünce zinciri üreten modellerde Q6_K ya da Q8_0’a çıkın.
- 3-bit ve altı. Q2_K ve IQ2, 70B’yi 24 GB’a sığdırıyor ama kayıp artık yüzde birlerle değil on’larla ölçülüyor. 70B Q2 ile 8B Q8 arasında kalırsanız 8B’yi seçin.
Kapsam notu: bunların hepsi ağırlıkların quantization’ı. Uzun context’te VRAM’i asıl yiyen KV cache ayrı bir konu; o da FP8’e ya da INT4’e iniyor, vLLM ve llama.cpp destekliyor[24].
Karar Tablosu
| Durumunuz | Tavsiye |
|---|---|
| MacBook / tek tüketici GPU, sohbet ve kod | GGUF Q4_K_M; VRAM artıyorsa Q6_K |
| Reasoning modeli lokal | Q6_K veya Q8_0 |
| H100/H200’de vLLM, yüksek trafik | FP8 W8A8 — kalibrasyon yok, %99.75 kalite |
| Model sığmıyor, az kullanıcı, gecikme önemli | W4A16 (GPTQ / AWQ) |
| Tek GPU’da fine-tuning | QLoRA — model 4-bit NF4’te donuk, üstüne küçük adaptörler eğitiliyor; 65B’yi 48 GB’ta eğitmenin tarifi[6] |
| Sağlayıcı QAT / MXFP4 sürümü vermiş | Onu kullanın; eğitimle yapılmış quantization her PTQ’dan iyi |
| Kendi fine-tune ettiğiniz model | Önce FP8 ya da Q8_0; 4-bit’i kendi eval’ınızla deneyin |
Kapanış
Quantization’ı tek cümleye indirirsek: modelin sayılarını daha az bit ile saklamak; kazanç bellekte kesin, hızda şartlı, kalitede ölçülmesi gereken bir bedel var. 2022’de soru “175B’yi bozmadan 8-bit’e indirebilir miyiz”di[1]. 2026’da cevabını bildiğimiz sorular çoğaldı: 8-bit bedava, 4-bit doğru yöntemle %99, 3-bit ve altı pazarlık, reasoning ve uzun context hassas. Donanım da yetişti; sağlayıcılar modelleri en baştan 4-bit’te yayımlamaya başladı.
Ama asıl soru değişmedi. Soru “modeli küçültebilir miyiz” değil; onu zaten yapabiliyoruz. Soru, küçülttükten sonra hâlâ işe yarıyor mu. Ve o soruyu genel benchmark’lar değil, sizin verinizle yaptığınız ölçüm cevaplıyor. En öğretici deney şu: bir 8B modeli Q8_0, Q4_K_M ve Q2_K olarak indirip aynı 20 soruyu üçüne sorun, farkı kendi gözünüzle görün. Kolay gelsin!
Kaynaklar
- Dettmers et al. — LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale (arXiv:2208.07339)
- Tim Dettmers — LLM.int8() and Emergent Features
- Frantar et al. — GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers (arXiv:2210.17323)
- Lin et al. — AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration (arXiv:2306.00978)
- Xiao et al. — SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models (arXiv:2211.10438)
- Dettmers et al. — QLoRA: Efficient Finetuning of Quantized LLMs (arXiv:2305.14314)
- Kurtic et al. — “Give Me BF16 or Give Me Death”? Accuracy-Performance Trade-Offs in LLM Quantization (arXiv:2411.02355, ACL 2025)
- Red Hat Developer — How well do quantized models handle long-context tasks?
- Liu et al. — Quantization Hurts Reasoning? An Empirical Study on Quantized Reasoning Models (arXiv:2504.04823, COLM 2025)
- Quantization Meets Reasoning: Exploring LLM Low-Bit Quantization Degradation for Mathematical Reasoning (arXiv:2501.03035)
- llama.cpp — quantize tool README (quantization types, sizes, bits per weight, imatrix)
- ggml — GGUF file format specification
- ZeroEntropy — GGUF format and k-quants: local LLM inference, explained
- ggml-org/llama.cpp — LLM inference in C/C++
- NVIDIA Technical Blog — Introducing NVFP4 for Efficient and Accurate Low-Precision Inference
- Google Developers Blog — Gemma 3 QAT Models: Bringing state-of-the-art AI to consumer GPUs
- Why INT4 Weight-Only Quantization Doesn’t Speed Up Prefill
- DeepInfra — From Precision to Quantization: A Practical Guide to Faster, Cheaper LLMs
- BentoML — LLM Inference Handbook: LLM quantization
- The AI Engineer — GPTQ vs AWQ vs GGUF: Which 4-Bit to Pick in 2026
- Prem AI — LLM Quantization Guide: GGUF vs AWQ vs GPTQ vs bitsandbytes Compared (2026)
- Kimi K3 Model Overview: 2.8T Parameters, MXFP4 Quantization, and What the Open Weights Mean
- A Comprehensive Evaluation of Quantized Instruction-Tuned Large Language Models: An Experimental Analysis up to 405B (arXiv:2409.11055)
- vLLM Documentation — Quantization (supported methods, FP8, INT4, KV cache)
- Ollama — run LLMs locally (GGUF-based)
- Kapak Görseli: Photo by Ricardo Gomez Angel on Unsplash