Quantization GGUF AWQ GPTQ LLM Model Optimizasyon Yerel Yapay Zeka Inference

Quantization Nedir? GGUF, GPTQ, AWQ ve INT4 Rehberi (2026)

Orta
person Yapay Zeka Uzmanı
campaign

Bu makale önemli ölçüde güncellendi

Son revizyon: 18 Temmuz 2026. İçerik mevcut araç sürümleri ve güncel kaynaklarla yenilendi.

list_altİçindekilerexpand_more
  1. 01Neden Bir LLM 70 GB Yer Kaplar?
  2. 02Quantization’ın Mantığı
  3. 03PTQ vs QAT: İki Farklı Strateji
  4. 04Bit Derinliği Karşılaştırması: 2b / 4b / 8b / 16b
  5. 05GGUF Formatı: llama.cpp Ekosistemi
  6. 06AWQ: Aktivasyona Duyarlı Ağırlık Quantization’ı
  7. 07GPTQ: Post-Training Quantization
  8. 08bitsandbytes ve QLoRA Bağlantısı
  9. 09Kalite Kaybı Hangi Görevlerde Hissedilir?
  10. 10Hangi Format Ne Zaman?
  11. 11Ollama ile Quantized Model Çalıştırmak
  12. 12HuggingFace’te Model Seçerken Etiket Okuma
  13. 13llama.cpp ile GGUF Model Çalıştırmak: Adım Adım
  14. 14Derleme
  15. 15Model İndirme ve Çalıştırma
  16. 16Sıkça Sorulan Sorular
  17. 17GGUF ve GGML arasındaki fark nedir?
  18. 184-bit kuantizasyon ne kadar kalite kaybına yol açar?
  19. 19GPTQ’yu CPU üzerinde çalıştırabilir miyim?
  20. 20Ollama hangi kuantizasyon formatını kullanıyor?
  21. 217B model için en iyi GGUF kuantizasyon seviyesi hangisi?

Quantization: büyük modeli daha küçük, verimli formata sıkıştırma

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ı. Float32, IEEE 754 standardına göre 1 işaret biti, 8 üs biti ve 23 mantis bitinden oluşur ve 7 basamak hassasiyet taşır. 4-bit tamsayıya (int4) geçtiğinizde elinizdeki bütçe yalnızca 16 farklı değer: -8’den 7’ye ya da 0’dan 15’e.

Peki float32’deki 0.347892 değeri int4’e nasıl dönüşür? Burada bir ölçekleme katsayısı devreye giriyor: bir ağırlık bloğundaki minimum ve maksimum değerler alınıp aralık 0-15 arasına sıkıştırılıyor. Dönüştürme sırasında kaçınılmaz bir yuvarlama hatası ortaya çıkıyor; buna quantization error deniyor. Parametre başına hata küçük görünse de milyarlarca parametrenin hatası birikince çıktı kalitesi etkileniyor. Tam da bu yüzden basit uniform quantization yerine aşağıda göreceğiniz daha sofistike yöntemler geliştirildi.

Bir ara teknik olan grup kuantizasyonu (group quantization) da burada devreye giriyor. Basit yaklaşımda tüm ağırlık matrisi tek bir ölçekleme katsayısıyla dönüştürülür; oysa matrisin bazı satırları -2 ile +2 arasında yoğunlaşırken diğerleri -50 ile +50 arasında dağılabilir. Grup kuantizasyonu matrisi 32, 64 ya da 128 parametrelik bloklara böler ve her blok için ayrı katsayı hesaplar. Dosya boyutu minimal artar, kalite belirgin biçimde iyileşir. GPTQ, AWQ ve GGUF’un K-quant seviyeleri bu teknikten yararlanıyor.

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.

PTQ vs QAT: İki Farklı Strateji

Model kuantizasyonunda iki temel yaklaşım var ve aralarındaki fark, kalitenin nerede korunduğuyla ilgili.

Post-Training Quantization (PTQ), eğitim bittikten sonra uygulanır: hazır bir modeli alıp ağırlıklarını daha düşük hassasiyete dönüştürürsünüz. Süreç hızlı ve ucuz; mevcut herhangi bir modele uygulanabilir. GPTQ, AWQ ve GGUF bu kategoriye giriyor. Dezavantajı, dönüşüm sırasında oluşan hatanın model tarafından telafi edilmemiş olması.

Quantization-Aware Training (QAT) ise eğitim sürecini işin içine katar. Model eğitilirken kuantizasyon simüle edilir: ileri geçişte düşük hassasiyetle çalışır, geri yayılımda gerçek gradyanlar kullanılır. Model kuantizasyon gürültüsünü öğrenip ona karşı dirençli hale gelir; aynı bit derinliğinde PTQ’ya kıyasla daha yüksek kalite elde edilir. Karşılığında modeli sıfırdan ya da fine-tuning ile yeniden eğitmek gerekir — ciddi bir hesaplama maliyeti.

Pratikte PTQ baskın: açık kaynak modelleri indirip çalıştırırken karşılaştığınız formatların neredeyse tamamı PTQ ürünü. QAT ise küçük özelleştirilmiş modeller ya da edge cihaz dağıtımları için tercih ediliyor.

Bit Derinliği Karşılaştırması: 2b / 4b / 8b / 16b

Bit derinliği karşılaştırması: 2b, 4b, 8b ve 16b için bellek ve kalite dengesi

Bit Derinliği70B Model BoyutuPerplexity ArtışıÖnerilen Senaryo
16-bit (float16)~140 GBReferans (%0)Araştırma, fine-tuning
8-bit (int8)~70 GB<%1Yüksek kalite gerektiren üretim
4-bit (int4)~35 GB%1-3Ev kullanımı, lokal çalıştırma
2-bit (int2)~18 GB>%10Deneysel, çok küçük modeller

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ı

GGUF dosya anatomisi: tokenizer, metadata ve quantized ağırlık katmanları

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)
  • IQ4_NL → 4-bit, importance quantization (düşük VRAM’e biraz daha uygun)

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.

HuggingFace Transformers ile AWQ modeli yüklemek olağan from_pretrained çağrısından farksız:

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen2.5-7B-Instruct-AWQ",
    device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct-AWQ")

Üretim ortamında vLLM ile OpenAI uyumlu bir API sunucusu ayağa kaldırmak da tek komut:

python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-72B-Instruct-AWQ \
    --quantization awq \
    --tensor-parallel-size 2

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ı. Standart int4, -8 ile +7 arasındaki değerleri eşit aralıklarla temsil eder; oysa sinir ağı ağırlıkları sıfır etrafında normal dağılıma benzer biçimde kümelenir. NF4 bu dağılıma özel tasarlanmış bir kuantizasyon ızgarası kullanır: sıfıra yakın değerler daha yoğun, uç değerler daha seyrek temsil edilir. Bu küçük değişiklik pratikte standart int4’ten daha az bilgi kaybı anlamına geliyor. Üstüne bir de double quantization eklenince (ölçekleme katsayılarının da 8-bit’e quantize edilmesi) bellek tasarrufu daha da artıyor.

HuggingFace Transformers ile 4-bit NF4 yükleme birkaç satır:

from transformers import AutoModelForCausalLM, BitsAndBytesConfig
import torch

quantization_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_quant_type="nf4",      # NF4 formatı
    bnb_4bit_use_double_quant=True   # İç içe kuantizasyon
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Meta-Llama-3.1-8B-Instruct",
    quantization_config=quantization_config,
    device_map="auto"
)

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.

Kalite Kaybı Hangi Görevlerde Hissedilir?

Perplexity ortalaması tek başına resmi tam anlatmıyor; görev tipi de önemli. Kod yazma, matematiksel çıkarım ve çok adımlı akıl yürütme, genel metin üretiminden daha fazla etkileniyor. Basit soru-cevap ya da özetleme görevlerinde int4 kaybı pratikte görmezden gelinebiliyor. Akıl yürüten AI modelleri için fark biraz daha belirginleşiyor.

Aynı 4-bit içinde bile varyantlar ayrışıyor: Q4_K_M’de float16’ya göre perplexity artışı %1-3 bandında kalırken, eski tip Q4_0’da %3-6’ya çıkabiliyor. K-quant varyantlarını tercih etmenin nedeni bu.

Structured outputs veya function calling gibi kısıtlı çıktı gerektiren görevlerde Q5 ya da Q8 seçmek daha güvenilir sonuç veriyor; int4’ün küçük perplexity artışı bu görevlerde geçersiz JSON gibi somut hatalar olarak tezahür edebiliyor.

Hangi Format Ne Zaman?

ÖzellikGGUFAWQGPTQbitsandbytes
CPU desteğiTamHayırHayırKısmi
GPU desteğiEvetCUDACUDACUDA
Ollama entegrasyonuYerelHayırHayırHayır
vLLM / TGIHayırEvetEvetHayır
Fine-tuning (QLoRA)HayırHayırHayırEvet
Calibration gerekirHayırEvetEvetHayır
Önerilen senaryoLokal çalıştırmaAPI servisiAPI servisiFine-tuning

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. Daha büyük bir modeli int4’te çalıştırmak, çoğu senaryoda daha küçük bir modeli tam hassasiyetle çalıştırmaktan daha iyi çıktı üretiyor — gerçi küçük dil modelleri bu denklemi giderek karmaşıklaştırıyor: 7B parametreli kuantize bir model ile 3B parametreli tam hassasiyetli bir modelin kalitesi pek çok görevde birbirine yaklaşıyor.

Quantization mevcut modeli olduğu yerde sıkıştırırken, knowledge distillation modeli baştan küçük eğitir; iki yaklaşım rakip değil, birbirini tamamlıyor. Beş yıl önce 70B parametreli bir modeli tek tüketici GPU’sunda çalıştırmak çoğu geliştiricinin ekranında olmayan bir seçenekti; quantization bu erişim bariyerini düşürdü.

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.


auto_stories İlgili Makaleler