Makine öğrenmesi modeli API olarak nasıl yayına alınır?
Beceri rehberi

Makine öğrenmesi modeli API olarak nasıl yayına alınır?

Hazırlayan: Mindset Institute EditörlüğüGüncellendi: 5 dk okuma

Makine öğrenmesi modelini API olarak yayına alma: paketleme, girdi doğrulama, asenkron servis, konteyner, ölçekleme ve sürüm geçişi adım adım anlatılıyor.

Model sunumu (model serving) ne demektir?

Model sunumu, eğitilmiş bir makine öğrenmesi modelini başka sistemlerin ve kullanıcıların çağırabileceği bir hizmete dönüştürmektir. Not defterinde çalışan bir model yalnız o defteri açan kişiye fayda sağlar; API olarak sunulduğunda mobil uygulama, web sitesi ya da başka bir servis ona girdi gönderip tahmin alabilir.

Temel olarak farklı kullanım biçimleri vardır. Çevrim içi (anlık) sunumda her istek ayrı ayrı ya da küçük gruplar halinde yanıtlanır; örneğin bir ödeme anında dolandırıcılık skoru üretmek. Toplu (batch) sunumda ise büyük bir veri kümesi belirli aralıklarla topluca puanlanır; örneğin her gece müşteri kaybı olasılığını yenilemek. Hangisinin seçileceği gecikme ihtiyacına bağlıdır. Anlık yanıt gerekmiyorsa toplu puanlama çok daha basit ve ucuzdur; API yalnız gerçekten gerektiğinde kurulmalıdır.

Adım adım: modelden çalışan API'ye

Tipik bir yayına alma süreci şu adımlardan oluşur: • Modeli taşınabilir biçimde kaydedin. Eğitim ortamının kütüphane sürümlerini de kaydedin; sunum ortamı farklı sürüm kullanırsa tahminler değişebilir. • Ön işleme adımlarını modelle birlikte paketleyin. Eğitimde yapılan ölçekleme, kodlama ve eksik değer doldurma sunumda da aynen uygulanmalıdır. • Girdi ve çıktı şemasını tanımlayın. Alan adları, türler ve izin verilen aralıklar açıkça yazılmalı; geçersiz girdi eğitim koduna ulaşmadan reddedilmelidir. • Bir web çerçevesiyle uç nokta yazın. Python dünyasında FastAPI gibi asenkron çerçeveler, ASGI üzerinde eşzamanlı istekleri verimli işler. • Modeli uygulama açılışında bir kez belleğe yükleyin; her istekte yeniden yüklemek gecikmeyi büyütür. • Sağlık kontrolü uç noktası ekleyin ki orkestrasyon sistemi servisin hazır olup olmadığını bilsin. • Bunu bir konteyner imajına paketleyip dağıtım ortamına gönderin.

BentoML gibi araçlar paketleme ve API oluşturma adımlarını standartlaştırır; elle FastAPI yazmak ise daha fazla esneklik ve daha fazla sorumluluk demektir.

API tasarımı ve performans

Model API'si sıradan bir web servisinden farklı sorunlar taşır. Tahmin hesabı işlemci ya da hızlandırıcı yoğundur, bu yüzden istek başına gecikme ile toplam verim arasında denge kurulur.

Performansı etkileyen başlıca kararlar: • Mikro gruplama: gelen istekleri çok kısa süre biriktirip modele birlikte vermek, hızlandırıcı kullanımını artırır ama gecikmeyi biraz uzatır. • Asenkron işleme: uzun süren tahminlerde isteği kuyruğa alıp sonucu sonradan döndürmek bağlantı sürelerini rahatlatır. • Girdi boyutu sınırları: çok büyük girdi tek bir isteği ve tüm servisi kilitleyebilir. • Önbellek: aynı girdi tekrar tekrar geliyorsa sonucu saklamak hesap yükünü azaltır. • Model küçültme: nicemleme ya da daha hafif model mimarisi gecikmeyi düşürebilir, ancak doğruluğa etkisi ölçülmelidir.

Sürüm bilgisini yanıta eklemek de iyi bir pratiktir; bir tahminin hangi model sürümünden geldiğini sonradan izleyebilirsiniz. API sözleşmesini (girdi alanları, yanıt biçimi) model değişse bile kararlı tutmak, tüketici ekiplerin yükünü azaltır.

Konteyner, Kubernetes ve ölçekleme

Konteyner imajı, modelin bağımlılıklarıyla birlikte aynı biçimde her ortamda çalışmasını sağlar. Kubernetes gibi bir orkestrasyon katmanı ise bu imajın birden çok kopyasını çalıştırır, sağlıksız kopyayı yeniler ve yük arttığında kopya sayısını ayarlar.

Model sunumunda ölçekleme kararı bazı özel noktalar taşır. Modelin belleğe yüklenme süresi uzunsa yeni kopya geç hazır olur ve ani yük artışında yetişemez. Hızlandırıcı (GPU) gerektiren modellerde kaynaklar pahalıdır; boşta bekleyen kopya doğrudan maliyettir. Bu nedenle ölçekleme ölçütü yalnız işlemci kullanımı değil, bekleyen istek sayısı ve gecikme olabilir.

Sürüm geçişi de ayrı bir konudur. Yeni modeli bütün trafiğe bir anda açmak yerine önce küçük bir paya yönlendirmek (kademeli geçiş), eski sürümü yedek tutmak ve sürümleri gerçek istekler üzerinde karşılaştırmak riski azaltır. Sorun çıkarsa trafiği eski sürüme çevirmek bir dakikalık iş olmalıdır.

Örnek senaryo: müşteri kaybı skoru servisi

Kurgusal bir örnek olarak bir telekom firmasının müşteri kaybı modelini ele alalım. Ekip modeli kaydeder, ön işleme adımlarını aynı pakete koyar ve bir FastAPI servisi yazar. Servis, müşteri kimliği ve birkaç özelliği alıp bir olasılık ve model sürümü döndürür. Girdi şeması yanlış türde değeri doğrudan reddeder.

Servis bir konteynere paketlenir ve çağrı merkezi uygulamasının kullanacağı bir uç nokta olarak yayımlanır. Yoğun saatlerde kopya sayısı artar. Yeni bir model sürümü hazır olduğunda önce çağrı merkezi trafiğinin küçük bir kısmı ona yönlendirilir; yanıt süreleri ve skor dağılımı eski sürümle karşılaştırılır, sonra geçiş genişletilir. Her tahmin, girdisi ve sürüm bilgisiyle günlüğe yazılır; böylece ilerde model izleme ve yeniden eğitim için veri birikir.

Sık yapılan hatalar

Yayına almada sık görülen sorunlar şunlardır: • Eğitim ve sunum arasında ön işleme farkı. En sinsi hata budur; model çalışır ama yanlış tahmin üretir. Ön işlemeyi tek bir kod yolundan geçirin. • Modeli her istekte yeniden yüklemek ya da çok büyük bir modeli her kopyada gereksiz yere tutmak. • Girdi doğrulaması yapmamak. Beklenmeyen değerler hatalı skor ya da servis çökmesi yaratır. • Eşzamanlı bloklayıcı kod kullanmak: ağır hesabı asenkron olay döngüsünün içinde çalıştırmak tüm istekleri bekletir. • Sürümleme olmadan model değiştirmek; sorun çıktığında geri dönülemez. • İzleme eklememek: gecikme, hata oranı ve tahmin dağılımı görünmüyorsa bozulma haftalarca fark edilmez. • Güvenliği unutmak: kimlik doğrulama, istek sınırlama ve girdi boyutu denetimi olmayan bir model API'si kötüye kullanıma açıktır.

Bu sorunlar model kalitesiyle değil, yazılım mühendisliği disipliniyle ilgilidir.

Öğrenme yolu

Önce basit bir modeli kaydedip yerelde küçük bir web servisi olarak çalıştırın. Girdi şeması tanımlayın ve hatalı girdilerin reddedildiğini test edin. Ardından servisi konteynere alın ve başka bir makinede çalıştığını doğrulayın.

İlerleyen aşamada asenkron çerçeve özelliklerini, bağımlılık enjeksiyonunu, arka plan görevlerini ve kuyrukları öğrenin. Sonra bir orkestrasyon ortamında dağıtım, sağlık kontrolleri, kaynak sınırları ve otomatik ölçeklemeye geçin. Son aşamada sürüm yönetimi, trafik yönlendirme, hızlandırıcı kullanımı, maliyet ve izleme gelir. Her aşamada küçük bir yük testi yapmak (örneğin çok sayıda eşzamanlı isteği simüle etmek) beklenmeyen darboğazları erkenden gösterir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Model Sunumu (Model Serving) ve Ölçekleme (BentoML, Seldon) programı modül başlıklarına göre model sunum mimarileri, BentoML ile paketleme, API tasarımı ve performans, Kubernetes üzerinde dağıtım, sürüm yönetimi ve trafik yönlendirme ile GPU, maliyet ve izlemeyi kapsar. Python FastAPI İleri Seviye ve Asenkron Servisler programı FastAPI mimarisi ve ASGI temelleri, bağımlılık enjeksiyonu, asenkron veritabanı erişimi, eşzamanlılık, arka plan ve kuyruklar, performans ve dayanıklılık ile güvenlik, test ve dağıtım konularını içerir.

İlgili Mindset programı

Model Sunumu (Model Serving) ve Ölçekleme (BentoML, Seldon)

Sık sorulanlar

Sık sorulan sorular

Model serving ile model deployment aynı şey mi?

Gündelik kullanımda sık birbirinin yerine kullanılır. Dağıtım (deployment) modeli bir ortama yerleştirme sürecinin tamamını, sunum (serving) ise modelin istekleri karşılayıp tahmin döndürmesini anlatır. Pratikte sunum, dağıtımın sonunda ortaya çıkan çalışan hizmettir.

Modeli API olarak sunmak için hangi araç seçilmeli?

Basit ve tek modelli işler için FastAPI gibi bir web çerçevesi yeterli olabilir. Çok sayıda model, sürüm yönetimi ve ölçekleme gerekiyorsa BentoML ya da Seldon gibi sunum araçları standart bir yapı sağlar. Seçim, ekibin altyapı olgunluğuna ve model sayısına bağlıdır.

Çevrim içi sunum mu toplu puanlama mı gerekir?

Karar anında yanıt gerekiyorsa çevrim içi sunum kurulur. Sonuç saatler sonra kullanılacaksa toplu puanlama daha basit, daha ucuz ve yönetmesi daha kolaydır. Önce kabul edilebilir gecikmeyi belirlemek, gereksiz API karmaşıklığını önler.

Yayındaki modeli kesintisiz nasıl güncellerim?

Yeni sürümü eskisinin yanında çalıştırıp trafiğin küçük bir kısmını ona yönlendirirsiniz. Gecikme, hata ve tahmin dağılımı sağlıklıysa payı artırırsınız. Sorun çıkarsa trafiği eski sürüme çevirirsiniz. Bunun için sürümlerin ayrı etiketlenmesi ve eski sürümün hemen kaldırılmaması gerekir.

Model API'sinin güvenliği için neye dikkat edilmeli?

Kimlik doğrulama ve yetkilendirme, istek sınırlama, girdi boyutu ve türü denetimi, iletişimin şifrelenmesi ile günlüklerde kişisel verinin korunması temel başlıklardır. Model dışarıya açılacaksa ayrıca girdi manipülasyonuna karşı beklenmeyen değerlerin reddedilmesi gerekir.