This change reduces the number of layers in the lmi dockerfile by combining some pieces that didn't need to be separated. It brings down the image size to 18GB. for reference
nightly is currently 22.3gb
0.30.0 is 22gb (before any refactors)
0.29.0 is 19.8gb (before any refactors)
The largest contributor to our image size are the python dependencies (9GB, of which PT is like 5GB). I don't know if we can get around that at the moment.
The DJL serving components, and patching/os updates are still left at the bottom since those are the most likely to change. If a change happens at either of these layers, it only requires pulling layers of about ~1GB. Before these series of changes, a change to the djl serving deb/jars would result in also needing to pull the python deps again.
We still pip install pytorch in a separate layer since by itself it's about 5GB, and the other python installs bring 5GB. Pytorch shouldn't change within the container for a given release version. Everything below that is more likely to change, which is about 6GB of the total image size
This should be an improvement for caching/fast-pulling of updates, but I think we also need to explore the multi-stage build paradigm
Description
This change reduces the number of layers in the lmi dockerfile by combining some pieces that didn't need to be separated. It brings down the image size to 18GB. for reference
The largest contributor to our image size are the python dependencies (9GB, of which PT is like 5GB). I don't know if we can get around that at the moment.
The DJL serving components, and patching/os updates are still left at the bottom since those are the most likely to change. If a change happens at either of these layers, it only requires pulling layers of about ~1GB. Before these series of changes, a change to the djl serving deb/jars would result in also needing to pull the python deps again.
We still pip install pytorch in a separate layer since by itself it's about 5GB, and the other python installs bring 5GB. Pytorch shouldn't change within the container for a given release version. Everything below that is more likely to change, which is about 6GB of the total image size
This should be an improvement for caching/fast-pulling of updates, but I think we also need to explore the multi-stage build paradigm