Yerinde Yapay Zeka Altyapısı için Felaket Kurtarma ve İş Sürekliliği

Yapay Zeka Altyapısının Neden Kendine Özgü Bir DR Stratejisine İhtiyacı Var

Geleneksel felaket kurtarma planları veritabanları, uygulama sunucuları ve dosya depolama etrafında inşa edilmiştir. Yerinde yapay zeka altyapısı, bu planların korumak için tasarlanmadığı varlıklar ortaya çıkarır: haftalarca GPU süresi harcanan eğitimli model ağırlıkları, özel açıklamalar içeren ince ayar veri setleri, aylarca süren performans optimizasyonunu kodlayan çıkarım boru hattı yapılandırmaları ve belirli iş alanlarına bağlı LoRA adapterleri.

Bir web uygulamasının veritabanını kaybetmek acı vericidir ancak kurtarılabilirdir — yedekten geri yükler ve işlem günlüklerini yeniden oynatırsınız. Yedeği olmayan tamamen eğitilmiş bir modeli kaybetmek, yüzlerce GPU-saat ve binlerce dolar hesaplama tüketmiş olabilecek bir eğitim işinin yeniden çalıştırılması anlamına gelir. Bu modelin arkasındaki kürate edilmiş, temizlenmiş ve açıklanmış eğitim veri setini kaybetmek, bir projeyi aylarca geri atabilir.

Zorluk, yapay zeka artefaktlarının boyutu ve karmaşıklığı tarafından daha da artırılır. Tek bir büyük dil modeli kontrol noktası 100 GB'yi aşabilir. Gömülülerle birlikte bir eğitim veri seti terabaytlara yayılabilir. Veritabanları ve belge depolama için tasarlanmış geleneksel yedekleme çözümleri, bu hacimleri kabul edilebilir kurtarma süresi pencerelerinde genellikle işleyemez. Özel bir yapay zeka felaket kurtarma stratejisi bu gerçekleri hesaba katar.

Yapay Zeka Varlıklarının Kurtarma Önceliği ile Sınıflandırılması

Her yapay zeka varlığı aynı kurtarma aciliyetini taşımaz. Pratik bir DR planı, varlıkları yeniden üretilmelerinin ne kadar zor olduğuna ve iş operasyonları için ne kadar kritik olduklarına göre katmanlara sınıflandırarak başlar.

Katman 1 — Yeri doldurulamaz veya yeniden üretimi son derece pahalı. Bu, üretim model ağırlıklarını (özellikle özel veriler üzerinde eğitilenler), ince ayarlı adapterleri ve manuel açıklamalı kürate edilmiş eğitim veri setlerini içerir. Bu varlıklar en agresif yedekleme ve çoğaltma stratejilerini gerektirir çünkü kayıpları haftalarca veya aylarca yeniden çalışma anlamına gelir.

Katman 2 — Yeniden üretilebilir ancak zaman alıcı. Çıkarım boru hattı yapılandırmaları, istem şablonları, değerlendirme ölçütleri ve model sunum yapılandırmaları buraya düşer. Belgelerden ve kurumsal bilgi birikiminden yeniden oluşturulabilirler, ancak bunu bir kesinti sırasında baskı altında yapmak hataya açık ve yavaştır.

Katman 3 — Koddan tamamen yeniden üretilebilir. Konteyner imajları, dağıtım bildirimleri, izleme panoları ve CI/CD boru hattı tanımları sürüm kontrolünde yer alır ve kaynaktan yeniden oluşturulabilir. Standart GitOps pratikleri bu katmanı iyi kapsar.

Çoğu kuruluş Katman 3 yedeklerine aşırı yatırım yapar (ki bunlar zaten Git tarafından ele alınır) ve gerçek riskin yattığı Katman 1'e yetersiz yatırım yapar. Yapay zeka varlıklarınızı bu katmanlara göre denetleyin ve DR bütçenizi buna göre tahsis edin.

Büyük Model Artefaktları için Yedekleme Stratejileri

Yapay zeka model ağırlıklarını ve eğitim verilerini ölçekte yedeklemek, geleneksel dosya yedeklemesinden farklı yaklaşımlar gerektirir. İlgili hacimler, sürüm oluşturma ve bütünlük doğrulama ihtiyacı ile birleştiğinde, amaca yönelik çözümler gerektirir.

Sürüm oluşturmalı nesne depolama temeldir. MinIO veya Ceph'i S3 uyumlu API'lerle yerinde artefakt deposu olarak dağıtın. Kova sürüm oluşturmayı etkinleştirin, böylece her model kontrol noktası ve veri seti sürümü korunur. Yapılandırma yaşam döngüsü politikalarını kullanarak eski sürümleri tamamen silmek yerine daha ucuz depolama katmanlarına (SSD'ler yerine HDD'ler) taşıyabilirsiniz.

Artımlı ve tekilleştirilmiş yedeklemeler depolama yükünü önemli ölçüde azaltır. restic veya BorgBackup gibi araçlar blok düzeyinde tekilleştirme yapar; bu, eğitim çalışmalarında ağırlıklarının önemli bir kısmını paylaşan model kontrol noktaları için etkilidir.

Karma değerleri ve bütünlük doğrulaması tartışmasızdır. Yedekleme veya aktarım sırasında bozulan model ağırlıkları, bariz hatalar yerine sessizce yanlış çıkarım sonuçları üretecektir. Yedekleme zamanında SHA-256 karma değerleri hesaplayın ve geri yüklemede doğrulayın. Bunu otomatikleştirin — yüzlerce model sürümünüz olduğunda manuel doğrulama ölçeklenmez.

Coğrafi çoğaltma, birden fazla tesise sahip kuruluşlar için en güçlü korumayı sağlar. Katman 1 varlıklarını asenkron çoğaltma kullanarak ikincil bir yerinde konuma çoğaltın. Tek bir tesisiniz varsa, yalnızca DR amaçlı bir geri dönüş olarak özel bir bulut kovasına şifrelenmiş çoğaltmayı değerlendirebilirsiniz.

Eğitim Verilerinin ve Boru Hatlarının Korunması

Eğitim verileri genellikle bir yapay zeka sistemindeki en değerli ve yeri en zor doldurulan varlıktır. Ham veriler yeniden elde edilebilir, ancak bunları eğitim için hazır bir veri setine dönüştüren temizleme, dönüştürme, açıklama ve doğrulama çalışması önemli insan emeğini temsil eder.

Veri setlerinizi modellerinizle birlikte sürümleyin. DVC (Data Version Control) veya LakeFS gibi araçlar, nesne deposunda depolanan büyük veri setleri için Git benzeri sürüm oluşturma sağlar. Her eğitim çalışması belirli, değişmez bir veri seti sürümüne atıfta bulunmalıdır.

Açıklama meta verilerini ham verilerden ayrı olarak yedekleyin. Label Studio gibi etiketleme platformları kullanıyorsanız, açıklamalar ham verilerden çok daha küçük bir veritabanında depolanır. Bu veritabanını sık sık yedekleyin — günlük hatta saatlik — çünkü verileri yeniden açıklamak, yeniden elde etmekten çok daha pahalıdır.

Veri boru hatlarınızı kod olarak belgeleyin ve sürümleyin. ETL betikleri, veri temizleme kuralları, özellik mühendisliği mantığı ve ön işleme adımları, uygulama koduyla aynı titizlikle sürüm kontrolünde yaşamalıdır.

Kurtarma Prosedürleri ve RTO Hedefleri

Test edilmiş bir kurtarma prosedürü olmayan yedek sadece bir umuttur. Her varlık katmanı için açık Kurtarma Süresi Hedefleri (RTO) ve Kurtarma Noktası Hedefleri (RPO) tanımlayın, ardından bunları düzenli olarak doğrulayın.

Çıkarım hizmetleri için RTO, saatlerle değil dakikalarla ölçülmelidir. Üretim modellerinin sıcak bekleme kopyalarını ikincil donanımda tutun. Kubernetes düğüm yakınlık kurallarını kullanarak çıkarım pod'larını hata alanlarına (farklı raflar, farklı güç beslemeleri) dağıtın.

Model artefaktları için saatlik bir RTO genellikle kabul edilebilirdir. Daha önemli olan RPO'dur — en son yedeklemeniz ne kadar güncel? Aktif olarak eğitilen modeller için 24 saatlik bir RPO, en fazla bir günlük eğitim ilerlemesini kaybedeceğiniz anlamına gelir.

Üç ayda bir kurtarma tatbikatları yapın. Rastgele bir Katman 1 varlığı seçin, kaybını simüle edin ve kurtarma prosedürünü baştan sona uygulayın. Gerçek kurtarma süresini RTO hedefinizle ölçün. Bu tatbikatlar sürekli boşluklar ortaya çıkarır: süresi dolmuş yedekleme kimlik bilgileri, dolan depolama birimleri, değişen ağ yolları.

Kurtarma çalışma kitabını otomatikleştirin. Geri yükleme adımlarını gerçekleştiren betikler yazın — model artefaktını yedek depolamadan çekme, karma değerini doğrulama, çıkarım kümesine dağıtma, duman testi çalıştırma ve trafiği geçirme. Bir kesinti sırasında stres altındaki insan operatörü adımları atlayacak veya hatalar yapacaktır.

DR'yi Yapay Zeka Platformunuza İlk Günden İtibaren Entegre Etmek

Felaket kurtarmayı mevcut bir yapay zeka platformuna sonradan eklemek, başından itibaren inşa etmekten önemli ölçüde daha zordur. Yerinde yapay zeka altyapınızı tasarlıyor veya yeniden yapılandırıyorsanız, DR değerlendirmelerini her mimari karara gömün.

Artefakt depolamayı en başından standartlaştırın. Her takım modelleri farklı yerlerde depoluyorsa — bazıları yerel SSD'lerde, bazıları NFS paylaşımlarında, bazıları özel veritabanlarında — yedekleme sisteminiz hepsini kapsayamaz. Tutarlı adlandırma kuralları ve meta verilerle tek bir artefakt deposu (MinIO, Ceph veya benzeri) zorunlu kılın, ardından bu tek sistemi kapsamlı bir şekilde yedekleyin.

Model meta verilerini birinci sınıf varlık olarak ele alın. Meta verileri olmayan bir model dosyası — hangi veri seti üzerinde eğitildiği, hangi hiperparametrelerin kullanıldığı, değerlendirme metriklerinin ne olduğu — önemli ölçüde daha az kullanışlıdır. Meta verileri MLflow gibi bir model kayıt defterinde depolayın ve bu kayıt defterinin veritabanını Katman 1 yedekleme planınıza dahil edin.

Zarif bozunma için tasarlayın. Birincil çıkarım kümeniz başarısız olursa, uygulamanız CPU'da çalışan daha küçük bir modele veya yaygın sorgular için önbellekte bulunan yanıtlara geri dönebilir mi? Zarif bozunma, tam bir hizmet kesintisi olmadan kurtarma sırasında size zaman kazandırır. Bu geri dönüş yollarını önceden tanımlayın ve test edin.

Yapay zeka altyapısı için felaket kurtarma bir kontrol listesi uygulaması değildir — devam eden bir pratiktir. Temel ilke değişmez: kaybetmeyi göze alamayacağınızı belirleyin, agresif bir şekilde koruyun ve korumanızın çalıştığını düzenli olarak test ederek kanıtlayın.

Featured image by Growtika on Unsplash.