LLM Inference Nedir, Nasıl Hızlandırılır? vLLM, Ollama, SGLang ve TensorRT-LLM (2026)

LLM inference nedir?

LLM inference (çıkarım), eğitilmiş bir büyük dil modelinin gelen istemi işleyip yanıtı token token üretmesidir. İki aşaması vardır: istemin tamamının paralel işlendiği ön doldurma (prefill) GPU'nun hesap gücünü sonuna kadar kullanır; her adımda tek token üretilen çözümleme (decode) ise bellek bant genişliğiyle sınırlıdır. Bu yüzden servis hızını çoğunlukla GPU belleği ve bant genişliği belirler.

Bu işi yürüten yazılıma inference engine, yani servis motoru denir. Inference optimizasyonu ise ilk tokena kadar geçen süreyi (TTFT) ve token başına süreyi düşürürken aynı GPU'da aynı anda daha çok isteğe hizmet etmektir.

LLM inference nasıl hızlandırılır?

Ekim 2026 itibarıyla çok kullanıcılı LLM servisinde öne çıkan üç açık kaynak motor vLLM, SGLang ve TensorRT-LLM'dir; Ollama ise tek kullanıcılı geliştirme ve denemeler için daha kolay bir başlangıçtır. Bu üç motor da continuous batching, sayfalı KV önbelleği, önek önbelleği, speculative decoding ve FP8 destekler. TensorRT-LLM'de 1.2 sürümünden beri ayrı bir TensorRT motoru (engine) derleme adımı yoktur; Hugging Face modelini doğrudan trtllm-serve ile sunarsınız.

Optimizasyon için önerdiğimiz sıra:

• FP8 ağırlıklar: Ada, Hopper ve Blackwell kartlarda ağırlık belleğini yarıya indirir; vLLM belgeleri verimde 1,6 kata kadar artış bildirir.
• FP8 KV önbelleği: Aynı bellekte yaklaşık iki kat token ve eşzamanlı istek taşır.
• Ölçerek ayar: TTFT, token başına süre ve verimi farklı eşzamanlılık düzeylerinde ölçüp GPU'nun gerçek kapasitesini bulun.

Blackwell kartlarda (bizde RTX PRO 6000 ve RTX 5090) NVFP4 ile bir adım daha ileri gidebilirsiniz.

vLLM, SGLang, TensorRT-LLM ve Ollama: hangi servis motoru seçilmeli?

Tek kullanıcılı geliştirme ve hızlı deneme için Ollama, birden çok kullanıcıya açılacak bir API için vLLM iyi bir varsayılandır; çok turlu ve ortak önekli işlerde SGLang, NVIDIA'ya özgü optimizasyonlar için TensorRT-LLM denenmeye değer. TensorRT-LLM yalnızca NVIDIA GPU'larda çalışır; AMD kartlarda vLLM ve SGLang ROCm üzerinden çalışır (AMD MI300X'te vLLM ve ROCm).

Dördü de OpenAI uyumlu bir API sunar (Ollama bu API'nin bir alt kümesini destekler); uygulamanızda büyük değişiklik yapmadan motor deneyebilirsiniz. TensorRT-LLM'i Python'dan kullanmak için LLM API'si yeterlidir: from tensorrt_llm import LLM ile modeli yükleyip llm.generate(...) çağırırsınız. Ekosistemdeki diğer adlar:

• NVIDIA Dynamo (1.6): Bu motorların üzerinde çalışan, çok GPU'lu ve çok sunuculu kurulumlar için bir orkestrasyon katmanı: ön doldurma (prefill) ile üretimi (decode) ayrı GPU havuzlarına bölme, KV önbelleğine göre yönlendirme. Belgelerine göre tek GPU'da tek model için çoğu zaman gerekmez.
• NVIDIA Dynamo-Triton: Triton Inference Server'ın yeni adı.
• NVIDIA NIM: Hazır, optimize model konteynerleri. Geliştirme için ücretsiz; üretimde kullanmak NVIDIA AI Enterprise lisansı gerektirir.

vLLM mi Ollama mı?

Ollama, modelleri tek komutla (ollama run <model>) indirip çalıştırmayı kolaylaştırır; ancak varsayılan olarak her model aynı anda tek isteği işler (OLLAMA_NUM_PARALLEL=1), diğer istekler kuyrukta bekler. vLLM ise continuous batching ve sayfalı KV önbelleğiyle, eşzamanlı istek arttıkça toplam verimi yükseltmek için tasarlanmıştır.

Red Hat'in Ağustos 2025'te tek bir A100 40 GB kartta Llama 3.1 8B Instruct ile yaptığı testte vLLM'in tepe verimi saniyede 793 token, Ollama'nınki 41 token oldu; paralel istek sınırı 32'ye çıkarılan Ollama da 1 ile 256 arasındaki her eşzamanlılık düzeyinde vLLM'in gerisinde kaldı.

TensorRT nedir, hangi GPU'ları destekler?

TensorRT, NVIDIA'nın derin öğrenme modellerinde çıkarımı hızlandıran SDK'sıdır: eğitilmiş modeli (çoğunlukla ONNX biçiminde) alır; nicemleme, katman ve tensör birleştirme ve çekirdek ayarıyla hedef GPU'ya özgü bir motor (engine) üretir. Yalnızca NVIDIA GPU'larda çalışır; Ekim 2026'daki 11.4 sürümü hesaplama yeteneği 7.5 ve üzerindeki kartları (Turing ve sonraki mimariler) destekler, yani kiraladığımız altı GPU modelinin hepsi kapsamdadır. Motor varsayılan olarak yalnızca derlendiği GPU türünde çalıştığından modeli kullanacağınız kartta derleyin.

TensorRT-LLM ise aynı ekosistemin büyük dil modellerine özel, açık kaynak kütüphanesidir; 1.2 sürümünden beri TensorRT motoru derlemez, PyTorch tabanlı çalışır. Destek matrisine göre Ampere, Ada Lovelace, Hopper (H100, H200) ve Blackwell mimarilerinde test edilir. Klasik TensorRT ise görüntü (ör. YOLO ile nesne tespiti) ve konuşma gibi LLM dışı işlerde kullanılmaya devam ediyor.

Continuous batching, sayfalı KV önbelleği ve speculative decoding ne işe yarar?

Üçü de aynı soruna saldırır: GPU'yu boşta bekletmeden ve belleği israf etmeden daha çok token üretmek.

• Continuous batching (sürekli gruplama): İstekler toplu halde beklemez; biten istek her adımda gruptan çıkar, yenisi hemen katılır. Fikir, Orca çalışmasının (OSDI 2022) adım düzeyinde zamanlamasına dayanır. TensorRT-LLM buna in-flight batching der.
• Sayfalı KV önbelleği (PagedAttention): Her isteğin dikkat (attention) önbelleği, işletim sistemlerindeki sanal bellek gibi küçük sayfalarda tutulur; parçalanmadan doğan israf neredeyse sıfıra iner. vLLM makalesi, aynı gecikmede verimin FasterTransformer ve Orca'ya göre 2–4 kat arttığını raporladı.
• Önek önbelleği: Aynı sistem istemiyle (system prompt) ya da aynı belgeyle başlayan isteklerde ortak kısmın KV önbelleği yeniden kullanılır. Yalnızca ön doldurmayı, yani ilk tokena kadar geçen süreyi kısaltır; token üretimini hızlandırmaz.
• Speculative decoding (spekülatif çözümleme): Küçük bir taslak model ya da istemdeki tekrar eden kalıplar (n-gram) birkaç token önerir; büyük model bunları tek adımda doğrular. Çıktı dağılımı değişmez. Leviathan ve arkadaşları (2023) T5-XXL'de 2–3 kat hızlanma raporladı. vLLM belgelerine göre kazanç, düşük ve orta yükte belirgindir, yüksek eşzamanlılıkta azalır.

vLLM'de ek model gerektirmeyen n-gram yöntemiyle speculative decoding:

vllm serve Qwen/Qwen3-8B-FP8 \
  --speculative-config '{"method": "ngram", "num_speculative_tokens": 4, "prompt_lookup_min": 2, "prompt_lookup_max": 5}'

Nicemleme seçenekleri neler, hangi donanımı ister?

FP8 Ada, Hopper ve Blackwell'de; INT4 AWQ/GPTQ Ampere, Ada ve Hopper'da; NVFP4 ise yalnızca Blackwell'de yerel olarak çalışır. Nicemleme (quantization) ağırlıkları ve isteğe bağlı olarak KV önbelleğini daha az bitle saklar; bellek ve bant genişliği ihtiyacı aynı oranda düşer. Örnek olarak Hugging Face'teki Qwen3-8B ağırlık dosyaları:

Hazır nicemlenmiş bir model (adı genellikle -FP8, -AWQ ya da -FP4 ile biter) kullanmak en kolay yoldur: vLLM, nicemleme biçimini modelin yapılandırma dosyasından kendisi okur.

KV önbelleği, uzun bağlamda ve çok kullanıcıda ağırlıklardan bile büyük olabilir. Qwen3-8B'de 36 katman, 8 KV başlığı ve 128 boyutlu başlıklar vardır; token başına KV önbelleği BF16'da 2 × 36 × 8 × 128 × 2 = 147.456 bayt (~0,15 MB) eder. 8.192 tokenlık tek bir istek ~1,2 GB tutar. Ağırlıklardan sonra KV önbelleğine 25 GB kaldığını varsayarsak kart aynı anda ~20 tam dolu 8K isteği taşır; FP8 KV önbelleğiyle bu sayı ~41'e çıkar.

vLLM ile FP8 ağırlık ve FP8 KV önbelleğiyle bir servis:

# Kurulum (Python 3.11 ve üzeri)
uv venv --python 3.12 --seed --managed-python
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

# FP8 ağırlıklı model, FP8 KV önbelleği, 8K bağlam
vllm serve Qwen/Qwen3-8B-FP8 --max-model-len 8192 --kv-cache-dtype fp8

Kalibrasyon ölçekleri olmadan vLLM, FP8 KV önbelleğinde ölçeği 1,0 alır; kaliteyi kendi değerlendirme setinizle karşılaştırın. Aynı model SGLang'de python3 -m sglang.launch_server --model-path Qwen/Qwen3-8B-FP8 --kv-cache-dtype fp8_e4m3, TensorRT-LLM'de NVIDIA'nın nicemlediği sürümle trtllm-serve nvidia/Qwen3-8B-FP8 komutuyla sunulabilir.

Performansı nasıl ölçersiniz?

Dört ölçüye bakın: ilk tokena kadar geçen süre (TTFT), token başına süre (TPOT ya da ITL), saniyedeki çıkış tokenı ve eşzamanlılık.

• TTFT: Kullanıcının yanıtın başladığını gördüğü an; kuyruk ve ön doldurma süresine bağlıdır.
• TPOT/ITL: Yanıtın akış hızı; sohbet arayüzlerinde algılanan hızı belirler.
• Çıkış verimi: Sunucunun tüm isteklerde saniyede ürettiği toplam token.
• Eşzamanlılık: Aynı anda işlenen istek sayısı. Arttıkça toplam verim yükselir, istek başına hız düşer.

vLLM'in yerleşik ölçüm aracıyla, sunucu çalışırken:

vllm bench serve --model Qwen/Qwen3-8B-FP8 \
  --dataset-name random --random-input-len 1024 --random-output-len 256 \
  --num-prompts 200 --max-concurrency 16 \
  --percentile-metrics ttft,tpot,itl,e2el --metric-percentiles 50,99

Testi --max-concurrency değerini 1, 4, 16 ve 64 yaparak tekrarlayın. p99 TTFT ve TPOT'un hedefinizi aşmadığı en yüksek eşzamanlılık, o GPU'nun sizin işiniz için gerçek kapasitesidir. Giriş ve çıkış uzunluklarını gerçek trafiğinize benzetin; 200 tokenlık sohbetle 8.000 tokenlık belge özetinin sonuçları çok farklıdır.

Servis için hangi GPU?

İki kural işin çoğunu görür: ağırlıklar ile KV önbelleği belleğe sığmalı ve tek bir isteğin hızı bellek bant genişliğiyle sınırlıdır. Üretim aşamasında her token için ağırlıklar bellekten yeniden okunduğundan, tek istekteki hızın teorik üst sınırı yaklaşık "bant genişliği ÷ ağırlık boyutu"dur. Qwen3-8B FP8 (9,4 GB) için:

Gerçek değerler bu üst sınırın altında kalır; eşzamanlı isteklerde toplam verim ise çok daha yüksektir. Pratik öneriler:

• RTX PRO 4000: Geliştirme, test ve küçük modeller.
• L40S: 8–32B modellerin FP8 servisi. Daha büyük modeller için: L40S mi, RTX PRO 6000 mi?
• RTX PRO 5000: L40S ile aynı 48 GB'ta 8–32B modellerin FP8 servisi (Qwen3 32B FP8, 8K bağlamda ~37,6 GB); bant genişliği daha yüksek olduğu için tek istekte L40S'ten hızlı token üretmesi beklenir. NVFP4'ü destekler ve MIG ile iki 24 GB'lık bölüme ayrılabilir.
• RTX 5090: 8–14B modellerin FP8 servisi ve 32B'nin NVFP4 servisi; yüksek bant genişliği tek istekte hız kazandırır. 32 GB yetmeyecekse: RTX 5090 mı, RTX PRO 6000 mi?
• RTX PRO 6000: 70B sınıfı modellerin FP8, NVFP4 ya da 4-bit servisi tek kartta; MIG ile kartı en fazla 4 bağımsız bölüme ayırıp birkaç küçük servisi aynı kartta da çalıştırabilirsiniz. H100 ile farkı için: RTX PRO 6000 mi, H100 mü?
• H100 ve H200: Yüksek eşzamanlılık ve uzun bağlam (H100 mü, H200 mü?). Model birden fazla GPU'ya bölünecekse tensor paralellik NVLink'ten büyük fayda görür; NVLink'siz kartlarda vLLM pipeline paralelliği önerir. Ayrıntılar multi-GPU ve NVLink rehberimizde.

Kartın belleğine sığan modeli kendi senaryonuz için VRAM hesaplayıcımızla hesaplayabilirsiniz. Fiyatlar GPU başına, aylık ve KDV hariçtir; ABD doları olarak belirlenir, fatura tarihindeki TCMB döviz satış kuruyla Türk lirası olarak faturalanır. Kiralamalarımız en az 1 aylıktır; 7/24 çalışan bir servis için uygundur, birkaç günlük bir performans denemesi için saatlik bulut GPU daha ucuz olabilir. Model seçimini eğitim tarafıyla birlikte düşünüyorsanız LLM eğitimi için GPU seçimi rehberimize bakın. Eşzamanlı istek sayısına göre bellek tablosunu ve kart önerilerini LLM inference hizmet sayfamızda topladık; şirket içi bir asistan kuruyorsanız kurumsal yapay zeka sayfamıza bakın.

Özet

• 2026'da LLM servisi için vLLM, SGLang ve TensorRT-LLM öne çıkar; TensorRT-LLM 1.2'den beri motor derlemeden, trtllm-serve ile doğrudan çalışır.
• Tek kullanıcılı geliştirme için Ollama yeterlidir; birden çok kullanıcıya hizmet veren bir API için vLLM ya da SGLang daha uygundur.
• Continuous batching ve sayfalı KV önbelleği motorlarda hazır gelir; önek önbelleği TTFT'yi, speculative decoding düşük yükte token hızını iyileştirir.
• FP8 ağırlık ve FP8 KV önbelleği, Ada, Hopper ve Blackwell'de belleği yarıya indiren ve uygulaması kolay adımlardır; NVFP4 yalnızca Blackwell'de yerel çalışır.
• Kapasiteyi TTFT, TPOT ve verimi farklı eşzamanlılık düzeylerinde ölçerek belirleyin.
• Tek istekteki hızın üst sınırı yaklaşık bant genişliği ÷ ağırlık boyutudur; GPU'yu buna ve belleğe göre seçin.

Kaynaklar

• vLLM: FP8 W8A8
• vLLM: Quantized KV Cache
• vLLM: Speculative Decoding
• vLLM: vllm bench serve
• TensorRT-LLM: Migration Guide: TensorRT Backend Removed
• TensorRT-LLM: Quantization
• Kwon ve ark. (2023): Efficient Memory Management for Large Language Model Serving with PagedAttention
• Leviathan ve ark. (2023): Fast Inference from Transformers via Speculative Decoding
• NVIDIA: Mastering LLM Techniques: Inference Optimization
• TensorRT-LLM: Release Notes (1.2: TensorRT backend removed)
• TensorRT-LLM: Support Matrix
• NVIDIA RTX PRO 5000 Blackwell
• NVIDIA TensorRT
• NVIDIA TensorRT: Support Matrix
• NVIDIA TensorRT: Engine Compatibility
• Ultralytics: TensorRT Export for YOLO Models
• Ollama: FAQ (OLLAMA_NUM_PARALLEL, OLLAMA_HOST)
• Ollama: OpenAI compatibility
• Ollama: Hardware support
• Ollama: Importing a model
• vLLM: Installation (desteklenen donanım)
• SGLang: AMD GPUs
• Red Hat (Ağustos 2025): Ollama vs. vLLM: A deep dive into performance benchmarking