1. Giriş

Makine öğrenimi modellerinin üretimde uygulanması, günümüz uygulama dünyasında iki temel çalışma paradigması etrafında şekilleniyor: toplu (batch) inference ve gerçek‑zamanlı (real‑time / online) inference. Kullanıcı beklileri, altyapı kapasitesi, veri tazeliği ve maliyet kısıtları; hangi yöntemin seçileceğini belirleyen ana etkenlerdir. Doğru seçim, yalnızca performans metriği değil, aynı zamanda işletme maliyeti, operasyonel karmaşıklık ve bakım yükü açısından da kritiktir.

Bu makale mühendis ve yazılım mimarı perspektifinden tasarlanmıştır. Amacımız sadece tanımlamak değil; sistem mimarisi, uygulama senaryoları, gerçek dünya örnekleri, avantaj‑dezavantaj analizi, karşılaştırmalar ve uygulamada işe yarayan en iyi pratikleri teknik ama anlaşılır bir dille sunmaktır. Okuduktan sonra, hangi durumda batch ya da real‑time seçmeniz gerektiğini, hibrit modellerin nasıl tasarlanacağını ve operasyonel risklerin nasıl azaltılacağını netleştirmiş olacaksınız.

Bu konu neden önemli? Çünkü ML modelleri üretimde iken yanlış operasyonel kararlar hem kullanıcı deneyimini bozabilir hem de maliyeti katlayabilir. Örneğin bir fraud detection akışı için batch yaklaşımı seçmek, finansal kayıplara yol açarken; reklam veya öneri sistemlerinde real‑time eksikliği tıklama oranlarını düşürebilir. Bu yüzden doğru mimari kararları almak, modern veri ve ML mühendisliğinin merkezinde yer alır.

Kimler için önemli? Ürün mühendisleri, ML mühendisleri, MLOps ekipleri, SRE'ler, veri mühendisleri ve teknik yöneticiler için kritik bir konudur. Ayrıca startup CTO’ları ile büyük ölçekli platform ekipleri de doğru altyapı yatırımını planlarken bu rehbere ihtiyaç duyacaktır.

2. Kavramsal Temeller

Temel Tanımlar

• Batch Inference: Modelin belirli zaman aralıklarında veya tetikleme ile toplu veri setleri üzerinde çalıştırılması. Büyük veri blokları paralel olarak işlenir.
• Real‑Time (Online) Inference: Gelen tekil istek başına anında tahmin üretme. Genellikle HTTP/gRPC endpoint veya streaming tüketici üzerinden sağlanır.
• Micro‑Batch / Streaming: Gerçek‑zaman ile batch arasında kalan, kısa periyotlarda (ör. saniyeler‑dakikalar) veri işleyen yaklaşımlar.
• Throughput: Birim zamanda işlenen örnek sayısı.
• Latency: Tek bir isteğin baştan sona yanıt süresi (ms). p50/p95/p99 ölçümleri kullanılır.
• Feature Store: Training ve serving için ortak özellik deposu; offline/online erişim seçenekleri vardır.

Mimari Bileşenler (Genel)

Bir inference sisteminin tipik bileşenleri:

1. Data Sources: Event stream, database, user interactions, batch files.
2. Feature Pipeline: ETL/ELT süreçleri, feature engineering, offline/online feature hesaplama.
3. Model Artifact Store: Model binary (ONNX/TorchScript/TensorFlow SavedModel), metadata ve versiyonlama.
4. Serving Infrastructure: API gateways, load balancers, K8s/Triton/TorchServe, serverless platforms.
5. Monitoring: Latency, throughput, model prediction drift, business KPIs.

3. Nasıl Çalışır?

Batch Inference — Teknik Akış

Batch inference genelde şu adımları izler:

1. Scheduler (Airflow/Prefect/Dagster) zamanlanan bir job tetikler.
2. Veri lake veya veri deposundan ham veri okunur.
3. Offline feature pipeline çalışır; özellikler normalize edilir, eksikler doldurulur.
4. Büyük batch'ler GPU/TPU veya CPU üzerinde yüksek paralellik ile işlenir. Burada vektörize ops ve I/O optimizasyonu önemlidir.
5. Sonuçlar veri tabanına, analitik tabloya veya downstream hizmete yazılır.

Özellikler:

• Batching sayesinde yüksek throughput ve daha düşük birim maliyet.
• Retry ve checkpoint mekanizmaları ile hata toleransı yüksek.
• Tipik kullanım: raporlama, toplu kampanya skorlama, günlük offline model değerlendirmeleri.

Real‑Time Inference — Teknik Akış

Real‑time inference, düşük gecikme hedefleri gözeterek titiz bir pipeline gerektirir:

1. Kullanıcı isteği API gateway üzerinden gelir (REST/gRPC/Websocket).
2. Endpoint minimal preprocessing (tokenization, feature normalization) uygular.
3. Gerekli online feature'lar, feature store veya hızlı cache (Redis/DynamoDB) üzerinden çekilir.
4. Model runtime (ONNX Runtime, TensorRT, TorchServe, Triton) kullanılarak inference yapılır.
5. Sonuç anında döndürülür; aynı zamanda telemetri gönderilir.

Öne çıkan teknik konular:

• Cold start: Dinamik ölçeklenen servislerde ilk çağrının ekstra gecikmesi.
• Batching for real‑time: Micro‑batching veya request coalescing ile throughput artırılırken latency kontrolü sağlanır.
• Model optimizasyonları: Quantization, operator fusion, FP16, TensorRT engINGLE gibi teknikler latency'yi düşürür.
• Edge vs Cloud: Edge ortamlar düşük ağ gecikmesi ve gizlilik avantajı sunar ama model güncellemeleri zordur.

Örnek Teknoloji Yığını

• Serving: NVIDIA Triton, TorchServe, ONNX Runtime, FastAPI + Uvicorn (lightweight), Vertex AI Predictions, SageMaker Endpoints.
• Feature Store: Feast, Tecton veya kendi in‑house Redis/Dynamo tabanlı çözümü.
• Orchestration: Airflow/Prefect/Dagster (batch); KEDA/HPA veya serverless (real‑time).
• Observability: Prometheus, Grafana, ELK, Sentry, custom model performance dashboards.

4. Gerçek Dünya Kullanımları

Hibrit Pattern — Öneri Sistemleri (Netflix, Amazon)

Çoğu öneri sistemi hibrit yaklaşım kullanır. Offline (batch) modeller büyük bir aday havuzu ve embedding'ler üretir; online katman ise bu havuzu kişiselleştirir ve hızlı re‑rank uygular. Böylece hem geniş kapsama (recall) hem de düşük latency (precision/better UX) sağlanır.

Fraud Detection (Stripe, Visa)

Dolandırıcılık algılama sistemleri genelde iki katmanlıdır: birinci katman gerçek‑zamanlı skorlar ile düşük gecikme kararları sağlar (ör: anlık işlemi durdur), ikinci katman batch olarak gelişmiş modeller ile geniş analizler yapar ve geri dönük inceleme sağlar.

Real‑Time Reklam / Bidding (RTB)

Reklam dünyasında gerçek‑zamanlı inference milisaniyelerle ölçülür. Burada latency en kritik parametredir. Genelde model complexity düşük tutulur; hesaplama hızına göre daha sofistike modeller offline olarak eğitilip parametreleri online sisteme aktarılır.

Large Language Models (OpenAI, Anthropic)

LLM servisleri kullanıcı sorgularına gerçek‑zamanlı yanıt üretir. Ancak embedding hesaplama, fine‑tune işlemleri ve offline batch analizleri ayrı pipeline'larda yürütülür. Ayrıca token bazlı maliyet ve latency yönetimi önemli bir mühendislik problemidir.

5. Avantajlar ve Sınırlamalar

Batch — Avantajlar

• Donanım verimliliği: GPU/TPU’lar büyük batch'lerle daha ekonomik çalışır.
• Ölçeklenebilirlik: Büyük veri blokları çoklu düğümlerde kolayca paralelleştirilebilir.
• Basit hata yönetimi: Job retry, checkpoint, idempotency ile güvenli işleme.

Batch — Dezavantajlar

• Gecikme: Anlık karar gerektiren uygulamalar için uygun değil.
• Data freshness: Gerçek zamanlı sinyaller batch pencere süresince gecikmiş olur.

Real‑Time — Avantajlar

• Anında geri bildirim: Kullanıcı etkileşimini doğrudan etkiler.
• Güncel veri kullanımı: Son kullanıcı davranışlarına dayalı anlık kararlar.

Real‑Time — Dezavantajlar

• Yüksek operasyonel maliyet: Düşük latency için daha fazla kaynak gerekir.
• Uygulama karmaşıklığı: Feature consistency, autoscaling, cold start yönetimi gerekir.

6. Alternatifler ve Karşılaştırma

7. En İyi Pratikler

Production Hazırlığı

• Model registry ve metadata yönetimi kurun (MLflow, ModelDB veya özel çözüm).
• Canary rollout ve shadow traffic ile yeni versiyonları test edin.
• Reproducibility: Eğitim ortamı, veri snapshot ve dependency versiyonlarını tutun.

Performans Optimizasyonu

• Quantization (INT8/FP16) ve distillation ile latency düşürün.
• Operator fusion ve inference runtime optimizasyonlarını kullanın.
• Micro‑batching: Online katmanda küçük window ile batching yaparak throughput artırın ama latency SLA'sını koruyun.

Ölçeklenebilirlik ve Dayanıklılık

• Autoscaling kurallarını gerçek trafik paternleriyle test edin.
• Fallback stratejileri oluşturun (baseline model, cached prediction).
• Multi‑AZ ve multi‑region dağıtımı ile availability artırın.

Monitoring ve Observability

• Model metrikleri (AUC, accuracy), iş metrikleri (conversion), ve latency histogramlarını birlikte izleyin.
• Input distribution drift için continuous scoring ve alert kurun.
• Explainability: Kritik kararlar için counterfactual veya SHAP benzeri açıklama kanalları sağlayın.

8. Sık Yapılan Hatalar

• Training/Serving skew: Offline eğitimde kullanılan feature hesaplamalarının production'da birebir tekrarlanmaması ciddi hata nedenidir.
• Eksik observability: Model performansını sadece offline metriklere göre değerlendirmek, gerçek hayatta sürpriz sonuçlara yol açar.
• Cold start ihmali: Serverless veya scale‑to‑zero stratejilerinde warmup ve readiness stratejileri yoksa latency patlaması yaşanır.
• Monolitik serving: Tek bir servis üzerinden tüm model tiplerini sunmak yönetimsel zorluklar çıkarır; micro‑servis yaklaşımı çoğu zaman daha yönetilebilirdir.

9. Gelecek Trendler

Önümüzdeki yıllarda şu trendlerin etkili olacağını öngörüyoruz:

1. MaaS (Model as a Service): Çoklu tenant ve paylaşılan altyapı çözümleri yaygınlaşacak; serverless model serving olgunlaşacak.
2. Edge ve Federated Inference: Gizlilik ve düşük gecikme gereksinimleri sayesinde edge deployment artacak.
3. Otomasyon ve governance: Model lifecycle otomasyonu, lineage ve governance standartları endüstri standardı olacak.
4. LLM operasyonları: Büyük dil modellerinin maliyet/latency optimizasyonu, konteyner‑native hızlandırıcılar ve yerel caching çözümleri önem kazanacak.

Ek Bölümler

Sık Sorulan Sorular (FAQ)

1. Batch mi real‑time mı daha ucuz?

   Genelde batch daha ucuzdur çünkü donanım verimliliği yüksektir. Ancak uygulama ihtiyaçları maliyeti aşıyorsa (ör. anlık karar gereksinimi) real‑time zorunlu olabilir.

2. Hibrit mimari nasıl kurulur?

   Offline model ile aday havuzu oluşturun; online küçük modellerle re‑rank veya business rule kombine edin. Feature store ve model registry entegrasyonu şarttır.

3. Cold start nasıl azaltılır?

   Warmup containerlar, pre‑warmed instance, provisioned concurrency (serverless) ve lifecycle health check stratejileri kullanın.

4. Micro‑batching ne zaman kullanılır?

   Real‑time throughput'u artırmak istediğiniz ama latency hedefinizi çok bozmadan ek verim almak istediğiniz durumlarda.

5. Feature drift tespiti nasıl yapılır?

   Input distribution monitoring, statistical tests (KS test, KL divergence) ve model performance takibi ile drift tespit edilebilir.

6. Edge deployment'ın zorlukları nelerdir?

   Model güncelleme, cihaz heterojenliği, bellek ve compute sınırlamaları en önemli zorluklardır.

7. ONNX mi TensorRT mi tercih edilmeli?

   ONNX Runtime çok platformlu ve esnek; TensorRT yüksek performanslı NVIDIA‑specific optimizasyon sağlar. Donanım ve latency ihtiyaçlarına göre seçim yapın.

8. Model monitoring için hangi araçlar kullanılmalı?

   Prometheus/Grafana (metrik), ELK (log), Sentry (error), WhyLogs/Deequ (data quality) ve özel model monitoring araçları (Evidently, Fiddler) kombinasyonu etkili olur.

Anahtar Kavramlar

Latency

Tek bir isteğin tamamlanma süresi (ms).

Throughput

Birim zamanda işlenen istek veya örnek sayısı.

Feature Store

Training ve serving için tutarlı feature erişimi sağlayan sistem.

Model Registry

Model versiyonlama, metadata ve deployment yönetimi.

Canary Release

Yeni modelin sınırlı trafikle test edilmesi yöntemi.

Öğrenme Yol Haritası

1. Python, veri yapıları, SQL — veri ve model temelleri için.
2. ML kütüphaneleri: scikit‑learn, PyTorch, TensorFlow.
3. Model optimizasyon: ONNX, pruning, quantization, TensorRT.
4. MLOps araçları: MLflow, Feast, Airflow/Dagster, Kubernetes.
5. Serving: Triton, TorchServe, FastAPI, serverless yaklaşımlar.
6. Observability: Prometheus, Grafana, log ve trace toplama.
7. Pratik projeler: öneri sistemi, fraud detection, real‑time scoring pipeline.