← Blog · Playbook · 10 min read
MLOps sering terdengar seperti kemewahan korporat. Padahal tim kecil pun butuh disiplin deploy, monitoring, dan rollback. Berikut versi yang realistis dan terjangkau.
A 30-minute scoping call. We listen, ask three questions, tell you if we can help.
Book a callAda satu pola yang berulang di banyak tim teknologi Indonesia: model machine learning yang bekerja sempurna di notebook seorang data scientist, lalu mati pelan-pelan setelah masuk produksi karena tidak ada yang memantau, tidak ada cara me-rollback, dan tidak ada catatan versi mana yang sebenarnya sedang melayani trafik. Ketika ditanya kenapa belum ada MLOps, jawabannya hampir selalu sama: "Tim kami terlalu kecil, MLOps itu untuk perusahaan dengan platform engineering sendiri."
Anggapan itu keliru. MLOps bukan soal membangun replika platform Uber atau Gojek. Ia adalah seperangkat disiplin minimum agar model Anda bisa di-deploy ulang dengan percaya diri, dipantau saat menurun, dan dikembalikan saat rusak. Tim tiga orang pun butuh itu, justru karena tim kecil tidak punya kemewahan untuk memadamkan kebakaran produksi setiap minggu. Artikel ini menyusun versi MLOps yang realistis, hemat, dan bisa Anda jalankan tanpa merekrut satu tim platform.
Sebelum membeli tooling, perlu jelas dulu masalah apa yang sedang dipecahkan. MLOps untuk tim kecil pada dasarnya menjawab empat pertanyaan operasional yang selalu muncul ketika model bertemu pengguna nyata:
Versi mana yang sedang berjalan? Saat akurasi tiba-tiba turun, Anda harus bisa menjawab "model v4, dilatih 12 Maret, dengan dataset commit abc123" dalam hitungan detik, bukan jam.
Bagaimana cara deploy ulang tanpa drama? Mengganti model seharusnya semudah dan seaman mengganti versi aplikasi web, lengkap dengan jalur balik.
Apakah model masih sehat? Data dunia nyata bergeser. Tanpa pemantauan, Anda baru tahu model rusak ketika pelanggan komplain atau pendapatan turun.
Bagaimana mengembalikan keadaan saat ada yang salah? Rollback yang cepat lebih berharga daripada pencegahan yang sempurna.
Empat hal inilah inti MLOps minimum viable. Sisanya—feature store terdistribusi, pipeline retraining otomatis penuh, A/B testing canggih—adalah pengoptimalan yang bisa menunggu sampai skala Anda benar-benar menuntutnya. Membangunnya terlalu dini hanya membuang waktu tim yang sudah tipis.
Tim kecil tidak gagal karena kekurangan tooling canggih. Mereka gagal karena tidak punya jawaban atas pertanyaan "versi mana yang berjalan dan bagaimana mengembalikannya".
Versioning adalah hal pertama yang harus benar, karena tanpa itu semua disiplin lain runtuh. Yang perlu Anda versi bukan hanya kode, melainkan tiga hal sekaligus: kode, data, dan model artifact.
Untuk kode, Git sudah cukup—tim Anda kemungkinan besar sudah memakainya. Yang sering terlewat adalah data dan model. Untuk data, DVC (Data Version Control) bekerja di atas Git dan menyimpan dataset besar di object storage seperti S3, Google Cloud Storage, atau bahkan MinIO yang Anda host sendiri. Dengan DVC, sebuah commit Git mereferensikan versi data yang persis, sehingga eksperimen menjadi dapat direproduksi. Ini krusial saat regulator atau auditor internal bertanya dataset mana yang dipakai melatih model yang membuat keputusan tertentu.
Untuk model artifact dan metadata eksperimen, MLflow adalah pilihan paling pragmatis. Ia open-source, bisa dijalankan di satu VM, dan memberi Anda model registry: tempat mencatat setiap model terlatih lengkap dengan metrik, parameter, dan tahap (staging, production, archived). MLflow Tracking mencatat eksperimen, sementara MLflow Model Registry menjadi sumber kebenaran tunggal tentang model mana yang boleh masuk produksi.
Aturan praktisnya sederhana: tidak ada model yang masuk produksi tanpa entri di registry. Disiplin ini murah, hanya butuh kebiasaan, dan langsung menyelesaikan pertanyaan "versi mana yang berjalan".
Banyak tim kecil terjebak memilih antara dua ekstrem: deploy manual yang rapuh (seorang engineer SSH ke server dan menyalin file model), atau platform deployment raksasa yang butuh berminggu-minggu untuk disetel. Ada jalan tengah yang nyaman.
Langkah pertama adalah membungkus model sebagai layanan HTTP—biasanya dengan FastAPI untuk Python—lalu mengemasnya ke dalam container Docker. Pendekatan ini langsung memberi banyak keuntungan: model jadi bahasa-agnostik bagi pengguna API, mudah di-scale horizontal, dan bisa di-deploy dengan tooling yang sama dengan aplikasi web Anda yang lain.
Untuk tim kecil di Indonesia, Anda tidak perlu Kubernetes sejak hari pertama. Platform seperti Google Cloud Run, AWS App Runner, atau bahkan satu instance dengan Docker Compose sudah cukup untuk melayani ribuan request per hari. Kubernetes baru masuk akal ketika Anda benar-benar punya banyak layanan dan butuh orkestrasi—bukan karena tutorial menyuruh demikian.
Pipeline CI/CD untuk model tidak harus rumit. GitHub Actions atau GitLab CI sudah memadai. Alur minimumnya:
Saat ada model baru dipromosikan ke "staging" di MLflow, pipeline membangun image Docker yang menyertakan model itu.
Pipeline menjalankan evaluation gate: serangkaian test pada golden dataset. Jika metrik turun di bawah ambang yang ditetapkan, deployment dibatalkan otomatis. Ini mencegah model yang lebih buruk masuk produksi hanya karena "lebih baru".
Bila lolos, image di-deploy ke lingkungan staging untuk smoke test, lalu dipromosikan ke produksi dengan persetujuan manual atau otomatis.
Evaluation gate inilah yang membedakan tim disiplin dari tim yang sekadar berharap. Sebuah model yang baru bukan berarti model yang lebih baik—dan satu-satunya cara mengetahuinya adalah menguji terhadap baseline sebelum trafik nyata menyentuhnya.
Realitas produksi adalah Anda akan salah, cepat atau lambat. Maka kemampuan memulihkan keadaan lebih berharga daripada ilusi rilis yang sempurna. Beberapa pola rilis yang terjangkau tim kecil:
Blue-green deployment: jalankan versi baru berdampingan dengan versi lama, alihkan trafik sekaligus, dan bila ada masalah, alihkan balik dalam hitungan detik. Mudah diterapkan di Cloud Run atau dengan dua target di load balancer.
Shadow mode: kirim trafik nyata ke model baru tetapi buang hasilnya (jangan tampilkan ke pengguna), lalu bandingkan diam-diam dengan model produksi. Ini cara teraman menguji model baru di data nyata tanpa risiko.
Canary bertahap: arahkan 5% trafik ke model baru, pantau metrik, lalu naikkan perlahan. Cukup dengan aturan weighted routing sederhana.
Yang non-negotiable: setiap rilis harus punya tombol rollback yang Anda yakin berfungsi. Uji rollback itu sesekali, sama seperti Anda menguji backup. Rollback yang tidak pernah dicoba sama saja dengan tidak punya rollback.
Inilah bagian yang paling sering diabaikan tim kecil, dan paling mahal saat diabaikan. Model bukan perangkat lunak biasa—ia tidak gagal dengan error 500 yang jelas. Ia menurun perlahan saat dunia berubah di luar data latihnya. Ada tiga lapis pemantauan yang perlu Anda pasang.
Ini pemantauan standar yang mungkin sudah Anda punya: latensi, throughput, error rate, penggunaan CPU/GPU dan memori. Prometheus dan Grafana, keduanya open-source, lebih dari cukup. Tujuannya memastikan layanan model hidup dan responsif.
Lapis ini khusus ML. Anda memantau apakah distribusi data masukan bergeser dari data latih (data drift), dan apakah distribusi prediksi model berubah (prediction drift). Contoh konkret: model scoring kredit yang dilatih pada data sebelum kenaikan harga BBM bisa melihat profil pemohon bergeser drastis sesudahnya. Tool seperti Evidently AI (open-source) bisa menghitung metrik drift ini dan memunculkan alert tanpa Anda menulis statistik dari nol.
Pada akhirnya yang penting adalah dampak. Apakah model rekomendasi masih menaikkan konversi? Apakah model deteksi fraud masih menangkap kasus tanpa membanjiri tim risk dengan false positive? Hubungkan output model ke metrik bisnis nyata, meski dengan lag, karena di sinilah penurunan paling penting akhirnya terlihat. Untuk banyak kasus, label ground truth baru datang belakangan—maka bangun feedback loop yang mengumpulkannya untuk evaluasi dan retraining nanti.
Jika digabung, tim kecil bisa membangun MLOps yang solid dengan tumpukan yang hampir seluruhnya open-source dan bisa di-host sendiri—penting untuk organisasi yang sensitif soal kedaulatan data atau anggaran dalam Rupiah yang ketat:
Versioning: Git + DVC + MLflow Model Registry
Packaging & deployment: Docker + FastAPI + Cloud Run / App Runner
CI/CD: GitHub Actions atau GitLab CI dengan evaluation gate
Monitoring: Prometheus + Grafana untuk operasional, Evidently AI untuk drift
Storage: object storage (S3/GCS) atau MinIO self-hosted
Yang menarik dari tumpukan ini: biaya bulanannya bisa di bawah jutaan Rupiah untuk beban kerja menengah, dan tidak ada satu pun komponen yang mengunci Anda ke vendor tertentu. Anda bisa mulai dengan MLflow dan monitoring dasar dulu, lalu menambah lapisan seiring kebutuhan—bukan memborong semuanya di awal.
Dua hal yang sering luput dari perhatian tim kecil justru menjadi penentu apakah sistem ML Anda berkelanjutan dalam jangka panjang: biaya dan reproduktibilitas. Keduanya saling terkait dan layak dipikirkan sejak awal, bukan setelah tagihan membengkak atau audit mengetuk pintu.
Soal biaya, model machine learning—terutama yang melibatkan inference GPU—bisa menjadi pos pengeluaran yang diam-diam membesar. Beberapa disiplin sederhana menjaganya tetap terkendali:
Pisahkan training dari serving. Training butuh sumber daya besar tetapi sesekali; serving butuh sumber daya kecil tetapi terus-menerus. Memakai infrastruktur yang sama untuk keduanya membuang uang. Gunakan instance on-demand atau spot untuk training, dan instance yang tepat-ukuran untuk serving.
Skala ke nol bila memungkinkan. Untuk model dengan trafik tidak konstan, platform seperti Cloud Run yang bisa menurunkan instance ke nol saat tidak ada permintaan menghemat biaya secara dramatis dibanding server yang menyala 24 jam.
Pantau biaya per prediksi. Jadikan biaya sebuah metrik yang dilacak, bukan kejutan di akhir bulan. Bila biaya per prediksi naik, Anda ingin tahu segera, bukan dari tagihan dalam Rupiah yang sudah membengkak.
Soal reproduktibilitas, kemampuan mereproduksi model yang persis—dengan kode, data, dan hyperparameter yang sama—bukan sekadar kerapian akademis. Di sektor yang diawasi seperti keuangan, regulator atau auditor internal bisa meminta Anda menunjukkan bagaimana sebuah model yang membuat keputusan tertentu dilatih. Tanpa versioning kode, data, dan artifact yang disiplin sejak awal, permintaan semacam itu bisa menjadi mimpi buruk berhari-hari. Kombinasi Git, DVC, dan MLflow yang sudah dibahas memberi Anda jejak audit ini hampir gratis sebagai produk sampingan dari disiplin harian.
Sebelum menyusun urutan implementasi, ada baiknya menyadari pola kegagalan yang berulang agar Anda bisa menghindarinya sejak awal:
Over-engineering di awal. Godaan terbesar adalah meniru arsitektur perusahaan raksasa. Tim kecil yang membangun Kubernetes, feature store terdistribusi, dan pipeline retraining otomatis penuh sebelum punya satu model stabil di produksi hampir selalu kehabisan napas sebelum memberi nilai. Bangun seperlunya.
Mengabaikan monitoring sampai terlambat. Banyak tim menunda monitoring karena "modelnya masih bagus". Padahal momen Anda paling butuh monitoring adalah saat model mulai diam-diam menurun—dan saat itu Anda tidak punya data historis untuk membandingkan. Pasang monitoring dasar dari hari pertama produksi.
Tidak menguji rollback. Rollback yang hanya ada di atas kertas adalah ilusi keamanan. Uji ia dalam kondisi terkendali sebelum Anda benar-benar membutuhkannya dalam kepanikan.
Mencampur tanggung jawab eksperimen dan produksi. Notebook eksperimen yang langsung di-deploy ke produksi adalah sumber bug yang tak berkesudahan. Pisahkan kode eksperimen dari kode produksi yang teruji, meski itu berarti sedikit duplikasi di awal.
Menyadari jebakan ini sama berharganya dengan mengetahui praktik terbaik—sering kali justru lebih, karena menghindari kesalahan besar lebih murah daripada memperbaikinya.
Jangan mencoba membangun semuanya sekaligus. Urutan yang terbukti bekerja untuk tim kecil:
1. Minggu 1-2: Pasang model registry (MLflow) dan disiplinkan bahwa setiap model produksi tercatat di sana. Ini memberi return tercepat. 2. Minggu 3-4: Bungkus model sebagai layanan terkontainer dan otomatiskan deployment dengan satu pipeline CI/CD plus evaluation gate. 3. Bulan kedua: Pasang monitoring operasional dan rollback yang teruji. Pastikan Anda bisa mengembalikan keadaan dengan percaya diri. 4. Bulan ketiga ke atas: Tambahkan drift detection dan feedback loop untuk retraining. Baru pertimbangkan otomasi retraining bila frekuensi perubahan menuntutnya.
Pendekatan bertahap ini memberi nilai di setiap langkah dan tidak pernah memaksa tim kecil membekukan pengembangan demi membangun infrastruktur.
MLOps untuk tim kecil bukan tentang membeli platform termahal, melainkan tentang menanamkan disiplin: setiap model tercatat, setiap rilis bisa dibatalkan, setiap model dipantau, dan setiap penurunan kualitas tertangkap sebelum pengguna merasakannya. Tumpukan open-source yang hemat sudah lebih dari cukup untuk mewujudkannya, asal diterapkan dengan urutan yang benar dan tanpa over-engineering.
Jika tim Anda sedang berjuang membawa model dari notebook ke produksi yang stabil—atau model yang sudah berjalan namun tidak terpantau dan menakutkan untuk disentuh—Sainskerta Solusi Nusantara bisa membantu merancang fondasi MLOps yang sesuai dengan skala dan anggaran Anda, bukan replika platform raksasa yang tidak Anda butuhkan. Kami mendampingi dari fase strategy hingga operate, memilih tooling yang realistis untuk konteks Indonesia. Jadwalkan sesi konsultasi singkat melalui halaman Kontak kami, dan mari petakan langkah pertama yang memberi dampak tercepat untuk tim Anda.
