Kıyaslama

LLM Kuantizasyonu: BF16 vs FP8 vs INT4

Ekrem Sarı

ile

Sıla Ermut

Güncellenme tarihi: 17 Mar 2026

Bakınız etik normlar

Bu Araştırmayı Kaynak Göster

Qwen3-32B'yi tek bir NVIDIA H100 80GB GPU üzerinde 4 hassasiyet seviyesinde (BF16, FP8, GPTQ-Int8, GPTQ-Int4) benchmark'ladık. Her yapılandırma, bilgi ve kod üretimi kapsayan 2 benchmark'ta (~12.2K soru) ve verimliliği ölçmek için 2.000'den fazla inference çalıştırmasında değerlendirildi. Int4, MMLU-Pro'da 2 puandan daha az kayıp yaşarken BF16'dan 2.7 kat daha hızlıdır, ancak kod üretimi (HumanEval) 8 puan düşer.

Kuantizasyon benchmark sonuçları

Loading Chart

MMLU-Pro, 14 alanda (~12K soru, 5-shot) geniş akıl yürütmeyi test eder. Bu, 4 yerine 10 seçenekli sorular içeren MMLU'nun daha zor versiyonudur.

HumanEval, kod üretimini test eder (164 problem, pass@1). Model, birim testlere karşı çalışan Python fonksiyonları yazar. Bu, çıktının sadece puanlanmadığı, çalıştırıldığı tek benchmark'tır.

Verimlilik (Throughput), batch boyutu 1'deki saniyedeki çıktı token sayısıdır.

Model boyutu, yüklenmeden sonra ölçülen, sadece ağırlıklar tarafından tüketilen GPU belleğidir.

Kategoriye göre MMLU-Pro dökümü

Kategori	BF16	FP8	GPTQ-Int8	GPTQ-Int4
Biyoloji	86.19%	86.47%	86.61%	86.05%
İşletme	75.67%	76.43%	77.44%	77.19%
Kimya	74.12%	73.41%	73.94%	72.08%
Bilgisayar Bilimi	74.15%	75.37%	74.39%	73.90%
Ekonomi	81.75%	81.75%	81.40%	80.69%
Mühendislik	49.64%	45.41%	47.06%	43.45%
Sağlık	73.59%	72.49%	73.72%	71.52%
Tarih	62.20%	61.15%	60.63%	62.47%
Hukuk	43.05%	41.69%	43.78%	40.60%
Matematik	81.87%	81.87%	81.87%	80.24%

Mühendislik ve hukuk, Int4'te en büyük düşüşleri gösterir. Matematik tüm hassasiyetlerde stabil kalır.

Bellek kapasitesi ve eşzamanlılık

nvidia-smi gibi GPU izleme araçları, model boyutundan bağımsız olarak neredeyse tam kullanım bildirir çünkü vLLM mevcut belleğin tamamını önceden tahsis eder. Asıl soru, bu belleğin model ağırlıkları ve KV önbelleği arasında nasıl bölündüğüdür, çünkü KV önbelleği aynı anda kaç kullanıcıya hizmet edebileceğinizi belirler.

Maksimum kullanıcı, OOM'dan önce bellek kısıtlı tavanıdır: toplam token kapasitesi bölü kullanıcı başına bağlam uzunluğu. Bu teorik maksimumdur. Pratikte, planlama maliyetleri bunu biraz azaltır.

Bunun akıl yürütme modelleri için doğrudan sonuçları vardır. DeepSeek-R1 ve Qwen-QwQ, nihai bir yanıt üretmeden önce binlerce dahili "düşünce" token'ı (genellikle 2K-5K) üretir. BF16'da, tek bir akıl yürütme isteği tüm 17K token kapasitesini tüketerek ikinci bir kullanıcıyı engelleyebilir. Int4'te, 193K kapasitesi birden fazla eşzamanlı akıl yürütme oturumuna sığar.

Temel bulgular

FP8 ölçülebilir doğruluk kaybetmez

FP8, 12.000 soruda 0.6 puanlık bir farkla MMLU-Pro'da 69.64% puan alırken BF16 için bu 70.24%'tür. HumanEval'da hem FP8 hem de BF16 39.02'de aynı puanı alır. FP8, 0.6 puanlık bir maliyet karşılığında size 1.5x verimlilik sağlar ve model boyutunuzu yarıya indirir.

GPTQ-Int8, MMLU-Pro'da 70.32% puan alır ancak HumanEval'da 1.8 puan düşer (37.20%). Kod üretimi önemliyse, FP8 daha güvenli bir seçimdir.

Int4, bilgi üretiminden daha fazla kod üretimini bozar

MMLU-Pro, Int4'te 1.6 puan düşer (70.24%'ten 68.66%'ya). HumanEval 8 puan düşer (39.02%'den 31.10%'a). Kod üretimi, küçük ağırlık hatalarının fonksiyon gövdeleri boyunca biriktiği hassas token tahminleri gerektirir.

Gerçek kazanç hız değil, eşzamanlılıktır

Int4, BF16'dan 2.7 kat daha hızlıdır. Ancak daha büyük etki bellektedir. BF16, KV önbellek için sadece 4.4 GB bırakır, bu da 4K bağlamda yaklaşık 4 eşzamanlı kullanıcı için yeterlidir. Int4, 47.3 GB serbest bırakır, bu da 47 kullanıcı için yeterlidir ve aynı GPU'dan 12 kat daha fazla hizmet kapasitesi sağlar.

Matematik puanları tüm hassasiyetlerde sabit kalır

Matematik puanları neredeyse değişmez: BF16'da 81.87%, FP8'de 81.87%, Int8'de 81.87%, Int4'te 80.24%. Mühendislik (49.64%'ten 43.45%'e) ve hukuk (43.05%'ten 40.60%'a) daha duyarlıdır.

Get our team to automate one of your business processes with AI agents, free of charge.

Automate a process

Token başına maliyet

RunPod'da ($2.69/saat) batch boyutu 1'de H100 SXM fiyatlandırması kullanılarak:

Bu sayılar tek kullanıcılı, gerçek zamanlı üretimi yansıtır. Toplu işleme maliyeti daha da düşürür.

LLM kuantizasyon benchmark metodolojisi

Ortam

GPU: Tek NVIDIA H100 80GB HBM3 (SXM) via RunPod ($2.69/saat)
Yazılım: vLLM 0.17.0, lm-evaluation-harness 0.4.11, PyTorch 2.8.0, CUDA 12.8, Python 3.11
Model: HuggingFace'den Qwen3-32B (sonradan eğitilmiş/instrüksiyonla ayarlanmış). Hiçbir fine-tuning uygulanmadı.

Doğruluk değerlendirmesi

Benchmark	Sorular	Tür	Few-shot	Metrik
MMLU-Pro (tam, 14 kategori)	~12K	generate_until	5-shot	exact_match
HumanEval	164	generate_until	0-shot	pass@1

Tüm değerlendirmeler lm-evaluation-harness ile ve batch_size="auto" aracılığıyla çalıştırılır.
Her görev ayrı bir alt işlemede çalışır. Model her seferinde taze yüklenir, görevler arasında GPU tamamen temizlenir. Bu, bellek parçalanmasından kaynaklanan OOM'u önler.
HumanEval, HF_ALLOW_CODE_EVAL=1 ile çalıştırılır (kod yürütme etkinleştirilmiş).
MMLU-Pro sonuçları kategori bazlı dökümü içerir (biyoloji, matematik, fizik, hukuk vb.).
Qwen3'ün düşünme modu değerlendirmeler sırasında aktif değildi. lm-evaluation-harness, modelin sohbet şablonunu uygulamadan ham biçimlendirilmiş prompt'lar gönderir (varsayılan olarak apply_chat_template=False), bu nedenle <think> token'ı asla enjekte edilmez.

Performans değerlendirmesi

Alanlar arasında (bilim, kodlama, genel bilgi) 5 dönen prompt
10 ısınma yinelemesi (ölçülmedi), ardından 500 ölçülen yineleme
Sabit çıktı: max_tokens=256, temperature=0.7, top_p=0.9, batch_size=1
Metrikler: verimlilik (token/saniye), GPU bellek kullanımı (GB)

Hassasiyet başına vLLM yapılandırması

Hassasiyet	HuggingFace ID	vLLM yapılandırması
BF16	`Qwen/Qwen3-32B`	`dtype="bfloat16"`
FP8	`Qwen/Qwen3-32B-FP8`	`dtype="bfloat16"`
GPTQ-Int8	`JunHowie/Qwen3-32B-GPTQ-Int8`	`dtype="float16", quantization="gptq_marlin"`
GPTQ-Int4	`JunHowie/Qwen3-32B-GPTQ-Int4`	`dtype="float16", quantization="gptq_marlin"`

Tüm hassasiyetler gpu_memory_utilization=0.90, max_model_len=4096 kullanır.

Bölünmüş işlem mimarisi

Her benchmark, OOM'u önlemek için iki ayrı işlem olarak çalışır:

Adım 1: Modeli yükle, ısın, verimliliği benchmark'la, geçici dosyaya kaydet, çık.
Temizlik: vLLM ve Ray işlemlerini zorla sonlandır, 10 saniye bekle.
Adım 2: Modeli taze yükle, her değerlendirme görevini ayrı bir alt işlemede çalıştır, adım 1 metrikleriyle birleştir, nihai JSON'u kaydet.

Kontrollü değişkenler

Dış faktörleri ortadan kaldırmak için aşağıdaki parametreler tüm çalıştırmalarda sabitlendi:

Parametre	Değer	Gerekçe
Batch boyutu	1	Tek kullanıcılı gecikmeyi simüle eder. Daha yüksek batch boyutları kuantize modellerin bant genişliği avantajını büyütür, ancak batch boyutu 1, hesaplama kullanımı için en kötü durumdur.
Çıktı uzunluğu	256 token	Verimliliğin tutarlı bir iş yükü üzerinde ölçülmesini sağlamak için sabit üretim sınırı.
Temperature	0.7	Standart örnekleme parametresi.
Top-p	0.9	Standart nükleus örnekleme eşiği.
GPU bellek kullanımı	0.90	Ampirik olarak ayarlandı. Daha yüksek değerler (0.95, 0.98), CUDA grafiği ısınması veya büyük batch değerlendirmesi sırasında OOM'a neden oldu.
Temizlik protokolü	Katı	Her çalıştırma arasında, tüm vLLM ve Ray işlemleri zorla sonlandırılır ve bir sonraki çalıştırma başlamadan önce GPU belleği temiz olarak doğrulanır.

Test prompt'ları

5 test prompt'u:

"Görelilik teorisini basit terimlerle açıklayın." (Bilim/Soyut)
"En uzun palindromik alt diziyi bulmak için bir Python fonksiyonu yazın." (Kodlama)
"İklim değişikliğinin ana nedenleri ve etkileri nelerdir?" (Karmaşık Akıl Yürütme)
"Fotosentez sürecini adım adım açıklayın." (Süreç Açıklaması)
"Bir sinir ağı veriden nasıl öğrenir?" (Teknik Açıklama)

Veri doğrulama: vLLM çalışma zamanı telemetrisi

Bu makaledeki bellek ve eşzamanlılık rakamları, benchmark çalıştırması sırasında vLLM motoru başlatma günlüklerinden doğrudan elde edildi.

BF16 başlatma:

1INFO ... Model loading took 61.03 GiB memory
2INFO ... Available KV cache memory: 4.38 GiB
3INFO ... GPU KV cache size: 17,952 tokens
4INFO ... Maximum concurrency for 4,096 tokens per request: 4.38x

GPTQ-Int4 başlatma:

1INFO ... Model loading took 18.14 GiB memory
2INFO ... Available KV cache memory: 47.28 GiB
3INFO ... GPU KV cache size: 193,632 tokens
4INFO ... Maximum concurrency for 4,096 tokens per request: 47.27x

Kıyaslamalarımızı ve veri odaklı içgörülerimizi kaçırmayın. Düğme Google'ı açar; AIMultiple'ı seçmeniz, Google arama sonuçlarında AIMultiple'ı daha sık görmek istediğinizi onaylar.

Tercih edilen kaynak olarak ekle

Sınırlamalar

Tüm testler batch boyutu 1 kullanır. yüksek verimlilik senaryolarında, bellek bant genişliği doygunluğu baskın darboğaz haline geldiğinden Int4 ve BF16 arasındaki performans farkı genişler.

Sonuçlar H100 SXM'ye özeldir. Eski GPU'lar (A100, A10) yerel FP8 desteğinden yoksundur. Tüketici GPU'ları (RTX 4090) farklı bellek bant genişliği özelliklerine sahiptir.

GPTQ modelleri (JunHowie), topluluk tarafından sağlanan kuantizasyonlardır. Resmi sürümler farklı kalibrasyon veri setleri veya parametreler kullanabilir, bu da doğruluğu etkileyebilir.

Sadece GPTQ'yu test ettik. Diğer kuantizasyon yöntemleri (AWQ, BitsAndBytes NF4, GGUF, HQQ) farklı takaslar sunabilir.

Sonuç

H100 üzerindeki Qwen3-32B için, FP8 varsayılan seçenektir. 1.5 kat verimlilik, yarı bellek ayak izi ve 0.6 puan doğruluk maliyeti elde edersiniz.

Int4, maksimum verimlilik veya eşzamanlılık gerektiğinde mantıklıdır: 2.7x hız, 12x eşzamanlılık, MMLU-Pro'da 1.6 puan ve HumanEval'da 8 puan maliyeti karşılığında.

Int8 ortada yer alır ve bu kurulumda FP8'e karşı net bir avantaj sunmaz. FP8'e göre verimlilik kazancı küçüktür (37.9'a karşı 43.3 tok/s) ve doğruluk karşılaştırılabilirdir. FP8, model yazarları tarafından resmi olarak sağlandığı ve üçüncü taraf kuantize bir checkpoint gerektirmediği için daha basittir.

Kuantizasyonun en büyük pratik etkisi hız değil, eşzamanlılıktır. BF16, tek bir H100'de 4K bağlamda 4 kullanıcıya hizmet verebilir. Int4 47'ye hizmet verebilir. $2.69/saat fiyatıyla, bu 1M token başına maliyeti $28.73'ten $10.69'a düşürür.

Bu araştırmayı kaynak gösterin

Yayınlayacağınız yere uygun formatı seçin. Bağlantılı sürümü CMS'inize yapıştırmak, geri bağlantıyı korur.

Ekrem Sarı and Sıla Ermut (2026) - "LLM Kuantizasyonu: BF16 vs FP8 vs INT4". AIMultiple.com adresinde çevrimiçi yayımlanmıştır. Erişim tarihi: 17 Mart 2026, kaynak: https://aimultiple.com/llm-quantization [Çevrimiçi Kaynak]

Sarı, E., & Ermut, S. (2026, 17 Mart). LLM Kuantizasyonu: BF16 vs FP8 vs INT4. AIMultiple. https://aimultiple.com/llm-quantization

@misc{sar2026,
  author = {Sarı, Ekrem and Ermut, Sıla},
  title  = {{LLM Kuantizasyonu: BF16 vs FP8 vs INT4}},
  year   = {2026},
  month  = mar,
  howpublished    = {\url{https://aimultiple.com/llm-quantization}},
  note   = {AIMultiple. Erişim tarihi: 17 Mart 2026}
}

Ekrem Sarı

Yapay Zeka Araştırmacısı

Takip Et

Ekrem, AIMultiple'da yapay zeka araştırmacısı olarak çalışmakta olup, akıllı otomasyon, GPU'lar, yapay zeka ajanları ve RAG çerçeveleri üzerine yoğunlaşmaktadır.

Tam Profili Görüntüle

Araştıran

Sıla Ermut

Sektör Analisti

Takip Et

Sıla Ermut, AIMultiple'da e-posta pazarlama ve satış videoları üzerine odaklanan bir sektör analistidir. Daha önce proje yönetimi ve danışmanlık firmalarında işe alım uzmanı olarak çalışmıştır. Sıla, Sosyal Psikoloji alanında Yüksek Lisans ve Uluslararası İlişkiler alanında Lisans derecesine sahiptir.

Tam Profili Görüntüle