SGLang'in RadixAttention'ı çok turlu agent TTFT'sini vLLM'e göre 11 kat düşürüyor, ama yalnızca paylaşımlı prefix trafiklerinde

Benchmark ne gösteriyor

Inference engine benchmark'ları üzerine yapılan bir dev.to analizi, çok turlu agent serving senaryosunda SGLang'in vLLM'e karşı büyük bir time-to-first-token (TTFT) avantajı elde ettiğini raporluyor. Manşet senaryoda — NextByteTech tarafından benchmark'lanan, 8.000 token'lık bir system context ile çalışan Qwen2.5-Coder-32B-Instruct-AWQ — SGLang'in RadixAttention'ı TTFT'yi 440ms'den 38ms'ye düşürerek 11,57 katlık bir iyileşme sağladı. Aynı ayarlarda prefix caching etkin olan vLLM v0.6, 480ms'den 92ms'ye inerek 5,21 katlık bir iyileşme yakaladı.\n Ancak yazının asıl iddiası, bu rakamın koşullu olduğudur. Farklı bir trafik biçiminde fark kapanıyor ya da tersine dönüyor; yazar da bu noktayı vurgulamak için yayınlanmış birkaç karşı örnek derlemiş.

RadixAttention agent trafiğine neden uyuyor

Her iki engine de istekler prompt prefix'lerini paylaştığında daha önce hesaplanmış KV cache'i yeniden kullanıyor. Fark, veri yapısında. dev.to yazısına göre vLLM'in otomatik prefix caching'i bütün prompt bloklarını hash'leyip bunları önbellekteki bloklarla eşleştiriyor; bu, istekler blok sınırlarına hizalanmış uzun ve özdeş prefix'ler paylaştığında işe yarıyor, ancak örtüşme dizinin ortasında sapmaya uğradığında performansı düşüyor. SGLang'in RadixAttention'ı ise KV cache'i bir radix tree'de — token dizileri üzerinden sıkıştırılmış bir trie'de — tutuyor, böylece yeniden kullanım yalnızca hizalanmış bloklarda değil, herhangi bir ortak prefix'in inceliğinde gerçekleşebiliyor.

Çok turlu agent konuşmaları bu yapıya çok iyi oturuyor: her tur aynı uzun system context'i artı büyüyen bir geçmişi tekrarlıyor, dolayısıyla sonraki her turda prefill hesaplamasının neredeyse tamamı atlanabiliyor.

ifnodoraemon tarafından yapılan ikinci bir dev.to karşılaştırması mekanizmayı metriklerde gözler önüne seriyor. 4.096 token'lık prompt ve %75 prefix örtüşmesiyle, 64 eşzamanlılıkta SGLang, vLLM'in %41,2'ine karşılık %78,6'lık bir KV cache isabet oranı yakaladı. Bu fark her yerde kendini gösterdi: medyan TTFT 85ms'ye karşılık 380ms (4,47 kat), P99 TTFT 280ms'ye karşılık 1.250ms ve throughput saniyede 5.430 tokena karşılık 3.120 token.

Avantajın buharlaştığı yerler

Yazı, SGLang'in üstünlüğünün kaybolduğu üç karşı örnek aktarıyor:

• Özgün prompt'lar. Eylül 2026 tarihli bir bex.co raporu, Spheron H100'lerde paylaşımlı prefix'in bulunmadığı, 50 eşzamanlı istekle Llama 3.3 70B FP8'i benchmark'ladı. SGLang, vLLM'in 1.850 tok/s'sine karşılık 1.920 tok/s üretti ve TTFT farkları 20ms içinde kaldı — tekrar eden bir şey yoksa radix tree'nin paylaşacak bir şeyi de olmadığından bu fiilen bir beraberlik.
• Kısa prompt'lu batch throughput'u. Aynı bex.co raporunda, Mayıs 2026 tarihli tek H100'lik bir Qwen2.5-7B çalışmasında vLLM, ham throughput açısından 23.500 tok/s'ye karşı SGLang'in 16.800 tok/s'sini geride bıraktı. SGLang yine de bir TTFT avantajı elinde tuttu (1,8 sn'ye karşı 7,8 sn), ancak gecikmeye toleranslı batch işlerinde turu vLLM aldı.
• Yüksek eşzamanlılık. bex.co'nun DGX Spark taramasında SGLang 1–4 eşzamanlı istekte öndeyken, vLLM 6 ve üzeri eşzamanlılıkta öne geçti. Ayrıca RunPod'un 2x H100 üzerinde, 7k context ile DeepSeek-R1-Distill-Llama-70B üzerinden yaptığı karşılaştırma, bir cache isabetinin kabaca +%20 hız demek olduğunu tahmin ediyor ve iki engine'in taze context'te karşılaştırılabilir olduğunu buldu.

Engine değiştirmeden önce sorulacak sorular

Yazı bir karar kontrol listesiyle kapanıyor: trafiğinizde gerçekte ne kadar prefix örtüşmesi olduğunu ölçün; eşzamanlılığınızı yayınlanmış kırılma noktalarıyla karşılaştırın ve kendi donanımınızda doğrulayın; prefix caching yalnızca prefill'i hızlandırdığı ve uzun çıktılar zamanlarının çoğunu decode'da geçirdiği için prefill-ağırlıklı mı decode-ağırlıklı mı olduğunuzu çıkarın; ve SLO'nuzun hangi gecikme yüzdeliğini hedeflediğini belirleyin, çünkü SGLang'in raporlanan üstünlüğü toplam saniyedeki token yerine TTFT ve kuyruk gecikmesinde yoğunlaşıyor.

Neden önemli

Agent iş yükleri üretimdeki LLM serving'de baskın bir desene dönüşüyor ve TTFT, bir agent döngüsünün kullanıcılara ne kadar hızlı hissettirdiğini doğrudan şekillendiriyor. Aktarılan rakamlar, bu trafik sınıfı için belirleyici etkenin ham işlem gücü değil cache mimarisi olduğunu ve bir radix tree'nin daha ince taneli prefix yeniden kullanımının blok tabanlı hash'lemeye karşı gerçek bir yapısal avantaj olduğunu gösteriyor.

Aynı veri, benchmark'a dayalı engine seçimine karşı da bir uyarı. bex.co, RunPod ve ikinci dev.to karşılaştırmasına göre özgün prompt'lu serving, kısa prompt'lu batch işleri ve yüksek eşzamanlıklı chatbot trafiğinde engine'ler berabere ya da vLLM önde. Ekipler, geçiş yapmadan önce kendi prefix örtüşmelerini ve eşzamanlılıklarını profillemeli. Bir uyarı daha: buradaki tüm rakamlar üçüncü taraf benchmark'lara atıfta bulunan tek bir dev.io yazısından geliyor değil — tek bir dev.to yazısından geliyor ve vLLM sonuçları v0.6'yı yansıtıyor; bu nedenle hedef donanımda bağımsız doğrulama gerekli.