VPS'te Ollama ile Qwen 3.8 27B çalıştırma
Qwen 3.8 27B için doğru etiket `qwen3.8:27b`; Ollama v0.32.12 gerekir. CPU VPS'te RAM hesabını ve 8-64 GB planlarda neyin sığdığını görün.
GPU olmadan bir VPS üzerinde Qwen 3.8 27B çalıştırılabilir mi?
Qwen 3.8 27B'yi bir VPS üzerinde çalıştırmak için qwen3.8:27b etiketinin kullanılması gerekir. 21 October 2026 itibarıyla Ollama library bu etiketi yerel olarak çekilebilir durumda sunmaktadır: 27.3 billion parametre, Q4_K_M quantisation, Apache 2.0 licence, 256K context window ve yaklaşık 0.9 GB boyutunda vision projector içeren 18 GB'lık bir indirme. Ollama, Qwen 3.8 27B desteğini 14 August 2026 tarihinde yayımlanan v0.32.12 sürümünde ekledi. Bu nedenle daha eski bir kurulumun önce yükseltilmesi gerekir. 29 October 2026 itibarıyla latest stable release, 28 October 2026 tarihinde yayımlanan v0.40.13 sürümüdür.
Kısa cevap: 32 GB veya daha büyük bir VPS üzerinde çalıştırılabilir, ancak yavaş çalışır. Q4 düzeyinde 27B dense model, tek bir context token'ı saklanmadan önce yalnızca weights için yaklaşık 17 GB RAM gerektirir. Bu nedenle 8 GB ve 16 GB planlar tamamen elenir. Yaygın bir çift kanallı DDR4 VPS üzerinde üst sınır yaklaşık 3 token/saniyedir. Bu hız çoğu kişinin okuma hızından düşüktür.
Önceki 27B etiketleri hâlâ library içindedir: qwen3.6:27b ve qwen3.5:27b benzer boyutta Q4_K_M derlemeleridir. Qwen3.8-27B, Qwen3.6-27B mimarisini korur. İki sürümün resmi config dosyaları aynı layer düzenini gösterdiği için aşağıdaki bellek hesabı her ikisi için de geçerlidir. Herhangi bir komutu kopyalamadan önce güncel listeyi Ollama qwen3.8 tag sayfasında kontrol edin. Buradaki hesap, sürüm numarasından çok parameter count, bits per weight ve attention layout değerlerine bağlıdır.
Hangi Ollama etiketi çekilmeli ve nasıl kontrol edilir
Mevcut olmayan bir etiketi çekmeye çalışmak net bir hata mesajı döndürür, bu nedenle sunucu üzerinde karar vermek hızlıdır. Mevcut olan bir etiket bile yerel olarak çalıştırılamayabilir; kütüphanede listelenen ancak yalnızca Ollama bulutundan sunulan GLM 5.2 gibi durumlarda kullanıcıların yaşadığı sorun budur.
ollama --version
ollama pull qwen3.8:27b
ollama show qwen3.8:27bollama show komutu; mimariyi, parametre sayısını, bağlam uzunluğunu ve sahip olduğunuz etiket için nicemlemeyi (quantisation) yazdırır. Parametre satırı 27.3B ve nicemleme satırı Q4_K_M olarak görünüyorsa, bu kılavuzun hazırlandığı yapıya sahipsiniz demektir. Kütüphane ayrıca aynı ağırlıklar için daha yüksek hassasiyette qwen3.8:27b-q8_0 ve qwen3.8:27b-bf16, 27b-mtp varyantlarını ve etiketler sayfasında MLX olarak etiketlenen 27b-nvfp4, 27b-mxfp8, 27b-mlx ve 27b-mlx-bf16 etiketlerini de barındırır; bu format Linux VPS yerine Apple Silicon için hedeflenmiştir. qwen3.6 aksine, qwen3.8 girdisinde 35b-a3b etiketi bulunmaz. Bu MoE (uzman karışımı) modelleri hala qwen3.6 altında yer alır ve CPU üzerinde çok farklı davranır. Bunlar hakkında daha fazla bilgi aşağıdadır.
Parametre sayisi, agirlik basina bit ile carpilir
Bu grafiğin arkasındaki veriler
[
{
"label": "Q4_K_M",
"size_gb": 17,
"bits_per_weight": 4.98,
"notes": "published tag qwen3.8:27b, language model file"
},
{
"label": "Q5_K_M",
"size_gb": 19.5,
"bits_per_weight": 5.7,
"notes": "computed, no official library tag exists"
},
{
"label": "NVFP4",
"size_gb": 18,
"bits_per_weight": 5.27,
"notes": "published tag 27b-nvfp4, MLX build, one file including the vision encoder"
},
{
"label": "Q8_0",
"size_gb": 29,
"bits_per_weight": 8.5,
"notes": "published tag 27b-q8_0, language model file"
},
{
"label": "BF16",
"size_gb": 55,
"bits_per_weight": 16.1,
"notes": "published tag 27b-bf16, language model file"
}
]Formul tek satirdir. Agirliklarin bayt cinsinden boyutu = parametre sayisi * agirlik basina bit / 8. Tam 4 bitlik bir formatta 27.3 milyar parametre 13.7 GB olur. Yayimlanan Q4_K_M etiketindeki dil modeli dosyasi 17 GB boyutundadir. Bu da pratikte agirlik basina 4.98 bite karsilik gelir.
Bu fark bir hata degildir. K-quant formatlari her tensoru nominal bit genisliginde saklamaz. Sikistirma altinda kaliteyi en fazla kaybeden tensorlere daha fazla bit ayrilir. Yayimlanan qwen3.8:27b dosyasina ait Ollama tensor listesinde su tensorler Q6_K olarak gorulur: cikis katmani, feed-forward down projection katmanlarinin yaklasik yarisi, full-attention katmanlarinin yaklasik yarisindaki attention V projection katmanlari ve linear-attention katmanlarindaki fused QKV projection katmanlarinin yaklasik yarisi. Kucuk normalizasyon tensorleri tam 32-bit hassasiyette tutulur. Token embedding, attention Q ve K projection katmanlari ile feed-forward gate ve up projection katmanlari, modelin buyuk bolumunde oldugu gibi Q4_K olarak kalir. Formatin adinda belirtilen deger bir ortalamadir ve ortalama yaklasik 5 bite denk gelir. Ayni etki olcegin diger ucunda da gorulur: BF16 icin 55 GB, sabit 16 bit yerine agirlik basina 16.1 bite karsilik gelir. Bu durumda token embedding diger her sey gibi BF16'dur. Kucuk farkin nedeni dosya metadata'si, 32-bit olarak tutulan normalizasyon tensorleri ve listelenen boyutun en yakin gigabayta yuvarlanmasidir.
Butun etiket icin bellek ayirin; yalnizca dil modeli dosyasini hesaba katmayin. qwen3.8:27b iceren her GGUF etiketi ayrica yaklasik 0.9 GB boyutunda bir vision projector ship eder. Q4_K_M etiketinin 18 GB olarak listelenmesinin nedeni budur.
Resmi qwen3.8 kutuphane girdisinde Q5_K_M icin yayimlanmis bir etiket yoktur. Bu nedenle 19.5 GB satiri olculmus bir deger yerine bu format icin yaygin olan agirlik basina 5.7 bit kullanilarak hesaplanmistir. Q8_0, Q4 boyutunu neredeyse ikiye katlayarak 29 GB olur. Yalnizca CPU kullanilan bir sistemde bu iki katina cikis, token basina bellek trafigini de iki katina cikarir. Bu nedenle saniyedeki token sayisi da yaklasik yarıya iner. Yalnizca bu nedenle bile Q4_K_M burada dogru varsayilandir. Bu kararın bellek boyutu yerine kalite etkisini incelemek isterseniz, Q4, Q8 ve fp16 formatlarinin daha ayrintili karsilastirmasi cikisin gercekte hangi noktada bozulmaya basladigini gosterir.
Bağlam büyüdükçe KV önbelleğinin maliyeti
Ağırlıklar sabit bir maliyete sahiptir. KV önbelleği (anahtar ve değer önbelleği; modelin daha önce gördüğü her token için tuttuğu dikkat durumu), bağlam uzunluğuyla doğru orantılı olarak büyür ve çoğu kullanıcının RAM kapasitesinin tükenmesine asıl sebep olan yer burasıdır.
Bu grafiğin arkasındaki veriler
[
{
"label": "4k tokens",
"kv_f16_gb": 0.25,
"kv_q8_gb": 0.13
},
{
"label": "8k tokens",
"kv_f16_gb": 0.5,
"kv_q8_gb": 0.25
},
{
"label": "16k tokens",
"kv_f16_gb": 1,
"kv_q8_gb": 0.5
},
{
"label": "32k tokens",
"kv_f16_gb": 2,
"kv_q8_gb": 1
},
{
"label": "64k tokens",
"kv_f16_gb": 4,
"kv_q8_gb": 2
},
{
"label": "128k tokens",
"kv_f16_gb": 8,
"kv_q8_gb": 4
}
]Bu rakamlar modelin kendi yapılandırma dosyasından gelmektedir. Qwen3.8-27B, tıpkı Qwen3.6-27B gibi hibrit dikkat (hybrid-attention) yapısına sahip bir modeldir. 64 katmanından sadece 16'sı tam dikkat (full attention) kullanır ve her token ile büyüyen bir önbellek tutar; bu katmanlar GQA (grouped-query attention) altında 4 anahtar/değer başlığına ve 256'lık bir başlık boyutuna sahiptir. Diğer 48 katman ise doğrusal dikkat (Gated DeltaNet) kullanır ve bunun yerine sabit boyutlu bir durum tutar; benim hesaplamalarıma göre bu, bağlam ne kadar uzarsa uzasın konuşma yuvası başına yaklaşık 150 MB civarındadır. Bu da f16 formatında token başına 64 KiB'a denk gelir; yani 32k token için 2 GB ve 128k token için 8 GB eder. Benim hesaplamalarıma güvenmek yerine kendi sisteminizde doğrulama yapın. Modeli yükleyin ve ağırlıklar, önbellek ve ek yükü tek bir rakam olarak raporlayan ollama ps çıktısındaki SIZE sütununu okuyun.
Model kartında belirtilen 256K bağlam kapasitesi bu mimaride ulaşılabilir durumdadır ancak bedelsiz değildir. f16 formatında bu alanı doldurmak, ağırlıklar için halihazırda 17 GB harcamış bir makinede, ağırlıkların üzerine yaklaşık 16 GB ek önbellek maliyeti getirir. Ollama, varsayılan olarak size tam pencereyi sunmaz. Bağlam uzunluğu belgeleri, varsayılan değeri VRAM miktarına göre belirler: 24 GiB altı için 4k token, 24 ile 48 GiB arası için 32k token ve 48 GiB ve üzeri için 256k token. Yalnızca CPU kullanan bir VPS'in hiç VRAM'i yoktur, bu yüzden 4k seviyesinde kalır; bunu OLLAMA_CONTEXT_LENGTH ile bilinçli olarak artırmanız gerekir. Sunucu genelindeki bu değişken tek kontrol mekanizması değildir; bireysel istek üzerinde num_ctx ayarı yapmak, diğer her şey için düşük bir varsayılan değer korurken, tek bir uzun işin daha geniş bir pencereye sahip olmasını sağlar. Değeri kademeli olarak artırın ve her değişiklikten sonra ollama ps çıktısını kontrol edin.
İki ayar önbellek kullanımını düşük tutar. OLLAMA_KV_CACHE_TYPE=q8_0, önbelleği 16 bit yerine 8 bit olarak saklar ve 32k token için gereken alanı 2 GB seviyesinden 1 GB seviyesine düşürür. Bu işlem flash attention gerektirir, bu nedenle OLLAMA_FLASH_ATTENTION=1 ayarını da yapın ve ayarın uygulandığını varsaymak yerine ollama ps çıktısındaki düşüşü doğrulayın. Daha önce önbellek türüne dokunmadıysanız, Ollama KV önbelleği için q8_0 ile f16 karşılaştırmalı kılavuzu, her iki değişkenin ayarlanmasını ve öncesi/sonrası rakamlarının okunmasını kapsar. OLLAMA_NUM_PARALLEL=1 de aynı derecede önemlidir. Ollama aynı anda birden fazla isteğe hizmet verebilir ve her yuva kendi bağlam dilimine sahiptir; bu nedenle paralelliği artırmak, bütçelediğiniz önbelleği sessizce katlar. Mevcut varsayılan değer zaten 1'dir ve aşağıdaki geçersiz kılma (override) bunu bu seviyede sabitler. Eğer bu sunucuyu birden fazla kişi kullanacaksa, sorun tam olarak bu çarpma işleminden kaynaklanır ve self-hosted bir modelin hizmet verebileceği eşzamanlı kullanıcı sayısı, çekirdek sayısından çok daha önce önbellek yuvaları ve kuyruk derinliği ile belirlenir.
8, 16, 32 ve 64 GB RAM'e neler sığar
Bu grafiğin arkasındaki veriler
[
{
"label": "8 GB",
"q4_max_ctx_ktok": 0,
"q8_max_ctx_ktok": 0,
"notes": "Weights alone exceed the box. Use a 4b or 8b model."
},
{
"label": "16 GB",
"q4_max_ctx_ktok": 0,
"q8_max_ctx_ktok": 0,
"notes": "17 GB of weights does not fit in 16 GB of RAM."
},
{
"label": "32 GB",
"q4_max_ctx_ktok": 128,
"q8_max_ctx_ktok": null,
"notes": "Q4 fits with room for long context. Q8 weights fit, but usable context needs a measured total memory budget."
},
{
"label": "64 GB",
"q4_max_ctx_ktok": 256,
"q8_max_ctx_ktok": 256,
"notes": "Both fit with the full 256K window."
}
]İki sayı, weights ve vision projector ile birlikte, f16 cache kullanılırken, işletim sistemi için yaklaşık 1.5 GB ve küçük bir ek pay bırakılan headless Linux VPS üzerinde sığan context miktarını bin token cinsinden gösterir. Sıfır, weights dosyalarının kendisinin sığmadığı ve bu nedenle hiçbir context miktarının sığmayacağı anlamına gelir; null ise weights dosyalarının sığdığını ancak ilgili katman için kullanılabilir bir context değerinin doğrulanmadığını belirtir.
8 GB ve 16 GB seçeneklerinde sonuç belirsiz değildir. 17 GB weights, 16 GB RAM'e sığmaz ve hiçbir context ayarı bunu değiştirmez. Swap eklemek de sorunu çözmez. Ollama, GGUF dosyasını memory-map eder. Resident sayfalar RAM kapasitesini aştığında kernel bu sayfaları diske taşımaya ve yeniden okumaya başlar. Bu durumda her token için diskten gigabaytlarca veri okunur. Sistem yüksek iowait değerlerinde çalışır ve saniyede bir tokenın oldukça altında üretim yapar.
32 GB başlangıç noktasıdır. Weights 17 GB yer kaplar. Vision projector yaklaşık 0.9 GB ekler. Yaklaşık 12.5 GB kalır. Bu miktar, pay bırakıldığında yaklaşık 128k token f16 context için yeterlidir. 29 GB boyutundaki Q8_0 weights, 32 GB içine sığar. Ancak kullanılabilir context miktarı vision projector, cache, işletim sistemi ve runtime belleğine de bağlıdır. Q8'in bu katmanda çalışacağını varsaymadan önce kendi sisteminizdeki toplam bellek kullanımını kontrol edin.
64 GB daha rahat bir kapasite sağlar. Q4, 256k tokenlık tam pencere için alan bırakır. Q8_0 weights de arkasında 256k tokenlık tam context ile sığar. Q8 kullanmak için 64 GB RAM satın almadan önce ne satın aldığınızı netleştirin: zaten yavaş olan bir makinede, hızın yarısına karşılık biraz daha iyi çıktı. Q4, 32 GB planında zaten 128k tokena ulaşır. Neredeyse herkes için daha iyi tercih budur.
Bir VPS üzerinde CPU çıkarımı ne kadar hızlıdır?
Yoğun bir modelden tek bir token üretmek, her ağırlığın bellekten bir kez okunması anlamına gelir. Bazılarının değil, tamamının. Dolayısıyla hız sınırı çekirdek sayınız değil, bellek bant genişliğinin ağırlıkların toplam boyutuna bölümüdür. Q4 nicemlemesinde bu, token başına 17 GB bellek trafiği demektir.
Bu grafiğin arkasındaki veriler
[
{
"label": "DDR4-2666, 2 channel",
"mem_bandwidth_gb_s": 42.6,
"ceiling_tok_s": 2.5
},
{
"label": "DDR4-3200, 2 channel",
"mem_bandwidth_gb_s": 51.2,
"ceiling_tok_s": 3
},
{
"label": "DDR5-4800, 2 channel",
"mem_bandwidth_gb_s": 76.8,
"ceiling_tok_s": 4.5
},
{
"label": "DDR4-3200, 8 channel",
"mem_bandwidth_gb_s": 204.8,
"ceiling_tok_s": 12
},
{
"label": "DDR5-4800, 12 channel",
"mem_bandwidth_gb_s": 460.8,
"ceiling_tok_s": 27.1
}
]Bunlar ölçüm değil, teorik üst sınırlardır. Bellek gecikmesi ve kusurlu ön getirme (prefetching) nedeniyle teorik zirveye asla ulaşılamadığından, gerçek çıktı gösterilen değerin yaklaşık yüzde 50 ila 70'i civarında gerçekleşir. İki kanallı DDR4-3200 bir VPS, saniyede 3 token üst sınırına sahiptir, bu yüzden yaklaşık 2 token beklenmelidir. İki kanallı DDR5-4800 bir makine ise 4.5 üst sınırına sahiptir, bu yüzden yaklaşık 3 token beklenmelidir.
Büyük sunucu seçenekleri bir uyarı ile gelir. On iki kanallı bir EPYC platformu 460.8 GB/s bant genişliğine ve saniyede 27.1 token üst sınırına sahiptir, ancak tüm bir EPYC işlemciyi kiralamazsınız. Bellek bant genişliği, o makinedeki her kiracı tarafından paylaşılan sunucu genelinde bir kaynaktır; dolayısıyla 8 vCPU'luk bir dilim, on iki kanallı özel bir bant genişliği ile gelmez. GPU odaklı kılavuzlar bu detayı tamamen atlar; aynı vCPU sayısına sahip iki VPS planının aynı model üzerinde üç kat fark göstermesinin nedeni budur.
Daha fazla vCPU, aynı nedenden dolayı kısa sürede faydasız hale gelir. Çekirdekler veriyi bellek denetleyicisinin iletebileceğinden daha hızlı talep ettiğinde, ek iş parçacıkları (threads) yalnızca zamanlama yükü ekler, başka bir katkı sağlamaz. Ollama'nın iş parçacığı sayısı için sunucu genelinde bir ortam değişkeni yoktur; bu nedenle num_thread değerini istek içindeki options kısmında fiziksel çekirdek sayınıza ayarlayın, ölçüm yapın ve ardından bu sayının yarısını deneyin. Birçok paylaşımlı planda daha düşük ayar daha hızlıdır.
İstem işleme (prompt processing) farklı davranır. İlk token görünmeden önce girdinizin üzerinden geçilen "prefill" aşaması, bant genişliği sınırlı değil işlem gücü sınırlıdır, bu nedenle çekirdek sayısıyla ölçeklenir. Bunun pratik etkisi, büyük bir istemde çıktı başlamadan önce uzun bir duraklama ve ardından yukarıda belirtilen yavaş ve sabit hızdır. Her istek için bir prompt eval rate ve bir eval rate yazdıran --verbose ile her iki aşamayı ayrı ayrı zamanlayın.
Eğer yoğun 27B modeli çok yavaşsa, CPU kullanımından vazgeçmeden önce qwen3.6:35b-a3b etiketlerine göz atın. Bunlar, 27,3 milyar parametrenin tamamı yerine token başına yaklaşık 3 milyar parametreyi etkinleştirir; böylece diskteki dosya daha büyük olsa bile token başına bellek trafiği yaklaşık on kat azalır. Hız kazanmak için RAM kullanımından feragat edersiniz. Çalışma zamanı seçimi de burada önemlidir ve Ollama ve llama.cpp aynı temel çıkarım kodu üzerinde farklı CPU ayar kontrolleri sunar.
Bunun yerine GPU saatlik ne zaman kiralanmalı
Bu grafiğin arkasındaki veriler
[
{
"label": "L40S, 48 GB",
"mem_bandwidth_gb_s": 864,
"ceiling_tok_s": 51
},
{
"label": "RTX 4090, 24 GB",
"mem_bandwidth_gb_s": 1008,
"ceiling_tok_s": 59
},
{
"label": "A100, 80 GB",
"mem_bandwidth_gb_s": 2039,
"ceiling_tok_s": 120
},
{
"label": "H100 SXM, 80 GB",
"mem_bandwidth_gb_s": 3350,
"ceiling_tok_s": 197
}
]Yayınlanmış GPU bellek bant genişliğine aynı formül uygulandığında farklı bir sonuç elde edilir. 24 GB tüketici ekran kartında bu ağırlıklar için üst sınır saniyede 59 token değerindedir. Güncel bir veri merkezi ekran kartı ise 197 değerine ulaşır. Bu fark, iş parçacığı sayılarını ayarlayarak kapatılamaz. Ekran kartı belleği 1008 GB/s hızında çalışırken VPS tarafında bu değer onlarca GB/s düzeyindedir.
Bu nedenle sınır, tercihe göre değil iş yüküne göre belirlenmelidir. İş asenkron yürütülüyorsa ve sonucu bekleyen kimse yoksa CPU üzerinde çıkarım doğru seçenektir: bir belge yığınını gece boyunca özetlemek veya siz uyurken çalışan gecelik bir sınıflandırma işi gibi. Bir kişi çıktıyı bekliyorsa veya istekler sunucunuzun bunları tamamlama hızından daha hızlı geliyorsa GPU kiralanmalıdır. CPU çalışma zamanları aynı anda yalnızca bir istekle sınırlı değildir: llama.cpp sunucusu CPU ve GPU üzerinde paralel çözümleme ile sürekli toplu işlemeyi belgeler; Ollama da daha fazla önbellek kullanımı karşılığında paralel isteklere hizmet verebilir. Belirleyici olan, ölçülen hizmet verme hızınız ile istek geliş hızınızdır. Bu nedenle kendi sunucunuzda gerçeğe uygun bir toplu işlemi zamanlayın. İstekler bu hızdan daha hızlı gelmeye başladığında kuyruk büyür.
Maliyet karşılaştırması göründüğü kadar açık değildir. 64 GB VPS, model yüklü olsun veya olmasın ayın her saati için ücretlendirilir. Saatlik GPU kiralama hizmetinde ise işlem ücretleri, GPU durduktan sonra da devam edebilen depolama ücretlerinden ayrılır. Gerçek kullanımınız günde iki saatse kiralanan GPU hem daha hızlı hem de daha ucuz olabilir. Önce kullanım oranınızı hesaplayın, ardından maliyeti karşılaştırın. GPU içeren bir VPS seçme bölümünde instance üzerinde kontrol edilmesi gerekenler ele alınır. GPU üzerinde eşzamanlı isteklere hizmet verdiğinizde vLLM, Ollama'nın önüne geçer bölümünde ise isteklerin düzgün biçimde toplu işlenmesinin sağladığı avantaj açıklanır.
İnsanların unuttuğu üçüncü bir seçenek daha vardır. Toplu işler için 27B modelini CPU üzerinde tutun ve etkileşimli yolu barındırılan bir API modeliyle destekleyin. Tek bir modelin her iki iş yüküne de hizmet vermesi gerekmez.
Ollama'yı kurma ve kendi sisteminizi ölçme
Kurulum betiği resmî betiktir ve özel bir ollama kullanıcısı olarak çalışan bir systemd servisi oluşturur.
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -gollama --version çıktısında, Qwen 3.8 27B desteği sunan ilk sürüm olan 0.32.12 veya daha yeni bir sürüm görünmelidir. Herhangi bir şeyi çekmeden önce free -g değerini kontrol edin. Bu değer GiB cinsinden raporlanır. Bu nedenle 32 GB RAM olarak tanıtılan bir plan, total sütununda yaklaşık 29 gösterebilir. Kullanılabilir belleği yukarıdaki ağırlıklar ve önbellek bütçesiyle karşılaştırın.
Çalışma zamanı seçeneklerini shell ortamınızda tanımlamak yerine bir systemd override dosyasında ayarlayın. Model servis içinde çalışır. Bu nedenle etkileşimli ortamınızı görmez.
sudo systemctl edit ollama[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"sudo systemctl restart ollama
ollama pull qwen3.8:27b
ollama run qwen3.8:27b --verbose "Name two Linux distributions."--verbose çıktısı, aradığınız ölçümdür. eval rate, üretim sırasında saniye başına işlenen token sayısıdır. prompt eval rate, prefill hızını gösterir. load duration, ağırlıkların diskten okunmasının ne kadar sürdüğünü gösterir. Bu nedenle OLLAMA_KEEP_ALIVE=60m ayarlanmıştır: CPU üzerinde 17 GB veriyi her istekte diskten yeniden yüklemek, isteğin kendisinden daha uzun sürer. Varsayılan boşta kalma zaman aşımı beş dakikadır. Bu süre, öğeler arasında boşluk bulunan bir batch kuyruğunun bu yükleme maliyetini tekrar tekrar ödemesine neden olacak kadar kısadır. Modeli bellekte tutma seçenekleri, hem istek başına kullanılan keep_alive alanını hem de ayarın yeniden başlatma sonrasında korunmasını kapsar.
Model yüklenirken bellek kullanımını ikinci bir terminalden kontrol edin.
ollama psSIZE sütunu, KV cache dahil gerçek bellek kullanımını gösterir. Bu değer, ağırlıkların toplamı ile vision projector boyutuna ve KV tablosunda seçtiğiniz context length satırına yakın olmalıdır. 8192 token ve 8-bit cache kullanıldığında, cache'in büyüyen bölümü yaklaşık çeyrek gigabayttır. Bu değer, cache f16 olarak kalsaydı 0.5 GB olurdu. Buna sabit linear-attention state de eklenir. PROCESSOR sütununda 100% CPU yazmalıdır. Farklı bir değer görünüyorsa GPU'yu başka bir süreç kullanıyordur. Bu durumda bu kılavuzdaki hız değerleri sisteminizi açıklamaz.
Hata modları ve göreceğiniz kesin dizeler
Model yüklenmeyi reddediyor. Ollama, her iki değeri de içeren model requires more system memory (18.6 GiB) than is available (15.2 GiB) biçiminde bir satır yazdırır. Bu, iyi bir hata türüdür çünkü Ollama, çekirdeğin durumu çözmesini beklemek yerine bellek ayırmadan önce kontrolü yapmıştır. Bağlam uzunluğunu (context length) düşürün, daha küçük bir etikete geçin veya daha yüksek bir plana yükseltin.
İşlem, yanıtın ortasında kayboluyor. İstemci yararlı bir bilgi göstermez ve journalctl -u ollama -n 50 servisin yeniden başladığını gösterir. dmesg -T | tail komutunu çalıştırın; Out of memory: Killed process ... (ollama) ifadesini içeren bir satır, çekirdek OOM killer'ın süreci sonlandırdığını belirtir. Bu durum, ön yükleme kontrolü başarılı olmasına rağmen uzun bir görüşme sırasında önbellek tahmini aştığında gerçekleşir. Bağlam uzunluğunu azaltın.
Çekme (pull) işlemi hemen başarısız oluyor. Error: pull model manifest: file does not exist, etiketin kütüphanede bulunmadığı anlamına gelir. Henüz yayınlanmamış bir sürüm numarası tam olarak bu hatayı üretir; etiketteki herhangi bir yazım hatası da aynı sonucu verir. qwen3.8:27b gerçek bir etikettir, bu nedenle eğer bu etiket başarısız oluyorsa önce yazım hatası olup olmadığını kontrol edin. Ağınızı suçlamadan önce kütüphane sayfasından etiketi doğrulayın; eğer gerçek bir etiket çekiliyor ancak çalışmıyorsa ollama --version değerini 0.32.12 ile karşılaştırın.
Her şey çalışıyor ancak dayanılmaz derecede yavaş. Yeterli RAM'e sahip bir makinede saniyede bir token'ın altında hız, hesaplama gücünden ziyade sayfalama (paging) sorununa işaret eder. Üretim sırasında vmstat 1 komutunu çalıştırın. Sıfır olmayan bir si veya so sütunu, çekirdeğin swap yaptığını gösterir; çözüm, bağlamı azaltmak veya daha az model yüklemektir. Swap etkinliği olmadan sürekli yüksek wa değeri, belleğe eşlenmiş ağırlıkların diskten tekrar okunduğu anlamına gelir; bu da modellerin aslında belleğe sığmadığını gösterir.
İlk token 30 saniye sürüyor ve ardından çıktı hızlanıyor. Bu, prefill aşamasıdır ve normaldir. Uzun bir sistem istemi (system prompt), önbelleği ıskalayan her istekte maliyet oluşturur; bu nedenle başka bir ayar yapmadan önce sistem istemini kısaltın.
CPU-only 27B modeli gerçekte hangi işlerde işe yarar
Beklentiler, umuda göre değil, sayılara göre belirlenmelidir. Saniyede iki ila dört token hızında, 500 token uzunluğundaki bir yanıt iki ila dört dakika sürer. Bu hız sohbet için kullanılamaz, ancak kuyruk tabanlı işler için tamamen uygundur. Yanıt vermeden önce düşünen bir model bu hesabı daha da kötüleştirir; çünkü gizli akıl yürütme token'ları da yanıtla aynı düşük hızda üretilir. Bu nedenle akıl yürütme çabasının düzeyini işe uygun belirlemek, modeli değiştirmeden yanıt süresini kısaltan az sayıdaki yöntemden biridir. Belgelerin özetlenmesi, toplu etiketleme, dosya kuyruğundan alan çıkarma ve gözetimsiz kod incelemesi bu hızı tolere eder; çünkü hiç kimse yanıtı beklemiyordur. Kodlama desteği tam bu sınırda yer alır. Bu nedenle bir kodlama aracısını barındırdığınız modele yönlendirmek, commit mesajları ve test iskeletleri gibi arka plan işleri için yararlıdır; başında oturup beklediğiniz satır içi öneriler için değil.
Asıl gerekçe gizliliktir. Model, kiraladığınız ve denetlediğiniz donanım üzerinde çalışır. Hiçbir istek sunucudan çıkmaz ve token başına ücret ödemezsiniz. Saniyede üç token hızında bile bu, düzenlemeye tabi veriler için önemli bir avantajdır. Ancak alternatifi gerçekçi biçimde değerlendirilmelidir: frontier ölçeğindeki bir modeli self-host etmek, büyüklük sırasıyla daha fazla donanım gerektirir. CPU üzerinde çalışan 27B model, çıktının hâlâ okunmaya değer olduğu bu eğrinin en düşük maliyetli noktasıdır.
Bunlardan herhangi birini ölçmek için gerçek ve yapılandırılmış girdilere ihtiyaç vardır. Çoğu herkese açık veri API'si ise throughput ölçülebilmeden önce hesap açılmasını ister. Strasmore'un demo şeması (bunu biz çalıştırıyoruz), ABD hisse senedi ve opsiyon verileri üzerinde anahtar veya kayıt gerektirmeden salt okunur SQL kullanımını belgeler ve veritabanı nitelemeli tablo adlarını kullanır: https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM global_markets.delayed_stocks_minute_aggs LIMIT 5. Demo sınırları çağrı başına 500 satır ve 20 saniyedir. Veriler 1 January 2025 tarihinden itibaren sunulur. Bu kapsam, saniyede iki token hızında çalışan bir sistemin tüketeceğinden fazlasını rahatlıkla karşılar. Tüm sütun listesi https://ai.strasmore.com/api/demo/schema adresindedir.
İlk Ollama kurulumunuzsa, Ollama'yı bir VPS üzerinde çalıştırmaya ilişkin eksiksiz rehber, bu kılavuzda önceden var olduğu varsayılan servis kurulumunu, HTTP API'sini ve firewall kurallarını açıklar. 11434 numaralı portu internete açmayın. Ollama'nın yerel API'si kimlik doğrulaması gerektirmez. Bu nedenle porta erişebilen herkes modelinizi kullanabilir.
FAQ
Ollama'da Qwen 3.8 27B modeli var mı?
Evet. 21 October 2026 itibarıyla Ollama kütüphanesinde bir qwen3.8 girdisi bulunur. qwen3.8:27b (latest olarak da etiketlenir), vision projector içeren ve 256K context window kullanan 27.3 milyar parametreli dense modelin 18 GB Q4_K_M derlemesidir. Model yerel olarak çalışır ve Ollama v0.32.12 veya sonraki bir sürümü gerektirir. Eski qwen3.6:27b ve qwen3.5:27b etiketleri de listelenmeye devam eder. Güncel liste için https://ollama.com/library/qwen3.8/tags kontrol edilmelidir. Var olmayan bir etiket kullanılırsa Error: pull model manifest: file does not exist hatası alınır.
VPS üzerinde Qwen 27B modeli çalıştırmak için ne kadar RAM gerekir?
Q4_K_M için pratik minimum 32 GB'tır. Ağırlıklar 17 GB yer kaplar. Vision projector yaklaşık 0.9 GB ekler. İşletim sistemi yaklaşık 1.5 GB gerektirir. KV cache, f16 kullanılırken context değerinin her 16,000 token'ı için yaklaşık 1 GB ekler; bunun nedeni modelin 64 katmanından yalnızca 16'sının büyüyen bir cache tutmasıdır. 16 GB'lık bir plan ağırlıkları tek başına bile barındıramaz. Swap yardımcı olmaz; dosya memory-mapped olduğu için kernel her token'da dosyayı diskten yeniden okur. 64 GB, 29 GB boyutundaki Q8_0 ağırlıklarıyla bile 256K'lık pencerenin tamamı için yeterli alan sağlar.
27B model CPU üzerinde saniyede kaç token üretir?
Bellek bant genişliğini ağırlıkların boyutuna bölün. Ardından elde edilen değerin yüzde 50 ila 70'ini alın. İki kanallı DDR4-3200 VPS için teorik üst sınır 3 token/saniye civarındadır ve pratikte yaklaşık 2 token/saniye verir. İki kanallı DDR5-4800 sistem için teorik üst sınır 4.5 civarındadır ve pratikte yaklaşık 3 token/saniye verir. Daha fazla kanallı sunucu platformları kâğıt üzerinde çok daha iyi görünür. Ancak bellek bant genişliği host üzerindeki tüm tenant'lar arasında paylaşılır. Bu nedenle kendi sisteminizde ollama run qwen3.8:27b --verbose ile ölçüm yapın ve eval rate satırını okuyun.
Yalnızca CPU kullanan bir VPS'te Q4 mü, Q8 mi kullanılmalı?
Neredeyse her durumda Q4_K_M kullanılmalıdır. Q8_0 29 GB, Q4_K_M ise 17 GB boyutundadır. Bu nedenle Q8_0 ağırlıkları 32 GB RAM'e sığar. Ancak projector, cache, işletim sistemi ve runtime için çok az boş alan kalır. 64 GB, uzun context değerleri için yeterli alan sağlar. Q8_0 token başına neredeyse iki kat fazla bellek taşır. Bu da saniyedeki token sayısını yaklaşık yarıya indirir. 27B modelde Q4_K_M ile Q8_0 arasındaki kalite farkı çoğu görev için küçüktür. RAM'i daha uzun bir context için kullanmak daha uygundur. Çünkü bu tercih modelin ifadelerini değil, gerçekleştirebileceği işlemleri değiştirir.
Büyük RAM'e sahip bir VPS yerine GPU kiralamak ne zaman daha ucuzdur?
Kullanım yoğunluğu düşük olduğunda veya bir kullanıcı yanıt beklediğinde. 24 GB belleğe sahip bir GPU, bu ağırlıklarla teorik olarak yaklaşık 59 token/saniyelik üst sınıra ulaşabilir. Tipik bir VPS'te bu değer yaklaşık 2 veya 3 token/saniyedir. Saatlik GPU işlem ücretleri instance durdurulduğunda sona erer. Ancak kalıcı depolama yine ücretlendirilebilir. 64 GB RAM'e sahip bir VPS, model yüklü olsun veya olmasın tüm ay boyunca ücretlendirilir. Gerçekte günde kaç saat token ürettiğinizi hesaplayın. Başabaş noktası kiralama ücretlerine, runtime maliyetlerine ve kalıcı depolama ücretlerine bağlıdır. Sürekli yürütülen düşük öncelikli batch işleri, her zaman açık VPS'in avantajlı olduğu kullanım alanıdır.