Ollama Kuantizasyon Farkları: Q4, Q8 ve fp16

Ollama kuantizasyonunun getirdiği değişiklikler

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: çok daha küçük bir bellek kullanımı ve saniyede daha fazla token üretimi; karşılığında ise küçük bir doğruluk kaybı. Aşağıda, yirmi dakikanızı ayırıp sığmayacak bir dosyayı indirmeden önce, belirli bir modelin belirli bir makinedeki performansını nasıl tahmin edeceğiniz anlatılmaktadır.

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

Ollama nicemleme etiketi (q4_K_M gibi) nasıl okunur

Yerel modeller, llama.cpp'nin ağırlıkları diskte saklamak 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: bu, çoğu modelin yayınlandığı hassasiyet olan on altı bit kayan noktalı (floating point) halidir.

K, K-nicemlemeyi işaret eder. Ağırlıklar küçük bloklara gruplanır ve her blok, paketlenmiş değerlerin yanında kendi ölçeğini saklar. Tüm ağırlıkları 0.01 civarında olan bir blok ince bir ölçek alır. Tek bir büyük aykırı değer içeren bir blok ise kaba bir ölçek alır. Dört bitlik bir dosyanın kullanılabilir kalmasını sağlayan şey bu blok bazlı ölçeklerdir; aynı zamanda dört bitlik bir dosyanın 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 etiketinin, neredeyse aynı dosya boyutunda eski q4_0 etiketinden daha iyi çıktı üretmesinin nedeni budur.

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

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

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

Ağırlık başına bit değeri, dosya boyutunun kaynağıdır

Her boyut tahmini tek bir sayıdan başlar: formatın, dosya genelinde ortalaması alınmış şekilde ağırlık başına kaç bit harcadığı. llama.cpp, Llama 3.1 8B için ölçülen değerleri quantize dokümantasyonunda yayınlar 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
  }
]

Bu tablodaki sürpriz ikinci sütundur. Q4_K_M, ağırlık başına dört bit değildir. 4.89 bit değerini ölçer; çünkü blok ölçekleri ve yükseltilmiş tensörlerin her biri gerçek bir alan kaplar. Q8_0, aynı nedenden dolayı sekiz yerine 8.5 bit değerini ölçer. Ölçülen sayıyı kullanın; hesaplama, gerçek dosya boyutunun yüzde birkaç hata payı içinde kalacaktır:

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 paketi açmaz: kuantize edilmiş ağırlıklar bellekte aynı paketlenmiş biçimde durur ve her blok kullanıldıkça 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. Bazı yeni aileler bu düzenin dışına çıkar ve kütüphanede yalnızca bulut etiketleri olarak görünür; bu modellerin herhangi bir boyutta çekilecek bir sürümü yoktur. GLM 5.2'yi bir VPS üzerinde çalıştırmayı denediğinizde karşılaştığınız engel budur. Bunlar, Ağustos 2026 itibarıyla model sayfasındaki etiket listesinden okunan Qwen3 boyutlarıdır. Aşağıdaki her rakam, RAM'e yüklenmeden önce diskte kapladığı alandır; bunlardan iki veya üç tanesi küçük bir VPS root birimini dolduracaktır. Bu nedenle, etiketleri toplamaya başlamadan önce Ollama'nın indirdiği modelleri nereye kaydettiğini bilmek faydalı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, q4_K_M sürümünün ta kendisidir. Q4_K_M, kütüphanenin isteksizce sunduğu bir taviz değildir. Bu, upstream tarafından seçilen varsayılan değerdir; dolayısıyla henüz kendinizin test etmediği herhangi bir model için ilk adım olarak bunu kullanmak mantıklıdır. Qwen 3'ü bir VPS üzerinde çalıştırma sürecindeki etiket seçimlerini de aynı mantık 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 iki katı değil, yaklaşık yüzde yetmiş daha fazla maliyet getirir; çünkü embedding ve output tensörleri, modelin geri kalanıyla aynı oranda ölçeklenmez. fp16, q4_K_M'nin yaklaşık üç 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 modellere göz atın.

KV önbelleğinin ikinci ve bağlama bağlı bir maliyet olmasının nedeni

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 tek kelimelik bir istemde bile uzun bir pencere bellek tüketir.

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'a ulaşır ki bu miktar neredeyse kuantize edilmiş ağırlıklar kadar bellek kaplar 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 üzerinde yer almasıdır. Model yüklendikten sonra gerçek rakamı ollama ps içindeki SIZE sütunundan okuyun.

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

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Bir 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 gerçekten 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 kuantize eder: 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 pencereye sahip küçük bir makinede ö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, pencerenin kendisini ayrıntılı olarak ele alır. Önbellek ayrıca sunucu başına değil, eşzamanlı istek yuvası başına bir kez boyutlandırılır; bu nedenle Ollama'nın aynı anda iki istemi yanıtlamasına izin vermek, az önce hesapladığınız rakamı ikiye katlar. paralel yuva sayısı ve kuyruk sınırı seçimi konusunun arkasındaki aritmetik budur.

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

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

8 GB. q4_K_M formatındaki 4B bir model 2.6 GB yer kaplar ve uzun bir bağlam penceresi için yeterli alan bırakır. q4_K_M formatındaki 8B bir model, varsayılan 4k pencere ile ucu ucuna sığar. 8B model için 32k pencere kullanmayı planlamayın; çünkü 10 GB olan taban bellek kullanımı zaten kapasiteyi aşmaktadır.

16 GB. q4_K_M formatındaki 8B bir model, 16k veya 32k pencere ile rahatça çalışır. q4_K_M formatındaki 14B bir model 9.3 GB ağırlığa sahiptir ve orta ölçekli bir pencere ile sığar. q8_0 formatındaki 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 formatındaki 14B (16 GB) ve q4_K_M formatındaki 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.

Kuantizasyonun ilk bozduğu alanlar

Kuantizasyon hatası, modelin yaptığı işlere eşit oranda dağılmaz. Akıcılık en uzun süre korunan özelliktir; hasarın gözden kaçmasının temel nedeni de budur: kötü kuantize edilmiş bir model bile düzgün cümleler kurmaya devam eder. İlk bozulan şey hassasiyettir. 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 yürütme zincirleri. Tek bir yanlış parantezin araç çağrısının başarısız olmasına neden olduğu katı çıktı formatları.

Bu sonuncusu pratik testtir. Model, kodunuzun ayrıştırdığı JSON formatında çıktı üretmek zorunda kaldığında, kuantizasyon hasarı belirsiz bir şekilde kötüleşen bir metin yerine ayrıştırma hatası olarak ortaya çıkar; dolayısıyla bunu 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 kuantizasyonun etkilerini bir öğleden sonra içinde ortaya çıkaracaktır.

Dört bitin altına inildiğinde 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çindir ve alternatif, modeli hiç çalıştıramamak olduğunda gerçek bir seçenektir. Ancak bunlar varsayılan olarak tercih edilmemelidir. 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 kararı bu şekilde vermeye çalışmayın. Her ikisini de kendi hazırladığınız otuz istem (prompt) ile çalıştırın ve çıktıları inceleyin.

q8_0 veya fp16 ne zaman RAM'e değer

Bellek gerçekten boşta olduğunda ve görev küçük hataları cezalandırdığında q8_0 çekin: yapılandırılmış veri çıkarma, araç çağırma, derlenmesi gereken kod. Burada gözle görülür derecede daha zeki bir model değil, sigorta satın alıyorsunuz.

fp16 çekmek için sadece iki neden vardır. Ya modeli kendiniz kuantize ediyorsunuz ve kaynak dosyaya ihtiyacınız var ya da dört bitlik yapınızın ne kadar kayıp verdiğini anlamak için bir temel ölçüm yapıyorsunuz. fp16 üzerinden servis vermek, çoğu insanın kör testte ayırt edemeyeceği bir fark için q4_K_M'in üç 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 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ı RAM (rastgele erişimli bellek) miktarını kullanır ve daha büyük model daha fazla bilgiye sahiptir. Bunu körü körüne kabul etmek yerine kendi istemlerinizle test edin.

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

Çoğu VPS planında GPU bulunmaz, bu nedenle model ana bilgisayarın CPU'su üzerindeki sistem belleğinde çalışır. Üretim süreci aritmetik işlemlerle değil, bellek bant genişliği ile kısıtlanır; çünkü tek bir token üretmek, tüm ağırlıkların bir kez okunmasını gerektirir. Bu durum, satın aldığınız ç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 bilgisayar 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 rakamları 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ı yaklaşık iki katına çıkarır. Kuantizasyon, GPU'su olmayan bir sistemde kullanılabilecek en büyük hız artırma aracıdır. Elde ettiğiniz hızın kabul edilebilir olup olmadığı modele bağlıdır ve VPS üzerinde Nemotron 3.5 Lightning makalesi, belirli bir yapı, etiket ve RAM değeri için bu hesaplamayı detaylandırır. Bekleme süresinin diğer yarısı, modelin ne kadar yazmaya karar verdiğidir; saniyede on token hızında altı yüz tokenlık bir yanıt tam bir dakika sürer. Bu yüzden num_predict ile yanıtı sınırlandırmak, hassasiyeti bir adım daha düşürmekten genellikle daha fazla zaman kazandırır.

İstem (prompt) işleme süreci farklı davranır. Uzun bir istemi okumak, bant genişliği yerine işlem gücü (compute) ile sınırlıdır; bu nedenle ek çekirdekler burada yardımcı olurken, üretim hızına neredeyse hiçbir katkı sağlamaz. 4k boyutundaki bir istemi hızlıca işleyen ancak yavaş üretim yapan bir sistem normal davranıyor demektir.

Aritmetik hesaplamaların hiçbirini olduğu gibi kabul etmeyin. Kendi sisteminizde her kuantizasyon seviyesi için saniyedeki token sayısını ölçün ve kendi verilerinizin bu değerlerin önüne geçmesine izin verin.

Kendi modelinizi kuantize etme

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

FROM /path/to/my/model/f16

Ardından oluşturun 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 bulunmadığından, bu tür modelleri llama.cpp'nin kendi aracıyla kuantize etmeniz ve tamamlanmış GGUF dosyasını içe aktarmanız gerekir. Bu içe aktarma yönteminin kendine has bir riski vardır; sohbet şablonu uyumsuzluğu modelin anlamsız yanıtlar vermesine neden olabilir. Bu durum Ollama içine GGUF dosyası aktarma rehberinde açıklanmıştır. Oluşturma işleminin istediğiniz gibi gerçekleştiğini doğrulamak için ollama show çıktısındaki quantization satırını kontrol edin.

İşler yolunda gitmediğinde görecekleriniz

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

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ığı, bu nedenle modelin bir kısmının sistem belleğine yerleştirildiği anlamına gelir. Her token yavaş olan yarıyı beklemek zorunda kaldığından, hız yalnızca CPU hızına yakın bir seviyeye düşer. 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ğlamayacaktır.

Model yüklenirken sonlandırılıyor (killed). Çekirdek 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.

Siz hiçbir şeyi değiştirmediğiniz halde yanıtlar kötüleşti. Aynı modelin iki farklı sürümü, farklı etiketler altında ollama ls içinde yan yana bulunabilir. Eki olmayan ismi çeken bir betik, kütüphanenin o an işaret ettiği sürümü takip edecektir. Yapılandırma dosyanızdaki isme güvenmek yerine, istemcinizin talep ettiği tam etiket üzerinde 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. Bu, Ollama kütüphanesinin çoğu model için varsayılan etiket olarak sunduğu sürümdür; dolayısıyla ollama pull qwen3:8b ve ollama pull qwen3:8b-q4_K_M aynı dosyayı çeker. 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 hassasiyete 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. Bunun nedeni, her ağırlık bloğunun kendi ölçeğini saklaması ve en hassas tensörlerin daha geniş bir türe yükseltilmesidir. Q8_0, aynı nedenden dolayı 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, bayt cinsinden dosya boyutunu verir.

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

Ağırlıkları, KV önbelleğini ve ek 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 alt sınır 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. Pencereyi OLLAMA_CONTEXT_LENGTH ile küçültü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.