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.