How to calculate the actual size of a .fit-trained model in sklearn?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
For a fitted scikit-learn model, "actual size" can mean two different things: how much memory the model occupies in a running Python process, or how large it becomes when serialized to disk. Those numbers are related, but they are not the same, so the first step is choosing which one you care about.
Disk Size: Measure the Serialized Model
If your deployment question is "how big is the saved artifact", the most practical answer is to serialize the model and measure the bytes.
Using joblib:
This is usually the best estimate for model artifact size because it measures the exact file you would store or ship.
You can also estimate serialized size in memory:
That is convenient for quick inspection, though the exact bytes depend on the serialization method.
sys.getsizeof Is Not Enough
Many developers try this first:
That number is usually misleading. sys.getsizeof reports the shallow size of the Python object wrapper, not the full memory of the arrays, trees, or nested structures hanging off the estimator.
For scikit-learn models, a large part of the real footprint often lives inside NumPy arrays or estimator internals, not in the top-level estimator object itself.
In-Memory Size: Use a Deep Size Tool
If you need the approximate in-memory footprint, use a recursive sizing tool such as pympler.asizeof.
This gives a much better approximation of runtime memory use than sys.getsizeof, because it walks referenced objects recursively.
Different Estimators Produce Very Different Sizes
Model size depends heavily on estimator type:
- linear models mainly store coefficient arrays and intercepts
- tree models store split structures and node arrays
- random forests store many trees, so size grows quickly with tree count
- nearest-neighbor models may effectively retain large parts of the training data
That is why there is no one formula for model size across scikit-learn. The model object's internal structure matters as much as the training data shape.
Decide What You Need for Deployment
Use disk size when you care about:
- artifact storage
- model registry quotas
- network transfer size
- package size in deployment
Use in-memory size when you care about:
- container memory limits
- runtime scaling
- number of concurrent models loaded
In many systems, you care about both. The serialized model might be small enough to store comfortably but expand significantly after loading into memory.
A Useful Comparison Pattern
For real deployment planning, measure both:
That gives you a practical pair of numbers instead of a misleading single metric.
Common Pitfalls
- Using
sys.getsizeofand assuming it reports the full model footprint. - Confusing serialized file size with loaded in-memory size.
- Comparing models with different serialization methods and treating the byte counts as directly equivalent.
- Ignoring that some estimators retain large internal structures or even much of the training data.
- Measuring only the estimator and forgetting preprocessing objects that are part of the full pipeline.
Summary
- For saved model size, serialize the fitted estimator and measure the resulting bytes.
- For runtime memory, use a recursive sizing tool rather than
sys.getsizeof. - Serialized size and in-memory size answer different questions.
- Estimator type strongly affects model footprint.
- If you deploy a full pipeline, measure the whole pipeline object, not just the final estimator.

