OpenShift AI 3.5’te KV cache offloading: CPU, NVMe ve CephFS

Red Hat, OpenShift AI 3.5’te KV cache offloading ile vLLM’in KV cache verisini GPU belleğinden CPU DRAM’e, yerel NVMe’ye ya da CephFS gibi POSIX uyumlu dosya sistemlerine taşıyan katmanlı yapının H100 benchmark sonuçlarını yayımladı. Ortalama yaklaşık 50K input token’lık agentic iş yüklerinde Nemotron-Ultra-253B için throughput 5,8 kata kadar arttı, ortalama TTFT (Time To First Token) 60 saniyeden 10 saniyeye indi.

OpenShift AI nedir, ne işe yarar?

Red Hat OpenShift AI, OpenShift üzerinde yapay zekâ modellerini geliştirmek, eğitmek ve servis etmek için Red Hat’in sunduğu platformdur. Model serving tarafında vLLM gibi inference motorlarını Kubernetes iş yükü olarak çalıştırır. Kurumsal ortamda GPU’lu cluster işleten ekipler kullanır; benzer işi gören alternatifler arasında Kubeflow ve bulut sağlayıcılarının yönetilen ML platformları sayılabilir.

KV cache nedir, ne işe yarar?

KV cache, transformer tabanlı dil modellerinin daha önce işlenen token’lar için hesapladığı key ve value tensörlerini saklayan bellek alanıdır. Model her yeni token’da önceki token’ları baştan hesaplamak yerine bu cache’i okur. Boyutu context uzunluğuyla doğrusal büyür ve genellikle GPU belleğinde tutulur; vLLM gibi inference motorları bu alanı bloklar hâlinde yönetir.

KV cache offloading hangi iş yükünde fark yaratıyor

Agentic uygulama, RAG ve çok turlu asistan çalıştıran ekiplerin ortak derdi aynı: model aynı prompt önekini tekrar tekrar görüyor. GPU HBM dolunca vLLM bu öneki atıyor ve bir sonraki istekte prefill’i baştan hesaplıyor. KV cache offloading bu işi çöpe atmak yerine daha ucuz bir katmana yazıyor.

Testler OpenShift AI 3.5 ile gelen vLLM 0.24.0 ve llm-d 0.8.0 üzerinde, OpenShift 4.22.2 cluster’ında 8xH100 node’larla yapıldı. En büyük fark Nemotron-Ultra-253B’de çıktı. Yalnızca CPU offload 3,3 kat kazanç verdi, NVMe ya da CephFS eklenince bu 5,8 kata yükseldi. Ayrımı yapan şey, modelin KV working set’inin CPU katmanına sığıp sığmaması.

Önce working set’i CPU katmanıyla karşılaştırın

Kaynaktaki örnekle kaba bir hesap yapalım. Llama 3.1 70B FP8 token başına yaklaşık 0,3 MB KV cache tutuyor, 128K token’lık tek context yaklaşık 40 GB ediyor. Testte Qwen ve Gemma için cpu_bytes_to_use 64 GB’tı. Bu boyuttaki bir CPU katmanı, Llama ölçeğinde bir modelin ancak bir buçuk tam 128K context’ini taşır.

Kendi modeliniz için kaynaktaki formülü kullanın: token başına bayt = 2 x attention katman sayısı x (KV head / TP) x head boyutu x eleman başına bayt. Sonucu ortalama context uzunluğu ve eşzamanlı oturum sayısıyla çarpıp CPU’ya ayıracağınız bellekle karşılaştırın. Sonra topolojiye göre seçin:

• Working set CPU’ya sığıyor: yalnızca CPU offload yeterli, disk katmanının ek kazancı sınırlı kalıyor.
• Sığmıyor, tek node: yerel NVMe. Testte en düşük ikincil katman latency’si burada ölçüldü.
• Sığmıyor, birden fazla replica: CephFS. Blok başına latency daha yüksek ama replica’lar aynı cache’i paylaşıyor. Çok replica’lı testlerde concurrency arttıkça CPU-only yapılar recompute’a döndü, CephFS reuse’u korudu.

Restore mu, recompute mu: crossover hesabı

Bir katmanın işe yarayıp yaramadığını tek soru belirliyor. Bloğu diskten geri yüklemek, aynı öneki GPU’da yeniden hesaplamaktan kısa mı sürüyor? Red Hat bunu şöyle formüle ediyor: “Lcrossover = TFIO,p99 / tprefill”, burada tprefill = TTFT / context uzunluğu.

Yani iki ölçüme ihtiyacınız var. Birincisi offload kapalıyken modelinizin TTFT’si; bunu context uzunluğuna bölünce token başına prefill maliyeti çıkıyor. İkincisi aday katmanın p99 restore süresi. Context’leriniz crossover değerinin üstündeyse restore kazanır. Kaynak bu eşiklerin evrensel olmadığını açıkça yazıyor, çünkü model ya da GPU sayısı değişince tprefill da değişiyor.

FIO’da p50’ye değil p99’a bakın

Sıralı 1 MB okuma testi bant genişliği tavanını gösterir, connector’ın gerçek erişim desenini göstermez. vLLM 16 token’lık sabit bloklarla çalışıyor ve connector eşzamanlı okuma ile yazma yapıyor. Red Hat’in inference (çıkarım) öncesi depolama ölçümü için kullandığı FIO komutu şu:

fio --rw=randrw --rwmixread=75 --bs=<blok_boyutu> --iodepth=1 --numjobs=16 --direct=1 --ioengine=libaio --runtime=60

–bs yerine modelinizin sunucu genelindeki blok boyutunu yazın. Kaynaktaki değerler gpt-oss-120B için yaklaşık 1,2 MB, Llama 3.1 70B FP8 için yaklaşık 5 MB.

Sonuçlarda RGW/S3 tuzağına dikkat edin. p50’de rekabetçi görünüyor ama 5 MB blokta p99 1,13 saniyeye çıkıyor ve bu tail doğrudan TTFT’ye biniyor. CephFS’in yaklaşık 205 MB/s’lik protokol tavanı da hesaba girmeli. 5 MB blokla bu, o test ortamında saniyede kabaca 41 blok restore demek.

CephFS kurulumundaki tek kopya bedeli

Testteki CephFS katmanı OpenShift Data Foundation 4.18 üzerinde 3 OSD ile kuruldu ve KV cache havuzlarında size 1 kullanıldı. Her blok tek OSD’de tek kopya duruyor. Bir OSD düşerse kalıcı veri kaybı yok, çünkü içerik yalnızca cache. Ama o OSD’deki girdiler miss oluyor ve recovery boyunca GPU bu önekleri yeniden hesaplıyor.

KV cache offloading için replication’ı artırmayı düşünüyorsanız, yayımlanan rakamların size 1 ile alındığını hesaba katın. Ölçümler IBM Cloud VPC block cihazları üzerindeki Ceph ile yapıldı; kendi Ceph cluster’ınızda FIO testini yeniden koşmadan bu sayıları kapasite planına yazmayın.