MoE Sunumda Dinamik HBM Yeniden Bölümlendirme: VAMP ve CUDA VMM

1. Abstract & Executive Summary

MoE sunumunda GPU HBM'nin uzman ağırlıkları ve KV önbelleği arasında statik dağıtımı, çok turlu isteklerde kritik bir darboğaz oluşturur. Qwen3-Next-80B modelinde, her H100 GPU'daki 94 GiB'lık alanın 72.0 GiB'ı yalnızca uzman ağırlıklarına ayrılır; bu durum KV önbelleği havuzunu sadece 8.02 GiB'a düşürür VAMP. Bu kısıtlı kapasite, yeniden kullanılabilir ön eklerin kaybedilmesine ve TTFT gecikmesinin ani yükselişine neden olan "ön ek önbelleği uçurumu"nu tetikler VAMP. VAMP, CUDA Sanal Bellek Yönetimi (VMM) API'sini kullanarak fiziksel HBM sayfalarını çalışma zamanında uzman bölgesinden KV önbelleğine yeniden eşleyerek bu sorunu çözer CUDA VMM. Bu mekanizma, mevcut KV verilerini kopyalamadan bellek havuzları arasında ince taneli geçiş sağlar VAMP. Üç yollu maliyet modeli, uzman dışa aktarma, KV atma ve istek ön alma seçeneklerinden en düşük cezaya sahip olanı seçer VAMP. 2.103 turluk SWE-bench izi üzerinde, VAMP TTFT p90'ı 26.1 s'dan 1.10 s'a indirirken throughput'u %20.7 artırır; ancak TPOT %31.1 artar VAMP. Bu kazanımlar, MoE'nin seyrekliliğini statik bellek yönetimi yerine dinamik yeniden dağıtımla kullanarak elde edilir; ancak sonuçlar yalnızca bu spesifik model ve çok turlu iş yükleri için geçerlidir VAMP.

2. Tarihsel Arka Plan ve Problem Tanımı

MoE sunumunda darboğaz, bellek yönetimi katmanının mimarinin seyrekliliğini (sparsity) gözetmemesinden kaynaklanır. Her token için yalnızca sınırlı sayıda uzman aktive edilirken, statik tahsis politikaları kullanılmayan uzman ağırlıklarının HBM üzerindeki alanını kilitlemeye devam eder. Qwen3-Next-80B modelinde 2x H100 (TP2) konfigürasyonu bu durumu somutlaştırır: GPU başına düşen 94 GiB'lık kapasitenin 72.0 GiB'ı uzman ağırlıklarına ayrılır ve KV önbelleği havuzu yalnızca 8.02 GiB'a iner VAMP. Bu yapısal dengesizlik, çok turlu iş yüklerinde bağlam boyutunun artmasıyla birlikte yeniden kullanılabilir ön eklerin kaybedilmesine ve TTFT gecikmesinin keskin biçimde yükseldiği "ön ek önbelleği uçurumu"nu tetikler VAMP.

Bu soruna yönelik mevcut alternatifler, GPU içi anlık yeniden dağıtımı ele almaz. LMCache gibi katmanlar KV verilerini CPU veya uzak depolama hiyerarşisine taşıyarak tekrar prefill maliyetini azaltmayı hedefler; ancak bu yaklaşım, GPU HBM üzerindeki atıl uzman alanını dinamik olarak KV havuzuna dönüştürmez LMCache. CUDA Sanal Bellek Yönetimi (VMM) API'si ise sanal adres alanının fiziksel bellekten ayrıştırılmasını sağlayarak, veri kopyalama maliyeti olmadan fiziksel sayfaların çalışma zamanında yeniden eşlenmesine olanak tanır CUDA VMM. VAMP'ın temel katkısı, bu genel API yeteneğini MoE'nin uzman seyrekliliğine özgü bir stratejiyle birleştirmesidir. Böylece atıl uzman sayfaları, KV önbelleği için anında ve kopyasız biçimde kullanılabilir hale gelir; bu mekanizma, statik bölümlendirmenin yarattığı kapasite tavanını aşarak çok turlu senaryolarda gecikme ve verimlilik sorununu adresler VAMP.

3. Matematiksel ve Teorik Temeller

VAMP'ın karar mekanizması, bellek baskısı altında üç alternatif aksiyonun beklenen maliyetini karşılaştırarak en düşük cezayı üreten yolu seçer: uzman dışa aktarma, KV önbelleği atma ve istek önceliği iptali. Bu seçim, prefix-cache hit oranı ve blok yeniliği gibi anlık durum sinyalleriyle beslenen analitik bir model üzerinden yapılır VAMP. Uzman dışa aktarma maliyeti ($C_{off}$), host belleğine transfer edilen ağırlık boyutunun ($W_{active}$) GPU-host arası bant genişliğine ($BW_{PCIe}$) bölünmesiyle oluşan gecikme olarak modellenebilir. KV önbelleği atma maliyeti ($C_{evict}$) ise kaybedilen ön eklerin yeniden işlenmesi (re-prefill) gerektirdiğinden, token sayısına ve hesaplama yoğunluğuna bağlıdır. İstek iptali maliyeti, yeniden planlama süresi ve kullanıcıya yansıyan gecikme artışı olarak ele alınır VAMP.

Bu kararların uygulanmasında kopyalama maliyetinin sıfıra inmesi, CUDA VMM API'sinin sanal adres rezervasyonunu fiziksel bellek atamasından ayırma yeteneğine dayanır CUDA VMM. Sanal adres alanı sabit tutulurken, fiziksel HBM sayfaları sayfa granülerliğinde KV havuzuna yeniden eşlenir. Bu sayede mevcut KV verileri taşınmaz; yalnızca eşleme tablosu güncellenir. Ancak bu mekanizma, uzman ağırlıklarının gerçekten host belleğine aktarılmasını gerektiren senaryolarda bant genişliği darboğazını ortadan kaldırmaz; sadece HBM içi yeniden dağıtımın kopyalama maliyetini sıfırlar.

Maliyet modelinin temel sınırı, gelecekteki istek desenini mükemmel tahmin edememesidir. Yanlış bir tahmin, gereksiz uzman transferine veya kritik ön eklerin kaybına yol açabilir. Ayrıca bu optimizasyon, MoE mimarisindeki uzman seyreliğinden doğrudan yararlanır; yoğun (dense) modellerde uzman ağırlığı payı düşük olduğundan KV havuzuna aktarılabilir alan sınırlıdır. Qwen3-Next-80B üzerinde 26.1 saniyeden 1.10 saniyeye düşen TTFT p90 değeri, H100 donanımı ve SWE-bench iş yüküne özgüdür; genel bir performans garantisi olarak yorumlanmamalıdır VAMP.

4. Sistem Mimarisi ve Veri Akışı

VAMP, vLLM sunum motorunun bellek yönetim katmanına entegre edilerek GPU HBM üzerindeki uzman ağırlıkları ve KV önbelleği havuzları arasında dinamik bir sınır oluşturur. Bu sınırların fiziksel sayfa düzeyinde yeniden eşlenmesi, CUDA Sanal Bellek Yönetimi (VMM) API'si aracılığıyla gerçekleştirilir CUDA VMM. VMM, sanal adres rezervasyonunu fiziksel bellek tahsisinden ayırarak, mevcut KV verilerinin kopyalanmadan farklı bir havuza atanmasını mümkün kılar VAMP.

Veri akışı şu şekilde işler: Sunum motoru, gelen isteklerin bağlam boyutunu ve mevcut önbellek kullanımını izler. KV havuzu doluluk eşiğine ulaştığında, VAMP'ın maliyet modeli devreye girer. Model, uzman dışa aktarma, KV atma veya istek önceliği iptali seçeneklerini karşılaştırır VAMP. En düşük ceza puanını üreten aksiyon seçilir. Uzman dışa aktarma kararı alındığında, ilgili fiziksel HBM sayfaları sanal olarak KV havuzuna yeniden eşlenir. Bu işlem sırasında, sayfalarda bulunan uzman ağırlıkları host belleğine taşınır; ancak bu transfer, KV verilerinin yerinden oynatılmasını gerektirmez VAMP.

+-------------------+       +-------------------+
|   vLLM Engine     |<----->|   VAMP Scheduler  |
+-------------------+       +-------------------+
          |                          |
          v                          v
+-------------------+       +-------------------+
| KV Cache Pool     |<--VMM-->| Expert Weight    |
| (Dynamic Size)    | Remap  | Region (Static   |
+-------------------+       | to Dynamic)       |
                            +-------------------+

Bu yapı, çok turlu iş yüklerinde biriken bağlamın daha uzun süre GPU'da kalmasını sağlar. Uzman ağırlıklarının geçici olarak host belleğine taşınması, PCIe bant genişliğinde ek bir yük oluşturur; ancak bu maliyet, tekrarlayan prefill hesaplarının önlenmesiyle dengelenir VAMP. Mekanizma, MoE modellerindeki uzman seyrelikliğini bellek yönetimi düzeyinde kullanarak statik sınırlamaları aşmayı hedefler.

5. Uygulama ve Referans Kod

VAMP'ın vLLM entegrasyonu, statik bellek bloklarını çalışma zamanında yeniden yapılandıran bir kontrol düğümü olarak çalışır. Aşağıdaki sözde kod, KV önbelleği talebi geldiğinde maliyet modelinin nasıl tetiklendiğini ve CUDA VMM çağrılarının hangi sırayla yapıldığını gösterir. Bu akış, mevcut KV verilerinin fiziksel konumunu değiştirmeden sanal eşlemelerin güncellenmesini sağlar.

function handle_kv_allocation_request(request):
    current_kv_usage = get_gpu_kv_pool_usage()
    if current_kv_usage > threshold:
        # Maliyet modelini çalıştır: en düşük cezalık aksiyonu seç
        action = cost_model.evaluate({
            offload_cost: estimate_expert_transfer(),
            eviction_cost: estimate_prefill_recompute(),
            preemption_cost: estimate_reschedule_penalty()
        })

    if action == OFFLOAD_EXPERTS:
        target_pages = select_inactive_expert_pages(request.context)
        
        # 1. Uzman ağırlıklarını host belleğine taşı (veri kopyalama)
        cudaMemcpyDtoH(target_pages, host_buffer)
        
        # 2. Sanal adres eşlemesini KV havuzuna yeniden yönlendir
        # Fiziksel sayfalar artık KV verileri için kullanılabilir
        cudaMemsetAddressRange(kv_pool_virtual_addr, target_pages)
        
        # 3. Mevcut KV bloklarının sanal referanslarını güncelle
        update_kv_block_pointers()
    else:
        execute_fallback(action) // Eviction veya Preemption

return allocate_new_kv_block(request)

Bu sözde kod, mekanizmanın iki aşamalı doğasını vurgular: önce fiziksel verinin (uzman ağırlıkları) hosta taşınması, ardından sanal adres alanının KV havuzu lehine yeniden eşlenmesi. CUDA VMM API'si, bu yeniden eşlemenin veri kopyalama maliyeti olmadan yapılmasına olanak tanır CUDA VMM. Ancak dikkat edilmelidir ki, uzman ağırlıklarının hosta taşınması (offloading) bant genişliği tüketen bir işlemdir; bu maliyet, maliyet modelinin estimate_expert_transfer() fonksiyonunda PCIe hızına göre hesaplanır. VAMP'ın kazancı, bu transfer maliyetinin, KV önbelleğinin dolması nedeniyle oluşacak tekrarlı prefill (yeniden hesaplama) maliyetinden düşük olması koşuluna dayanır VAMP. Kodun çalışma zamanı davranışı, vLLM'in iç bellek yöneticisiyle senkronize çalışmasını gerektirir; bu entegrasyon detayları makalede mimari bir bütünlük olarak sunulur ancak bağımsız bir referans implementasyonu şu an için mevcut değildir.

6. Empirik Analiz ve Benchmark Karşılaştırmaları

VAMP'ın performans verileri, Qwen3-Next-80B modelinin H100 donanımında ve kaydedilmiş çok turlu iş yüklerinde ölçülmüştür. Bu sınırlama, bulguların genel bir MoE sunum standardına doğrudan genellenemeyeceği anlamına gelir VAMP. Değerlendirme, 2.103 turluk bir SWE-bench ajan iş yükü yeniden oynatması dahil olmak üzere çeşitli senaryoları kapsar; ancak sonuçlar bu spesifik donanım ve model konfigürasyonuna bağlıdır VAMP.

Ölçüm verileri, VAMP'ın TTFT p90 gecikmesini 26.1 saniyeden 1.10 saniyeye düşürdüğünü gösterir; bu da 23.6 katlık bir iyileşmeye karşılık gelmektedir VAMP. Aynı koşullarda genel çıktı hızı (throughput) %20.7 oranında artmıştır. Ancak bu iyileşme, Token Başına Gecikme (TPOT) üzerinde %31.1'lik bir artışla birlikte gerçekleşmiştir VAMP. Bu durum, sistem bütünlüğünde bir takas olduğunu açıkça ortaya koyar: İlk token gecikmesindeki dramatik düşüş, ardışık token üretimi sırasında artan gecikme bedeliyle dengelenmiştir.

Karşılaştırmalı olarak bakıldığında, LMCache gibi mevcut katmanlar KV önbelleğini GPU dışındaki kademeli depolama hiyerarşilerine taşıyarak benzer bir kapasite genişletme mantığı sunar LMCache. Ancak VAMP'ın farkı, veri kopyalama maliyeti olmadan fiziksel HBM sayfalarını çalışma zamanında yeniden eşlemesidir. Bu mekanizma, özellikle MoE modellerindeki uzman ağırlıklarının dinamik olarak dışa aktarılmasına olanak tanır VAMP. Diğer yandan, CUDA VMM API'sinin teorik yetenekleri, bu tür dinamik yönetimin mimari olarak mümkün olduğunu destekler ancak tek başına performans garantisi vermez CUDA VMM.

Sonuç olarak, VAMP'ın sunduğu kazanım, statik bellek dağılımının yarattığı "ön ek önbelleği uçurumu"nu aşmak için kullanılan bir mühendislik çözümüdür. Bu çözüm, çok turlu ve uzun bağlam içeren iş yüklerinde kritik öneme sahip olsa da, TPOT artışı göz ardı edilmemelidir. Sistem, tüm olası bellek yönetimi stratejilerinden üstün olduğu iddia edilmez; bunun yerine, uzman dışa aktarma, KV atma ve istek iptali arasında analitik bir maliyet dengesi kurar VAMP.

7. Kısıtlamalar, Çıkmazlar ve Mühendislik Ödünleşimleri

VAMP'ın ölçüm sonuçları, Qwen3-Next-80B modelinin 2x H100 (TP2) konfigürasyonunda ve kaydedilmiş çok turlu iş yüklerinde sınırlıdır. Bu bulgular, farklı MoE mimarileri veya donanım topluluklarına doğrudan genellenemez VAMP. Sistem, dinamik yeniden dağıtımı etkinleştirmek için CUDA VMM API'sine bağımlıdır; bu API'nin gerektirdiği sürücü desteği ve düşük seviyeli bellek kontrolü, tüm GPU ortamlarında eşit derecede erişilebilir değildir CUDA VMM.

Mühendislik ödünleşimi, gecikme ve bant genişliği arasında gerçekleşir. Uzman ağırlıklarının host belleğine taşınması veya sanal eşlemelerin değiştirilmesi işlemi, PCIe bant genişliğine bağlı bir maliyet oluşturur. VAMP'ın maliyet modeli bu transfer süresini tahmin ederek en düşük cezalı aksiyonu seçer; ancak bu optimizasyon, Token Başına Gecikme (TPOT) üzerinde %31.1'lik bir artışa yol açmıştır VAMP. Bu durum, TTFT'deki dramatik iyileşmenin, token üretimi sırasında eklenen gecikme bedeliyle dengelendiğini gösterir.

Ayrıca, VAMP'ın başarısı statik dağıtıma kıyasla değerlendirilmiştir. LMCache gibi katmanlı KV önbelleği yönetimi çözümleri, GPU bellek dışına taşımak için farklı mekanizmalar kullanır ve motor bağımsız çalışabilir LMCache. VAMP'ın uzman ağırlıklarıyla dinamik paylaşıma odaklanması, bu alternatiflerle doğrudan karşılaştırıldığında özgün bir yol izler; ancak mevcut kaynaklar, bu yaklaşımın diğer tüm bellek yönetim stratejilerinden üstün olduğunu kanıtlayan genel bir performans verisi sunmamaktadır. Sistem, yalnızca üç spesifik aksiyon arasında karar verir ve evrensel bir üstünlük iddiası taşımaz VAMP.

8. Gelecek Projeksiyonu ve Açık Sorunlar

VAMP'ın mevcut kapsamı, Qwen3-Next-80B modeli ve H100 donanımına özgü ölçümlerle sınırlıdır. Bu bulguların farklı uzman sayıları, bağlam uzunlukları veya GPU nesilleri için geçerliliği henüz bağımsız olarak doğrulanmamıştır VAMP. Sistemin CUDA Sanal Bellek Yönetimi (VMM) API'sine bağımlılığı, belirli sürücü versiyonları ve donanım desteğini zorunlu kılar; bu durum heterojen GPU kümelerinde dağıtımı kısıtlar CUDA VMM. Dinamik yeniden eşleme sırasında uzman ağırlıklarının host belleğine taşınması, PCIe bant genişliğine bağlı gecikmeler yaratır ve bu maliyetin TPOT üzerindeki etkisi yüksek paralellikte dikkatli izlenmelidir.

Gelecekteki çalışmalar, maliyet modelinin daha genel MoE mimarilerine uyarlanmasını gerektirir. VAMP, KV verilerini GPU dışına taşımayı değil, mevcut HBM içindeki havuzlar arası dinamik yeniden dağıtımı hedeflediğinden, LMCache gibi katmanlı depolama çözümleriyle entegrasyonu değerlendirilebilir LMCache. Ancak bu hibrit yaklaşımın performansa net etkisi, ek ölçümler beklenmeden varsayım düzeyinde kalmaktadır. Açık kalan en kritik soru, dinamik yeniden dağıtım sıklığının artması durumunda sistem kararlılığı ve öngörülebilirliğinin nasıl korunacağıdır.

9. Referanslar ve İleri Okuma

• Dynamic HBM Repartitioning for Multi-Turn MoE Serving — VAMP is an MoE serving framework that dynamically repartitions GPU HBM at runtime by offloading expert weights to host memory and remapping those pages into the KV cache pool using CUDA Virtual Memory Management, aiming to mitigate the 'prefix-cache cliff' in multi-turn workloads. Tarih: 2609.13537; sürüm: bilinmiyor.

• LMCache: A KV Cache Management Layer for Scalable LLM Inference — Official documentation for LMCache, a vendor-neutral KV cache management layer that enables persistent storage and reuse of KV caches across serving engines to reduce prefill computation in multi-turn workloads. Tarih: bilinmiyor; sürüm: bilinmiyor.

• CUDA Programming Guide: Virtual Memory Management — Official NVIDIA documentation describing the CUDA VMM API, which allows decoupling virtual address reservation from physical memory mapping. This mechanism enables dynamic re-mapping of GPU memory regions without data copying, a foundational capability for repartitioning HBM between weights and KV cache in LLM serving systems. Tarih: bilinmiyor; sürüm: CUDA 12.4 (mentioned for Fabric Memory support).