Kubernetes'te Karpenter ile GPU Otomatik Ölçeklendirme: LLM Çıkarım İş Yükleri için Dinamik Node Yönetimi

GPU altyapısı, makine öğrenimi ve üretken yapay zeka iş yüklerini çalıştıran kuruluşlar için bulut harcamalarının en hızlı büyüyen kalemi haline geldi. Doğru GPU'yu seçmek önemlidir; ancak asıl kritik olan, pahalı GPU kapasitesinin iş yükleri ihtiyaç duyduğunda hazır olması, ihtiyaç kalmadığında ise serbest bırakılmasıdır.

Kubernetes, makine öğrenimi ve çıkarım iş yüklerini zamanlamak için esnek bir platform sağlar. Karpenter ise gerçek talebe göre GPU işlem kapasitesinin sağlanmasını ve kaldırılmasını otomatikleştirir. İkisi birlikte, GPU altyapısının sürekli çalışmak yerine iş yükü talebiyle birlikte ölçeklenen bir yapı kurmanıza olanak tanır.

Bu rehber; Karpenter'ın GPU iş yükleriyle nasıl çalıştığını, üretim ortamındaki bir LLM çıkarım yığınına nasıl oturduğunu ve verimli bir platform ile pahalı bir platform arasındaki farkı yaratan pratik yapılandırma ayrıntılarını ele almaktadır.

Karpenter Nedir ve Hangi Bulut Sağlayıcıları Destekler?

Karpenter, AWS tarafından geliştirilen ve Apache 2.0 lisansıyla yayımlanan açık kaynaklı bir Kubernetes node sağlama aracıdır. Mevcut node'larda yetersiz kaynak nedeniyle zamanlanamayan pod'ları izler ve gereksinimlerini karşılayan işlem kapasitesini otomatik olarak sağlar. İş yükleri tamamlandığında ve node'lar boşta kaldığında Karpenter, iş yüklerini birleştirir ve boş node'ları kaldırır.

Önceki nesil Cluster Autoscaler'dan farklı olarak Karpenter, önceden tanımlanmış node gruplarını ölçeklendirmek yerine her iş yükünün gerçek kaynak taleplerine göre örnek türlerini dinamik olarak seçer. Bu, GPU iş yükleri için özellikle değerlidir; zira küçük bir çıkarım servisi ile büyük bir model eğitim işi için ideal örnek türü birbirinden çok farklıdır.

Bulut sağlayıcı desteği: Karpenter, AWS EKS üzerinde olgun ve üretime hazır desteğe sahiptir. Google Cloud (GKE Autopilot) ve Azure (AKS), benzer ilkeleri izleyen kendi yönetilen node otomatik sağlama uygulamalarına sahiptir; ancak bu kılavuzdaki yapılandırma Karpenter'ın AWS uygulamasını kullanmaktadır. GCP veya Azure üzerinde çalışıyorsanız, eşdeğer işlevsellik için sağlayıcınızın node otomatik sağlama belgelerini incelemenizi öneririz.

Sürüm notu: Bu makale, birincil kaynak olarak Provisioner API'sinin yerini alan NodePool ve NodeClaim'i tanıtan Karpenter v1 (kararlı API) esas alınarak hazırlanmıştır. Kümeniz Karpenter v0.x çalıştırıyorsa kaynak adları ve bazı alan yapıları farklılık gösterecektir.

GPU Otomatik Ölçeklendirme Neden CPU'dan Farklı Bir Problemdir?

CPU tabanlı uygulamalar ölçeklendirmesi görece kolaydır: işlem ucuzdur, geniş çapta erişilebilirdir ve başlatma süreleri kısadır. GPU iş yükleri ise farklı kısıtlamalar getirir.

Tek bir NVIDIA H100 örneği, karşılaştırılabilir bir CPU node'undan saatte yaklaşık 10–15 kat daha pahalıya mal olur. Bu fiyatta boşta GPU kapasitesi yalnızca israf değil, platformdaki her yapay zeka servisinin birim ekonomisini doğrudan aşındıran sürekli bir bütçe sorunudur. %20 kullanım oranıyla günde 20 saat çalışan bir H100 örneği, daha iyi bir altyapı tasarımıyla ortadan kaldırılabilecek ciddi bir yinelenen giderdir.

ML iş yükleri aynı zamanda gerçekten değişken talep kalıplarına sahiptir. Bir üretim çıkarım servisi, günlük ortalamanın birkaç katına ulaşan trafik zirvelerini yaşayabilir. Toplu çıkarım, model değerlendirme ve ince ayar işleri yalnızca belirli zaman dilimlerinde GPU gerektirir. Geliştirme ve deneme ortamları aralıklı olarak kullanılır. Dinamik sağlama olmadan tüm bu iş yükleri, talep yaşanıp yaşanmadığından bağımsız olarak her zaman zirve talebine göre boyutlanmak zorunda kalan sabit bir GPU kapasitesi havuzuyla rekabet etmek durumunda kalır.

GPU İş Yükleri için Karpenter ile Cluster Autoscaler Karşılaştırması

Her iki araç da Kubernetes node'larını ölçeklendirir; ancak temelden farklı yaklaşımlar benimserler.

Cluster Autoscaler, önceden tanımlanmış node gruplarıyla (AWS'de Auto Scaling Groups) çalışır. Pod'lar zamanlanamadığında uygun node grubunu büyütür; node'lar yetersiz kullanıldığında küçültür. Örnek türü node grubu başına sabittir — GPU node grubunuz p3.2xlarge örnekleri kullanıyorsa, bu gruptaki her GPU node'u bu tür olacaktır.

Karpenter'ın node grubu kavramı yoktur. Zamanlanamayan pod'ları değerlendirir, kaynak gereksinimlerini ve zamanlama kısıtlamalarını okur ve sağlama zamanında GPU örnekleri de dahil olmak üzere geniş bir havuzdan en uygun örnek türünü seçer. Tek bir Karpenter NodePool'u, gerçek gereksinimlere göre farklı iş yükleri için farklı GPU örnek türleri sağlayabilir.

GPU altyapısı söz konusu olduğunda bu önemlidir: 7B çıkarım pod'u için en uygun örnek, 70B eğitim işi için en uygun örnekten çok farklıdır. Karpenter her ikisine de tek bir yapılandırmadan hizmet verebilirken, Cluster Autoscaler her biri için ayrı node grupları gerektirir.

Karpenter ile GPU Node Sağlama Nasıl Çalışır?

Bir GPU iş yükü mevcut node'larda zamanlanamadığında sağlama sırası şu şekilde işler:

1. GPU kaynak talebi (nvidia.com/gpu: 1) ve zamanlama kısıtlamalarıyla bir pod gönderilir.
2. Kubernetes zamanlayıcısı uygun bir node bulamaz ve pod'u zamanlanamaz olarak işaretler.
3. Karpenter zamanlanamayan pod'u algılar ve gereksinimlerini değerlendirir.
4. Karpenter uygun bir GPU örnek türü seçer ve yeni bir node sağlar.
5. NVIDIA cihaz eklentisi GPU'yu Kubernetes zamanlayıcısı tarafından kullanılabilir hale getirir.
6. Pod zamanlanır ve çalışmaya başlar.
7. Pod tamamlandığında ve node artık gerekli olmadığında Karpenter onu kaldırır.

LLM çıkarım iş yükleri için 4. adımdan 6. adıma kadar geçen süre, örnek türüne ve bölgeye bağlı olarak genellikle 3–6 dakika sürer. Bu sürenin önemli bir kısmı model yüklemesidir — yeni sağlanan bir node'a nesne depolama alanından 15–30 GB'lık bir model çekmek. Bu soğuk başlatma gecikmesi, çıkarım altyapısını sessiz dönemlerde ne kadar agresif biçimde ölçekleyebileceğinizi belirleyen temel pratik kısıtlamadır.

En etkili hafifletme yöntemi, DaemonSet veya node imajı hazırlama kullanarak model ağırlıklarını node düzeyinde önbelleğe almaktır; böylece model, talep üzerine çekilmek yerine pod başladığında hemen hazır olur.

GPU NodePool Yapılandırması

Karpenter NodePool'u, Karpenter'ın node sağlayabileceği kısıtlamaları tanımlar. GPU iş yükleri için minimal bir yapılandırma şu şekilde görünür:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-inference
spec:
  template:
    spec:
      requirements:
        - key: karpenter.k8s.aws/instance-gpu-count
          operator: Gt
          values: ["0"]
        - key: karpenter.k8s.aws/instance-gpu-name
          operator: In
          values: ["a100", "h100", "l40s"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
      nodeClassRef:
        apiVersion: karpenter.k8s.aws/v1
        kind: EC2NodeClass
        name: gpu-nodeclass
  limits:
    nvidia.com/gpu: 32
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 5m

limits alanı, bu havuz tarafından sağlanan tüm node'lardaki toplam GPU kapasitesini sınırlar — kontrolsüz ölçeklendirmeye karşı önemli bir güvencedir. disruption bloğu, Karpenter'ın ne zaman node kaldırmasına veya birleştirmesine izin verildiğini kontrol eder; WhenEmptyOrUnderutilized, hem boş node kaldırma hem de iş yüklerini daha az node üzerinde birleştirme olanağı sağlar.

Karpenter sağlamayı tetikleyen bir GPU pod spec'i şu şekilde görünür:

resources:
  requests:
    nvidia.com/gpu: 1
    memory: "24Gi"
  limits:
    nvidia.com/gpu: 1
    memory: "24Gi"

Açık bir GPU kaynak talebi olmadan Karpenter, pod'un GPU node'u gerektirdiğine dair bir sinyal alamaz ve pod'u mevcut herhangi bir node türüne zamanlamaya çalışır.

Pod Otomatik Ölçeklendirme ile GPU Node Otomatik Ölçeklendirme Karşılaştırması

GPU altyapısı tasarımında en yaygın karışıklık kaynaklarından biri, iki farklı ölçeklendirme problemini birbirine karıştırmaktır: kaç tane çıkarım pod'una ihtiyaç var ve bunları çalıştırmak için ne kadar GPU kapasitesi mevcut?

Bunlar, farklı araçlarla ele alınan ayrı katmanlardır.

• Pod otomatik ölçeklendirme — istek hacmine, kuyruk derinliğine veya gecikmeye bağlı olarak kaç çıkarım servisi çoğaltmasının çalışması gerektiğini belirler. LLM çıkarım iş yükleri için KEDA (Kubernetes Event-Driven Autoscaler / Kubernetes Olay Güdümlü Otomatik Ölçekleyici) en uygun araçtır. KEDA, GPU yükü için zayıf bir vekil olan CPU veya bellek yerine vllm:num_requests_waiting gibi özel Prometheus metriklerine göre ölçeklenebilir. Standart HPA bu esneklikten yoksundur.
• Node otomatik ölçeklendirme — bu pod'ları çalıştırmak için kümede ne kadar GPU işlem kapasitesi bulunduğunu belirler. Bu, Karpenter'ın yönettiği alandır.

Pratikte iki katman birlikte çalışır: KEDA kuyruk derinliği arttığında çıkarım çoğaltmalarını ölçeklendirir, mevcut node'lar doluysa yeni pod'lar zamanlanamaz hale gelir ve Karpenter onları barındırmak için ek GPU node'ları sağlar. Trafik düştüğünde KEDA çoğaltmaları azaltır, node'lar yetersiz kullanılır hale gelir ve Karpenter bunları birleştirir ve kaldırır.

Karpenter Birleştirme ve Ölçek Küçültme

Talep arttığında GPU kapasitesi sağlamak denklemin yalnızca yarısıdır. Diğer yarısı — artık ihtiyaç kalmadığında kapasiteyi kaldırmak — pek çok ekibin parayı masada bıraktığı yerdir.

Karpenter'ın birleştirme mekanizması, çalışan iş yüklerinin daha az node üzerinde yeniden zamanlanıp zamanlanamayacağını, böylece diğerlerinin kaldırılmasını mümkün kılıp kılamayacağını değerlendirir. GPU iş yükleri için birleştirme davranışı üç temel ayar tarafından yönetilir:

• consolidationPolicy: WhenEmpty — node'ları yalnızca tüm pod'lar tamamlandığında kaldırır. Muhafazakâr; durum bilgisi olan veya gecikmeye duyarlı çıkarım servisleri için uygundur.
• consolidationPolicy: WhenEmptyOrUnderutilized — pod'ları tahliye edip yeniden zamanlayarak yetersiz kullanılan node'ları da birleştirir. Daha agresif; toplu iş yükleri ve geliştirme ortamları için uygundur.
• consolidateAfter — bir node birleştirme için uygun hale geldikten sonra Karpenter'ın harekete geçmeden önce beklediği süre. Çıkarım iş yüklerinde bunu çok düşük ayarlamak kısa trafik durgunlukları sırasında gereksiz pod yeniden başlatmalarına neden olabilir.

Üretim çıkarım servisleri için, geniş bir consolidateAfter penceresiyle (10–15 dakika) WhenEmpty genellikle daha güvenli bir başlangıç noktasıdır. Toplu çıkarım işleri ve deneme ortamları için daha dar bir pencereyle WhenEmptyOrUnderutilized, servis kalitesini etkilemeden boşta kalan maliyetleri azaltır.

Somut bir örnek: Günde sekiz kez çalışan, her seferinde 30 dakika dört GPU gerektiren bir toplu çıkarım iş yükü düşünün. Otomatik ölçeklendirme olmadan bu dört GPU sürekli çalışır — günde yaklaşık 96 GPU-saat. Karpenter ile kapasite yalnızca her iş penceresi için sağlandığında, gerçek tüketim günde 16 GPU-saate düşer; bu iş yükü için yaklaşık %83'lük bir azalmadır.

Ek Maliyet Tasarrufu için Spot GPU Örnekleri

Kesintilere tolerans gösterebilen iş yükleri için Karpenter'ın esnek örnek seçimi, Spot GPU kapasitesini dahil etmeyi kolaylaştırır. Spot örnekler, isteğe bağlı fiyatlandırmaya kıyasla %60–90 indirim sunar; ancak bulut sağlayıcısı kapasiteyi geri aldığında kesinti riski taşır.

Spot GPU'lar şunlar için uygundur:

• Kontrol noktası desteğiyle toplu çıkarım işleri
• Model değerlendirme ve kıyaslama
• Kontrol noktasından devam ettirilebilen ince ayar çalışmaları
• Geliştirme ve deneme ortamları
• Kritik olmayan veya çevrimdışı çıkarım ardışık düzenleri

Bir kesintinin istek başarısızlıklarına ve model yeniden yükleme süresi dahil pod yeniden başlatma süresinin kullanıcı deneyimini doğrudan etkileyeceği gecikmeye duyarlı üretim çıkarımı için daha az uygundur.

Çoğu kuruluş için en pratik yaklaşım, karma kapasite stratejisidir: üretim çıkarım servisleri için isteğe bağlı GPU node'ları, toplu iş yükleri ve geliştirme için Spot node'ları. Karpenter, farklı capacity-type kısıtlamalarına sahip ayrı NodePool tanımları aracılığıyla bunu destekler.

vLLM ve Karpenter: Katmanlar Birlikte Nasıl Çalışır?

LLM çıkarımı çalıştıran kuruluşlar için vLLM ve Karpenter, yığının farklı düzeylerinde çalışır ve farklı sorunları çözer — bu ayrımı anlamak yanlış yapılandırmayı ve hizasız optimizasyon çabasını önler.

vLLM GPU'nun içinde çalışır. Sürekli toplu işleme ve PagedAttention kullanarak her GPU'nun saniyede ürettiği token sayısını maksimize eder ve çalışan donanım üzerindeki üretilen token başına maliyeti azaltır.

Karpenter, altyapı düzeyinde çalışır. Kaç GPU node'unun var olduğunu belirler, pod'lar ihtiyaç duyduğunda bunları sağlar ve ihtiyaç kalmadığında kaldırır.

İstekten donanıma kadar tam yığın şu şekilde görünür:

• Gelen istekler → vLLM çıkarım motoru (sürekli toplu işleme, PagedAttention)
• Çoğaltma sayısı → KEDA (kuyruk derinliğine göre pod'ları ölçeklendirir)
• Node kapasitesi → Karpenter (GPU node'larını sağlar ve kaldırır)
• Fiziksel işlem → Yapay zeka ve makine öğrenimi için GPU sunucuları

Her katman bağımsız olarak ayarlanabilir. Kötü ölçeklendirilmiş bir altyapı üzerindeki iyi optimize edilmiş bir vLLM yapılandırması, boşta GPU'lar için fazla ödeme yapmaya devam eder. Eşit biçimde, mükemmel Karpenter yapılandırması, GPU belleğini verimsiz kullanan bir çıkarım motorunu telafi edemez. Ölçekte maliyet azaltımı her ikisini de gerektirir.

Vurgulanmaya değer pratik bir etkileşim: vLLM büyük modeli başlangıçta GPU belleğine yüklediğinden, yeni sağlanan bir Karpenter node'unda soğuk başlatan bir çıkarım pod'u tipik durumsuz bir uygulamadan çok daha uzun sürer. 30B'lik bir model için toplam soğuk başlatma süresi — node sağlama ve model yükleme dahil — 5–8 dakikaya ulaşabilir. KEDA ölçeklendirme eşiklerinizi ve Karpenter birleştirme pencerelerinizi bu gecikmeyi hesaba katarak tasarlayın.

Her İş Yükü Türü için Doğru GPU'yu Seçmek

Otomatik ölçeklendirme, verimsiz bir GPU seçimini kendiliğinden maliyet etkin hale getirmez. Doğru örnek türünün hâlâ iş yükünün gerçek gereksinimlerine uygun olması gerekir.

Kullanışlı bir başlangıç çerçevesi:

• Üretim çıkarımı, 7B–13B modeller: NVIDIA L40S veya A100 40GB. 16K'ya kadar bağlam pencereleriyle orta düzey eş zamanlılık için maliyet etkin.
• Üretim çıkarımı, 30B–70B modeller: A100 80GB veya H100 80GB. Üretim eş zamanlılığında daha büyük KV önbellek alanı için gereklidir.
• Toplu çıkarım ve değerlendirme: Küçük modeller için T4 veya L4; gecikme yerine verim için maliyet optimize edilmiş.
• Eğitim ve ince ayar: Büyük modeller için NVLink'li H100; orta ölçekli çalışmalar için A100.
• Geliştirme ve deneme: Modeli barındırabilen en küçük örnek; mevcut durumlarda Spot kapasitesi.

En hızlı GPU nadiren en ekonomik seçimdir. Bir GPU yapılandırmasına karar vermeden önce eş zamanlılık, bağlam uzunluğu ve toplu işleme özellikleri dahil gerçek iş yüklerini kıyaslayın. Farklı yapılandırmaları uzun vadeli taahhüt olmadan test etmek isteyen ekipler için Cloud4U'nun yapay zeka ve makine öğrenimi için GPU sunucuları saatlik faturalandırmayla sunulmaktadır.

Üretimdeki GPU Otomatik Ölçeklendirmeyi İzleme

GPU kullanımı tek başına, bir otomatik ölçeklendirme platformunun doğru çalışıp çalışmadığı için yeterli bir sinyal değildir. Yüksek kullanım, kapasitenin verimli kullanıldığını gösterebilir — ya da kümenin doymuş olduğunu ve isteklerin kuyrukta beklediğini.

GPU otomatik ölçeklendirme için eksiksiz bir izleme kurulumu üç katmanı kapsamalıdır.

Çıkarım motoru metrikleri (Prometheus aracılığıyla vLLM'nin /metrics uç noktasından):

• vllm:gpu_cache_usage_perc — KV önbellek kullanımı; %95'in üzerindeki sürekli değerler bellek baskısına işaret eder
• vllm:num_requests_waiting — çıkarım kuyruk derinliği; KEDA ölçeklendirme için birincil sinyal
• vllm:e2e_request_latency_seconds — P50, P95, P99'da uçtan uca gecikme
• vllm:time_to_first_token_seconds — etkileşimli uygulamalar için kritik

GPU donanım metrikleri (DCGM Exporter veya nvidia-smi aracılığıyla):

• GPU kullanım yüzdesi
• GPU bellek kullanımı
• GPU sıcaklığı ve güç tüketimi

Karpenter altyapı metrikleri (Karpenter'ın Prometheus uç noktası aracılığıyla):

• karpenter_nodes_total — Karpenter tarafından yönetilen toplam node sayısı
• karpenter_provisioner_scheduling_duration_seconds — zamanlanamayan pod'dan node sağlama kararına geçen süre
• karpenter_nodes_termination_duration_seconds — birleştirme kararından sonra bir node'un kaldırılma süresi

Tüm bunları birbirine bağlayan maliyet metriği, üretilen milyon token başına maliyet'tir — toplam GPU altyapısı harcaması bölü üretilen toplam token sayısı. Bu, otomatik ölçeklendirme, çıkarım optimizasyonu ve GPU seçiminin birlikte etkin çalışıp çalışmadığını yansıtan rakamdır. GPU iş yükleri için maliyet ölçümü ve FinOps uygulamaları hakkında daha geniş bir tartışma için yapay zeka/ML iş yükleri için GPU maliyet optimizasyonu stratejileri rehberimize bakabilirsiniz.

GPU Otomatik Ölçeklendirme Dağıtımlarında Yaygın Hatalar

Çıkarım pod ölçeklendirmesi için KEDA yerine HPA kullanmak. HPA, CPU ve bellek üzerinde ölçeklendirir; bunlar çıkarım yükünü doğru biçimde yansıtmaz. Bir vLLM pod'u, GPU'su doymuş ve istek kuyruğu büyüyor olsa bile %10 CPU kullanımında görünebilir. vllm:num_requests_waiting üzerinde özel bir Prometheus metriği kullanan KEDA, gerçekten önemli olan sinyale göre ölçeklendirir.

Birleştirme pencerelerinde soğuk başlatma gecikmesini görmezden gelmek. Yeniden başlatması 5 dakika süren bir çıkarım servisi için consolidateAfter: 1m ayarı, sürekli salınıma neden olur: Karpenter kısa bir trafik durgunluğu sırasında node'ları kaldırır, trafik geri geldiğinde yeni pod'lar zamanlanamaz hale gelir ve sağlama baştan başlar. Birleştirme pencerelerini soğuk başlatma süresinden daha uzun olacak şekilde boyutlandırın.

Pod spec'lerinde GPU kaynak taleplerinin olmaması. Açık nvidia.com/gpu kaynak talepleri olmadan Karpenter, pod'un GPU node'u gerektirdiğini belirleyemez. GPU iş yükleri CPU örneklerine zamanlanabilir.

NodePool'da GPU sınırlarının olmaması. NodePool'da bir limits üst sınırı olmadan, yanlış yapılandırılmış bir iş yükü veya trafik zirvesi sınırsız GPU sağlamayı tetikleyebilir. Her zaman üretim NodePool'larında GPU sınırı belirleyin.

Tüm iş yüklerine aynı birleştirme politikasını uygulamak. Toplu işler agresif biçimde birleştirilebilir. Üretim çıkarım servisleri birleştirilemez. Her iş yükü türü için farklı kesinti ayarlarına sahip ayrı NodePool'lar kullanın.

Daha Verimli Bir GPU Platformu İnşa Etmek

Karpenter ve Kubernetes, dinamik GPU sağlama için altyapı katmanını sağlar; ancak ölçekte maliyet verimliliği çok katmanlı bir sonuçtur. GPU harcamalarını en çok azaltan kuruluşlar, tüm katmanları aynı anda optimize edenlerdir: doğru GPU örnek türünü seçmek, verimli bir çıkarım motoru çalıştırmak, pod'ları anlamlı metriklere göre ölçeklendirmek ve altyapıyı gerçek talebe göre dinamik olarak sağlamak.

Bu optimizasyonların hiçbiri tek başına yeterli değildir. Sürekli aşırı sağlanan bir kümede verimli bir çıkarım motoru hâlâ fazla öder. Mükemmel otomatik ölçeklendirme, iş yükünün gerektirdiğinden 3 kat daha büyük bir GPU örnek türünü telafi edemez.

Pratik ilerleme yolu iteratiftir: önce ölçüm yapın, en büyük maliyet etkisine sahip katmanı optimize edin, ardından bir sonrakine geçin. Çoğu ekip için en büyük kazanımlar dinamik sağlama (boşta GPU kapasitesini ortadan kaldırmak) ve çıkarım motoru optimizasyonundan (GPU-saat başına daha fazla token) gelir; bu sırayla.