Ollama Kuantizasyon Rehberi: Q4, Q8 ve FP16 Farkları

Ollama kuantizasyon değişiklikleri

Ollama kuantizasyonu, bir modeldeki her ağırlığı, eğitildiği dosyadan daha az bit ile saklar. q4_K_M ile biten bir etiket, ağırlık başına yaklaşık dört bit tutarken fp16 on altı bit tutar; bu nedenle indirme boyutu yaklaşık dörtte birine düşer ve makine her token'ı üretmek için dörtte bir oranında daha az bayt okur. Ağırlıklar atılmaz, kaba bir ızgara üzerine yuvarlanır; dört bit seviyesinde çoğu model, tam hassasiyetteki yanıtlarına yakın sonuçlar verir.

Tüm takas şudur: daha küçük bir bellek kullanımı ve saniyede daha fazla token üretimi; bunun karşılığında ise küçük bir doğruluk kaybı yaşanır. Aşağıda, yirmi dakikanızı ayırıp sığmayacak bir dosyayı indirmeden önce, belirli bir modelin belirli bir makinedeki performansını her iki açıdan da nasıl tahmin edebileceğiniz anlatılmaktadır.

Ollama henüz çalışmıyorsa, VPS üzerinde Ollama kurulumu ile başlayın. Bu sayfa, ollama ls aracının halihazırda çalıştığını varsayar.

Ollama q4_K_M gibi bir nicemleme etiketi nasıl okunur

Yerel modeller, llama.cpp'nin ağırlıkları diskte depolamak için kullandığı GGUF dosyaları olarak dağıtılır. Ollama, llama.cpp üzerine inşa edildiğinden, Ollama etiketleri llama.cpp'nin nicemleme isimlerini değiştirmeden taşır.

Sayı, hedef genişliği belirtir. q4, çoğu ağırlık tensörünün her biri dört bit olacak şekilde paketlendiği anlamına gelir. q8 sekiz biti ifade eder. fp16 ise hiç nicemlenmemiştir: model, çoğu modelin yayınlandığı hassasiyet olan on altı bit kayan noktalı formatındadır.

K, bir K-nicemlemeyi işaret eder. Ağırlıklar küçük bloklar halinde gruplandırılır ve her blok, paketlenmiş değerlerin yanında kendi ölçeğini saklar. Ağırlıklarının tamamı 0.01 civarında olan bir blok hassas bir ölçek alır. Tek bir büyük aykırı değer barındıran bir blok ise kaba bir ölçek alır. Dört bitlik bir dosyayı kullanılabilir kılan şey bu blok bazlı ölçeklerdir; aynı zamanda dört bitlik bir dosyanın hiçbir zaman ağırlık başına tam olarak dört bit olmamasının nedeni de budur.

Son harf karışımdır. S, M ve L, kaç tensörün hedef genişliğin üzerine çıkarılacağına karar verir. q4_K_M içinde, yuvarlandığında en çok zarar veren tensörler daha geniş saklanırken, ağırlıklı kısım dört bit seviyesinde kalır. q4_K_M'in, neredeyse aynı dosya boyutunda eski q4_0'dan daha iyi çıktı üretmesinin nedeni budur.

Yazdığınız isimden tahmin yürütmek yerine, Ollama'ya diskinde ne olduğunu sorun:

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show; architecture, parameters, quantization, context length ve embedding length bilgilerini yazdırır. quantization satırı, aylar önce çektiğiniz ve artık seçtiğinizi hatırlamadığınız bir model için kesin gerçeği gösterir.

Ağırlık başına bit değeri, dosya boyutunu belirleyen temel unsurdur

Her boyut tahmini tek bir sayıdan yola çıkar: formatın, dosyanın tamamına yayıldığında ağırlık başına harcadığı ortalama bit miktarı. llama.cpp, Llama 3.1 8B modeli için ölçülen değerleri quantize dokümantasyonunda yayınlamaktadır ve bu değerler, benzer yapıdaki tüm yoğun modeller için geçerlidir.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

Tablodaki şaşırtıcı kısım ikinci sütundur. Q4_K_M, ağırlık başına dört bit değildir. Bu format 4.89 bit değerindedir; çünkü blok ölçekleri ve yükseltilmiş tensörler gerçek anlamda alan kaplar. Q8_0 ise aynı nedenle sekiz değil, 8.5 bit değerindedir. Ölçülen bu sayıyı kullandığınızda, hesaplama gerçek dosya boyutunun yüzde birkaç sapma payıyla aynısını verir:

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

Bu, iki sayıdan elde edilen 4.58 GiB boyutundaki Q4_K_M dosyasıdır. Bu değer aynı zamanda, ağırlıklar yüklendiğinde kapladıkları bellek miktarına da oldukça yakındır. Ollama yükleme sırasında herhangi bir açma işlemi yapmaz: kuantize edilmiş ağırlıklar bellekte aynı paketlenmiş biçimde durur ve her blok kullanıldığı sırada dönüştürülür.

Ollama'nın her model boyutu için sunduğu sürümler

Kütüphane, çoğu model ailesi için bir q4_K_M, bir q8_0 ve bir fp16 etiketi yayınlar. Bunlar, Ağustos 2026 itibarıyla model sayfasındaki etiket listesinden alınan Qwen3 boyutlarıdır.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

Burada varsayılan etiket önemlidir. ollama pull qwen3:8b, ollama pull qwen3:8b-q4_K_M ile tam olarak aynı 5.2 GB veriyi indirir; çünkü sonek içermeyen etiket, doğrudan q4_K_M sürümüdür. Q4_K_M, kütüphanenin isteksizce sunduğu bir taviz değildir. Yukarı akış (upstream) tarafından seçilen varsayılan değerdir; bu nedenle, henüz kendinizin test etmediği herhangi bir model için bu değerle eşleşmek, atılacak en mantıklı ilk adımdır. Aynı mantık, bir VPS üzerinde Qwen 3 çalıştırma rehberindeki etiket seçimlerini de yönlendirir.

Oranlar her satırda geçerliliğini korur. q4_K_M sürümünden q8_0 sürümüne geçmek, tam olarak iki katı değil, yaklaşık yüzde yetmiş daha fazla maliyet getirir; çünkü embedding ve çıktı tensörleri, geri kalan kısımlarla aynı oranda ölçeklenmez. fp16, q4_K_M'in kabaca üç katıdır. q4_K_M sürümündeki 32B bir model, 20 GB ağırlığındadır ve bu değer, 16 GB belleğe sahip bir sunucunun herhangi bir bağlam penceresiyle (context window) barındırabileceği sınırın üzerindedir. Hangi modelin hangi makineye sığacağına dair daha geniş bir bakış için kendi sunucunuzda barındırabileceğiniz modeller bölümüne bakabilirsiniz.

KV önbelleğinin neden ikinci, bağlama bağlı bir maliyet olduğu

Ağırlıklar sabit maliyettir. KV önbelleği (anahtar ve değer önbelleği) ise değişken maliyettir. Bağlam penceresindeki her token, her katman için kendi anahtar ve değer vektörlerini tutar; bu nedenle önbellek, izin verdiğiniz pencere boyutuyla doğru orantılı olarak büyür. Önbellek, konuşma ilerledikçe değil, model yüklendiği anda tüm pencere için ayrılır; bu yüzden uzun bir pencere, tek kelimelik bir istemde bile bellek maliyeti oluşturur.

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

Bu model numaraları, modelin kendi yapılandırmasından gelir: 36 katman, 8 anahtar/değer başlığı ve 128'lik başlık boyutu. ollama show size mimariyi ve parametre sayısını verir; modelin Hugging Face üzerindeki config.json sayfası ise geri kalan bilgileri sağlar. Token başına maliyeti pencere boyutuyla çarptığınızda, önbellek artık ihmal edilebilir bir değer olmaktan çıkar.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

Ollama'nın varsayılan 4096 token'lık penceresinde önbellek, ağırlıkların üzerine 0.6 GB ekler. Pencereyi 32k değerine yükselttiğinizde, sadece önbellek 4.83 GB seviyesine ulaşır ki bu, nicelenmiş ağırlıklar kadar bellek tüketir ve tüm model için alt sınır 10 GB olur. Buna alt sınır denmesinin nedeni, hesaplama tamponlarının ve işletim sisteminin bunun üzerine eklenmesidir. Gerçek değeri, model yüklendikten sonra ollama ps içindeki SIZE sütunundan okuyun.

Ollama'yı bir servis olarak çalıştırdığınızda pencere boyutu, istek bazlı değil, sunucu bazlı ayarlanır:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

systemd kurulumu için ayarı bir drop-in dosyasına ekleyin:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

sudo systemctl restart ollama ile yeniden başlatın, ardından çalışan modelin hangi pencere boyutuyla yüklendiğini doğrulamak için ollama ps içindeki CONTEXT sütununu kontrol edin. OLLAMA_KV_CACHE_TYPE, önbelleğin kendisini niceler: f16 varsayılan değerdir, q8_0, f16 değerinin yaklaşık yarısı kadar bellek kullanır, q4_0 ise yaklaşık dörtte birini kullanır. Bu küresel bir seçenektir, dolayısıyla sunucudaki her model aynı işleme tabi tutulur. Uzun pencere boyutuna sahip küçük bir sistemde, önbelleği yarıya indirmek diğer tüm değişikliklerden daha fazla bellek açığa çıkarır. num_ctx ayarı ve maliyeti konusu, pencere boyutunu ayrıntılı olarak ele alır.

8, 16 veya 32 GB VPS üzerinde neler çalıştırılabilir

Model ağırlıkları, KV cache ve işletim sistemi ile diğer çalışan süreçler için ayrılan pay toplamı dikkate alınmalıdır. Küçük bir VPS üzerinde 2 GB boşluk bırakmak güvenli bir çalışma alanı sağlar.

8 GB. q4_K_M seviyesindeki 4B bir model 2.6 GB yer kaplar ve uzun bir bağlam penceresi için alan bırakır. q4_K_M seviyesindeki 8B bir model, varsayılan 4k pencere ile ucu ucuna sığar. Burada 32k pencere ile 8B model çalıştırmayı planlamayın; çünkü 10 GB olan alt sınır, sunucunun kapasitesini aşmaktadır.

16 GB. q4_K_M seviyesindeki 8B bir model, 16k veya 32k pencere ile rahatça çalışır. q4_K_M seviyesindeki 14B bir model 9.3 GB ağırlığındadır ve makul bir pencere boyutuyla sığar. q8_0 seviyesindeki 8B bir model ise 8.9 GB yer kaplar; bu da sığabileceği anlamına gelir. Bu iki modeli kendi istemlerinizle karşılaştırmak, bu konu üzerinde geçireceğiniz en verimli saattir.

32 GB. q8_0 seviyesindeki 14B (16 GB) ve q4_K_M seviyesindeki 32B (20 GB) modellerin her ikisi de yüklenebilir. Geniş bir pencereye sahip 32B yapılandırması bellek sınırlarını zorlayacaktır; bu nedenle varsayımlarda bulunmak yerine ollama ps değerini izleyin.

Hangi nicemleme (quantization) ilk önce bozulur

Nicemleme hatası, bir modelin yaptığı işlere eşit şekilde dağılmaz. Akıcılık en uzun süre korunan özelliktir; hasarın gözden kaçmasının nedeni tam olarak budur: kötü nicemlenmiş bir model bile düzgün cümleler kurmaya devam eder. İlk bozulan şey kesinliktir. Bir sürüm numarası, bir API imzası veya bir tarihin tam olarak hatırlanması gibi. İkinci adımda yapılan küçük bir hatanın sekizinci adımda yanlış bir cevaba dönüştüğü uzun mantık zincirleri. Tek bir yanlış parantezin araç çağrısının başarısız olmasına neden olduğu katı çıktı formatları.

Sonuncusu, pratik testtir. Bir model, kodunuzun ayrıştırdığı JSON formatında çıktı vermesi gerektiğinde, nicemleme hasarı belirsiz bir şekilde kötüleşen bir metin yerine bir ayrıştırma hatası olarak ortaya çıkar; bu yüzden durumu aynı gün fark edersiniz. Bir kodlama ajanı, bu testin en zorlu versiyonudur çünkü modeli sürekli araç çağrıları yapmaya zorlar; bu nedenle bir ajanı Ollama sunucunuza yönlendirmek, aşırı agresif bir nicemlemeyi bir öğleden sonra içinde ortaya çıkaracaktır.

Dört bitin altında kayıp hızla artar. q3 ve iki bitlik türler, büyük bir modeli küçük donanımlara sığdırmaya çalışanlar için mevcuttur ve alternatif, modeli hiç çalıştıramamak olduğunda gerçek bir seçenektir. Ancak bunlar kötü varsayılanlardır. q4_K_M ile q8_0 arasındaki fark, yayınlanmış bir şaşkınlık (perplexity) tablosunun iş yükünüz için karar vermeye yetmeyeceği kadar küçüktür, bu yüzden bu yöntemle karar vermeye çalışmayın. Her ikisini de kendi otuz isteminizle çalıştırın ve çıktıyı okuyun.

q8_0 veya fp16'nın RAM'e değdiği durumlar

Bellek gerçekten boştaysa ve görev küçük hataları cezalandırıyorsa q8_0 sürümünü çekin: yapılandırılmış veri çıkarma, araç çağırma ve derlenmesi gereken kodlar gibi. Burada belirgin şekilde daha zeki bir model değil, bir tür sigorta satın alıyorsunuz.

fp16 sürümünü yalnızca iki nedenden dolayı çekin. Ya modeli kendiniz kuantize ediyorsunuz ve kaynak dosyaya ihtiyacınız var ya da dört bitlik derlemenizin ne kadar performans kaybettiğini ölçmek için bir temel (baseline) oluşturuyorsunuz. fp16 üzerinden servis vermek, çoğu insanın kör testte ayırt edemeyeceği bir fark için q4_K_M sürümünün üç katı bellek harcar; sadece CPU bulunan bir makinede ise token hızınızı üçte bire düşürür.

Sabit bir bellek bütçesinde geçerli olan daha güçlü kural şudur: q4_K_M seviyesindeki daha büyük bir model, genellikle q8_0 seviyesindeki daha küçük bir modeli geride bırakır. 9.3 GB boyutundaki 14B ağırlıkları ile 8.9 GB boyutundaki 8B ağırlıkları neredeyse aynı miktarda RAM (rastgele erişimli bellek) kullanır ve daha büyük olan model daha fazla bilgiye sahiptir. Bunu körü körüne kabul etmek yerine kendi istemlerinizle test edin.

CPU tabanlı çıkarım, bellek bant genişliği ile sınırlıdır

Çoğu VPS planında GPU bulunmaz, bu nedenle model, ana makinenin CPU'su üzerindeki sistem belleğinde çalışır. Üretim süreci aritmetik işlemlerden ziyade bellek bant genişliğine bağlıdır; çünkü tek bir token üretmek, tüm ağırlıkların bir kez okunmasını gerektirir. Bu durum, satın alınan çekirdek sayısından bağımsız bir üst sınır oluşturur.

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

Saniyede 50 GB, çift kanallı DDR4-3200 bir ana makine için yaklaşık teorik değerdir. Sizin payınıza düşen miktar daha azdır, çünkü bir VPS, bu veri yolunu makinedeki diğer tüm kiracılarla paylaşır; bu nedenle bu sayıları kimsenin ulaşamadığı bir tavan değeri olarak kabul edin. Önemli olan eğilimdir: CPU üzerinde, ağırlık başına bit sayısını yarıya indirmek, token hızını kabaca iki katına çıkarır. Kuantizasyon, GPU olmayan bir makinede mevcut olan en büyük hız artırma aracıdır.

İstem (prompt) işleme süreci farklı davranır. Uzun bir istemi okumak, bant genişliğine değil işlem gücüne bağlıdır; bu nedenle ek çekirdekler burada işe yararken, üretim hızı üzerinde neredeyse hiçbir etkisi olmaz. 4k uzunluğundaki bir istemi hızlıca alan ancak ardından yavaş üretim yapan bir makine normal şekilde çalışıyordur.

Aritmetik hesaplamaların hiçbirini olduğu gibi kabul etmeyin. Kendi makinenizde saniyedeki token sayısını ölçün ve her kuantizasyon seviyesinde aynı istemi kullanarak elde ettiğiniz sonuçların bu verilerin önüne geçmesine izin verin.

Bir modeli kendiniz kuantize etme

Ollama, fp16 veya fp32 bir kaynaktan kuantize edilmiş bir model oluşturabilir. Bu işlem, ince ayar (fine-tune) yaptığınız ve henüz bir kütüphane etiketi bulunmayan modeller için gereklidir. Modelfile dosyasını kuantize edilmemiş ağırlıklara yönlendirin:

FROM /path/to/my/model/f16

Ardından derleyin ve doğrulayın:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize komutu q8_0, q4_K_S ve q4_K_M parametrelerini kabul eder. Burada q6_K veya q5_K_M seçeneği bulunmamaktadır; bu nedenle bu tür işlemler için llama.cpp'nin kendi aracını kullanarak kuantizasyon yapmalı ve tamamlanmış GGUF dosyasını içe aktarmalısınız. ollama show içindeki quantization satırı, derleme işleminin istediğiniz şekilde gerçekleştiğini doğrulamanızı sağlar.

İşler yolunda gitmediğinde görecekleriniz

Beklediğinizin aksine her şey CPU üzerinde çalışıyor. PROCESSOR sütununu okuyun:

ollama ps

Bu sütun 100% GPU, 100% CPU veya 48%/52% CPU/GPU gibi bir bölünme çıktısı verir. Bölünme, ağırlıkların ve KV önbelleğinin VRAM'e (ekran kartı üzerindeki video belleği) sığmadığı, dolayısıyla modelin bir kısmının sistem belleğine yerleştirildiği anlamına gelir. Bu durumda hız, her bir token yavaş olan yarıyı beklediği için CPU hızına yaklaşır. Bağlam penceresini (context window) küçültün, önbelleği nicemleyin (quantize) veya daha küçük bir yapı (build) çekin. Çekirdek sayısını artırmak bir çözüm sağlamaz.

Model yüklenirken sonlandırılıyor. Çekirdek (kernel) ve servis günlüklerini kontrol edin:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

Out of memory: Killed process ifadesini içeren bir satır, ağırlıkların, KV önbelleğinin ve arabelleklerin toplamının sunucudaki bellek miktarını aştığı anlamına gelir. Swap yapılandırılmamış bir VPS üzerinde, bu satır görünmeden önce tüm makine birkaç saniyeliğine donabilir.

Hiçbir şeyi değiştirmediğiniz halde yanıtlar kötüleşti. Aynı modelin iki farklı sürümü, farklı etiketler (tag) altında ollama ls içinde yan yana durabilir ve etiketsiz ismi çeken bir betik, kütüphanenin o an işaret ettiği sürümü takip eder. Yapılandırma dosyanızdaki isme güvenmek yerine, istemcinizin talep ettiği tam etiket için ollama show komutunu çalıştırın ve quantization satırını okuyun.

FAQ

Hangi Ollama kuantizasyonunu çekmeliyim?

q4_K_M ile başlayın. Ollama kütüphanesinin çoğu model için varsayılan etiket olarak sunduğu sürüm budur; bu nedenle ollama pull qwen3:8b ve ollama pull qwen3:8b-q4_K_M aynı dosyayı indirir. Yalnızca bellek boşta olduğunda ve görev, araç çağırma veya yapılandırılmış JSON çıktısı gibi küçük hataların cezalandırıldığı durumlarda q8_0 sürümüne geçin. Bellek bütçesi kısıtlı olduğunda, q4_K_M seviyesindeki daha büyük bir model genellikle q8_0 seviyesindeki daha küçük bir modeli geride bırakır; bu nedenle hassasiyet için RAM harcamadan önce bu eşleşmeyi test edin.

q4_K_M gerçekten ağırlık başına dört bit mi demek?

Hayır. Llama 3.1 8B üzerinde yapılan ölçümlerde bu değer 4.89 bit/ağırlıktır; çünkü her ağırlık bloğu kendi ölçeğini saklar ve en hassas tensörler daha geniş bir türe yükseltilir. Q8_0 aynı nedenle sekiz yerine 8.5 bit ölçülür. Tahmin yaparken ölçülen rakamı kullanın: parametre sayısı çarpı ağırlık başına bit, bölü sekiz, dosya boyutunu bayt cinsinden verir.

Sadece CPU içeren bir VPS üzerinde 8B model ne kadar RAM gerektirir?

Ağırlıkları, KV önbelleğini (cache) ve payı toplayın. Qwen3 8B modelinin q4_K_M sürümü 5.2 GB ağırlığa sahiptir. Varsayılan 4096 token penceresinde önbellek 0.6 GB ekler; bu da hesaplama tamponları ve işletim sistemi öncesinde 5.8 GB civarında bir taban değer oluşturur. 32k penceresinde ise sadece önbellek 4.83 GB yer kaplar. Kısa bir pencere için 8 GB, uzun bir pencere istiyorsanız 16 GB RAM planlayın.

Sunucuda GPU olmasına rağmen model neden %100 CPU kullanıyor?

ollama ps komutunu çalıştırın ve PROCESSOR sütununu inceleyin. 100% CPU veya 48%/52% CPU/GPU gibi bir bölünme, ağırlıkların ve KV önbelleğinin VRAM'e sığmadığı, bu nedenle Ollama'nın modelin bir kısmını veya tamamını sistem belleğine yerleştirdiği anlamına gelir. Bunun yaygın nedeni, model yüklendiğinde önbelleğin tüm pencere için ayrılması nedeniyle bağlam penceresinin kartın kapasitesinden büyük olmasıdır. Pencere boyutunu OLLAMA_CONTEXT_LENGTH ile düşürün, önbelleği yarıya indirmek için OLLAMA_KV_CACHE_TYPE=q8_0 ayarını yapın veya daha küçük bir kuantizasyon sürümü çekin.