vLLM vs TensorRT-LLM vs Ollama vs SGLang: hangisini çalıştırmalısınız?

Çoğu kurumsal dağıtım için vLLM, doğru öntanımlı LLM sunum motorudur: en geniş model desteğine, OpenAI uyumlu bir API'ye, olgun bir Kubernetes ekosistemine ve Apache 2.0 lisansına sahiptir. NVIDIA GPU'larında yüksek hacimde tek bir istikrarlı modeli sunuyorsanız ve en iyi ham verim için bir derleme adımını kabul edebiliyorsanız TensorRT-LLM'i (doğrudan veya NVIDIA NIM olarak paketlenmiş) seçin; trafiğiniz uzun önekleri paylaşıyorsa veya ajan ile RAG iş yüklerinde olduğu gibi hızlı JSON şema çıktısına bağlıysa SGLang'ı seçin. Ollama, geliştirici dizüstü bilgisayarları ve prototipler için mükemmeldir ancak yüksek eşzamanlılıklı üretim için tasarlanmamıştır.

Karşılaştırma tablosu: dört motora bir bakışta

Tablo, motorları 2026 itibarıyla özetler; "tipik olarak" ifadesini bir tasarım beyanı olarak okuyun, bir kıyaslama sonucu olarak değil.

Önemli çıkarım: vLLM güvenli öntanımlıdır, TensorRT-LLM operasyonel bir maliyet karşılığında zirve NVIDIA verimi satın alır, SGLang paylaşılan önekler ve yapılandırılmış çıktıda kazanır ve Ollama geliştirici makinelerine aittir.

Her motor neyi farklı yapar

vLLM: PagedAttention ve sürekli gruplama

vLLM, KV önbelleğini dizi başına tek bir bitişik ayırma yerine sabit boyutlu bloklarda saklayan PagedAttention'ı tanıttı, böylece aynı GPU belleğine çok daha fazla eşzamanlı dizi sığar. Sürekli gruplama (continuous batching), bir grubun bitmesini beklemek yerine her decode adımında yeni istekleri kabul eder, bu da GPU'yu patlamalı trafik altında meşgul tutar. 2025'ten beri varsayılan olan V1 motoru; otomatik önek önbellekleme, parçalı prefill ve spekülatif decode ekler. vLLM, NVIDIA, AMD ROCm, Intel, Google TPU ve CPU arka uçlarında çalışır ve 2026 itibarıyla bir PyTorch Foundation projesidir; bkz. vLLM belgeleri.

FP8 ağırlıklarla dört H100 80 GB GPU'da 70B bir model için tipik bir başlatma:

vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 4 \
  --quantization fp8 \
  --max-model-len 32768 \
  --api-key "$VLLM_API_KEY"

Önemli çıkarım: vLLM, hiçbir derleme adımı olmadan en geniş model kapsamını ve en büyük operasyonel ekosistemi sunar.

TensorRT-LLM: derlenmiş motorlar ve Triton

TensorRT-LLM, bir modeli GPU mimarisine, TensorRT sürümüne, maksimum grup boyutuna ve maksimum dizi uzunluğuna özgü bir TensorRT motoruna derler. Derleyici çekirdekleri kaynaştırır, ince ayarlı dikkat uygulamalarını seçer ve kuantizasyon uygular (FP8, INT8 SmoothQuant, INT4 AWQ ve Blackwell'de NVFP4). Uçuş içi gruplaması ve sayfalanmış KV önbelleği, vLLM'nin sürekli gruplaması ve PagedAttention'ıyla aynı rolü oynar.

Bedeli derleme adımıdır: GPU modeli, sürücü, TensorRT sürümü veya dizi uzunluğu sınırındaki bir değişiklik, yeniden derleme ve yeniden doğrulama anlamına gelir. Son sürümler bu yükü azaltan PyTorch tabanlı bir çalışma zamanı ekler, ancak felsefe donanıma özgü kalır. Sunum, trtllm-serve (OpenAI uyumlu) veya Triton Inference Server'ın TensorRT-LLM arka ucu üzerinden yapılır; bkz. TensorRT-LLM belgeleri.

Önemli çıkarım: TensorRT-LLM tipik olarak NVIDIA donanımında en iyi ham verimi sağlar; bedelini bir derleme hattı ve yalnızca NVIDIA taşınabilirliğiyle ödersiniz.

SGLang: RadixAttention ve hızlı yapılandırılmış üretim

SGLang, tamamlanmış isteklerin KV önbelleğini token önekine göre anahtarlanan bir radix ağacında tutar, böylece bir sistem istemini, birkaç örnekli (few-shot) örnekleri, araç tanımlarını veya önceki turları paylaşan yeni bir istek, önbelleğe alınmış hesaplamayı otomatik olarak yeniden kullanır. Düşük ek yüklü bir zamanlayıcı, CPU zamanlamasını GPU yürütmesiyle örtüştürür, böylece küçük modeller Python ek yükü tarafından aç bırakılmaz.

Yapılandırılmış çıktı için SGLang; JSON şemalarını, düzenli ifadeleri ve EBNF gramerlerini kısıtlı-decode otomatına derler ve gramerin zaten belirlediği token'ları bir ileri geçiş olmadan yaymak için jump-forward decode kullanır. Tensor, veri ve uzman paralelliğinin yanı sıra düğümler arasında prefill-decode ayrıştırmasını destekler ve DeepSeek V3 ile R1'i tam optimizasyonlarla çalıştıran ilk motorlar arasındaydı; bkz. SGLang belgeleri.

Önemli çıkarım: SGLang, trafik bağlamı paylaştığında veya yüksek oranlarda şemaya uygun JSON döndürmesi gerektiğinde tipik olarak kazanır.

Ollama: geliştirici dostu tek düğümlü sunum

Ollama, llama.cpp ve GGUF modellerini tek komutluk bir deneyime sarar: ollama pull, ollama run ve OpenAI uyumlu bir sohbet uç noktasına sahip bir HTTP API'si. macOS, Linux ve Windows üzerinde Apple Silicon, NVIDIA ve AMD GPU'larıyla çalışır ve bellek tükendiğinde katmanları CPU'ya aktarır.

Yüksek eşzamanlılıklı bir sunucu değildir. Paralel istek işleme mevcuttur (OLLAMA_NUM_PARALLEL), ancak vLLM tarzı sürekli gruplama, çoklu düğüm paralelliği veya bir üretim zamanlayıcısı yoktur, dolayısıyla kullanıcı eklendikçe verim keskin biçimde düşer; bkz. GitHub'da Ollama.

Önemli çıkarım: Ollama'yı dizüstü bilgisayarlarda, demolarda ve tek kullanıcılı uç kutularda kullanın, yüzlerce çalışana hizmet veren bir yük dengeleyicinin arkasında değil.

NVIDIA NIM: paketlenmiş seçenek

NVIDIA NIM, desteklenen her modeli OpenAI uyumlu bir API, bir Helm şeması ve Kubernetes üzerinde NIM Operator ile önceden derlenmiş bir konteyner olarak sunar. Başlangıçta konteyner, tespit edilen GPU için genellikle bir TensorRT-LLM motoru olan optimize edilmiş bir profil seçer ve derlenmiş bir profil bulunmadığı yerlerde vLLM'e (bazı modeller için SGLang'a) geri döner, böylece derleme hattını işletmeden TensorRT-LLM hızını elde edersiniz.

Ödünleşim: NIM, NVIDIA AI Enterprise altında lisanslanmıştır (NVIDIA Developer Program aracılığıyla geliştirme için ücretsiz, üretim için ücretli; güncel lisanslamayı doğrulayın), seçilmiş bir model listesini kapsar ve özelleştirmeyi açığa çıkarılan parametrelerle sınırlar. İmzalı konteynerler ve bir destek sözleşmesi isteyen düzenlemeye tabi kurumlar için bu genellikle buna değer; bkz. NVIDIA NIM belgeleri.

Önemli çıkarım: NIM, lisanslama ve esneklik pahasına, tedarikçi desteğiyle TensorRT-LLM performansına giden en hızlı yoldur.

Senaryoya göre karar rehberi

Boyutlandırma seçimle etkileşime girer: 70B bir model yaklaşık 140 GB FP16 ağırlığa (FP8'de yaklaşık 70 GB) artı yüzde 20-50 KV önbellek payına ihtiyaç duyar, dolayısıyla dört H100 80 GB üzerinde tensor paralelliği veya FP8'de iki H100 ya da bir H200 141 GB planlayın. Bkz. 70B, 405B ve DeepSeek R1 boyutlandırma tablosu.

Yayımlanan kıyaslamalar her sürümde değişir ve nadiren istem karışımınızla eşleşir, dolayısıyla karar vermeden önce kendi trafiğinizde kıyaslama yapın: gerçek girdi ve çıktı uzunluğu dağılımlarını tekrar oynatın, motorlar arasında modeli, kuantizasyonu ve GPU'yu sabitleyin, her projenin yük aracını (vllm bench serve, sglang.bench_serving, trtllm-bench) veya NVIDIA GenAI-Perf'i kullanın ve ilk token'a kadar geçen süreyi (TTFT), token'lar arası gecikmeyi (ITL) ve verimi kaydederken eşzamanlılığı tarayın.

Önemli çıkarım: motoru manşet bir rakama göre değil, iş yükü şekline ve kendi trafiğinizdeki bir kıyaslamaya göre seçin.

Herhangi bir sunum motoru için üretim kontrol listesi

Motorun etrafındaki platform çalışma süresine karar verir. Bu, Kubernetes üzerinde bir üretim dağıtımı için asgaridir; şirket içi LLM dağıtım rehberi tam yığını kapsar.

1. Sağlık kontrolleri: ayrı başlangıç (startup), hazır olma (readiness) ve canlılık (liveness) yoklamaları kullanın. 70B bir kontrol noktasını yüklemek dakikalar sürebilir, dolayısıyla başlangıç yoklamasına uzun bir pencere verin ve pod'u yalnızca bir ısınma isteği başarılı olduktan sonra hazır olarak işaretleyin. vLLM ve SGLang /health'i açığa çıkarır; Triton /v2/health/ready kullanır.
2. Otomatik ölçeklendirme: CPU'ya değil, motor metriklerine (kuyruktaki istekler, KV önbelleği kullanımı, TTFT) göre ölçeklendirin. KEDA veya Prometheus beslemeli bir metrik adaptörü kullanın ve erken ölçeklendirin, çünkü yeni bir GPU pod'u saniyeler değil dakikalar alır.
3. Gözlemlenebilirlik: motorun Prometheus /metrics uç noktasını tarayın (kuyruk derinliği, KV önbelleği kullanımı, TTFT, ITL, verim), ağ geçidine OpenTelemetry izleri ekleyin ve istemleri yalnızca PII kontrolleriyle günlükleyin.
4. Kanarya sürümleri: yeni bir motor sürümüne, sürücüye veya model revizyonuna küçük bir trafik payı gönderin, gecikmeyi, hata oranını ve sabit bir kalite değerlendirme setini referansla karşılaştırın, ardından terfi ettirin. Konteyner görüntülerini, model revizyonlarını ve TensorRT-LLM motor derlemelerini sabitleyin.
5. Kapasite korumaları: aşırı yükün sınırsız kuyruklama yerine hızlı bir 429 döndürmesi için --max-model-len, maksimum eşzamanlı dizi sayısı ve kiracı başına hız sınırları belirleyin.
6. Güvenlik: motorları herkese açık ağın dışında tutun, TLS ve kimlik doğrulamayı bir ağ geçidinde sonlandırın ve API anahtarlarını döndürün.

Bir vLLM pod'u için örnek Kubernetes yoklamaları:

startupProbe:
  httpGet: {path: /health, port: 8000}
  periodSeconds: 10
  failureThreshold: 90
readinessProbe:
  httpGet: {path: /health, port: 8000}
  periodSeconds: 5

Başlangıç yoklaması, Kubernetes pod'u yeniden başlatmadan önce 15 dakikalık ağırlık yüklemesine izin verir. Küme düzeyinde seçimler için bkz. Kubernetes GPU Operator vs Slurm.

Önemli çıkarım: sağlık yoklamaları, metrik odaklı otomatik ölçeklendirme, gözlemlenebilirlik ve kanaryalar, motor seçiminin kendisinden çok daha fazla çalışma süresine katkıda bulunur.

Sıkça sorulan sorular

TensorRT-LLM, vLLM'den daha mı hızlı?

Derlenmiş, kuantize bir motorla NVIDIA GPU'larında, TensorRT-LLM tipik olarak aynı model için vLLM'den daha yüksek verim ve daha düşük gecikme elde eder, çünkü çekirdekleri tam donanım için kaynaştırılmış ve ince ayarlıdır. Fark her vLLM sürümüyle daralır ve modele, kuantizasyona ve trafik şekline bağlıdır, dolayısıyla karar vermeden önce ikisini de kendi istemlerinizde kıyaslayın.

Ollama üretimde kullanılabilir mi?

Ollama, amacı için üretim kalitesinde bir yazılımdır: bir veya birkaç kullanıcı için tek düğümlü bir çalışma zamanı. vLLM tarzı sürekli gruplama, çoklu düğüm paralelliği ve bir üretim zamanlayıcısından yoksundur, dolayısıyla eşzamanlı kullanıcılar arttıkça verim hızla düşer. Tek bir iş istasyonundaki bir avuç kullanıcı için uygundur; şirket çapında bir asistan için vLLM, SGLang veya TensorRT-LLM kullanın.

vLLM ile SGLang arasındaki fark nedir?

İkisi de sürekli gruplamaya, sayfalanmış KV önbelleğine, OpenAI uyumlu API'lere ve çoklu GPU desteğine sahip Apache 2.0 motorlarıdır. vLLM daha geniş model ve donanım kapsamına ve daha büyük ekosisteme sahiptir. SGLang'ın RadixAttention'ı paylaşılan önekleri daha agresif biçimde önbelleğe alır, zamanlayıcısının ek yükü daha düşüktür ve kısıtlı decode'u daha hızlıdır; bu da tipik olarak ajansal, çok turlu ve JSON ağırlıklı iş yüklerini destekler.

Dört motorun tümü OpenAI uyumlu bir API sunar mı?

Evet, 2026 itibarıyla: vLLM ve SGLang, /v1/chat/completions ve ilgili uç noktaları doğal olarak sunar, TensorRT-LLM bunları trtllm-serve ve Triton'ın OpenAI ön ucu aracılığıyla sunar, Ollama sohbet tamamlama alt kümesini uygular ve NVIDIA NIM tasarım gereği OpenAI uyumludur. Araç çağırma, görsel girdiler, logprobs ve response_format kapsamı farklılık gösterir, dolayısıyla uygulamanızın kullandığı tam alanları test edin.

Hangi motor en iyi yapılandırılmış çıktı desteğine sahip?

SGLang tipik olarak öndedir; JSON şema, regex ve EBNF gramerleri derlenmiş bir otomat tarafından zorunlu kılınır ve jump-forward decode, gramerin zaten belirlediği token'ları atlar. vLLM, xgrammar ile hemen arkasında gelir, TensorRT-LLM son sürümlerde yönlendirilmiş decode ekledi ve Ollama, llama.cpp gramerleri aracılığıyla JSON şemayı destekler. Hepsi geçerli sözdizimini garanti eder, doğru içeriği değil, dolayısıyla uygulama düzeyinde doğrulamayı sürdürün.

TensorRT-LLM, AMD veya Intel GPU'larında çalışır mı?

Hayır. TensorRT-LLM ve NVIDIA NIM, NVIDIA GPU'ları ve CUDA gerektirir. AMD Instinct hızlandırıcıları, Intel donanımı, Google TPU'ları veya yalnızca CPU'lu sunum için, bu platformlar için arka uçlar koruyan vLLM'i veya NVIDIA ile AMD'yi destekleyen SGLang'ı kullanın. Donanım taşınabilirliği önemliyse, vLLM üzerinde standartlaşın ve TensorRT-LLM'i isteğe bağlı, yalnızca NVIDIA'ya özgü bir optimizasyon olarak ele alın.

NVIDIA NIM, vLLM'nin yerini alır mı?

Hayır. NIM, motorları yerine koymak yerine paketler: bir NIM konteyneri, tespit edilen GPU için optimize edilmiş bir TensorRT-LLM profili seçer ve hiçbirinin bulunmadığı yerde vLLM veya SGLang'a geri döner. İmzalı konteynerler, bir Helm şeması, NIM Operator ve bir NVIDIA AI Enterprise lisansı altında kurumsal destek ekler. Tam kontrol, özel modeller veya NVIDIA dışı donanım isteyen ekipler doğrudan vLLM çalıştırır.

Nanobase AI nasıl yardımcı olabilir

Nanobase AI, özel LLM sunum yığınlarını uçtan uca tasarlar, dağıtır ve işletir: gerçek trafiğinizde motor seçimi ve kıyaslama, GPU Operator ile Kubernetes üzerinde vLLM, TensorRT-LLM, SGLang veya NVIDIA NIM dağıtımı, kuantizasyon ve çoklu GPU yapılandırması, ve sağlık kontrolleri, otomatik ölçeklendirme, gözlemlenebilirlik ve kanarya sürümlerinden oluşan üretim katmanı. Altındaki H100, H200, B200 ve RTX PRO altyapısını boyutlandırır ve kurarız, sunum katmanını MCP sunucuları ve RAG hatları aracılığıyla sistemlerinize bağlarız. Silikon Vadisi merkezli ve NVIDIA Inception Programı'nın bir üyesi olarak; şirket içi, bulut ve hibrit ortamlarda çalışırız. Çözümlerimize göz atın veya bir canlı demo rezervasyonu yapın.

Projenizi görüşmeye hazır mısınız? Nanobase AI ile iletişime geçin veya hello@bumu.tech adresine e-posta gönderin.