Red Hat AI ile GPU Maliyetlerini Optimize Etmenin Akıllı Yolu

AI projelerine yatırım yapan şirketlerin en büyük sorularından biri şu: GPU kaynaklarımızı gerçekten verimli kullanıyor muyuz? Her geçen gün daha karmaşık hale gelen LLM iş yükleri, yanlış mimarilerle kurulduğunda GPU maliyetlerini katlanarak artırıyor. Basit chatbotlardan otonom agent workload’larına uzanan bu süreçte, doğru inference altyapısını seçmek artık bir tercih değil, zorunluluk.

Bu makalede, Red Hat AI ürün ailesinin temel bileşeni olan vLLM Inference Server ile başlayarak llm-d, Semantic Router, KEDA ve Kueue teknolojilerinin bir araya geldiğinde nasıl akıllı ve maliyet-etkin bir AI inference mimarisi oluşturduğunu inceliyoruz.

vLLM Inference Server Nedir ve Neden Önemlidir?

Geleneksel LLM inference mimarilerinde ciddi bir kaynak israfı söz konusudur. Sisteme gelen her istek — ister basit bir “merhaba” mesajı olsun, ister 20.000 token’lık bir kod analizi — maksimum sequence length’e göre önceden sabit bir bellek bloğu tahsis edilir. Kullanıcı 50 token’da işini bitirdiğinde, kalan bellek bir sonraki isteğe kadar boşta bekler.

Paged Attention ile KV Cache Optimizasyonu

vLLM Inference Server, işletim sistemlerindeki sanal bellek mantığından ilham alarak geliştirilen Paged Attention mekanizmasını kullanır. Bu yaklaşımla KV Cache, sabit boyutlu küçük bloklara bölünür:

• İstek büyüdükçe yeni blok eklenir
• İstek tamamlandığında blok serbest bırakılır
• Aynı sistem promptunu kullanan farklı istekler, o prefix’e ait KV Cache bloklarını fiziksel olarak paylaşır — bellek kopyalanmaz, yeniden kullanılır

Bu mimari sayesinde daha hızlı response time elde edilmesi, memory’nin daha etkin kullanılması ve doğrudan donanım maliyetinin düşürülmesi mümkün hale gelir.

İlginizi Çekebilir: Yapay Zekâ Gelişmeleri ve OpenShift AI Platform

llm-d ile Disaggregated Inference: Prefill ve Decode Ayrımı

Geleneksel LLM inference sürecinde iki kritik aşama aynı GPU üzerinde çalışmak zorunda kalır:

• Prefill (hesaplama yoğunluklu): Soruyu anlayan ve bağlamı üreten aşama
• Decode (bellek yoğunluklu): Cevabı kelime kelime üreten aşama

Bu iki sürecin aynı kaynakta çalışması darboğaz yaratır: uzun bir prefill işlemi başladığında decode beklemek zorunda kalır ve aktif kullanıcıların yanıt akışı yavaşlar.

llm-d’nin Çözümü: Pod Bazlı İş Ayrımı

llm-d, prefill ve decode süreçlerini birbirinden ayırarak her işi en uygun pod’a yönlendirir:

• Prefill pod’ları: Yüksek hesaplama gücü için optimize edilmiş
• Decode pod’ları: Bellek bant genişliği için optimize edilmiş

Prefill pod’u KV Cache’i ürettikten sonra decode pod’una transfer eder. Bu sayede TTFT ve yanıt akıcılığı birbirinden bağımsız olarak iyileştirilebilir.

Semantic Router: Akıllı Model Yönlendirme Katmanı

Kurumsal AI altyapılarında onlarca farklı model bir arada çalışır. Matematik için güçlü bir model yaratıcı yazarlıkta zayıf kalabilir; kod analizinde uzmanlaşmış bir model için basit bir soruyu göndermek ise gereksiz maliyet yaratır. Her istek için büyük bir reasoning modeli kullanıldığında sonuç hem maliyetli hem de verimsizdir.

Maliyet-Doğruluk Dengesini Nasıl Kurar?

vLLM Semantic Router, ModernBERT gibi hafif bir sınıflandırıcı kullanarak gelen isteğin içeriğini ve karmaşıklığını analiz eder:

• Basit sorgular → Küçük, hızlı ve düşük maliyetli modellere yönlendirilir
• Karmaşık istekler → Derin analiz destekli güçlü reasoning modellerine gönderilir

Semantic Router’a ek olarak Semantic Caching de devreye girer. Tekrarlanan veya benzer istemler mevcut çıkarım sonuçlarını yeniden kullanabilir; bu da özellikle tekrarlayan soru kalıplarına sahip üretim ortamlarında işlem yükünü önemli ölçüde azaltır.

Ölçülebilir Sonuçlar: MMLU-Pro Benchmark

Qwen3 30B modeli ile yapılan MMLU-Pro benchmark testlerinde Semantic Router’ın etkisi somut biçimde ölçülmüştür:

• Karmaşık görevlerdeki doğruluk: +%10,2 artış
• Latency: -%47,1 azalma
• Token kullanımı: -%48,5 azalma

İlginizi Çekebilir: BGP Nedir? Rota Anonsları ve İnternetin Omurgası

Kueue ile GPU Kaynak Yönetimi ve İş Kuyruğu

Büyük ekiplerde GPU kaynakları üzerinde çalışırken kaçınılmaz bir çatışma ortaya çıkar: Kim ne zaman, ne kadar kaynak kullanacak? Bir ekibin uzun süren training işlemi tüm GPU’ları meşgul ettiğinde, diğer ekiplerin inference veya deney iş yükleri kuyrukta beklemek zorunda kalır.

Kubernetes-Native İş Kuyruğu

Kueue, Kubernetes-native bir iş kuyruğu sistemi olarak AI/ML iş yüklerini önceliklendirir ve kaynakları ekipler arasında adil biçimde dağıtır:

• İş yükü kuyruğa alındığında mevcut kaynak kotasını kontrol eder
• Yeterli kaynak varsa pod’ları ayağa kaldırır; yoksa sıraya koyar
• GPU’lar boşuna tahsis edilmez; gerçekten işlenecek iş olduğunda kullanıma girer
• Ekipler arası kaynak kotalarını ve önceliklerini merkezi olarak yönetir

KEDA ile Olay Güdümlü Otomatik Ölçeklendirme

OpenShift’in yerleşik otomatik ölçeklendirme mekanizmaları CPU ve bellek gibi standart metriklerle çalışır. Ancak AI iş yüklerinde izlenmesi gereken asıl metrikler bunlar değildir: modele gelen istek yoğunluğu ve yanıt süreleri çok daha belirleyicidir.

AI Metriklerine Dayalı Akıllı Ölçeklendirme

KEDA (Kubernetes Event-Driven Autoscaler), OpenShift’te Custom Metrics Autoscaler olarak gelir ve Prometheus aracılığıyla vLLM’nin sunduğu metrikleri okur:

• Aktif istek sayısı
• KV Cache doluluk oranı
• Kuyruk uzunluğu

KEDA’nın en kritik özelliği ise sıfıra ölçeklenebilmesidir. Belirli bir süre boyunca aktif istek ve kuyruk kalmadığında iş yükünü tamamen kapatır. Boşta bekleyen GPU, boşta bekleyen maliyete dönüşmez.

Sonuç: Entegre Mimarinin Faydaları

vLLM Inference Server, llm-d, Semantic Router, Kueue ve KEDA bir arada kullanıldığında birbirini tamamlayan bir optimizasyon zinciri oluşturur:

• vLLM: Bellek verimliliğini Paged Attention ile maksimize eder
• llm-d: Prefill/decode ayrımıyla GPU kullanımını uzmanlaştırır
• Semantic Router: Doğru isteği doğru modele yönlendirerek hem maliyet hem doğruluğu optimize eder
• Kueue: Ekipler arası GPU kaynaklarını adil ve verimli yönetir
• KEDA: Gerçek AI metriklerine dayalı ölçeklendirmeyle boşa harcamayı önemli ölçüde azaltır.

Bu mimarinin temelinde yatan fikir basittir: Her kaynak, ihtiyaç duyulduğunda ve ihtiyaç duyulduğu kadar çalışmalıdır. Red Hat AI ekosistemi içinde bu bileşenlerin entegrasyonu, kurumsal AI altyapılarını hem maliyet açısından sürdürülebilir hem de performans açısından rekabetçi kılmaktadır.

Sıkça Sorulan Sorular (SSS)

vLLM Inference Server hangi durumlarda tercih edilmelidir?

Yüksek eşzamanlı istek alan, farklı büyüklükte prompt ve yanıt üreten uygulamalarda vLLM Inference Server, geleneksel inference çözümlerine kıyasla belirgin biçimde daha iyi GPU kullanım oranı ve daha düşük gecikme süresi sunar.

OpenShift AI bu mimarinin hangi bileşenlerini hazır olarak sunar?

vLLM varsayılan inference runtime olarak gelir; KEDA ise Custom Metrics Autoscaler operatörü olarak OpenShift’e entegre edilmiştir. Kueue ayrıca kurulum gerektirse de OpenShift ekosistemiyle uyumlu çalışır. llm-d ve Semantic Router ise daha yeni bileşenler olup Red Hat AI ürün ailesi içinde olgunlaşmaya devam etmektedir.

llm-d her model için gerekli midir?

llm-d’nin prefill/decode ayrımı özellikle uzun context ve yüksek eşzamanlılık gerektiren iş yüklerinde anlam kazanır. Kısa prompt’larla çalışan veya düşük trafikli ortamlarda bu ek mimari karmaşıklık yerine tek pod üzerinde standart vLLM yeterli olabilir.

Hazırlayan: Başak Buğa – VAS Mühendisi – Sekom