Benchmarklar: vLLM ve SGLang, tool çağrıları arasında agent geçmişinin yarısından fazlasını yeniden hesaplıyor

Agent turu problemi

Dev.to üzerinde yayımlanan bir benchmark çalışması, en yaygın kullanılan açık kaynak inference motorlarından ikisi olan vLLM ve SGLang'in AI agent trafiğini kötü yönettiğini savunuyor: gerçekçi yük altında işledikleri prompt token'larının yarısından fazlası, motorların daha önce bir kez hesaplayıp sonra GPU belleğinden attığı konuşma geçmişiydi.

Agent turu sorunu

nahuel990 adıyla yayınlanan yazara göre bir coding agent döngü halinde çalışır: tüm konuşmayı modele gönderir, bir tool çağrısı alır, tool'u çalıştırır, sonucu ekler ve her şeyi tekrar gönderir. Kullanılan kayıtlardaki medyan oturum yaklaşık 60 turu kapsıyor ve on binlerce token'a kadar büyüyor; hepsi her turda yeniden gönderiliyor.

Bir turu yanıtlamak için tüm geçmişin KV cache'i gerekir. Önceki turdan kalan cache hâlâ GPU belleğindeyse yalnızca yeni token'ların hesaplanması yeterlidir. Agent tool'uyla meşgulken cache atıldıysa, motor tüm geçmişi yeniden hesaplar. Her iki motorda da prefix caching var ama hiçbiri bir isteğin bir saniye içinde dönecek bir agente ait olduğunu bilmiyor. vLLM 0.33.0 bir session_id kabul ediyor ama bunu yalnızca metadata olarak ele alıyor; pinning veya time-to-live yok ve blokları en az recently used esasına göre atıyor. SGLang 0.5.23'ün gerçek session uç noktaları var, ancak OpenAI uyumlu chat API'si yalnızca session id'sini iletiyor; bir oturumun KV cache'ini sabit tutan mod ise varsayılan olarak kapalı ve /generate API'sini gerektiriyor.

Deney

Maliyeti ölçmek için yazar, her agent'ın oturumunu turlar arasında GPU belleğinde tutan, ortak prompt önekini oturumlar arasında paylaşan ve bellekteki oturumlar sığmaya devam ettiği sürece yeni oturumları kabul eden yaklaşık 1.700 satırlık bir Rust serving motoru yazdı. Bu motor, SWE-rebench-OpenHands veri setinden 24 gerçek coding-agent oturumu (791 tur) eşzamanlı olarak yeniden oynatılarak vLLM ve SGLang ile karşılaştırıldı; Qwen3-8B modeli tek bir NVIDIA L40S üzerinde, 173.200 token'lık özdeş KV cache boyutuyla kullanıldı. Turlar arasındaki tool bekleme süreleri 0.5, 5 veya 60 saniye olarak sabitlendi. Ölçülen coding-agent tool çağrılarının medyan aralığı yaklaşık 0.42 saniye olduğundan 0.5 saniyelik senaryo gerçekçi olanı.

Rakamlar

0.5 saniyelik beklemede vLLM 0.33.0 tüm oturumları iki denemede 2.264 ve 2.222 saniyede tamamladı, geçmişin %55'ini yeniden hesapladı ve 28.6 saniyelik medyan ilk token süresi gösterdi. Varsayılan LRU çıkarmasıyla SGLang 0.5.23 2.013 ve 2.048 saniyede, %51 yeniden hesaplama ve 35.0 saniyelik medyanla tamamlandı; TLRU seçeneği %52 ve 36.3 saniyeyle benzerdi. Rust session motoru iş yükünü 1.506 ve 1.586 saniyede tamamladı, geçmişin yalnızca %8–16'sını yeniden hesapladı ve ilk token'ı 4.5 saniyede üretti; bu kabaca beş kat daha hızlı.

Bu, genel olarak SGLang'den 1.31 kat, vLLM'den 1.45 kat daha hızlı demek. Avantaj, tool'lar yavaşladıkça küçülüyor: 5 saniyelik beklemede 1.13 ve 1.24 kata düşüyor, 60 saniyede ise tüm motorlar benzer performans gösteriyor, çünkü aynı anda GPU için yarışan agent sayısı az.

Çalışmanın iddia etmediği şeyler

Yazar sınırları hakkında açık konuşuyor. Prototipin decoding'i token başına vLLM'den %15–21 daha yavaş; dolayısıyla tüm kazanç yeniden hesaplamaktan kaçınmaktan geliyor. Temel fikir yeni değil: InferCept, Pensieve ve Continuum daha önce agent KV cache'lerini tool çağrıları arasında canlı tutmayı önermişti. Test tek bir modeli, tek bir GPU'yu, tek bir yük düzeyini ve sabit tool beklemelerini kapsıyor; LMCache veya SGLang'in HiCache gibi CPU offload seçeneklerini ve farkı daraltabilecek SGLang'in streaming session'larını değerlendirmemiş. Prototipin pinning politikalarından üçü, 60 saniyelik beklemelerde vLLM'e kaybetti; çünkü oturumları çok uzun tutmak, diğer agentların kullanabileceği belleği bloke ediyor.

Neden önemli

Kendi GPU'larında çok sayıda eşzamanlı agent çalıştıranlar, aynı token'ları farkında olmadan iki kez hesaplıyor olabilir. Hem vLLM hem de SGLang istek başına cache'lenen token'ları raporlayabiliyor; vLLM'de --enable-prompt-tokens-details, SGLang'de --enable-cache-report ile. Bu testteki gibi prompt trafiğinin yarısından fazlası yeniden hesaplanmış geçmiş çıkarsa, darboğaz ham motor hızı değil iş yüküdür. Yazar araç değiştirmeyi önermiyor: Rust motoru bir araştırma prototipi ve her iki projede de yerel session farkındalığı için açık öneriler halihazırda mevcut; bunlar vLLM PR #38514 ve RFC #37003 ile SGLang RFC #24656 olarak anılıyor. Motor, replay istemcisi, ham sonuçlar ve eşlik eden makale GitHub'daki agent-session-engine deposunda açık kaynak olarak yayımlandı.