Paylaşımlı Şirket İçi GPU Çıkarım Kümeleri için QoS ve Adillik

Paylaşımlı GPU'lar için açık kalite-hizmeti tasarımının gereği

Bir kuruluş şirket içi çıkarımı merkezileştirdiğinde kolay kısım sunucuları kurmaktır. Zor kısım, bir iş yükündeki gecikme sıçramalarının diğerini aç bıraktığı veya toplu bir analiz işinin belleği o kadar çok tükettiği için etkileşimli sohbet oturumlarının çöktüğü durumlarda ekipler arasındaki güveni sürdürmektir. Genel Kubernetes CPU kısıtlamasının aksine GPU paylaşımı keskin arıza modları ortaya çıkarır: bellek dışı öldürmeler, çıkarım sunucusunun içinde başa sıra kilitlenmesi ve yalnızca demo gününe kadar iyi görünen opak kuyruk derinlikleri.

GPU çıkarımı için hizmet kalitesi; zamanlama politikası, sunucu yapılandırması ve kod olarak ifade edilen kurumsal anlaşmaların ürünüdür. Bu üçlü olmadan “paylaşımlı küme” hızla “paylaşımlı suçlama”ya döner.

Bölümleme stratejileri: sert izolasyondan ağırlıklı paylaşıma

En güçlü izolasyon, kritik hizmet sınıfı başına ayrılmış donanım. Bu maliyet hedefleriyle çelişir; bu yüzden platformlar genelde fiziksel havuzları mantıksal ayrım ile birleştirir. Desteklenen hızlandırıcılarda NVIDIA Multi-Instance GPU (MIG), kartı sınırlı bellek ve hesapla daha küçük profillere böler. MIG seçeneği yoksa aynı ana bilgisayarda tek kuyruk yerine katman başına ayrı çıkarım sunucusu örnekleri hâlâ çapraz etkileşimi azaltır.

Daha zayıf ama yaygın kalıplar arasında yük dengeleyicinin arkasında ayrı Kubernetes öncelik sınıfları ve kaynak kotalarıyla birden fazla dağıtım yer alır. Bu kontroller yerleşimde yardımcı olur; fakat uzun süreli bir çıkarım işçisi içinde adil GPU süresini otomatik olarak sağlamaz. Yine de uygulama katmanında etkileşimli, standart toplu ve fırsatçı istek sınıfları ve her sınıfın kaç eşzamanlı toplu akışa izin verebileceğine dair açık sınırlar gerekir.

Kuyruklama, geri basınç ve kullanıcıya görünen davranış

Adillik yalnızca ortalama iş hacmi değil; kapasiteyi aştığında ne olduğu. Davranışı önceden tanımlayın: etkileşimli trafik devam eden toplu işi keser mi? İstemciler üstel geri denemeyle mi yoksa son tarihli sınırlı bir kuyrukta mı bekler? Çok saniyelik sessiz tıkanıklıklardan iyidir yapılandırılmış HTTP 429 yanıtları ve gövde.

Sürekli toplu işlemeyi destekleyen çıkarım sunucuları maksimum toplu boyutu, toplu oluşturmak için bekleme süresi ve diziler beklenmedik büyüdüğünde çıkarma kuralları için ayar kollarına ihtiyaç duyar. Bu kollar hizmet sınıfına göre farklı olmalıdır. Katman başına varsayılanları ve kimin değiştirebileceğini listeleyen dahili bir oyun kitabı, bir ekibe yardım eden bir ekibi şaşırtan gece yarısı düzenlemelerini önler.

Mühendislik ve finansın paylaşabileceği gözlemlenebilirlik

GPU kullanım yüzdesi tek başına yanıltıcıdır: GPU meşgul olsa bile toplular tek bir kiracıya ağırlık veriyorsa kuyruk gecikmesi felaket olabilir. İsim alanı veya API anahtarına bağlı kiracı veya uygulama başına ilk token öncesi kuyruk süresi, toplu oluşma süresi, önlem sayıları ve bellek dışı olayları gibi sinyalleri izleyin. Bu metrikleri mevcut Prometheus tarzı yığınınıza aktarın ve kuruluşunuzun GPU kotalarını zaten çalıştırdığı geri ödeme veya gösterim panolarına bağlayın.

Teknik metrikleri, büyüme eğrilerini tedarik süreleriyle karşılaştıran kapasite incelemeleri ile eşleştirin. QoS politikaları çatışmayı yumuşatarak zaman kazandırır; fakat silikon üretmez. Sürekli çatışma göründüğünde doğru sonuç çoğu zaman sonsuz ayar yerine bütçe görüşmesidir.

Adillik bozulduğunda: olay müdahalesi

Kuyruk gecikmesi sıçramaları veya bellek dışı olayları tek bir ad alanı veya API anahtarı etrafında kümelendiğinde durumu yalnızca uygulama hatası değil, kapasite ve kiracılık olayı olarak ele alın. Runbook'lar geçici olarak hangi kiracı sınıfının kimin tarafından kısıtlanabileceğini, mümkün olduğunda uzun ömürlü oturumları düşürmeden bir düğümü nasıl boşaltacağınızı ve iç tüketicilere hizmet sınıfı düşüşünün nasıl iletileceğini kaydetmelidir. Olay sonrası incelemeler, arıza modunun zaten topladığınız metriklerde görünür olup olmadığını sormalıdır; değilse, başka bir gayri resmi kural katmanı yerine bir sinyal ekleyin.

Çıkarım metriklerini yukarı akım bağımlılıklarıyla—erişim gecikmesi, kimlik doğrulama ve özellik depoları—ilişkilendirin; böylece kökü başka yerde olan sorunlar için GPU kuyrukları suçlanmaz. Amaç tekrarlanabilir iyileşmedir: aynı nöbetçi mühendis sabahın üçünde, mesai saatinde olduğu gibi aynı belgelenmiş kolları uygular.

Yönetişim: SLO'lar, sözleşmeler ve eskalasyon

Katman başına hizmet düzeyi hedeflerini belgeleyin: örneğin etkileşimli iş yükleri mesai saatlerinde sınırlı gecikme yüzdesi hedeflerken toplu işler gece pencerelerini kabul eder. Bu SLO'ları tüketici kayıt olan ürün sahiplerine görünür kılın. Çakışma çıktığında—aynı lansmanda iki “etkileşimli” ekip—eskalasyon yolları geçici olarak donanım ayırmaya yetkili bir platform yönetişim forumuna yönlendirilmelidir.

Otomasyon yardımcı olur. Hız sınırları, ad alanı kotaları ve giriş öncelikleri için Git ile yönetilen politikalar değişiklikleri gözden geçirilebilir tutar. Denetim izi bırakmayan geçici kubectl düzenlemelerinden kaçının.

Özet

Paylaşımlı şirket içi GPU kümeleri teknik olarak değil sosyal olarak önce bozulur. Riskinize uygun izolasyon mekanizmalarına, başarısızlığın görünür olduğu kuyruk politikalarına, kiracı düzeyinde deneyimi ortaya çıkaran metriklere ve SLO'ları finansman kararlarına bağlayan yönetişime erken yatırım yapın. Sonuç, ekiplerin anekdot yerine veriyle tartıştığı ve kapasite tam abone olsa bile çıkarımın öngörülebilir hissettirdiği bir platformdur.

Öne çıkan görsel: Avi Waxman, Unsplash.