# ML in a Box: Analyzing Containerization Practices in Open Source ML Projects

arXiv: https://arxiv.org/abs/2607.10126 · HTML: https://mlsanity.com/paper/2607.10126/

## Key facts

- No citing papers in the map yet (data through 14 Oct 2026).
- Builds on 10 of its 28 references that are in the map.
- First posted on arXiv 11 Jul 2026.

## Builds on (most cited first, 10 of 10)

- [Studying the Practices of Deploying Machine Learning Projects on Docker](https://mlsanity.com/paper/2206.00699/) (2022)
- [How Developers Iterate on Machine Learning Workflows -- A Survey of the Applied Machine Learning Literature](https://mlsanity.com/paper/1803.10311/) (2018)
- [A Container-Based Workflow for Distributed Training of Deep Learning Algorithms in HPC Clusters](https://mlsanity.com/paper/2208.02498/) (2022)
- [Fixing Dockerfile Smells: An Empirical Study](https://mlsanity.com/paper/2208.09097/) (2022)
- [Empirical Analysis on CI/CD Pipeline Evolution in Machine Learning Projects](https://mlsanity.com/paper/2403.12199/) (2024)
- [Mining Container Image Repositories for Software Configuration and Beyond](https://mlsanity.com/paper/1802.03558/) (2018)
- [Learning from, Understanding, and Supporting DevOps Artifacts for Docker](https://mlsanity.com/paper/2002.03064/) (2020)
- [Refactoring for Dockerfile Quality: A Dive into Developer Practices and Automation Potential](https://mlsanity.com/paper/2501.14131/) (2025)
- [FaaSGuard: Secure CI/CD for Serverless Applications -- An OpenFaaS Case Study](https://mlsanity.com/paper/2509.04328/) (2025)
- [Cost-Performance Analysis: A Comparative Study of CPU-Based Serverless and GPU-Based Training Architectures](https://mlsanity.com/paper/2509.14920/) (2025)

## Abstract (arXiv)

Containerization has become increasingly essential in the machine learning (ML) domain, providing reproducibility, portability, and environment consistency. While prior studies have analyzed Dockerfile structures and best practices, none have examined ML projects in depth to reveal how the iterative nature of ML workflows influences container footprint, build performance, and caching behavior. We present the first large scale empirical study of 1,993 ML related Dockerfiles, combining quantitative analysis of container roles in ML projects and build dynamics with a qualitative investigation of refactoring practices. Results show that containers serve distinct roles across training, inference, and infrastructure. Containers are typically large, averaging 10.27 GB in size, and require long build times of about 8.84 minutes. We find that 44.4% of commits trigger rebuilds, primarily due to context file changes (96.4%), with experimentation being the main motive behind those commits that initiate rebuilds. Despite partial cache reuse, 71% of rebuild work is wasted on redundant computation. From stable projects, we identify 7 recurring ML-specific Dockerfile refactoring patterns that improve build efficiency and reduce container footprint.