Kurum İçi Yapay Zeka Sistemleri İçin Kademeli Bozulma Desenleri

Kademeli Bozulma Neden Kurum İçi Sistemlerde Daha Kritiktir

Bulut tabanlı yapay zeka servisleri genellikle bölgeler ve kullanılabilirlik alanları arasındaki yedeklilik ile arızaları yönetir. Kurum içi dağıtımlar nadiren bu lükse sahiptir. Bir GPU düğümü çöktüğünde veya bellek baskısı arttığında, saniyeler içinde yedek kapasite oluşturamazsınız. Soru, kurum içi yapay zeka sisteminizin bozulmuş koşullarla karşılaşıp karşılaşmayacağı değil, karşılaştığında nasıl davranacağıdır.

Kademeli bozulma, koşullar kötüleştikçe giderek azalan ancak yine de kullanışlı hizmet sunan sistemler tasarlama disiplinidir. Tam performans ile tamamen çökme arasında ikili bir seçim yerine, iyi tasarlanmış sistemler kritik iş yüklerini çalışır durumda tutarken gerekli olmayan yükü azaltan ara hizmet seviyeleri sunar.

Kademeli Hizmet Seviyeleri: Bozulma Merdiveninin Tanımlanması

İlk adım, mevcut kaynaklarla eşleşen açık hizmet katmanları tanımlamaktır. Pratik bir yaklaşım üç ila dört katman kullanır:

Katman 1 (Tam Kapasite): Tüm modeller maksimum kalitede hizmet verir. Toplu işleme, gerçek zamanlı çıkarım ve arka plan görevleri eş zamanlı çalışır. Bu normal çalışma durumunuzdur.

Katman 2 (Azaltılmış Kalite): Büyük modellerden daha küçük, kuantize edilmiş varyantlara geçiş yapılır. 70B parametreli bir model, 7B varyantına geri döner. Gecikme hedefleri gevşer ancak yanıtlar çoğu kullanım senaryosu için doğru kalır. GPU döngülerini serbest bırakmak için arka plan toplu işleri duraklatılır.

Katman 3 (Yalnızca Temel): Yalnızca iş açısından kritik çıkarım hatları aktif kalır. Temel olmayan uç noktalar önbelleğe alınmış yanıtlar veya önceden tanımlanmış varsayılanlar döndürür. GPU kapasitesi tamamen tükenirse, hafif modeller için CPU tabanlı çıkarıma geçilir.

Katman 4 (Acil Durum): Sistem yalnızca statik, önceden hesaplanmış yanıtlar sunar. Canlı çıkarım çalışmaz. Kapasite geri kazanıldığında tespit etmek için sağlık kontrolleri ve izleme aktif kalır.

Her katmanın açıkça belgelenmiş giriş koşulları, çıkış koşulları ve geçişler sırasında sistemin aldığı belirli eylemler olmalıdır. Katman geçişlerini manuel müdahale yerine kaynak izleme yoluyla otomatikleştirin.

Model Geri Dönüş Zincirleri

Model geri dönüş zinciri, aynı uç noktaya hizmet veren, önceden yapılandırılmış ve giderek hafifleyen modellerden oluşan bir dizidir. Birincil model kullanılamaz hale geldiğinde veya çok yavaşladığında, sistem istekleri otomatik olarak zincirdeki bir sonraki modele yönlendirir.

Örneğin, bir belge sınıflandırma hattı şöyle tanımlanabilir: Mistral 7B (birincil, GPU) -> DistilBERT (yedek, CPU) -> kural tabanlı sınıflandırıcı (acil durum). Her adım doğruluğu esneklik lehine takas eder. Temel gereklilik, zincirdeki tüm modellerin uyumlu giriş ve çıkış şemalarını paylaşmasıdır; böylece aşağı akış tüketicileri hangi modelin isteğine hizmet ettiğini bilmek zorunda kalmaz.

Geri dönüş zincirlerini bireysel servisler içinde değil, çıkarım ağ geçidi seviyesinde uygulayın. Bu, mantığı merkezileştirir ve gözlemlenebilir kılar. NVIDIA Triton Inference Server gibi araçlar, bu zincirleri bildirimsel olarak ifade edebilen model toplulukları ve koşullu yürütmeyi destekler.

Geri dönüş zincirlerinizi gerçekçi koşullar altında test edin. Karşılaştırmalarda iyi puan alan bir model, aşağı akış işlemeyi bozan ince farklılıklar üretebilir. Uçtan uca doğruluğu doğrulamak için her yedek model aktifken entegrasyon testleri çalıştırın.

İstek Önceliklendirme ve Yük Atma

Tüm çıkarım istekleri eşit iş değeri taşımaz. Ödeme işleme hattında çalışan bir dolandırıcılık tespit modeli, dahili bilgi tabanı makaleleri öneren bir tavsiye modelinden daha önemlidir. Bozulmuş koşullarda sistem bu önceliği uygulamalıdır.

API ağ geçidinde istek sınıflandırması uygulayın. Her isteği çağıran servise ve uç noktaya göre bir öncelik seviyesiyle etiketleyin. Çıkarım zamanlayıcınızda öncelik kuyrukları kullanın; böylece kapasite kısıtlı olduğunda yüksek öncelikli istekler önce karşılanır.

Yük atma, yüksek öncelikli iş yüklerini korumak için düşük öncelikli isteklerin kasıtlı olarak reddedilmesidir. İstemcilerin zarif bir şekilde geri çekilebilmesi için uygun bir yanıt kodu (Retry-After başlığıyla 503) döndürün. Bu, tüm istekleri kabul edip herkese yavaş yanıtlar vermeye tercih edilir; aksi durumda gecikme sorunları tüm sisteme yayılır.

Mevcut kapasite düştükçe sıkılaşan uyarlanabilir hız sınırları yapılandırın. Katman 2'de çalışan bir sistem, düşük öncelikli arayanlar için hız sınırını %50 azaltabilirken, Katman 3 onları tamamen engeller.

Geçişler Sırasında Durum Yönetimi

Katman geçişleri, devam eden isteklerin kesintiye uğrayabileceği tehlikeli bir dönem yaratır. Çıkarım ortasında kaldırılan büyük bir modele gönderilen istek başarısız olacaktır. Geçiş mantığınızı bunu ele alacak şekilde tasarlayın:

Geçişten önce boşaltma: Aşağı geçiş yaparken, kaldırılacak model için yeni istekleri kabul etmeyi durdurun, devam eden isteklerin tamamlanmasını bekleyin (bir zaman aşımıyla), ardından modeli kaldırın ve yedeği yükleyin. Bu kısa bir kuyruk süresi gerektirir ancak istek başarısızlıklarını önler.

Geçiş sırasında çift hizmet: Bellek izin veriyorsa, birincili kaldırmadan önce yedek modeli yükleyin. Birincil kuyruğunu bitirirken yeni istekleri yedeğe yönlendirin. Bu hizmet boşluğunu önler ancak geçici olarak iki model çalıştırmayı gerektirir.

Uzun süren görevler için kontrol noktaları: İnce ayar veya büyük veri kümesi çıkarımı gibi toplu işleme işleri düzenli olarak ilerleme kontrol noktaları oluşturmalıdır. Sistem bozulduğunda, kısmi çalışmayı kaybetmek yerine işi son kontrol noktasında duraklatın. Kapasite geri döndüğünde devam edin.

İzleme ve Otomatik Kurtarma

Kademeli bozulma, yalnızca sistem aynı zamanda kademeli olarak kurtarılabiliyorsa faydalıdır. Her katman geçişi için kurtarma kriterlerini tanımlayın: hizmet katmanını yükseltmeden önce minimum bir süre boyunca sürdürülmesi gereken belirli GPU kullanım eşikleri, bellek kullanılabilirliği, hata oranları ve gecikme yüzdelikleri.

Histerezis uygulayarak salınımı önleyin. Bozulma eşiği, kurtarma eşiğinden daha hassas olmalıdır. %90 GPU kullanımında bozulma yaşıyorsanız, kullanım en az beş dakika boyunca %70'in altına düşene kadar kurtarma yapmayın. Bu, sınır koşullarında katmanlar arasında hızlı salınımı önler.

Mevcut katmanı, aktif modelleri, atılan istek oranını ve kurtarma ilerlemesini gösteren bir bozulma panosu oluşturun. Olaylar sırasında operatörlerin sistemin ne yaptığını ve nedenini bir bakışta görmesi gerekir. Olay sonrası analizde bozulma olaylarını gözden geçirebilmek için her katman geçişini tetikleyen metriklerle birlikte günlüğe kaydedin.

Bozulma yollarını planlı tatbikatlarla düzenli olarak test edin. Bakım pencerelerinde kaynakları yapay olarak kısıtlayın ve sistemin katmanlar arasında sorunsuz geçiş yaptığını ve doğru şekilde kurtarıldığını doğrulayın. Üretimde hiç çalışmamış bozulma mantığı, en çok ihtiyaç duyduğunuzda başarısız olacak bozulma mantığıdır.

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