GPU destekli VPS mi yoksa CPU yeterli mi?

GPU destekli bir VPS mi yoksa CPU yeterli mi?

GPU destekli bir VPS, bir modeli kendi başınıza çalıştırmanızla ilgili iki şeyi değiştirir: token üretim hızı ve modelin belleğe sığıp sığamayacağı. Bunun dışında hiçbir şeyi değiştirmez. İş yükünüz tek bir kişiye yanıt veren 7B ile 27B arası kuantize edilmiş bir sohbet modeli, düşük hacimli bir embedding görevi veya Whisper small ile konuşma dökümü ise, yeterli RAM'e sahip standart bir CPU VPS bu işi zaten görür. CPU üzerinde başlayın, sizi rahatsız eden değeri ölçün ve ardından yükseltme yapın.

Bunun nedeni bellek bant genişliğidir. Bir dil modeli bir token ürettiğinde, ihtiyaç duyduğu her ağırlığı bellekten okur. 4 bit kuantize edilmiş 8B bir model, diskte yaklaşık 4.7 GB yer kaplar ve bellekte de hemen hemen aynı boyuttadır; dolayısıyla bir token üretmek, yaklaşık 4.7 GB verinin taşınması anlamına gelir. Makinenin bellek bant genişliğini bu sayıya böldüğünüzde, saniyedeki token üretim hızının üst sınırını bulursunuz. Bu basit bölme işlemi, okuyacağınız neredeyse tüm performans testlerinin temelini açıklar.

GPU size gerçekte ne kazandırır

Bant genişliği. Modern bir sunucudaki DDR5 bellek, saniyede onlarca gigabayt veri aktarabilir. GPU belleği (VRAM) ise yüzlerce, hatta binden fazla gigabayt aktarır. Aradaki oran hız artışını belirler ve bu fark oldukça büyüktür.

Hız ile birlikte kapasite. 64 GB RAM'e sahip bir CPU sunucusu, 70B parametreli bir modeli 4-bit seviyesinde yükleyebilir. Model çalışır, ancak hızı sohbet etmekten ziyade okuma hızına yakın olur. GPU burada yalnızca model VRAM'e sığdığında yardımcı olur; çünkü katmanlar sistem RAM'ine taştığı anda yavaş olan yol tekrar devreye girer.

Toplu işleme (Batch throughput). İnsanların en çok hafife aldığı kısım budur. Bir kullanıcı için üretim yapan GPU, bellekten veri beklediği için işlem gücünün büyük kısmını boşta tutar. Aynı anda 20 isteğe hizmet verdiğinizde, okunan aynı ağırlık verisi 20 isteğin tamamı için kullanılır. Saniye başına üretilen toplam token sayısı birkaç kat artarken, kullanıcı başına düşen hız neredeyse hiç değişmez. CPU bunu yapamaz. Bir CPU sunucusunda aynı anda iki kullanıcı olması, her birinin hızını kabaca yarıya düşürür. Birçok istemcinin çağrı yaptığı bir API oluşturuyorsanız, toplu işleme (batching) özelliği, ham tek akışlı hızdan çok daha önemli bir GPU tercih sebebidir.

İstem işleme (Prompt processing). Uzun bir istemi okumak bellek odaklı değil, işlem gücü odaklı bir iştir ve GPU'ların en büyük farkı attığı alan burasıdır. CPU'nun bir dakikada işlediği 30.000 token'lık bir bağlam, GPU'da sadece birkaç saniye sürer. Belgeleri her isteğin içine yerleştiren retrieval (bilgi getirme) kurulumları, bu farkı sürekli hisseder.

Yaklaşık değerler ve bu değerlerin okunması

Aşağıdaki blok, Temmuz 2026 itibarıyla 4-bit kuantizasyon seviyesindeki 8B bir model için yayınlanmış tipik tek akışlı (single-stream) verileri içermektedir. Bu değerler bir taahhüt değil, büyüklük sırası hakkında yol gösterici niteliktedir. Kuantizasyonunuz, bağlam uzunluğunuz ve çıkarım motorunuz bu değerleri değiştirecektir.

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

24 GB GPU satırı, DDR5 CPU kutusu için 11 değerine karşılık saniyede 50 token göstermektedir. Bu yaklaşık beş katlık bir farktır ve ham hesaplama gücü farkından ziyade bant genişliği oranını yansıtmaktadır. Gerçek iş hacmi, bant genişliğinin model boyutuna bölünmesiyle elde edilen değerin altında kalır; çünkü büyüyen bir bağlam üzerindeki dikkat (attention) mekanizması, basit bölme işleminin hesaba katmadığı ek bir iş yükü oluşturur.

Karşılaştırma yapmak gerekirse, bir insan saniyede yaklaşık 5 ila 10 kelime okur. Saniyede 15 token ve üzerindeki herhangi bir hız, tek bir okuyucu için normal bir yazma hızı hissi verir. Sadece CPU kullanılan birçok kurulumun sessizce yeterli olmasının nedeni budur.

Satın almadan önce VRAM boyutlandırma

Model dosya boyutu bir gereksinim değil, taban değerdir. Ağırlıklar, KV cache (dikkat mekanizmasının her token için tuttuğu anahtar-değer belleği) ve yaklaşık 1 GB ek yük için bütçe ayırın.

Sabit bir yüzde eklemek yerine cache miktarını hesaplayın; çünkü ağırlıkların kuantize edilmesi cache miktarını değiştirmez. Tam dikkat (full-attention) modellerinde her token için her katman ve her KV başlığında bir anahtar ve bir değer saklanır. Ollama'nın varsayılan cache türü olan FP16'da bu, sayı başına 2 bayt demektir. 2026-10-13 tarihinde kontrol edilen Ollama model meta verilerine göre, Llama 3.1 8B modeli 32 katmana ve 128 boyutlu 8 KV başlığına sahiptir. Bu da token başına 128 KiB eder: 8k bağlamda yaklaşık 1.07 GB, 16k bağlamda ise 2.15 GB. Dolayısıyla 4.7 GB boyutundaki bir 8B model, 8k bağlamda yaklaşık 7 GB, 16k bağlamda ise yaklaşık 8 GB VRAM gerektirir. 4 bitlik bir 27B model (Ollama kütüphanesindeki Gemma 3 27B) yaklaşık 17 GB'tır. Gemma 3 meta verileri, cache büyümesini sınırlayan 1.024 tokenlik bir kayan pencere (sliding window) listeler; bu nedenle 20 GB veya daha fazlasını planlayın. 4 bitlik bir 70B model (Llama 3.3 70B) yaklaşık 43 GB'tır. 80 katmanlı yapısıyla FP16 cache, 8k bağlamda yaklaşık 2.7 GB, 16k bağlamda ise 5.4 GB ek yük getirir. Bu, 48 GB'lık bir kartın sınırda kalacağı veya iki küçük kartın gerekeceği anlamına gelir. Aynı aritmetik bunun ötesinde de geçerlidir ve Kimi K3 gibi 2.8 trilyon parametreli bir model için VRAM hesabı, kart seçiminin neden artık tek başına bir soru olmaktan çıktığını gösterir.

Uzun bağlamlar bu konunun en kritik olduğu yerdir. Llama 3.1 gibi tam dikkat modellerinde KV cache, bağlam uzunluğuyla doğrusal olarak büyür ve 128k token seviyesinde ağırlıkların kendisini aşabilir. Kayan pencereli veya parçalı dikkat (chunked attention) kullanan modeller farklıdır: Hugging Face Transformers belgeleri Mistral, Gemma 2 ve Llama 4'ü, bu katmanlardaki cache boyutu pencere veya parça boyutuna ulaştığında büyümenin durduğu örnekler olarak gösterir; bu nedenle toplamları daha yavaş artar. Uzun bağlamlar kullanmayı planlıyorsanız, önce cache için boyutlandırma yapın ve motorunuzun cache kuantizasyonu için neler sunduğunu kontrol edin. Ollama'da OLLAMA_KV_CACHE_TYPE=q8_0, varsayılan f16 belleğinin yaklaşık yarısını kullanır ve cache kuantizasyonu yalnızca Flash Attention etkinleştirildiğinde geçerli olur. Bağlam uzunluğunu da açıkça ayarlayın. Ollama varsayılan değerini VRAM'e göre seçer: 24 GiB altı için 4k, 24-48 GiB arası için 32k ve 48 GiB ve üzeri için 256k. 70B model çalıştıran 48 GB'lık bir kartta bu varsayılan değer, kartın kapasitesinden çok daha fazla cache talep eder.

Makinede nelerin mevcut olduğunu kontrol etme

Bir GPU örneğinde, başka hiçbir işlem yapmadan önce sürücünün kartı gördüğünü doğrulayın.

nvidia-smi

GPU adını, sürücü sürümünü ve toplam bellekten kullanılan miktarı listeleyen bir tablo görmelisiniz. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver, sürücünün eksik olduğu veya çekirdek yükseltmesinden sonra çekirdek modülünün yeniden derlenmediği anlamına gelir. Standart bir Ubuntu imajında çözüm genellikle sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install komutunu çalıştırmak ve ardından yeni modülün yüklenmesi için sistemi yeniden başlatmaktır. Hesaplama makineleri için Ubuntu sunucu belgeleri, sunucu sürücü dalını seçen sudo ubuntu-drivers install --gpgpu komutunu önerir.

Konteynerler için yalnızca sürücü yeterli değildir. Docker'ın cihazı içeri aktarabilmesi için NVIDIA Container Toolkit gereklidir.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Ardından, konteyner içinden aktarımın (passthrough) çalıştığını doğrulayın:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

Aynı tablo görünmelidir. Karşılayamadığı bir GPU yeteneğini belirten bir docker: Error response from daemon: could not select device driver satırı, araç setinin yüklü olduğunu ancak Docker'ın yeniden yapılandırılmadığını veya yeniden başlatılmadığını gösterir; bu durumda nvidia-ctk satırını ve yeniden başlatma işlemini tekrar çalıştırın. Compose içinde bunun karşılığı, driver değeri nvidia olan ve yetenek listesinde gpu bulunan bir deploy.resources.reservations.devices girdisidir; bu, Docker Compose on a VPS bölümünde ele alınan standart servis tanımlarına eklenir.

Yükseltme öncesi ölçüm yapın

Kullanmayı planladığınız modeli mevcut CPU sunucunuzda çalıştırın ve değerleri kaydedin. Ollama ile VPS üzerinde LLM barındırma rehberinde belirtildiği üzere, bu işlem tek bir bayrak ile gerçekleştirilir:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

Çıktı, zamanlama verileriyle sona erer. eval rate, saniye başına token cinsinden üretim hızınızdır. prompt eval rate ise makinenin girdi verinizi ne kadar hızlı okuduğunu gösterir. Bu iki değer, hangi yükseltmenin faydalı olacağını belirler: düşük bir eval rate bellek bant genişliği sorununa, uzun girdilerde düşük bir prompt eval rate ise işlem gücü sorununa işaret eder.

GPU içeren bir makinede, modelin gerçekten GPU üzerine yüklenip yüklenmediğini kontrol edin:

ollama ps

PROCESSOR sütunu, her şey GPU'ya sığdığında 100% GPU değerini, sığmadığında ise 43%/57% CPU/GPU benzeri bir değer gösterir. Kısmi bir bölünme genellikle beklenenden daha kötü sonuç verir; çünkü her token, yavaş olan tarafın tamamlanmasını beklemek zorundadır.

Maliyet sorusu

GPU örnekleri, benzer CPU örneklerinden birkaç kat daha pahalıdır ve üretilen token miktarına göre değil, var oldukları her saat için ücretlendirilirler. Günde sadece birkaç istek alan sürekli açık bir GPU, çıkarım (inference) çalıştırmanın en maliyetli yoludur. Başabaş noktası kullanım oranına bağlıdır: yoğun kullanılan bir GPU, token başına ucuzdur; boşta duran bir GPU ise tamamen israftır.

Üç dürüst yöntem işe yarar. Düşük hacimli sürekli işleri bir CPU VPS üzerinde tutun. Ara sıra gelen zorlu istekleri barındırılan bir API'ye gönderin ve token başına ödeme yapın. Toplu işler, ince ayar (fine-tuning) veya büyük ölçekli embedding işlemleri için saatlik GPU kiralayın ve işiniz bittiğinde örneği silin. Bunları bir arada kullanmak normaldir ve Sürekli açık bir VPS üzerinde yapay zeka ajanı maliyet kontrolü bölümünde açıklanan bütçeleme disiplini burada da geçerlidir; tek fark, burada sızıntının token sayısı değil, boşta geçen süre olmasıdır.

GPU olmadan sorunsuz çalışan iş yükleri

Düşük hacimli embedding işlemleri. Küçük bir embedding modeli, birkaç CPU çekirdeği üzerinde dakikada yüzlerce kısa dokümanı işleyebilir; bir kez oluşturulan bir dizinin ise hızlı olması gerekmez.

Transkripsiyon için Whisper small ve base modelleri. CPU üzerinde çalışan faster-whisper, small modeli ile neredeyse gerçek zamanlı transkripsiyon yapabilir; bu da gece boyunca çalışan bir iş akışı için yeterlidir.

Bir veya iki kullanıcı için yaklaşık 27B parametreye kadar kuantize edilmiş sohbet modelleri. Yavaş olsa da okunabilir ve kullanılabilirdir.

Toplu iş (batch job) olarak adlandırabileceğiniz her şey. Eğer ekran başında bekleyen kimse yoksa, işlem süresi bir gereksinimden ziyade zamanlama detayından ibarettir.

Gerçekten GPU gerektiren işler: küçük bir adaptörün ötesinde eğitim veya ince ayar (fine-tuning) yapmak, aynı anda çok sayıda kullanıcıya hizmet vermek, görsel ve video üretimi ile gecikmenin ürünün kendisi olduğu gerçek zamanlı konuşma işlemleri. Kartı görsel üretimi için kiraladıysanız, ComfyUI'yi bir GPU VPS üzerinde kurma ve güvenceye alma rehberi; sürümü sabitlemeyi, modeller için disk ayırmayı ve arayüzü internete açık bırakmak yerine SSH tüneli ya da kimlik doğrulayan bir ters proxy arkasına almayı adım adım anlatır.

FAQ

7B veya 8B bir model için ne kadar VRAM gerekir?

Ollama'nın varsayılan FP16 cache ayarıyla, 8k bağlamda 4 bit kuantize edilmiş 8B bir model için yaklaşık 7 GB, 16k bağlamda ise yaklaşık 8 GB gerekir. Ağırlıklar yaklaşık 4.7 GB, KV cache 8k'da yaklaşık 1.07 GB veya 16k'da 2.15 GB ekler; geri kalanı ise yaklaşık 1 GB'lık ek yüktür. 8 GB'lık bir kart 8k bağlamda yeterli olurken 16k'da zorlanır; 12 GB'lık bir kart ise daha uzun bağlamlar için rahat bir alan bırakır. Cache'i q8_0 olarak değiştirmek, cache'in kapladığı alanı yaklaşık yarıya indirir. 128k bağlamda çalıştırmayı planlıyorsanız, cache ağırlıklardan daha büyük olabileceği için boyutlandırmayı cache'e göre ayrı yapın.

Ollama'yı GPU olmadan çalıştırabilir miyim?

Evet. Ollama otomatik olarak CPU'ya geçer ve yalnızca modeli tutacak kadar RAM'e ihtiyaç duyar. Bellek hızına bağlı olarak 4 bitlik 8B bir model için saniyede yaklaşık 5 ila 12 token almayı bekleyin; bu, tek bir kullanıcı için okuma hızına yakındır. Uzun istemler (prompts) CPU'da gerçek darboğazdır, çünkü 30.000 tokenlik bağlamı okumak hesaplama yoğunlukludur ve yanıt üretmekten çok daha uzun sürer.

GPU'm neden CPU'dan çok az daha hızlı?

Genellikle modelin tamamı VRAM'e sığmadığı için bazı katmanlar CPU'da çalışır ve her token yavaş olan tarafta bekler. ollama ps komutunu çalıştırın ve PROCESSOR sütununun 100% GPU değerini gösterip göstermediğini kontrol edin. Eğer bir bölünme varsa, daha küçük bir kuantizasyon veya daha küçük bir model kullanın. Diğer yaygın neden ise model yükleme süresinin ölçümü domine ettiği kısa süreli kıyaslamalardır.

Tek bir kullanıcı için GPU VPS almaya değer mi?

Genellikle hayır. Bir kişi saniyede 5 ila 10 kelime okur ve bir CPU sunucusu, yaklaşık 13B'ye kadar olan modeller için zaten bu hızdan daha hızlı token üretir. Tek bir kullanıcı için maliyeti haklı çıkaran durumlar; uzun istemler, görsel oluşturma ve ince ayar (fine-tuning) işlemleridir. Birçok kullanıcıya aynı anda hizmet vermek en güçlü argümandır, çünkü toplu işleme (batching) sayesinde bir GPU, bir isteği yanıtlama maliyetine yakın bir maliyetle yirmi isteği yanıtlayabilir.

GPU'yu saatlik mi kiralamalıyım yoksa sürekli açık mı tutmalıyım?

İş yükü düzensizse (ince ayar, toplu embedding çalıştırma veya toplu transkripsiyon gibi) saatlik kiralayın. GPU örneği token üretimine göre değil, varlığına göre faturalandırıldığı için, kart sürekli meşgul kalacaksa sürekli açık tutun. Düşük trafikli bir asistan, boşta duran bir GPU'dan ziyade bir CPU VPS'inde veya token başına ödeme yapılan bir API hizmetinde daha ucuzdur.