# GPU sunucu mu, CPU'lu bulut sunucu mu? Hangi yapay zeka modeli GPU ister, hangisi CPU'da yeter > GPU sunucu kiralamadan önce işinizin CPU'lu bulut sunucuda yürüyüp yürümediğini ölçün. Model boyutu, token/sn hedefi ve eşzamanlı kullanıcı sayısına göre karar tablosu, Ollama ve llama.cpp ile test komutları ve KVKK açısından lokasyon farkı. Yayın: 2026-11-14 · Güncelleme: 2026-11-14 · Yazar: sunucu.com.tr Ekibi · Kaynak: https://sunucu.com.tr/blog/gpu-sunucu-mu-cpulu-bulut-sunucu-mu-hangi-yapay-zeka-modeli-gpu-ister Kendi sunucunuzda dil modeli çalıştırmak istiyorsanız, en pahalı karar en başta verilir: GPU sunucu mu kiralamalı, yoksa CPU'lu bir bulut sunucu yeter mi? Bu rehber, KOBİ sahipleri ve sistem yöneticileri için bu soruyu tahminle değil ölçümle yanıtlamayı anlatıyor. Model boyutu, ulaşmanız gereken token/sn hızı ve aynı anda kaç kişinin modeli kullanacağı kararı belirler. Aşağıdaki adımlarla birkaç saat içinde kendi rakamlarınızı elde edebilirsiniz. ## GPU sunucu ile CPU'lu sunucu arasındaki asıl fark Dil modelinin yanıt üretmesi iki aşamadan oluşur. İlk aşamada (prompt işleme, "prefill") girdi metninin tamamı bir kerede işlenir. Bu aşama hesaplama yoğundur ve paralel çalışan binlerce GPU çekirdeği burada büyük fark yaratır. İkinci aşamada (üretim, "decode") model her yeni token için ağırlıklarının neredeyse tamamını bellekten okur. Bu aşamada sınırı çoğunlukla işlemci hızı değil, bellek bant genişliği belirler. Bu yüzden kaba ama işe yarar bir üst sınır hesabı vardır: - Tek kullanıcı için üretim hızı (token/sn) ≈ bellek bant genişliği (GB/sn) ÷ model dosyasının boyutu (GB) Bir sunucunun RAM bant genişliği, veri merkezi GPU'larının bellek bant genişliğinin çok altındadır. Aynı model CPU'da çalışır, ama daha yavaş üretir. Model büyüdükçe her token için okunan veri artar ve CPU'daki hız orantılı olarak düşer. Bu formül, gerçek ölçüme başlamadan önce "bu model CPU'da kullanılabilir mi" sorusuna hızlı bir ön eleme yapmanızı sağlar. Kesin sonuç için aşağıdaki ölçüm adımları gerekir. İkinci fark eşzamanlılıktır. GPU, birden çok isteği tek bir toplu işlemde (batch) birleştirip aynı bellek okumasıyla birden çok kullanıcıya token üretebilir. CPU'da da paralel istek mümkündür, ama hesaplama kapasitesi çabuk dolar ve her kullanıcının hızı belirgin biçimde düşer. ## Hangi işler CPU'da yeter Aşağıdaki iş yükleri çoğu zaman CPU'lu bir sunucuda kabul edilebilir sonuç verir: - **1B ile 8B parametre arası, kuantize edilmiş modeller.** Q4 kuantizasyonlu 7B-8B bir model birkaç GB yer kaplar. Tek kullanıcılı iç araçlarda, e-posta taslağı, özetleme ve metin düzeltme gibi işlerde yeterli hız alınabilir. - **Embedding üretimi.** RAG için belge parçalarını vektöre çeviren embedding modelleri küçüktür. Belgeleri bir kerelik indekslerken süre uzasa da iş gece toplu çalıştırılabilir. - **Sınıflandırma ve yönlendirme.** Destek talebini kategoriye ayırma, duygu analizi, kısa etiket döndüren karar modelleri az token üretir. Az token, CPU'nun zayıf olduğu üretim aşamasının kısa sürmesi demektir. - **Düşük trafikli RAG.** Günde birkaç düzine sorgu alan, aynı anda bir iki kişinin kullandığı kurum içi doküman asistanı CPU'da yürüyebilir. Dikkat: RAG uzun bağlam gönderir, bu da prefill aşamasını uzatır. İlk tokenın gelme süresini mutlaka ölçün. - **Gecikmeye duyarsız toplu işler.** Gece çalışan özetleme, çeviri ya da veri çıkarma kuyrukları için yanıtın 2 saniyede mi 20 saniyede mi geldiği önemsizdir. ## Hangi işler GPU sunucu ister - **14B ve üzeri modeller.** Model dosyası büyüdükçe CPU'da üretim hızı sohbet için kullanışsız seviyeye iner. 32B ve 70B sınıfı modeller pratikte GPU ister. - **Çok kullanıcılı sohbet.** Aynı anda beş, on ya da daha fazla kişinin yanıt beklediği bir asistan, GPU'nun toplu işleme avantajı olmadan kuyruğa girer. - **Uzun bağlam.** Onlarca sayfalık sözleşme ya da kod tabanı gönderilen işlerde prefill aşaması CPU'da dakikalar sürebilir. - **İnce ayar (fine-tuning, LoRA).** Eğitim, geri yayılım hesapları nedeniyle çıkarımdan çok daha ağırdır. CPU'da pratik değildir. - **Görsel üretim ve görsel modeller.** Difüzyon tabanlı görsel üretim yoğun matris hesabıdır, CPU'da her görsel çok uzun sürer. Modelin GPU'ya sığıp sığmayacağını ve kaç kart gerektiğini hesaplamak için [LLM VRAM hesaplama rehberindeki](/blog/llm-vram-hesaplama-model-agirligi-kv-cache-ve-gpu-sunucu-secimi) model ağırlığı ve KV cache formüllerini kullanabilirsiniz. ## Ollama ve llama.cpp ile CPU'da test Karar vermeden önce modeli hedef sunucu sınıfında çalıştırıp ölçün. Saatlik ya da kısa süreli bir CPU'lu [bulut sunucu](/bulut-sunucu) bu test için yeterlidir. ### 1. İşlemciyi ve RAM'i kontrol edin Önce sunucunun vektör komut setlerini ve belleğini görün. llama.cpp tabanlı motorlar AVX2 ve varsa AVX-512 ile belirgin şekilde hızlanır. ```bash # İşlemci modeli, çekirdek sayısı ve vektör komut desteği lscpu | grep -E 'Model name|^CPU\(s\)|Thread|NUMA node\(s\)' grep -o -E 'avx2|avx512f|avx512_vnni|amx_tile' /proc/cpuinfo | sort -u # Toplam ve kullanılabilir bellek free -h ``` Beklenen çıktıda en az `avx2` görmelisiniz. Hiç görünmüyorsa o sunucu LLM için uygun değildir. `free -h` çıktısındaki "available" değeri, model dosyası artı bağlam için gereken bellekten rahatça büyük olmalı. ### 2. Paylaşımlı vCPU kontrolü Paylaşımlı vCPU'larda başka sanal makineler aynı fiziksel çekirdeği kullanır. LLM tüm çekirdekleri uzun süre doldurduğu için bu durumda hız dalgalanır. Model çalışırken ikinci bir terminalde şunu izleyin: ```bash # 'st' sütunu: hipervizörün sizden aldığı CPU zamanı (steal) vmstat 2 10 ``` `st` sütunu sürekli birkaç yüzdenin üzerindeyse ölçtüğünüz token/sn güvenilir değildir. Ayrılmış (dedicated) vCPU'lu bir plan ya da fiziksel sunucu düşünün. ### 3. Ollama'da modelin nerede çalıştığını doğrulayın Ollama, GPU yoksa otomatik olarak CPU modunda çalışır. Modeli `--verbose` ile çalıştırınca yanıtın sonunda hız istatistikleri basılır. `ORNEK_MODEL` yerine test etmek istediğiniz modeli yazın (ör. 8B sınıfı bir model). ```bash ollama run ORNEK_MODEL --verbose "Bir KOBİ için yedekleme politikasının beş maddesini yaz." # Ayrı terminalde: model bellekte mi, CPU'da mı GPU'da mı? ollama ps ``` `--verbose` çıktısındaki `eval rate` satırı üretim hızını, `prompt eval rate` satırı prefill hızını gösterir. `ollama ps` çıktısındaki PROCESSOR sütununda `100% CPU` görmeniz beklenir. GPU'lu bir sunucuda `100% GPU` yerine `40%/60% CPU/GPU` gibi bölünmüş bir değer görürseniz model VRAM'e sığmamış demektir (aşağıda anlatılıyor). ### 4. llama.cpp ile tekrarlanabilir ölçüm `llama-bench` aynı modeli sabit koşullarda ölçer ve sonuçları karşılaştırmayı kolaylaştırır. `-ngl 0` hiçbir katmanın GPU'ya gönderilmemesini, yani saf CPU ölçümünü sağlar. ```bash # GGUF dosyasının yolunu ve iş parçacığı sayısını kendinize göre değiştirin llama-bench -m /opt/modeller/ORNEK_MODEL-Q4_K_M.gguf -ngl 0 -t 8 -p 512 -n 128 ``` Çıktı tablosundaki `pp512` satırı 512 tokenlık girdiyi işleme hızını, `tg128` satırı 128 token üretme hızını verir. Karar için asıl bakacağınız değer `tg128` (üretim) ve uzun bağlamlı işler için `pp512`'dir. `-t` değerini fiziksel çekirdek sayısının biraz altında ve tam sayısında deneyin; bazen tüm iş parçacıklarını kullanmak hızı artırmaz. ### 5. Eşzamanlı kullanıcı testi Tek kullanıcılık hız yanıltıcıdır. Aşağıdaki betik Ollama API'sine aynı anda N istek gönderir ve her isteğin üretim hızını ve ilk yanıt öncesi bekleme süresini yazdırır. Ubuntu 24.04 ve Debian 12 için hazırlandı; `curl` ve `jq` gerektirir. Sistemde kalıcı bir değişiklik yapmaz, yalnız geçici bir dizin açıp çıkışta siler. Geri almak için betik dosyasını silmeniz yeterli. ```bash #!/usr/bin/env bash # ollama-eszamanli-test.sh # Kullanım: ./ollama-eszamanli-test.sh ORNEK_MODEL 4 set -euo pipefail MODEL="${1:?Model adı verin, ör. ORNEK_MODEL}" ESZAMANLI="${2:-1}" # aynı anda gönderilecek istek sayısı URL="http://localhost:11434/api/generate" # Ollama yalnız yerelde dinlemeli PROMPT="Bir KOBİ için yedekleme politikasının beş maddesini kısaca yaz." command -v jq >/dev/null || { echo "jq gerekli: sudo apt install -y jq"; exit 1; } TMP="$(mktemp -d)" trap 'rm -r "$TMP"' EXIT # yalnız bu geçici dizini siler BASLA=$(date +%s) for i in $(seq 1 "$ESZAMANLI"); do curl -s "$URL" -d "{\"model\":\"$MODEL\",\"prompt\":\"$PROMPT\",\"stream\":false,\"options\":{\"num_predict\":200}}" \ > "$TMP/$i.json" & done wait BITIS=$(date +%s) for f in "$TMP"/*.json; do # eval_duration ve prompt_eval_duration nanosaniye cinsindendir jq -r '"token: \(.eval_count) | uretim: \(((.eval_count / (.eval_duration/1e9))*10|floor)/10) token/sn | ilk token oncesi: \((((.prompt_eval_duration + .load_duration)/1e9)*10|floor)/10) sn"' "$f" done echo "Toplam süre: $((BITIS - BASLA)) sn, eşzamanlı istek: $ESZAMANLI" ``` Önce betiği bir kez `1` ile çalıştırın; ilk çalıştırma modeli belleğe yüklediği için yavaş olur. Sonra 1, 2, 4 ve 8 eşzamanlı istekle tekrarlayın. Ollama'nın aynı anda kaç isteği paralel işleyeceği `OLLAMA_NUM_PARALLEL` ortam değişkeniyle ayarlanır; değer düşükse istekler kuyruğa girer ve "ilk token öncesi" süre büyür. Ayarın güncel davranışı için [Ollama belgelerine](https://docs.ollama.com/faq) bakın. ### Kendi eşiğinizi belirleyin Ölçümden önce kabul edilebilir değeri yazın. Örneğin: "Sohbet ekranında kullanıcı başına en az 10 token/sn ve ilk token 3 saniyeden kısa." Toplu işlerde ise "gece 8 saatte 5.000 belge özetlenmeli" gibi bir hedef koyun ve ölçülen hızla çarparak tutup tutmadığına bakın. Eşik yoksa her sonuç "idare eder" gibi görünür. ## VRAM'e sığmayan model: CPU'ya taşma neden yavaşlatır Ollama ve llama.cpp, modelin VRAM'e sığmayan katmanlarını sistem RAM'ine bırakıp CPU'da çalıştırabilir (offload). Bu özellik modelin hiç açılmamasından iyidir, ama performans beklentisini bozar. Her token üretiminde CPU'daki katmanlar yavaş bellekten okunur ve GPU bu katmanları beklemek zorunda kalır. Toplam hız, zincirin en yavaş halkasına yaklaşır. Pratik sonuç: "Biraz büyük bir modeli küçük bir GPU'da taşırarak çalıştırırım" yaklaşımı çoğu zaman beklenenden kötü sonuç verir. `ollama ps` çıktısında CPU/GPU bölünmesi görüyorsanız üç seçeneğiniz var: daha küçük ya da daha agresif kuantize edilmiş bir model, bağlam uzunluğunu (`num_ctx`) düşürmek ya da daha fazla VRAM'li bir kart. llama.cpp'de `-ngl` değerini değiştirerek kaç katmanın GPU'da kaldığını görebilir ve hız farkını aynı `llama-bench` komutuyla ölçebilirsiniz. ## Eşzamanlı kullanıcıya göre karar tablosu Aşağıdaki tablo bir başlangıç noktasıdır, ölçümün yerine geçmez. Kendi `tg128` ve eşzamanlı test sonuçlarınız tablodan farklıysa kendi sonuçlarınıza güvenin. | İş yükü | Model sınıfı | Eşzamanlı kullanıcı | Önerilen başlangıç | |---|---|---|---| | Sınıflandırma, etiketleme, karar modeli | 1B-4B | Düşük ya da toplu | CPU'lu bulut sunucu | | Embedding üretimi (indeksleme) | Küçük embedding modeli | Toplu iş | CPU'lu bulut sunucu | | İç asistan, özetleme | 7B-8B, Q4 | 1-2 | CPU'lu sunucu, ayrılmış vCPU | | Kurum içi RAG, kısa bağlam | 7B-8B | 2-5 | Önce CPU'da test, sınırdaysa GPU | | Uzun bağlamlı RAG, sözleşme analizi | 8B ve üzeri | Herhangi | GPU sunucu | | Ekip sohbet asistanı | 14B ve üzeri | 5 ve üzeri | GPU sunucu | | İnce ayar, LoRA, görsel üretim | Her boyut | Herhangi | GPU sunucu | ### Aylık maliyeti doğru karşılaştırmak Burada sabit TL rakamı vermek yanıltıcı olur; fiyatlar kur ve plana göre değişir. Doğru karşılaştırma şöyle yapılır: 1. Ölçtüğünüz hızla hedef iş hacmini karşılayan en küçük CPU'lu planı bulun (vCPU türü, RAM, disk). 2. Aynı iş hacmini karşılayan GPU yapılandırmasını belirleyin. 3. İkisini "aylık maliyet ÷ ayda üretilen token" ya da "aylık maliyet ÷ ayda karşılanan kullanıcı" birimine çevirin. CPU'lu sunucu aylık tutarda daima ucuzdur. Ancak 14B üstü model ya da çok kullanıcı söz konusuysa, hedef hıza ulaşmak için gereken CPU kapasitesi büyür ve token başına maliyette GPU öne geçebilir. Güncel plan fiyatlarını [fiyatlar sayfasından](/fiyatlar) alıp bu hesaba koyabilirsiniz. Bir başka seçenek de karma yapıdır: embedding ve sınıflandırma CPU'lu sunucuda, sohbet modeli GPU'da. ## KVKK: verinin nerede kaldığı İki seçeneği lokasyon açısından da karşılaştırın, çünkü burada fark var. - **CPU'lu bulut sunucu:** sunucu.com.tr bulut sunucuları İstanbul ve Strasbourg (Fransa) lokasyonlarında sunulur. İstanbul lokasyonunu seçtiğinizde model, istemler ve yanıtlar Türkiye'deki sunucuda işlenir. - **GPU sunucu:** katalogdaki GPU sunucular Frankfurt'ta (Almanya, AB) bulunur. Kişisel veri içeren istemleri bu sunucuya göndermek yurt dışına aktarım anlamına gelir ve KVKK'nın 9. maddesi kapsamında değerlendirilmesi gerekir. İstanbul lokasyonu ya da farklı kart modeli ihtiyacı için GPU sayfasındaki formla talep iletilebilir. Pratik bir çözüm: kişisel veriyi İstanbul'daki CPU'lu sunucuda maskeleyip ya da anonimleştirip yalnız gerekli metni GPU'ya göndermek. Hangi yolu seçerseniz seçin, aktarım ve saklama kararını hukuk danışmanınızla birlikte yazılı hale getirin. Mevzuatın güncel metni için [KVKK'nın resmi sitesine](https://www.kvkk.gov.tr) başvurun. ## Sık yapılan hatalar - **Paylaşımlı vCPU'da model çalıştırmak.** Steal süresi yüksek bir sanal makinede ölçülen hız gün içinde dalgalanır. Üretim için ayrılmış çekirdek seçin ve `vmstat` ile doğrulayın. - **RAM'i model dosyası kadar seçmek.** Model dosyasına ek olarak KV cache, işletim sistemi, embedding modeli ve vektör veritabanı da bellek ister. Bellek yetmezse sistem swap'a düşer ve hız çöker. - **Yalnız tek kullanıcıyla test etmek.** Tek istekte iyi görünen sunucu, dört eşzamanlı istekte eşiğin altına inebilir. Betiği farklı eşzamanlılık değerleriyle mutlaka çalıştırın. - **Prefill süresini görmezden gelmek.** RAG'de uzun bağlam gönderildiğinde kullanıcıyı asıl bekleten şey ilk tokenın gecikmesidir. `prompt eval rate` ve `pp512` değerlerine bakın. - **Ollama portunu internete açmak.** 11434 portu kimlik doğrulama içermez. Uzaktan erişim gerekiyorsa ters vekil ve kimlik doğrulama arkasına alın. - **Kuantizasyonu kalite testi yapmadan düşürmek.** Q2-Q3 gibi agresif kuantizasyon hızı artırır ama Türkçe yanıt kalitesini düşürebilir. Kendi örnek sorularınızla kaliteyi de karşılaştırın. ## Sık sorulan sorular ### Ekran kartı olmadan yapay zeka sunucusu kurulabilir mi? Evet. Ollama ve llama.cpp GPU bulamazsa CPU'da çalışır. 1B-8B arası kuantize modeller, embedding ve sınıflandırma işleri için CPU'lu sunucu yeterli olabilir. Yeterli olup olmadığını `ollama run --verbose` ve `llama-bench -ngl 0` ile ölçerek anlarsınız. ### GPU sunucu ne zaman gerekir? 14B ve üzeri model, beş ve üzeri eşzamanlı kullanıcı, uzun bağlam, ince ayar ya da görsel üretim söz konusuysa GPU sunucu gerekir. Ayrıca ölçtüğünüz CPU hızı kendi belirlediğiniz token/sn eşiğinin altındaysa karar netleşir. ### CPU'da hızı artırmak için ne yapabilirim? Daha küçük ya da daha iyi kuantize edilmiş bir model seçin, bağlam uzunluğunu ihtiyaç kadar tutun, iş parçacığı sayısını `-t` ile deneyerek ayarlayın ve AVX-512 destekli, ayrılmış çekirdekli bir sunucu kullanın. Bellek bant genişliği asıl sınır olduğu için çekirdek sayısını artırmak belli bir noktadan sonra fayda vermez. ### CPU'da başlayıp sonra GPU'ya geçmek zor mu? Değil. Ollama ve llama.cpp aynı model dosyalarını ve aynı API'yi GPU'lu sunucuda da kullanır. Uygulamanız API adresini değiştirerek yeni sunucuya yönelebilir. Çok kullanıcılı üretimde vLLM gibi bir motora geçmek isterseniz yalnız servis katmanı değişir, OpenAI uyumlu API sayesinde uygulama tarafı büyük ölçüde aynı kalır. ### Verim Türkiye'de kalmalı, GPU sunucu kullanabilir miyim? Katalogdaki GPU sunucular Frankfurt'tadır, bu yüzden kişisel veri gönderiyorsanız yurt dışı aktarım değerlendirmesi gerekir. Seçenekler: işi İstanbul'daki CPU'lu sunucuda çözmek, veriyi anonimleştirip GPU'ya göndermek ya da İstanbul lokasyonu için talep iletmek. ## Bu işi hazır yapmak isterseniz Ölçüm sonuçlarınız GPU gerektiğini gösteriyorsa, kart ve yapılandırma seçimini iş yükünüze göre birlikte netleştirmek için [GPU sunucu](/gpu-sunucu) sayfasından talep iletebilirsiniz. Farklı kart modeli ya da lokasyon ihtiyacınızı da aynı formda belirtebilirsiniz. ## Sonuç GPU ile CPU arasındaki seçim bir inanç meselesi değil, ölçüm meselesidir. Önce kabul edilebilir token/sn ve ilk token süresini yazın, sonra modeli CPU'lu bir sunucuda `ollama --verbose`, `llama-bench -ngl 0` ve eşzamanlı istek betiğiyle test edin. Küçük modeller, embedding ve düşük trafikli işler çoğu zaman CPU'da kalabilir. Büyük modeller, çok kullanıcı, uzun bağlam ve eğitim ise GPU ister. Kararı verirken maliyeti token başına hesaplayın ve kişisel verinin hangi lokasyonda işleneceğini en baştan planlayın.