vLLM vs SGLang 2026: H100 Üzerinde İkisini de Benchmark'ladık

vLLM vs SGLang: 2026'da Doğru LLM Çıkarım Sunucusunu Seçmek

Hugging Face, TGI'yi Aralık 2025'te bakım moduna aldı ve ekipleri artık yeni dağıtımlar için vLLM veya SGLang'a yönlendiriyor. Bugün bir çıkarım yığını kuruyorsanız, gerçek soru "TGI'den uzaklaşmalı mıyım?" değil -- bu iki motordan hangisinin iş yükünüze gerçekten uyduğu.

Hızlı Özet

vLLM'i seçin -- en geniş donanım desteğini, en büyük topluluğu ve AWS, GCP ve Azure üzerinden üretime giden denenmiş bir yolu istiyorsanız.

SGLang'ı seçin -- iş yükünüz çok turlu konuşmalar, yapılandırılmış çıktılar veya RAG gibi prefix yoğun pipeline'lar içeriyorsa ve daha küçük bir ekosistemle çalışmaktan rahatsız olmuyorsanız.

Şimdi her motorun gerçekte nerede öne çıktığını inceleyelim.

Buraya Nasıl Geldik? TGI'nin Ayrılışı

Text Generation Inference (TGI), Hugging Face ekosistemini yıllarca taşıdı; ancak Aralık 2025'ten itibaren yalnızca hata düzeltmeleri kabul ediyor -- yeni özellikler artık eklenmiyor. Hugging Face'in kendi Inference Endpoints'i artık varsayılan olarak vLLM kullanıyor; SGLang ise alternatif olarak sunuluyor.

Bu durum, kendi kendine barındırılan LLM sunumu için iki gerçek aday bırakıyor. Her ikisi de açık kaynaklı, her ikisi de OpenAI API'siyle konuşuyor ve her ikisi de NVIDIA GPU'larında çalışıyor. Farklar yük altında ortaya çıkıyor.

Sonuç: Hem vLLM hem de SGLang, üretime hazır TGI alternatifleridir. Geçiş yapıyorsanız, her ikisi de güvenli bir seçimdir -- bu rehberin geri kalanı hangisini seçeceğinizi belirlemenize yardımcı olur.

Verim ve Gecikme Benchmark'ları

Benchmark'lar modele, GPU'ya ve eş zamanlılığa göre değişir, bu nedenle aynı donanım üzerindeki bağımsız testlerden elde edilen rakamlar aşağıdadır. Bu veriler, Spheron'un FP8 formatındaki Llama 3.3 70B Instruct ile gerçekleştirdiği H100 benchmark'larından ve PremAI'ın Llama 3.1 8B ile yaptığı testlerden alınmıştır.

H100 Üzerinde Llama 3.3 70B (FP8)

H100 Üzerinde Llama 3.1 8B

Daha küçük modellerde fark açılıyor. PremAI, SGLang'ı yaklaşık 16.200 tok/sn ölçürken vLLM 12.500 tok/sn'de kaldı -- SGLang için %29 verim avantajı. LMDeploy burada SGLang ile eşleşti ama bu ayrı bir konu.

Rakamların Anlamı

70B ölçeğinde delta mütevazı (%3-5). 8B ölçeğinde ise önemli. Bu kalıp mantıklı: SGLang'ın RadixAttention'ı, prefill toplam maliyetin daha büyük bir bölümünü oluşturduğunda daha fazla verim sağlıyor; bu durum daha küçük modellerde ve kısa çıktılarda ortaya çıkıyor.

Kuyruk gecikmesi de benzer bir tablo çiziyor. SGLang'ın TTFT p95'i, test edilen her eş zamanlılık seviyesinde tutarlı olarak vLLM'den %5-8 düşük kaldı. Her 50ms'nin önemli olduğu gerçek zamanlı bir sohbet arayüzü kuruyorsanız, bu fark kullanıcılar arasında birikerek artıyor.

Sonuç: SGLang, özellikle küçük modellerde ham verimde kazanıyor. vLLM, 70B+ ölçeğinde çok yakın seyrediyor. Çoğu üretim iş yükü için fark tek haneli bir yüzde -- büyük ölçekte anlamlı, ama tek başına belirleyici değil.

Prefix Önbellekleme: RadixAttention ve Otomatik Prefix Önbellekleme

Her iki motor da tekrarlanan prefix'ler için KV hesaplamalarını önbelleğe alıyor; ancak mekanizmalar, belirli iş yükleri için önem taşıyan biçimlerde farklılaşıyor. API düzeyinde istem önbellekleme hakkında bilginiz varsa, bunu bunun sunucu tarafı versiyonu olarak düşünebilirsiniz.

vLLM, blok düzeyinde hashing kullanıyor. KV önbelleğini sabit boyutlu bloklara bölüyor, bunları hash'liyor ve yeni isteklerde eşleşme arıyor. Öngörülebilir, verimli ve kolay anlaşılır -- ancak önbellek isabetleri için tutarlı blok sınırlarına ihtiyaç duyuyor.

SGLang, token düzeyinde indekslenmiş bir radix ağacı kullanıyor. Manuel yapılandırmaya gerek kalmadan istekler arasında paylaşılan prefix'leri otomatik olarak keşfediyor. 50 kullanıcı aynı konuşma dizisinde mesaj gönderirse, SGLang ortak prefix'i otomatik olarak bulup yeniden kullanıyor.

Gerçekten Önemli Olduğu Yer

RunPod, çok turlu konuşmalar üzerinde benchmark yaptı ve SGLang'ın yüksek eş zamanlılık altında tutarlı olarak ~30-31 tok/sn sunduğunu, vLLM'nin ise önbellek baskısı arttıkça 22'den 16 tok/sn'ye düştüğünü buldu. Bu, sohbet botu ve ajan iş yükleri için anlamlı bir fark.

Şablonlu istemler üzerinde toplu çıkarım için -- her isteğin aynı sistem istemini kullandığı durumlarda -- vLLM'nin yaklaşımı gayet iyi çalışıyor. Önbellek sınırları, şablon yapınızla doğal olarak örtüşüyor.

Sonuç: SGLang, dinamik çok turlu iş yüklerinde kazanıyor. vLLM, prefix'lerin öngörülebilir olduğu toplu çıkarım ve şablonlu istemler için tamamen yeterli.

Yapılandırılmış Çıktılar

JSON şema zorlama veya kısıtlı üretim gerekiyorsa bu bölüm çok önemli. Her iki motor da XGrammar ve LLGuidance gibi dil bilgisi backend'leri aracılığıyla yapılandırılmış çıktıları destekliyor; ancak performans hikayesi çok farklı.

SqueezeBits, ayrıntılı benchmark'lar yaptı ve vLLM'nin yönlendirilmiş kod çözme etkinleştirildiğinde, özellikle 8 ve üzeri batch boyutlarında önemli verim kaybı yaşadığını buldu. SGLang ise aksine maske üretimini GPU çıkarım adımıyla örtüştürüyor ve ek yükü minimum düzeyde tutuyor.

Tekrarlayan ve Dinamik Şemalar

Backend seçimi de önemli:

Yapılandırılmış zorlama olmadan çıktılar, karmaşık şemalarda ~%61 doğruluğa düşüyor. Zorlamayla bu oran 20-25 yüzde puan artıyor. Dolayısıyla üretim ajan iş akışları için bu isteğe bağlı değil -- ve seçtiğiniz motor ne kadar verim feda ettiğinizi belirliyor.

Sonuç: SGLang, yapılandırılmış çıktılarda kazanıyor. Pipeline'ınız JSON şema zorlamasına dayanıyorsa (ve çoğu ajan iş akışı dayanıyor), SGLang'ın örtüşen yaklaşımı verim vergisi ödemediğiniz anlamına geliyor.

Çoklu LoRA ve İnce Ayarlı Model Sunumu

Her iki motor da tek bir temel modelden birden fazla LoRA adaptörü sunmayı destekliyor; bu, farklı kiracılar veya görevler için modellere ince ayar yapıyorsanız vazgeçilmez.

SGLang, çoklu LoRA'yı yerel batch işlemeyle birlikte birinci sınıf bir özellik olarak ele alıyor -- farklı adaptörleri hedefleyen istekler aynı batch'i paylaşabiliyor. vLLM de destekliyor, ancak SGLang'ın implementasyonu son sürümlerde biraz daha olgun hale geldi.

Pratik fark? Tek bir Llama 70B temel modelinden 5-10 LoRA adaptörü sunuyorsanız her ikisi de çalışıyor. 50'den fazla adaptörü heterojen trafik kalıplarıyla çalıştırıyorsanız, SGLang'ın yerel batch işlemesi zamanlamayı daha zarif biçimde yönetiyor.

Sonuç: SGLang, büyük ölçekte çoklu LoRA'da hafif bir avantaja sahip. Birkaç adaptör için her iki motor da eşit derecede iyi çalışıyor.

Spekülatif Kod Çözme

Her iki motor da spekülatif kod çözmeyi destekliyor; bu yöntem, ana modelin paralel olarak doğruladığı token'ları tahmin etmek için küçük bir "taslak" model kullanıyor. Sonuç, bellek bant genişliği sınırlı senaryolar için 2-3 kat daha hızlı çıkarım.

vLLM yakın zamanda Unified Parallel Drafting'i tanıttı ve spekülatif kod çözme artık yapılandırılmış çıktılarla birlikte çalışıyor. SGLang'ın implementasyonu kapasitesi bakımından benzer; orta düzey eş zamanlılıklarda biraz daha iyi performans gösteriyor.

Gerçek farklılaştırıcı motor değil -- spekülatif kod çözmenin iş yükünüze uyup uymadığı. Darboğazın hesaplama değil bellek bant genişliği olduğu büyük modellerin uzun çıktılarında en çok yardımcı oluyor.

Sonuç: Beraberlik. Her iki motor da spekülatif kod çözme hız artışları açısından karşılaştırılabilir sonuçlar sunuyor.

Donanım Desteği ve Dağıtım

vLLM'nin önemli ölçüde öne çıktığı yer burası.

vLLM

• NVIDIA GPU'ları (A100, H100, H200, B200)
• AMD GPU'ları (MI250, MI300X)
• Intel GPU'ları (vllm-xpu-kernels aracılığıyla)
• AWS Trainium ve Inferentia
• Google TPU'ları
• Helm chart'ları, başlangıç/hazırlık/canlılık probe'larıyla olgun Kubernetes dokümantasyonu
• Kutudan çıkar çıkmaz NVIDIA Container Toolkit entegrasyonu

SGLang

• NVIDIA GPU'ları (A100, H100, H200, B200)
• AMD GPU'ları (MI300X, ROCm aracılığıyla)
• Docker öncelikli dağıtım
• Kubernetes mümkün ancak daha az belgelenmiş

NVIDIA veya AMD dışında bir donanıma dağıtım yapıyorsanız, vLLM tek seçeneğiniz. AWS'de özellikle Trainium desteği, çıkarım maliyetlerini önemli ölçüde düşürebileceğiniz anlamına geliyor -- ve SGLang bu donanıma ulaşamıyor.

Standart NVIDIA GPU'larında çalışan ekipler için dağıtım hikayesi benzer. Her ikisi de Docker görüntüleri ve OpenAI uyumlu uç noktalar sunuyor. vLLM'nin yalnızca daha fazla denenmiş üretim rehberi ve topluluk katkılı Helm chart'ları var.

LLM'leri yerel olarak çalıştırmak için araçları araştırıyorsanız veya kendi kendine barındırılan çıkarıma daha geniş bir bakış açısıyla bakmak istiyorsanız, her iki motor da tüketici GPU'larında yerel dağıtımı destekliyor -- her ne kadar veri merkezi donanımı için tasarlanmış olsalar da.

Sonuç: vLLM, donanım genişliği ve dağıtım olgunluğunda kazanıyor. NVIDIA veya AMD kullanıyorsanız SGLang iyidir. Başka bir donanımda ise vLLM tek seçenek.

Ayrıştırılmış Sunum

Her iki motor da prefill'i (hesaplama yoğun) ve decode'u (bellek yoğun) farklı çalışan havuzlarına ayırmayı destekliyor. Bu, her aşamayı bağımsız olarak ölçeklendirmenizi sağlıyor -- istem yoğun burst'larda daha fazla prefill çalışanı, uzun üretim için daha fazla decode çalışanı.

SGLang, ayrıştırma için Mooncake ve NIXL'i transfer backend'leri olarak destekliyor ve NVIDIA GB200 NVL72 kümelerinde 2,7 kat daha yüksek kod çözme verimi gösteren sonuçlar yayımladı. vLLM'nin ayrıştırılmış sunumu da işlevsel, ancak daha az öne çıkan belgelere sahip.

Bu özellik en çok çok büyük ölçekte (96+ GPU) önem taşıyor. Birkaç GPU çalıştırıyorsanız muhtemelen henüz buna ihtiyacınız yok.

Sonuç: SGLang, ayrıştırılmış sunum olgunluğunda hafif bir avantaja sahip. Her ikisi de destekliyor; SGLang daha fazla gerçek dünya sonucu yayımladı.

Ne Zaman Hangisini Kullanmalı: Karar Çerçevesi

Pek çok ekip için dürüst cevap: her ikisini de deneyin. Her ikisi de açık kaynaklı, her ikisi de aynı OpenAI API'sini sunuyor ve aralarında geçiş yapmak bir container değişimi. Gerçek iş yükünüzü bir gün boyunca her birine karşı çalıştırın ve size önemli olan metrikleri karşılaştırın.

Trafiği birden fazla çıkarım backend'ine yönlendiriyorsanız, her iki motorun önüne bir LLM gateway'i yerleştirerek yük devretme, hız sınırlama ve gözlemlenebilirliği yönetebilirsiniz.

Techsy Çıkarım Sunucusu Seçimine Nasıl Yaklaşıyor

Ekiplerin LLM destekli özellikler dağıtmasına yardımcı olduğumuzda, çıkarım motoru seçimi üç soruya bağlanıyor:

1. Hangi donanıma bağlısınız? Trainium veya TPU'ysa vLLM. Diğer her şey için her ikisi de çalışıyor.
2. İş yükünüzün şekli nedir? Çok turlu sohbet ve ajan döngüleri SGLang'ın prefix önbelleklemesini tercih ediyor. Toplu işleme ve basit tamamlamalar her ikisinde de iyi çalışıyor.
3. Ne kadar operasyon kapasiteniz var? vLLM'nin daha büyük topluluğu, sabah 3'te bir şey bozulduğunda daha fazla StackOverflow cevabı ve Helm chart'ı demek oluyor.

Her iki sistemde de üretim iş yüklerini çalıştırdık. Gerçekten birbirine çok yakınlar. Doğru cevap kısıtlamalarınıza bağlı, soyut anlamda birinin "daha iyi" olmasına değil.

Bir çıkarım sunucusu seçmek veya dağıtmak için yardıma ihtiyaç duyuyor musunuz? Bize ulaşın -- iş yükünüzü değerlendirip doğru stack'i önereceğiz.

Araç seçmek işin kolay kısmı. Onu gerçek bir üründe güvenilir şekilde çalıştırmak ise çoğu ekibin takıldığı yer; yapay zeka entegrasyon ekibimiz müşterileri için tam olarak bunu yapıyor, RAG hatlarından özel ajanlara kadar.

Sıkça Sorulan Sorular

SGLang, vLLM'den daha hızlı mı?

Daha küçük modellerde (7B-8B) SGLang, H100 GPU'larında yaklaşık %29 daha yüksek verim gösteriyor. 70B+ modellerde fark %3-5'e daralıyor. SGLang ayrıca test edilen tüm eş zamanlılık seviyelerinde daha düşük kuyruk gecikmesine (TTFT p95) sahip.

vLLM ve SGLang'ı OpenAI API formatıyla kullanabilir miyim?

Evet. Her ikisi de kutudan çıkar çıkmaz OpenAI uyumlu uç noktalar sunuyor. İstemci kodunuzu değiştirmeden birini diğeriyle değiştirebilirsiniz. /v1/chat/completions çağrılarınız her ikisinde de aynı şekilde çalışıyor.

Hugging Face neden TGI'yi kullanımdan kaldırdı?

TGI, Aralık 2025'te bakım moduna girdi. Hugging Face, ayrı bir çıkarım motoru sürdürmek yerine vLLM ve SGLang'a katkıda bulunmaya karar verdi. TGI mevcut dağıtımlar için hâlâ çalışıyor, ancak yeni özellikler artık eklenmeyecek.

SGLang NVIDIA ve AMD GPU'larını destekliyor mu?

SGLang, NVIDIA GPU'larını (A100, H100, H200, B200) ve AMD GPU'larını (ROCm aracılığıyla MI300X) destekliyor. Intel GPU'larını, AWS Trainium'u, Inferentia'yı veya Google TPU'larını desteklemiyor. vLLM daha geniş donanım kapsamına sahip.

RadixAttention nedir ve neden önemli?

RadixAttention, SGLang'ın prefix önbellekleme mekanizması. KV önbellek girişlerini token düzeyinde indekslenmiş bir radix ağacında saklıyor ve istekler arasında paylaşılan prefix'leri otomatik olarak keşfediyor. Bu sayede tekrarlanan bağlamın yeniden hesaplanmasına gerek olmadığından çok turlu konuşmalar ve RAG pipeline'ları önemli ölçüde hızlanıyor.

Yapılandırılmış JSON çıktıları için hangi motor daha iyi?

SGLang. Dil bilgisi maske üretimini GPU çıkarımıyla örtüştürüyor, bu nedenle yapılandırılmış çıktı zorlaması verimi neredeyse etkilemiyor. vLLM, yönlendirilmiş kod çözme etkinleştirildiğinde 8 ve üzeri batch boyutlarında belirgin bozulma gösteriyor.

Tek temel modelden birden fazla LoRA adaptörü sunabilir miyim?

Her iki motor da çoklu LoRA sunumunu destekliyor. SGLang bunu, aynı istek batch'indeki farklı adaptörler arasında batch işlemeyle birlikte yerel bir özellik olarak ele alıyor. vLLM de destekliyor, ancak yüksek adaptör sayılarında SGLang'ın zamanlaması daha verimli.

Ayrıştırılmış prefill/decode sunumu nedir?

Prefill aşamasını (istem işleme) decode aşamasından (token üretimi) ayrı GPU çalışanları üzerinde çalıştırmak demek. Prefill hesaplama sınırlı; decode bellek sınırlı. Bunları ayırmak, her aşamayı bağımsız olarak ölçeklendirmenizi sağlıyor. Her iki motor da bunu destekliyor; SGLang daha fazla yayımlanmış üretim sonucuna sahip.

TGI'den vLLM veya SGLang'a nasıl geçiş yapabilirim?

Her üçü de OpenAI uyumlu API'ler sunduğundan geçiş büyük ölçüde bir container değişimi. Docker Compose veya Kubernetes dağıtımınızı yeni görüntüye yönlendirin, model yükleme bayraklarını ayarlayın ve sağlık kontrolü uç noktalarını güncelleyin. İstemci kodu değişmeden kalıyor.

RAG pipeline'ı için vLLM mi yoksa SGLang mı kullanmalıyım?

RAG için SGLang daha güçlü bir seçim. RadixAttention'ı, RAG pipeline'larının tekrar tekrar gönderdiği uzun sistem istemlerini ve belge bağlamlarını otomatik olarak önbelleğe alıyor ve yeniden kullanıyor. vLLM'nin blok düzeyinde önbelleklemesi de çalışıyor; ancak belge parçaları istekler arasında hafifçe değiştiğinde SGLang'ın token düzeyinde yaklaşımıyla daha iyi önbellek isabet oranları elde edeceksiniz.

Nihai Değerlendirme

SGLang daha fazla kategoride kazanıyor; ancak vLLM'nin avantajları -- donanım genişliği ve ekosistem olgunluğu -- bir düğüm sabah 3'te çöktüğünde önemli olan türden şeyler.

NVIDIA donanımındaysanız ve iş yükünüz çok turlu konuşmalar, yapılandırılmış çıktılı ajanlar veya paylaşılan prefix'li RAG pipeline'ları içeriyorsa, SGLang'dan başlayın. Önemli olduğu yerlerde daha iyi verim ve daha düşük gecikme elde edeceksiniz.

Çoklu bulut esnekliğine, NVIDIA dışı donanım desteğine veya en büyük açık kaynaklı LLM sunum topluluğunun rahatlığına ihtiyacınız varsa, vLLM'den başlayın. Çoğu ekibe iyi hizmet edecek daha güvenli bir varsayılan.

Her halükârda, her iki motor da mükemmel ve hızla gelişiyor. Birini seçin, dağıtın, gerçek iş yükünüzü ölçün ve rakamlar size söylüyorsa geçiş yapın. OpenAI uyumlu API, bu geçişi ağrısız kılıyor.

Kaynaklar

• Spheron H100 Benchmark'ları: vLLM vs TensorRT-LLM vs SGLang
• PremAI: vLLM vs SGLang vs LMDeploy Benchmark'ları
• SqueezeBits: vLLM ve SGLang'da Yönlendirilmiş Kod Çözme Performansı
• RunPod: SGLang vs vLLM KV Önbellek Yeniden Kullanımı
• SGLang Resmi Dokümantasyonu
• vLLM Resmi Dokümantasyonu