LLM Kuantizasyon Rehberi: Benchmark Verileriyle 7 Yöntem Karşılaştırması

LLM Kuantizasyon Rehberi: Benchmark Verileriyle 7 Yöntem Karşılaştırması

FP16 formatında Llama 3.3 70B, yalnızca ağırlıklar için 140 GB gerektiriyor. Yani iki adet H100. Q4_K_M'de aynı model kabaca 42 GB'a sığıyor; bu da eBay'den alınmış ikinci el bir RTX A6000 demek. Bu fark, LLM kuantizasyonunun var olma sebebi ve yanlış yöntemi seçmek size ya gözle görülür bir kalite kaybına ya da sahip olmadığınız bir VRAM'e mal oluyor.

Bu LLM kuantizasyon rehberi, 2026'da önemli olan 7 yöntemi, her sayı yayınlanmış bir kaynağa dayandırılarak karşılaştırıyor.

Öne Çıkanlar

• Kuantizasyon, bellek ve bant genişliğini ölçülebilir, genellikle küçük, bir kalite kaybı karşılığında takas eder.
• GPTQ ve AWQ önce GPU için tasarlanmıştır; GGUF ise CPU'da da çalışabilen formattır.
• Q4_K_M, ağırlık başına 4 değil, yaklaşık 4,8 bit'e oturur. Adlandırma bu ek yükü gizler.
• llama.cpp k-quants PR'ına göre 6-bit kuantizasyon, FP16 perplexity'sinin ~%0,1 yakınında kalır.

LLM Kuantizasyonu Modelinize Gerçekte Ne Yapar?

LLM kuantizasyonu, model ağırlıklarını daha düşük sayısal hassasiyette saklayarak bellek ve bant genişliğini küçültür; bedeli yuvarlama hatasıdır. 70B parametreli bir model FP16'da 140 GB iken 4-bit'te yaklaşık 42 GB'a düşer. Zeka kalır; ondalık basamaklar gider. Bu rehberdeki her yöntem, bu takasın bir varyantıdır.

Hassasiyet merdiveni FP32'den (32 bit) aşağı doğru FP16 ve BF16 (her biri 16 bit), ardından INT8, sonra INT4 şeklinde iner. Her basamak, parametre başına bayt sayısını yarıya indirir. IEEE 754 standardı kayan nokta formatlarını tanımlar; Mark Horowitz'in 2014 tarihli "Computing's Energy Problem" makalesi, enerji maliyetine bu baytların üzerindeki aritmetiğin değil, baytları taşımanın hükmettiğini göstermiştir. Kuantizasyonun çıkarımı hızlandırmasının fiziksel sebebi budur.

Kuantizasyonu çalıştıran iki parametre vardır: bir ölçek çarpanı (tamsayı aralığını gerçek değerlere geri eşleyen çarpan) ve bir sıfır noktası (0,0 değerini temsil eden tamsayı). Simetrik kuantizasyon aralığı sıfırda ortalar ve sıfır noktasını atlar; asimetrik kuantizasyon ise ağırlıklar sıfırdan uzakta kümelendiğinde tam tamsayı aralığını kullanmak için kaydırma uygular.

Ağırlıklar temiz kuantize olur, çünkü statiktirler ve normal dağılırlar. Aktivasyonlar öyle değildir. Bazen medyanın 100 katına ulaşan aykırı aktivasyonlar, naifçe kuantize ederseniz yuvarlama hatasını patlatır. Buradaki çoğu yöntemin yalnızca ağırlıkları kuantize etmesinin (W4A16) ve aktivasyonları FP16'da bırakmasının nedeni bu asimetridir.

Eğitim sonrası kuantizasyon (PTQ), eğitimi bitmiş bir modeli dönüştürür. Kuantizasyon farkında eğitim (QAT) ise yuvarlamayı eğitim sırasında simüle eder, böylece model uyum sağlar. Bu yazıdaki her şey PTQ'dur. QAT daha fazla hesaplama ve bir eğitim turu gerektirir; o ayrı bir karardır.

INT4 ve NF4 satırları teorik saf 4-bit'i gösterir: ağırlık başına 4 bit, hepsi bu. Gerçek 4-bit formatlar bunun üzerine blok ölçekleri ve minimum değerleri ekler, bu yüzden daha yükseğe çıkarlar. Q4_K_M'de bir 70B modeli yaklaşık 42 GB'tır, 35 GB değil. Daha aşağıdaki VRAM tablosu bunun yerine efektif oranları kullanır.

Kuantizasyon modelin zekasını küçültmez. O zekayı sakladığı ondalık basamak sayısını küçültür. API çıkarımı için token başına ödeme yapıyorsanız, LLM API faturanızı kısmak çoğu zaman kuantize edilmiş bir modeli kendiniz çalıştırmakla başlar.

7 Kuantizasyon Yöntemi Yan Yana

Aşağıdaki yedi yöntem, 2026'da bir LLM'i kuantize etmenin tüm üretim yollarını kapsıyor. İkisi yalnızca GPU'da çalışır (GPTQ, AWQ), biri her yerde çalışır (GGUF), biri yükleme anında kuantize eder (BitsandBytes), ikisi yüksek verimli sunumu hedefler (SmoothQuant, FP8) ve biri PyTorch yerlisidir (TorchAO). Doğru seçim, bir liderlik tablosunda en yüksek puanı alan yönteme değil, donanımınıza bağlıdır.

GPTQ, ters Hessian kullanarak yuvarlama hatasını kalan ağırlıklar arasında yeniden dağıtarak katman katman kuantize eder. Bir kalibrasyon seti ve bir GPU gerektirir. GPTQ makalesi, 175B'lik bir modelin yaklaşık 4 GPU-saatte 3-4 bit'e kuantize edildiğini bildiriyor.

AWQ, en kritik olan ~%1'lik ağırlık dilimini (aktivasyon büyüklüklerinden bulunan belirgin ağırlıklar) tespit eder ve bunları yuvarlamadan korumak için ölçekler. AWQ makalesi (MLSys 2024 en iyi makale ödülü), hem masaüstü hem mobil GPU'larda HuggingFace FP16 implementasyonuna göre 3x'ten fazla hızlanma bildiriyor.

GGUF bir dosya formatıdır, bir algoritma değil. İçindeki algoritma, llama.cpp PR #1684'ten gelen k-quant blok şemasıdır. Burada CPU'da çalışabilen tek yöntem budur; bu da onu yerel çıkarımın varsayılanı yapar. Ona ne vereceğinizi görmek için kuantize etmeye değer açık ağırlıklı modellere bakın.

BitsandBytes önceden değil, yükleme anında kuantize eder. NF4 (4-bit NormalFloat) onun imza formatıdır ve QLoRA ince ayarının omurgasıdır. Kalibrasyon seti gerekmez.

SmoothQuant, aktivasyon aykırı değerlerini ağırlıklara taşır, böylece her ikisi de INT8'de çalışabilir. Makale 1,56x'e kadar hızlanma ve 2x bellek azaltma bildiriyor; hedefi, W4A16 yöntemlerinin performansı masada bıraktığı büyük batch'li sunumdaki verimdir.

FP8 (W8A8), H100 ve B200 GPU'larda yerel yoldur. 8-bit'te neredeyse kayıpsız, kalibrasyon derdi yok ve vLLM bunu doğrudan destekliyor.

TorchAO, PyTorch'un kendi kuantizasyon kütüphanesidir ve torch.compile ile çalışacak şekilde tasarlanmıştır. Pipeline'ınız zaten PyTorch ise, en az dirençli yol budur.

Ortada yalnızca iki gerçek soru var: donanımınız bunu çalıştırıyor mu ve size mal olacağı kaliteyle yaşayabilir misiniz?

Yayınlanmış Benchmark'lar Gerçekte Ne Gösteriyor?

Yayınlanmış benchmark'lara göre 4-bit kuantizasyon, 7B'lik bir modelde %1-2 perplexity'ye mal oluyor, 6-bit ise %0,1'in altında. Bu sayılar llama.cpp PR #1684'ten (2023) geliyor; llama.cpp geliştiricileri tarafından tek bir 7B modeli üzerinde, RTX 4080'de ölçülmüş. Kuantizasyon alanında en çok alıntılanan rakamlar bunlar ve gerçekler. Aynı zamanda n = 1'ler.

Kaynak: llama.cpp PR #1684 (2023). 7B modeli, RTX 4080, llama.cpp geliştiricileri tarafından ölçüldü. n = 1 model.

Bit/ağırlık sütunu üzerine bir not: bunlar temel k-quant tipinin nominal oranlarıdır ve _K karışımları efektif oranı yükseltir. Q2_K buna iyi bir örnek. Yazının kendi formülünü nominal 2,5625 ve 6,74B parametreli bir model üzerinde çalıştırırsanız ~2,0 GB bulursunuz, ama satır 2,67 GB'lık bir dosya bildiriyor; bu da geriye doğru ~3,4 bit/ağırlığa karşılık gelir. Bu yazının geri kalanı, bu dosya boyutlarından türetilen efektif oranları kullanır.

GPU yöntemi sayıları doğrudan makalelerden geliyor. GPTQ, FP16'ya kıyasla A100'de kabaca 3,25x, A6000'de ~4,5x uçtan uca çıkarım hızlanması ve 175B'lik bir modelin yaklaşık 4 GPU-saatte 3-4 bit'e kuantize edildiğini bildiriyor. AWQ, "hem masaüstü hem mobil GPU'larda Huggingface FP16 implementasyonuna göre 3x'ten fazla hızlanma" ve TinyChat aracılığıyla bir mobil GPU'da gerçekleştirilen ilk 70B Llama-2 dağıtımını bildiriyor. Bir sayıyı sahte bir kesinliğe yuvarlamak yerine makalenin ifadesini alıntılıyoruz.

Buradaki özgün katkı aritmetik. Ağırlık belleği şu formülü izler: weights (GB) ≈ params (B) × bits per weight ÷ 8. Püf noktası, hangi bit/ağırlık sayısını verdiğinizdir. PR #1684 temel k-quant tipinin oranını yayınlar (Q4_K = 4,5) ve _S/_M/_L karışımları bu temel oranın üzerinde oturur, çünkü dikkat ve ileri beslemeli tensörlere ekstra bit ayırırlar. Bu yüzden efektif oranları, PR'ın kendisinin yayınladığı dosya boyutlarından, gerçekte 6,74B parametre olan bir 7B modeli üzerinden türettik: 2,67 GB ile Q2_K ~3,4 bpw'ye, 3,56 GB ile Q4_K_S ~4,5'e, 5,15 GB ile Q6_K ~6,6'ya karşılık geliyor. Q4_K_M ise 4,8 civarına oturuyor.

Bu, manşet sayısını değiştirir. Q4_K_M'de bir 70B modeli: 70 × 4.8 ÷ 8 = 42 GB. Çoğu yazı 35 GB der. 4,0 bpw kullanıp blok ölçeği ek yükünü tamamen atlıyorlar. Çapraz kontrol tek tık alır: Llama-3.3-70B-Instruct-Q4_K_M.gguf HuggingFace'te 42,5 GB olarak sunuluyor; bartowski, lmstudio-community ve second-state repolarının hepsinde aynı. Aşağıdaki VRAM tablosundaki her hücreyi bu temele göre yeniden hesapladık.

Bu sayılardan bizim çıkardığımız şu: Q6_K (5,9110) ile F16 (5,9066) arasındaki perplexity farkı 0,0044'tür ve bu, aynı temel modelin iki farklı ince ayarı arasındaki farktan küçüktür. "Gidin Q4_K_M ya da Q5_K_M kullanın" tavsiyesinin gerçek donanımla temas ettiğinde hâlâ ayakta kalmasının sebebi budur. ms/token sütunu ayrıca Q2_K'nin Q4_K_S'e göre hiçbir hız kazanmadığını (ikisi de 15,5 ms/token) gösterirken, 0,75 perplexity'ye mal olur. Q2_K, tablodaki en kötü takastır.

Sayıların size söylemediği: wikitext perplexity'si, kendi prompt'larınızdaki kaliteyle aynı şey değildir. Tek GPU'da tek model n = 1'dir. Hız rakamları batch boyutuna bağlıdır. Bunları evrensel değil, yönlendirici kabul edin.

6-bit kuantizasyon, tam hassasiyetli modelin perplexity'sinin yaklaşık %0,1 yakınına iner. Bu seviyede sıkıştırma neredeyse bedavadır.

GPTQ mi AWQ mi: İki GPU Yöntemi Arasında Seçim

GPTQ ve AWQ'nun ikisi de bir kalibrasyon setinden 4-bit GPU kontrol noktaları üretir ve ikisi de vLLM'de iyi desteklenir. Fark, yuvarlama hatasını ele alış biçimlerindedir. GPTQ, ters Hessian kullanarak hatayı kalan ağırlıklar arasında yeniden dağıtır. AWQ, aktivasyonların önemli olarak işaretlediği %1'lik ağırlık dilimini korur. İkisi de işe yarar. Seçim, sunum deseninizle ilgilidir.

GPTQ katman katman çalışır. Her katman için tek seferde bir ağırlığı kuantize eder, ardından o katmandaki kalan ağırlıkları, az önce yaptığı yuvarlamayı telafi edecek şekilde ayarlar. Ayarlama, Hessian matrisinden gelen ikinci derece bilgiyi kullanır; hesaplamak için bir kalibrasyon seti gerekmesinin nedeni budur. Sonuç, verimin token başına gecikmeden daha önemli olduğu toplu çıkarım için güçlüdür.

AWQ farklı bir açıdan yaklaşır. Kalibrasyon seti boyunca aktivasyon büyüklüklerine bakarak, kabaca kanalların en üst %1'i olan belirgin ağırlıkları tespit eder. Bu ağırlıklar, yuvarlama sırasında daha yüksek hassasiyetli aralıkta kalmalarını sağlayan kanal başına bir ölçek çarpanı alır. Kalibrasyon seti GPTQ'nunkinden küçük olabilir ve AWQ buna daha az aşırı uyar, çünkü belirli girdilere uymak yerine yapısal özellikleri korur. Makale, gecikmeye duyarlı sunumda güçlü sonuçlar bildiriyor.

Şu durumlarda GPTQ seçin: GPU'da toplu çıkarım yapıyorsanız, alanınıza uyan iyi bir kalibrasyon setiniz varsa ve asıl metrik verim ise.

Şu durumlarda AWQ seçin: düşük gecikmeyle tek kullanıcılı isteklere sunum yapıyorsanız, daha küçük bir kalibrasyon seti istiyorsanız veya uç/mobil GPU'larda dağıtım yapıyorsanız.

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

Sunum motorları arasında da seçim yapıyorsanız, vLLM ile SGLang karşılaştırması bu kararı ayrıca ele alıyor.

GGUF ve K-Quant'lar: Q4_K_M Gerçekte Ne Anlama Geliyor

GGUF bir dosya formatıdır, bir kuantizasyon algoritması değil. GGUF spesifikasyonu, model ağırlıkları, meta veri ve tokenizer verileri için bir konteyner tanımlar. Bir GGUF dosyasının içindeki kuantizasyon algoritması, llama.cpp PR #1684'ten gelen k-quant (veya i-quant) blok şemasıdır. Konteyneri algoritmayla karıştırmak bu alandaki en yaygın hatadır ve tam olarak anlam kazanmayan "GGUF mi iyi, GPTQ mi?" gibi sorulara yol açar.

Adlandırma şeması şöyle çözülür. Q, k-quant blok şeması demektir; IQ, önem matrisli i-quant anlamına gelir (aynı bit derinliğinde daha iyi kalite için bir önem matrisi kullanan daha yeni bir varyant). Sayı, nominal bit derinliğidir. _K, k-quant ailesini Q4_0 gibi eski formatlardan ayırır. _S, _M, _L hangi tensör gruplarının ekstra bit alacağını kontrol eder: small, medium, large. Daha yüksek sonek, en kritik olan dikkat ve ileri beslemeli tensörlere daha fazla bit ayrılması demektir.

Efektif oranlar; PR #1684'te yayınlanan 7B (6,74B parametre) dosya boyutlarından geriye doğru çözüldü, temel tip rakamlarından değil. Eski satırlar yapıları gereği kesindir: bir Q4_0 bloğu 4 bit'te 32 ağırlık artı bir FP16 ölçektir, yani ağırlık başına 4,5 bit; Q8_0 ise 8 bit'te 32 ağırlık artı bir FP16 ölçektir, yani 8,5. PR da bunu doğrular ve 7B Q4_0 ile Q4_K_S dosyalarını aynı 3,56 GB olarak listeler.

Q4_K_M, ağırlık başına 4 bit değildir. Yaklaşık 4,8'dir. Blok ölçekleri ve minimum değerleri bir yerde durmak zorundadır ve _M karışımı bunun üzerine dikkat ile ileri beslemeli tensörlere ekstra bit harcar; Q4_K_M'nin Q4_K_S'in, Q3_K_M'nin de Q3_K_S'in üzerinde oturmasının, onlarla eşleşmemesinin sebebi tam olarak budur.

GGUF'un GPTQ'nun çalışamadığı yerlerde çalışmasının nedeni: CPU çıkarımını ve GPU VRAM'i ile sistem RAM'i arasında katman boşaltmayı (offload) destekler. Tamamı GPU'nunuza sığmayan bir 32B modeli, katmanlarının yarısı boşaltılmış halde çalıştırabilirsiniz; yavaş ama işlevsel. GPTQ'nun CPU yolu yoktur.

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

Yerel modellerde yeni misiniz? Herhangi bir şeyi kuantize etmeden önce ilk yerel modelinizi çalıştırmaya başlayın. Bir tarayıcı arayüzü istiyorsanız, Ollama üzerinde Open WebUI yaklaşık on dakika sürer. HuggingFace GGUF dokümanları, Hub'ın quant tipi adlandırmasını nasıl sunduğunu açıklar.

BitsandBytes, Marlin, SmoothQuant ve TorchAO

Bu dördü, kalan üretim yollarını kapsar. Hiçbiri "daha iyi bir GPTQ" değildir. Farklı sorunları çözerler.

BitsandBytes önceden değil, yükleme anında kuantize eder. Onu bir FP16 kontrol noktasına yönlendirirsiniz, o da anında NF4 veya FP4'e dönüştürür. Kalibrasyon seti yok, çevrimdışı adım yok. Asıl ünü QLoRA'dır: üzerine LoRA adaptörleri eğitilen 4-bit dondurulmuş bir temel model; bu, 65B'lik bir modelin tek GPU'da, 48 GB VRAM ile ince ayarını mümkün kılar. QLoRA bir çıkarım değil, eğitim tekniğidir, ama çoğu insanın BitsandBytes ile ilk tanışma sebebi budur.

Marlin bir kuantizasyon yöntemi değildir. Mevcut 4-bit kontrol noktalarını orta batch boyutlarında hızlandıran bir INT4xFP16 karma hassasiyetli GEMM çekirdeğidir. Marlin makalesi, A100 ve H100'de hızlanmalar bildirir. Sunum yığınınız destekliyorsa, zaten kuantize edilmiş bir model üzerinde etkinleştirirsiniz. "Marlin ile kuantize etmek" diye bir şey yoktur.

SmoothQuant, aktivasyon aykırı değerlerini kanal başına bir ölçekleme çarpanı aracılığıyla ağırlıklara kaydırır ve W8A8'i (hem ağırlıklar hem aktivasyonlar INT8'de) uygulanabilir kılar. Makale, W4A16 yöntemlerinin verimi masada bıraktığı büyük batch'li sunumu hedefler. Yüzlerce eşzamanlı isteğe sunum yapıyorsanız, doğru hamle budur.

TorchAO, torch.compile ile çalışan PyTorch yerlisi kuantizasyondur. Harici bağımlılık yok, format dönüşümü yok. Çıkarım pipeline'ınız zaten PyTorch ise, en düşük sürtünmeli seçenektir. Embedding modellerini yerel çalıştırmak için Ollama yolu genellikle daha basittir, ama TorchAO özel PyTorch yığınlarına uyar.

Kuantize Edilmiş Bir Model Ne Kadar VRAM Gerektirir?

Formül: weights (GB) ≈ params (B) × bits per weight ÷ 8. Q4_K_M'de bir 70B modeli: 70 × 4.8 ÷ 8 = 42.0 GB. Aşağıdaki oranlar efektif olanlardır; llama.cpp PR #1684'ün yayınladığı dosya boyutlarından geriye doğru çözüldü, temel tip rakamlarından değil; çünkü _M karışımları her zaman temel k-quant oranlarının üzerinde seyreder. Her zamanki 4,0 bpw kestirmesini kopyalamak yerine yeniden hesapladık.

Efektif bit/ağırlık değerlerinden hesaplandı: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. PR #1684'teki 7B (6,74B parametre) dosya boyutlarından türetildi, ardından yayınlanmış bir 70B derlemesiyle çapraz kontrol edildi: Llama-3.3-70B-Instruct-Q4_K_M.gguf HuggingFace'te 42,5 GB; burada öngörülen ise 42,0 GB.

Dürüst uyarı: bu, yalnızca ağırlıklar. KV önbelleği, bağlam uzunluğu ve framework ek yükü bunun üzerine eklenir. KV önbelleği bağlam uzunluğu ve batch boyutuyla ölçeklenir. 70B'lik bir modelde 32k bağlamlı bir oturum birkaç GB ekleyebilir. Ağırlık tablosu bütçe değil, tabandır. Bağlam pencereniz de VRAM kiralar. Tam tablo için model bazlı VRAM gereksinimleri ayrıntılarına bakın.

Hangi Kuantizasyon Yöntemini Kullanmalısınız?

Tercihlerinizden önce donanımınız karar verir. GPU'nuzda çalışmayan bir yöntem bir seçim değildir, bir dilektir. Aşağıdaki tablo, yaygın kurulumları, yukarıda ele alınan donanım kısıtları ve kalite takasları temelinde, onlar için gerçekten işe yarayan yönteme eşler.

Tüketici donanımındaki çoğu okuyucu için doğru cevap, önceden kuantize edilmiş bir Q4_K_M veya Q5_K_M GGUF'tur. HuggingFace'ten çekin, Ollama veya llama.cpp'te çalıştırın ve optimize etmeyi bırakın. Q4_K_M ile Q5_K_M arasındaki kalite farkı, bir perplexity tablosuna göre değil, dosyanın sığıp sığmadığına göre karar vermeniz gerekecek kadar küçüktür. Bunun ötesindeki her şey, kendi hatırı için yapılan optimizasyondur ve buna ancak modelin Q4'te sorununuzu gerçekten çözdüğünü doğruladıktan sonra değer.

Bu modelleri gerçekten yerelde çalıştıran araçlar rehberi, bir quant seviyesi seçtikten sonra sunum tarafını ele alır.

Kuantizasyonun Yanlış Gittiği Beş Durum

Kuantizasyon hataları neredeyse her zaman yapılandırma sorunlarıdır, yöntem sorunları değil. Şu beşi sürekli karşımıza çıkar.

1. Kalibrasyon seti alanınıza uymuyor. GPTQ de AWQ de kalibrasyon verisine uyar. Wikipedia üzerinde kalibre edip tıbbi transkriptlerde dağıtırsanız, kuantize model hiç görmediği token'larda düşük performans gösterir. Çözüm: gerçek girdi dağılımınızdan alınan bir kalibrasyon seti kullanın; 128 örnek bile işe yarar.

2. Grup boyutu çok büyük ayarlanmış. GPTQ'nun grup boyutu, kaç ağırlığın bir ölçek çarpanını paylaştığını kontrol eder. Standart 128'dir. 256 veya 512, kuantizasyon sırasında hesaplama tasarrufu sağlar ama küçük modellerde bir kalite uçurumuna çarpar. Çözüm: prompt'larınızda kalitenin korunduğunu doğrulamadıkça 128'de kalın.

3. Q2_K'nin kullanılabilir olmasını beklemek. PR #1684 verilerine göre Q2_K, F16'ya kıyasla ~0,87 perplexity'ye mal olur ve Q4_K_S'e göre hiçbir hız kazandırmaz (7B benchmark'ında ikisi de 15,5 ms/token). Daha küçük bir dosya ve daha kötü çıktı alırsınız, gecikme kazancı olmadan. Çözüm: dosya boyutu katı bir kısıt olmadıkça taban Q4_K_S'tir.

4. Kendi prompt'larınız yerine wikitext perplexity'siyle benchmark yapmak. Perplexity bir dil modelleme metriğidir. Modelin sistem prompt'unuza uyup uymadığını, JSON'ı doğru biçimlendirip biçimlendirmediğini veya alanınıza ait kelime dağarcığını işleyip işlemediğini ölçmez. Çözüm: 20-30 gerçek prompt'unuzu hem kuantize hem de kuantize edilmemiş modelden geçirip çıktıları karşılaştırın.

5. GGUF konteynerini içindeki kuantizasyon algoritmasıyla karıştırmak. Bu, "GGUF mi GPTQ mi" karşılaştırmasına, aynı kategoriymişler gibi yol açar. Değiller. GGUF bir dosya formatıdır. İçindeki k-quant şeması algoritmadır. Çözüm: dosya formatlarını değil, k-quant seviyelerini karşılaştırın (Q4_K_M ile Q5_K_M).

Sıkça Sorulan Sorular

LLM kuantizasyonu nedir?

LLM kuantizasyonu, bir modelin ağırlıklarının sayısal hassasiyetini düşürür; tipik olarak 16-bit kayan noktadan 4-bit veya 8-bit tamsayılara. Bu, bellek kullanımını azaltır ve bant genişliğini düşürerek çıkarımı hızlandırır. 70B'lik bir model 140 GB'tan yaklaşık 42 GB'a, 4-bit'e düşer. Kalite maliyeti genellikle 4-bit'te %1-2 perplexity'dir; 6-bit'te daha az.

Kuantizasyon modelin doğruluğunu düşürür mü?

Evet, ama çoğu kişinin beklediğinden az. llama.cpp PR #1684 benchmark'larına göre, 7B'lik bir modelde Q4_K_S, F16'ya kıyasla yaklaşık %2 perplexity'ye mal olur ve Q6_K %0,1'in altındadır. Gerçek prompt'lardaki pratik etki, özellikle Q4_K_M ve üzerinde, çoğu zaman perplexity sayısının düşündürdüğünden küçüktür.

GPTQ mi AWQ mi daha iyi?

İkisi de evrensel olarak daha iyi değildir. GPTQ ters Hessian hata yeniden dağıtımı kullanır ve toplu GPU çıkarımına uygundur. AWQ, aktivasyon farkında ölçekleme ile belirgin ağırlıkları korur ve gecikmeye duyarlı sunuma uygundur. AWQ daha küçük bir kalibrasyon seti gerektirir ve buna daha az aşırı uyar. Düşük gecikmeyle tek kullanıcılı isteklere sunum yapıyorsanız, AWQ ile başlayın.

Q4_K_M ne anlama geliyor?

Q4_K_M bir k-quant GGUF kuantizasyon seviyesidir. "Q4" nominal 4-bit derinlik demektir, "K" k-quant blok şemasını işaretler (eski Q4_0'a karşı) ve "M" medium anlamına gelir: dikkat ve ileri beslemeli tensörler ekstra bit alır. Efektif bit/ağırlık yaklaşık 4,8'dir, 4,0 değil; çünkü blok ölçekleri ve minimum değerleri ek yük bindirir ve medium karışımı bunun üzerine daha fazlasını harcar.

Kuantize edilmiş bir modeli CPU'da çalıştırabilir miyim?

Evet, ama yalnızca GGUF ile. GPTQ ve AWQ yalnızca GPU formatlarıdır. GGUF'un k-quant modelleri llama.cpp veya Ollama üzerinden CPU'da çalışır ve GPU VRAM'i ile sistem RAM'i arasında katman boşaltmayı destekler. Q4_K_M standart CPU quant'ıdır. GPU'dan daha yavaş token üretimi bekleyin, ama işlevsel çıkarım.

GGUF ile GGML arasındaki fark nedir?

GGML, llama.cpp'nin başlangıçta kullandığı eski tensör kütüphanesi ve dosya formatıdır. GGUF, Ağustos 2023'te onun yerini aldı; daha iyi meta veri desteği sunan daha esnek bir konteyner formatı olarak. Bugün HuggingFace'ten indirdiğiniz dosyalar GGUF'tur. GGML dosyaları eskidir ve artık nadiren dağıtılır.

Bir modeli kendim mi kuantize etmeliyim, yoksa önceden kuantize edilmiş mi indirmeliyim?

Önce önceden kuantize edilmiş olanı indirin. llama.cpp ve HuggingFace toplulukları, popüler modellerin çoğunu zaten her seviyede kuantize etti. Kendiniz kuantize etmek yalnızca alanınıza özel bir kalibrasyon seti gerekiyorsa veya modeliniz için önceden kuantize edilmiş bir sürüm yoksa mantıklıdır.

Ne zaman daha küçük bir model yerine kuantizasyon kullanmalıyım?

Daha büyük modelin yeteneğine ihtiyacınız var ama belleğe sığdıramıyorsanız kuantizasyon kullanın. Kuantize edilmiş bir 70B modeli, karmaşık akıl yürütme görevlerinde genellikle kuantize edilmemiş bir 13B modelini geride bırakır. Gecikme asıl kısıtsa bunun yerine daha küçük bir model kullanın; çünkü küçük modeller, kuantizasyondan bağımsız olarak daha hızlı token üretir.

Kuantizasyon ile distilasyon arasındaki fark nedir?

Kuantizasyon, mevcut bir modelin ağırlıklarının sayısal hassasiyetini düşürür. Distilasyon, daha küçük bir modeli daha büyük birini taklit edecek şekilde eğitir ve gerçekten farklı (daha küçük) bir mimari üretir. Kuantizasyon özgün modelin mimarisini korur ve ilke olarak geri döndürülebilir. Distilasyon yeni bir model oluşturur ve bir eğitim turu gerektirir.

Kısa versiyon: kuantizasyon, istediğiniz modeli sahip olduğunuz donanıma sığdırmanın yoludur. Tüketici GPU'ları veya Apple Silicon'daki çoğu kişi için, HuggingFace'ten çekilmiş önceden kuantize bir Q4_K_M GGUF çözümün tamamıdır. GPTQ ve AWQ, GPU sunumunun cevaplarıdır. FP8 ve SmoothQuant, üretim veriminin cevaplarıdır. Geri kalan her şey, modelin çalıştığını doğruladıktan sonra yapılan optimizasyondur.

Neyi kendi sunucunuzda barındıracağınıza karar veriyorsanız ve donanım-yöntem eşleşmesi için ikinci bir görüş istiyorsanız, bizimle konuşmaktan memnuniyet duyarız.