Yazı

Yerinde Yapay Zeka Altyapisi icin Felaket Kurtarma Planlamasi

On-Premises AI · AI Architecture · Best Practices · MLOps · Intermediate

Yerinde yapay zeka model artefaktlarini, egitim verilerini ve cikarim hizmetlerini felaket senaryolarina karsi koruyan pratik bir cerceve.

Sunucu raflari ve ag ekipmanlariyla veri merkezi altyapisi

Yapay Zeka Altyapisinin Neden Kendine Ozgu Bir DR Stratejisine Ihtiyaci Var

Geleneksel felaket kurtarma planlari veritabanlari, uygulama sunuculari ve dosya depolama etrafinda insa edilmistir. Yerinde yapay zeka altyapisi, bu planlarin korumak icin tasarlanmadigi varliklar ortaya cikarir: haftalarca GPU suresi harcanan egitimli model agirliklari, ozel aciklamalar iceren ince ayar veri setleri, aylarlik performans ayarlamasini kodlayan cikarim boru hatti yapilandirmalari ve belirli is alanlarina bagli LoRA adapterleri.

Bir web uygulamasinin veritabanini kaybetmek aci vericidir ancak kurtarilabilir — yedekten geri yukler ve islem gunluklerini yeniden oynatirsiniz. Yedegi olmayan tamamen egitilmis bir modeli kaybetmek, yuzlerce GPU-saat ve binlerce dolar hesaplama tuketmis olabilecek bir egitim isinin yeniden calistirilmasi anlamina gelir. Bu modelin arkasindaki kurate edilmis, temizlenmis ve aciklanmis egitim veri setini kaybetmek, bir projeyi aylarca geri atabilir.

Zorluk, yapay zeka artefaktlarinin boyutu ve karmasikligi tarafindan daha da arttirilir. Tek bir buyuk dil modeli kontrol noktasi 100 GB'yi asabilir. Gomulularla birlikte bir egitim veri seti terabaytlara yayilabilir. Veritabanlari ve belge depolama icin tasarlanmis geleneksel yedekleme cozumleri, bu hacimleri kabul edilebilir kurtarma suresi pencerelerinde genellikle isleyemez. Ozel bir yapay zeka felaket kurtarma stratejisi bu gercekleri hesaba katar.

Yapay Zeka Varliklarinin Kurtarma Onceligi ile Siniflandirilmasi

Her yapay zeka varligi ayni kurtarma aciliyetini tasimaz. Pratik bir DR plani, varliklari yeniden uretilmelerinin ne kadar zor olduguna ve is operasyonlari icin ne kadar kritik olduklarina gore katmanlara siniflandirarak baslar.

Katman 1 — Yeri doldurulamaz veya yeniden uretimi son derece pahali. Bu, uretim model agirliklarini (ozellikle ozel veriler uzerinde egitilenler), ince ayarli adapterleri ve manuel aciklamali kurate edilmis egitim veri setlerini icerir. Bu varliklar en agresif yedekleme ve cogaltma stratejilerini gerektirir cunku kayiplari haftalarca veya aylarca yeniden calisma anlamina gelir.

Katman 2 — Yeniden uretilebilir ancak zaman alici. Cikarim boru hatti yapilandirmalari, prompt sablonlari, degerlendirme olcutleri ve model sunum yapilandirmalari buraya duser. Belgelerden ve kurumsal bilgi birikiminden yeniden olusturulabilirler, ancak bunu bir kesinti sirasinda baski altinda yapmak hataya acik ve yavasdir.

Katman 3 — Koddan tamamen yeniden uretilebilir. Konteyner imajlari, dagitim bildirimleri, izleme panolari ve CI/CD boru hatti tanimlari surum kontrolunde yer alir ve kaynaktan yeniden olusturulabilir. Standart GitOps pratikleri bu katmani iyi kapsar.

Cogu kurulusum Katman 3 yedeklerine asiri yatirim yapar (ki bunlar zaten Git tarafindan ele alinir) ve gercek riskin yattigi Katman 1'e yetersiz yatirim yapar. Yapay zeka varliklarinizi bu katmanlara gore denetleyin ve DR butcenizi buna gore tahsis edin.

Buyuk Model Artefaktlari icin Yedekleme Stratejileri

Yapay zeka model agirliklarini ve egitim verilerini olcekte yedeklemek, geleneksel dosya yedeklemesinden farkli yaklasimlar gerektirir. Ilgili hacimler, surum olusturma ve butunluk dogrulama ihtiyaci ile birlestiginde, amaca yonelik cozumler gerektirir.

Surum olusturmali nesne depolama temeldir. MinIO veya Ceph'i S3 uyumlu API'lerle yerinde artefakt deposu olarak dagitir. Kova surum olusturmayi etkinlestirin, boylece her model kontrol noktasi ve veri seti surumu korunur. Yapilandirma yasam dongusu politikalarini kullanarak eski surumleri tamamen silmek yerine daha ucuz depolama katmanlarina (SSD'ler yerine HDD'ler) tasiyabilirsiniz.

Artimsal ve tekillestirilmis yedeklemeler depolama yukunu onemli olcude azaltir. restic veya BorgBackup gibi araclar blok duzeyinde tekillestirme yapar; bu, egitim calismalarinda agirliklarinin onemli bir kismini paylasan model kontrol noktalari icin etkilidir.

Sagi toplamlari ve butunluk dogrulamasi tartismasizdir. Yedekleme veya aktarim sirasinda bozulan model agirliklari, bariz hatalar yerine sessizce yanlis cikarim sonuclari uretecektir. Yedekleme zamaninda SHA-256 sagi toplamlari hesaplayin ve geri yuklemede dogrulayin. Bunu otomatiklestirin — yuzlerce model surumunuz oldugunda manuel dogrulama olceklenmez.

Cografi cografik cogaltma, birden fazla tesise sahip kuruluslar icin en guclu koruma saglar. Katman 1 varliklarini asenkron cogaltma kullanarak ikincil bir yerinde konuma cogaltin. Tek bir tesisiniz varsa, yalnizca DR amacli bir geri donus olarak ozel bir bulut kovasina sifrelenmis cogaltmayi degerlendirebilirsiniz.

Egitim Verilerinin ve Boru Hatlarinin Korunmasi

Egitim verileri genellikle bir yapay zeka sistemindeki en degerli ve yeri en zor doldurulan varliktir. Ham veriler yeniden elde edilebilir, ancak bunlari egitim icin hazir bir veri setine donusturen temizleme, donusturme, aciklama ve dogrulama calismasi onemli insan emegiyi temsil eder.

Veri setlerinizi modellerinizle birlikte surumleyin. DVC (Data Version Control) veya LakeFS gibi araclar, nesne deposunda depolanan buyuk veri setleri icin Git benzeri surum olusturma saglar. Her egitim calismasi belirli, degismez bir veri seti surumune atifta bulunmalidir.

Aciklama meta verilerini ham verilerden ayri olarak yedekleyin. Label Studio gibi etiketleme platformlari kullaniyorsaniz, aciklamalar ham verilerden cok daha kucuk bir veritabaninda depolanir. Bu veritabanini sik sik yedekleyin — gunluk hatta saatlik — cunku verileri yeniden aciklamak, yeniden elde etmekten cok daha pahalidir.

Veri boru hatlarinizi kod olarak belgeleyin ve surumleyin. ETL betikleri, veri temizleme kurallari, ozellik muhendisligi mantigi ve on isleme adimlari, uygulama koduyla ayni titizlikle surum kontrolunde yasamalidir.

Kurtarma Prosedurlerun ve RTO Hedefleri

Test edilmis bir kurtarma proseduru olmayan yedek sadece bir umuttur. Her varlik katmani icin acik Kurtarma Suresi Hedefleri (RTO) ve Kurtarma Noktasi Hedefleri (RPO) tanimlayin, ardindan bunlari duzenli olarak dogrulayin.

Cikarim hizmetleri icin RTO, saatlerle degil dakikalarla olculmelidir. Uretim modellerinin sicak bekleme kopyalarini ikincil donaninda tutun. Kubernetes dugum yakinlik kurallarini kullanarak cikarim pod'larini hata alanlarina (farkli raflar, farkli guc beslemeleri) dagitin.

Model artefaktlari icin saatlik bir RTO genellikle kabul edilebilir. Daha onemli olan RPO'dur — en son yedeklemeniz ne kadar guncel? Aktif olarak egitilen modeller icin, 24 saatlik bir RPO en fazla bir gunluk egitim ilerlemesini kaybedeceginiz anlamina gelir.

Ucel ayda bir kurtarma tatbikatlari yapin. Rastgele bir Katman 1 varligi secin, kaybini simule edin ve kurtarma prosedurunu bastan sona uygulayin. Gercek kurtarma suresini RTO hedefinizle olcun. Bu tatbikatlar surekli bosluklar ortaya cikarir: suresi dolmus yedekleme kimlik bilgileri, dolan depolama birimleri, degisen ag yollari.

Kurtarma calisma kitabini otomatiklestirin. Geri yukleme adimlarini gerceklestiren betikler yazin — model artefaktini yedek depolamadan cekme, sagi toplamini dogrulama, cikarim kumesine dagitma, duman testi calistirma ve trafigi gecirme. Bir kesinti sirasinda stres altindaki insan operatoru adimlari atlayacak veya hatalar yapacaktir.

DR'yi Yapay Zeka Platformunuza Birinci Gunden Itibaren Entegre Etmek

Felaket kurtarmayi mevcut bir yapay zeka platformuna sonradan eklemek, basindan itibaren insa etmekten onemli olcude daha zordur. Yerinde yapay zeka altyapinizi tasarliyor veya yeniden yapilandiriyorsaniz, DR degerlendirmelerini her mimari karara gomin.

Artefakt depolamayi en basindan standartlastirin. Her takim modelleri farkli yerlerde depoluyorsa — bazilari yerel SSD'lerde, bazilari NFS paylasimlarinda, bazilari ozel veritabanlarinda — yedekleme sisteminiz hepsini kapsayamaz. Tutarli adlandirma kurallari ve meta verilerle tek bir artefakt deposu (MinIO, Ceph veya benzeri) zorunlu kilin, ardindan bu tek sistemi kapsamli bir sekilde yedekleyin.

Model meta verilerini birinci sinif vatandas olarak ele alin. Meta verileri olmayan bir model dosyasi — hangi veri seti uzerinde egitildigi, hangi hiperparametrelerin kullanildigi, degerlendirme metriklerinin ne oldugu — onemli olcude daha az kullanislidir. Meta verileri MLflow gibi bir model kayit defterinde depolayin ve bu kayit defterinin veritabanini Katman 1 yedekleme planiniza dahil edin.

Zarifce bozulma icin tasarlayin. Birincil cikarim kumeniz basarisiz olursa, uygulamaniz CPU'da calisan daha kucuk bir modele veya yaygin sorgular icin onbellege alinmis yanitlara geri donebilir mi? Zarifce bozulma, tam bir hizmet kesintisi olmadan kurtarma sirasinda size zaman kazandirir. Bu geri donus yollarini onceden tanimlayin ve test edin.

Yapay zeka altyapisi icin felaket kurtarma bir kontrol listesi uygulamasi degildir — devam eden bir pratiktir. Temel ilke degismez: kaybetmeyi goze alamayacaginizi belirleyin, agresif bir sekilde koruyun ve korumamuzun calistigini duzenli olarak test ederek kanitlayin.

Featured image by Growtika on Unsplash.