Bir modelin POC (proof of concept) aşamasında “çalışması” ile üretimde güvenilir şekilde değer üretmesi arasında büyük fark vardır. POC genellikle tek seferlik bir notebook çıktısı, sınırlı veri örneği ve manuel değerlendirme ile ilerler. Üretim ise tekrarlanabilirlik, izlenebilirlik, ölçek, maliyet kontrolü ve operasyonel sorumluluk ister.

Bu yazı; “modeli bir API’ye bağlayalım” seviyesinin ötesine geçip, POC’den başlayarak üretimde ölçeklenebilir bir MLOps pratiğine nasıl evrileceğinizi anlatır. Örnekler; model registry, Kubernetes tabanlı serving, performans optimizasyonu (ör. quantization), kontrollü rollout ve model izleme başlıklarında pratik karar noktalarına odaklanır.

1) POC’den üretime geçiş için başarı kriterlerini netleştirin

Üretime alma kararı teknik olduğu kadar ürün ve operasyon kararıdır. Önce “neyi iyi yapmak istiyoruz?” sorusunu sayısallaştırın ve dokümante edin:

  • Ürün metriği: Örn. arama alaka düzeyi, sahtecilik yakalama, müşteri destek otomasyonu kalitesi gibi.
  • Operasyon metriği: Gecikme (latency), kapasite (throughput), hata oranı, maliyet sınırı.
  • Kalite metriği: Offline değerlendirme ve (varsa) online deney (A/B veya canary) metrikleri.
  • Veri kapsamı: Hangi ülkeler/segmentler, hangi giriş türleri, hangi “uç” örnekler desteklenecek?
  • Sahiplik ve süreç: Modelin sahibi kim (ekip/rol), güncelleme periyodu nedir, geri dönüş (rollback) nasıl yapılır?

Bu kriterleri belirlemek, ileride model izleme alarmlarının eşiklerini ve rollout kararlarını da daha az tartışmalı hale getirir.

2) Üretim hazırlığı kontrol listesi (kısa ve etkili)

Model ve veri

  • Eğitim verisinin kaynağı, versiyonu ve hazırlanma adımları kayıtlı mı?
  • Özellik (feature) üretimi eğitim ve servis aşamasında tutarlı mı?
  • Offline metrikler tekrarlanabilir mi (aynı veri + aynı kod = aynı sonuç)?
  • Model çıktısı “iş kararı”na nasıl dönüşüyor (eşikler, iş kuralları, fallback)?

Paketleme ve bağımlılıklar

  • Model artefact’ı (ağırlıklar, tokenizer vb.) tek bir kimlikle sürümleniyor mu?
  • Çalışma zamanı bağımlılıkları (Python/conda, CUDA, kütüphaneler) sabitlenmiş mi?

Üretim davranışı

  • Beklenen gecikme hedefi ve kapasite hedefi tanımlı mı?
  • Gözlemlenebilirlik: istek sayısı, hata, gecikme, model sürümü etiketleri loglanıyor mu?
  • Geri dönüş planı: bir önceki model sürümüne dönüş adımı net mi?

3) Model registry ile versiyonlama ve onay akışını merkezileştirin

Üretim olgunluğunun en hızlı kaldıraçlarından biri, model yaşam döngüsünü “tek yerden” yönetmektir. Model registry; model versiyonlarını, aşamalarını (ör. staging/production), onay süreçlerini ve dağıtım kayıtlarını toplar. Bu yaklaşımın pratik karşılığı: “Hangi model ne zaman, hangi metriklerle, kim tarafından üretime alındı?” sorusuna hızlı yanıt verebilmenizdir.

Örneğin MLflow Model Registry dokümantasyonu; model versiyonlama, stage geçişleri ve onay iş akışları gibi üretim süreçlerini destekleyen kavramları anlatır: https://www.mlflow.org/docs/2.19.0/model-registry.html.

Pratik öneri: “tek komutla deploy” yerine “tek referansla deploy”

  • Deploy hedefi bir dosya yolu veya geçici (ad hoc) artefact yerine registry’deki model sürümü referansı olsun.
  • Her dağıtım, model sürümü + veri/özellik sürümü + kod sürümüyle ilişkilendirilsin.
  • Registry’de “Production” gibi bir aşamaya geçiş, ölçümler ve kontrol adımlarından sonra yapılsın.

Bu, hem denetim izi (audit trail) hem de hızlı rollback için temel oluşturur.

4) CI/CD ve “gated” pipeline: eğitimden dağıtıma güvenli köprü

MLOps’ta hedef; eğitim, değerlendirme ve dağıtımın manuel adımlardan arındırılıp ölçülebilir kapılar (gate) ile otomatikleşmesidir. Google Cloud’un TFX, Kubeflow Pipelines ve Cloud Build ile MLOps mimarisi dokümanı, veri/model validasyon adımlarının pipeline içine yerleştirilmesi fikrini örnekler: https://docs.cloud.google.com/architecture/architecture-for-mlops-using-tfx-kubeflow-pipelines-and-cloud-build.

Örnek pipeline akışı (genel şablon)

  1. Veri alma (batch/stream) + şema kontrolleri
  2. Özellik üretimi (eğitim/servis uyumunun kontrolü)
  3. Eğitim (tekrarlanabilir ortam)
  4. Değerlendirme (offline metrikler + karşılaştırma)
  5. Paketleme (model formatı, imaj/artefact)
  6. Registry kaydı + “staging”e terfi
  7. Dağıtım (canary/blue-green)
  8. İzleme (kalite, drift, performans) + geri besleme

Gate örnekleri (üretimde regresyon riskini düşürmek için)

  • Veri şeması beklenenden saparsa pipeline dursun.
  • Offline metrik önceki production sürümüne göre belirgin düşerse onay gereksin.
  • Paket güvenilirliği (ör. bağımlılık çözümü, çalışma testi) başarısızsa deploy olmasın.

5) Serving mimarisi seçimi: tek doğru yok, net trade-off var

Serving seçimi; gecikme hedefi, model sayısı, donanım (CPU/GPU), ölçekleme ihtiyacı ve ekip yetkinliğiyle şekillenir. Aşağıdaki yaklaşım, karar çerçevesi sunar.

Online, batch ve streaming ayrımı

  • Online (senkron API): Kullanıcı isteğine anlık yanıt gerekir (latency kritik).
  • Asenkron: Yanıt gecikebilir; kuyruklar ile daha stabil kapasite sağlanır.
  • Batch: Günlük/haftalık skorlama; yüksek hacimde maliyet verimliliği odaklıdır.

Kubernetes-native serving: KServe

Model serving’i Kubernetes üzerinde standartlaştırmak isteyen ekipler için KServe; ölçekleme, çoklu model ve dağıtım desenleri gibi konuları ele alan bir çözüm ailesidir. Başlangıç ve kavramsal çerçeve için resmi dokümantasyon: https://www.kubeflow.org/docs/components/kserve/introduction/.

  • Ne zaman mantıklı? Birden fazla modelin benzer şekilde yönetilmesi, otomatik ölçekleme ve platform standardizasyonu hedeflendiğinde.
  • Dikkat edilmesi gerekenler: Kubernetes operasyon yükü ve gözlemlenebilirlik entegrasyonunun erken planlanması.

Yüksek performans odaklı serving: NVIDIA Triton

Gecikme ve throughput baskısı yüksek senaryolarda (özellikle GPU tabanlı inference) Triton; farklı backend’ler ve dinamik batching gibi performans odaklı yeteneklerle öne çıkar. Güncel özellikler ve değişiklikler için NVIDIA’nın dokümantasyon ve sürüm notları: https://docs.nvidia.com/deeplearning/triton-inference-server/release-notes/index.html.

  • Ne zaman mantıklı? GPU verimliliği, batchleme ve yüksek throughput gereken üretim servislerinde.
  • Dikkat: Sürüm takibi, backend uyumluluğu ve model formatlarının yönetimi operasyonun parçasıdır.

Taşınabilir çalışma zamanı ve optimizasyon: ONNX Runtime

Modeli ONNX formatına taşımak ve çalışma zamanında performans optimizasyonları (ör. quantization) yapmak isteyenler için ONNX Runtime’ın resmi rehberi iyi bir başlangıçtır: https://onnxruntime.ai/docs/performance/model-optimizations/quantization.html.

  • Ne zaman mantıklı? Farklı ortamlarda taşınabilirlik, CPU inference, edge/on-prem senaryoları veya standart format hedeflendiğinde.
  • Dikkat: Quantization performansı artırabilir; ancak bazı modellerde kalite düşüşü görülebilir. Bu nedenle zorunlu olarak karşılaştırmalı test gerekir.

Hızlı başlangıç için managed servisler (izleme dahil)

Bulut sağlayıcılarının managed yaklaşımları, izleme/alarmlama ve operasyonel entegrasyon açısından hızlı değer sağlar. Örneğin Google Vertex AI Model Monitoring kurulumu ve drift tespiti akışını anlatır: https://docs.cloud.google.com/vertex-ai/docs/model-monitoring/set-up-model-monitoring. Benzer şekilde AWS SageMaker Model Monitor veri ve model kalite izlemesi için iş akışları sunar: https://docs.aws.amazon.com/sagemaker/latest/dg/model-monitor.html.

6) Cloud / on-prem / edge için kısa karşılaştırma tablosu

Hedef Artılar Sınırlamalar / riskler Tipik araç yaklaşımı
Cloud (managed) Hızlı kurulum, yerleşik izleme ve operasyon entegrasyonu Sağlayıcıya bağımlılık, maliyet görünürlüğü ve sınırlandırmaların iyi anlaşılması gerekir Managed endpoint + yerleşik monitoring (ör. Vertex / SageMaker)
On-prem (Kubernetes) Taşınabilirlik, daha fazla kontrol, kurum içi altyapı ile uyum Kubernetes işletimi ve gözlemlenebilirlik “sizin sorumluluğunuzda” KServe + registry + kendi izleme yığını
Edge / cihaz Veri yerinde işlenir, düşük bağlantı bağımlılığı Donanım çeşitliliği, güncelleme yönetimi, model boyutu/performans kısıtları ONNX Runtime + model optimizasyonu (gerektiğinde quantization)

7) Latency optimizasyonu: ölçmeden optimize etmeyin

Latency optimizasyonu, genellikle birkaç bileşenin toplamıdır: ağ gecikmesi, ön işleme (preprocessing), inference, son işleme (postprocessing) ve bağımlı servis çağrıları. Bu nedenle ilk adım “nerede zaman harcıyoruz?” sorusunu izlerle (tracing/metrics) yanıtlamaktır.

Yüksek etkili pratikler

  • İstek boyutunu küçültme: Gereksiz alanları atın, sıkıştırmayı düşünün.
  • Ön/son işleme maliyetini azaltma: Vektörleştirme, daha verimli veri yapıları.
  • Batching: Uygunsa micro-batching throughput’u artırabilir (özellikle GPU). Triton gibi çözümler bu alanda yetenekler sunar.
  • Model optimizasyonu: ONNX graph optimizations, quantization gibi yaklaşımlar bazı senaryolarda gecikmeyi azaltabilir; ancak kalite regresyonu riski vardır (ONNX Runtime rehberi bu trade-off’ları vurgular).

Quantization için “uygulama notları” (risk yönetimi)

  • Back-to-back test: Aynı istek setinde önce FP32 (veya mevcut üretim) sonra quantized modeli çalıştırın.
  • Kalite kapısı: Offline metrikte kabul edilebilir tolerans aralığını önceden tanımlayın.
  • Donanım uyumu: Performans kazanımı donanım ve çalışma zamanına bağlıdır; tek ortamda gördüğünüz kazanımı genellemeyin.

Aşağıdaki tabloyu bir “kendi benchmark şablonunuz” olarak kullanabilirsiniz (rakamlar örnek değildir; siz doldurmalısınız):

Model sürümü Ortam p50 latency p95 latency Throughput Offline kalite metriği
Baseline (mevcut) CPU/GPU — — — —
Quantized CPU/GPU — — — —

8) Rollout stratejileri: kontrollü değişiklik, hızlı geri dönüş

Üretimde model güncellemek, uygulama güncellemekten farklıdır: veri dağılımı değişebilir, etiket gecikmesi olabilir, gerçek dünya geri bildirimi zaman alabilir. Bu yüzden küçük adımlarla ilerlemek değerlidir.

Yaygın rollout desenleri

  • Blue/green: Yeni sürüm ayrı ortamda hazırlanır; trafik tek seferde yönlendirilir. Geri dönüş hızlıdır.
  • Canary: Trafiğin küçük bir yüzdesi yeni modele verilir; metrikler iyi ise kademeli artırılır.
  • Shadow: Yeni model gerçek trafiği “gölge” olarak görür ama karar vermez; gözlem için uygundur.
  • A/B: Ürün metriği için deney altyapısı varsa, etkiyi ölçmek için idealdir.

CI/CD mimarilerinde canary ve kontrollü geçiş pratikleri, validasyon kapılarıyla birlikte ele alınır (örnek mimari tartışmaları için Google Cloud mimari rehberine bakabilirsiniz).

Rollback kuralı (basit ama kritik)

  • Rollback tetikleyicileri önceden tanımlı olsun (ör. hata oranı artışı, latency bozulması, kalite göstergesi düşüşü).
  • Rollback “tek adım” olmalı: registry’de bir önceki “Production” sürümüne dönmek gibi.

9) Üretim izleme: yalnızca uptime değil, model sağlığı

Üretimde izleme iki katmandır: (1) servis sağlığı (latency, hata oranı, kapasite), (2) model sağlığı (veri dağılımı, kalite göstergeleri, drift sinyalleri). Managed araçlar bu konuda hız kazandırabilir.

Bulutta izleme örnekleri

Pratik izleme kontrol listesi

  • Model sürümü etiketi: Her istekte hangi sürüm çalıştı loglarda görülebilsin.
  • Girdi sağlığı: Eksik alan, beklenmeyen tip/şema, uç değer sinyalleri.
  • Çıktı sağlığı: Skor dağılımı değişiyor mu, anormal yoğunlaşma var mı?
  • Etiket gecikmesi stratejisi: Gerçek etiket geç geliyorsa, kısa vadeli proxy metrikler belirleyin.
  • Alarm tasarımı: Sinyal gürültüsünü azaltmak için eşik + süre + trend mantığı kurun.

10) Büyük modeller ve hızla değişen optimizasyon alanları için not

Büyük model inference optimizasyonları (özellikle donanım verimliliği teknikleri) hızlı evriliyor. Bu yazıda aktarılan performans optimizasyonu prensipleri (ölçüm, kontrollü değişiklik, regresyon testi) kalıcıdır; ancak spesifik teknik ve araç özellikleri sürümlere göre değişebilir. Üretimde karar verirken kullandığınız serving/accelerator dokümantasyonunun güncel sürüm notlarını düzenli takip edin (ör. Triton sürüm notları).

11) Araç seçimi: teknoloji kadar organizasyon tasarımı

MLOps araçları; yalnızca teknik özelliklerle değil, ekiplerin çalışma biçimiyle de uyumlu olmalıdır. 2025 tarihli bir derleme çalışma, MLOps ekosisteminde platform ve araç çeşitliliğini ve benimseme eğilimlerini özetler: https://link.springer.com/article/10.1007/s10462-025-11164-3. Pratikte şu sorular işe yarar:

  • Platform ekibi var mı? Yoksa managed servisler daha hızlı değer sağlayabilir.
  • Model sayısı ve çeşitliliği nedir? Tek model vs çok model operasyonu farklıdır.
  • Dağıtım hedefleri çeşitleniyor mu? Cloud + on-prem + edge birlikteyse taşınabilirlik kritikleşir.
  • Governance ihtiyacı nedir? Registry ve onay akışları gereksinimi erken anlaşılmalı.

12) Yayına almadan önce: “son 30 dakika” kontrol listesi

  • Model registry’de doğru sürüm “Production” hedefiyle etiketlendi mi?
  • Canary oranı ve geri dönüş adımı hazır mı?
  • Latency/hata oranı panoları (dashboards) açık mı ve model sürümü filtrelenebiliyor mu?
  • İzleme alarmları aktif mi (veri sağlığı + servis sağlığı)?
  • Gizli anahtarlar/erişim yetkileri doğru yönetiliyor mu?
  • İş birimleriyle başarı kriterleri ve “durma/geri dönüş” koşulları paylaşıldı mı?

Sonuç: Üretimde sürdürülebilir MLOps için minimum set

POC’den üretime geçişi hızlandıran “minimum set” çoğu ekipte şunlara indirgenebilir: (1) registry üzerinden net versiyonlama ve geri dönüş, (2) gate’li CI/CD pipeline, (3) doğru serving mimarisi, (4) kontrollü rollout, (5) servis + model sağlığı izleme.

Bir sonraki adım: Ekibinizde standardı hızla oturtmak için Model registry kontrol listesi ve Serving seçim çalışma sayfası gibi kısa şablonlar oluşturun.

Not: Bu içerik genel bilgilendirme amaçlıdır ve kurumunuzun gereksinimlerine göre güvenlik, veri yönetişimi ve uyum kontrollerini ayrıca değerlendirmeniz gerekir.