vLLM, 64K tokenlık istemlerde SGLang'ı geride bırakıyor, ancak bağlam 200K'ya ulaştığında 8 GPU'lu bir B300 sunucusunda SGLang öne geçiyor. Bu değişim, token pencereleri genişledikçe performansı prefill (ön doldurma) işleminin değil, decode (kod çözme) aşamasındaki darboğazların belirlediğini gösteriyor.
Bu benchmark neden önemli
Uzun bağlamlı çıkarım (inference); sohbet asistanları, kod asistanları ve bellekte yüz binlerce token tutması gereken her türlü uygulama için maliyeti belirleyen ana unsurdur. Büyük parametreli bir model olan Kimi-K3, bu tür pencereleri rahatlıkla yönetebilen ilk açık ağırlıklı (open-weight) LLM'lerden biridir; ancak onu çalıştıran motor, bir isteğin saniyeler içinde mi yoksa dakikalar içinde mi tamamlanacağını belirler.
Hem vLLM hem de SGLang yüksek verimli (high-throughput) çıkarım vaat eder, ancak decode aşamasına zıt yaklaşımlar benimserler. vLLM, Decode Context Parallelism (DCP) ile gelen ekstra senkronizasyondan kaçınarak decode yolunu basit tutar. SGLang ise DCP kullanarak key-value (KV) cache okumalarını birden fazla GPU'ya yayar; bu teknik, ek iletişim maliyeti karşılığında bellek bant genişliğini amorti edebilir.
Test ortamı
- Donanım: her biri özdeş belleğe sahip sekiz adet NVIDIA B300 GPU içeren tek bir sunucu.
- İş yükleri: iki bağlam uzunluğu ayarı – 64K token ("uzun bağlam"ın alt sınırı) ve 200K token (birçok araştırma demosunun hedeflediği üst sınır).
- Metrikler: sabit bir istem grubunu (batch) işlemek için geçen toplam süre; verimlilik (throughput) ise zaman farkından türetilir.
Batch boyutu, model ağırlıkları ve bellek kullanım hedeflerini sabit tuttuk. Çalıştırmalar arasında değiştirdiğimiz tek parametre çıkarım motoruydu.
Rakamlar ne diyor?
| Bağlam | Motor | Süre (sn) | Göreceli hız |
|---|---|---|---|
| 64 K | vLLM | 100.5 | – |
| SGLang | 150.8 | vLLM ≈ 1.5× daha hızlı | |
| 200 K | vLLM | 295.2 | – |
| SGLang | 225.3 | SGLang ≈ 1.31× daha hızlı |
Bağlam büyüdüğünde vLLM için verimlilik (saniye başına token) çarpıcı bir şekilde düştü: 64K'dan 200K'ya 3.29x'lik bir düşüş. SGLang'ın verimliliği ise aynı aralıkta yalnızca 1.25x azaldı.
Fark nereden kaynaklanıyor?
Her iki motor da prefill aşamasında —yani istemin KV cache'e yüklenmesinde— benzer miktarda zaman harcar. Farklılaşma, modelin tokenları tek tek ürettiği decode aşamasında ortaya çıkar.
- 64K token: GPU'lar arası iletişim baskındır. vLLM'in tek GPU'lu decode yolu, DCP'nin gerektirdiği ekstra senkronizasyonu devre dışı bırakarak yaklaşık 1.5x daha hızlı bitirmesini sağlar.
- 200K token: KV cache o kadar büyür ki, onu okumak darboğaz haline gelir. Boyutu 8 olarak ayarlanan SGLang'ın DCP'si, bu okumaları sekiz GPU'nun tamamına dağıtır. Bant genişliği kazancı, iletişim maliyetinden daha ağır basarak SGLang'a net bir üstünlük sağlar.
İkincil ve pratik bir gözlem ise bellek baskısıyla ilgilidir. Her iki motoru da 0.95 bellek kullanım hedefiyle çalıştırmak, B300'lerde bellek yetersizliği (OOM) denemelerine yol açtı. Hedefi 0.92'ye düşürmek, gecikmedeki (latency) hafif bir artış pahasına, bu denemeleri ortadan kaldırdı ve çalışma sürelerini stabilize etti.
Kim kazanıyor, kim kaybediyor?
- Kısa ila orta ölçekli bağlamlarla çalışan geliştiriciler (≤ 64K token), vLLM'in yalın decode yolundan daha fazla yararlanır. Daha hızlı işlem süresi, daha düşük bulut bilişim faturaları ve daha akıcı kullanıcı deneyimi döngüleri anlamına gelir.
- Bağlamda yüz binlerce token tutması gereken derin analiz veya araştırma araçları geliştiren ekipler, DCP etkinleştirilmiş SGLang'a yönelmelidir. SGLang'ın daha istikrarlı verimliliği, zaman aşımı (time-out) riskini azaltır ve bellek talepleri arttıkça GPU kullanımını daha yüksek tutar.
- Donanım planlamacıları, sadece ham GPU sayısının doğrusal ölçeklenmeyi garanti etmediğini görürler. KV bant genişliği darboğaz haline geldiğinde, ister DCP yoluyla ister gelecekteki bellek alt sistemi yükseltmeleriyle olsun, cache okumalarını paralelleştirebilen mimariler aynı silikon donanımdan daha fazla değer elde edecektir.
Karşı görüş: vLLM arayı kapatabilir mi?
Yeni veriler ortaya çıkana kadar, mevcut rakamlar en iyi halka açık karşılaştırma olarak kalmaktadır.
Sırada ne var?
- Daha büyük bağlam pencereleri, KV bant genişliğini daha da zorlayarak potansiyel olarak SGLang'ın liderliğini artıracaktır.
Özetle
B300 tabanlı bir kümede uzun bağlamlı istekleri karşılamanız gerektiğinde, token pencerenize uygun olan motoru seçin. 64K tokenlık iş yükleri için vLLM yaklaşık 1.5x daha hızlı çıkarım sağlar. 200K token sınırını geçtiğinizde ise SGLang'ın DCP tabanlı decode işlemi, verimliliğinin vLLM'in 3.29x'lik düşüşüne kıyasla yalnızca 1.25x düşmesiyle daha verimli bir seçenek haline gelir. OOM denemelerinden kaçınmak için bellek kullanımını 0.92'ye ayarlayın ve unutmayın ki "en iyi" motor bağlama bağlıdır, her duruma uyan tek bir çözüm değildir.