On-Premises GPU Kümelerinde Telemetri Tabanlı Kapasite Tahmini

Sezgisel GPU tedarikinin problemi

Çoğu on-premises yapay zeka ekibi, GPU tedarikini 2005'te sunucu satın alma yöntemiyle aynı şekilde yapıyor: birisi tepe talebi tahmin ediyor, güvenlik payı ekliyor ve satın alma siparişi veriyor. Altı ay sonra küme ya yüzde 30 boşta oturuyor ya da kimsenin öngörmediği iş yükleri altında eziliyor. Kurumsal GPU donanımı için teslimat süreleri — NVIDIA H100 veya B200 düğümleri için genellikle 12 ila 20 hafta — kötü bir tahmini düzeltmeyi pahalı ve yavaş kılıyor.

Telemetri tabanlı kapasite tahmini, varsayımları veriyle değiştirir. Çıkarım ve eğitim yığınının her katmanını enstrümante ederek, kümenizin gerçekte nasıl tüketildiğine dair yaşayan bir model oluşturursunuz. Bu model, talebi haftalar veya aylar öncesinden tahmin etmenizi, tedariki gerçek büyüme eğrilerine göre planlamanızı ve donanım bütçenizi CFO'nuzun denetleyebileceği rakamlarla savunmanızı sağlar.

Ne ölçülmeli: GPU altyapısı için telemetri yığını

Etkili tahmin, her biri ham GPU kullanımının tek başına sağlayamadığı sinyaller katan dört farklı katmanda telemetri gerektirir:

• GPU donanım metrikleri: SM (akış çoklu işlemci) kullanımı, bellek bant genişliği doygunluğu, GPU bellek doluluk oranı, termal kısıtlama olayları ve NVLink veya PCIe trafiği. NVIDIA DCGM (Data Center GPU Manager) gibi araçlar bunları saniye başı granülerlikle Prometheus uyumlu metrikler olarak dışa aktarır.

• Servis katmanı metrikleri: saniyedeki istek sayısı, kuyruk derinliği, ilk token'a kadar geçen süre, tokenlar arası gecikme, sürekli batcher tarafından elde edilen batch boyutları ve KV önbellek isabet oranları. Bunlar çıkarım motorunuzdan gelir — vLLM, TGI veya TensorRT-LLM hepsi bunları açığa çıkarır.

• İş yükü düzeyi metrikleri: model başına ve ekip başına işlenen tokenlar, istek türü dağılımı (etkileşimli, batch, ajan), prompt ve tamamlama uzunluğu dağılımları ile hata veya zaman aşımı oranları. Bunlar genellikle yapay zeka ağ geçidinizde veya yönlendirme katmanınızda bulunur.

• Zamanlayıcı ve orkestrasyon metrikleri: bekleyen iş kuyruğu uzunlukları, zamanlama bekleme süreleri, öncelik kesme sayıları ve Kubernetes cihaz eklentilerinden veya SLURM muhasebe kayıtlarından GPU zaman paylaşım oranları.

Temel kavrayış şudur: GPU kullanımı tek başına gecikmiş bir göstergedir. Yüzde 70 GPU kullanımında çalışan bir küme, kuyruk derinlikleri artıyorsa ve kuyruk sonu gecikmeleri bozuluyorsa zaten kapasitesinde olabilir. Tersine, düz kuyruk derinlikleri ve sağlıklı gecikme süreleriyle yüzde 90 kullanım, başlık rakamının önerdiğinden daha fazla kapasite payınız olduğu anlamına gelir.

Geçmiş kalıplardan talep modeli oluşturma

Ham telemetri, kalıplara ayrıştırılana kadar gürültüdür. Üç teknik, GPU iş yükleri için tutarlı biçimde kullanışlı tahminler üretir:

Mevsimsel ayrıştırma: çoğu kurumsal yapay zeka iş yükünün güçlü günlük ve haftalık döngüleri vardır. Belge işleme mesai saatlerinde tepe yapar; eğitim işleri etkileşimli talep düştüğünde gece veya hafta sonları çalışır. Trend, mevsimsel ve artık bileşenleri ayırmak için klasik ayrıştırma (STL veya benzeri) kullanın. Trend çizgisi büyüme sinyalinizdir; mevsimsel bileşen tepe-dip dalgalanmanızı boyutlandırır.

İş yükü segmentasyonu: toplu GPU talebini tahmin etmek zordur çünkü temelden farklı iş yüklerini karıştırır. Model, ekip, istek türü ve öncelik katmanına göre segmente edin. NLP ekibinin ince ayar iş yükü ayda yüzde 15 büyüyor olabilirken, bilgisayarlı görü çıkarım yükü sabit kalabilir. Her segmenti bağımsız tahmin edip toplamak, toplamı tahmin etmekten çok daha iyi sonuçlar üretir.

Doygunluk eğrisi tespiti: GPU kümeleri, kullanım kapasiteye yaklaştıkça doğrusal olmayan bozulma sergiler. Yanıt gecikmeleri bir devrilme noktasına kadar — genellikle yüzde 75 ila 85 sürekli kullanım civarında — sabit kalır, ardından hızla bozulur. Talep modeliniz, öngörülen kullanım bu eşiği aştığında uyarı vermelidir, yüzde 100'ü aştığında değil. Yüzde 100'e ulaştığınızda, kullanıcılarınız haftalardır mağdur olmuş demektir.

Tahminden tedariğe: talep eğrilerini donanım planlarına çevirme

Bir talep tahmini, ancak eyleme dönüştürülebilir tedarik kararlarına dönüştüğünde kullanışlıdır. Bu dönüşüm üç girdi gerektirir: talep eğrisinin kendisi, mevcut donanım seçenekleri ve her seçenek için teslimat süresi.

Gerçek iş yüklerinize uyan kapasite birimleri tanımlayarak başlayın. Çıkarım için kullanışlı bir birim "p95 gecikme 200ms altında 14B parametreli eşzamanlı sohbet oturumu" olabilir. Eğitim için "8xH100 düğümlerinde BF16'da haftalık GPU-saat" olabilir. Bu birimler, ham FLOPS karşılaştırmalarında kaybolmadan talep tahminlerini donanım miktarlarına çevirmenizi sağlar.

Ardından, teslimat süresine göre ayarlanmış tedarik zaman çizelgesi oluşturun. Tahmininiz doygunluk eşiğini 16 hafta içinde aşacağınızı gösteriyorsa ve donanım teslimat süresi 14 hafta ise, karar marjınız iki haftadır — 16 hafta değil. Birçok ekip, donanımı üç ay önce sipariş etmeleri gerektiğini keşfeder. Tahmin, alternatifleri keşfetmek için bunu yeterince erken görünür kılar: iş yüklerini modeller arasında yeniden dengeleme, düşük öncelikli batch işleri spot bulut kapasitesine yükleme veya istek başına GPU maliyetini azaltmak için model sıkıştırma projelerini hızlandırma.

Son olarak, talep modelinize karşı senaryo analizi çalıştırın. Yeni ürün özelliği çıkarım trafiğini iki katına çıkarırsa ne olur? Araştırma ekibi eğitim kapasitesinin yüzde 40'ını üç hafta boyunca tüketen büyük bir ince ayar çalışması başlatırsa? Bu senaryoları parametrize etmek, sermaye taahhüt etmeden önce tedarik planınızı stres testinden geçirmenizi sağlar.

Tahmin hattı için araçlar ve mimari

Bir tahmin hattı oluşturmak için özel bir ML platformuna ihtiyacınız yok. Pratik bir mimari, çoğu altyapı ekibinin zaten işlettiği bileşenleri kullanır:

• Toplama: NVIDIA DCGM Exporter ve uygulama düzeyinde Prometheus dışa aktarıcıları, metrikleri bir zaman serisi veritabanına aktarır. Ham verileri en az 90 gün, örneklenmiş verileri mevsimsel kalıpları yakalamak için 12 ila 18 ay saklayın.

• Depolama: Uzun süreli saklama için Thanos veya Cortex ile Prometheus veya tek ikili dağıtımı tercih eden ekipler için VictoriaMetrics. Kritik gereklilik, kardinalite sınırlarına takılmadan aylarca veriyi sorgulama yeteneğidir.

• Tahmin: Ayrıştırılmış talep segmentlerine uygulanan Prophet, NeuralProphet veya basit Holt-Winters modelleri. Bunları zamanlanmış işler olarak çalıştırın — çoğu tedarik döngüsü için haftalık yeterlidir — ve tahmin doğruluğunu zamanla ölçebilmek için tahmin çıktılarını gerçek değerlerle birlikte saklayın.

• Görselleştirme ve uyarı: Tahmin bantlarını gerçek kullanımın üzerine bindiren Grafana panoları, gerçek değerlerin üst tahmin bandını sürekli aştığında uyarılar. Mevcut büyüme hızında doygunluğa kalan haftaları gösteren bir "tedarik ufku" paneli, altyapı liderliği için en değerli görünümdür.

Tüm hat mütevazı bir VM üzerinde çalışabilir. Yatırım hesaplama gücünde değil, iş yükü segmentleri tanımlama, uygun kapasite birimleri seçme ve tahmin doğruluğunu aylık olarak gözden geçirme disiplinindedir.

Sık karşılaşılan tuzaklar ve kaçınma yöntemleri

GPU tahmin yetenekleri geliştiren kuruluşlarda birkaç başarısızlık modu tekrar tekrar ortaya çıkar:

KV önbelleğini görmezden gelmek: KV önbellek büyümesinin yönlendirdiği GPU bellek kullanımı, model ağırlığı yüklemesinin yönlendirdiği kullanımdan farklı davranır. Telemetriniz ikisi arasında ayrım yapmıyorsa, bellek tahminleriniz güvenilir olmayacaktır. Modern servis motorlarının çoğu KV önbellek metriklerini ayrıca açığa çıkarır — bunları kullanın.

Tepeler yerine ortalamaları tahmin etmek: tedarik, ortalama talebi değil tepe talebi karşılamalıdır. Her zaman talep dağılımınızın p95 veya p99'unu tahmin edin ve mevsimsel ayrıştırmanızın haftalık ve aylık tepe noktalarını doğru yakaladığını doğrulayın.

Tüm GPU'ları birbirinin yerine geçebilir olarak değerlendirmek: "16 GPU daha lazım" diyen bir tahmin, iş yükleriniz belirli bellek boyutları, bağlantı topolojileri veya donanım nesilleri gerektiriyorsa işe yaramazdır. Bu kısıtlamaları kodlaması gereken kapasite birimleriniz düzeyinde tahmin yapın.

Tahmin doğruluğunu asla doğrulamamak: gerçek değerlerle asla karşılaştırmadığınız bir tahmin, ekstra adımlarla yapılmış bir varsayımdır. Segment başına ortalama mutlak yüzde hatası (MAPE) aylık olarak izleyin. Bir segmentin MAPE'si sürekli yüzde 20'yi aşıyorsa, model o iş yükü hakkında önemli bir şeyi yakalayamıyordur — tedarik için güvenmeden önce araştırın.

Telemetri tabanlı tahmin, tek seferlik bir proje değildir. Bir pratiktir: enstrümante edin, ölçün, tahmin edin, tedarik edin, doğrulayın ve iyileştirin. Bu pratiği benimseyen ekipler, GPU bütçeleri hakkında tartışmayı bırakır ve altyapı yatırımı konusunda kanıta dayalı konuşmalar yapmaya başlar.

Öne çıkan görsel: Nadin Nandin tarafından Unsplash'ta paylaşılmıştır.