Belajar MLOps - Multi-Model & Multi-Cloud

#Pendahuluan

Setelah episode 23 latensi ter-tuning, sekarang saatnya berpikir sebagai arsitek platform: banyak model, banyak tenant, mungkin banyak cloud. Satu model churn yang dideploy manual memang cukup — tetapi begitu sebuah organisasi punya puluhan model dari banyak tim, cara mereka di-deploy satu per satu berubah menjadi satu platform serving yang melayani semuanya.

Mengapa topik ini penting? Karena inilah garis pemisah antara "tim yang kebetulan punya model" dan "platform ML yang serius". Platform yang dirancang dengan baik membuat tim baru bisa deploy model dalam hitungan jam; yang dirancang buruk membuat setiap model menjadi proyek infrastruktur tersendiri. Episode ini membedah multi-tenancy, model router, dan multi-cloud.

#Kenapa Multi-Model

Kebutuhan multi-model muncul secara alami:

• Per tim — tim fraud, tim churn, tim recommendation, masing-masing dengan modelnya.
• Per use case — model yang sama dengan versi berbeda untuk region berbeda.
• Per latensi — model besar untuk akurasi, model kecil untuk kecepatan (episode 23).

Platform serving yang baik menyeragamkan: model di-deploy dengan cara yang sama, dipantau dengan cara yang sama, dan diberi resource yang diatur secara adil.

#Multi-Tenancy: Isolasi Antar Tim

Masalah inti multi-tenant adalah isolasi: satu tenant yang berperilaku buruk (traffic gila-gilaan, model bermasalah) tidak boleh merusak tenant lain. Di Kubernetes, isolasi dasar dibangun dari namespace, resource quota, dan RBAC.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-finance-quota
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    count/services: 20

Dengan quota, tenant finance tidak bisa mengonsumsi semua resource cluster. Lapisan berikutnya: kuota per model (berapa replica, berapa GPU), supaya satu model tidak mengkanibal resource model lain.

#Model Router & Gateway

Saat banyak model hidup berdampingan, kalian butuh router — lapisan yang memutuskan request ke model mana:

Tugas router:

• Routing berbasis identitas — tenant mana, model mana.
• Traffic split — canary dan blue-green di level platform (episode 10).
• Fallback — jika satu model down, request dialihkan ke model cadangan atau respons error yang rapi.
• Rate limiting per tenant — melindungi platform dari satu tenant yang boros.

#Multi-Cloud: Kapan, Kenapa, dan Harga yang Harus Dibayar

Multi-cloud menjanjikan: resiliency (satu cloud down, yang lain melayani), leverage harga regional, dan hindari lock-in. Tetapi ia juga mahal dalam kompleksitas: jaringan antar cloud, konsistensi data, dan duplikasi operasional.

Strategi yang realistis untuk kebanyakan tim:

1. Mulai single-cloud, multi-region — sebagian besar keuntungan resiliency didapat dari sini, dengan kompleksitas jauh lebih rendah.
2. Portabilitas dari awal — model dalam container dan format standar (ONNX, episode 23), config as code, sehingga pindah cloud bukan menulis ulang.
3. Registry terpusat — model registry satu-satunya sumber kebenaran, diakses semua cloud; hindari registry duplikat yang tidak sinkron.

#Desain Platform Serving

Arsitektur yang dirangkai dari semua episode sebelumnya:

┌─────────────┐   ┌──────────────┐   ┌───────────────┐
│ Client/API  │──►│ Model Router │──►│ Serving layer │
└─────────────┘   └──────────────┘   └───────┬───────┘
                        │                    │
                        ▼                    ▼
              ┌─────────────────┐   ┌──────────────────┐
              │ Model Registry  │   │ Observability    │
              │ (versi + alias) │   │ (latensi, drift) │
              └─────────────────┘   └──────────────────┘

Komponen kunci:

• Registry terpusat — semua model masuk satu registry dengan alias (champion, episode 11).
• Serving layer — KServe/Seldon (episode 17) atau managed platform (episode 16).
• Router — bisa Istio/Envoy atau gateway platform.
• Observability terpadu — satu dashboard untuk semua model dan tenant.

#Praktik: Desain Serving Platform

Checklist saat merancang platform:

• Setiap tenant punya namespace + quota + RBAC sendiri.
• Setiap model punya kuota resource dan batas rate tersendiri.
• Router punya fallback dan traffic split.
• Semua model di satu registry terpusat.
• Observability satu dashboard untuk semua tenant.
• Model dalam format portabel (container/ONNX) sejak awal.

#Common Pitfalls

• Tenant tidak terisolasi — satu model bermasalah merusak seluruh platform; isolasi dulu.
• Router tanpa fallback — satu model down berarti semua request gagal.
• Data berpindah lintas region tanpa cek regulasi — melanggar compliance (episode 15 & 19).
• Registry duplikat per cloud — versi tidak sinkron, rollback jadi tebak-tebakan.
• Multi-cloud sebelum multi-tenant — kompleksitas ganda tanpa manfaat yang jelas.

#Penutup

Pada episode 24 ini, kalian telah merancang platform serving multi-model.

Inti yang harus dibawa pulang:

• Platform serving menyatukan deploy, monitoring, dan resource untuk banyak model.
• Multi-tenancy dibangun dari namespace, quota, dan rate limit.
• Model router menangani identitas, canary, dan fallback.
• Multi-cloud dimulai dari portabilitas, bukan dari duplikasi.
• Selesaikan multi-tenant dulu, baru multi-cloud.

Di episode 25 selanjutnya kita akan membawa model keluar dari datacenter: MLOps untuk edge & IoT — deployment di perangkat, quantization untuk resource kecil, dan update model OTA. Sampai jumpa di episode 25!