vLLM vs SGLang vs TGI: Hangi LLM Servisi Seçmeli? (2026)

Bir modeli eğitmek, onu servis etmekten çok daha kolaydır. GPU’nun ham gücü, talebi karşılayan bir altyapı olmadan boşa gider. 2026 itibarıyla üretim ortamlarında üç isim öne çıkıyor: vLLM, SGLang ve HuggingFace TGI. Her biri farklı bir problemi çözüyor; doğru seçim, yanlış seçimden kolayca 3× throughput farkı yaratıyor.

Aşağıda her motorun ne yaptığını, nerede kırıldığını ve hangi senaryoda gerçekten fark yarattığını kıyaslıyoruz.

Servis Motoru Neden Önemli?

Bir LLM’i API arkasına koymak basit görünür; transformers kütüphanesiyle birkaç satırda inference yapılabilir. Ama üretimde mesele başka: onlarca eş zamanlı kullanıcı, farklı uzunluklarda promptlar, token akışı beklentisi ve GPU’yu boşta bırakmama zorunluluğu.

Servis motorları bu kısıtlamayı çözmek için iki boyutu dengeler:

• Throughput: Saniyede üretilen toplam token sayısı. Toplu (batch) iş yüklerinde kritik.
• TTFT (Time to First Token): İsteğin sisteme ulaşmasından ilk tokenin gelmesine kadar geçen süre. İnteraktif kullanımda kullanıcı deneyimini doğrudan etkiler.

Bu iki metrik çoğunlukla çatışır: batch büyüdükçe throughput artar ama TTFT kötüleşir. İyi bir servis motoru bu denklemi akıllı bellek yönetimi ve önceliklendirme ile çözer. transformers’ın basit generate döngüsü bu sorunları ele almaz; dolayısıyla trafik arttığında kuyruklar birikir, GPU aktivasyon oranı düşer ve maliyet gereksiz yere tırmanır.

vLLM: PagedAttention ve OpenAI Uyumu

vLLM, UC Berkeley’de 2023’te yayınlandı ve kısa sürede LLM serving’in fiili standardı haline geldi. Başarısının arkasında iki teknik yenilik yatıyor.

PagedAttention işletim sistemlerindeki sanal bellek konseptini KV cache’e uyguluyor. Geleneksel yaklaşımda her isteğin KV cache’i baştan ayrılmış bir bellek bloğunda tutulur; bu hem fragmentasyona hem de israf edilen GPU belleğine yol açar. PagedAttention bu bloğu sayfalar halinde yönetir; farklı istekler aynı fiziksel sayfaları paylaşabilir. Bellek verimliliğindeki artış, aynı anda daha fazla isteğin bellekte tutulmasına kapı açar.

Continuous batching ise kuyruk yönetimini kırar. Statik batch’lerde GPU, kısa bir isteğin tamamlanmasını beklerken uzun istekler için boş kalır. vLLM tamamlanan istekleri anında batch’ten çıkarıp yenilerini ekler; GPU kullanım oranı böylece %85+ seviyesinde tutulur.

OpenAI uyumlu API (/v1/chat/completions) mevcut kod tabanlarına minimal değişimle entegrasyon imkânı verir. Llama, Mistral, Qwen, Gemma, Falcon, Phi ve daha fazlası desteklenir. Quantization cephesinde AWQ, GPTQ ve Ampere+ GPU’larda FP8 desteği mevcuttur.

Zayıf nokta: prefix ağırlıklı workload’larda (RAG pipeline’ları, sistem promptlu ajan zincirleri gibi) SGLang’ın RadixAttention yaklaşımı öne geçiyor. Built-in structured output desteği de kısıtlı; JSON schema veya regex kısıtlı üretim için harici kütüphane gerekiyor.

Daha fazla teknik detay için vLLM nedir yazısına bakabilirsiniz.

SGLang: RadixAttention ve Yapısal Üretim

SGLang (Structured Generation Language), Stanford ekibinin 2024 başında yayınladığı ve 2025’te hızla olgunlaşan bir servis çerçevesi. İki alanda vLLM’in önüne geçiyor.

RadixAttention prefix-heavy workload’lar için tasarlanmış. Farklı isteklerin ortak prefix’lerini (sistem promptları, RAG belgelerinin başlangıcı, ajan zincirleri arasındaki tekrar eden bağlamlar) bir ağaç (radix tree) yapısında önbelleğe alır. Aynı sistem promptuna sahip 100 eş zamanlı istek geldiğinde bu prefix yalnızca bir kez hesaplanır. SGLang ekibinin yayınladığı benchmark’lara göre bu senaryoda throughput 2–3× artıyor; TTFT ise belirgin biçimde kısalıyor.

Built-in structured output cephesinde durum daha da belirgin. vLLM JSON schema kısıtlı üretim için outlines veya lm-format-enforcer gibi araçlara ihtiyaç duyarken, SGLang bu kabiliyeti doğrudan çekirdekte tutuyor. Constrained decoding hem daha hızlı hem de daha az ek yük getiriyor; veri çıkarma ve ajan araç çağrısı senaryolarında kayda değer fark ortaya çıkıyor.

Speculative decoding entegrasyonu da öne çıkıyor: Eagle-2 ile küçük taslak model, büyük hedef modelin büyük kısmını tahmin ederek latency’yi düşürüyor. Detaylı anlatım için speculative decoding yazısına bakılabilir.

Multi-LoRA serving vLLM’e göre daha olgun: farklı adaptörleri tek model ağırlığı üzerine hotswap ile yükleme, büyük multi-tenant senaryolar için kritik bir özellik.

Zayıf yanı: vLLM’e göre daha genç bir proje. Bazı model ailelerinde test kapsamı eksik, topluluk boyutu vLLM’in çok gerisinde. Hata ayıklama ve sorun giderme süreçleri daha meşakkatli olabiliyor.

TGI: HuggingFace’in Üretim Çözümü

Text Generation Inference, HuggingFace’in kendi üretim deneyiminden doğdu. Hub’daki milyonlarca modelde çalışacak biçimde tasarlanmış; entegrasyon kolaylığı ve ekosistem bütünlüğü ön planda.

Hub entegrasyonu en güçlü kozu. Model adını verip Docker container’ı başlatmak yeterli; weights indirme, safetensors formatını okuma ve model konfigürasyonunu çözme otomatik yürüyor. HuggingFace altyapısını kullanan ekipler için bu kolaylık somut zaman tasarrufu anlamına geliyor.

Token streaming (SSE) desteği vLLM ve SGLang’a kıyasla daha olgun ve kapsamlı test edilmiş. Doğrudan kullanıcıya yönelik, anlık yanıt beklentisi yaratan uygulamalar için bu detay önem taşıyor.

TGI ayrıca LoRA adaptor hotswap (v1.4+) destekliyor. FlashInfer ve FlashAttention entegrasyonu attention hesaplamayı hızlandırıyor.

Quantization desteği: AWQ, GPTQ ve bitsandbytes. FP8 desteği vLLM kadar gelişmiş değil.

Zayıf yanı: yüksek eş zamanlı kullanıcı senaryolarında throughput vLLM ve SGLang gerisinde kalıyor. Desteklenen model ailesi de daha dar; yeni açık kaynak modeller vLLM desteği kazandıktan aylar sonra TGI’da kullanılabilir hale gelebiliyor.

Throughput ve Latency Karşılaştırması

Her motorun avantajı farklı senaryolarda ortaya çıkıyor. Aşağıdaki tablo ortak kullanım durumlarında üç motoru konumlandırıyor:

KV cache ve bellek yönetimi konusunda daha fazla bilgi için KV cache nedir yazısına bakabilirsiniz.

Özellik Matrisi

Karar vermeyi kolaylaştırmak için üç motorun temel özelliklerini yan yana:

Quantization türleri hakkında ayrıntılı okuma için quantization nedir yazısına bakılabilir.

Hangi Motor Hangi Durum İçin?

Teknik farklılıklar pratikte şu tabloya dönüşüyor:

vLLM seçin, eğer:

• Geniş model desteği önceliğinizse (Llama, Mistral, Qwen, Gemma, Falcon, Phi, DeepSeek…)
• Mevcut OpenAI tabanlı kod tabanınızı minimal değişimle taşıyacaksanız
• Basit chat veya tamamlama workload’u çalıştırıyorsanız
• Büyük topluluğa ve zengin eklenti ekosistemine ihtiyaç duyuyorsanız

SGLang seçin, eğer:

• RAG pipeline’ları kuruyorsanız ve sorgular uzun, paylaşılan belgeler üzerinden geliyor
• Birden fazla ajan aynı sistem promptuyla çalışıyorsa
• JSON schema veya araç çağrısı için kısıtlı üretim şartsa
• Multi-LoRA ile farklı müşteri profilleri aynı GPU’da servis edilecekse
• Speculative decoding ile latency kısaltmak istiyorsanız

TGI seçin, eğer:

• HuggingFace Hub entegrasyonu ekibinizin iş akışının merkezindeyse
• Doğrudan kullanıcıya yönelik streaming deneyimi öncelikliyse
• Basit kurulum ve resmi Hub model yapılandırmalarına güvenmek istiyorsanız

Yerel geliştirme ve test için bu üç motordan hiçbirini önermiyoruz; Ollama gibi araçlar çok daha hafif bir deneyim sunar. RAG için yerel LLM kurulumunu anlatan yazıya da göz atabilirsiniz. Ayrıca yerel geliştirme araçlarını Ollama vs LM Studio karşılaştırmasında ele aldık.

Hızlı Kurulum

Üç motorun kurulumu birkaç satıra inebiliyor. Temel başlatma komutları:

# vLLM
pip install vllm
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-8B-Instruct

# SGLang
pip install sglang[all]
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --port 30000

# TGI (Docker)
volume=$PWD/data
docker run --gpus all -p 8080:80 \
  -v $volume:/data \
  ghcr.io/huggingface/text-generation-inference:latest \
  --model-id meta-llama/Llama-3.1-8B-Instruct

vLLM ve SGLang CUDA 12+ ve Python 3.9+ ile çalışıyor; TGI için Docker ve nvidia-container-toolkit yeterli. Üçü de çok-GPU (tensor parallelism) destekliyor; parametre sayısı arttığında --tensor-parallel-size N ile genişlemek mümkün.

SGLang’ın --enable-torch-compile bayrağı ilk başlatmada derleme süresi getirse de sonraki çalışmalarda ciddi hız kazanımı sağlıyor. Prefix caching varsayılan olarak açık; --disable-radix-cache ile kapatılabilir.

TGI’da quantization başlatırken --quantize awq veya --quantize gptq parametresi eklemek yeterli; model konfigürasyonu Hub’dan otomatik okunuyor.

Üretimde İzleme

Her üç motor da Prometheus metrik endpoint’i açıyor. vLLM /metrics path’ında vllm:num_requests_running, vllm:gpu_cache_usage_perc ve vllm:request_success sayaçlarını raporluyor. Grafana’ya bağlamak için ekstra yapılandırma gerekmez.

Gerçek throughput testi için locust veya k6 işe yarıyor. Kısa promptlar, uzun yanıtlar ve prefix-heavy senaryolar birbirinden farklı sonuçlar veriyor; hepsini ayrı ayrı çalıştırın. Tek bir ölçümle motor seçimi yapmak iş yükünüzü yanlış tanımlama riski taşıyor.

SGLang’da --log-level INFO ile prefix cache hit oranını takip edin; düşerse RadixAttention avantajı da küçülüyor. vLLM’de gpu_cache_usage_perc %90 üzerine çıkıyorsa batch boyutunu veya model büyüklüğünü gözden geçirin. TGI’da /info endpoint’i aktif yapılandırmayı ve quantization ayarlarını raporluyor.

Sistem promptları uzadıkça TTFT artar ve bellek kullanımı baskıya girer. Prompt engineering yazısında prompt tasarımını daha ayrıntılı ele aldık.

Motor seçimi genellikle altyapı kararı gibi görünür ama workload profili yanlış eşleştiğinde GPU maliyeti aynı kalır, kapasite düşer. Mevcut RAG pipeline’ınızda prefix tekrarı yüksekse SGLang’a geçmek kurulumu değil performansı değiştirir. vLLM veya TGI ile kalmak için de geçerli sebepler var; yukarıdaki karar rehberini kendi sisteminizde ölçümle birleştirdiğinizde tablo netleşiyor.