LLM’leri local çalıştırırken üç isim sürekli karşımıza çıkıyor:
- vLLM
- SGLang
- llama.cpp
Üçü de aynı işi yapıyor gibi görünüyor: modeli yükle, API aç, prompt gönder, cevap al.
Ama teknik olarak çok farklı felsefeleri var. Özellikle büyük modeller, MoE modeller, uzun context, tool calling, GPU/CPU offload ve local workstation kullanımı söz konusu olduğunda aralarındaki fark ciddi hale geliyor.
Bu yazıda özellikle şu soruya odaklanıyorum:
Tek GPU’lu veya ev/ofis tipi güçlü bir makinede, hangisi ne zaman daha mantıklı?
Kısa Özet
Benim pratik gözlemim şöyle:
vLLM = daha olgun, daha stabil, daha geniş model/quant desteği
SGLang = daha agresif, agent/structured generation ve prefix-cache işlerinde güçlü
llama.cpp = GGUF, CPU offload ve “olmayan VRAM’i RAM ile telafi etme” tarafında özel
Eğer model VRAM’e rahat sığıyorsa, vLLM veya SGLang daha hızlı ve server olarak daha profesyonel.
Ama model VRAM’e sığmıyorsa, özellikle de MoE bir modelse, llama.cpp hâlâ çok özel bir yerde duruyor.
1. vLLM Nedir?
vLLM temel olarak bir LLM inference serving engine.
Ana hedefi:
yüksek throughput
düşük latency
OpenAI-compatible API
iyi batching
iyi KV cache yönetimi
çok kullanıcı / çok istek senaryosu
vLLM’in meşhur tarafı PagedAttention. Bu sistem KV cache’i GPU belleğinde daha esnek yönetiyor. Basitçe, KV cache’i büyük tek parça bir alan gibi değil, sayfalara/bloklara bölünmüş bir memory sistemi gibi düşünüyor.
Bu sayede:
daha az memory fragmentation
daha çok eş zamanlı request
uzun context’lerde daha iyi memory kullanımı
continuous batching
mümkün oluyor.
vLLM ayrıca OpenAI-compatible API tarafında çok olgun. Yani birçok client, agent framework, UI veya backend için drop-in replacement gibi çalışabiliyor.
2. SGLang Nedir?
SGLang de bir inference server ama biraz farklı bir felsefeye sahip.
Sadece “model serve edeyim” değil, aynı zamanda:
structured generation
agentic workflows
prefix reuse
branching generation
tool use
multi-step LLM programs
gibi işlerde daha iddialı.
SGLang’in en önemli teknik fikri RadixAttention.
Bunu şöyle düşünebiliriz:
vLLM KV cache’i iyi yönetir.
SGLang ise özellikle tekrar eden prompt prefix’lerini daha akıllı kullanmaya çalışır.
Mesela her request şu yapıya sahipse:
uzun system prompt
aynı tool schema
aynı browser state
aynı agent kuralları
farklı küçük user instruction
SGLang bu ortak prefix’leri tekrar tekrar hesaplamak yerine cache’ten daha agresif faydalanabilir.
Bu yüzden browser agent, coding agent, tool-heavy agent gibi işlerde SGLang ilginç hale geliyor.
3. llama.cpp Nedir?
llama.cpp bambaşka bir dünya.
vLLM ve SGLang daha çok:
Python
PyTorch
CUDA
Triton
server/inference framework
tarafında dururken, llama.cpp daha düşük seviyeli ve portable bir runtime.
Ana avantajları:
GGUF formatı
CPU + GPU hybrid çalışma
çok geniş platform desteği
Windows’ta daha rahat kullanım
quantized model çalıştırmada esneklik
VRAM yetmeyince RAM’e yaslanabilme
Özellikle consumer hardware kullananlar için llama.cpp çok değerli.
Çünkü her zaman ideal datacenter setup yok. Bazen elde şunlar var:
1 adet RTX 3090 / 4090 / 5090
128GB veya 256GB sistem RAM’i
Windows veya WSL
garip quantized GGUF model
çok büyük MoE model
Bu durumda llama.cpp çok pratik olabiliyor.
4. En Kritik Fark: CPU Expert Offload
Bence local kullanıcı için en önemli teknik farklardan biri bu.
Özellikle MoE modellerde.
MoE, yani Mixture of Experts, modelin tamamının her token’da aktif olmadığı mimari. Modelde birçok expert var ama her token için bunların sadece bazıları kullanılıyor.
Örnek:
Toplam model: 100B parametre
Aktif parametre: 10B-20B civarı
Her token’da sadece bazı expert’ler kullanılıyor
Teoride bu çok güzel. Ama pratikte modelin bütün expert ağırlıkları bellekte durmak zorunda olduğu için VRAM ihtiyacı devasa olabiliyor.
İşte burada llama.cpp’in avantajı çıkıyor.
5. llama.cpp’in MoE CPU Offload Avantajı
llama.cpp’te bazı MoE modeller için şuna benzer kullanım mümkün:
-ngl 999 --n-cpu-moe 20
Kabaca anlamı:
mümkün olduğunca çok layer’ı GPU’ya koy
ama bazı MoE expert kısımlarını CPU RAM’de tut
Bu çok önemli.
Çünkü consumer GPU’larda VRAM sınırlı:
RTX 3090 = 24GB
RTX 4090 = 24GB
RTX 5090 = 32GB civarı
Ama sistem RAM’i çok daha yüksek olabilir:
128GB
192GB
256GB
512GB
llama.cpp bu RAM’i gerçekten işe yarar şekilde kullanabiliyor.
Sonuç:
Model tam VRAM’e sığmasa bile çalışabilir.
Hız düşer.
Ama çalışır.
Bence ev tipi LLM rig’lerinde bu çok büyük fark.
Çünkü “yavaş ama çalışıyor” ile “hiç yüklenmiyor” arasında uçurum var.
6. vLLM’de CPU Offload Var mı?
Evet, var.
vLLM’de şöyle bir parametre var:
--cpu-offload-gb 16
Bu GPU belleğini sanal olarak büyütmek gibi düşünülebilir. Mesela 24GB VRAM’li bir kartta 16GB CPU offload kullanırsanız, model bazı ağırlıkları CPU RAM’de tutup forward sırasında GPU’ya taşıyabilir.
Ama bu, llama.cpp’teki MoE expert offload kadar zarif değil.
vLLM’in CPU offload’u daha genel bir weight offload sistemi gibi:
modelin bazı parçaları CPU’da
ihtiyaç oldukça GPU’ya taşınıyor
Ama llama.cpp tarafındaki gibi:
özellikle MoE expert’lerini CPU’da tut
aktif/shared kısımları GPU’da tut
routing’e göre çalıştır
mantığı kadar pratik ve granular değil.
Kısaca:
vLLM CPU offload yapabilir.
Ama llama.cpp gibi MoE expert offload konusunda özel ve pratik değildir.
7. SGLang’de CPU Expert Offload Var mı?
SGLang’de de CPU offload parametreleri var.
Örneğin şuna benzer ayarlar bulunuyor:
--cpu-offload-gb
--offload-group-size
--offload-num-in-group
--offload-prefetch-step
--offload-mode cpu
Ama yine aynı durum var.
Bu ayarlar daha çok layer/group seviyesinde offload için.
Yani pratikte SGLang de şu noktada llama.cpp gibi değil:
MoE expert’lerinin belirli kısmını CPU’da tutayım,
shared/dense kısımlar GPU’da kalsın,
model büyük de olsa tek GPU + bol RAM ile çalışsın.
Bu konuda llama.cpp hâlâ özel.
Benim pratik sıralamam şöyle:
Çok büyük MoE + tek GPU + bol RAM:
llama.cpp
Model VRAM’e sığıyor + hızlı OpenAI API lazım:
vLLM veya SGLang
Agent/prefix reuse/structured output önemli:
SGLang
Garip quantized HF model / maksimum uyumluluk:
vLLM
GGUF ve CPU-RAM destekli deney:
llama.cpp
8. KV Cache Karşılaştırması
LLM inference’ta sadece model ağırlıkları değil, KV cache de çok önemli.
Özellikle uzun context’te.
Bir model 32K, 64K, 128K context ile çalışıyorsa, KV cache ciddi VRAM yer.
vLLM: PagedAttention
vLLM’in PagedAttention sistemi KV cache’i bloklar halinde yönetir.
Avantaj:
daha iyi bellek kullanımı
çok request senaryosunda daha az fragmentation
continuous batching için uygunluk
Bu yüzden vLLM production serving için çok güçlü.
SGLang: RadixAttention
SGLang’in RadixAttention yaklaşımı ise ortak prompt prefix’lerini yeniden kullanmaya daha odaklı.
Örneğin:
aynı system prompt
aynı tool listesi
aynı web page state’i
aynı browser instruction
farklı küçük user mesajları
Bu tip workload’larda SGLang ciddi avantaj sağlayabilir.
llama.cpp
llama.cpp de KV cache kullanıyor ama vLLM/SGLang kadar server-scale batching ve multi-request optimizasyonu için tasarlanmış değil.
llama.cpp daha çok:
tek kullanıcı
local inference
GGUF
CPU/GPU hybrid
VRAM yetmeyince RAM desteği
tarafında parlıyor.
9. Batching ve Scheduler
vLLM
vLLM’in scheduler’ı çok olgun.
Şunları iyi yapıyor:
continuous batching
prefill/decode karışımı
chunked prefill
çok eş zamanlı kullanıcı
OpenAI API uyumu
Eğer bir modeli API olarak servis edecekseniz ve farklı client’lardan request gelecekse, vLLM güvenli seçim.
SGLang
SGLang’in scheduler’ı daha çok cache reuse ve structured generation tarafında avantajlı.
Özellikle agent loop’larında:
düşün
tool çağır
sonucu oku
tekrar düşün
başka tool çağır
aynı context’i tekrar kullan
gibi akışlarda SGLang’in prefix reuse mantığı anlamlı olabilir.
llama.cpp
llama.cpp de server modunda çalışabilir ama vLLM/SGLang gibi high-throughput serving motoru değildir.
Bana göre llama.cpp server olabilir ama asıl gücü:
local model çalıştırma
GGUF deneme
CPU/GPU karışık inference
çok büyük modeli bir şekilde ayağa kaldırma
10. Quantization Desteği
vLLM
vLLM bu konuda genellikle daha güvenli.
Desteklediği quantization formatları oldukça geniş:
GPTQ
AWQ
FP8
INT4
INT8
ModelOpt
Marlin
GGUF tarafında bazı destekler
compressed-tensors
Özellikle Hugging Face’ten gelen quantized modellerde vLLM çoğu zaman ilk denenmesi gereken seçenek.
Mesela:
AutoRound
GPTQ-Marlin
AWQ
NVFP4
ModelOpt
gibi formatlarda vLLM genellikle daha olgun hissettiriyor.
SGLang
SGLang de quantization destekliyor ama bazı kombinasyonlarda daha seçici olabilir.
Eğer model tam destekleniyorsa çok hızlı olabilir. Ama “bu garip quant acaba çalışır mı?” sorusunda vLLM daha güvenli.
llama.cpp
llama.cpp tarafında dünya daha çok GGUF etrafında dönüyor.
Burada avantaj:
çok farklı quant seviyeleri
Q4_K_M
Q5_K_M
Q6_K
IQ quant’lar
CPU/GPU hybrid
Dezavantaj:
HF modelini doğrudan çalıştırmak yerine GGUF dönüştürülmüş model gerekir
11. Tool Calling ve Reasoning Parser
Bu özellikle Qwen, DeepSeek, tool-use modelleri için önemli.
vLLM
vLLM OpenAI-compatible tool calling tarafında daha olgun.
Örneğin Qwen tarzı modeller için:
--reasoning-parser qwen3
--enable-auto-tool-choice
--tool-call-parser qwen3_xml
gibi ayarlar kullanılabiliyor.
OpenAI API uyumluluğu önemliyse vLLM daha az sürpriz çıkarır.
SGLang
SGLang’de de parser seçenekleri var:
--reasoning-parser qwen3
--tool-call-parser qwen
Ama parser isimleri ve çıktı formatları birebir vLLM ile aynı değil.
Bu yüzden agent kullanıyorsanız mutlaka şu testleri yapmak lazım:
tool call JSON doğru geliyor mu?
arguments parse edilebiliyor mu?
streaming sırasında tool call bozuluyor mu?
reasoning text ayrı geliyor mu?
client bunu OpenAI gibi okuyabiliyor mu?
llama.cpp
llama.cpp tool calling tarafında daha manuel kalabilir.
Bazı server/client kombinasyonları destek verse de vLLM ve SGLang kadar “OpenAI-compatible tool server” mantığında değildir.
12. Multimodal / Vision
vLLM ve SGLang multimodal modelleri çalıştırabiliyor.
vLLM tarafında şu tarz ayarlar görebiliyoruz:
--limit-mm-per-prompt '{"image": 4, "video": 1}'
SGLang de multimodal destekliyor ama modelden modele ayarlar değişebilir.
llama.cpp tarafında ise genellikle:
GGUF model
mmproj dosyası
vision projector
mantığı var.
Vision model denemelerinde llama.cpp çok pratik olabilir ama production API için vLLM/SGLang daha düzenli.
13. Windows Desteği
Bu da local kullanıcı için önemli.
llama.cpp
Windows’ta en rahat çalışan seçenek genellikle llama.cpp.
Native binary, CUDA build, ROCm/Metal/CPU build gibi birçok varyasyon var.
Windows kullanıyorsanız ve “hemen çalışsın” diyorsanız llama.cpp çok pratik.
vLLM
vLLM native Windows desteklemez denebilir.
Pratik yol:
Windows 11
WSL2 Ubuntu
NVIDIA driver
CUDA
vLLM
veya Docker + WSL2.
SGLang
SGLang de native Windows-first değil.
En mantıklı yol yine:
WSL2 Ubuntu
Docker
Linux environment
Kısaca:
Windows native:
llama.cpp daha rahat
Windows + WSL2:
vLLM ve SGLang mantıklı
Native Windows Python:
vLLM/SGLang için uğraşmaya değmez
14. Hangi Dilde Yazılmışlar?
vLLM
vLLM büyük ölçüde:
Python
PyTorch
C++
CUDA
Triton
ile yazılmıştır.
Python tarafı:
server
scheduler
API
model integration
config
orchestration
işlerini yapar.
C++/CUDA/Triton tarafı:
attention kernels
custom ops
fast path inference
memory operations
gibi performans kritik işleri yapar.
SGLang
SGLang de benzer şekilde:
Python
PyTorch
CUDA
C++
Triton
kullanır.
Ayrıca SGLang tarafında bazı router / non-GPU infra bileşenlerinde Rust’a doğru ilgi veya geçiş çalışmaları da var.
Ama ana runtime hâlâ Python + CUDA/Triton/PyTorch dünyasında.
llama.cpp
llama.cpp ise çok farklı:
C
C++
CUDA / Metal / HIP / Vulkan backend’leri
Bence llama.cpp’in pratik gücü de burada.
Daha düşük seviyeli, daha taşınabilir, daha az Python/PyTorch bağımlı.
Bu yüzden:
Windows’ta daha rahat
CPU’da çalışabilir
GPU ile hybrid çalışabilir
çok değişik cihazlarda koşabilir
15. 5090 / 3090 / Consumer Rig için Pratik Tavsiye
Eğer elinizde şuna benzer bir makine varsa:
RTX 5090
128GB-256GB RAM
Windows 11 + WSL2
tek GPU veya birkaç consumer GPU
benim tavsiyem şu olur:
vLLM’i ana server olarak tut
Özellikle:
Qwen
Gemma
Llama
AutoRound
GPTQ-Marlin
AWQ
OpenAI-compatible API
tool calling
için.
vLLM daha güvenli default.
SGLang’i benchmark ve agent workload için dene
Özellikle:
browser agent
WebBrain tarzı workflow
aynı uzun system prompt’un tekrar kullanılması
tool schema reuse
structured output
Qwen/DeepSeek hot-path
için.
SGLang bazı işlerde vLLM’den daha iyi sonuç verebilir.
llama.cpp’i mutlaka kenarda tut
Özellikle:
GGUF modeller
çok büyük MoE modeller
CPU expert offload
VRAM yetmediği durumlar
Windows-native kullanım
hız değil “çalışsın yeter” senaryosu
için.
llama.cpp local LLM dünyasının İsviçre çakısı gibi.
16. En Net Karar Tablosu
| Senaryo | En Mantıklı Seçenek |
|---|---|
| OpenAI-compatible stabil API | vLLM |
| Çok farklı HF quant model denemek | vLLM |
| Agent / browser automation / prefix reuse | SGLang |
| Structured generation / constrained output | SGLang veya vLLM |
| Büyük GGUF model | llama.cpp |
| Model VRAM’e sığmıyor ama RAM çok | llama.cpp |
| MoE expert CPU offload | llama.cpp |
| Çok kullanıcı production serving | vLLM |
| DeepSeek/Qwen MoE performans denemeleri | SGLang + vLLM benchmark |
| Windows native kullanım | llama.cpp |
| WSL2/Linux server | vLLM veya SGLang |
Sonuç
vLLM, SGLang ve llama.cpp aynı kategoride görünse de aslında farklı ihtiyaçlara cevap veriyorlar.
Benim güncel teknik kanaatim:
vLLM = güvenli, olgun, production-friendly inference server
SGLang = daha deneysel/agresif, agent ve prefix-cache workload’larında çok ilginç
llama.cpp = local hacker tool’u; GGUF, CPU offload ve büyük modeli bir şekilde çalıştırma kralı
Özellikle son nokta önemli:
vLLM ve SGLang CPU offload yapabilir, ama llama.cpp’in MoE expert offload yaklaşımı local consumer hardware için hâlâ çok özel.
Bir model VRAM’e tam sığıyorsa vLLM/SGLang kullanmak daha mantıklı.
Ama model çok büyükse, MoE ise ve elinizde bol sistem RAM’i varsa, llama.cpp hâlâ oyunu değiştiriyor.
Bence ideal setup tek bir runtime seçmek değil.
İdeal setup şu:
vLLM -> ana OpenAI-compatible server
SGLang -> agent/prefix-cache/structured output benchmark server
llama.cpp -> GGUF, MoE CPU offload ve “bunu bir şekilde çalıştıralım” fallback’i
Local LLM işi biraz böyle:
bazen en hızlı motor kazanır, bazen en uyumlu motor kazanır, bazen de sadece modeli yükleyebilen motor kazanır.
Bir yanıt yazın