Every project has that folder. A checkpoint named something like model_epoch12_final_v2.pt sits next to a config you edited three times, a results CSV with no timestamps, and a sticky note that reads "the good one." The training works. The record of it does not.

The tools below are open source, unglamorous, and aimed squarely at that problem. They cover experiment tracking, dataset versioning, visualization, tuning and lightweight serving. Ten is a list to choose from, not a checklist to finish. Two or three, adopted properly, will change how your next project runs.

Track experiments without a spreadsheet

MLflow is still the default answer for run tracking. Point it at a local file store or a database, log parameters, metrics and artifacts with a handful of calls, then open the UI and compare runs side by side. The model registry is the part teams underuse: it gives artifacts named versions and stage transitions, so you can answer "which file is the service loading?" without guessing. The overhead is small enough to justify on a solo project.

TensorBoard is older and still the fastest way to watch a run as it happens. Scalar curves, weight histograms, the computation graph and the embedding projector are all there, and PyTorch's SummaryWriter feeds it without ceremony. Use it live during training and keep MLflow as the archive; they solve different halves of the same problem.

At minimum, a run record should capture:

• The exact config, including defaults you never touched.
• A hash or version tag for the training data.
• Code commit, environment file and hardware.
• Metrics per epoch, not just the final number.
• The artifact itself, plus a note on what changed since the last run.

Version data and models the way you version code

DVC keeps large files out of Git while keeping them addressable. Running dvc add on a data folder writes a small pointer file you commit, and dvc push copies the bytes to S3, SSH or another remote. Pipelines declared in dvc.yaml rerun only the stages whose inputs changed. The habit matters more than the command syntax: your commits start describing a reproducible state instead of a hopeful one.

LakeFS takes the same idea to object storage with branches, commits and merges over a bucket. When several people write to the same data lake, you can train against a branch, merge it once validation passes, and roll back a bad ingestion the way you would roll back code. Pick it if your team already lives in S3 or GCS and DVC's per-file pointers feel too granular.

Look at your data before the loss curve flattens

FiftyOne is a browser-based view over your dataset. Sort samples by embedding similarity, surface near-duplicates, filter by model prediction, and inspect the images or clips where confidence is low. Label errors usually cluster, and finding them visually beats reading a confusion matrix. You can tag a slice, export it in the original format, and hand it to whoever fixes labels.

Netron opens a saved model and draws the graph: layer names, tensor shapes, dtypes. It takes seconds to install and is the quickest way to catch a wrong input shape or a silently dropped node after an export to ONNX or TFLite. Open the file before you write the serving code, not after it fails.

Tune deliberately, then watch for drift

Optuna turns hyperparameter search into a short script. Define an objective, suggest values for learning rate or depth, and let the pruner stop trials that are clearly behind by epoch three. Store studies in SQLite so a crashed process does not erase the search, and run several workers against the same storage when you have the hardware. Random search still works; the pruning is what makes it affordable.

Evidently compares a reference dataset against current production data and writes an HTML report covering distribution drift and data quality. It is cheap insurance against the failure mode where inputs shift quietly and nobody notices until someone complains.

Serve small models without renting a cluster

ONNX Runtime runs exported models on CPU or GPU with a small footprint, and post-training quantization can cut size and latency noticeably for the accuracy you are willing to trade. Check operator coverage during export: custom layers occasionally need a fallback path, and it is better to discover that on your laptop than in a container.

BentoML packages a model, its preprocessing and its dependencies into a service, generates a container image, and handles request batching and concurrency. For heavier multi-model deployments on provisioned GPUs, Triton Inference Server and TorchServe are worth reading, but they assume more infrastructure than most projects need in the first month.

Ship a demo people can click

Gradio builds an interface in a few lines, queues requests so a slow model does not fall over, and can produce a temporary share link for review. Streamlit gives you more control over layout when you want a small dashboard rather than a single input-and-output panel. Both let a stakeholder test the model without anyone writing frontend code, which shortens the feedback loop more than another point of accuracy would.

A stack that fits together

If you want a concrete order, try this:

1. Put raw data under DVC or LakeFS and commit the pointers.
2. Log every run to MLflow with params, metrics and the data version.
3. Browse the training set in FiftyOne and fix obvious label errors first.
4. Tune with Optuna, keeping the study in a database so it survives restarts.
5. Export the winner to ONNX or package it with BentoML, then expose it through Gradio.

Adding all of this in one week will stall you. Start with the failure that cost you the most time last month — probably the missing record of which run was good — and wire in one tool properly. The rest can wait until the pain shows up again.

If you cannot reproduce your last good model from a clean checkout, the tooling is not finished yet.

Photo: Pexels / Pixabay