Infrastruktur Versioning Model: Mengelola Artefak ML dalam Skala Besar

Diperbarui 11 Desember 2025

Pembaruan Desember 2025: MLflow 3.0 memperluas registry untuk AI generatif dan agen AI—menghubungkan model ke versi kode, konfigurasi prompt, evaluation run, dan metadata deployment. Versioning model kini melacak tidak hanya weight tetapi juga adapter yang di-fine-tune, template prompt, dan konfigurasi retrieval. LLM dengan weight ratusan GB membutuhkan infrastruktur khusus di luar Git.

MLflow 3.0 memperluas model registry-nya untuk menangani aplikasi AI generatif dan agen AI, menghubungkan model ke versi kode yang tepat, konfigurasi prompt, evaluation run, dan metadata deployment.¹ Evolusi ini mencerminkan pergeseran fundamental dalam arti "versioning model"—dari melacak file pickle sederhana menjadi mengelola sistem kompleks dengan berbagai adapter fine-tuned, template prompt, dan konfigurasi retrieval. Organisasi yang menjalankan AI produksi membutuhkan infrastruktur yang melakukan versioning tidak hanya weight, tetapi seluruh konteks yang diperlukan untuk mereproduksi dan men-deploy model secara andal.

Berbeda dengan versioning software tradisional, versioning model ML melibatkan pelacakan file biner berukuran besar, konfigurasi training yang kompleks, versi dataset, dan metrik evaluasi—semuanya sambil mempertahankan persyaratan reproducibility dan compliance.² Tantangan ini semakin kompleks untuk LLM di mana model fine-tuned berkembang pesat dan prompt engineering menambahkan lapisan artefak lain yang memerlukan version control.

Mengapa versioning model penting

Sistem ML produksi gagal secara diam-diam. Model mengalami degradasi seiring waktu, versi fine-tuned berkinerja buruk secara tidak terduga, dan tanpa versioning yang tepat, tim tidak dapat mengidentifikasi apa yang berubah atau rollback ke kondisi yang diketahui baik.

Tantangan versioning

Artefak biner: Weight model berkisar dari megabyte untuk ML klasik hingga ratusan gigabyte untuk large language model. Git tidak dapat menangani file-file ini secara efisien; infrastruktur khusus menjadi esensial.

Ledakan konfigurasi: Satu model melibatkan kode training, hyperparameter, data preprocessing, feature engineering, dan konfigurasi deployment. Perubahan apa pun berpotensi memengaruhi perilaku model.

Ketergantungan dataset: Kualitas model bergantung pada data training. Tanpa versioning dataset, mereproduksi model menjadi tidak mungkin bahkan dengan kode yang identik.

Keterkaitan evaluasi: Metrik kinerja pada test set tertentu menentukan keputusan deployment. Metrik tersebut harus terhubung secara permanen ke versi model.

Persyaratan bisnis

Reproducibility: Persyaratan regulasi di keuangan dan healthcare menuntut kemampuan untuk membuat ulang versi model yang tepat yang di-deploy pada titik waktu mana pun.³

Auditability: Compliance memerlukan penelusuran model yang di-deploy kembali ke data training, kode, dan pengambil keputusan yang menyetujui deployment.

Kemampuan rollback: Insiden produksi memerlukan pengembalian ke versi model sebelumnya dalam hitungan menit, bukan jam.

Kolaborasi: Beberapa data scientist yang bekerja pada model yang sama membutuhkan kepemilikan yang jelas dan resolusi konflik untuk artefak model.

Arsitektur model registry

Model registry berfungsi sebagai repositori pusat yang mengelola lifecycle model ML dari pengembangan hingga produksi:⁴

Komponen inti

Version control: Setiap versi model menerima identifier unik, biasanya menggabungkan nama model dengan semantic version (v1.2.3) atau identifier berbasis hash.

Penyimpanan metadata: Parameter training, metrik evaluasi, data lineage, dan riwayat deployment disimpan bersama artefak model.

Penyimpanan artefak: Weight model, file konfigurasi, dan aset terkait disimpan di object storage yang skalabel (S3, GCS, Azure Blob).

Lifecycle management: Model bertransisi melalui tahapan—development, staging, production, archived—dengan kontrol governance di setiap transisi.

Workflow registry

Training Job → Register Model → Staging Review → Production Deployment
     ↓              ↓               ↓                    ↓
  Metrics      Version ID      Approvals          Traffic Routing
  Logged       Generated       Recorded            Monitored

Registrasi: Pipeline training secara otomatis mendaftarkan model yang berhasil dengan metadata terkait: - Training run ID dan konteks eksperimen - Hyperparameter dan konfigurasi - Metrik evaluasi pada data held-out - Referensi versi data - Hash commit kode

Staging: Model kandidat menjalani validasi sebelum produksi: - Pengujian otomatis terhadap benchmark - Review manusia untuk aplikasi sensitif - A/B testing terhadap model produksi saat ini - Profiling kinerja untuk latensi inferensi

Promosi: Model yang disetujui di-deploy ke produksi: - Traffic secara bertahap beralih ke versi baru - Monitoring mendeteksi degradasi - Rollback dipicu jika metrik menurun

Perbandingan platform

MLflow

MLflow menyediakan model registry open-source paling komprehensif:⁵

Fitur Model Registry: - Store model terpusat dengan versioning dan aliasing - Pelacakan lineage (experiment → run → model) - Transisi stage (Staging, Production, Archived) - Anotasi dan penandaan metadata - REST API untuk akses programatik

Peningkatan MLflow 3.0: - Entitas LoggedModel menghubungkan model ke kode, prompt, dan evaluasi - Tracing yang ditingkatkan untuk aplikasi AI generatif - Dukungan agen untuk sistem AI kompleks - Databricks menyediakan versi enterprise terkelola

Contoh workflow:

import mlflow

# Log model selama training
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 0.001, "epochs": 10})
    mlflow.log_metrics({"accuracy": 0.95, "f1": 0.92})
    mlflow.pyfunc.log_model("model", python_model=trained_model)

# Daftarkan ke model registry
model_uri = f"runs:/{run_id}/model"
mlflow.register_model(model_uri, "fraud-detection-model")

# Promosikan ke produksi
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
    name="fraud-detection-model",
    version=3,
    stage="Production"
)

Terbaik untuk: Organisasi yang menginginkan kapabilitas MLOps komprehensif dengan fleksibilitas open-source.

Weights & Biases

W&B menekankan experiment tracking dengan versioning artefak yang kuat:⁶

Kapabilitas utama: - Experiment tracking dengan visualisasi yang kaya - Versioning artefak dengan grafik lineage - Model registry dengan alias (@champion, @production) - Fitur kolaborasi untuk workflow tim - Integrasi dengan framework ML utama

Versioning artefak:

import wandb

run = wandb.init(project="nlp-models")

# Log model sebagai artefak
artifact = wandb.Artifact("bert-classifier", type="model")
artifact.add_file("model.pt")
run.log_artifact(artifact)

# Tautkan ke registry dengan alias
run.link_artifact(artifact, "model-registry/bert-classifier",
                  aliases=["latest", "production"])

Pertimbangan: Arsitektur cloud-first memerlukan pengiriman data ke server eksternal, yang mungkin bertentangan dengan persyaratan privasi data yang ketat.

Terbaik untuk: Tim yang memprioritaskan experiment tracking dan kolaborasi dengan overhead setup minimal.

DVC (Data Version Control)

DVC memperluas Git untuk file besar dan dataset:⁷

Arsitektur: - Perintah mirip Git (dvc add, dvc push, dvc pull) - File metadata dilacak di Git, file besar di remote storage - Definisi pipeline untuk eksperimen yang dapat direproduksi - Berbagai backend storage (S3, GCS, Azure, SSH)

Perkembangan terkini: DVC bergabung dengan keluarga lakeFS, dengan lakeFS berfungsi sebagai standar enterprise untuk versioning data skala petabyte.

Contoh workflow:

# Tambahkan file model besar ke DVC
dvc add models/bert-finetuned.pt

# Commit metadata ke Git
git add models/bert-finetuned.pt.dvc .gitignore
git commit -m "Add fine-tuned BERT model v1.0"

# Push ke remote storage
dvc push

# Reproduksi dari commit mana pun
git checkout v1.0
dvc checkout

Terbaik untuk: Tim dengan workflow Git yang sudah ada yang menginginkan versioning data dan model yang ringan.

Registry cloud-native

Vertex AI Model Registry (Google Cloud):⁸ - Integrasi GCP native - Deployment langsung ke endpoint - Pelacakan lineage otomatis - Integrasi dengan Vertex AI Pipelines

Amazon SageMaker Model Registry: - Integrasi ekosistem AWS - Workflow persetujuan - Berbagi model lintas akun - Integrasi dengan SageMaker Pipelines

Azure ML Model Registry: - Integrasi Azure - Kompatibilitas MLflow - Deployment endpoint terkelola

Terbaik untuk: Organisasi yang berkomitmen pada penyedia cloud tertentu yang menginginkan integrasi native.

Pertimbangan khusus LLM

Large language model menghadirkan tantangan versioning unik di luar ML tradisional:⁹

Apa yang perlu di-version

Model dasar: Lacak model foundation mana (Llama 3.1-8B, GPT-4, Claude) yang menjadi titik awal.

Weight fine-tuned: Full fine-tuning menghasilkan file weight yang sepenuhnya baru; adapter LoRA menghasilkan file delta kecil yang mereferensikan model dasar.

Template prompt: System prompt, contoh few-shot, dan format instruksi secara signifikan memengaruhi perilaku model.

Konfigurasi retrieval: Sistem RAG memerlukan versioning embedding model, strategi chunking, dan parameter retrieval.

Semantic versioning untuk LLM

Adopsi semantic versioning untuk mengkomunikasikan signifikansi perubahan:¹⁰

Versi major (v2.0.0): - Model dasar berbeda - Perubahan arsitektur - Perubahan API yang breaking

Versi minor (v1.3.0): - Fine-tuning pada data baru - Peningkatan kinerja signifikan - Kapabilitas baru ditambahkan

Versi patch (v1.2.1): - Perbaikan bug - Optimisasi minor - Pembaruan konfigurasi

Manajemen adapter

LoRA dan QLoRA membuat file adapter yang berkembang pesat yang memerlukan organisasi sistematis:

base-model/
├── llama-3.1-8b/
│   └── v1.0.0/
│       ├── weights/
│       └── config.json
└── adapters/
    ├── customer-support-v1/
    │   ├── adapter_model.bin
    │   └── adapter_config.json
    ├── code-generation-v2/
    └── summarization-v1/

Strategi versioning adapter: - Version adapter secara independen dari model dasar - Dokumentasikan versi model dasar yang kompatibel - Lacak data training dan hyperparameter per adapter - Aktifkan perpindahan cepat antar adapter saat serving

Strategi deployment

Canary deployment

Rutekan persentase kecil traffic ke versi model baru sebelum rollout penuh:¹¹

# Konfigurasi canary Kubernetes
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: model-service
        subset: v1
      weight: 90
    - destination:
        host: model-service
        subset: v2
      weight: 10

Proses: 1. Deploy versi baru bersamaan dengan produksi 2. Rutekan 5-10% traffic ke versi baru 3. Monitor metrik (latensi, error rate, metrik bisnis) 4. Tingkatkan traffic secara bertahap jika metrik stabil 5. Selesaikan rollout atau rollback berdasarkan hasil

Tooling: Istio, Argo Rollouts, dan Flagger mengotomatisasi progressive delivery dengan rollback otomatis saat degradasi metrik.

A/B testing

Bandingkan versi model untuk mengukur dampak bisnis:¹²

Perbedaan utama dari canary: - Canary mendeteksi masalah (menit hingga jam) - A/B testing mengukur dampak (hari hingga minggu) - Signifikansi statistik diperlukan untuk kesimpulan A/B

Implementasi: - Hash user ID untuk routing yang konsisten - Lacak metrik konversi per varian - Jalankan hingga signifikansi statistik tercapai - Dokumentasikan hasil untuk referensi masa depan

Shadow deployment

Rutekan traffic produksi ke model baru tanpa menyajikan respons:

Manfaat: - Uji dengan pola traffic nyata - Bandingkan output tanpa dampak ke pengguna - Identifikasi edge case sebelum deployment

Implementasi: - Model produksi menyajikan respons - Model shadow memproses request yang sama - Output dibandingkan tetapi tidak dikembalikan ke pengguna - Diskrepansi memicu investigasi

Prosedur rollback

Setiap deployment membutuhkan kemampuan rollback:

Rollback segera:

# Rollback traffic routing
kubectl set image deployment/model-service model=model:v1.2.0

# Rollback feature flag
feature_flags.disable("new_model_v2")

Rollback berbasis registry: ```py

[Konten dipotong untuk terjemahan]