Model Versioning Infrastructuur: ML-Artefacten Beheren op Schaal

Bijgewerkt op 11 december 2025

December 2025 Update: MLflow 3.0 breidt registry uit voor generatieve AI en AI-agents—het verbinden van modellen met codeversies, promptconfiguraties, evaluatieruns en deployment-metadata. Model versioning volgt nu niet alleen gewichten maar ook fine-tuned adapters, prompttemplates en retrieval-configuraties. LLM's met honderden GB aan gewichten vereisen gespecialiseerde infrastructuur voorbij Git.

MLflow 3.0 heeft zijn model registry uitgebreid om generatieve AI-applicaties en AI-agents te ondersteunen, waarbij modellen worden verbonden met exacte codeversies, promptconfiguraties, evaluatieruns en deployment-metadata.¹ Deze evolutie weerspiegelt een fundamentele verschuiving in wat "model versioning" betekent—van het volgen van simpele pickle-bestanden naar het beheren van complexe systemen met meerdere fine-tuned adapters, prompttemplates en retrieval-configuraties. Organisaties die productie-AI draaien hebben infrastructuur nodig die niet alleen gewichten versioned, maar de volledige context die nodig is om modellen betrouwbaar te reproduceren en te deployen.

In tegenstelling tot traditionele softwareversioning omvat ML-model versioning het volgen van massieve binaire bestanden, complexe trainingsconfiguraties, datasetversies en evaluatiemetrieken—terwijl tegelijkertijd aan reproduceerbaarheid en compliance-eisen wordt voldaan.² De uitdaging wordt groter voor LLM's waar fine-tuned modellen snel prolifereren en prompt engineering een extra laag van artefacten toevoegt die versiebeheer vereisen.

Waarom model versioning ertoe doet

Productie-ML-systemen falen stilletjes. Modellen degraderen in de loop van de tijd, fine-tuned versies presteren onverwacht slecht, en zonder goede versioning kunnen teams niet identificeren wat er is veranderd of terugdraaien naar bekende werkende states.

De versioning-uitdaging

Binaire artefacten: Modelgewichten variëren van megabytes voor klassieke ML tot honderden gigabytes voor large language models. Git kan deze bestanden niet efficiënt verwerken; gespecialiseerde infrastructuur wordt essentieel.

Configuratie-explosie: Een enkel model omvat trainingscode, hyperparameters, datapreprocessing, feature engineering en deploymentconfiguratie. Elke wijziging beïnvloedt potentieel het modelgedrag.

Dataset-afhankelijkheid: Modelkwaliteit hangt af van trainingsdata. Zonder dataset versioning wordt het reproduceren van een model onmogelijk, zelfs met identieke code.

Evaluatiekoppeling: Prestatiemetrieken op specifieke testsets bepalen deploymentbeslissingen. Die metrieken moeten permanent gekoppeld zijn aan modelversies.

Bedrijfsvereisten

Reproduceerbaarheid: Regelgevingsvereisten in financiën en gezondheidszorg eisen de mogelijkheid om exacte modelversies te recreëren die op elk moment zijn gedeployed.³

Controleerbaarheid: Compliance vereist het traceren van gedeployde modellen terug naar trainingsdata, code en besluitvormers die deployment hebben goedgekeurd.

Rollback-mogelijkheid: Productie-incidenten vereisen het terugdraaien naar eerdere modelversies binnen minuten, niet uren.

Samenwerking: Meerdere data scientists die aan hetzelfde model werken hebben duidelijk eigenaarschap nodig en conflictoplossing voor modelartefacten.

Model registry-architectuur

Een model registry dient als de centrale repository die de lifecycle van ML-modellen beheert van ontwikkeling tot productie:⁴

Kerncomponenten

Versiebeheer: Elke modelversie krijgt een unieke identifier, typisch een combinatie van modelnaam met semantische versie (v1.2.3) of hash-gebaseerde identifiers.

Metadata-opslag: Trainingsparameters, evaluatiemetrieken, data lineage en deploymentgeschiedenis worden naast modelartefacten opgeslagen.

Artefactopslag: Modelgewichten, configuratiebestanden en gerelateerde assets worden opgeslagen in schaalbare object storage (S3, GCS, Azure Blob).

Lifecycle management: Modellen doorlopen fases—development, staging, productie, gearchiveerd—met governance-controles bij elke transitie.

Registry-workflow

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

Registratie: Trainingspipelines registreren automatisch succesvolle modellen met bijbehorende metadata: - Training run ID en experiment-context - Hyperparameters en configuratie - Evaluatiemetrieken op held-out data - Dataversiereferenties - Code commit hash

Staging: Kandidaatmodellen ondergaan validatie vóór productie: - Geautomatiseerde tests tegen benchmarks - Menselijke review voor gevoelige applicaties - A/B-testing tegen huidig productiemodel - Performance profiling voor inference-latency

Promotie: Goedgekeurde modellen worden naar productie gedeployed: - Verkeer verschuift geleidelijk naar nieuwe versie - Monitoring detecteert degradatie - Rollback wordt getriggerd als metrieken verslechteren

Platformvergelijking

MLflow

MLflow biedt de meest uitgebreide open-source model registry:⁵

Model Registry-features: - Gecentraliseerde modelopslag met versioning en aliasing - Lineage tracking (experiment → run → model) - Fase-transities (Staging, Production, Archived) - Annotaties en metadata-tagging - REST API voor programmatische toegang

MLflow 3.0-verbeteringen: - LoggedModel-entiteit verbindt modellen met code, prompts en evaluaties - Verbeterde tracing voor generatieve AI-applicaties - Agent-ondersteuning voor complexe AI-systemen - Databricks biedt managed enterprise-versie

Voorbeeldworkflow:

import mlflow

# Log model during 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)

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

# Promote to production
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
    name="fraud-detection-model",
    version=3,
    stage="Production"
)

Beste voor: Organisaties die uitgebreide MLOps-mogelijkheden willen met open-source flexibiliteit.

Weights & Biases

W&B legt nadruk op experiment tracking met sterke artefact versioning:⁶

Belangrijkste mogelijkheden: - Experiment tracking met rijke visualisatie - Artefact versioning met lineage-grafen - Model registry met aliassen (@champion, @production) - Samenwerkingsfeatures voor teamworkflows - Integratie met belangrijke ML-frameworks

Artefact versioning:

import wandb

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

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

# Link to registry with alias
run.link_artifact(artifact, "model-registry/bert-classifier",
                  aliases=["latest", "production"])

Overwegingen: Cloud-first architectuur vereist het verzenden van data naar externe servers, wat kan conflicteren met strikte dataprivacy-eisen.

Beste voor: Teams die prioriteit geven aan experiment tracking en samenwerking met minimale setup-overhead.

DVC (Data Version Control)

DVC breidt Git uit voor grote bestanden en datasets:⁷

Architectuur: - Git-achtige commando's (dvc add, dvc push, dvc pull) - Metadatabestanden worden in Git gevolgd, grote bestanden in remote storage - Pipeline-definities voor reproduceerbare experimenten - Meerdere storage backends (S3, GCS, Azure, SSH)

Recente ontwikkeling: DVC is toegetreden tot de lakeFS-familie, waarbij lakeFS dient als enterprise-standaard voor petabyte-schaal data versioning.

Voorbeeldworkflow:

# Add large model file to DVC
dvc add models/bert-finetuned.pt

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

# Push to remote storage
dvc push

# Reproduce from any commit
git checkout v1.0
dvc checkout

Beste voor: Teams met bestaande Git-workflows die lichtgewicht data- en model versioning willen.

Cloud-native registries

Vertex AI Model Registry (Google Cloud):⁸ - Native GCP-integratie - Directe deployment naar endpoints - Automatische lineage tracking - Integratie met Vertex AI Pipelines

Amazon SageMaker Model Registry: - AWS-ecosysteemintegratie - Goedkeuringsworkflows - Cross-account model sharing - Integratie met SageMaker Pipelines

Azure ML Model Registry: - Azure-integratie - MLflow-compatibiliteit - Managed endpoints deployment

Beste voor: Organisaties die toegewijd zijn aan specifieke cloudproviders en native integratie willen.

LLM-specifieke overwegingen

Large language models presenteren unieke versioning-uitdagingen voorbij traditionele ML:⁹

Wat te versionen

Basismodellen: Volg welk foundation model (Llama 3.1-8B, GPT-4, Claude) als startpunt dient.

Fine-tuned gewichten: Volledige fine-tuning produceert volledig nieuwe gewichtsbestanden; LoRA-adapters produceren kleine delta-bestanden die verwijzen naar basismodellen.

Prompttemplates: Systeemprompts, few-shot voorbeelden en instructieformaten beïnvloeden het modelgedrag significant.

Retrieval-configuraties: RAG-systemen vereisen versioning van embedding-modellen, chunking-strategieën en retrieval-parameters.

Semantische versioning voor LLM's

Adopteer semantische versioning om de significantie van wijzigingen te communiceren:¹⁰

Major versie (v2.0.0): - Ander basismodel - Architectuurwijzigingen - Breaking API-wijzigingen

Minor versie (v1.3.0): - Fine-tuning op nieuwe data - Significante prestatieverbeteringen - Nieuwe mogelijkheden toegevoegd

Patch versie (v1.2.1): - Bugfixes - Kleine optimalisaties - Configuratie-updates

Adapter management

LoRA en QLoRA creëren prolifererende adapterbestanden die systematische organisatie vereisen:

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/

Adapter versioning-strategie: - Version adapters onafhankelijk van basismodellen - Documenteer compatibele basismodelversies - Volg trainingsdata en hyperparameters per adapter - Maak snel wisselen tussen adapters mogelijk in serving

Deploymentstrategieën

Canary deployments

Route een klein verkeerspercentage naar een nieuwe modelversie vóór volledige uitrol:¹¹

# Kubernetes canary configuration
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

Proces: 1. Deploy nieuwe versie naast productie 2. Route 5-10% van verkeer naar nieuwe versie 3. Monitor metrieken (latency, foutpercentage, business metrics) 4. Verhoog verkeer geleidelijk als metrieken standhouden 5. Voltooi uitrol of rollback op basis van resultaten

Tooling: Istio, Argo Rollouts en Flagger automatiseren progressive delivery met automatische rollback bij metriekdegradatie.

A/B-testing

Vergelijk modelversies om business impact te meten:¹²

Belangrijkste verschillen met canary: - Canary detecteert problemen (minuten tot uren) - A/B-testing meet impact (dagen tot weken) - Statistische significantie vereist voor A/B-conclusies

Implementatie: - Hash user ID's voor consistente routing - Volg conversiemetrieken per variant - Run totdat statistische significantie is bereikt - Documenteer resultaten voor toekomstige referentie

Shadow deployment

Route productieverkeer naar nieuw model zonder responses te serveren:

Voordelen: - Test met echte verkeerspatronen - Vergelijk outputs zonder gebruikersimpact - Identificeer edge cases vóór deployment

Implementatie: - Productiemodel serveert responses - Shadow-model verwerkt dezelfde requests - Outputs worden vergeleken maar niet aan gebruikers geretourneerd - Discrepanties triggeren onderzoek

Rollback-procedures

Elke deployment heeft rollback-mogelijkheid nodig:

Onmiddellijke rollback:

# Traffic routing rollback
kubectl set image deployment/model-service model=model:v1.2.0

# Feature flag rollback
feature_flags.disable("new_model_v2")

Registry-gebaseerde rollback: ```py

[Content truncated for translation]