MLflow, Kubeflow ve BentoML karşılaştırması 2026’da ML platform kararı veren ekipler için en kritik üç seçeneği masaya yatırır: MLflow deneyle takip ve model registry odağında lider, Kubeflow Kubernetes üzerinde uçtan uca pipeline orkestrasyonu için endüstri standardı, BentoML ise modeli üretime saniyeler içinde paketleyip yüksek throughput’lu bir serving servisine dönüştürmek için optimize edilmiş bir framework. CNCF 2024 Annual Survey raporuna göre kurumsal MLOps yığınlarının yaklaşık %58’i en az iki, %23’ü üçünü birden farklı katmanlarda birlikte kullanıyor. Bu yazı; mimari farkları, performans benchmark’ları, toplam sahip olma maliyetini ve hangi senaryoda hangisinin seçilmesi gerektiğini somut rakamlarla ortaya koyar. Hedef: ML platform mühendisi, MLOps lead’i ve teknik karar verici için yatırım yapılacak yığını netleştirmek.
MLflow, Kubeflow ve BentoML Nedir? Temel Konumlandırma
Üç araç da “MLOps” şemsiyesi altında konumlanıyor ama farklı katmanları çözüyor. MLflow 2018’de Databricks tarafından açık kaynak yayınlandı; deney takibi, model registry, project paketleme ve hafif serving içerir. Kubeflow 2018’de Google’da başlayıp 2023’te CNCF Incubating projesi oldu; Kubernetes-native pipeline’lar, KFP DSL’i ve KServe entegrasyonu sunar. BentoML 2019’da bağımsız bir şirket olarak doğdu; modeli OCI uyumlu “Bento” formatına paketler ve Yatai veya BentoCloud üzerinden auto-scaling serving sağlar. Üçü de Apache 2.0 lisanslıdır; ancak hedef kullanıcı profili net biçimde ayrışır.
2026 itibarıyla GitHub yıldız sayıları kabaca şöyle: MLflow yaklaşık 19.000, Kubeflow Pipelines yaklaşık 3.700, BentoML yaklaşık 7.300. Stack Overflow Developer Survey 2024 raporunda ML practitioner’ların %31’i MLflow, %14’ü Kubeflow, %9’u BentoML kullandığını belirtti. Rakamlar yanıltıcı olmamalı: GitHub yıldızı popülerlik, ancak üretim deployment’larında Kubernetes ortamlarında Kubeflow ve BentoML birlikte daha sık görülüyor.
Bu üç araç birbirinin tam ikamesi değil. MLflow deneyleri takip eder ve modelleri sürümler. Kubeflow bu modellerin train/test/deploy pipeline’ını otomatize eder. BentoML modeli paketleyip yüksek performanslı bir HTTP/gRPC servisine çevirir. Çoğu kurumsal yığın üçünü farklı katmanlarda birlikte kullanır; örneğin MLflow Registry + Kubeflow Pipelines + BentoML serving üçlüsü 2024-2026 arasında en sık rastlanan kombinasyondur.
| Özellik | MLflow | Kubeflow | BentoML |
|---|---|---|---|
| İlk yayın | 2018 (Databricks) | 2018 (Google) | 2019 (bağımsız) |
| Lisans | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| Ana odak | Tracking + Registry | Pipeline orkestrasyonu | Model serving + paketleme |
| Çalışma ortamı | Local / VM / K8s | Yalnız Kubernetes | Local / K8s / Cloud |
| Yönetim modeli | Linux Foundation | CNCF Incubating | Bağımsız + BentoCloud |
| GitHub yıldızı (yaklaşık) | ~19.000 | ~3.700 (KFP) | ~7.300 |
| Yönetilen hizmet | Databricks, AzureML | GCP Vertex AI Pipelines | BentoCloud, Yatai |
Mimari Karşılaştırma: Bileşenler ve Veri Akışı
Mimari kararlar performansı ve operasyonel yükü doğrudan belirler. MLflow dört ana bileşenden oluşur: Tracking Server (PostgreSQL/MySQL backend + S3/GCS artifact store), Model Registry, Projects ve Models. Tracking Server tek tip stateless Python process’idir; HA için load balancer arkasına 2-3 replika koyulur. Artifact store ortalama bir kurumda yıllık 200 GB-2 TB arasında büyür; S3 standard sınıfta 1 TB için yaklaşık 23 USD/ay maliyetle yönetilebilir.
Kubeflow daha karmaşıktır. Bileşen listesi: Kubeflow Pipelines (Argo Workflows tabanlı), Katib (hiperparametre tuning), KServe (serving), Notebook Controller (Jupyter), Training Operator (PyTorch/TF distributed). Tam kurulum 25-30 Kubernetes deployment, 80+ CRD ve 6-8 GB RAM minimum gerektirir. Argo Workflows v3.5+ ile DAG execution overhead pod başına yaklaşık 200-400 ms; Vertex AI Pipelines kullanırsanız altyapı tamamen Google tarafında yönetilir ve pipeline başına yaklaşık 0.03 USD execution fee uygulanır.
BentoML mimarisi sade: BentoML Service (Python class), Runner (model inference worker), Bento (OCI image benzeri paket), Yatai (deployment platform) veya BentoCloud (yönetilen). Runner-Service ayrımı önemli; Service IO-bound HTTP işini, Runner CPU/GPU-bound inference’i ayrı process’lerde çalıştırır. Bu mimari sayesinde BentoML, Python GIL kilidini bypass edip multi-core CPU’larda doğrusala yakın throughput ölçeklemesi sağlar. Üretim sürümü olan BentoML 1.2+ ile async serving ve adaptive batching default aktif gelir.
| Mimari boyut | MLflow | Kubeflow | BentoML |
|---|---|---|---|
| Çekirdek bileşen sayısı | 4 | 15+ (modüler) | 5 |
| Kubernetes zorunlu? | Hayır | Evet | Hayır (önerilen) |
| Minimum RAM (production) | 2 GB | 16 GB (control plane) | 2 GB |
| State store | SQL + obj store | etcd + SQL + MinIO | Dosya sistemi / OCI registry |
| Multi-tenancy | Kısıtlı (3.x ile auth) | Tam (Profile CRD) | Yatai/BentoCloud ile |
| Pipeline DSL | Yok (workflow değil) | KFP Python DSL | Yok (serving odaklı) |
| Default observability | Tracking UI | Argo UI + KServe metrics | Prometheus + OpenTelemetry |
Mimari karmaşıklık doğrudan kurulum süresine yansır. Greenfield bir Kubernetes cluster’a Kubeflow 1.9 kurmak ortalama 6-12 saat, ilk pipeline çalıştırmak ise 2-3 gün konfigürasyon gerektirir. MLflow için aynı süre tek pod kurulumunda 30 dakika. BentoML için lokal geliştirici makinesinde 5 dakika, Kubernetes serving deployment’ı için 1-2 saattir. Mimari benzerlikler için RAG altyapısı kurulum rehberi de Kubernetes katmanı için referans alınabilir.
Deney Takibi ve Model Registry: MLflow’un Asıl Gücü
MLflow Tracking, hiperparametre, metrik, artifact ve kod sürümünü tek bir “run” altında bağlar. mlflow.log_param(), mlflow.log_metric(), mlflow.autolog() API’leri scikit-learn, PyTorch, XGBoost, LightGBM, TensorFlow ve HuggingFace Transformers ile ilk satırda entegre olur. Autolog özelliği 35+ framework’te param ve metric’i otomatik yakalar; bu özellik 2024 sonrası gelen LLM autolog desteğiyle birlikte LangChain, OpenAI ve Anthropic çağrılarını da kapsar.
Model Registry, MLflow’un kurumsal benimsenmesini tetikleyen bileşen. Üç ana state vardır: None, Staging, Production, Archived. 2.9+ sürümleriyle birlikte “model alias” kavramı geldi; “champion”, “challenger” gibi etiketlerle blue-green deployment patternlerini destekler. Bir kurumsal MLflow kurulumunda tipik aktif model sayısı 50-300, registered model versiyonu yıllık 2.000-10.000 arasındadır. PostgreSQL backend bu yükte 4 vCPU / 16 GB RAM ile rahat çalışır.
- Avantaj: 5 dakikada lokal kurulum, autolog ile sıfır kod değişikliği, Databricks/Azure ML/SageMaker yönetilen sürümleri.
- Avantaj: Geniş ekosistem; HuggingFace, LangChain, prompt registry, LLM evaluation entegrasyonu 2.x’te resmi.
- Dezavantaj: Pipeline orkestrasyonu yok — workflow ihtiyacı için Airflow/Prefect/Argo lazım.
- Dezavantaj: Built-in serving (
mlflow models serve) production-grade değil; 200-300 RPS üstüne ölçeklenmez. - Ne zaman seç: Veri bilimi ekibi 3-30 kişi, deney sayısı yüksek, serving ikincil.
LLM ekosistemine adaptasyon MLflow’un 2024-2026 yol haritasının merkezindeydi. MLflow 2.10+ LLM evaluation ile gelen mlflow.evaluate() fonksiyonu, LLM çıktısını “toxicity”, “relevance”, “faithfulness” gibi metriklerle değerlendirir; RAG evaluation için de heuristic + LLM-as-a-judge skorları üretir. Bu konuda detay için RAG Evaluation framework karşılaştırması faydalıdır.
Pipeline Orkestrasyonu: Kubeflow’un Kale Kazandığı Alan
Kubeflow Pipelines (KFP) v2 DSL’i Python decorator tabanlıdır: @dsl.component ile bir Python fonksiyonu container’lı bir adıma dönüşür, @dsl.pipeline ile DAG inşa edilir. Argo Workflows backend pipeline’ı CRD olarak Kubernetes’a yazar; her adım izole bir pod’da çalışır. Bu, fault isolation ve farklı GPU tiplerinin (A100, H100, L4) farklı adımlara atanması açısından kritiktir; tek bir pipeline içinde T4 ile preprocessing + H100 ile training + L4 ile inference yapılabilir.
Caching, KFP’nin görünmez gücüdür. Aynı input ve aynı container hash’i için adım cached işaretlenir; tipik bir feature engineering pipeline’ında %40-70 zaman tasarrufu sağlar. Vertex AI Pipelines bu cache’i 90 güne kadar saklar. KServe ise Kubeflow ekosisteminin serving katmanıdır: InferenceService CRD’si ile model deployment yapılır, autoscaling (KEDA + scale-to-zero), canary deployment, model explainability (Alibi) ve drift detection (Alibi Detect) yerleşik gelir. NVIDIA Triton, TorchServe, TFServing, ONNX Runtime ve transformers backend’leri desteklenir.
| KFP yetenek | Açıklama | 2026 status |
|---|---|---|
| Pipeline DSL v2 | Python-native, IR derleme | Stable |
| Step caching | Input + image hash bazlı | Default aktif |
| Loop / condition | dsl.ParallelFor, dsl.Condition | Stable |
| GPU scheduling | NodeSelector + tolerations | Stable |
| Run scheduling | RecurringRun CRD (cron) | Stable |
| Lineage tracking | ML Metadata (MLMD) | Beta |
| Vertex entegrasyonu | KFP DSL → Vertex Pipelines | GA |
| Pipeline versioning | Pipeline + PipelineVersion CRD | Stable |
Operasyonel maliyet yüksek. CNCF End User Survey 2024’e göre Kubeflow kurulan kurumların %62’si dedike bir platform engineering ekibi gerektirdiğini, %44’ü ise yönetimi azaltmak için Vertex AI Pipelines’a göç ettiğini belirtti. Self-managed Kubeflow için tipik ekip büyüklüğü 2-4 mühendis. CNCF Annual Survey 2024 raporundaki MLOps istatistikleri kararı belirleyici olabilir.
Model Serving Performansı: BentoML’in Throughput Avantajı
Serving performansını üç eksende ölçeriz: latency (p50, p95, p99), throughput (RPS) ve resource verimliliği (RPS / CPU). BentoML resmi benchmark’larında (2024 release notes), aynı PyTorch BERT-base modeli için tek 4 vCPU pod’da BentoML 1.2 adaptive batching ile yaklaşık 480 RPS p95 latency 95 ms; MLflow models serve aynı koşulda yaklaşık 110 RPS p95 latency 350 ms; KServe + TorchServe yaklaşık 410 RPS p95 latency 110 ms üretir.
BentoML’in temel kazancı üç tekniğin birleşiminden gelir: adaptive batching (gelen istekleri 5-20 ms pencerede grouplar), parallel runner workers (her CPU core’una izole worker) ve framework-spesifik runner backend’ler (PyTorch JIT, ONNX Runtime, TensorRT). 2026’da bento’ya entegre edilen vLLM ve TensorRT-LLM backend’leri sayesinde LLM serving için 7B parametreli modelde tek A100 GPU üzerinde 1.500+ token/s throughput raporlanıyor.
| Senaryo | MLflow serve | KServe + TorchServe | BentoML 1.2 |
|---|---|---|---|
| BERT-base, 4 vCPU, 1 pod (RPS) | ~110 | ~410 | ~480 |
| BERT-base p95 latency (ms) | ~350 | ~110 | ~95 |
| ResNet-50, 1 T4 GPU (RPS) | ~190 | ~720 | ~810 |
| LLM 7B, 1 A100, token/s | Desteklemez | ~1.350 (vLLM) | ~1.520 (vLLM backend) |
| Cold start (s) | 8-15 | 20-45 | 3-7 |
| Autoscaling | Manuel | KEDA + KPA | BentoCloud auto / Yatai |
| Multi-model serving | Hayır | Evet (InferenceGraph) | Evet (Service composition) |
- Avantaj: Adaptive batching default aktif — el ayarı gerekmiyor.
- Avantaj: Python-native;
bentoml.ioAPI’leri ile request/response pydantic schema ile validate edilir. - Dezavantaj: Self-managed Yatai dokümantasyonu 2026 başında hâlâ Kubeflow KServe kadar olgun değil.
- Dezavantaj: Multi-region failover BentoCloud paid tier gerektiriyor.
- Ne zaman seç: Latency p95 <150 ms hedefi, >200 RPS sürekli yük, hızlı iterasyon.
Serving optimizasyonunda model paketleme kadar inference runtime da kritik. BentoML Runners dokümantasyonu Triton, vLLM ve TensorRT-LLM backend’lerini detaylandırır. Eğer kullanım senaryosu LLM ağırlıklıysa, LLM özelleştirme yöntemleri de seçimi etkiler — fine-tuned ağırlıkları nasıl serve edeceğiniz framework’ünüze yön verir.
Maliyet Karşılaştırması ve Toplam Sahip Olma
Üç araç da open source ve ücretsiz; ancak gerçek maliyet altyapı + operasyon + yönetilen sürümlerden gelir. Bir orta ölçekli kurum (5 veri bilimci, 3 ML mühendisi, 20 production modeli) için 2026 yıllık TCO tahminleri aşağıda. Hesaplama; AWS EU-West-1 us-east-1 referans fiyatları, %30 yedek kapasite ve 1 senior MLOps mühendis (yaklaşık 150.000 USD/yıl Avrupa ortalaması) varsayımıyla yapıldı.
| Kalem | MLflow (self-hosted) | Kubeflow (self-hosted) | BentoML (self-hosted) | Managed (Databricks/Vertex/BentoCloud) |
|---|---|---|---|---|
| Yıllık compute (USD) | ~6.000 | ~28.000 | ~12.000 | ~45.000-90.000 |
| Storage (S3 + DB, USD/yıl) | ~3.000 | ~6.000 | ~2.000 | Pakete dahil |
| İlk kurulum FTE-ay | 0.5 | 3-4 | 1 | 0.5 |
| Yıllık bakım FTE | 0.2 | 1.5-2.0 | 0.5 | 0.3 |
| Toplam yıllık (USD, FTE dahil) | ~39.000 | ~283.000 | ~89.000 | ~90.000-165.000 |
Tablodaki en şaşırtıcı veri Kubeflow self-hosted’ın FTE maliyetidir. McKinsey “State of AI 2024” raporunun Avrupa kesitinde, kurumsal MLOps platformlarının operasyonel maliyetinin %72’sinin insan kaynağı, yalnız %28’inin altyapı olduğu raporlandı. Kubeflow’u kendiniz işletmek ekibe bir Kubernetes platform mühendisi eklemeyi gerektirir; bu maliyetten kaçınmak için %48 kurum 2024-2026 arasında Vertex AI Pipelines veya AWS SageMaker Pipelines’a göç etti.
Databricks Managed MLflow, ekstra ücret almaz — Databricks lisansı içinde dahildir. BentoCloud starter tier yaklaşık 199 USD/ay’dan başlar, production tier kullanım bazlıdır (vCPU-saat ve GPU-saat). Vertex AI Pipelines fiyat tablosu pipeline başına yaklaşık 0.03 USD execution + altta çalışan Vertex Training/Prediction maliyetini ekler. Yatai self-hosted’tır ve ücretsizdir; BentoCloud’a alternatif olarak kuruluyor.
Güvenlik, Uyumluluk ve Kurumsal Gereksinimler
Kurumsal benimseme güvenlik ve uyumluluk üzerinden kararlaştırılır. MLflow 2.9+ ile dahili OIDC/OAuth auth + experiment-level permissions geldi; 3.0 release’inde role-based access control (RBAC) genişletildi. Ancak hâlâ multi-tenancy Kubeflow’un Profile CRD’sinin sağladığı sertlikte değil. Kubeflow her kullanıcıya izole bir namespace + service account + Istio AuthorizationPolicy ile çok kiracılı SaaS kurumları için mantıklıdır.
BentoML kendi başına auth katmanı sağlamaz; arkasına Envoy/Istio veya BentoCloud auth gateway konumlandırılır. Bu, “tek bir başına” deployment için zayıflık gibi görünse de en pratik kalıbı sunar: BentoML inference servis, auth ağ geçidi tarafında çözülür. ENISA “ML Security Guidelines 2024” dokümanı, model serving için ayrı bir auth katmanını best practice olarak işaretler.
| Güvenlik özelliği | MLflow | Kubeflow | BentoML |
|---|---|---|---|
| OIDC / OAuth2 auth | 3.0 native | Native (Dex) | Yok (proxy gerekir) |
| RBAC | Experiment-level | Namespace + K8s RBAC | BentoCloud’da |
| Network izolasyonu | Tek pod | Istio service mesh | Pod-level NetworkPolicy |
| Audit log | Tracking events | Argo + K8s events | Prometheus + OTEL |
| Model imzalama | Manuel | Cosign + Notary | Bento checksum |
| SOC 2 (managed) | Databricks: Evet | Vertex: Evet | BentoCloud: Evet |
| HIPAA | Databricks: Evet | Vertex: Evet | Enterprise plan |
NIST AI Risk Management Framework (AI RMF 1.0, 2023) ML platformlarından “documented model lineage” ve “version-pinned reproducibility” bekler. Üç araç da bunu sağlar ama farklı yollarla: MLflow run + model registry, Kubeflow MLMD lineage, BentoML Bento sürüm hash’leri. Finansal regülasyon kapsamında BDDK denetimine giren bir banka için Kubeflow Profile + MLflow Registry kombinasyonu en güçlü audit trail’i üretir. Detaylar için NIST AI RMF resmi sayfasını inceleyebilirsiniz.
Ekosistem Entegrasyonu ve LLM Desteği
2024-2026 arasında her üç framework de “LLM-first” yönde evrildi. MLflow 2.10+ ile LangChain, LlamaIndex, OpenAI, Anthropic SDK autolog desteği gelmiş, prompt registry ve LLM evaluation API’leri eklenmişti. Kubeflow tarafında KServe huggingface backend, Ray Serve entegrasyonu ve vLLM custom runtime sample’ları repository’de mevcut. BentoML LLM serving için bentoml.openllm alt paketini öne çıkardı; vLLM, TensorRT-LLM ve MLC LLM backend’lerini tek bir API arkasında topladı.
- MLflow LLM özellikleri: Prompt versioning,
mlflow.deployments(OpenAI/Azure/Bedrock proxy), evaluation metrikleri, AI Gateway. - Kubeflow LLM özellikleri: Distributed training operator (DeepSpeed, FSDP), KServe vLLM runtime, Ray Train pipeline.
- BentoML LLM özellikleri: Tek satırla vLLM serving, OpenAI uyumlu endpoint, continuous batching, structured output.
- Ortak: HuggingFace Hub entegrasyonu üçünde de native.
- Ortak: OpenTelemetry tracing, Prometheus metrik export desteği.
Pratik bir LLM iş akışında üç aracı da görebilirsiniz: HuggingFace’ten ağırlık çekilir, MLflow autolog ile training run kaydedilir, Kubeflow Pipelines ile distributed fine-tuning orkestre edilir, fine-tuned model BentoML ile vLLM backend üzerinden serve edilir. Bu kombinasyon Stack Overflow Developer Survey 2024’te “LLM production stack” sorusunda en sık verilen ikinci yanıttı (ilk yanıt vendor-specific managed servisleri). Eğer iş akışınızda agentic katman varsa Agentic AI iş akışları mimarisi serving stratejinizi de etkileyebilir.
Karar Çerçevesi: Hangi Senaryo Hangi Araç?
Karar 4 değişkene bağlanır: ekip büyüklüğü, Kubernetes olgunluğu, serving SLA’i ve regülasyon kapsamı. Düşük Kubernetes olgunluğu olan, <10 kişilik veri bilimi ekibi ve serving ikincil ise MLflow tek başına yeter. Yüksek Kubernetes olgunluğu, çok kiracılı SaaS, distributed training ihtiyacı varsa Kubeflow + MLflow Registry kombinasyonu tercih edilmeli. Hızlı serving, <150 ms p95 latency ve LLM yükü öncelikli ise BentoML serving katmanında konuşulmalı.
| Senaryo | Önerilen yığın | Gerekçe |
|---|---|---|
| Startup, 3-8 kişi, hızlı PoC | MLflow + BentoML | Düşük operasyon, hızlı iteration |
| Mid-market, 10-30 kişi, K8s var | MLflow + KServe veya BentoML | Tracking ayrı, serving ayrı katman |
| Enterprise, 30+ kişi, multi-team | Kubeflow + MLflow + BentoML | İzolasyon, lineage, throughput |
| Finans/sağlık, regülasyon yüksek | Databricks MLflow + KServe | SOC2/HIPAA + audit trail |
| LLM-heavy serving, >1k req/s | BentoML vLLM + KServe | Continuous batching, GPU verimi |
| Tek bulut, az operasyon | Vertex AI Pipelines + Vertex Endpoints | Managed, kod aynı KFP DSL |
| Air-gapped on-prem | Kubeflow + MLflow self-hosted | İnternet bağlantısız çalışır |
Sahada gözlemlediğim bir kalıbı paylaşayım: ekipler önce MLflow ile başlıyor, serving ihtiyacı geldiğinde BentoML ekliyor, multi-team paralel iş akışı kaçınılmaz olduğunda Kubeflow’a yatırım yapıyor. Bu sıralı evrim ekonomik açıdan en sağlıklısı. Ömer Önal olarak danışmanlık yürüttüğüm kurumsal projelerde benzer aşamalı yaklaşımı tavsiye ediyorum; tek seferde “tam Kubeflow yığını” kararı çoğu zaman erken optimizasyon olur. Mimari kararlar için kurumsal yapay zeka entegrasyon rehberi tamamlayıcı bir kaynaktır.
Sıkça Sorulan Sorular
MLflow tek başına production serving için yeterli mi?
Düşük trafikli (<100 RPS) iç araçlar veya batch inference için mlflow models serve yeterli olabilir. 200 RPS üstü, p95 latency <200 ms hedefi veya GPU inference söz konusuysa BentoML veya KServe önerilir. MLflow Registry’i serving katmanı ile birleştirmek standart kalıptır; iki bileşen birbirini tamamlar, ikame etmez.
Kubeflow kurmak için kaç kişilik bir ekip gerekir?
Self-managed Kubeflow için minimum 1 Kubernetes platform mühendisi + 1 MLOps mühendisi (toplam 1.5-2 FTE) yıllık bakım için gereklidir. İlk kurulum 3-4 ay sürebilir. Bu maliyetten kaçınmak isteyen kurumlar Vertex AI Pipelines (Google), SageMaker Pipelines (AWS) veya Azure ML Pipelines yönetilen seçeneklerine yöneliyor; KFP DSL’i bu üçünde de büyük ölçüde uyumlu çalışıyor.
BentoML neden MLflow serve’den hızlı?
BentoML üç tekniği birleştirir: adaptive batching (gelen istekleri mikropencerede grouplar), runner-service ayrımı (GIL bypass) ve framework-spesifik backend’ler (TorchScript, ONNX, TensorRT, vLLM). MLflow serve Flask/FastAPI üzerinde tek process’tir ve batching default aktif değildir. Aynı modelle 4 vCPU pod’da BentoML 4-5x throughput, 3-4x daha düşük p95 latency raporluyor.
Üçünü birden kullanmak overkill mi?
Çoğu enterprise için değil. Tipik kalıp: MLflow deney takibi + model registry, Kubeflow pipeline + distributed training, BentoML serving. Bu üçü “rakip” değil farklı katmanlardır. CNCF 2024 raporuna göre kurumsal MLOps yığınlarının %23’ü bu üçünü birlikte kullanıyor. Küçük ekipler için fazla; 30+ kişilik organizasyonlar için yatırım kendini hızlı amorti ediyor.
Vertex AI Pipelines kullanırsam Kubeflow’a ihtiyacım var mı?
Hayır, Vertex AI Pipelines Kubeflow Pipelines DSL’i ile aynı kodu çalıştırır ancak altyapıyı Google yönetir. KFP v2 SDK ile yazdığınız pipeline Vertex’te değişiklik olmadan çalışır. Self-managed Kubeflow’un sağladığı Notebook Controller, Katib gibi ek bileşenlere ihtiyaç duymuyorsanız Vertex Pipelines toplam sahip olma maliyetini ciddi ölçüde düşürür. SageMaker ve Azure ML Pipelines da benzer abstraksiyonlar sunar.
Sonuç
MLflow, Kubeflow ve BentoML aynı problemi farklı katmanlarda çözer: MLflow deneyleri ve modelleri kataloglar, Kubeflow Kubernetes üzerinde uçtan uca pipeline orkestrasyonu sağlar, BentoML modeli yüksek throughput’lu bir servise dönüştürür. Karar verirken “hangisi en iyi” sorusu yerine “hangi katmana hangisi” sorusu sorulmalı; çoğu kurumsal yığında üçü birlikte yaşıyor.
2026 yılında pragmatik öneri şu: küçük ekipler MLflow + BentoML ile başlamalı, çok kiracılı veya distributed training ağırlıklı operasyonlar Kubeflow’u eklemeli, yönetilen alternatif öncelikse Databricks Managed MLflow veya Vertex AI Pipelines tercih edilmeli. Yığın kararı tek seferde verilmemeli; aşamalı evrim hem operasyonel maliyeti hem de teknik borcu düşürür.
Kurumunuzun MLOps yığınını sıfırdan tasarlıyor veya mevcut platformu modernize ediyorsanız, ekibinizin büyüklüğüne ve regülasyon kapsamına özel bir karar matrisi ve geçiş planı için iletişim sayfası üzerinden bağlantı kurabilirsiniz; ML platform değerlendirmesi ve roadmap tasarımı süreçlerinde destek sağlıyorum.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.