MLflow
chirashi.mlflow
Platform for tracking machine-learning experiments, logging parameters, metrics and artifacts per run, with a model registry holding versions, stage transitions and lineage back to the producing run.
A Docker Compose file for MLflow alone, generated from the catalog and checked by the safety inspector. Sign in and use Kitchen Credits to activate it.
Uses the Medusa cart and payment-session path. This test control does not create an order or capture payment.
MLflow records each training run as a set of parameters, metrics over time, tags and artifacts, grouped into experiments and comparable side by side, which turns which configuration produced this result into a query rather than a feat of memory. The registry takes a logged model, versions it, carries stage annotations and links every version back to the run and code that produced it. A packaging format describes a model with its dependencies and signature so it loads through the same call regardless of the framework it was trained in. The tracking server needs a backend store for metadata and a separate artifact store for files.
You know it worked when
- The tracking interface loads and lists experiments.
- A run logs parameters and metrics that appear in the interface.
- An artifact logged by that run downloads intact.
- A model registered from the run appears in the registry with a version number.
- That version loads through the tracking URI from a separate process.
Known sharp edges
- The default configuration writes to local files, and both metadata and artifacts must be moved to durable backends before any of it can be relied on.
- The artifact store path is resolved by the client as well as the server, so a path valid inside the container is frequently invalid where training actually runs.
- The tracking server has no authentication of its own, and anyone reaching it can read or delete experiments and registered models.
- Artifact volume grows quickly when model files are logged per run, and nothing expires automatically.