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 modellerin çoğu, genellikle 4-bit nicelenmiş (quantized) GGUF dosyalarıdır; bu nedenle 7B veya 8B boyutundaki bir model diskte 16 GB yerine yaklaşık 5 GB yer kaplar. Niceleme, CPU çıkarımı (inference) için gereken bellek miktarını azaltır. Apple Silicon Mac cihazlarda MLX motoru aracılığıyla safetensors tabanlı modelleri de çalıştırabilir ve v0.40.0 (Eylül 2026) sürümünden itibaren desteklenen mimariler MLX üzerinde otomatik olarak çalışır.

GGUF çalıştırıcısı, GGUF nicelemesini standart donanımlar üzerinde pratik hale getiren C++ çıkarım kütüphanesi llama.cpp üzerine inşa edilmiştir. Ekim 2026 itibarıyla Ollama, llama.cpp ve MLX olmak üzere iki motoru destekler; Linux sürümleri ise CUDA ile MLX çıkarımını desteklemektedir. Geliştirme kılavuzu, CUDA 13+ ve cuDNN 9+ ön koşullarıyla bu arka ucu cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13 ile etkinleştirir. Dolayısıyla insanlar Ollama ile llama.cpp'yi kıyasladıklarında, aslında bir ergonomi katmanını, onun sarmaladığı araçla karşılaştırmaktadırlar.

Tasarım hedefi tek bir kullanıcıdır. Ekim 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ü yerel API herhangi bir kimlik doğrulama gerektirmez.

vLLM nedir

vLLM yalnızca bir çıkarım (inference) sunucusudur. Bir model kütüphanesini yönetmez, çalışan bir sunucu için vllm chat istemcisi sağlar ve istek anında sizin için bir model çekmez. Başlatma sırasında bir Hugging Face deposu belirtirsiniz, o modeli yükler ve siz süreci durdurana kadar sunar.

Bu kısıtlı kapsamın sağladığı avantaj iş hacmidir (throughput). İki mekanizma bu işi yapar. PagedAttention, KV önbelleğini (anahtar-değer önbelleği, bir modelin her aktif istek için tuttuğu token başına dikkat durumu) işletim sistemlerinin belleği sayfaladığı gibi sabit boyutlu bloklar halinde saklar. Bir istek artık en kötü durum için ayrılmış büyük ve bitişik bir bellek alanına ihtiyaç duymaz; böylece daha önce 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şin bitmesini beklemeden bir sonraki kod çözme adımında çalışan toplu işe katılmasına olanak tanır. Tamamlanan bir dizi toplu işten hemen ayrılır 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 miktarını keskin bir şekilde artırırken, kullanıcı başına hız beklenenden çok daha az düşer. Ollama'nın varsayılan ayarlarında ise birden otuz kullanıcıya çıkmak, sadece yirmi dokuz kişinin beklemesine neden olur.

Sürekli batching her şeyi belirler

Aynı donanım üzerinde her sunucuya aynı anda ulaşan beş istek olduğunu düşünün.

Ollama, varsayılan ayarlarla ilk isteği tamamlanana kadar işler, ardından ikinci isteğe geçer ve bu şekilde devam eder. Beşinci isteği gönderen istemci, dört tam üretimin tamamlanmasını bekler. Toplam throughput, yaklaşık olarak tek bir üretimin hızına eşittir; çünkü işlemci aynı anda yalnızca bir sequence üzerinde çalışır.

vLLM, beş isteğin tamamını aynı forward pass içinde decode eder. Beş sequence için bir token üretmenin maliyeti, tek bir sequence için bir token üretmekten çok az daha fazladır. Bunun nedeni, maliyetli işlemin model weight'lerini bellekten okumak olmasıdır ve bu okuma batch'in tamamı arasında paylaşılır. CPU inference işlemini yavaşlatan bellek bant genişliği gerçeği de aynıdır: maliyet aritmetik işlemlerden değil, weight'lerin taşınmasından kaynaklanır.

OLLAMA_NUM_PARALLEL=4 ayarını yapılandırarak bunun bir bölümünden yararlanılabilir. Bunun bedeli bellektir. Her paralel slot kendi KV cache alanına ihtiyaç duyar ve Ollama context allocation değerini bölmek yerine çarpar: FAQ sayfasında gerekli RAM'in OLLAMA_NUM_PARALLEL ile OLLAMA_CONTEXT_LENGTH çarpımına göre ölçeklendiği belirtilir. Bu nedenle 8192 token için yapılandırılmış bir modelle dört paralel istek çalıştırıldığında her istek 8192 token tutar; ancak sunucunun toplamda 32768 token için cache barındırması gerekir. 8192 değeri de sabit bir gereklilik değil, bir tercihtir. Bu nedenle num_ctx değerini artırmak ve bunun gerektirdiği RAM'i boyutlandırmak, dört slotun gerçekten sığıp sığmayacağını belirleyen adımdır. vLLM'nin paged cache yapısı, her slot için pencerenin tamamını başlangıçta ayırma gereğini ortadan kaldırır; çünkü bloklar, istek gerçekten büyüdükçe o isteğe atanır. Her iki durumda da tek bir sunucunun aynı anda hizmet verebileceği kişi sayısının üst sınırı KV cache boyutuna, prefill maliyetine ve queue depth değerine bağlıdır. Bu durum, tek kişi için yeterli görünen bir sunucunun beş kişide neden yavaşladığını açıklar.

Ollama ile kurulum ve sunma

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 system user oluşturur, binary dosyasını kurar ve 127.0.0.1:11434 adresine bağlı ollama.service kaydını oluşturur. --verbose tarafından yazdırılan eval rate satırı, bu sistemdeki gerçek saniye başına token değeridir. Yayımlanmış değerlerden çok bu ölçüme güvenilmelidir. Tek bir istemden alınan tek ölçüm, kapasite değeri değil başlangıç noktasıdır. Bu nedenle eşzamanlılık aralığı boyunca saniye başına token değerini ölçmek, sistemin beklenen yükte dayanıp dayanmadığını ve GPU kiralamanın token başına ödeme yapmaktan daha avantajlı olup olmadığını gösterir.

Eşzamanlılığı artırmak için systemd drop-in dosyası kullanılmalıdır. Böylece yükseltme işlemi bu değişikliği ü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 yüklü olanı gösterir ve PROCESSOR sütunu gerçek durumu belirtir. 100% CPU, GPU kullanılmadığı anlamına gelir. Ollama'nın yavaş olduğuna ilişkin raporların çoğunun gerçek nedeni budur. Bu drop-in içindeki OLLAMA_KEEP_ALIVE=30m satırı, sistem düşük yükteyken de aynı ölçüde önemlidir. Çünkü varsayılan değer, istek gelmediğinde modeli beş dakika sonra bellekten çıkarır. İstekler arasında modeli bellekte tutmak, durgunluk sonrasında gelen ilk istemin yeniden tam yükleme süresini ödemesini engeller. Durgunluk dönemleri bundan uzun sürüyorsa daha uzun bir değer ayarlanmalıdır.

vLLM kurulumu ve servisin başlatılması

vLLM'in GPU sürümleri Linux gerektirir (Apple Silicon üzerindeki macOS, 0.32.0 sürümünde önceden derlenmiş bir paketle yalnızca CPU desteği sunar; bu cihazlarda GPU hızlandırması, MLX üzerine inşa edilmiş ve topluluk tarafından sürdürülen ayrı bir eklenti olan vLLM-Metal ile sağlanır). Python tarafında, güncel sürüm (0.32.0, Ekim 2026) 3.11 ile 3.14 arasındaki sürümleri desteklemektedir ve kurulum kılavuzu da aynı aralığı belirtir. Python 3.10 desteği 0.32.0 ile kaldırıldığı için aşağıda kullanılan 3.12 sürümü güvenli tercihtir. vLLM, belirli bir PyTorch sürümünü bağımlılık olarak çektiği için kurulumu kendi sanal ortamına yapın:

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

Son satır, Ekim 2026 itibarıyla vLLM'in NVIDIA kurulum kılavuzunda yer almaktadır. Bu komut, FlashInfer'in önceden derlenmiş çekirdeklerini kurar. Bu çekirdekler olmadan vLLM, başlangıçta çekirdekleri indirip derler; kılavuza göre bu işlem Hopper ve daha yeni GPU'larda süreci birkaç dakika uzatabilir. FlashInfer, çekirdek sürümleri uyuşmadığında içe aktarma işlemini reddettiği için, her vLLM yükseltmesinden sonra bu komutu tekrar çalıştırın.

Ardından bir model sunun. Model adı, kısa bir etiket değil, Hugging Face depo kimliğidir:

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

Ağırlıklar indirildikten sonra GPU profillenerek kaç adet KV cache bloğunun sığacağına karar verildiği için ilk başlatma yavaştır. Servis 8000 numaralı portu dinler. Herhangi bir istemci kodu yazmadan önce servisi 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 parametresi, container'a ana makinenin paylaşılan belleğine erişim sağlar; --shm-size değerini artırmak da bir diğer seçenektir. PyTorch, özellikle tensor-parallel çıkarım işlemleri sırasında tensor'ları süreçler arasında paylaşılan bellek üzerinden aktarır.

Üretim ortamında en önemli bayraklar şunlardır: --max-model-len (kullanmayı hedeflediğiniz bağlam penceresi), --gpu-memory-utilization (vLLM'in kart üzerinde talep edebileceği oran, Ekim 2026 itibarıyla varsayılan değer 0.92'dir), tek bir modeli birden fazla GPU'ya bölmek için --tensor-parallel-size ve --api-key.

Kimlik doğrulama vLLM üzerinde bir bayrak iken Ollama'nın yerel API'sinde mevcut değildir

vLLM, kendisine bir tane verdiğiniz 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 gelebilir. Bu değişken olmadan /v1 rotalarına yapılan bir istek HTTP 401 hatası döndürür. Ancak anahtar tüm sunucuyu kapsamaz. vLLM güvenlik kılavuzu ve 0.32.0 kaynak kodundaki kimlik doğrulama mantığı, bunu yalnızca /v1, /v2, /inference ve /cohere yol önekleri altındaki uç noktalar için uygular. vllm serve sayfasındaki --api-key yardım metni yalnızca ilk üçünü listeler ancak kod dördünü de kontrol eder. Hem kılavuz hem de yardım metni, /v1 ile aynı çıkarım (inference) işlemini sunan /invocations gibi diğer uç noktaların kimlik doğrulamaya tabi olmadığını belirtir. Bu durum, 8000 numaralı portu genel bir arayüzde dış dünyaya açmamak için yeterli bir nedendir. vLLM güvenlik kılavuzu ayrıca hız sınırlamayı (rate limiting) önündeki bir reverse proxy'ye bırakır ve düz HTTP üzerinden gönderilen bir token aktarım sırasında okunabilir; yine de bu bayrak, sunucunun bir çağırıcı kavramına sahip olduğu anlamına gelir.

Ollama'nın yerel API'si kimlik doğrulama gerektirmez. Bulut modelleri, model yayınlama ve özel model indirmeleri oturum açmayı gerektirir; ollama.com'a doğrudan API erişimi bir API anahtarı gerektirir. 11434 numaralı porta erişebilen herhangi bir süreç model çalıştırabilir, çekebilir veya silebilir. Servisi loopback üzerinde tutun ve ona kendi barındırdığınız bir WireGuard VPN üzerinden veya TLS (transport layer security) sonlandırması yapan kimlik doğrulamalı bir reverse proxy aracılığıyla erişin.

Donanım: her biri ne gerektirir

Ollama CPU üzerinde çalışır. 4 bit kuantize edilmiş bir model, her bir milyar parametre için yaklaşık yarım GB RAM kullanır. Buna yaklaşık 1 GB çalışma zamanı ek yükü ve bağlam için gereken ek bellek dahildir. Bu nedenle 3B bir model için yaklaşık 4 GB, 8B bir model için yaklaşık 8 GB boş bellek gerekir. Paylaşımlı bir vCPU üzerindeki hız, saniyede tek haneli ile düşük çift haneli token aralığındadır. Bunun nedeni bellek bant genişliğidir; bir yanlış yapılandırma söz konusu değildir ve hiçbir flag bunu düzeltemez. Bu hesabın yaklaşık bir kural yerine belirli bir sürümde nasıl gerçekleştiğini görmek için bir VPS üzerinde Nemotron 3.5 Lightning çalıştırma içeriği, çekilecek tam etiketi, model yüklendikten sonra kullandığı RAM miktarını ve yalnızca CPU kullanımının kabul edilebilir hızda olup olmadığını netleştirir.

vLLM bir GPU varsayar. Varsayılan yol, ağırlıkları 16 bit duyarlıkta ve kuantize edilmemiş olarak sunar. Bu, her bir milyar parametre için yaklaşık 2 GB anlamına gelir. 8B bir model, yalnızca ağırlıklar için yaklaşık 16 GB video belleği gerektirir. Buna, vLLM'yi kurma nedeniniz olan eşzamanlı istekleri sağlayan KV önbelleği dahil değildir. 24 GB'lık bir kartta kullanılabilir bir önbellek için yeterli alan kalır. 16 GB'lık bir kartta bu alan kalmaz. Bu durumda daha küçük bir model seçilir, --quantization geçirilir (kuantize edilmiş bir checkpoint ile veya tam duyarlıklı ağırlıkları yükleme sırasında kuantize etmek için) ya da ağırlıkların bir bölümü --cpu-offload-gb ile sistem RAM'ine taşınır. Bu işlem ağırlıkların duyarlığını korur ancak daha yavaştır. Bunun nedeni, her forward pass sırasında bu ağırlıkların GPU'ya aktarılmasıdır. Ayrı wheel paketleriyle birlikte bir CPU backend'i de vardır. Ancak bu backend, vLLM çalıştırma gerekçesini ortadan kaldırır.

Bu nedenle donanım sorusu çoğu zaman yazılım sorusunu da yanıtlar. GPU yoksa Ollama kullanılır. Kiralanan bir GPU, istekler seri işlendiği için yüzde 5 kullanımda kalıyorsa vLLM kullanılır.

İş 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 dizgiler

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

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

Model, ağırlıklar yüklendikten sonra kalan bellekten daha büyük bir bağlam penceresi (context window) tanımlıyor. Bunu --max-model-len 8192 ile düşürün veya kartı başka hiçbir şey kullanmıyorsa --gpu-memory-utilization değerini yükseltin.

Ollama, üretim sırasında Killed çıktısı veriyor. Linux bellek yetersizliği (OOM) sonlandırıcısı, modelin sistemin sahip olduğundan daha fazla RAM'e ihtiyaç duyması nedeniyle süreci durdurdu. Bunu sudo dmesg | grep -i oom ile doğrulayın. Çözüm bir ayar değil, daha küçük veya daha yoğun 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. OLLAMA_NUM_PARALLEL=1 istekleri sıraya dizdiği için, istek sayısı arttıkça yanıt süreleri uzuyor. Uzun yanıtlar kuyruğu daha da kötüleştirir; çünkü model durmaya karar verene kadar tek bir yuvayı (slot) işgal eden bir 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 tavan getirir. Paralel ayarını yükseltin ve her yuvanın bağlamının gerektirdiği ek RAM maliyetini kabul edin ya da iş yükünü vLLM'e taşıyın.

vLLM, her /v1 çağrısında 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ğiyle veya ayarladıysanız --served-model-name değeriyle eşleşmelidir. Tam dizgiyi 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 her ikisinin de desteklenen çıkarım yolları mevcuttur; vLLM bu durumda ayrı CPU paketleri (wheels) kullanır.

vLLM GPU olmadan çalışabilir mi?

Evet, CPU arka ucu aracılığıyla çalışabilir. Standart paketler NVIDIA veya AMD GPU'ları hedefler; vLLM'in varlık sebebi olan bir hızlandırıcıyı toplu isteklerle dolu tutma gerekliliği, CPU üzerinde ortadan kalkar. x86 ve Arm için ayrı paketlere sahip bir CPU arka ucu mevcuttur. Gerçek CPU çıkarımı için doğrudan Ollama veya llama.cpp kullanılması önerilir.

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, GGUF çıkarımı için bu kütüphaneyi kullanır ve üzerine bir model kayıt defteri, etiketli indirmeler, model yönetimi ve bir systemd birimi ekler. Ollama ayrıca Apple Silicon üzerinde safetensors tabanlı modelleri çalıştıran bir MLX motoru sunar ve Linux üzerinde CUDA derlemelerini destekler; bu nedenle ikisi altta yatan yapıda her zaman aynı değildir.

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

16-bit hassasiyette yalnızca 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 kapasiteli bir kart rahat bir kullanım sağlar. 16 GB kapasiteli bir kart için nicelenmiş bir model, daha küçük bir model veya ağırlıkların bir kısmını sistem RAM'ine hız kaybı pahasına taşıyan --cpu-offload-gb kullanımı gerekir. vLLM, Ekim 2026 itibarıyla varsayılan değeri 0.92 olan --gpu-memory-utilization ile kartın belirli bir kısmını rezerve eder.

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

Genellikle yalnızca 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 hizmet verir ve bir anahtar belirlediyseniz bunu /v1 rotalarında zorunlu tutar. Model adlarının biçimi 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.