Ollama vs vLLM vs TGI 2026: Lokal LLM Serving Karşılaştırması

Ollama vs vLLM tartışması 2026’da artık ikili değil, üçlü bir mesele: Ollama, vLLM ve Hugging Face TGI. Kısa cevap: bireysel geliştirici ve macOS/edge cihazlar için Ollama, GPU sunucularında yüksek throughput üretim trafiği için vLLM, Hugging Face ekosistemi içinde stabil REST API ve telemetri arayan kurumsal ekipler için TGI. Üçü de Apache 2.0 lisanslı, hepsi PagedAttention veya benzeri optimizasyonlardan faydalanıyor; ama mimari öncelikleri, batching davranışı, kuruluma giren saat ve birim token başına maliyet ciddi şekilde ayrışıyor. Bu yazıda üç framework’ün kuantitatif karşılaştırmasını, hangi senaryoda hangisini seçmen gerektiğini ve gerçek üretim trafiğinde karşılaştığım inceltici detayları paylaşıyorum.

2026’ya gelindiğinde lokal LLM serving, “akademik deney” kategorisinden çıkıp finans, sağlık, kamu ve hukuk gibi veri egemenliği zorunlu sektörlerin temel altyapısına dönüştü. Hugging Face Inference Stack istatistiklerine göre TGI 9 bin GitHub yıldızını aştı, vLLM 30 bini geçti, Ollama ise 95 bini devirdi. Yıldız sayısı popülerliğin kaba bir göstergesi; fakat üç projenin de aktif commit frekansı haftalık 50+ seviyesinde. Bu hız, sürüm uyumsuzluğunu da beraberinde getiriyor: Yanlış CUDA toolkit, yanlış driver, yanlış GGUF quant level seçimi 8 saatlik sessiz bir downtime’a kolayca dönüşebiliyor.

Üç Framework Tek Bakışta: Mimari ve Hedef Kitle

Üç framework’ün ayrıştığı temel nokta hedeflenen kullanıcı profili. Ollama Go ile yazılmış, llama.cpp’nin üzerine oturan, “indirip çalıştır” felsefesini benimseyen bir CLI; vLLM Berkeley Sky Computing Lab’tan çıkan, PagedAttention paper’ı (arXiv:2309.06180) ile literatüre giren saf Python ve CUDA kernel’ları üzerine kurulu yüksek throughput motoru; TGI ise Hugging Face’in Rust + Python hibrit, OpenTelemetry yerel destekli production stack’i.

Özellik	Ollama	vLLM	TGI
Çekirdek dil	Go + llama.cpp (C++)	Python + CUDA	Rust + Python
İlk sürüm	Haz 2023	Haz 2023	Tem 2023
Hedef profil	Tek geliştirici, edge	GPU prod throughput	HF ekosistem, REST API
CPU inference	Birinci sınıf	Sınırlı, deneysel	Sınırlı
GPU desteği	NVIDIA + Apple MPS	NVIDIA + AMD ROCm	NVIDIA + AMD ROCm
Quant format	GGUF (q2-q8)	AWQ, GPTQ, FP8	AWQ, GPTQ, EETQ
API formatı	OpenAI-uyumlu /v1/chat	OpenAI-uyumlu /v1/chat	HF Inference + OpenAI
Lisans	MIT	Apache 2.0	Apache 2.0
Aktif sürdürücü sayısı	~250	~600	~120

Tabloyu özetlersek: Ollama tek geliştiricinin cebine sığar (Apple Silicon’da bile 70B-q4 modelleri çalıştırabilir), vLLM data center ölçeğinde yüksek concurrency için tasarlanmış, TGI ise Hugging Face Hub ile bütünleşik ve “kuruma teslim edilebilir” bir paket. Üçünü aynı anda denemek isteyen ekipler için Kurumsal Yapay Zeka Entegrasyonu yazımdaki referans mimari şablonu birim test seviyesinde başlangıç için işe yarayacaktır.

Performance Benchmark: Throughput, Latency ve TTFT

Sayısal karşılaştırma yapmadan teknik bir framework tartışması havada kalır. Aşağıdaki benchmark, A100 80GB üzerinde Llama-3.1-8B-Instruct modeli ile 1024 input + 512 output token uzunluğunda, eşzamanlı 64 client ile yapılan testlerin tipik sonuçlarını gösteriyor (vLLM v0.6+, TGI v3.0+, Ollama v0.5+ sürümlerinde yayımlanan resmi benchmark raporları ve topluluk tekrarlarından derlenmiştir; donanım ve sürücü konfigürasyonuna göre %15-20 sapma normaldir).

Metrik	Ollama (llama.cpp)	vLLM	TGI
Throughput (tokens/sec, batch=64)	~1.200	~5.800	~4.700
Throughput (tokens/sec, batch=1)	~110	~95	~92
TTFT — Time to First Token (ms)	~140	~85	~95
P99 inter-token latency (ms)	~28	~14	~17
GPU VRAM kullanımı	~9 GB (q4_K_M)	~22 GB (FP16)	~22 GB (FP16)
KV-cache evict mekanizması	Yok	PagedAttention	Continuous batching
Maks. concurrent request	~16 pratik	~256+	~128+

Sonuç net: tek-istek yanıt hızında üçü de yakın, fark batch büyüdükçe ortaya çıkıyor. vLLM’in PagedAttention’ı KV-cache parçalanmasını yaklaşık 4× azaltarak aynı GPU’dan 4.5×’e kadar daha fazla token saniyede çıkarmasına izin veriyor. TGI continuous batching ile %85-90 verimliliğe ulaşıyor ama Rust router’ı vLLM’inkinden biraz daha düşük tavan veriyor. Ollama ise batch=1 dünyasının kralı — saatlik 100-200 istek alan iç araçlar için fazlasıyla yeterli.

• Throughput öncelik ise: vLLM birinci, TGI yakın ikinci, Ollama uzak üçüncü.
• Tek-istek latency öncelik ise: Üçü de 100 ms TTFT bandında, fark istatistiksel olarak anlamlı değil.
• VRAM tasarrufu öncelik ise: Ollama (GGUF q4_K_M ile 3-4× daha az VRAM).
• Kuyrukta bekleme süresi (queue time) öncelik ise: vLLM (continuous batching + PagedAttention kombinasyonu).

Kurulum, Operasyon ve Sürdürülebilirlik

Bir framework’ün gerçek maliyeti CUDA driver matching, container imajı boyutu, gözlemlenebilirlik ve upgrade hattıdır. NVIDIA NGC kataloğunda yayımlanan resmi container’lar üzerinden ölçüldüğünde imaj boyutları belirgin şekilde ayrışıyor.

Operasyon kriteri	Ollama	vLLM	TGI
Docker imaj boyutu	~450 MB	~9-12 GB	~7-9 GB
Cold start (ilk model yükleme)	5-15 sn	30-90 sn	25-70 sn
Konfigürasyon yüzeyi	Modelfile (10 satır)	50+ CLI flag	40+ env var
Prometheus metrik	Sınırlı	Yerleşik	Yerleşik + OTel
Distributed inference	Yok	Tensor + Pipeline parallel	Sharded (TP)
Model formatı uyumluluğu	GGUF (dönüştürme gerek)	HF safetensors direkt	HF safetensors direkt
Otomatik model indirme	ollama pull ile tek komut	HF cache mekanizması	HF cache mekanizması
Multi-model serving	Aynı port, dinamik load	Statik (process başına)	Statik (process başına)

Operasyonel anlamda Ollama “sıfır konfigürasyon” felsefesini taşırken vLLM ve TGI “üretim ekibi varsa parlar” mantığı ile geliyor. Hugging Face TGI’ın OpenTelemetry desteği özellikle OpenTelemetry ekosistemine alışık ekipler için tracing, span ve token bazlı kullanım takibini ücretsiz hale getiriyor. vLLM 0.6+ ile gelen Prometheus exporter, e2e_request_latency_seconds, gpu_cache_usage_perc gibi metrikleri kutudan çıkar çıkmaz veriyor.

Quantization ve Bellek Yönetimi: GGUF, AWQ, GPTQ, FP8

Quantization, lokal LLM serving’in en kritik karar düğümü. Yanlış quant level seçimi modelin matematik becerisini %20 düşürebilir; doğru seçim ise GPU VRAM ihtiyacını dörde bölebilir. Üç framework de farklı quant ekosistemlerine yatırım yaptı.

Quant Format	Bit	Ollama	vLLM	TGI	Tipik kalite kaybı
FP16 (baseline)	16	Evet	Evet	Evet	%0
FP8 (Hopper+)	8	Hayır	Evet	Evet	~%1-2
AWQ	4	Hayır	Evet	Evet	~%2-4
GPTQ	4	Hayır	Evet	Evet	~%3-5
GGUF q5_K_M	~5	Evet	Hayır	Hayır	~%2-3
GGUF q4_K_M	~4	Evet	Hayır	Hayır	~%3-5
GGUF q2_K	~2.5	Evet	Hayır	Hayır	~%10-15

1. FP8 ne zaman: H100/H200/B200 GPU varsa, model 70B+ ise, throughput öncelikli ise. vLLM ve TGI’da NVIDIA TransformerEngine üzerinden çalışır.
2. AWQ ne zaman: A100/A6000 sınıfı, kalite kaybına %3 toleransın varsa. Activation-aware olduğu için GPTQ’ya kıyasla long-context’te daha stabil.
3. GGUF ne zaman: Apple Silicon, CPU-only deployment, edge cihaz ya da 24 GB altı consumer GPU (RTX 4090, 3090). q5_K_M kalite/boyut sweet spot.
4. FP16 ne zaman: Fine-tuning ardından doğruluk regresyonu test etmeden önce hep baseline olarak.

Quantization sonrası perplexity ölçümünü atlayan ekipler kaliteyi nereden kaybettiğini anlamadan sahaya iniyor. LLM Özelleştirme yazısında perplexity’yi token-level değil görev-level (MMLU, HumanEval, Türkçe ARC-c) ölçmek için kullandığım üçlü protokol detaylandırılmıştır.

Maliyet Modeli: Token Başına TL Hesabı

Yıllık maliyet karşılaştırması yapmadan “lokal LLM ucuzdur” demek havada kalır. Aşağıdaki tablo Türkiye’deki tipik kiralama fiyatları (RunPod, vast.ai, Hetzner GPU Cloud topluluk fiyatları, 2026 Q1) ile hesaplandı. 1 USD ≈ 38 TL varsayıldı.

Senaryo	Donanım	Aylık maliyet (TL)	Aylık token kapasitesi (yaklaşık)	1M token TL
Ollama, Mac mini M4 Pro, 8B-q4	Tek seferlik 95.000 TL	~1.500 elektrik	~150M (saatte 200 istek)	~10 TL
vLLM, RTX 4090 self-host	Tek seferlik 75.000 TL	~3.000 elektrik	~3B	~1 TL
vLLM, A100 80GB kiralık	RunPod $1.89/sa	~52.000	~12B	~4.3 TL
TGI, A100 80GB kiralık	RunPod $1.89/sa	~52.000	~10B	~5.2 TL
API: GPT-4o-mini (referans)	—	Kullanıma göre	—	~22 TL input/~91 TL output
API: Gemini 2.5 Flash	—	Kullanıma göre	—	~11 TL input/~91 TL output

• Avantaj (lokal): Veri sınır dışına çıkmaz, KVKK / EU AI Act uyum kapısı bir kademe basitleşir, latency stabildir.
• Dezavantaj (lokal): Aylık 1B token altı trafikte amortisman 12-18 aya uzar; küçük ekipte sysadmin maliyeti gizli kalır.
• Ne zaman seç (lokal): Aylık 500M+ token, regülatör baskısı, gizlilik tabanlı satış vaadi.
• Ne zaman seçme (lokal): Aylık 50M altı token, ekipte SRE yok, 1 haftalık MVP hedefi.

Maliyet hesabını sadece donanım üzerinden yapmak yanıltıcı. McKinsey’in “The state of AI in 2025” raporunda kurumların lokal GenAI altyapısında toplam sahip olma maliyetinin (TCO) %40-55’inin operasyon ve gözlemlenebilirlik kalemlerinden geldiği belirtiliyor. Saat bazlı GPU kirası kar topu gibi büyür; gözlemlenebilirlik bütçesini ilk haftadan koy.

Concurrency, Continuous Batching ve PagedAttention

vLLM’in 2024’te yayımladığı PagedAttention algoritması KV-cache’i sayfalanmış sanal bellek mantığıyla yönetir; Linux kernel’inin sayfa tablolarına benzer bir yapı kurarak iç parçalanmayı %96’dan %4’e indirir. TGI’ın continuous batching yaklaşımı ise her token üretiminden sonra batch’i yeniden derler ve tamamlanan istekleri anında kuyruktan düşürür. Ollama bu iki tekniğe sahip değil; her istek FIFO bir kuyrukta beklemek zorunda.

Batching tekniği	Ollama	vLLM	TGI
Static batching	Evet (varsayılan)	Hayır	Hayır
Continuous batching	Hayır	Evet	Evet (varsayılan)
PagedAttention	Hayır	Evet (varsayılan)	Kısmi (FlashAttention ile)
Speculative decoding	Hayır	Evet (v0.6+)	Evet (medusa)
Prefix caching	Sınırlı	Evet (–enable-prefix-caching)	Evet
Chunked prefill	Hayır	Evet	Kısmi

Pratikte bu kalemler şu anlama gelir: 100 eşzamanlı kullanıcılı bir RAG endpoint’inde vLLM’in P99 latency’si 1.8 saniyede kalırken Ollama 12 saniyenin üzerine çıkar. RAG Altyapı Kurulumu yazımda da vurguladığım gibi, batching katmanı seçilmeden retriever optimizasyonuna geçmek erken optimizasyondur.

Güvenlik, Veri Yerleşimi ve Uyum

Lokal LLM serving’in en güçlü argümanı veri kontrolüdür. ENISA’nın 2025 AI Threat Landscape raporu, üretken AI sistemlerinde prompt injection’ı T10 listenin başına yerleştirdi; NIST AI 600-1 generative AI risk profili ise data leakage ve model exfiltration’ı kurumsal gündeme taşıdı. Lokal serving bu risklerin hepsini ortadan kaldırmaz; sadece veri yerleşimini netleştirir.

• Network izolasyonu: vLLM ve TGI varsayılan olarak 0.0.0.0:8000 dinler; mTLS veya reverse proxy (Nginx, Envoy) önüne koymadan açma. Ollama da aynı durumda.
• Auth katmanı: Üç framework de API key veya OAuth desteğini bizzat sağlamaz. Authelia, Keycloak veya cloud provider IAM ile sarmala.
• Rate limit: vLLM ve TGI’da request başına token sınırı vardır ama IP başına RPS yok. Bunu Nginx limit_req veya API gateway’e bırak.
• Logging diskresi: Prompt içeriği log’lara düşerse KVKK madde 6 hassas veri sızdırma riski oluşur. Üç framework’te de prompt loglamayı kapatmayı unutma.
• Model çalma (extraction): Açık ağırlıklı modellerde teknik olarak risk düşük; ama fine-tuned varyantlar IP kategorisine girer, output sınırlaması ve query rate kontrolü gerekir.

NIST’in AI Risk Management Framework dokümanı ve ENISA’nın tehdit panoraması her sürüm yükseltmesinde kontrol listesi olarak kullanılmalı. Ayrıca AI Act’in yüksek riskli sistemler için getirdiği log saklama yükümlülüğü, lokal serving’i avantajdan zorunluluğa dönüştürebilir.

Hangisini Ne Zaman Seçmeli: Karar Matrisi

Üç framework’ün ideal kullanım hattını net çizmek için 8 senaryoluk bir karar matrisi:

Senaryo	Önerilen	Sebep
Tek geliştirici, MacBook M-serisi	Ollama	Tek komut, Apple MPS yerel
İç PoC, <10 kullanıcı, RTX 4090	Ollama veya vLLM	İkisi de tek GPU’da çalışır
200+ eşzamanlı kullanıcı, A100×2	vLLM	PagedAttention + TP
HF Hub’tan model dağıtımı zorunlu	TGI	HF Inference Endpoint paritesi
OpenTelemetry, Grafana stack var	TGI	OTel yerleşik
Multi-model dinamik yükleme	Ollama	Aynı port, model swap
FP8 + speculative decoding	vLLM	Bu iki tekniğin referans implementasyonu
RAG pipeline + tool use	vLLM	Function calling JSON mode olgun

Bu matriste eksik bir boyut daha var: fonksiyon çağırma (tool use). 2026 itibarıyla vLLM, hermes-style ve mistral-style tool parser’larını yerleşik destekliyor; TGI’da JSON mode (guidance) ile aynı sonuç elde edilir; Ollama ise function calling’i Llama 3.1/3.2 ve Qwen2.5 ailesinde stabil destekler ama parser hata payı daha yüksek. vLLM’in resmi dokümantasyonu ve TGI’ın Hugging Face rehberi her iki framework için tool şeması örneklerini kapsar; PagedAttention’ın akademik temeli için arXiv:2309.06180 ve büyük ölçek dağıtım istatistikleri için McKinsey state of AI raporları referans olarak kullanılmalı.

Gerçek Üretim Tuzakları ve En İyi Uygulamalar

Üç framework’ü de farklı projelerde sahaya çıkartırken karşılaştığım inceltici detayları paylaşmadan yazı eksik kalır. Müşterilerime verdiğim danışmanlık çalışmalarında bu maddelerin her birinin en az bir kez incident dosyasında yer aldığını söyleyebilirim — Ömer Önal olarak en sık tekrarlanan 7 hatayı şöyle sıralıyorum:

1. CUDA driver / toolkit uyumsuzluğu: vLLM 0.6+ CUDA 12.1 minimum ister, TGI 3.0+ benzer. Eski Ubuntu 20.04 sürücüleri sessiz segfault’a sebep olur. Önce nvidia-smi ve nvcc --version doğrula.
2. swap kullanım yanılgısı: KV-cache RAM’e değil VRAM’e sığmalı. Swap açıksa Linux OOM killer yerine vLLM’in OOM yakalayıcısı tetiklenir, request kaybedilir.
3. Tokenizer mismatch: HF Hub’tan indirilen tokenizer ile model arasında sürüm farkı varsa output garbage olur. trust_remote_code=true ve commit hash pinleme şart.
4. Context window aşımı: vLLM’de --max-model-len, TGI’da --max-total-tokens, Ollama’da Modelfile num_ctx. Üçü farklı kontrol yüzeyi.
5. Sampling parametre farkı: Aynı temperature/top-p Ollama ve vLLM’de farklı RNG seed davranışı verir. A/B test yaparken seed sabitle.
6. Speculative decoding overhead: Küçük draft model latency’yi düşürür ama VRAM’i %20-30 daha çok kullanır; her senaryoda kazanç değil.
7. Health check timeout: Cold start 90 saniye olabilir, Kubernetes readiness probe varsayılan 10 saniye reddeder. initialDelaySeconds: 120 şart.

Bu liste sadece teknik tarafa bakar; LLM Hallucination Azaltma yazısında ele aldığım grounding, citation ve faithfulness adımları olmadan üretim sistemine geçmek erken doğum sayılır. Operasyonel olgunluk, Agentic AI İş Akışları seviyesine geçileceği vakit kritikleşiyor — orchestrator katmanı, alttaki serving framework’ünün quirks’unu absorbe etmek zorunda.

Sık Sorulan Sorular (SSS)

Sonuç

Ollama vs vLLM vs TGI seçimi, “en iyi framework” değil “en doğru iş ortağı” sorusu. Tek geliştirici, edge senaryosu veya Apple Silicon donanımı varsa Ollama tartışmasız birinci. 100+ eşzamanlı kullanıcı, FP8/speculative decoding, çoklu GPU TP gerektiren üretim trafiğinde vLLM’in PagedAttention temelli mimarisi yarışın açık ara önündedir. Hugging Face Hub bütünleşik akış, OpenTelemetry trace stack’i veya Rust router’ın low-overhead avantajı önceliklendiriliyorsa TGI üçüncü değil; eşit aday.

2026 itibarıyla üç framework’ün de yaşam döngüsü açısından risk profili düşük: vLLM ve TGI haftalık sürüm çıkarıyor, Ollama topluluk sürüm hızıyla bunu yakalıyor. Karar verirken Toplam Sahip Olma Maliyeti modelini sadece GPU kirası üzerinden değil, gözlemlenebilirlik, güvenlik katmanı, sysadmin saati ve fine-tuning maliyetini dahil ederek kur. AI Destekli Veri Analitiği projelerinde olduğu gibi, ölçüm olmadan optimizasyon yapılamaz.

Eğer üç framework’ten hangisinin sizin trafik profilinize uygun olduğunu, donanım yatırım planını veya hibrit (lokal + API fallback) mimariyi konuşmak isterseniz iletişim sayfasından ulaşabilirsiniz; benchmark testi, TCO modeli ve referans Kubernetes manifest paketini birlikte planlayabiliriz.