Paylaşımlı On-Prem AI Platformlarında GPU Chargeback ve Kota Tasarımı

Paylaşımlı GPU Platformları, Kapasite Bedava Göründüğünde Tıkanır

On-premises AI genellikle mantıklı bir teknik hedefle başlar: GPU kapasitesini merkezileştirip birden fazla ekibin aynı platformu kullanmasını sağlamak. Sonra platform popüler olur, kuyruklar uzar ve her ekip kendi işinin acil olduğunu iddia etmeye başlar. Kota ve chargeback modeli yoksa genellikle sesi yüksek çıkan ekip kazanır, ama gerçekten kritik operasyonel işler beklemek zorunda kalır. Bu sadece scheduler problemi değildir. Bu bir ekonomi problemidir. Kısıtlı GPU zamanı ücretsiz göründüğünde talep, yönetişim kapasitesinden daha hızlı büyür.

Bulut platformları bunun bir kısmını görünür faturalama ile çözer. On-prem ortamların da benzer bir disipline ihtiyacı vardır. Bu, ilk günden tam maliyet yansıtması yapmak anlamına gelmez. Birçok kurum için showback daha doğru ilk adımdır: kim hangi GPU sınıfını ne kadar kullandı, hangi kuyruk önceliğiyle çalıştı ve ne kadar depolama kapladı, bunların görünür hale getirilmesi. Kullanım verisi açık olduğunda kota kararları keyfi görünmez ve platform tartışmaları daha sağlıklı zemine oturur.

Fiyatı Değil, Önce Hizmet Sınıflarını Tanımlayın

Kota modellerinin büyük bölümü, maliyet formülünden başladığı için başarısız olur. Önce platformun gerçekte nasıl kullanıldığını yansıtan hizmet sınıflarını tanımlamak gerekir. Pratik bir yapı üç katmanlıdır. İnteraktif sınıf; notebook, deneme ve kısa süreli geliştirme işlerini destekler. Batch sınıfı; fine-tuning, embedding üretimi, offline evaluation ve gece çalışan işleri kapsar. Kritik sınıf ise production inference veya önceden mutabık kalınmış önemli iş pencereleri için ayrılır. Her sınıfın runtime limiti, queue priority'si, preemption davranışı ve kullanabileceği donanım farklı olmalıdır.

Hizmet sınıfları tanımlandığında kotalar da daha anlamlı hale gelir. Bir ekip, aylık bazda interaktif A10 veya L40 düğümleri için temel bir kota, paylaşımlı H100 pencereleri için ayrı bir batch kotası ve iş-kritik bir servisi varsa üretim inference için küçük ama garanti bir kapasite dilimi alabilir. Bu, herkese her GPU tipini açmak ve sorunu scheduler'ın kendi kendine çözmesini beklemekten çok daha sağlıklıdır. Platform politikayı namespace, queue class ve admission control seviyesinde açıkça ifade etmelidir.

Ekiplerin reserved capacity ile burst capacity arasındaki farkı da net biçimde görmesi gerekir. Reserved capacity, güvenle plan yapabilecekleri kapasitedir. Burst capacity ise uygunluk olduğunda kullanılabilecek fırsatçı kapasitedir ve geri alınabilir. Bu iki kavramın karıştırılması sonsuz çatışma üretir çünkü kullanıcılar garanti edilmemiş kapasiteye göre plan yapmaya başlar.

Chargeback Formülünü Ekiplerin Anlayacağı Tüketim Birimleri Üzerinden Kurun

En kullanışlı chargeback modelleri matematiksel olarak mükemmel olanlar değil, mühendislik yöneticilerinin davranış sonucunu öngörebildiği modellerdir. Güçlü bir başlangıç formülü; donanım sınıfına göre GPU-saat, kalıcı artifact depolama ve reserved kapasite veya özel destek pencereleri için ek bedel içerir. Bazı kurumlar vector database alanı, hızlı ağ kaynakları veya adanmış inference endpoint maliyetlerini de dahil eder; ancak ancak bu kalemler maddi olarak anlamlıysa ve tüketen ekip tarafından kontrol edilebiliyorsa eklenmelidir.

Az kalemli bir iç rate card yayınlamak faydalıdır: GPU sınıfına göre saatlik maliyet, reserved slice aylık ücreti, kalıcı hızlı depolama bedeli ve garantili production support maliyeti. Finans ekipleri ilk etapta bunları gerçek faturalamaya çevirmese bile, bu tablo mimari kararlar için ortak bir dil yaratır. O anda sürekli açık duran büyük model endpoint'inin sadece teknik bir tercih olmadığı, küçük model, batch pencere veya model routing gibi alternatiflerle rekabet eden bir bütçe kararı olduğu görünür hale gelir.

Teşviklerin platform sağlığıyla uyumlu olması gerekir. Kısa ve düzgün sonlandırılan deneyleri cezalandırmayın. Buna karşın terk edilmiş uzun batch işleri, gereksiz büyük rezervasyonlar ve hiç ölçeklenmeyen boş production endpoint'leri için net yaptırımlar koyun. İyi chargeback modeli sonradan suç dağıtmaz; baştan verimli davranışı teşvik eder.

Kotaları Spreadsheet ile Değil, Scheduler Üzerinden Uygulayın

Yönetişim ancak control plane içine kodlandığında gerçeğe dönüşür. Kubernetes tabanlı platformlarda bu çoğu zaman resource quota, priority class ve Kueue ya da Volcano gibi kuyruk uzantılarıyla mümkündür. HPC odaklı ortamlarda Slurm, kısıtlı accelerator kaynaklarını bölmek ve fair-share politikaları uygulamak için hala çok güçlü bir seçenektir. Dağıtık eğitim tarafında Ray veya Kubeflow kullanan ekipler bile, alttaki scheduler'ın aynı kota kurallarına uymasını sağlamalıdır; aksi halde istisnalar zamanla üst katman araçlar üzerinden yayılır.

Donanım bölümlendirmesi de faydalıdır. NVIDIA MIG, tam GPU gerektirmeyen interaktif veya inference işleri için anlamlıdır; tam cihaz tahsisi ise gerçekten buna ihtiyaç duyan işler için saklanmalıdır. OPA Gatekeeper veya Kyverno gibi policy araçları, kullanıcıların yasaklı GPU sınıfları istemesini, aşırı büyük persistent volume açmasını veya sınırsız runtime talep etmesini engelleyebilir. Boş kaynakların geri alınması da aynı derecede önemlidir. Bir notebook ya da endpoint belirlenen eşik boyunca atıl kaldığında platform bunu otomatik olarak kapatabilmeli veya daha düşük öncelikli havuza taşıyabilmelidir.

Operasyonel hedef nettir: kullanıcılar platform politikasını ay sonu toplantısında değil, işi sisteme gönderdikleri anda hissetmelidir. Adalet, kaynak tükendikten sonra yapılan tartışmayla değil, submission anındaki kurallarla sağlanır.

Kotaları Çeyreklik Gözden Geçirin ve Gerçek İhtiyaç İçin İstisna Yolu Bırakın

Hiçbir kota modeli olduğu gibi kalmaz. Yeni kullanım alanları ortaya çıkar, ürün lansmanları dönemsel tepe noktalar yaratır ve bir ekip bir güncelleme veya validasyon kampanyası için geçici olarak ek kapasite ister. Bu nedenle kota yönetişimi yılda bir kez yazılan sert bir kural değil, hafif ama düzenli bir çeyreklik inceleme mekanizması olmalı. Gerçek kullanım, hizmet sınıfına göre kuyruk baskısı, boş duran rezervasyonlar ve sürekli taban ihtiyacı aşan işler birlikte incelenmelidir. Bu veriler size sorunun politika mı, tahmin mi, yoksa kapasite planlama mı olduğunu gösterir.

İstisna yönetimi resmi ama hızlı olmalıdır. Production incident, denetim takvimi veya saha yayını gibi durumlar geçici önceliği haklı kılabilir; ancak kriterler yazılı ve zaman kutulu olmak zorundadır. Aksi halde her talep doğası gereği acil hale gelir. Genelde şu kadar basit bir istisna kaydı yeterlidir: iş gerekçesi, istenen süre, etkilenen GPU sınıfı, beklenen geri dönüş tarihi ve onaylayan sorumlu. Böylece kısa vadeli esneklik korunur ama kalıcı adaletsizlik oluşmaz.

On-premises AI'da chargeback ve kota tasarımı, mühendisliğin üstüne sonradan eklenmiş bürokrasi değildir. Bu, platform mimarisinin kendisidir. GPU ekonomisi görünür ve uygulanabilir olduğunda ekipler daha bilinçli model seçimleri yapar, işlerini daha akıllı yönlendirir ve pahalı donanımı yalnızca gerçekten gerekli olduğu noktalara ayırır.

Featured image by Elimende Inagella on Unsplash.