VPS'te Ollama ile Qwen 3.8 27B Çalıştırma

GPU Olmadan Bir VPS Üzerinde Qwen 3.8 27B Çalıştırılabilir mi?

Qwen 3.8 27B çalıştırmak için önce mevcut bir model etiketi gerekir. 4 August 2026 itibarıyla Ollama library içinde hiç qwen3.8 girdisi bulunmamaktadır. Yayınlanmış en yakın 27B etiketi qwen3.6:27b olarak görünür: 27.8 milyar parametre, Q4_K_M quantisation ve Apache 2.0 licence. Aşağıdaki tüm komutlarda ve sayılarda, 27 July 2026 tarihinde yayımlanan Ollama v0.32.5 üzerinde bu etiket kullanılır.

Kısa yanıt: 32 GB veya daha büyük bir VPS üzerinde çalıştırılabilir, ancak yavaş çalışır. Q4 kullanan 27B dense model, context içindeki tek bir token bile saklanmadan önce yalnızca weight değerleri için yaklaşık 17 GB RAM gerektirir. Bu nedenle 8 GB ve 16 GB planlar tamamen yetersiz kalır. Yaygın iki kanallı DDR4 VPS yapılandırmalarında üst sınır yaklaşık 3 token/saniyedir. Bu hız, çoğu kişinin okuma hızından düşüktür.

3.8 nereden geliyor? Büyük olasılıkla parametre sayısından. qwen3.6:27b için Ollama sayfasında 27.8B parametre bildirilmektedir. 27.8 değeri daha sonra kolayca 3.8 olarak hatırlanabilir. Ayrıca önceki sürümdeki aynı Q4_K_M derlemesi olan bir qwen3.5:27b de vardır. Herhangi bir komutu kopyalamadan önce canlı listeyi Ollama qwen3.6 etiket sayfasından kontrol edin. Daha sonra gerçek bir qwen3.8 yayımlanırsa bu hesaplama yine geçerli olur. Bunun nedeni, hesaplamanın sürüm numarasına değil parametre sayısına ve weight başına bit sayısına bağlı olmasıdır.

Hangi Ollama tag'inin çekileceği ve nasıl kontrol edileceği

Mevcut olmayan bir tag'i çekmeye çalışmak açık bir hata verir. Bu nedenle hangi tag'in kullanılacağı doğrudan sunucu üzerinde hızlıca belirlenebilir. Mevcut olan bir tag yerel olarak yine de çalıştırılamayabilir. Kütüphanede listelenen ancak yalnızca Ollama cloud üzerinden sunulan GLM 5.2 kullanımında sorun genellikle burada ortaya çıkar.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show gerçekten sahip olduğunuz tag için mimariyi, parametre sayısını, context uzunluğunu ve quantisation bilgisini gösterir. Parametre satırında 27.8B, quantisation satırında ise Q4_K_M yazıyorsa bu kılavuzun temel aldığı build kullanılıyor demektir. Kütüphanede aynı ağırlıklar için daha yüksek precision sunan qwen3.6:27b-q8_0 ve qwen3.6:27b-bf16 tag'leri de bulunur. Ayrıca CPU üzerinde çok farklı davranan MoE (mixture of experts) modelleri için 35b-a3b tag'lerinden oluşan bir grup vardır. Bunlar aşağıda daha ayrıntılı olarak ele alınır.

Ağırlık başına bayt ile parametre sayısının çarpımı

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

Formül tek satırdan oluşur. Ağırlıkların bayt cinsinden boyutu = parametre sayısı * ağırlık başına bit / 8. Tam olarak 4 bit kullanıldığında 27.8 milyar parametre 13.9 GB olur. Yayınlanan Q4_K_M etiketi 17 GB boyutundadır. Bu da pratikte ağırlık başına 4.89 bite karşılık gelir.

Bu fark hata değildir. K-quant biçimleri her tensoru nominal bit genişliğinde saklamaz. Sıkıştırmadan en fazla kalite kaybeden tensorlar 5 veya 6 bitte tutulur. Token embedding ve output katmanları da genellikle Q6_K veya Q8_0 olarak bırakılır. Biçimin adı ortalama değeri ifade eder. Bu ortalama yaklaşık 4.9 bite ulaşır. Aynı etki ölçeğin diğer ucunda da görülür: BF16 için 56 GB, sabit 16 yerine ağırlık başına 16.1 bite karşılık gelir. Bunun nedeni dosyanın metadata ve tam hassasiyetli bir embedding tablosu da içermesidir.

Bu model için Q5_K_M yayımlanmış bir etikete sahip değildir. Bu nedenle 19.8 GB satırı ölçülmüş değer yerine, bu biçim için kullanılan standart ağırlık başına 5.7 bit üzerinden hesaplanmıştır. Q8_0, Q4 boyutunu neredeyse ikiye katlayarak 30 GB olur. Yalnızca CPU kullanılan bir sistemde bu iki katına çıkış, token başına bellek trafiğini de iki katına çıkarır. Bu nedenle saniye başına token sayısı da yaklaşık yarıya iner. Yalnızca bu nedenle bile burada varsayılan seçenek Q4_K_M olmalıdır. Bu kararı bellek kullanımı yerine kalite açısından değerlendirmek istenirse, Q4, Q8 ve fp16 için daha ayrıntılı bir karşılaştırma, çıktının hangi noktada bozulmaya başladığını gösterir.

Bağlam büyüdükçe KV cache maliyeti

Ağırlıklar sabit bir maliyettir. KV cache (key ve value cache; modelin daha önce gördüğü her token için tuttuğu attention durumu) bağlam uzunluğuyla doğrusal olarak büyür. Çoğu sistemde RAM tükenmesine neden olan bölüm budur.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

Bu değerler, Qwen’in bu boyut sınıfındaki güncel dense modellerinde kullandığı yapı varsayılarak hesaplanmıştır: 64 katman, GQA (grouped-query attention) altında 8 key/value head ve 128 head boyutu. Bu yapı, f16 formatında token başına 256 KiB tüketir. Bu nedenle 32k token için 8 GB, 128k token için 32 GB gerekir. Bu hesabı kendi sisteminiz için kesin değer olarak kabul etmeyin. Modeli yükleyin ve ağırlıkları, cache’i ve ek yükü tek bir değer olarak bildiren ollama ps çıktısındaki SIZE sütununu okuyun.

Model kartında belirtilen 256K bağlamın bir plandan çok öne çıkan bir değer olmasının nedeni budur. Bu pencerenin tamamını f16 formatında doldurmak, ağırlıklar için zaten 17 GB kullanmış olan bir makinede, ağırlıklara ek olarak 64 GB cache gerektirir. Ollama varsayılan olarak size tam bağlam penceresini vermez. Çok daha küçük bir pencere yükler. OLLAMA_CONTEXT_LENGTH ile bu değeri bilinçli olarak artırabilirsiniz. Sunucu genelindeki bu değişken tek ayar değildir. Tek tek isteklerde num_ctx ayarlamak, diğer tüm işlemler için düşük maliyetli varsayılan değeri korurken uzun süren tek bir iş için daha büyük bir pencere kullanmanızı sağlar. Değeri kademeli olarak artırın ve her değişiklikten sonra ollama ps çıktısını kontrol edin.

İki ayar cache kullanımını yarıya veya daha altına indirir. OLLAMA_KV_CACHE_TYPE=q8_0, cache’i 16 bit yerine 8 bit olarak depolar. Böylece 32k token için kullanım 8 GB’tan 4 GB’a düşer. Bunun için flash attention gerekir. Bu nedenle OLLAMA_FLASH_ATTENTION=1 ayarını da yapın ve değişikliğin uygulandığını varsaymak yerine ollama ps çıktısındaki düşüşü doğrulayın. OLLAMA_NUM_PARALLEL=1 de aynı ölçüde önemlidir. Ollama aynı anda birden fazla isteğe hizmet verebilir. Her slot kendi bağlam bölümünü kullanır. Bu nedenle paralellik değerini varsayılan haliyle bırakmak, cache için ayırdığınız bütçeyi fark edilmeden katlar. Bu makineyi birden fazla kişi kullanacaksa sorun bu çarpanla başlar. Self-host edilen bir modelin hizmet verebileceği eşzamanlı kullanıcı sayısı, core sayısından çok daha önce cache slotları ve kuyruk derinliği tarafından belirlenir.

8, 16, 32 ve 64 GB RAM'e neler sığar

[
  {
    "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": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

İki sayıyı, ağırlıklarla birlikte f16 cache için sığan binlerce tokenlık context miktarı olarak okuyun. Bu değerler, işletim sistemi için yaklaşık 1.5 GB ve ek olarak küçük bir pay ayrılmış headless Linux VPS için geçerlidir. Sıfır, ağırlıkların kendisinin sığmadığı ve dolayısıyla hiçbir context değerinin sığmayacağı anlamına gelir.

8 GB ve 16 GB kesinlikle sınırda değildir. 17 GB ağırlık 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 yöntemiyle eşler. Resident sayfalar RAM'i aştığında kernel bu sayfaları tahliye edip yeniden okumaya başlar. Bunun sonucunda her token için diskten gigabaytlarca veri okunur. Sistem yüksek iowait değerinde kalır ve saniyede 1 tokenın oldukça altında üretim yapar.

32 GB başlangıç noktasıdır. Ağırlıklar 17 GB yer kaplar ve yaklaşık 13 GB boş alan kalır. Bu alan, bir pay bırakarak yaklaşık 32k tokenlık f16 context için yeterlidir. 30 GB boyutundaki Q8_0 ağırlıkları bu RAM katmanına hiç sığmaz.

64 GB rahat bir seçenektir. Q4 için yaklaşık 128k tokenlık context alanı kalır. Q8_0 ağırlıkları ise arkalarında yaklaşık 64k tokenlık alan kalacak şekilde sığar. Q8 kullanmak için 64 GB RAM satın almadan önce ne aldığınızdan emin olun: zaten yavaş olan bir makinede, hızın yarısına karşılık biraz daha iyi çıktı. Neredeyse herkes için daha uzun context kullanan Q4 daha iyi bir tercihtir.

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. Ağırlıkların yalnızca bir bölümü okunmaz. Tamamı okunur. Bu nedenle hız sınırı çekirdek sayısı değil, ağırlıkların boyutuna bölünmüş bellek bant genişliğidir. Q4 düzeyinde bu değer, token başına 17 GB bellek trafiğidir.

[
  {
    "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. Gerçek çıktı, gösterilen değerin yaklaşık yüzde 50 ila 70'i düzeyinde olur. Bunun nedeni, bellek gecikmesi ve kusurlu prefetch işlemi nedeniyle teorik tepe değerine hiçbir zaman ulaşılamamasıdır. İki kanallı DDR4-3200 kullanan bir VPS'in üst sınırı saniyede 3 token'dır; bu nedenle yaklaşık 2 token beklenmelidir. İki kanallı DDR5-4800 kullanan bir sunucunun üst sınırı 4.5 token'dır; bu nedenle yaklaşık 3 token beklenmelidir.

Büyük sunucu satırları için bir uyarı gerekir. On iki kanallı bir EPYC platformu 460.8 GB/s bellek bant genişliğine ve saniyede 27.1 token üst sınırına sahiptir. Ancak bütünüyle bir EPYC sistemi kiralanmaz. Bellek bant genişliği, o makinedeki tüm kiracılar tarafından paylaşılan host genelinde bir kaynaktır. Bu nedenle 8 vCPU'luk bir dilim, on iki kanallı özel bant genişliğiyle birlikte sunulmaz. GPU odaklı kılavuzlar bu konuyu tamamen atlar. Aynı modelde aynı vCPU sayısına sahip iki VPS planının neden üç kata varan farklılık gösterebildiği de budur.

Aynı nedenle daha fazla vCPU kısa sürede fayda sağlamayı bırakır. Çekirdekler, bellek denetleyicisinin sağlayabileceğinden daha hızlı veri istemeye başladığında ek thread'ler yalnızca zamanlama yükü oluşturur. OLLAMA_NUM_THREAD değerini fiziksel çekirdek sayısına ayarlayın, ölçüm yapın ve ardından bu sayının yarısını deneyin. Paylaşımlı planların çoğunda düşük ayar daha hızlıdır.

Prompt işleme farklı davranır. İlk token görünmeden önce girdinizin üzerinden geçilen aşama olan prefill, bant genişliği sınırlı değil, hesaplama sınırlıdır. Bu nedenle çekirdek sayısıyla ölçeklenir. Pratikte büyük bir prompt için çıktının başlamasından önce uzun bir bekleme yaşanır. Ardından yukarıdaki yavaş ve sabit hız devam eder. Her iki bölümü --verbose ile ayrı ayrı ölçün. Bu komut, her istek için bir prompt eval rate ve bir eval rate yazdırır.

Yoğun 27B modelinin hızı yetersizse CPU'dan vazgeçmeden önce qwen3.6:35b-a3b etiketlerine bakın. Bu etiketler, tüm 27.8 milyar parametre 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 bir büyüklük sırası azalır. RAM kullanımı karşılığında hız kazanılır. Runtime seçimi de burada önemlidir. Aynı temel inference kodu üzerinde Ollama ve llama.cpp farklı CPU ayarlama denetimleri sunar.

Bunun yerine GPU saatlik kiralanması ne zaman tercih edilmelidir?

[
  {
    "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ımlanmış GPU bellek bant genişliğine aynı formül uygulandığında farklı bir sonuç elde edilir. 24 GB tüketici ekran kartı, bu ağırlıklar üzerinde saniyede en fazla 59 token üretebilir. 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 ortamı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 hiç kimse sonucu beklemiyorsa CPU üzerinde çıkarım doğru seçimdir: bir belge yığınının gece boyunca özetlenmesi veya siz uyurken çalışan gecelik bir sınıflandırma işi gibi. Bir kullanıcı çıktıyı beklediği anda ya da istekler 30 saniyede birden daha sık gelmeye başladığında GPU kiralanmalıdır. Yalnızca CPU kullanan bir sunucuda toplu işleme payı yoktur ve kuyruk sürekli büyür.

Maliyet karşılaştırması göründüğünden daha karmaşıktır. 64 GB RAM içeren bir VPS, model yüklü olsun veya olmasın ayın her saati için ücretlendirilir. GPU instance ise yalnızca çalışır durumda tutulduğu saatler için ücretlendirilir. Gerçek kullanımınız günde iki saat ise kiralanan GPU hem daha hızlı hem de daha ucuz olabilir. Önce kullanım oranınızı hesaplayın, ardından maliyeti çıkarın. GPU içeren bir VPS seçme instance üzerinde kontrol edilmesi gerekenleri açıklar. Ayrıca GPU üzerinde eşzamanlı istekler sunulduğunda vLLM, Ollama'nın önüne geçer; bunun nedeni istekleri düzgün biçimde toplu işlemesidir.

İnsanların unuttuğu üçüncü bir seçenek daha vardır. Toplu işler için 27B modelini CPU üzerinde tutun ve etkileşimli işlem yolunun önüne barındırılan bir API modelini yerleştirin. Tek bir modelin her iki kullanım amacına da hizmet etmesi gerekmez.

Ollama'yı yükleyin ve kendi sisteminizi ölçün

Yükleme betiği resmidir ve ayrılmış bir ollama kullanıcısı olarak çalışan bir systemd servisi kurar.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version çıktısında 0.32.5 veya daha yeni bir sürüm görünmelidir. Herhangi bir şey çekmeden önce free -g değerini kontrol edin. Mem satırındaki total sütunu 32'nin altındaysa burada durun ve daha küçük bir model seçin. Çalıştıramayacağınız 17 GB boyutundaki bir modeli çekmek bir saati ve yüksek miktarda disk alanını boşa harcar.

Çalışma zamanı seçeneklerini shell yerine bir systemd override dosyasında ayarlayın. Model servis içinde çalışır; bu nedenle etkileşimli ortamınızı hiçbir zaman 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.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

--verbose çıktısı, aradığınız ölçümü verir. eval rate, üretim sırasındaki saniye başına token hızınızdır. prompt eval rate, prefill hızınızdır. 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 ayak izini ikinci bir terminalden kontrol edin.

ollama ps

SIZE sütunu, KV cache dahil gerçek bellek ayak izidir. Bu değer, ağırlıkların boyutuna ve KV grafiğinde kullandığınız context length satırına yakın olmalıdır. 8-bit cache ile 8192 token için ağırlıklara ek olarak yaklaşık bir gigabayt bekleyin. Cache f16 olarak kalsaydı bu değer 2 GB olurdu. PROCESSOR sütununda 100% CPU görünmelidir. Başka bir değer görünüyorsa GPU'yu başka bir işlem kullanıyordur ve bu kılavuzdaki hız değerleri sisteminizi tanımlamaz.

Hata durumları ve görülecek tam dizeler

Model yüklenmeyi reddediyor. Ollama, her iki değeri adlandıran bir satırı model requires more system memory (18.6 GiB) than is available (15.2 GiB) biçiminde yazdırır. Bu iyi bir hata durumudur; çünkü Ollama belleği ayırmadan önce kontrol yapmıştır ve kararı kernel'e bırakmamıştır. Context length değerini düşürün, daha küçük bir tag kullanın veya daha büyük bir plan seçin.

Yanıtın ortasında süreç kayboluyor. İstemci yararlı bir bilgi göstermez ve journalctl -u ollama -n 50 servisin yeniden başlatıldığını gösterir. dmesg -T | tail komutunu çalıştırın. Out of memory: Killed process ... (ollama) satırı, sürecin kernel OOM killer tarafından sonlandırıldığı anlamına gelir. Bu durum, ön yükleme denetimi başarılı olduktan sonra uzun bir konuşma sırasında cache'in tahmin edilenden daha fazla büyümesiyle oluşur. Context length değerini düşürün.

Pull işlemi hemen başarısız oluyor. Error: pull model manifest: file does not exist, tag'in library içinde bulunmadığı anlamına gelir. qwen3.8:27b yazıldığında tam olarak bu çıktı alınır. Sürüm numarasındaki herhangi bir yazım hatası da aynı sonucu verir. Ağ bağlantınızı suçlamadan önce tag'i library sayfasında doğrulayın.

Her şey çalışıyor, ancak işlem dayanılmaz derecede yavaş. Yeterli RAM bulunan bir sistemde saniyede 1 token'dan düşük hız, hesaplama gücü sorunundan çok paging sorununa işaret eder. Üretim sırasında vmstat 1 komutunu çalıştırın. Sıfır olmayan si veya so sütunu, kernel'in swap kullandığı anlamına gelir. Çözüm, context length değerini veya yüklenen model sayısını azaltmaktır. Swap etkinliği olmadan sürekli yüksek wa değeri, memory-mapped ağırlıkların diskten yeniden okunduğunu gösterir. Bu da ağırlıkların gerçekte belleğe sığmadığı anlamına gelir.

İlk token 30 saniye sonra geliyor, ardından çıktı hızlanıyor. Bu prefill işlemidir ve normaldir. Uzun bir system prompt, cache kullanılmayan her istekte yeniden işlenir. Başka ayarları değiştirmeden önce system prompt'u kısaltın.

CPU-only 27B modeli gerçekte hangi işler için uygundur

Beklentileri umuda göre değil, sayılara göre belirleyin. 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 kuyruğa alınan işler için tamamen yeterlidir. Yanıt vermeden önce akıl yürüten 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 düzeyini işe göre ayarlamak, modeli değiştirmeden yanıt süresini kısaltan az sayıdaki yöntemden biridir. Doküman özetleme, toplu etiketleme, dosya yığınlarından alan çıkarma ve gözetimsiz kod inceleme bu gecikmeyi tolere eder. Çünkü yanıtı bekleyen kimse yoktur. Kodlama yardımı tam sınırda yer alır. Bu nedenle bir coding agent'ı barındırdığınız bir 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 uygun değildir.

Asıl gerekçe gizliliktir. Model, kiraladığınız ve kontrol ettiğiniz donanımda çalışır. Hiçbir istek sunucudan dışarı çıkmaz ve token başına ücret alınmaz. 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ğerlendirin: frontier ölçeğinde bir modeli self-host etmek, bir büyüklük derecesi daha fazla donanım gerektirir. 27B modelini CPU üzerinde çalıştırmak, çıktının hâlâ okunmaya değer olduğu bu eğrinin en düşük maliyetli noktasıdır.

Bunlardan herhangi birini karşılaştırmalı olarak ölçmek için gerçek ve yapılandırılmış girdilere ihtiyaç vardır. Ayrıca çoğu herkese açık veri API'si, aktarım hızını ölçmeye başlamadan önce hesap açılmasını ister. Strasmore'un demo endpoint'i (bu endpoint'i biz çalıştırıyoruz), 22 yıllık ABD piyasa verileri üzerinde salt okunur SQL sorgularını anahtar veya kayıt gerektirmeden yanıtlar. https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 adresine gönderilen GET isteği, doğrudan prompt döngüsüne aktarabileceğiniz JSON verisiyle birlikte, bu veriyi oluşturan tam SQL sorgusunu da döndürür. Böylece modelin özetleyeceği ve bağımsız olarak doğrulayabileceğiniz bir içerik elde edilir. Sınırlar çağrı başına 500 satır ve 20 saniyedir. Bu değerler, saniyede iki token hızında çalışan bir sistemin tüketebileceğinden fazlasını rahatlıkla karşılar. Tam sütun listesi https://api.strasmore.com/v1/schema adresindedir.

İlk Ollama kurulumunuzsa, Ollama'yı bir VPS üzerinde çalıştırmaya ilişkin kapsamlı yönerge, bu kılavuzda varsayılan servis kurulumunu, HTTP API'sini ve firewall kurallarını açıklar. 11434 numaralı portu internete açmayın. Ollama kendi authentication mekanizmasıyla birlikte gelmez. Bu nedenle porta erişebilen herkes modelinizi kullanabilir ve prompt'larınızı okuyabilir.

FAQ

Ollama üzerinde Qwen 3.8 27B modeli var mı?

Hayır. 4 August 2026 itibarıyla Ollama library içinde qwen3.8 namespace'i bulunmamaktadır. Mevcut 27B tag'leri qwen3.5:27b ve qwen3.6:27b değerleridir. Her ikisi de 27.8 billion parameter içeren dense modelin Q4_K_M build'leridir. Arama ifadesindeki 3.8 değeri büyük olasılıkla sürüm numarası olarak hatırlanan 27.8B parameter sayısıdır. Güncel liste için https://ollama.com/library/qwen3.6/tags kontrol edilmelidir. En yeni yayımlanan 27B modelini kullanmak için qwen3.6:27b pull edilebilir. Mevcut olmayan bir tag, Error: pull model manifest: file does not exist hatasıyla başarısız olur.

Bir Qwen 27B modelini VPS üzerinde çalıştırmak için ne kadar RAM gerekir?

Q4_K_M için pratik minimum 32 GB'tır. Weights boyutu 17 GB'tır. İşletim sistemi yaklaşık 1.5 GB kullanır. KV cache, f16 formatında her 4000 context token için yaklaşık 1 GB ekler. 16 GB'lık bir plan weights dosyasını hiç sığdıramaz. Swap da yardımcı olmaz. Bunun nedeni dosyanın memory-mapped olması ve kernel'in her token için dosyayı diskten yeniden okumasıdır. 64 GB, uzun context veya 30 GB boyutundaki Q8_0 weights için yeterli alan sağlar.

27B model CPU üzerinde saniyede kaç token üretir?

Memory bandwidth değeri weights boyutuna bölünmeli, ardından sonucun 50 ila 70 yüzdesi alınmalıdır. İki kanallı DDR4-3200 VPS için üst sınır yaklaşık 3 token/saniyedir. Gerçek hız yaklaşık 2 token/saniyedir. İki kanallı DDR5-4800 sistem için üst sınır yaklaşık 4.5 değerindedir. Gerçek hız yaklaşık 3 token/saniyedir. Daha fazla kanallı server platformları kağıt üzerinde çok daha iyi görünür. Ancak memory bandwidth, host üzerindeki tüm tenant'lar arasında paylaşılır. Bu nedenle kendi sisteminizde ollama run qwen3.6:27b --verbose ile ölçüm yapılmalı ve eval rate satırı okunmalıdır.

Yalnızca CPU kullanılan bir VPS için Q4 mü, Q8 mi tercih edilmelidir?

Neredeyse her durumda Q4_K_M tercih edilmelidir. Q8_0 boyutu 30 GB, Q4_K_M boyutu ise 17 GB'tır. Bu nedenle Q8_0 için 64 GB'lık bir plan gerekir. Ayrıca token başına neredeyse iki kat fazla memory taşınır ve tokens per second değeri yaklaşık yarıya iner. 27B modelinde Q4_K_M ile Q8_0 arasındaki kalite farkı çoğu görev için küçüktür. RAM, modelin ifadeleri nasıl kurduğundan çok neler yapabileceğini değiştiren daha uzun bir context için ayrılmalıdır.

Büyük RAM kapasitesine sahip bir VPS yerine GPU kiralamak ne zaman daha ucuzdur?

Kullanım oranı düşük olduğunda veya bir kullanıcı yanıt beklediğinde GPU kiralamak daha ucuzdur. 24 GB memory içeren bir GPU, bu weights üzerinde yaklaşık 59 token/saniye hızına ulaşır. Tipik bir VPS ise 2 veya 3 token/saniye hız sağlar. GPU yalnızca çalıştığı saatler için ücretlendirilir. 64 GB VPS, model yüklü olsun veya olmasın tüm ay boyunca ücretlendirilmeye devam eder. Gerçekte günde kaç saat token ürettiğiniz hesaplanmalıdır. Bu süre iki veya üç saatin altındaysa saatlik GPU kiralama genellikle hem hız hem de maliyet açısından avantajlıdır. Sürekli yürütülen düşük öncelikli batch işlemlerinde ise sürekli açık VPS daha avantajlıdır.