Ollama ve vLLM Karşılaştırması: Hangisi Seçilmeli?

Ollama ve vLLM karşılaştırması

Ollama, bünyesinde bir sunucu barındıran bir model yöneticisidir; kuantize edilmiş ağırlıkları indirir, bunları yükler ve donanımda yalnızca CPU varsa bu kaynak üzerinden 127.0.0.1:11434 adresinde yanıt üretir. vLLM ise bir iş hacmi motorudur; çok sayıda isteği aynı anda işleyerek GPU kullanımını en üst düzeyde tutar ve GPU bulunmayan bir makinede kullanılması uygun değildir; temel ayrım noktası budur. Yerel bir asistanla etkileşim kuran tek bir kullanıcı için Ollama, bir ekibe hizmet veren bir uygulama için ise vLLM tercih edilmelidir.

Her iki araç da OpenAI uyumlu bir HTTP API üzerinden iletişim kurar, bu nedenle istemci kodu yalnızca temel URL değiştirilerek birinden diğerine taşınabilir; aradaki fark API yapısından kaynaklanmaz. Temel fark, ilk istek henüz token üretmeye devam ederken ikinci bir istek geldiğinde sistemin nasıl tepki vereceğidir.

Ollama nedir

Ollama bir kolaylık katmanıdır. Tek bir kurulum komutuyla model kayıt defteri (ollama pull llama3.1:8b), yerel ağırlık deposu, sohbet istemi, systemd servisi ve HTTP API sağlar. Sunduğu modeller genellikle 4-bit kuantize edilmiş GGUF dosyalarıdır; bu nedenle 7B veya 8B bir model diskte 16 GB yerine yaklaşık 5 GB yer kaplar. Kuantizasyon, CPU üzerinde çıkarım yapılmasını mümkün kılan temel unsurdur.

Çalıştırıcısı, GGUF kuantizasyonunu standart donanımlarda pratik hale getiren C++ çıkarım kütüphanesi llama.cpp üzerine inşa edilmiştir. Ollama o zamandan beri bazı yeni model aileleri için kendi motorunu eklemiştir ancak llama.cpp, sunduğu çoğu şeyin temelini oluşturmaya devam etmektedir. Bu nedenle insanlar Ollama ile llama.cpp'yi kıyasladıklarında, aslında bir ergonomi katmanı ile onun sarmaladığı yapıyı kıyaslamaktadırlar.

Tasarım hedefi tek bir kullanıcıdır. Temmuz 2026 itibarıyla OLLAMA_NUM_PARALLEL için varsayılan değer 1'dir; bu, bir modelin aynı anda tek bir isteği işlediği ve diğer her şeyin varsayılan olarak 512 giriş tutan bir kuyrukta beklediği anlamına gelir (OLLAMA_MAX_QUEUE). Paralel ayarını yükseltebilirsiniz; aşağıdaki bölüm bunun size maliyetini açıklamaktadır. Ollama'yı daha önce çalıştırmadıysanız, Ollama'yı bir VPS üzerinde barındırmak ve 11434 numaralı portu kapalı tutmak ile başlayın, çünkü API herhangi bir kimlik doğrulama mekanizmasına sahip değildir.

vLLM nedir

vLLM sadece bir çıkarım (inference) sunucusudur, başka bir şey değildir. Model kütüphanesi yönetmez, sohbet istemi (chat prompt) içermez ve istek anında sizin yerinize model indirmez. Başlatma sırasında bir Hugging Face deposu belirtirsiniz, o modeli yükler ve siz süreci durdurana kadar servis eder.

Bu kısıtlı kapsamın sağladığı avantaj yüksek iş hacmidir (throughput). İki mekanizma bu işi yapar. PagedAttention, KV önbelleğini (key-value cache; modelin her aktif istek için tuttuğu token bazlı dikkat durumu) işletim sistemlerinin bellek sayfalamasına benzer şekilde sabit boyutlu bloklarda saklar. Bir isteğin artık en kötü senaryoya göre ayrılmış büyük ve bitişik bir bellek alanına ihtiyacı yoktur; böylece önceden ayrılmış ancak kullanılmayan bellek, daha fazla eşzamanlı istek için kullanılabilir hale gelir. Continuous batching (sürekli toplu işleme), yeni bir isteğin mevcut toplu işlemin bitmesini beklemeden, bir sonraki kod çözme adımında çalışan toplu işe dahil olmasını sağlar. Tamamlanan bir dizi toplu işten hemen çıkar ve boşalan yuvası doldurulur.

Pratik sonuç şudur: Tek bir GPU üzerinde, eşzamanlı kullanıcı sayısını birden otuza çıkarmak toplam saniye başına token sayısını ciddi oranda artırırken, kullanıcı başına düşen hız beklenenden çok daha az azalır. Ollama'nın varsayılan ayarlarında ise kullanıcı sayısını birden otuza çıkarmak, sadece yirmi dokuz kişinin beklemesine neden olur.

Continuous batching temel farkı yaratır

Aynı donanım üzerinde beş isteğin aynı anda bir sunucuya ulaştığını varsayın.

Ollama, varsayılan ayarlarla birinci isteği tamamlar, ardından ikinciye geçer ve bu şekilde devam eder. Beşinci kullanıcı, dört tam nesil işleminin bitmesini bekler. Toplam iş hacmi kabaca tek bir nesil hızına eşittir, çünkü işlemci her seferinde yalnızca bir dizi üzerinde çalışır.

vLLM ise beş isteğin tamamını aynı ileri geçişte (forward pass) çözer. Beş dizi için bir token üretmek, tek bir dizi için bir token üretmekten neredeyse farksızdır; çünkü maliyetli olan kısım model ağırlıklarının bellekten okunmasıdır ve bu okuma işlemi tüm grup (batch) genelinde paylaşılır. Bu, CPU çıkarımını yavaşlatan bellek bant genişliği gerçeğiyle aynıdır: maliyeti aritmetik işlemler değil, ağırlıkların taşınması oluşturur.

OLLAMA_NUM_PARALLEL=4 ayarını yaparak bu verimliliğin bir kısmını elde edebilirsiniz. Bunun bedeli bellektir. Her paralel yuva (slot) kendi KV önbelleğine ihtiyaç duyar ve Ollama, bağlam penceresini yuvalar arasında böler. Bu nedenle, 8192 token için yapılandırılmış bir modelde dört paralel istek, her isteğe 2048 tokenlik bağlam alanı bırakır. 8192 değeri sabit bir kural değil bir tercihtir; bu yüzden num_ctx değerini artırmak ve buna karşılık gelen RAM miktarını ayarlamak, dört yuvanın kullanılabilir olup olmayacağını belirleyen adımdır. vLLM'in sayfalandırılmış önbelleği (paged cache), bloklar istek büyüdükçe tahsis edildiği için bu ödünleşimi ortadan kaldırır. Her iki durumda da, tek bir sunucunun aynı anda kaç kişiye hizmet verebileceğinin sınırı KV önbellek boyutu, ön doldurma (prefill) maliyeti ve kuyruk derinliğine bağlıdır; bu da tek kişi için sorunsuz çalışan bir sunucunun beş kişide neden yavaşladığının temel nedenidir.

Ollama kurulumu ve servisi

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

Kurulum betiği bir ollama sistem kullanıcısı oluşturur, ikili dosyayı yükler ve 127.0.0.1:11434 adresine bağlı ollama.service servisini kaydeder. --verbose tarafından yazdırılan eval rate satırı, o sunucudaki gerçek saniye başına token değerinizdir. Bu değeri, yayınlanan herhangi bir rakamdan daha fazla dikkate alın. Tek bir istemden alınan tek bir okuma, kapasite değerinden ziyade bir başlangıç noktasıdır; bu nedenle eşzamanlılık taramasında saniye başına token zamanlaması, sunucunun beklediğiniz yük altında çalışıp çalışmayacağını ve bir GPU kiralamanın token başına ödeme yapmaktan daha avantajlı olup olmadığını size gösterir.

Eşzamanlılığı artırmak için bir systemd drop-in dosyası kullanın; böylece bir yükseltme işlemi yaptığınız değişikliğin üzerine yazmaz:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps nelerin yüklü olduğunu gösterir ve PROCESSOR sütunu gerçek durumu yansıtır. 100% CPU, hiçbir GPU'nun kullanılmadığı anlamına gelir; bu, Ollama'nın yavaş olduğuna dair çoğu raporun dürüst açıklamasıdır. Bu drop-in dosyasındaki OLLAMA_KEEP_ALIVE=30m satırı, boş bir sunucuda da aynı derecede önemlidir; çünkü varsayılan ayar, beş dakika boyunca istek gelmediğinde modeli bellekten kaldırır ve modeli istekler arasında bellekte tutmak, boş geçen bir saatin ardından gelen ilk istemin tam yükleme süresini tekrar harcamasını engeller.

vLLM kurulumu ve servis edilmesi

vLLM, Linux ve Python 3.10 ile 3.13 arası sürümleri gerektirir. Belirli bir PyTorch sürümüyle geldiği için kurulumu kendi sanal ortamında yapın:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

Ardından bir model servis edin. Buradaki isim, kısa bir etiket değil, Hugging Face depo kimliğidir:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

Başlangıç ilk seferde yavaştır; çünkü ağırlıklar indirilir ve ardından kaç adet KV cache bloğunun sığacağını belirlemek için GPU profili çıkarılır. Servis 8000 numaralı portu dinler. Herhangi bir istemci kodu yazmadan önce bunu kontrol edin:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

Eğer sunucuda Docker yüklüyse, resmi imajı kullanmak CUDA bağımlılığıyla uğraşmanızı engeller:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host dekoratif değil, zorunludur: PyTorch, tensörleri süreçler arasında paylaşımlı bellek üzerinden aktarır ve varsayılan Docker paylaşımlı bellek tahsisi, tensör paralelli çıkarım için çok küçüktür.

Üretim ortamında en önemli bayraklar; --max-model-len (kullanmaya razı olduğunuz bağlam penceresi), --gpu-memory-utilization (vLLM'in kart üzerinde talep edebileceği oran, Temmuz 2026 itibarıyla varsayılan 0.92'dir), tek bir modeli birden fazla GPU'ya bölmek için --tensor-parallel-size ve --api-key'dir.

Kimlik doğrulama vLLM üzerinde bir bayrak iken Ollama üzerinde mevcut değildir

vLLM, kendisine bir tane sağladığınız takdirde bir bearer token zorunlu kılar:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

Aynı değer VLLM_API_KEY ortam değişkeninden de gelebilir. Bu değişken olmadan yapılan bir istek HTTP 401 hatası alır. vLLM üzerinde hız sınırlaması (rate limiting) bulunmadığı ve düz HTTP token'ı iletim sırasında okunabilir olduğu için bu durum, 8000 numaralı portu genel bir arayüzde yayınlamak için bir neden teşkil etmez; ancak sunucunun bir çağırıcı kavramına sahip olduğu anlamına gelir.

Ollama'da ise böyle bir özellik yoktur. Anahtar, giriş veya izin listesi bulunmaz. 11434 numaralı porta erişebilen herhangi bir süreç model çalıştırabilir, çekebilir veya silebilir. Servisi loopback üzerinde tutun ve kendi barındırdığınız bir WireGuard VPN üzerinden ya da TLS (transport layer security) sonlandıran kimlik doğrulamalı bir reverse proxy aracılığıyla erişin.

Donanım: her birinin ihtiyacı

Ollama, CPU üzerinde çalışır. 4-bit kuantize edilmiş bir model, milyar parametre başına yaklaşık yarım gigabayt RAM, buna ek olarak yaklaşık bir gigabayt çalışma zamanı yükü ve bağlam (context) için daha fazlasını gerektirir; bu nedenle 3B bir model yaklaşık 4 GB boş alan, 8B bir model ise yaklaşık 8 GB boş alan ister. Paylaşımlı bir vCPU üzerindeki hız, saniyede tek haneli veya düşük çift haneli token seviyesindedir. Bu durum bir yapılandırma hatası değil, bellek bant genişliği kısıtlamasıdır ve hiçbir flag bunu düzeltemez. Bu hesaplamanın genel bir kural yerine belirli bir sürümde nasıl işlediğini görmek için Nemotron 3.5 Lightning'i bir VPS üzerinde çalıştırma rehberi, çekilmesi gereken tam etiketi, yüklendiğinde kapladığı RAM miktarını ve sadece CPU ile çalışmanın kabul edilebilir bir hızda olup olmadığını netleştirir.

vLLM, bir GPU gerektirir. Varsayılan yolu, ağırlıkları 16-bit hassasiyetinde sunar; bu da milyar parametre başına yaklaşık 2 GB demektir: 8B bir model, vLLM'i kurma amacınız olan eşzamanlılığı sağlayan KV cache öncesinde, sadece ağırlıklar için yaklaşık 16 GB video belleğine ihtiyaç duyar. 24 GB'lık bir kartta bu durum çalışılabilir bir önbellek alanı bırakır. 16 GB'lık bir kartta ise bu alan yetersiz kalır; bu durumda ya daha küçük bir model seçmeli ya da kuantize edilmiş bir checkpoint ile --quantization flag'ini kullanmalısınız. Bir CPU arka ucu mevcuttur ancak standart paketler bunun için derlenmemiştir ve bu kullanım, vLLM çalıştırmanın temel mantığını ortadan kaldırır.

Dolayısıyla donanım sorusu, çoğu zaman yazılım sorusunun da cevabını verir. GPU yoksa Ollama kullanılır. İstekler sıraya alındığı için yüzde 5 kullanımda kalan kiralanmış bir GPU varsa, vLLM tercih edilmelidir.

İş yükünüz için hangisi uygun

• Tek kişi, bir CPU VPS, taslak oluşturma ve özetleme: Ollama. Hız kabul edilebilir düzeydedir ve daha basit bir seçenek yoktur.
• Bir kodlama asistanı veya araçlarınızı yerel bir modele bağlayan bir MCP sunucusu, sadece sizin kullandığınız: Ollama. Tekil eşzamanlılık, gerçek iş yüküdür.
• Bu hafta beş modeli karşılaştırma: Ollama. Etiketli modelleri çekmek ve silmek tam olarak bu aracın uzmanlık alanıdır; vLLM ise her model için süreç yeniden başlatması gerektirir.
• Dahili bir uygulama, sohbet ürünü veya gerçek kullanıcıları olan bir getirme hattı: vLLM. Toplu işleme (batching) özelliğinin GPU maliyetini haklı çıkardığı nokta burasıdır.
• Gece boyunca yüz bin belgeyi puanlayan bir toplu iş: vLLM, yüksek bir --max-num-seqs ile. Önemli olan tek metrik iş hacmidir (throughput), belge başına gecikme süresi değildir.
• Birden fazla kendi kendine barındırılan yapay zeka aracının aynı anda modele eriştiği bir aracı platformu: vLLM, çünkü aracı trafiği doğası gereği ani ve paraleldir.

Hata modları ve karşılaşacağınız dizgeler

vLLM, bir KV cache hatası nedeniyle başlamayı reddediyor. İleti, her iki sayıyı da belirtir:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

Model, ağırlıklar yüklendikten sonra kalan bellekten daha büyük bir bağlam penceresi (context window) tanımlıyor. --max-model-len 8192 ile bu değeri düşürün veya kartı başka hiçbir şey kullanmıyorsa --gpu-memory-utilization değerini artırın. Kullanımı 0.95 seviyesinin üzerine çıkarmak, genellikle bu başlangıç hatasını daha sonra yük altındayken oluşacak bir CUDA bellek yetersizliği (out-of-memory) çökmesine dönüştürür ki bu iki durum arasında daha kötü olanıdır.

Ollama, üretim (generation) sırasında Killed çıktısı veriyor. Linux bellek yetersizliği sonlandırıcısı (OOM killer), modelin sunucuda mevcut olandan daha fazla RAM'e ihtiyaç duyması nedeniyle süreci durdurdu. sudo dmesg | grep -i oom ile durumu doğrulayın. Çözüm bir ayar değişikliği değil, daha küçük veya daha yüksek oranda kuantize edilmiş bir model kullanmaktır.

Ollama tek başına düzgün yanıt veriyor ancak yük altında takılıyor. Hiçbir yerde hata görünmüyor. İstekler, OLLAMA_NUM_PARALLEL=1 onları sıraya dizdiği için daha fazla kullanıcı olduğunda daha uzun sürüyor. Uzun yanıtlar kuyruğu daha da kötüleştirir; çünkü model durmaya karar verene kadar tek bir yuvayı (slot) işgal eden kullanıcı, arkasındaki herkesi engeller. Bu nedenle num_predict ile yanıtı sınırlamak, tek bir oturumun sunucuyu ne kadar süre meşgul edebileceğine bir üst sınır koyar. Paralel ayarını yükseltip istek başına daha küçük bağlamı kabul edin veya iş yükünü vLLM'e taşıyın.

vLLM her çağrıda 401 hatası döndürüyor. Servisi --api-key ile başlattınız ancak istemci herhangi bir Authorization başlığı göndermiyor. Çoğu OpenAI istemci kütüphanesi, anahtar olarak ne gönderirseniz onu iletir; bu nedenle bayrağı kaldırmak yerine anahtarı istemci tarafında ayarlayın.

vLLM modelin bulunamadığını belirtiyor. Ollama modelleri talep üzerine çeker, vLLM çekmez. İstek gövdesindeki model alanı, başlatma sırasında kullandığınız depo kimliği (repository id) ile veya ayarladıysanız --served-model-name değeri ile eşleşmelidir. Tam dizgeyi curl http://localhost:8000/v1/models ile doğrulayın.

Her ikisini de çalıştırmak makul bir çözümdür

Bunlar birbirini dışlayan seçenekler değildir. Yaygın bir yapılandırma, uygulamaya hizmet veren GPU örneğinde vLLM çalıştırmak ve bunun yanında yerel betikler, cron işleri ve yeni model sürümlerini denemek için standart bir VPS üzerinde Ollama bulundurmaktır. Her iki uç nokta da OpenAI uyumludur; bu sayede tek bir istemci kütüphanesi ve base-URL değişikliği ile her ikisi de kullanılabilir. Burada maliyet kontrolü, kullanılan motorun kendisinden daha önemlidir; çünkü boşta duran bir GPU, yoğun çalışan bir GPU ile aynı maliyeti oluşturur. Ayrıca temsilci ve çıkarım maliyetlerini öngörülebilir tutmak, sunucu seçiminden ayrı bir uzmanlık alanıdır.

FAQ

vLLM, Ollama'dan daha mı hızlıdır?

Aynı GPU üzerinde tek bir istek için aradaki fark azdır, çünkü her ikisi de aynı aritmetik işlemleri gerçekleştirir. Çok sayıda eşzamanlı istek söz konusu olduğunda vLLM çok daha ileridedir; çünkü sürekli toplu işleme (continuous batching), aktif olan her diziyi tek bir ileri geçişte (forward pass) çözerken, Ollama varsayılan olarak bunları sırayla çalıştırır. Yalnızca CPU kullanılan bir makinede bu soru geçerli değildir: Ollama orada çalışır, vLLM ise pratikte çalışmaz.

vLLM, GPU olmadan çalışabilir mi?

Verimli bir şekilde çalışamaz. Standart paketler NVIDIA veya AMD GPU'ları hedefler ve vLLM'in varlık sebebi olan bir hızlandırıcıyı toplu isteklerle sürekli meşgul tutma mantığı, CPU üzerinde geçerliliğini yitirir. Geliştirme çalışmaları için bir CPU arka ucu mevcuttur. Gerçek CPU çıkarımı (inference) için doğrudan Ollama veya llama.cpp kullanılmalıdır.

Ollama ve llama.cpp arasındaki fark nedir?

llama.cpp bir çıkarım kütüphanesidir ve GGUF bunun nicelenmiş (quantized) ağırlık formatıdır. Ollama'nın çalıştırıcısı bunun üzerine inşa edilmiştir ve llama.cpp'nin kullanıcıya bıraktığı kısımları ekler: bir model kayıt defteri, otomatik indirme, arka planda çalışan bir sunucu, bir systemd birimi ve OpenAI uyumlu bir uç nokta. Ollama, bazı yeni model aileleri için kendi motorunu eklemiştir, bu nedenle ikisi artık temel düzeyde tamamen aynı değildir.

vLLM, 8B bir model için ne kadar GPU belleğine ihtiyaç duyar?

16-bit hassasiyette sadece ağırlıklar yaklaşık 16 GB yer kaplar (milyar parametre başına yaklaşık 2 GB) ve KV önbelleğinin bunun üzerinde bir alana ihtiyacı vardır. 24 GB'lık bir kart rahat bir kullanım sağlar. 16 GB'lık bir kart, nicelenmiş bir kontrol noktası (checkpoint) veya daha küçük bir model gerektirir. vLLM, Temmuz 2026 itibarıyla varsayılan değeri 0.92 olan --gpu-memory-utilization ile belirlenen kartın bir kısmını kullanır.

Bunlar arasında geçiş yapmak için uygulama kodumu değiştirmem gerekir mi?

Genellikle sadece temel URL, API anahtarı ve model adını değiştirmeniz yeterlidir. Ollama, OpenAI uyumlu arayüzünü http://127.0.0.1:11434/v1 adresinde sunar ve anahtarı görmezden gelir; vLLM ise http://localhost:8000/v1 adresinde sunar ve eğer bir anahtar ayarladıysanız bunu zorunlu tutar. Model adlarının biçimleri farklıdır: Ollama için llama3.1:8b, vLLM için ise Qwen/Qwen2.5-1.5B-Instruct gibi tam bir depo kimliği kullanılır.