Shrinking ML container images

Setup#

pip install scikit-learn pandas numpy

Measuring what is actually taking up the space#

Before shrinking anything, measure it. This walks the real installed files of each library on disk — genuine sizes from this machine, not estimates.

import importlib
from pathlib import Path


def installed_size_mb(package_name):
    """Real size on disk of one installed package, right now, on this machine."""
    module = importlib.import_module(package_name)
    package_dir = Path(module.__file__).parent
    total_bytes = sum(f.stat().st_size for f in package_dir.rglob("*") if f.is_file())
    return total_bytes / (1024 * 1024)


sizes = {name: installed_size_mb(name) for name in ["numpy", "pandas", "sklearn"]}
for name, mb in sizes.items():
    print(f"{name:10s} {mb:7.1f} MB on disk")
print(f"{'total':10s} {sum(sizes.values()):7.1f} MB, before Python or your own code")

numpy         26.1 MB on disk
pandas        52.8 MB on disk
sklearn       36.5 MB on disk
total        115.4 MB, before Python or your own code

These sizes come from whatever library versions and platform are installed on the machine running this. Yours will differ, sometimes by a wide margin. But the shape of the result generally holds — even a small, ordinary set of data-science libraries adds up to well over a hundred megabytes, before a single line of your own code exists.

The Dockerfile side: a real multi-stage build#

This is real, correct Dockerfile syntax — it needs Docker itself to build and to observe the resulting image size, which this lesson's sandbox cannot do. Run docker build and docker images on your own machine to see your own numbers.

# Stage 1: has compilers, only used to build anything that needs them
FROM python:3.11-slim AS builder
WORKDIR /build
COPY requirements.txt .
RUN pip install --no-cache-dir --target=/build/deps -r requirements.txt

# Stage 2: the image that actually ships — no compilers, no build cache
FROM python:3.11-slim
WORKDIR /app
COPY --from=builder /build/deps /usr/local/lib/python3.11/site-packages
COPY model.joblib predict.py ./
CMD ["python", "predict.py"]

Walking through it#

installed_size_mb walks every file under a package's installed directory and sums real byte counts. It is the same information du -sh would report from a shell, computed in Python instead. That way it works identically wherever Python runs, including inside a container with no du installed.

The multi-stage Dockerfile never ships stage 1 at all. Anything installed with compilers in the builder stage stays behind when the final image is built. Only the COPY --from=builder line carries forward, bringing only the installed packages, none of the tools that built them.

--no-cache-dir on the pip install line matters even inside a stage that gets discarded. A wasteful build stage still costs build time and build-machine disk, even if it never reaches the final image.

Common mistakes#

Measuring the wrong thing. Assuming the model file is the largest part of an image, without checking, is a common and often wrong guess. For many classical ML models, the surrounding libraries dwarf the model file itself, as the measurement above shows directly.

Copying the whole project directory into the image. COPY . . sweeps in .git, test fixtures, notebooks, and any dataset sitting in the project folder — none of which the running service reads. A .dockerignore, covered in Docker for ML, is the fix, and it is worth checking on every project, not assuming it is already there.

Installing a full deep-learning framework's GPU build when serving runs on CPU. A CUDA-enabled PyTorch wheel is gigabytes larger than its CPU-only counterpart. If the machine actually serving requests has no GPU, the CPU wheel is not a compromise — it is the correct choice.

Deleting files in a later layer and assuming the space is reclaimed. A RUN rm -rf in a separate instruction from the RUN pip install that created the files does not shrink the image. Docker's layered filesystem keeps the earlier layer's bytes regardless. Combine install and cleanup into one RUN instruction, or use a multi-stage build as shown above, which sidesteps the problem entirely.

Try it yourself#

Run installed_size_mb against a deep learning framework you have installed, if any — torch or tensorflow. Compare the result against the classical-ML libraries measured above, to get a feel for how much larger that category of dependency actually is on real disk.

What to learn next#

• Docker for ML — the full layer-caching and .dockerignore mechanics this lesson builds on.
• Training and serving environment parity — making sure a smaller image still behaves identically to the one it replaced.
• Scale to zero, and what it costs you — where a smaller image's faster startup pays off most directly.