MLflow 3.0 v Pythonu 2026: Sledování ML experimentů a modelový registr

Aktualizováno: 15. července 2026

MLflow 3.0 je open-source platforma pro správu celého životního cyklu strojového učení v Pythonu, od sledování experimentů, přes verzování modelů v registru, až po tracing generativní AI a nasazení do produkce. Vydání MLflow 3 v červnu 2025 zavedlo novou entitu LoggedModel, modul mlflow.genai pro observabilitu LLM aplikací a nativní podporu UV. V tomhle průvodci vás krok za krokem provedu instalací, sledováním experimentů, prací s Model Registry a produkčními vzory, které používám v každém svém ML projektu.

• MLflow 3.0 (vydání 06/2025, aktuální verze 3.9.0) přináší entitu LoggedModel jako first-class citizen. Modely jsou nyní nezávislé na běhu (run) a mají vlastní verzování napříč experimenty.
• Modul mlflow.genai poskytuje tracing, hodnocení a monitoring pro GenAI aplikace s autologgingem pro 20+ frameworků (OpenAI, LangChain, LlamaIndex, Anthropic).
• Autologging zaznamená hyperparametry, metriky i model bez jediného řádku manuálního kódu. Stačí napsat mlflow.autolog() před tréninkem.
• Model Registry s aliasy (models:/nazev@champion) nahrazuje deprecated stage-based transitions a umožňuje bezpečné A/B nasazení bez změn v deployment kódu.
• Integrace s Optunou pro ladění hyperparametrů a s FastAPI pro serving vytváří kompletní produkční MLOps pipeline v čistém Pythonu.
• MLflow má přes 30 milionů měsíčních stažení a je nejrozšířenější open-source MLOps platformou, bez vendor lock-inu na Databricks.

Co je MLflow a k čemu v roce 2026 slouží

MLflow je open-source platforma pro správu životního cyklu strojového učení, kterou původně vytvořil tým Databricks a v roce 2018 uvolnil pod Apache 2.0 licencí. V praxi řeší tři fundamentální problémy, které trápí každý ML tým: (1) nereprodukovatelnost experimentů, (2) chaos při porovnávání desítek modelů a (3) nejasnou cestu od trénovacího notebooku po produkční endpoint. Za sedm let se z něj stala de facto standardní vrstva MLOps, s více než 30 miliony měsíčních stažení a přispěvateli z 850+ organizací.

Historicky se MLflow skládá ze čtyř komponent: Tracking (logování běhů), Projects (reprodukovatelné běhy), Models (formát pro serializaci) a Model Registry (centrální katalog verzí). Vydání 3.0 z června 2025 přidalo pátou vrstvu, GenAI observabilitu, a redesignovalo tracking okolo entity LoggedModel. Detailní přehled najdete v oficiálních MLflow 3 release notes.

Kdy MLflow nasadit? V okamžiku, kdy si přestanete pamatovat, který notebook produkoval model, který právě běží v produkci. To v mé zkušenosti nastává přibližně po pátém trénovacím experimentu, vždycky. Pro solo data science skripty stačí SQLite backend a lokální souborový systém. Pro tým doporučuji PostgreSQL tracking store a S3/MinIO pro artefakty.

Instalace MLflow 3.0 a první experiment

MLflow 3 vyžaduje Python 3.10+ (od verze 3.2 je oficiálně podporován i Python 3.14). Doporučuji izolované prostředí. V roce 2026 sáhnu vždy po uv, protože MLflow 3 má nativní podporu pro UV lockfile při inferenci závislostí modelu:

uv venv .venv
source .venv/bin/activate
uv pip install "mlflow>=3.9,<4" scikit-learn pandas

Pro plnou GenAI výbavu (tracing, evaluace LLM, prompt registry) použijte mlflow[genai]. Základní ověření instalace:

import mlflow
print(mlflow.__version__)  # 3.9.0 nebo vyšší

Teď spustíme lokální tracking server. MLflow poskytuje jak Python API, tak webové UI dostupné na http://127.0.0.1:5000:

mlflow server --host 127.0.0.1 --port 5000 \
  --backend-store-uri sqlite:///mlflow.db \
  --default-artifact-root ./mlruns

Backend store (SQLite/PostgreSQL) uchovává metadata, tedy parametry, metriky a tagy. Artifact root (lokální disk, S3, GCS) uchovává samotné modely a artefakty. Pozor: pro použití Model Registry musíte mít databázový backend. Souborový store ho nepodporuje.

Sledování ML experimentů: parametry, metriky, artefakty

Několik termínů, které je nutné pojmenovat dřív, než začneme kódovat. Experiment je pojmenovaný kontejner pro sadu souvisejících běhů (například „fraud-detection-v2"). Run (běh) je jedno spuštění tréninkového kódu, zachytává parametry, metriky, tagy a artefakty. Artefakt je libovolný soubor, typicky model, konfusní matice, feature importance plot nebo HTML report.

Minimální plnohodnotný běh s scikit-learn:

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://127.0.0.1:5000")
mlflow.set_experiment("wine-classification")

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

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_metric("accuracy", accuracy_score(y_test, preds))
    mlflow.log_metric("f1_macro", f1_score(y_test, preds, average="macro"))

    mlflow.sklearn.log_model(
        sk_model=model,
        name="model",
        input_example=X_train.head(3),
        registered_model_name="wine-rf",
    )
    print(f"Run ID: {run.info.run_id}")

Klíčových je pár detailů. Parametr input_example uloží signaturu (MLflow z něj odvodí schema vstupů a výstupů). Bez signatury vám mlflow models serve spadne na produkci na prvním špatně typovaném requestu. Honestly, tohle je bug, na který jsem narazil hned v prvním nasazení a od té doby signaturu neopomínám nikdy. Argument registered_model_name okamžitě zaregistruje model v Registry a vytvoří novou verzi, pokud model už existuje. To je vzor, který doporučuji: vždy registrovat, i experimentální běhy. Filtrovat produkční verze budete přes aliasy, ne mazáním.

Autologging: automatické sledování bez psaní kódu

Autologging je funkce, díky které si MLflow zaslouží místo ve vaší stack. Jediný řádek mlflow.autolog() automaticky zaznamená hyperparametry, trénovací metriky, feature importance, konfusní matici a serializuje model. Podporuje scikit-learn, XGBoost, LightGBM, PyTorch, TensorFlow/Keras, Spark ML, Optuna a další, bez psaní jediného log_param.

import mlflow
from sklearn.ensemble import GradientBoostingClassifier

mlflow.set_experiment("wine-autolog")
mlflow.autolog()  # zapne vše automaticky

with mlflow.start_run():
    model = GradientBoostingClassifier(n_estimators=300, learning_rate=0.05)
    model.fit(X_train, y_train)
    # metriky a model se logují automaticky

Pod kapotou MLflow monkey-patchuje fit() metody knihoven a wrappuje je do log_* volání. Můžete i selektivně. Volání mlflow.sklearn.autolog(log_input_examples=True, log_model_signatures=True, silent=True) zapne autolog jen pro scikit-learn a přidá signatury. Pro produkční pipeline kombinuji autolog s manuálním logováním doménových metrik (například revenue_uplift ze simulace), které framework sám neumí spočítat.

Model Registry: verzování a aliasy modelů

Model Registry je centrální katalog vašich produkčních modelů. Rozdíl oproti trackingu je zásadní: tracking říká, co se stalo během experimentu; registry říká, co je schváleno pro nasazení. V praxi z 500 běhů registrujete 3–5 kandidátů a jeden z nich promujete do produkce.

MLflow 3 posunul model management od stage-based transitions (Staging/Production/Archived) k aliasům, což jsou libovolně pojmenované ukazatele na konkrétní verzi. Stage transitions jsou teď deprecated; oficiální migrační cesta je nahradit je aliasy @champion, @challenger, @shadow. Detaily jsou v Model Registry dokumentaci.

from mlflow.tracking import MlflowClient

client = MlflowClient(tracking_uri="http://127.0.0.1:5000")

# Přiřadíme alias k verzi
client.set_registered_model_alias(
    name="wine-rf",
    alias="champion",
    version="3",
)

# Načteme model podle aliasu, deployment kód se nikdy nemění
import mlflow.pyfunc
model = mlflow.pyfunc.load_model("models:/wine-rf@champion")
predictions = model.predict(X_test)

Výhoda je fundamentální. Váš serving kód referencuje models:/wine-rf@champion, ne version=3. Když natrénujete lepší verzi 4, změníte alias jedním voláním API a nasazení proběhne bez rebuildu image, bez CI/CD a bez restartu (pokud používáte MLflow model loader s TTL cache). To je vzor, který nasazuji ve všech produkčních systémech od roku 2025.

LoggedModel: nová architektura v MLflow 3

LoggedModel je největší koncepční změna v MLflow 3. V MLflow 2 byl model artefaktem „uvnitř" runu a byl s ním pevně svázán. V MLflow 3 je LoggedModel první třídy entita: má vlastní UUID, vlastní metadata a vlastní metriky napříč více runy. To je zásadní pro dva scénáře:

1. Deep learning checkpointy: během jednoho tréninkového runu můžete logovat 20 checkpointů jako 20 samostatných LoggedModelů a každý hodnotit na jiném datasetu.
2. GenAI agenti: „model" nemusí být neurální síť, může to být verze promptu plus konfigurace nástrojů plus LLM engine. LoggedModel tenhle koncept sjednocuje.

import mlflow

with mlflow.start_run() as run:
    for epoch in range(1, 11):
        # ... trénink ...
        val_loss = train_one_epoch(epoch)

        # Každý checkpoint = samostatný LoggedModel
        logged = mlflow.pytorch.log_model(
            pytorch_model=model,
            name=f"checkpoint-epoch-{epoch}",
            step=epoch,
        )
        mlflow.log_metric(
            "val_loss",
            val_loss,
            step=epoch,
            model_id=logged.model_id,  # nové v MLflow 3
        )

Následně můžete použít mlflow.search_logged_models() s SQL-like filtry a najdete nejlepší checkpoint napříč všemi experimenty jedním voláním. To je funkce, kterou jsem před MLflow 3 emuloval vlastními SQL dotazy nad backend databází. Tohle sjednocení mi ušetřilo hodně skriptů.

Tracing GenAI aplikací s mlflow.genai

Modul mlflow.genai je odpovědí MLflow na LangSmith a Langfuse. Poskytuje tracing, tedy strukturované záznamy volání LLM zachycující vstup, výstup, latenci, počet tokenů a mezikroky, a to pro 20+ frameworků. Autoinstrumentace stačí jedno volání:

import mlflow
import openai

mlflow.set_experiment("rag-support-bot")
mlflow.openai.autolog()  # tracing všech OpenAI volání

client = openai.OpenAI()
response = client.chat.completions.create(
    model="gpt-5",
    messages=[{"role": "user", "content": "Vysvětli MLflow tracing"}],
)
# Trace se objeví v MLflow UI se všemi tokeny, latencí i cenou

Pro strukturovanou evaluaci LLM aplikací použijte mlflow.genai.evaluate() s vestavěnými LLM-as-a-judge scorery (correctness, groundedness, relevance) nebo definujte vlastní. Filozofií MLflow 3 je Evaluation-Driven Development: neoptimalizujte agenta, dokud ho neumíte měřit. Podrobný přehled GenAI kapabilit najdete v MLflow 3 GenAI dokumentaci.

Integrace MLflow s Optunou pro ladění hyperparametrů

MLflow a Optuna pro Bayesovskou optimalizaci hyperparametrů jsou přirozený pár. Optuna generuje kandidáty, MLflow zaznamenává výsledky. Doporučená integrace je přes MLflowCallback:

import optuna
from optuna.integration.mlflow import MLflowCallback
from sklearn.ensemble import GradientBoostingClassifier
from sklearn.model_selection import cross_val_score

mlflc = MLflowCallback(
    tracking_uri="http://127.0.0.1:5000",
    metric_name="cv_f1_macro",
)

def objective(trial):
    params = {
        "n_estimators": trial.suggest_int("n_estimators", 100, 500),
        "learning_rate": trial.suggest_float("learning_rate", 0.01, 0.3, log=True),
        "max_depth": trial.suggest_int("max_depth", 3, 10),
    }
    model = GradientBoostingClassifier(**params, random_state=42)
    score = cross_val_score(model, X_train, y_train, cv=5, scoring="f1_macro").mean()
    return score

study = optuna.create_study(direction="maximize")
study.optimize(objective, n_trials=50, callbacks=[mlflc])

Každý trial vytvoří samostatný MLflow run pod jedním rodičovským experimentem. V UI pak porovnáte 50 trialů, vygenerujete parallel coordinates plot a promujete nejlepší běh do Registry, a to vše bez opuštění MLflow. Pokud vás zajímá i preprocessing pipeline, který se s tímhle workflow páruje, mrkněte na scikit-learn Pipeline průvodce automatizací ML.

Nasazení MLflow modelu do produkce s FastAPI

MLflow poskytuje vestavěný serving přes mlflow models serve -m models:/wine-rf@champion -p 5001, který exponuje predikci jako REST endpoint. V produkci ale často potřebujete vlastní autentizaci, rate limiting, doménovou validaci vstupů nebo custom preprocessing. Tehdy zabalím MLflow model do produkčního FastAPI serveru pro ML modely:

from contextlib import asynccontextmanager
from fastapi import FastAPI
from pydantic import BaseModel
import mlflow.pyfunc
import pandas as pd

MODEL_URI = "models:/wine-rf@champion"
ml_models = {}

@asynccontextmanager
async def lifespan(app: FastAPI):
    ml_models["classifier"] = mlflow.pyfunc.load_model(MODEL_URI)
    yield
    ml_models.clear()

app = FastAPI(lifespan=lifespan)

class WineFeatures(BaseModel):
    alcohol: float
    malic_acid: float
    ash: float
    # ... ostatní featury

@app.post("/predict")
async def predict(features: WineFeatures):
    df = pd.DataFrame([features.model_dump()])
    prediction = ml_models["classifier"].predict(df)
    return {"class": int(prediction[0]), "model_uri": MODEL_URI}

Vzor je jednoduchý: model načíst jednou při startu (lifespan handler), predikci provést synchronně (scikit-learn není async) a vrátit ji společně s URI modelu. Audit trail v produkci nemá cenu bez informace, která verze predikci vyprodukovala. Tohle jsem si osobně ošklivě vyzkoušel, když mi po incidentu chyběl konkrétní model_uri v logu a strávil jsem tři hodiny dohledáváním verze v Registry.

Best practices pro MLOps s MLflow v roce 2026

Za sedm let používání MLflow v produkci jsem konvergoval k několika pravidlům, která snižují technický dluh:

• Jedno jméno experimentu = jeden business problém, ne jeden algoritmus. „fraud-detection" ano; „xgboost-fraud" ne. Různé modely stejného problému musí být porovnatelné.
• Vždy logujte git commit hash a data hash jako tagy. Kód a data jsou stejně důležité jako hyperparametry, bez nich není reprodukovatelnost.
• Používejte aliasy, ne stages. Stage-based transitions jsou v MLflow 3 deprecated. @champion, @challenger, @shadow jsou expressive a umožňují A/B testy.
• Backend store = PostgreSQL, artifact store = S3/MinIO. Nikdy nepoužívejte souborový backend v produkci. Souběžné zápisy z více workerů korumpují souborový store.
• Nastavte retention policy. Bez ní vám mlruns/ naroste na terabajty. Skriptujte mlflow gc týdně.
• Sledujte drift produkčních modelů. MLflow 3 přidal integraci s Evidently a datasetovými snapshoty. Logujte production predictions zpět do MLflow jako inference tabulky.

Pro srovnání s alternativami: Databricks post o MLflow 3 shrnuje pozici platformy vůči komerčním nástrojům jako Weights & Biases. Zjednodušeně: pokud potřebujete open-source, on-premise a bez per-user licenčního modelu, MLflow je jednoznačná volba. Pokud upřednostňujete hosted UX a nevadí vám vendor lock-in, W&B nabídne polished frontend, ale infrastrukturu si stejně budete platit.

Často kladené otázky

Jaký je rozdíl mezi MLflow 2 a MLflow 3?

Hlavní rozdíly: (1) nová entita LoggedModel jako first-class citizen, kdy jsou modely nezávislé na runech; (2) modul mlflow.genai pro tracing a evaluaci LLM aplikací; (3) stage-based transitions v Model Registry jsou deprecated ve prospěch aliasů; (4) nativní podpora UV pro lockfile inference závislostí. MLflow 2 API zůstává funkční, ale nové projekty by měly začít na 3.x.

Jak porovnat MLflow a Weights & Biases?

MLflow je open-source, self-hosted, bez per-user licence a s plnou vlastní kontrolou nad daty. Weights & Biases nabídne lépe zpracované UI a hosted infrastrukturu, ale je proprietární a účtuje za uživatele. Pro regulované industry (banky, healthcare v EU) je MLflow prakticky jediná volba, protože data neopouštějí vaši infrastrukturu.

Podporuje MLflow PyTorch, TensorFlow i XGBoost?

Ano. MLflow má vestavěné „flavors" pro scikit-learn, PyTorch, TensorFlow/Keras, XGBoost, LightGBM, Spark ML, ONNX, HuggingFace Transformers, LangChain a další. Každý flavor poskytuje log_model, load_model a autolog. Pro custom framework můžete implementovat mlflow.pyfunc.PythonModel, což je univerzální rozhraní kompatibilní se servingem.

Kolik stojí MLflow?

MLflow samotný je pod Apache 2.0 licencí, tedy zdarma včetně komerčního použití. Platíte pouze za infrastrukturu (server, databáze, object storage). Databricks nabízí Managed MLflow jako součást své platformy s dodatečnými enterprise funkcemi, ale sám core framework zůstává open-source a plně funkční on-premise.

Jak zálohovat MLflow tracking data?

Zálohujte dvě věci: (1) backend databázi standardními nástroji (pg_dump pro PostgreSQL) a (2) artifact store (S3 versioning, MinIO replikace nebo rsync pro lokální disk). Obě zálohy musí být synchronní, protože metadata bez artefaktů (nebo naopak) jsou nepoužitelná. Doporučuji denní snapshot databáze plus týdenní inkrementální zálohu artefaktů.