MLflow 3 Pythonissa: Kokeilujen seuranta ja mallien tuotantokäyttö (2026)

Päivitetty: 11. syyskuuta 2026

MLflow 3 on avoimen lähdekoodin alusta ML-kokeilujen seurantaan, mallirekisterin hallintaan ja tuotantoonvientiin. Versio 3.x tuo mukanaan uuden LoggedModel-abstraktion, natiivin GenAI-arvioinnin sekä tiukemman integraation Unity Catalogiin. Olen käyttänyt MLflow'ta viimeiset viisi vuotta useassa tiimissä, ja versio 3 on ensimmäinen, joka aidosti auttaa myös LLM-tiimejä eikä pelkästään klassisia scikit-learn-putkia. Tämä opas käy läpi asennuksen, kokeiluseurannan, mallirekisterin, GenAI-arviointimoduulin ja tuotantoon viennin. Kaikki koodiesimerkein ja tuotantokokemuksen perusteella.

• MLflow 3.2 (elokuu 2026) tuo LoggedModel-API:n, joka korvaa vanhat run-artefaktit ensimmäisen luokan mallikohteilla omalla ID:llä ja versioinnilla.
• Natiivi GenAI-arviointi (mlflow.evaluate tyypille text) tukee RAG-, tool-use- ja hallusinaatiotarkastuksia ilman lisäkirjastoja.
• Unity Catalog on nyt oletustallennuspaikka tuotannon mallirekisterille. Filestore on suositeltu vain paikalliseen kehitykseen.
• MLflow Deployments Server reitittää LLM-kutsut palveluntarjoajakohtaisiin päätepisteisiin ja lisää nopeusrajoituksia sekä käyttökattoja.
• Autologiuntia tukevat scikit-learn, XGBoost, LightGBM, PyTorch, TensorFlow, transformers ja LangChain-agentit. Muista poistaa se käytöstä tuotantokoulutuksissa.
• Vaihtoehdot: Weights & Biases, Neptune.ai ja ClearML. MLflow voittaa yleensä hinnalla ja itse hostattavuudella.

Mikä on MLflow ja mitä uutta versiossa 3?

MLflow on avoimen lähdekoodin alusta, joka kattaa ML-elinkaaren neljä osa-aluetta: kokeilujen seurannan, mallirekisterin, projektiajastuksen (MLflow Projects) ja mallien tuotantoonviennin (MLflow Deployments). Alkuperäinen versio julkaistiin Databricksin toimesta vuonna 2018, ja projekti siirtyi Linux Foundationin AI & Data Foundationin alle vuonna 2024. Versio 3.0 julkaistiin marraskuussa 2025, ja tuoreimmassa 3.2-julkaisussa (elokuu 2026) on mukana LoggedModel-refaktorointi sekä laajennettu GenAI-arviointimoduuli. Yksityiskohtaiset muutoslokit löydät MLflow'n GitHub-julkaisusivulta.

No niin, sukelletaan siihen mikä oikeasti muuttui. Kolme merkittävää uudistusta versiossa 3 ovat:

• LoggedModel-API: Aikaisemmin mallit tallennettiin runin artefaktikansioon. LoggedModel tekee mallista ensimmäisen luokan kohteen, jolla on oma ID, versiot ja metatiedot (myös ilman rekisteröintiä).
• Natiivi GenAI-arviointi: mlflow.evaluate(model_type="text") laskee automaattisesti relevanssin, faithfulness-arvon, toksisuuden ja RAG-metriikat LLM-tuomarin avulla.
• Unity Catalog -integraatio: Mallien rekisteri tukee kolmiportaista nimeämistä (catalog.schema.model_name) ja pääsynhallintaa työtiloista riippumatta.

Näiden lisäksi Tracking Server sai uuden pluggable-lokikirjastorajapinnan, ja UI on kirjoitettu uudelleen React 19 -pohjalle. Kokemuksesta sanon, että 3.x:n asennuspaketti on selvästi kevyempi kuin 2.x:n, koska LangChain- ja LlamaIndex-riippuvuudet siirrettiin lisäpaketteihin (mlflow[genai], mlflow[langchain]). Tämä on merkittävää konttikuvien koon kannalta. Meidän Kubernetes-imagemme kutistui 1,2 GB:sta noin 480 MB:iin pelkästään päivittämällä. Ihan mukava sivuvaikutus.

Asennus ja MLflow'n arkkitehtuuri

Suositeltu asennustapa on virtuaaliympäristö uv:llä tai pip:llä. MLflow 3.2 vaatii Python 3.10+:n, ja versio 3.3 (arvioitu joulukuu 2026) pudottaa 3.9-tuen kokonaan. Katso viimeisimmät riippuvuudet MLflow'n virallisesta dokumentaatiosta.

# Perusinstallaatio kokeilun seurantaan
pip install mlflow==3.2.0

# GenAI-arviointi ja LLM-osiot
pip install "mlflow[genai]==3.2.0"

# Palvelinkomponentit tuotantoon (postgres, boto3, gunicorn)
pip install "mlflow[extras]==3.2.0"

MLflow'n peruskomponentit ovat:

• Tracking Server: HTTP-palvelin, joka kirjaa parametrit, metriikat, artefaktit ja LoggedModelit. Backend-tietokantana toimii oletuksena SQLite (paikallinen kehitys) tai Postgres/MySQL (tuotanto).
• Artefaktitallennus: S3, GCS, Azure Blob tai NFS. Suuret mallipainot tallennetaan tänne, ja Tracking DB:hen menevät vain viittaukset.
• Model Registry: mallin versiointi, ympäristöleimat (staging/production/champion/challenger) ja alias-järjestelmä 3.x:stä alkaen.
• Deployment: mlflow models serve tai mlflow deployments-CLI ulkoista palvelualustaa varten.

Tuotannossa kannattaa ajaa Tracking Server erillisessä konttiverkossa, jotta artefaktien pääsyoikeudet voidaan hallita IAM-roolein. Käytä konttikuvana virallista ghcr.io/mlflow/mlflow:v3.2.0:aa ja tallenna backend Postgresiin (14+). Meidän tiimimme setupissa Tracking DB:llä on omat replikat lukemiseen, mikä pitää UI:n responsiivisena vaikka koulutus-CI kirjoittaisi 1 000 runia tunnissa.

Miten MLflow-kokeiluja seurataan Pythonissa?

MLflow-kokeiluseuranta perustuu ajoihin (runs), jotka ryhmitellään kokeiluihin (experiments). Yksi ajo sisältää parametrit (log_param), metriikat (log_metric), artefaktit (log_artifact) ja mahdollisen mallin (log_model). Ajastinpalvelimen URI-osoitteen voi asettaa ympäristömuuttujalla MLFLOW_TRACKING_URI tai koodissa mlflow.set_tracking_uri-kutsulla.

import mlflow
import mlflow.sklearn
from sklearn.datasets import load_wine
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split
from sklearn.metrics import accuracy_score, f1_score

mlflow.set_tracking_uri("http://tracking.internal:5000")
mlflow.set_experiment("wine-classifier")

X, y = load_wine(return_X_y=True)
X_train, X_test, y_train, y_test = train_test_split(X, y, random_state=42)

with mlflow.start_run(run_name="rf-baseline") as run:
    params = {"n_estimators": 200, "max_depth": 8, "random_state": 42}
    mlflow.log_params(params)

    model = RandomForestClassifier(**params).fit(X_train, y_train)
    preds = model.predict(X_test)

    mlflow.log_metrics({
        "accuracy": accuracy_score(y_test, preds),
        "f1_macro": f1_score(y_test, preds, average="macro"),
    })

    # LoggedModel-abstraktio: ei enää pelkkä artefakti
    mlflow.sklearn.log_model(
        sk_model=model,
        name="rf_classifier",
        input_example=X_test[:2],
        registered_model_name="finance.prod.wine_classifier",
    )
    print(f"Run ID: {run.info.run_id}")

Käytännön vinkki: kutsu mlflow.autolog()-funktiota käynnistysvaiheessa, kun teet nopeita eksperimenttejä. Autologging kirjaa mallihyperparametrit, oppimiskäyrät ja input signature -metadatan automaattisesti scikit-learnille, XGBoostille, LightGBMille, PyTorchille, Kerakselle, transformersille ja LangChain-agenteille. Poista autologging käytöstä ennen tuotantokoulutusta. Se lisää 10–30 % viivettä isoihin ajoihin, ja voi kirjoittaa arkaluontoisia inputseja lokiin. Törmäsin tähän ihan itse viime kesänä, kun asiakastietoja lipsahti automaattisesti Tracking Serverin taulukkoon. Ei kivaa.

LoggedModel ja mallien rekisteröinti Unity Catalogiin

Ehkä merkittävin muutos MLflow 3:ssa on LoggedModel-abstraktio. Aikaisemmin malli tallennettiin runin artefakteihin, ja rekisteröinti loi viittauksen (pointer) tähän artefaktikansioon. Nyt malli on itsenäinen objekti, jolla on oma ID, aikaleima ja mahdolliset viittaukset yhdestä tai useasta runista. Tämä helpottaa mallipipelinejä, joissa lopputulos rakentuu useasta koulutusvaiheesta (esim. embedding-koulutus + classifier-fine-tune).

import mlflow
from mlflow import MlflowClient

client = MlflowClient(tracking_uri="databricks-uc")

# Rekisteröinti Unity Catalogiin: kolmiportainen nimi
model_uri = "runs:/<run_id>/rf_classifier"
mv = client.create_model_version(
    name="finance.prod.wine_classifier",
    source=model_uri,
    tags={"data_version": "2026-08-01", "framework": "sklearn"},
)

# Aliakset korvaavat vanhat 'stage'-arvot (Staging/Production)
client.set_registered_model_alias(
    name="finance.prod.wine_classifier",
    alias="champion",
    version=mv.version,
)

# Uusi malli tuotantoon otetaan käyttöön aliasten kautta
model = mlflow.pyfunc.load_model("models:/finance.prod.wine_classifier@champion")
print(model.predict(X_test[:5]))

Unity Catalog -rekisteri edellyttää Databricks-työtilaa, mutta mlflow-oss-rekisteri (Postgres-taustainen) tukee samat aliasrutiinit versiosta 3.0 lähtien. Aliaksen voi ohjata "champion", "challenger", "staging" tai omaan konventioon perustuvaan tagiin. Suosittelen välttämään vanhoja "stage"-arvoja, koska ne on merkitty poistuvaksi 3.4:ssä.

Jos olet aiemmin lukenut scikit-learn-putkien ja ColumnTransformerin oppaan, huomaat että sama Pipeline-objekti voidaan tallentaa LoggedModelina ja MLflow'n input signature tunnistaa esikäsittelyvaiheet automaattisesti. Tuotannossa tämä tarkoittaa, että samat StandardScaler- ja OneHotEncoder-parametrit siirtyvät koulutuksesta inferenssiin ilman erillistä serialisointia. Iso helpotus, kun putket menevät monimutkaisiksi.

GenAI-arviointi ja prompt-versiointi MLflow 3:ssa

Versio 3.0 lisäsi natiivin GenAI-arvioinnin, ja 3.2 tarkensi metriikkalaskennat. Erityisen hyödyllinen on prompt-versiointi: prompt-mallineet tallennetaan runin metadataksi, ja niistä muodostetaan LoggedPrompt-objekti, jota voi kutsua samaan tapaan kuin mallia. Lisää detaljeja on MLflow-blogin GenAI-artikkeleissa.

import mlflow
import pandas as pd

mlflow.set_experiment("rag-eval")

eval_df = pd.DataFrame({
    "inputs": [
        "Miten SEPA-tilisiirto tehdään?",
        "Mikä on IBAN-numero?",
    ],
    "ground_truth": [
        "Verkkopankissa: valitse SEPA, syötä IBAN ja summa.",
        "Kansainvälinen tilinumero, jossa on maakoodi ja tarkiste.",
    ],
    "predictions": [
        "SEPAn tekemiseksi kirjaudu verkkopankkiin ja täytä IBAN.",
        "IBAN on eurooppalainen pankkitilinumero-standardi.",
    ],
})

with mlflow.start_run():
    results = mlflow.evaluate(
        data=eval_df,
        predictions="predictions",
        targets="ground_truth",
        model_type="text",
        extra_metrics=[
            mlflow.metrics.genai.answer_relevance(),
            mlflow.metrics.genai.faithfulness(),
            mlflow.metrics.genai.toxicity(),
        ],
    )
    print(results.metrics)

Metriikkoja tukee LLM-tuomari (esim. GPT-5, Claude Sonnet 5 tai paikallinen vLLM). Konfiguroi tuomari MLFLOW_LLM_JUDGE-ympäristömuuttujalla, tai anna extra_metrics-listassa oma make_genai_metric-funktio. Meidän tiimissämme ajamme evaluoinnin CI-putken osana joka pull requestissa. Jos faithfulness putoaa alle 0,85, build kaatuu, eikä koodia yhdistetä main-haaraan. Rehellisesti sanottuna tämä on ainoa tapa, jonka olen löytänyt, joka estää regressioita RAG-systeemissä ilman jatkuvaa manuaalista tarkastelua.

Miten MLflow-malli viedään tuotantoon?

MLflow tarjoaa neljä pääasiallista tapaa viedä malli tuotantoon. Valinta riippuu latenssibudjetista ja hosting-alustasta. Käytännössä 90 % tapauksista päätyy Docker-kontin ja Kubernetesin yhdistelmään.

1. mlflow models serve: pikakäynnistys REST-palveluna FastAPI-taustalla. Sopii kehityksen sisäisiin testeihin.
2. mlflow models build-docker: luo Docker-kuvan, joka sisältää mallin, conda-ympäristön ja gunicorn-palvelimen.
3. SageMaker/Azure ML/Vertex AI -pluginit: pilvipalvelukohtaiset ajastimet, jotka lukevat suoraan mallirekisteristä.
4. MLflow Deployments Server (LLM-tarkoituksiin): reititys OpenAI-, Anthropic-, Cohere- ja itse hostatuille palvelimille.

# Rakenna kontti tuotantoon
mlflow models build-docker \
    --model-uri "models:/finance.prod.wine_classifier@champion" \
    --name wine-classifier:v42 \
    --enable-mlserver

# MLServer (ml-server) käyttää FastAPI:ta ja gRPC:tä;
# se on 25-40 % nopeampi kuin oletusarvoinen Flask-taustapalvelin.

docker run -p 8080:8080 wine-classifier:v42

curl -X POST http://localhost:8080/invocations \
    -H "Content-Type: application/json" \
    -d '{"inputs": [[12.8, 2.4, 2.3, 21.5, 88.0, 2.6, 2.5, 0.35, 1.5, 4.5, 1.0, 3.0, 990]]}'

Kun ajat MLflow-kontteja Kubernetesissa, käytä readinessProbe-koettimena /ping-päätepistettä ja livenessProbe-koettimena /health-päätepistettä. Aseta muistiraja (memory limit) vähintään 2× mallipainojen koko + 500 MB kirjastoille. SIGKILL 137 -virhe ilmenee tyypillisesti latauksen aikana, ei ennustamisen. Cost-per-prediction -laskelmassa muista, että gunicorn worker istuu idle-tilassa 90 % ajasta pienissä liikennemäärissä; harkitse Knative-tyylisiä scale-to-zero -asetuksia jos QPS on alle 5.

Yksityiskohtaisemman tarkastelun mallien esikäsittelystä ja pandas-integraatiosta löydät Pandas 3.0 -oppaastamme, koska MLflow'n input signature nojaa PyArrow-tyyppeihin, jotka ovat oletuksena Pandas 3:ssa.

MLflow vs Weights & Biases vs Neptune vs ClearML

Alla yhteenveto suurimmista kokeilujen seuranta -alustoista vuonna 2026. Kaikki tukevat Pythonia, mutta hinnoittelu, self-hosting ja LLM-tuki eroavat merkittävästi. Vertailu perustuu tammikuun 2026 vendorimateriaaleihin ja omiin tuotantoasennuksiini.

Ominaisuus	MLflow 3	Weights & Biases	Neptune.ai	ClearML
Lisenssi	Apache 2.0 (avoin)	Suljettu SaaS + rajoitettu OSS	Suljettu SaaS	Apache 2.0 (avoin)
Self-hosting	Kyllä, ilmainen	Kyllä, Enterprise-lisenssi	Kyllä, on-prem-paketti	Kyllä, ilmainen
Hinta 5 hengen tiimille	0 €/kk + infra	~50 € / käyttäjä / kk	~29 € / käyttäjä / kk	0 € / kk + infra
GenAI-arviointi	Natiivi (3.0+)	Weave (2024+)	Rajoitettu	Yhteensopiva
Mallirekisteri	Kyllä, UC-integraatio	Artifacts + Registry	Kyllä	Kyllä
Pipelines-orkestraattori	MLflow Projects (kevyt)	Sweeps	Ei natiivia	ClearML Pipelines
Skaalautuvuus (runs / kk)	Miljoonat (Postgres)	Miljoonat (SaaS)	Kymmenet tuhannet	Miljoonat

Käytännössä valitsen MLflow'n kolmesta syystä: se on itse hostattava, se on maksuton skaalautumisen ylärajaan asti, ja Databricksin ostettua projektin tuki on parantunut merkittävästi. W&B on kauniimpi UI:n suhteen, mutta 50 €/käyttäjä/kk kertyy nopeasti 20 hengen tiimissä. Neptune sopii yksittäisille tutkijoille ja pienille yksiköille. ClearML on hyvä valinta, jos tarvitset kevyttä orkestraattoria ilman erillistä Airflowia, mutta sen dokumentaatio jää selvästi jälkeen MLflow'sta. Suora vertailu ClearML:n omaan dokumentaatioportaaliin paljastaa nopeasti aukkoja, joita joutuu paikkaamaan GitHub-issueista.

Tuotannon sudenkuopat ja parhaat käytännöt

Olen kompastellut useaan kertaan seuraaviin. Kirjoitan ne tähän muistiin, jotta sinun ei tarvitse toistaa samoja virheitä.

1. Artefaktikoko räjähtää

Jokainen log_artifact tallentaa tiedoston. Jos ajat 5 000 hyperparametrisäätöä ja tallennat jokaisesta predictions.csv-tiedoston (50 MB), täytät 250 GB S3:sta viikossa. Käytä log_dict-funktiota pienille JSON-yhteenvedoille ja log_input-funktiota vain kertaalleen ajon alussa. S3-lifecycle-säännöt eivät myöskään ole ilmaisia; asetimme kerran 30 päivän glacier-transition-säännön ja säästimme 60 % kuukausikuluista.

2. Backend-tietokannan lukituksia

SQLite ei kestä yli 10 samanaikaista ajoa. Vaihda Postgres 14+:aan heti kun tuotannossa on enemmän kuin yksi työntekijä. Muista säätää max_connections-arvoon vähintään 200 ja luoda indeksit runs(experiment_id, start_time)-sarakkeille. UI:n hakukyselyt hidastuvat merkittävästi ilman näitä indeksejä, kun taulukossa on yli 100 000 riviä.

3. Autolog ei kirjaa kaikkia hyperparametreja

mlflow.autolog() ei kirjaa mukautettujen luokkien parametreja. Käytä mlflow.log_params(model.get_params())-kutsua koulutusvaiheen jälkeen, jotta parametrit todella tallentuvat kokonaan. Tämä on erityisen tärkeää sklearn-Pipeline-objekteille, joissa get_params() palauttaa myös alavaiheiden parametrit prefiksillä step__param.

4. Alias-törmäys CI-putkessa

Jos kaksi CI-runia asettaa yhtä aikaa "champion"-aliaksen, uudempi voittaa hiljaisesti ilman virheilmoitusta. Kärsin tästä ihan itse eräässä tuotantopromotoinnissa, ja väärä malli päätyi liikenteen kärkeen noin 20 minuutiksi. Käytä MlflowClient.set_registered_model_alias-metodin if_current_version-parametria (uusi 3.2:ssa) atomisen päivityksen varmistamiseen, tai lukitse promoottipäivitys Redis-lockilla.

5. Latenssibudjetti tuotannossa

MLflow'n oletuspalvelin (Flask + gunicorn 1 worker) tuottaa noin 40 ms p50-latenssin. Vaihda MLServeriin (--enable-mlserver) ja voit saavuttaa 12–18 ms p50. Kun latenssitakuu on alle 10 ms, kannattaa siirtyä TorchServeen tai NVIDIA Tritoniin. MLflow'n paketointi käy kummallakin läpi mlflow deployments-CLI:llä. On-call-näkökulmasta MLServer on turvallisin valinta, koska se palauttaa jäsennellyt virheet gRPC-status-koodilla, mikä auttaa hälytysten viritystä Prometheusissa.

Usein kysytyt kysymykset

Onko MLflow ilmainen käyttää?

Kyllä. MLflow'n koodikanta on lisensoitu Apache 2.0 -lisenssillä, ja voit ajaa Tracking Serveriä ja Model Registry -palvelua omalla palvelimellasi ilmaiseksi. Databricks tarjoaa maksullisen managed-version, mutta se on täysin valinnainen.

Miten MLflow eroaa Weights & Biases -työkalusta?

MLflow on avoimen lähdekoodin ja itse hostattava, kun taas W&B on suljettu SaaS-tuote. W&B:n UI on hiotumpi ja Sweeps-hyperparametrisäätö on vahvempi, mutta hinta nousee nopeasti tiimin kasvaessa. MLflow taas voittaa self-hosting- ja skaalautuvuusskenaarioissa.

Miten malli rekisteröidään MLflow-mallirekisteriin?

Yksinkertaisin tapa on antaa registered_model_name-parametri suoraan mlflow.sklearn.log_model-kutsulle. Vaihtoehtoisesti käytä MlflowClient.create_model_version-metodia, joka luo uuden version olemassa olevan mallin alle ja tukee myös Unity Catalog -kolmiportaista nimeämistä.

Mikä on LoggedModel MLflow 3:ssa?

LoggedModel on uusi ensimmäisen luokan objekti, joka korvaa vanhat run-artefaktit. Sillä on oma ID, versiot ja metatiedot, ja se voi viitata yhteen tai useaan runiin. Tämä yksinkertaistaa mallipipelineja ja mallien elinkaaren hallintaa etenkin monivaiheisissa koulutusprosesseissa.

Voiko MLflow'ta käyttää LLM-projekteissa?

Kyllä. Versiosta 3.0 alkaen MLflow tarjoaa natiivin GenAI-arvioinnin (mlflow.evaluate) sekä MLflow Deployments -komponentin, joka reitittää LLM-kutsut OpenAI-, Anthropic- ja itse hostatuille päätepisteille. Prompt-versiot tallentuvat LoggedPrompt-objekteina.