AWS, vLLM'e çift yönlü KV aktarımı ekledi: TTFT 3,3 kata kadar düştü

Amazon Web Services (AWS), açık kaynaklı model sunum kütüphanesi vLLM'e çok turlu ajan iş yüklerinde ilk yanıt süresini (TTFT) kısaltan çift yönlü KV önbellek aktarımı özelliğini ekledi. Şirketin AWS Machine Learning Blog üzerinden paylaştığı testlere göre özellik, EFA bağlantılı Amazon EC2 P5en örnekleri üzerinde Qwen3-32B'de TTFT'yi 1,6 kata, GLM-5-FP8'de 3,3 kata kadar iyileştirdi. Sonuçların iş yüküne ve yapılandırmaya göre değişebileceği belirtiliyor.

Çok turlu ajan uygulamalarında istemci, her yeni turda sistem talimatları, önceki sorular, araç sonuçları ve model yanıtları dahil tüm sohbet geçmişini yeniden gönderiyor. Prefill-decode ayrıştırmasında prefill düğümü istemi işleyip anahtar-değer (KV) önbelleğini oluşturuyor, decode düğümü de bu blokları alıp yanıtı üretiyor.

Çift yönlü KV aktarımı ne sorunu çözüyor?

Geleneksel ayrıştırılmış sunumda KV önbelleği yalnızca prefill düğümünden decode düğümüne tek yönlü aktarılıyor. Bu akış iki verimsizliğe yol açıyor: decode düğümü yanıtı ürettikten sonra elinde tuttuğu KV kayıtlarını prefill düğümü geri alamıyor ve önceki yanıt tokenları için hesaplamayı baştan yapmak zorunda kalıyor. Ayrıca oturum durumu yalnızca decode düğümünde tutulduğu için prefill düğümlerinde aktif oturumların önbellekten atılma olasılığı artıyor.

Bu durumda prefill düğümü, sohbet geçmişinin tamamı için KV projeksiyonlarını yeniden hesaplıyor. Konuşma uzadıkça bu gereksiz iş hem hızlandırıcı kapasitesini tüketiyor hem de TTFT'yi yükseltiyor. Çift yönlü KV aktarımı, decode düğümünün hesapladığı KV bloklarını sonraki turlarda prefill düğümüne geri göndermesine dayanıyor ve bu sayede paylaşılan bağlam yeniden hesaplanmıyor.

Altyapıda neler değişti?

AWS, özelliği ilk olarak EFA ile bağlanan Trainium kümesinde geliştirip doğruladıktan sonra hızlandırıcıdan bağımsız bir yetenek olarak vLLM'e katkıda bulundu. Blog yazısındaki sonuçlar, avantajın GPU'lara da taşındığını göstermek için EFA bağlantılı bir P5en GPU kümesinden alındı.

Ekip bunun için NVIDIA Inference Xfer Library (NIXL) KV bağlayıcısını genişletti. Prefill düğümleri artık decode düğümünün sunduğu uzak KV bloklarını tüketebiliyor; iki düğüm türü mimari olarak farklı olduğu için uzak ve yerel blokların üst verisi kendi rollerine göre hesaplanmaya devam ediyor. Gerçek aktarım mekanizması ise her iki yönde de aynı NIXL okuma işlemiyle yürüyor.

Bunun yanında, turlar arasında KV yeniden kullanımını koordine eden, KV önbelleğinden haberdar bir yönlendirici devreye giriyor. İstemcinin sağladığı konuşma kimliğini decode düğümünün aktarım parametreleriyle eşleyen bu bileşen yalnızca blok konumu üst verisini saklıyor; KV tensörlerini değil. Üst veriyi ayrıca sorgulamak yerine yanıt akışından alıyor.

Blok saklama ve yeniden hesaplama eşiği nasıl çalışıyor?

Normalde decode örneği, üretim biter bitmez isteğin bloklarını serbest bırakıyor. Çift yönlü modda ise blokları yapılandırılabilir bir süre, varsayılan olarak 480 saniye boyunca (decoder_kv_blocks_ttl) elinde tutuyor ve konumlarını süresiyle birlikte yayımlıyor. Süre dolmadan gelen turda prefill düğümü KV'yi yeniden kullanıyor, geç gelen turda normal prefill akışına dönülüyor. Süre sabit olduğu ve yenilenmediği için turlar arası beklenen zamana göre ayarlanması öneriliyor.

KV yeniden kullanımı her zaman yerel yeniden hesaplamadan hızlı olmuyor. Kısa yeniden kullanılabilir öneklerde bağlantı ve koordinasyon maliyeti, tokenları yeniden hesaplama süresini aşabiliyor. Varsayılanı 64 token olan kv_recompute_threshold ayarı bu kararı veriyor: hesaplanacak token sayısı eşiğin altındaysa prefill yeniden hesaplıyor, eşiğe eşit ya da üstündeyse KV decode düğümünden çekiliyor.

TTFT ne kadar kısaldı?

Değerlendirmede Qwen3-32B ve GLM-5-FP8 modelleri, EFA ile bağlanan P5en örnekleri üzerinde 1P1D kurulumunda test edildi. Prefill düğümünün yerel önbelleğini attığı ya da yönlendiricinin konuşmanın KV bloklarına sahip olmayan farklı bir prefill düğümü seçtiği durumları taklit etmek için prefill tarafında önek önbelleği kapatıldı.

Özellik kapalıyken prefill örneği her turda büyüyen bağlamın tamamını yeniden hesapladığı için TTFT dik biçimde yükseliyor: Qwen3-32B 2 bin token bağlamda 158 ms'den 24 bin token bağlamda 778 ms'ye, GLM-5-FP8 ise 2 bin token bağlamda 500 ms'den 20 bin token bağlamda 2.334 ms'ye çıkıyor. Özellik açıkken decode örneğinin sakladığı KV yeniden kullanıldığı için TTFT çok daha yatay seyrediyor: Qwen3-32B aynı aralıkta 122 ms'den 460 ms'ye, GLM-5-FP8 358 ms'den 702 ms'ye yükseliyor.

Çift yönlü aktarım beraberinde küçük bir KV aktarım süresi getiriyor (Qwen3-32B'de yaklaşık 30-130 ms, GLM-5-FP8'de yaklaşık 29-110 ms). Ancak ortadan kaldırdığı prefill hesaplaması bu maliyeti fazlasıyla aşıyor. Toplam prefill süresi aktarım açıkken Qwen3-32B'de 128-414 ms, GLM-5-FP8'de 316-541 ms aralığında kalıyor; bu değerler yalnızca yeniden hesaplama yolunun (Qwen3-32B'de 153-744 ms, GLM-5-FP8'de 500-2.331 ms) belirgin biçimde altında. Daha büyük model olan GLM-5-FP8'de fark hem mutlak hem oransal olarak daha yüksek; token başına yeniden hesaplama süresi arttıkça KV yeniden kullanımının getirisi de büyüyor.

Neden önemli?

AWS'nin paylaştığı veriler, sohbet asistanları ve ajan uygulamalarında uzayan etkileşim geçmişinin yarattığı gecikme ve hızlandırıcı kapasitesi tüketiminin, önbellek yönünü tersine çevirerek önemli ölçüde azaltılabildiğini gösteriyor. Özellik hızlandırıcıdan bağımsız olarak vLLM'e katkıda bulunulduğu için, vLLM üzerinde kendi altyapısını kuran ekipler bunu kendi ortamlarına uyarlayabilecekleri bir örnek yönlendiriciyle deneyebiliyor.

Blog yazısı, çift yönlü KV aktarımının mimarisini, yönlendirici üst veri akışını, blok saklama ve yeniden hesaplama kontrollerini ve performans sonuçlarını ayrıntılandırıyor; yazıda benchmark'ın nasıl yeniden üretilebileceği de anlatılıyor. Ekip ayrıca decode tarafında da kalp atışıyla yenilenen bir kiralama modeline geçilmesini, böylece blokların sabit sürenin sonunda değil konuşma boşta kalır kalmaz geri alınmasını olası bir sonraki iyileştirme olarak işaret ediyor.