From Data to ML Model Serving: A Simple Local MLOps Setup
Why I built this project
Many people learn machine learning, but very few get a chance to understand how machine learning systems are actually built and maintained in real-world environments. This project is my way of creating a local and straightforward MLOps example that anyone can run on their laptop.
My goals were:
The GitHub repository is here: https://github.com/ankit-khare-2015/local-mlops-fraud-classifier
Use case: Fraud detection
To make the project more practical, I selected an everyday use case: predicting whether a transaction is fraudulent.
The dataset is synthetic. It is generated in a way that follows typical real-world patterns. The fraud probability increases when:
This makes the model output meaningful and provides a reasonable basis for demonstrating MLOps processes.
What MLOps ideas does this project shows
This project demonstrates the core ideas behind MLOps without becoming too complex.
1. Reproducible training
All training happens inside a Docker container. This makes the process repeatable.
2. Experiment tracking and model versioning
MLflow stores metrics, parameters, artifacts, and model versions. Each training run creates a new version in the model registry.
3. Workflow orchestration
Airflow triggers the pipeline steps. For example:
4. Model lifecycle management
Training is only the first step. A model also needs:
Recommended by LinkedIn
5. Model serving
The FastAPI service loads the Production model directly from MLflow. It does not retrain anything. It only serves predictions.
This shows a clean separation between training and serving.
Architecture overview
Model serving: single prediction and batch prediction
The API supports two kinds of prediction calls.
Single prediction
You send one transaction record. The API returns one fraud probability. This is similar to real-time scoring.
Batch prediction
You send a list of multiple records. The API returns a list of fraud probabilities. This is similar to daily or hourly batch processing jobs.
Both types use the same Production model, which keeps the behaviour consistent.
Technologies used
All components run locally so that anyone can try the system end-to-end.
This project shows how all parts of an ML system work together. It is meant for students, engineers, and anyone who wants to understand the basics of MLOps in a simple environment without cloud services.
You can find the complete code here: https://github.com/ankit-khare-2015/local-mlops-fraud-classifier
I have explored it however not in production
Open Source / SWE at Databricks
4moGreat work, Ankit! "Training is only the first step" is spot on. The end-to-end coverage (registry, promotion, serving) is what most tutorials skip. Curious have you explored applying this same thinking to LLM workflows with MLflow? Seems like a natural extension.