Yazı
Air-Gapped MLOps ile On-Prem AI: İnternet Olmadan Model Yayınlama
İzole ortamlarda model eğitmek, doğrulamak, onaylamak ve yayınlamak zorunda olan kurumlar için pratik bir sürüm yönetimi yaklaşımı.
Air-Gapped AI, Bulut MLOps'un Ağsız Bir Kopyası Değildir
Pek çok kurum bunu uygulama aşamasında fark ediyor. On-premises AI için iyi bir proof of concept geliştiriliyor, sonra aynı teslim şekli izole üretim ortamına taşınmak isteniyor. O anda süreç dağılıyor. Paket depoları kapalı, model indirmeleri onaya bağlı, güvenlik ekibi artifact provenance istiyor, operasyon ekibi ise manuel kopyalama istemiyor çünkü bu durum denetim izini zayıflatıyor. Air-gapped ortamlarda yalnızca model değil, tüm artifact zinciri korunması gereken bir tedarik akışı haline gelir. Bu zincir zayıfsa deployment da zayıftır.
Bu durum en çok savunma sanayii, kritik altyapı, sağlık ve endüstriyel ortamlarda ortaya çıkar. Asıl tasarım sorusu hangi modeli çalıştıracağınız değildir. Asıl soru; ağırlıkları, promptları, değerlendirme sonuçlarını, container imajlarını, tokenizer dosyalarını, güvenlik politikalarını ve rollback paketlerini güven sınırları arasında izlenebilir şekilde nasıl taşıyacağınızdır. Bu ihtiyacı geçici bir güvenlik istisnası gibi ele alan ekipler, sonunda USB kopyalama, kahramanlık gerektiren acil çözümler ve dokümansız değişikliklerle karşı karşıya kalır. Bunu bir MLOps tasarım problemi olarak ele alan ekipler ise güvenlik tarafının onaylayabildiği ve operasyonun sürekli işletebildiği tekrar edilebilir bir yayın mekanizması kurar.
Güven Sınırları Etrafında Bir Release Train Kurgulayın
En temiz yaklaşım, yapının üç bölgeye ayrılmasıdır: internete açık mühendislik bölgesi, pre-production doğrulama bölgesi ve tamamen izole production bölgesi. Bağlantılı alan; eğitim, fine-tuning, bağımlılık çözümleme ve ilk benchmark çalışmalarının yapıldığı yerdir. Doğrulama alanı production'a çok benzer ama güvenlik incelemesine izin verecek kadar kontrollüdür. Production alanı ise sadece imzalı release bundle kabul eder. Bu model, tek tek dosya aktarmaya göre çok daha sağlıklıdır çünkü aktarma ritüeli değil, terfi eden bir yayın yolu kurar.
Pratikte release bundle içinde model artifact'i, container image digest'i, tokenizer dosyaları, serving konfigürasyonu, evaluation raporu, prompt setleri ve modelin amacını, sınırlarını ve geri dönüş sürümünü anlatan bir model card bulunmalıdır. Bunları platform ekiplerinin zaten tanıdığı sistemlerde saklamak isabetlidir: container'lar için Harbor, model metadata için MLflow ya da benzeri bir registry, değiştirilemez artifact'ler için ise MinIO gibi bir object store. Bundle'ın kendisi Cosign benzeri araçlarla imzalanırsa, hedef ortam internete çıkmadan bütünlük doğrulaması yapabilir.
Release train'in bir ritmi de olmalıdır. Aylık veya iki haftada bir yapılan terfiler, plansız taleplere göre çok daha kolay yönetilir. Güvenlik incelemeleri, validation işleri ve bakım pencereleri önceden planlanabilir. Acil geçişler tabii ki olur; ancak bunlar varsayılan çalışma biçimi değil, istisna olmalıdır.
Validation Kapıları Sadece Doğruluğa Basmamalı
Düzgün yönetilen regüle ortamlarda bir model, sadece benchmark skoru yüksek diye ileri aşamaya geçmez. Promotion öncesinde yazılım tedarik zinciri, davranış ve operasyonel uyumu kapsayan bir gate seti çalıştırılmalıdır. En azından container image için zafiyet taraması, software bill of materials, eğitim veri paketleri için checksum kontrolü ve production'da çalışacak inference stack'inin offline tekrar üretilebilirlik testi yapılmalıdır. Bir ekip, versioned girdilerden serving artifact'ini yeniden oluşturamıyorsa o release hazır değildir.
Davranış doğrulaması da aynı disiplinle ele alınmalıdır. Dil modelleri için bu; sabitlenmiş offline test setleri, temsil edici promptlar, adversarial prompt denemeleri, refusal kontrolleri, structured output doğrulamaları ve göreve özel kabul kriterleri anlamına gelir. Örneğin doküman inceleme asistanı yalnızca genel reasoning kalitesiyle değil, field extraction tutarlılığı, schema uyumu ve escalation oranıyla değerlendirilmelidir. Fabrikada kullanılan bir görüntü modeli ise ışık değişimi, kamera kayması ve hatalı alarm toleransı gibi gerçek koşullarda test edilmelidir. Yani değerlendirilen şey genel bir skor değil, iş bağlamındaki davranış olmalıdır.
Burada işe yarayan basit bir kural vardır: Her promotion paketi dört denetim sorusunu açıkça cevaplamalıdır. Ne değişti? Neden değişti? Kim onay verdi? Geri nasıl döneceğiz? Bu cevaplar bundle ile birlikte gelmiyorsa deployment hala kurum hafızasına bağlıdır ve bu da kırılgandır.
Push Yerine Pull, Doğrudan Geçiş Yerine Shadow ve Yerel Rollback
Air-gapped production ortamları, manuel push değişiklikleri kabul etmek yerine onaylı artifact'leri iç kaynaktan pull ettiğinde daha stabil olur. İmzalı bundle izole registry'ye aktarıldıktan sonra deployment; GitOps akışları, imzalı manifestler ve değişiklik kontrollü promotion işleriyle yönetilmelidir. Araç seti kuruma göre değişir, ancak Argo CD, Flux veya benzeri yaklaşımlar deklaratif durumu ve denetim izini koruduğu için genellikle başarılı olur.
Model serving katmanında ise doğrudan değişim yerine aşamalı rollout kullanmak gerekir. Özellikle kritik inference API'lerinde blue-green deployment, kesintisiz kontrol için daha güvenlidir. AI tarafında shadow mode çok değerlidir çünkü yeni modelin çıktılarını son kullanıcıya göstermeden mevcut production modeliyle aynı trafik üzerinde karşılaştırma imkânı verir. Örneğin farmasötik kalite süreçlerinde yeni model, aynı batch kayıtları üzerinde sınıflandırma veya extraction yapabilir; ancak canlı kararı mevcut model verir. Trafik kaydırılmadan önce farklar incelenir.
Rollback mekanizması da yerel ve hızlı olmalıdır. İzole ortam içinde en az bir bilinen iyi container image, model artifact'i ve konfigürasyon seti tutulmalıdır. Eski bir sürüme dönmek başka bir ekibin yeniden export yapmasına bağlıysa, elinizde gerçek bir kurtarma mekanizması yoktur. Elinizde sadece yeni bir talep süreci vardır.
Air-Gapped MLOps'u Ortak Bir Platform Kabiliyeti Olarak Yönetin
Bu işi iyi yapan kurumlar problemi ne sadece data science ekibine ne de sadece güvenlik tarafına verir. Platform mühendisliği, ML mühendisliği, güvenlik ve iş sahipleri arasında ortak bir operating model kurarlar. Platform ekipleri artifact yolu, cluster policy, registry ve rollback otomasyonundan sorumludur. ML ekipleri evaluation setleri, model card'lar, prompt varlıkları ve release evidence üretir. Güvenlik ekipleri imza kurallarını, import kontrollerini ve onay kriterlerini belirler. İş sahipleri ise kabul eşiklerini tanımlar; örneğin kabul edilebilir escalation hacmi, inceleme süresi veya kaçırılan extraction sayısı gibi.
Başlangıç için yalnızca birkaç şeyi standartlaştırmak yeterlidir: tek bir release bundle formatı, tek bir promotion checklist'i, tek bir imzalama yöntemi, tek bir rollback paterni ve tek bir onay kanıt şablonu. Bunlar oturduktan sonra offline drift raporlama, temel modellerin periyodik recertification süreci ve hassas veriler için izole retraining pipeline'ları eklenebilir. Sonuç çok parlak görünmeyebilir ama kritiktir: her model güncellemesini özel operasyona çevirmeden evrilebilen bir on-prem AI yapısı.
On-premises AI'da olgunluk burada kendini belli eder. En güçlü ekip, laboratuvarda en hızlı ilerleyen ekip değildir. En güçlü ekip, gerçek güvenlik kuralları altında bile güvenli, tekrar edilebilir ve tamamen izlenebilir şekilde yayın yapabilen ekiptir.