LLM RL'de Eğitim-Çıkarım Uyumsuzluğunu Skor Merkezileme ile Düzeltme

1. Abstract & Executive Summary

Eğitim-çıkarım uyumsuzluğu (TIM), pekiştirmeli öğrenmedeki istikrarsızlığın ana kaynağıdır; bu sapma, her adımda modeli örnekleyiciye doğru distilasyon eden 'drift' terimini üretir Score Centering Stabilizes Off-policy Reinforcement Learning. TIM'i tamamen gidermek rollout verimliliğini düşürdüğü için pratik değildir; yöntem, uyumsuzluğu yok etmek yerine stabiliteyi hedefler Score Centering Stabilizes Off-policy Reinforcement Learning. Skor merkezileme, drifti sıfırlayan additif bir düzeltmedir; örnekleyicinin top-k log-olasılıklarını (varsayılan k=128) depolar ve kuyruğu eğitimcinin dağılımıyla modeller Score Centering Official Repository. Yazar ölçümlerine göre 0.6B-30B parametreli Qwen3 modellerinde, kuantizasyon altındaki önem örneklemesiyle eşdeğer veya daha iyi performans gösterir; fark uyumsuzluk arttıkça büyür Score Centering Stabilizes Off-policy Reinforcement Learning. Düzeltme, önem örneklemesiyle birleştirilebilir ve bu kompozisyon saf baz çizgilerinden üstündür Score Centering Stabilizes Off-policy Reinforcement Learning. Sonuçlar spesifik model ölçekleri ve görev dağılımlarıyla sınırlıdır; evrensel bir üstünlük iddiası taşımaz Score Centering Stabilizes Off-policy Reinforcement Learning.

2. Tarihsel Arka Plan ve Problem Tanımı

Pekiştirmeli öğrenmede (RL) büyük dil modeli eğitimi, eğitim motoru ile çıkarım (sampler) motoru arasındaki yapısal farklılıklardan kaçınmak zorundadır. Bu durum, eğitim-çıkarım uyuşmazlığı olarak bilinen TIM'i yaratır. TIM'in tamamen ortadan kaldırılması, örneğin her adımda ağırlıkların senkronize edilmesi veya batch-invariant kernel kullanımı gibi yöntemlerle mümkündür; ancak bu yaklaşımlar rollout verimliliği üzerinde ciddi bir performans düşüşüne neden olur Score Centering Stabilizes Off-policy Reinforcement Learning. Pratik sistemlerde, çıkarım motorunun kuantizasyonu (FP8, INT4 vb.) veya KV-cache yönetimi gibi optimizasyonlar, eğitim motorundaki tam hassasiyetli hesaplama ile arasında kalıcı bir dağıtım farkı bırakır. Bu fark, tek seferlik bir gürültü değil, her eğitim adımında biriken sistematik bir sapmadır.

Sorunun kök nedeni, bu uyumsuzluğun politik gradyan kaybına nasıl yansıdığıdır. TIM varlığında, standart politika gradyanı beklenen ödülle ölçeklenmiş bir çapraz entropi (SFT) kaybı gradyanını içerir; bu terim, modelin her önekinde örnekleyici dağılımına doğru distilasyonuna yol açar Score Centering Stabilizes Off-policy Reinforcement Learning. Bu 'drift' terimi, RL'nin ödül sinyaliyle öğrenme kapasitesini baltalar ve istikrarsızlığa neden olur. Skor merkezileme yaklaşımı, TIM'i yok etmek yerine bu drift teriminin etkisini matematiksel olarak iptal ederek stabiliteyi sağlamayı hedefler Score Centering Stabilizes Off-policy Reinforcement Learning. Bu ayrım kritik öneme sahiptir: yöntem, motorları eşleştirmek yerine, uyumsuzluğun neden olduğu yan etkiyi telafi eder. Böylece, rollout verimliliğinden ödün vermeden, eğitim sürecinin öngörülebilirliğini korumak mümkün hale gelir.

3. Matematiksel ve Teorik Temeller

TIM kaynaklı istikrarsızlığın kökeni, politika gradyanındaki drift terimidir. Bu terim, örnekleyici dağılımı $q$ ile eğitimci dağılımı $p$ arasındaki farktan doğar ve matematiksel olarak, örnekleyiciye doğru çapraz entropi (SFT) kaybının beklenen gradyanına karşılık gelir Score Centering Stabilizes Off-policy Reinforcement Learning. Bu durum, her eğitim adımında modelin örnekleyiciye doğru sürekli bir distilasyonuna neden olur; süreç, pozitif geri bildirim döngüsüyle bileşik hale gelerek eğitimi istikrarsızlaştırır.

Skor merkezileme, bu drift terimini sıfırlayan additif bir düzeltmedir. Düzeltme, ödül ile token skorları arasındaki kovaryansı ($Cov_q(R, s_{y_t})$) kullanarak hesaplanır ve kayıp fonksiyonuna doğrudan eklenir Score Centering Stabilizes Off-policy Reinforcement Learning. Bu mekanizma, örnekleyici dağılımının yarattığı sistematik önyargıyı iptal ederek RL güncellemesinin TIM varlığında stabil kalmasını sağlar.

Uygulamada, yöntem örnekleyicinin top-k log-olabilirliklerini ($k=128$ varsayılan) depolar ve kuyruk dağılımını eğitimci modeliyle ölçeklendirir Score Centering Official Repository. Bu, motorlar arasında ek veri aktarımı gerektirse de TIM'i tamamen ortadan kaldırmaya kıyasla rollout verimliliği korunur. Düzeltmenin additif doğası, onu önem örnekleme ile birleştirmeye olanak tanır; yazar ölçümlerine göre bu kompozisyon, kuantizasyon ve staleness senaryolarında saf önem örneklemesi baz çizgilerinden daha iyi performans gösterir Score Centering Stabilizes Off-policy Reinforcement Learning.

4. Sistem Mimarisi ve Veri Akışı

Sistem mimarisi, eğitimci (trainer) ile örnekleyiciyi (sampler) fiziksel olarak ayırır. Bu ayrım, asenkron veri üretimi ve GPU verimliliği için gereklidir; ancak iki motorun farklı donanım optimizasyonları veya ağırlık kuantizasyonu kullanması durumunda TIM ortaya çıkar Score Centering Stabilizes Off-policy Reinforcement Learning. Veri akışında kritik olan, örnekleyicinin ürettiği token dizilerinin yanı sıra, her adım için top-k log-olasılıklarının (varsayılan k=128) eğitimciye aktarılmasıdır Score Centering Official Repository. Bu ek veri yükü, düzeltme teriminin hesaplanabilmesi için zorunludur; ancak k=32 gibi daha küçük değerlerin de tam merkezileme ile eşdeğer performans gösterdiği raporlanmıştır Score Centering Official Repository.

Eğitim döngüsünde, skor merkezileme düzeltmesi kayıp fonksiyonuna additif olarak eklenir. Kod tabanında score_center parametresi, RL kaybı hesaplanırken doğrudan gradyan girdisine dahil edilir train_rl.py Implementation. Bu yapı, yöntemin önem örnekleme (importance sampling) teknikleriyle bağımsız veya kompozit olarak kullanılmasına olanak tanır; örneğin TIS veya MIS ağırlıkları ile birlikte uygulanabilir train_rl.py Implementation. Örnekleyici tarafında, TIM'i simüle etmek için sentetik ağırlık gürültüsü, INT8/FP8 kuantizasyonu veya KV-cache kısıtları yapılandırılabilir train_rl.py Implementation. Bu mimari esneklik, yöntemin farklı mühendislik senaryolarında test edilmesine imkân verir.

[Sampler (FP8/INT4)] --(Tokens + Top-k Logprobs)--> [Data Buffer]
       |                                                |
       | (Ağırlık Snapshot / Staleness)                 v
       |                                        [Trainer (FP32/BF16)]
       |                                                |
       |                                        +-------------------+
       |                                        | RL Loss Function  |
       |                                        | - Policy Gradient |
       |                                        | - Score Centering |
       |                                        | - IS Weights (opt)|
       |                                        +-------------------+
       |                                                |
       v                                                v
[Inference Engine]                        [Optimizer Update]

5. Uygulama ve Referans Kod

Skor merkezileme düzeltmesi, mevcut RL eğitim döngülerine additif bir terim olarak entegre edilir. Resmî depodaki JAX tabanlı train_rl.py betiğinde, score_center bayrağı doğrudan RL kaybı fonksiyonuna geçirilerek mekanizma gradyan hesabına dahil edilir Score Centering train_rl.py. Bu yapı, yöntemin standart politika gradyan güncellemelerine bağımsız bir düzeltme olarak eklenebildiğini gösterir. Düzeltme, weight_fn parametresi üzerinden TIS veya MIS gibi önem örneklemesi (importance sampling) stratejileriyle birlikte kullanılabilecek şekilde tasarlanmıştır; bu kompozisyon yeteneği, yöntemin evrensel bir üstünlük iddiası taşımak yerine mevcut stabilizasyon teknikleriyle uyumlu çalıştığını vurgular Score Centering Stabilizes Off-policy Reinforcement Learning.

Uygulama tarafında, örnekleyici yapılandırması TIM'i simüle etmek veya gerçekleştirmek için esnek parametrelere sahiptir. Ağırlık kuantizasyonu (int8, fp8 vb.), KV-cache kuantizasyonu ve sentetik ağırlık gürültüsü gibi ayarlar, çıkarım motorunun eğitimden sapmasını kontrollü biçimde yönetmeyi sağlar Score Centering train_rl.py. Mimari olarak, örnekleyici ağırlıkları belirli bir refresh_period ile eğitimci ağırlıklarından anlık görüntü alınarak güncellenir; bu ayrık mimari, veri tazelik (staleness) sorunlarının doğduğu asenkron senaryoları modellemeye olanak tanır. Yazarların raporladığı deneylerde, k=128 ve k=32 top-k değerlerinin tam skor merkezileme ile eşdeğer performans gösterdiği gözlemlenmiştir Score Centering Official Repository. Bu bulgu, veri aktarım maliyetini düşürme potansiyeli sunan mühendislik bir çıkarımdır; ancak bant genişliği tasarrufu doğrudan ölçülen bir metrik değildir. Aşağıdaki sözde kod, düzeltmenin aktif olduğu basit bir kayıp hesaplama akışını özetler:

function compute_rl_loss(trainer_logits, sampler_topk_logprobs, rewards):
    # Drift terimini hesapla ve iptal et
    score_center_correction = calculate_covariance(rewards, token_scores)
    
    # Önem örneklemesi ağırlıkları (isteğe bağlı)
    is_weights = compute_importance_ratio(trainer_logits, sampler_topk_logprobs)
    
    base_loss = policy_gradient_loss(rewards, trainer_logits)
    final_loss = base_loss + score_center_correction
    
    if is_weights is not null:
        final_loss = apply_weighting(final_loss, is_weights)
        
    return final_loss

Bu uygulama yaklaşımı, TIM'i tamamen ortadan kaldırmak yerine stabiliteyi koruma hedefini destekler ve mevcut RL altyapılarına düşük entegrasyon maliyetiyle uygulanabilir.

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

Yazarlar, yöntemin etkinliğini Qwen3-0.6B (Countdown) ve Qwen3-30B-A3B-Base (INTELLECT-2 math) modelleri üzerinde test etmiştir Score Centering Stabilizes Off-policy Reinforcement Learning. Deneyler, TIM'i simüle etmek için ağırlık kuantizasyonu ve yapay gürültü gibi koşulları içerir. Yazar ölçümüne göre, skor merkezileme tek başına kullanıldığında kuantizasyon altındaki önem örneklemesi yöntemleriyle eşdeğer veya daha iyi performans gösterir; uyumsuzluk şiddetlendikçe bu farkın arttığı gözlemlenmiştir Score Centering Stabilizes Off-policy Reinforcement Learning. Düzeltmenin additif yapısı sayesinde önem örneklemesi ile birleştirildiğinde, saf önem örneklemesi baz çizgilerinden daha yüksek stabilite sağladığı raporlanmıştır Score Centering Stabilizes Off-policy Reinforcement Learning.

Yöntem	Model Ölçeği	Görev	TIM Koşulu	Performans
Skor Merkezileme (SC)	0.6B / 30B	Countdown / Math	Kuantizasyon	Önem örneklemesi ile eşdeğer veya üstün Kaynak
SC + Önem Örneklemesi	0.6B / 30B	Math	Staleness	Saf IS'den daha iyi Kaynak
Top-k = 32 / 128	Raporlanmadı	Raporlanmadı	Raporlanmadı	Tam SC ile eşdeğer Kaynak

Resmî depoda, örnekleyicinin top-k log-olasılıklarının (varsayılan k=128) depolandığı ve kuyruğun eğitimcinin dağılımıyla modellendiği belirtilmiştir Score Centering Official Repository. Yazarlar, k=32 değerinin de tam merkezileme ile eşdeğer performans gösterdiğini raporlamıştır Score Centering Official Repository. Mühendislik çıkarımı olarak, bu esneklik sistemler arası veri aktarım maliyetini yönetilebilir kılar; ancak kaynak metin bant genişliği tasarrufuna dair doğrudan bir ölçüm sunmaz. Bulgular yalnızca belirtilen model ölçekleri ve görev dağılımları için geçerlidir; daha büyük modellerde performansın korunup korunmadığı raporlanmamıştır Score Centering Stabilizes Off-policy Reinforcement Learning. Skor merkezileme, TIM'i yok etmek yerine stabiliteyi sağlamayı hedefleyen bir telafi mekanizmasıdır Score Centering Stabilizes Off-policy Reinforcement Learning.

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

Skor merkezileme, TIM'i tamamen ortadan kaldırmayı hedeflemediğinden, mühendislik ödünleşimleri kaçınılmazdır. En somut maliyet, örnekleyici ile eğitimci arasındaki ek veri aktarımıdır; düzeltme teriminin hesaplanması için örnekleyicinin top-k log-olasılıklarının (varsayılan k=128) depolanması ve eğitimciye gönderilmesi gerekir Score Centering Official Repository. Bu durum, sistem bant genişliği tüketimi ve bellek basıncı yaratır. Yazarlar, k=32 gibi daha küçük değerlerin de tam merkezileme ile eşdeğer performans gösterdiğini raporlayarak bu veri aktarım maliyetinin sınırlanabileceğini göstermiştir Score Centering Official Repository.

Yöntemin genel geçerliliği, mevcut kanıtların kapsamıyla sınırlıdır. Deneyler yalnızca Qwen3-0.6B (Countdown) ve Qwen3-30B-A3B-Base (INTELLECT-2 matematik) modellerinde yürütülmüş olup, farklı model aileleri veya görev dağılımlarına dair bağımsız doğrulama bulunmamaktadır Score Centering Stabilizes Off-policy Reinforcement Learning. Ayrıca, skor merkezilemenin önem örneklemesi ile birleştirilmesi (kompozisyon), belirli esneklik/staleness senaryolarında saf önem örneklemesinden üstün performans gösterse de, evrensel bir üstünlük iddiası taşımaz; sonuçlar koşula bağlıdır Score Centering Stabilizes Off-policy Reinforcement Learning. Sonuç olarak, yöntem TIM'in yarattığı istikrarsızlığı stabilize etmek için pratik bir düzeltme sunar; ancak rollout verimliliği ile stabilite arasındaki dengeyi korumak, sistem spesifik parametrelerin (k değeri, kuantizasyon seviyesi) dikkatli ayarlanmasını gerektirir.

8. Gelecek Projeksiyonu ve Açık Sorunlar

Skor merkezileme yönteminin mevcut kanıt tabanı, Qwen3 ailesinin 0.6B ve 30B-A3B ölçekli modelleri ile sınırlıdır; bu nedenle daha büyük parametre sayılarına veya farklı mimarilere genelleme yapılamaz Score Centering Stabilizes Off-policy Reinforcement Learning. Deneyler, Countdown ve INTELLECT-2 gibi spesifik görev dağılımlarında yürütülmüş olup, genel dil modelleme performansına dair bağımsız bir doğrulama sunulmamaktadır. Bu kapsam darlığı, yöntemin evrensel bir stabilizasyon çözümü olarak kabul edilmesini engeller; yalnızca test edilen TIM senaryoları için geçerli bir mühendislik düzeltmesi olarak konumlandırılmalıdır.

Açık kalan en kritik soru, top-k log-olasılık aktarımının büyük ölçekli dağıtık sistemlerdeki bant genişliği maliyetidir. K=128 varsayılan değeri, örnekleyici ile eğitimci arasındaki veri trafiğini artırır; k=32'nin eşdeğer performans göstermesi bu yükü azaltmakla birlikte, aşırı kuantizasyon veya yüksek staleness koşullarında yeterli olup olmadığı raporlanmamıştır Score Centering Official Repository. Ayrıca, düzeltmenin önem örneklemesi ile kompozisyonunda elde edilen kazanımların, farklı optimizasyon dinamiklerinde (örn. PPO vs GRPO) nasıl değiştiği net değildir.

Gelecek çalışmalar için üç temel yön öne çıkmaktadır: Birincisi, çok uzun bağlam pencerelerinde ve asenkron veri üretim oranları yüksek sistemlerdeki davranışın incelenmesidir. İkincisi, kuyruk dağılımının modelleme hassasiyetinin, eğitimci dağılımından sapma arttıkça nasıl degrade olduğu ve bunun için adaptif k seçim mekanizmalarının geliştirilmesidir. Son olarak, yöntemin mevcut RLHF/HF pipeline'larındaki entegrasyon derinliği ve farklı çıkarım motorları arasındaki spesifik TIM profillerine karşı performansı, bağımsız ölçümlerle test edilmelidir. Bu boşluklar doldurulmadan, skor merkezilemenin üretim ortamlarındaki standart bir bileşen olarak benimsenmesi erken olacaktır.

9. Referanslar ve İleri Okuma

• Score Centering Stabilizes Off-policy Reinforcement Learning — Bu makale, Büyük Dil Modellerinin (LLM) pekiştirmeli öğrenmedeki kırılganlığının eğitim ve çıkarım motorları arasındaki kalıcı sapma (drift) kaynaklı olduğunu gösterir. Sapmayı ortadan kaldırmak için 'skor merkezileme' (score centering) düzeltme terimini önerir ve bu yöntemin, tamamen eşleşen motorlar gerektirmeyen bir yaklaşım olarak RL stabilitesini sağladığını iddia eder. Tarih: 2026; sürüm: v1.

• Score Centering Stabilizes Off-policy Reinforcement Learning (Official Repository) — The official repository and implementation for the 'Score Centering' method, which proposes a correction term to stabilize off-policy RL under training-inference mismatch (TIM) by canceling drift. It includes JAX and PyTorch loss implementations, configuration sweeps for quantization/staleness, and integration with importance sampling. Tarih: 2026; sürüm: bilinmiyor.

• train_rl.py from martin-marek/score-centering — Implementation of an RL training loop using JAX that explicitly supports a 'score centering' (sc) correction term and various importance sampling (IS) strategies to handle drift between the trainer and sampler engines. Tarih: bilinmiyor; sürüm: main.

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).

GPU-CFR: Oyun Ağaçlarını Statik Veri Akışına Derleyerek Kernel Başlatma Maliyetini Azaltmak

1. Abstract & Executive Summary

GPU-CFR, sabit iki kişilik sıfır toplamlı oyunların ağaç yapısını derleme aşamasında düz dizilere ve önceden hesaplanmış indekslere dönüştürerek çalışma zamanındaki dinamik kontrol akışını ortadan kaldırır. Bu statik veri akışı yaklaşımı, CUDA Graph Replay ile tek bir grafik başlatma komutuyla tüm iterasyonları yürütmeye olanak tanır; böylece milyonlarca küçük kernel'in bireysel başlatma ve framework dağıtım maliyetleri eleme edilir. Yazar ölçümüne göre, tek bir A100 GPU üzerinde sekiz farklı oyundan oluşan test setinde, eşleşen en hızlı mevcut GPU CFR uygulamasına kıyasla 29.8–80.4 kat (medyan 44.1 kat) hızlanma elde edilmiştir GPU-CFR arXiv. Bu kazanımın önemli bir kısmı, CUDA Graphs'tan bağımsız olarak derlenmiş temsilin kendisinden kaynaklanır; yalnızca 8 CPU iş parçacığında çalışan derlenmiş çözüm, GPU baz çizgisine göre 2.2–51.1 kat daha hızlı çalışır GPU-CFR arXiv. Mekanizma, oyun topolojisinin ve tensör şekillerinin sabit kaldığı senaryolara özgüdür; dinamik yapılar veya farklı donanımlara genelleme iddiası bulunmamaktadır GPU-CFR arXiv. Doğrulama, CUDA yolunda atol=1e-9 toleransı kullanırken, CPU yolunda bire bir eşitlik gerektirmektedir GPU-CFR GitHub.

2. Tarihsel Arka Plan ve Problem Tanımı

Geleneksel GPU tabanlı CFR uygulamaları, oyun ağacındaki her bir bilgi seti ve eylem için ayrı kernel çağrıları yapar. Ağaç derinliği arttıkça, bu küçük bağımlı işlemlerin sayısı milyonlara ulaşır. Ancak modern GPU'larda tek bir kernel'in çalışma süresi mikrosaniye mertebesindeyken, kernel başlatma ve framework dağıtım gecikmesi (dispatch overhead) makro saniyelere kadar çıkabilir. Bu asenkron darboğaz nedeniyle, optimize edilmiş CPU kodlarına kıyasla GPU implementasyonlarının beklenen hızlanmayı sağlayamaması veya daha yavaş çalışması gözlemlenmiştir GPU-CFR arXiv.

Bu durumun temel nedeni, çalışma zamanında dinamik olarak belirlenen kontrol akışıdır. Standart yaklaşımlarda, her iterasyonda hangi kernelin ne zaman ve hangi parametrelerle çalışacağı CPU tarafından hesaplanır ve GPU'ya gönderilir. Bu süreçte oluşan kuyruk bekleme süreleri, GPU'nun yüksek paralel işleme kapasitesini boşa harcar. Sorun, oyunun matematiksel yapısı (topoloji, bilgi setleri, şans düğümleri) sabit kalırken, yalnızca strateji ve pişmanlık değerlerinin değişmesidir GPU-CFR arXiv.

Bu tarihsel kısıt, kontrol akışını sayısal hesaplama döngüsünden ayırma ihtiyacını doğurur. Eğer operasyon sırası önceden biliniyorsa, GPU'nun grafik replasman (graph replay) mekanizmaları kullanılabilir. Bu yaklaşım, tekrarlanan kernel dizilerini tek bir nesne olarak kaydeder ve yeniden oynatır. Böylece framework dağıtım maliyeti, iterasyon başına düşen toplam sürenin baskın bileşeni olmaktan çıkar GPU-CFR arXiv. Bu mekanizma, GPU-CFR'nin derleme aşamasında oyun yapısını statik veri akışına dönüştürme kararının temel gerekçesini oluşturur.

3. Matematiksel ve Teorik Temeller

GPU-CFR'nin performans kazanımı, iki katmandan oluşur: statik veri akışı temsilinin kendisi ve CUDA Graph Replay mekanizması. Derleme aşamasında oyun ağacı düz kenar dizileri ve önceden hesaplanmış indekslere dönüştürülür; bu sayede çalışma zamanındaki dinamik kontrol akışı sabit bir operasyon sırasına indirgenir. Yazar ölçümüne göre, yalnızca 8 CPU iş parçacığında çalışan derlenmiş temsil, GPU baz çizgisine kıyasla 2.2–51.1 kat daha hızlıdır; bu, kazanımın önemli kısmının CUDA Graphs'tan bağımsız olarak temsil değişikliğinden kaynaklandığını gösterir GPU-CFR arXiv.

CUDA Graph Replay katmanı ise framework dağıtım maliyetini ele alır. Tekrarlayan CFR iterasyonlarında operasyon sırası sabit kaldığından, kernel zinciri bir kez kaydedilip tek bir grafik başlatma komutuyla yeniden oynatılabilir. Bu yaklaşım, her iterasyonda CPU'nun milyonlarca küçük kernel'i sırayla GPU'ya göndermesi gereken dispatch döngüsünü atlayarak, çekirdek hesaplama sürelerinin (mikrosaniye mertebesinde) başlatma gecikmesine (makro saniye mertebesinde) oranını iyileştirir GPU-CFR arXiv.

Sayısal doğruluk açısından, CUDA-graph replay ile eager execution arasındaki farkın atol=1e-9 toleransı içinde kaldığı raporlanmıştır; bu, strateji ve pişmanlık toplamlarının tutarlılığını sağlar ancak bit-birebir eşitlik garantisi vermez GPU-CFR GitHub. Mekanizmanın geçerliliği, oyun topolojisinin, bilgi setlerinin ve tensör şekillerinin iterasyonlar boyunca sabit kalması varsayımına bağlıdır. Dinamik yapılar veya tablo dışı CFR varyantları için bu statik derleme yaklaşımı doğrudan uygulanamaz; ayrıca performans sonuçları yalnızca test edilen sekiz oyunlu A100 setiyle sınırlıdır ve farklı donanımlara genellenmesi için ek doğrulama gerektirir GPU-CFR arXiv.

4. Sistem Mimarisi ve Veri Akışı

GPU-CFR mimarisi, çalışma zamanı dinamikliğini derleme aşamasına taşıyarak iki temel yapısal dönüşüm uygular. İlk olarak, oyun ağacının topolojisi ve bilgi setleri düz kenar dizileri ile önceden hesaplanmış indekslere indirgenir. Bu statik temsil, her iterasyonda yalnızca strateji, pişmanlık (regret) ve erişim değerlerinin güncellenmesini gerektirir; operasyon sırası ise sabit kalır GPU-CFR arXiv. Bu yapısal karar, derlenmiş temsilin CUDA Graphs'tan bağımsız olarak bile 8 CPU iş parçacığında GPU baz çizgisine kıyasla 2.2–51.1 kat daha hızlı çalışmasını sağlar GPU-CFR arXiv.

İkinci katman, bu sabit operasyon zincirinin CUDA Graph Replay mekanizmasıyla yürütülmesidir. Sistem, CFR iterasyonundaki tüm kernel çağrılarını bir kez kaydeder ve ardından tek bir grafik başlatma komutuyla yeniden oynatır GPU-CFR arXiv. Bu yaklaşım, her kernel için ayrı ayrı yapılması gereken CPU tarafı framework dağıtım maliyetini ortadan kaldırır. Kod deposundaki iter_bench sürücüsü, bu iki modun (eager ve graph replay) kararlı durum iterasyon sürelerini karşılaştırmak için tasarlanmıştır GPU-CFR GitHub. Doğrulama testleri, CUDA-graph replay çıktılarının eager çalıştırma ile pişmanlık toplamları ve kök değerinde 1e-9 tolerans sınırlarında tutarlı olduğunu gösterir GPU-CFR GitHub.

Mimarinin kritik sınırı, sabit oyun topolojisine bağımlılığıdır. Derleme işlemi, ağaç yapısı, şans davranışı ve tensör şekillerinin iterasyonlar boyunca değişmediği varsayımına dayanır GPU-CFR arXiv. Dinamik oyun yapıları veya farklı tensor boyutlarına sahip senaryolar, bu statik veri akışı yaklaşımının doğrudan uygulanabilirliğini ortadan kaldırır. Ayrıca, bağımsız doğrulama süreçlerinde bazı baz çizgileri (örneğin NoRegret) eksik sürücü dosyaları nedeniyle paket üzerinden çalıştırılamamaktadır GPU-CFR GitHub.

5. Uygulama ve Referans Kod

GPU-CFR referans implementasyonu, derlenmiş oyun temsilini gpu_cfr/solvers/ altındaki CUDA-graph tabanlı aşamalı çözümleyici ve yaşam döngüsü API'si ile birleştirir. Modül yapısı, tensor düzeni, kenar tabloları ve toplama mantığını statik olarak tanımlarken, çalışma zamanında yalnızca reset(), set_payoffs() ve set_root_ranges() gibi durum güncelleyici fonksiyonlar çağrılır GPU-CFR GitHub. Bu yapı, CUDA Graph Replay'in gerektirdiği sabit operasyon sırasını doğrudan destekler; kernel zinciri bir kez kaydedildikten sonra, her iterasyonda tek bir grafik başlatma komutuyla yürütülür. Depoda yer alan iter_bench sürücüsü, steady-state iterasyon sürelerini eager (açık) çalıştırma ve CUDA-graph replay modları arasında karşılaştırmak için tasarlanmıştır; bu araç, framework dağıtım maliyetinin izole edilerek ölçülmesine olanak tanır GPU-CFR GitHub.

Doğrulama süreci, sayısal tutarlılığı garanti altına almak için iki farklı eşik kullanır. CPU yolunda bit-bir (bitwise) eşitlik kontrolü uygulanırken, CUDA yolu için atol=1e-9 toleransı kabul edilir; bu fark, GPU kayan nokta aritmetiğindeki beklenen küçük sapmaları yansıtır GPU-CFR GitHub. Yazar ölçümüne göre, CUDA-graph replay sonuçları pişmanlık toplamları, strateji toplamları ve kök değerinde eager çalıştırmayla bu tolerans sınırları içinde örtüşmektedir GPU-CFR GitHub. Bağımsız doğrulama açısından önemli bir sınırlama olarak, NoRegret baz çizgisi dış sürücü dosyalarının eksikliği ve ABI uyumsuzlukları nedeniyle paketten doğrudan çalıştırılamamaktadır; bu durum, belirli karşılaştırmaların yeniden üretimini kısıtlar GPU-CFR GitHub. LiteEFG ise EFG girdisini destekleyerek kısmi bir alternatif doğrulama yolu sunar. Kod yapısının statik veri akışı ile CUDA Graphs'ı entegre ettiği, ancak performans metriklerinin yalnızca yazarın raporladığı ölçümlere dayandığı not edilmelidir.

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

GPU-CFR'nin performans iddiaları, tek bir NVIDIA A100 GPU üzerinde sekiz farklı oyundan oluşan (kart, zar ve tahta oyunları) standart bir test setinde ölçülmüştür. Yazar ölçümüne göre, sistem eşleşen en hızlı mevcut GPU CFR uygulamasına kıyasla 29.8–80.4 kat (medyan 44.1 kat) daha hızlı çalışmaktadır GPU-CFR arXiv. Bu hızlanmanın kaynağını anlamak için kazanım iki bileşene ayrıştırılmalıdır: statik veri akışı temsili ve CUDA Graph Replay mekanizması.

Önemli bir mühendislik çıkarımı, derlenmiş temsilin kendisinin bağımsız bir performans kazancı sağladığıdır. Yazar ölçümüne göre, yalnızca 8 CPU iş parçacığında çalışan ve hiçbir hızlandırıcı kullanmayan derlenmiş çözüm, GPU baz çizgisine kıyasla 2.2–51.1 kat daha hızlıdır GPU-CFR arXiv. Bu sonuç, toplam hızlanmanın büyük kısmının CUDA Graphs'tan bağımsız olarak, dinamik kontrol akışının statik dizilere indirgenmesinden kaynaklandığını gösterir. CUDA Graph Replay katmanı ise framework dağıtım maliyetini ele alarak bu taban kazanımına ek bir iyileştirme sağlar.

Doğruluk açısından, CUDA-graph replay çalıştırması eager (açık) çalıştırmayla tutarlıdır; pişmanlık toplamları ve strateji değerleri 1e-9 tolerans sınırı içinde eşleşmektedir GPU-CFR GitHub. Ancak bağımsız doğrulama sınırlıdır: NoRegret baz çizgisi, eksik sürücü dosyaları nedeniyle paket üzerinden çalıştırılamamaktadır GPU-CFR GitHub. Sonuçlar yalnızca test edilen sekiz oyunda ve tek A100 donanımında geçerlidir; farklı oyun yapıları veya donanımlara genelleştirilemez.

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

GPU-CFR yaklaşımının geçerliliği, oyun yapısının çalışma zamanında değişmemesi koşuluna sıkı sıkıya bağlıdır. Sistem; ağaç topolojisi, bilgi setleri, şans davranışları ve tensor boyutlarının sabit kaldığı senaryolar için tasarlanmıştır. Bu varsayım altında yalnızca strateji, erişim (reach) ve pişmanlık (regret) değerleri iterasyonlar arasında değişir; operasyon sırası ise derleme aşamasında dondurulur GPU-CFR arXiv. Dinamik oyun yapıları veya tablo dışı (non-tabular) CFR varyantları, bu statik veri akışı varsayımını ihlal ettiği için mevcut mimari doğrudan uygulanamaz; ek adaptasyon gerektirir.

Performans ölçümleri de belirli donanım ve ölçek sınırlarına sahiptir. Raporlanan 29.8–80.4 katlık hızlanma, tek bir NVIDIA A100 GPU üzerinde ve test edilen sekiz oyundan oluşan spesifik bir set için geçerlidir GPU-CFR arXiv. Bu sonuçların farklı GPU mimarilerine, çok daha büyük veya küçük oyun ağaçlarına veya alternatif çözümleyici yapılandırmalarına genellenmesi kaynaklarda desteklenmemektedir.

Doğrulama sürecindeki mühendislik ödünleşimleri de dikkat çekicidir. CPU implementasyonu, referans iterasyonlarla birebir (bitwise) eşitlik kontrolü için zorunlu tutulurken, CUDA karşılaştırmalarında atol=1e-9 toleransı kabul edilmiştir GPU-CFR GitHub. Bu durum, GPU yolunun sayısal kesinlik garantisi açısından CPU yolundan farklı bir doğrulama standardına tabi olduğunu gösterir. Ayrıca, bağımsız validasyon için kritik olan NoRegret baz çizgisi, paket içinde eksik sürücü dosyaları ve ABI uyumsuzlukları nedeniyle çalıştırılamamaktadır; bu durum bazı karşılaştırmaların tam olarak yeniden üretilmesini engeller GPU-CFR GitHub. Sonuç olarak, GPU-CFR'nin kazancı, statik yapı varsayımı ve belirli donanım koşulları altında geçerli olan, sınırları net çizilmiş bir mühendislik çözümüdür.

8. Gelecek Projeksiyonu ve Açık Sorunlar

GPU-CFR'nin mevcut mimarisi, statik oyun topolojisi varsayımına sıkı sıkıya bağlıdır. Ağaç yapısı, bilgi setleri ve tensor boyutları çalışma zamanında değiştiğinde, derlenmiş veri akışı geçersiz hale gelir; bu durum dinamik oyun senaryolarında veya tablo dışı (non-tabular) CFR varyantlarında doğrudan uygulanabilirliği sınırlar GPU-CFR arXiv. Bu yapısal kısıt, sistemin genişletilebilirlik potansiyelini belirleyen temel faktördür.

Ölçüm sonuçlarının genellenmesi de dikkatli yorum gerektirir. Raporlanan 29.8–80.4 katlık hızlanma, yalnızca tek bir NVIDIA A100 GPU üzerinde ve sekiz oyundan oluşan spesifik bir test setinde elde edilmiştir GPU-CFR arXiv. Farklı donanım mimarileri, çok daha büyük oyun ölçekleri veya alternatif çözümleyici yapılandırmaları için bu kazanımın korunup korunmayacağı henüz doğrulanmamıştır. Ayrıca, bağımsız doğrulama süreci bazı teknik engellerle karşı karşıyadır; örneğin NoRegret baz çizgisi, eksik sürücü dosyaları ve ABI uyumsuzlukları nedeniyle mevcut paket üzerinden çalıştırılamamaktadır GPU-CFR GitHub.

Gelecekteki çalışmaların odaklanması gereken kritik alanlar şunlardır:

1. Dinamik Topoloji Desteği: Oyun yapısının çalışma zamanında değişebildiği senaryolar için yeniden derleme maliyetini minimize edecek hibrit mekanizmalar geliştirilmelidir.
2. Donanım Genellenmesi: Farklı GPU nesilleri ve çoklu GPU kurulumlarında CUDA Graph Replay'in verimliliğinin incelenmesi gerekmektedir.
3. Doğrulama Standartları: CPU tarafındaki bit-bit eşitlik kontrolü ile GPU tarafındaki tolerans tabanlı (atol=1e-9) doğrulama arasındaki fark, bağımsız tekrarlanabilirlik açısından netleştirilmelidir GPU-CFR GitHub.

Bu sınırlar, GPU-CFR'nin mevcut başarısının belirli bir mühendislik ödünleşimi sonucu olduğunu gösterir. Statik derlemenin sağladığı hızlanma, esneklikten vazgeçilerek elde edilmiştir; dolayısıyla daha geniş oyun alanlarına yayılım, mimari düzeyde yeni adaptasyonlar gerektirecektir.

9. Referanslar ve İleri Okuma

• GPU-CFR: 80x Faster Counterfactual Regret Minimization by Compiling the Game to Static Dataflow and CUDA Graph Replay — Original research proposing GPU-CFR, a compiler that transforms fixed game structures into static dataflow graphs for CUDA Graph Replay to eliminate kernel launch overhead in CFR iterations. Tarih: 2026-09-10; sürüm: v1.

• GPU-CFR: 80x Faster Counterfactual Regret Minimization by Compiling the Game to Static Dataflow and CUDA Graph Replay — Official code repository for the paper proposing GPU-accelerated CFR via static dataflow compilation and CUDA Graph replay. Tarih: 2026; sürüm: bilinmiyor.

Kubernetes'te CXL Bellek ile LLM KV Önbelleği: Fizibilite Sınırları ve Paylaşımlı Katman Tasarımı

1. Abstract & Executive Summary

Bu fizibilite çalışması, Kubernetes DRA sürücüsüyle kompoze edilebilir CXL belleğini küme düzeyinde programlanabilir bir kaynağa dönüştürür. Sürücü, talebe göre oluşturulan CXL bölgelerini her konakta DAX cihazı olarak somutlaştırır ve tek bir CDI adı altında konteynerlere enjekte eder Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Bu tasarım, standart DRA'nın tek düğümlü ResourceSlice varsayımını aşarak aynı fiziksel bölgeye birden fazla düğümden erişimi mümkün kılar Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. İki düğümlü test yatağında Qwen2.5-7B-Instruct modeliyle yapılan ölçümlerde, dışarıdan gelen önek yeniden kullanımı TTFT'yi 5.5x–36.6x oranında azaltmıştır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Düğüme özgü katmanların tam yeniden hesaplama yaparken paylaşılan CXL katmanının %95.4–99.5 isabet oranı sağlaması, paylaşım açığını somutlaştırır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Düğümler arası yeniden kullanımın aynı düğümdeki yeniden kullanıma kıyasla gecikme oranı yalnızca %1–4 olarak ölçülmüştür Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Çalışma, prefill/decode ayrıştırması değil bellek ayrıştırması gösterir; kapalı döngü test düzeneği TTFT metrikini desteklerken iyi getiri veya kuyruk gecikmesi iddiaları yapılmaz Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Zamanlayıcı yalnızca bıçak seçimini yapar, kapasite hesabı ve aşırı taahhüt koruması bulunmaz Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Sıfır kopyalı GPU-CXL DMA, havuzlanmış RDMA taban çizgisi ve çok kiracılı zamanlama deneyleri açık hedef dışı olarak belirlenmiştir Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving.

2. Tarihsel Arka Plan ve Problem Tanımı

Standart Kubernetes DRA, genellikle tek bir fiziksel konuma bağlı hızlandırıcılar için tasarlanmıştır; ResourceSlice nesnesi belirli bir düğümü adlandırır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Kompoze edilebilir CXL belleği ise birden fazla konakta eşzamanlı takılabilen bir topoloji sunar. Bu durum, mevcut DRA'nın tek düğümlü varsayımını kıran temel bir darboğaz yaratır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Çözümün çekirdeği, cihaz soyutlaması ile kaynak yönetimini ayıran Container Device Interface (CDI) mekanizmasına dayanır. CDI, üçüncü taraf cihazları tam nitelikli adlarla tanımlar; ancak kapsamı yalnızca konteynerin cihaza erişimini sağlamaktır CDI - The Container Device Interface. Kaynak yönetimi açıkça orkestratöre bırakılmıştır CDI - The Container Device Interface. Bu ayrım, DRA sürücüsünün CXL bölgelerini küme kaynağı olarak planlayıp, somutlaştırdığı cihazları tek bir CDI adı altında konteynerlere enjekte etmesine olanak tanır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Farklı düğümlerdeki pod'lar böylece aynı fiziksel bölgeye erişebilir hale gelir.

Alternatif yaklaşımlarda, NVIDIA NIXL gibi kütüphaneler CPU ve GPU bellek türleri üzerinde soyutlama sağlayarak dağıtık metadata değişimi için ETCD kullanır NVIDIA Inference Xfer Library (NIXL). Bu yöntemler ağ tabanlı veri aktarımına odaklanırken, CXL tabanlı yaklaşım ağ kopyalama maliyeti yerine paylaşılan fiziksel bellek alanı üzerinden doğrudan erişimi hedefler. DRA entegrasyonu sayesinde bu katman, düğüm yerel izolasyonunun yarattığı yeniden hesaplama sorununu ortadan kaldırmayı amaçlar Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving.

3. Matematiksel ve Teorik Temeller

Kazanç mekanizması, düğüme özgü bellek katmanlarının karşılayamadığı erişim maliyetini kapatmasından kaynaklanır. Yazarların ölçümüne göre, iki düğümlü test yatağında Qwen2.5-7B-Instruct modeliyle yapılan denemelerde dışarıdan gelen önek yeniden kullanımı TTFT değerini 5.5x–36.6x oranında azaltmıştır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Bu hızlanma, GPU önbellekleme ve CPU-DRAM ofload gibi yerel katmanların tam yeniden hesaplamaya düşmesiyle oluşan "paylaşım boşluğunu" kapatmasından ileri gelir Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Düğümler arası erişim gecikmesinin, aynı düğümdeki yeniden kullanıma kıyasla %1–4 oranında ek maliyet getirdiği ölçülmüştür; bu düşük oran, CXL topolojisinin ağ tabanlı çözümlere göre gecikme avantajı sunduğunu gösterir Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving.

Bu teorik kazanımın pratikteki sınırı, zamanlayıcı mantığındaki basitlikte yatar. Sistemde kapasite hesaplama veya aşırı taahhüt koruması bulunmaz; zamanlayıcı yalnızca fiziksel bıçak seçimini yapar Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Bu nedenle, yakın aralıklarla oluşturulan iki talep aynı boş kapasiteye tahsis edilebilir ve ikinci talep oluşturma anında başarısız olur Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Ayrıca, deney düzeneği kapalı döngüde çalıştığı için bu sonuçlar goodput veya kuyruk gecikmesi gibi yüksek yük metriklerini desteklemez Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Sıfır kopyalı DMA ve çok kiracılı zamanlama açık hedef dışıdır; bu nedenle, yüksek eşzamanlılık senaryolarında CXL katmanının davranışı henüz doğrulanmamıştır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving.

4. Sistem Mimarisi ve Veri Akışı

Mimari katmanlar, talebi küme düzeyinde bir kaynak iddiasına dönüştürüp fiziksel CXL belleğini konteyner içi DAX cihazı olarak görünür kılar. Standart DRA'da ResourceSlice tek düğümü adlandırır; bu tasarımda sürücü, bölge oluşturma işlemini tetikleyerek aynı fiziksel alanın birden fazla konakta somutlaşmasını sağlar Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. CDI, cihaz soyutlamasını yönetirken kaynak tahsisini orkestratöre bırakır; bu ayrım, DAX cihazlarının pod'lara enjeksiyonunda kritik rol oynar CDI - The Container Device Interface. Veri akışı, LLM sunucusunun KV önbelleği için paylaşımlı bölgeye erişim isteğiyle başlar ve DAX cihazı üzerinden CXL fabric'a ulaşır. Zamanlayıcı yalnızca bıçak seçimini yapar; kapasite hesaplama veya aşırı taahhüt koruması bulunmaz, bu da eşzamanlı taleplerde oluşturma anında hata riski taşır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving.

[LLM Pod A]                [LLM Pod B]
     |                          |
[CDI: cxi-region]      [CDI: cxi-region]
     |                          |
[DAX /dev/dax0.0]      [DAX /dev/dax1.0]
     \                        /
      +----------------------+
             |
      [CXL Switch/Fabric]
             |
[Shared CXL Memory Region]

Bu yapı, düğüme özgü katmanların tam yeniden hesaplamaya düşmesiyle oluşan paylaşım boşluğunu kapatır. Ancak sistem prefill/decode ayrıştırması değil, bellek ayrıştırması olarak çalışır; sıfır kopyalı DMA ve çok kiracılı zamanlama açık hedef dışıdır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving.

5. Uygulama ve Referans Kod

Önceki bölümde tanımlanan DRA-CDI entegrasyonu, aşağıdaki sözde kodla somutlaştırılır. Bu akış, talep üzerine bölge oluşturma ve konaklarda DAX cihazı olarak somutlaştırma adımlarını temsil eder; kodun çalıştırıldığı iddia edilmemektedir. Mekanizma, Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving kaynakındaki mimariyi yansıtır.

# Varsayımlar: N düğüm, M byte'lık CXL bölge, tek CDI FQN
function allocate_cxl_region(request):
    # 1. DRA Sürücüsü: Küme düzeyinde tahsis
    region_id = compose_cxl_region(size_bytes=M)
    
    # 2. Konak Somutlaştırma: Her düğümde DAX cihazı
    for node in participating_nodes:
        dax_dev = materialize_dax(node, region_id)
        
    # 3. CDI Enjeksiyonu: Konteyner içi erişim
    cdi_fqn = generate_cdi_name("cxl.mem", region_id)
    for pod in target_pods:
        inject_device(pod, cdi_fqn)
        
    return region_id

# KV Önbellek Erişimi (Uygulama Düzeyi)
function read_kv_cache(process):
    addr = mmap(dax_device, offset=kv_offset)
    return data_from(addr)

Bu sözde kod, yalnızca bıçak seçimini yapan zamanlayıcı mantığını gösterir; kapasite hesaplama ve aşırı taahhüt koruması sürücü tarafında bulunmaz Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. CDI katmanı, cihaz soyutlamasını yönetirken kaynak tahsisini orkestratöre bırakır; bu ayrım, konteynerin cihaza erişimini standartlaştırır CDI - The Container Device Interface. DAX cihazı, kullanıcı uzayından doğrudan erişim sağlayarak ağ tabanlı kopyalama maliyetini ortadan kaldırır. Ancak bu mimari, prefill/decode ayrıştırması değil, bellek ayrıştırması olarak çalışır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Ölçümler kapalı döngü ve sefer başına tek oturum varsayımıyla yapıldığından, bu kod üretim ortamlarındaki kuyruk dinamiklerini yansıtmaz Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving.

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

Yazarların iki düğümlü test yatağında (512 GiB CXL aygıtı, Qwen2.5-7B-Instruct) gerçekleştirdiği ölçümler, düğümler arası önek yeniden kullanımının Time-To-First-Token (TTFT) değerini 5.5x–36.6x oranında azalttığını göstermektedir Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Bu kazanç, dışarıdan gelen isteklerde %95.4–99.5 aralığında bir önbellek isabet oranıyla elde edilmiştir Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Karşılaştırma tablosunda, düğüm yerel katmanların (GPU önek önbelleği ve CPU-DRAM offload) bu senaryoda tam yeniden hesaplama durumuna düşerken, paylaşılan CXL katmanının isabet sağlayabildiği görülmektedir Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Bu yapısal fark, düğümler arası paylaşımın gerekliliğini vurgular.

Katman	TTFT Kazancı	İsabet Oranı
Paylaşılan CXL (DRA)	5.5x – 36.6x	%95.4 – 99.5
GPU Önek Önbelleği	Tam yeniden hesaplama	raporlanmadı
CPU-DRAM Offload	Tam yeniden hesaplama	raporlanmadı

Düğümler arası erişimin ek maliyeti, paylaşım boşluğu (sharing gap) metriğiyle değerlendirilmiştir. Yazarların ölçümüne göre, düğümler arası ve aynı düğümdeki yeniden kullanım arasındaki gecikme oranı yalnızca %1–4 arasındadır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Bu düşük oran, test yatağındaki CXL topolojisinin ağ tabanlı çözümlere kıyasla daha az ek gecikme getirdiğine işaret eder. Ancak bu çalışma bir fizibilite raporu olup, performans değerlendirmesi olarak sunulmamaktadır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Deney düzeneği kapalı döngüde ve sefer başına tek oturum çalıştığından, iyi getiri (goodput) veya kuyruk gecikmesi iddiaları yapılmamıştır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Sıfır kopyalı GPU-CXL DMA ve havuzlanmış RDMA taban çizgisi, bu analizlerin kapsamı dışında bırakılmıştır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving.

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

Bu fizibilite çalışması, prefill/decode ayrıştırmasından ziyade bellek ayrıştırmasını (memory disaggregation) hedefler; her iki replika da tam motor olarak çalışır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Bu kapsam, düğümler arası yeniden kullanımın aynı düğümdeki duruma kıyasla eklatansının (sharing gap) yalnızca %1–4 olduğunu ölçen test yatağına özgüdür ve genel bir performans üst sınırı teşkil etmez Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving.

Mühendislik ödünleşimleri, zamanlayıcı tasarımındaki sınırlarla doğrudan bağlantılıdır. Zamanlayıcı yalnızca bıçak (blade) seçimini yapar; kapasite hesaplama veya aşırı taahhüt koruması içermez Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Bu yapısal boşluk nedeniyle, yakın zamanda oluşturulan iki talep aynı boş kapasiteye tahsis edilebilir ve ikinci talep bölge oluşturma (compose) sırasında başarısız olabilir Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Ayrıca, sıfır kopyalı GPU-CXL DMA, havuzlanmış RDMA taban çizgisi ve çok kiracılı zamanlama deneyleri açık hedef dışı (non-goal) olarak tanımlanmıştır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving.

Ölçüm düzeneğinin kapalı döngü (closed-loop) çalışması ve sefer başına yalnızca bir oturum yürütmesi, metriklerin kapsamını daraltır. Bu yapı Time-To-First-Token (TTFT) metriğini desteklerken, iyi getiri (goodput) veya kuyruk gecikmesi (tail-latency) gibi yük bağımlı iddiaların yapılmasını engeller Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Sonuç olarak, raporlanan hızlanma değerleri spesifik test koşullarına bağlıdır ve farklı istek desenleri veya eşzamanlılık seviyelerinde genellenmemelidir.

8. Gelecek Projeksiyonu ve Açık Sorunlar

Bu fizibilite çalışması, prefill/decode ayrıştırması yerine bellek ayrıştırmasını (memory disaggregation) hedefler; her iki replika da tam motor olarak çalışır Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Bu kapsam, düğümler arası yeniden kullanımın aynı düğümdeki duruma kıyasla eklatansının (sharing gap) yalnızca %1–4 olduğunu ölçen test yatağına özgüdür ve genel bir performans üst sınırı teşkil etmez Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving.

Mühendislik ödünleşimleri, zamanlayıcı tasarımındaki sınırlarla doğrudan bağlantılıdır. Zamanlayıcı yalnızca bıçak (blade) seçimini yapar; kapasite hesaplama veya aşırı taahhüt koruması içermez Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Bu eksiklik nedeniyle, kısa aralıklarla oluşturulan iki talep aynı boş kapasiteye tahsis edilebilir ve ikinci talep compose zamanında başarısız olur Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Bölge boyutu (byte sayısı) yerine bıçak seçimi üzerinden çalışan bu mekanizma, çok kiracılı ortamlardaki eşzamanlılık çakışmalarını yönetmek için ek bir katman gerektirir.

Geleceğe yönelik açık sorunlar arasında sıfır kopyalı GPU-CXL DMA, havuzlanmış RDMA taban çizgisi ve çok kiracılı zamanlama deneyleri yer alır; bunlar çalışma kapsamında açık hedef dışı (non-goal) olarak belirlenmiştir Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Ayrıca, kapalı döngü test düzeneğinin sefer başına yalnızca bir oturum yürütmesi nedeniyle, iyi getiri (goodput) veya kuyruk gecikmesi (tail-latency) iddiaları yapılamaz Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving. Bu sınırlamalar, sistemin mevcut haliyle yalnızca belirli bir senaryoda işlevselliğini kanıtladığını, ancak yüksek yük altındaki davranışının henüz doğrulanmadığını gösterir.

9. Referanslar ve İleri Okuma

• Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving: A Feasibility Study on Seagate Composable Memory Appliance — A feasibility study presenting a Kubernetes DRA driver for composable CXL memory and evaluating its use as a shared KV-cache tier for cross-node LLM serving. Tarih: 2026-09-11; sürüm: v1 feasibility report.

• CDI - The Container Device Interface — Official documentation for the Container Device Interface (CDI) specification and CLI, explaining how container runtimes support third-party devices. Tarih: bilinmiyor; sürüm: 0.6.0 (spec version mentioned in examples).

• NVIDIA Inference Xfer Library (NIXL) GitHub Repository README — Official documentation for NIXL, a library for accelerating point-to-point communication in AI inference frameworks. It provides an abstraction over various memory types (CPU, GPU) and storage backends via a modular plugin architecture. Tarih: 2026-09-11; sürüm: bilinmiyor.