AIDiveForge field notes · Evidence recorded October 15–16, 2026
Our runtime images ranged from about 1.2 to 9.4 GB, but image size excluded other components. Treat the image, model files, additional backends and running memory as separate quantities.
Four numbers, four particular images
The Docker images in our October test records occupied 9.37 GB for Ollama, 4.68 GB for our LM Studio image, 1.21 GB for llama.cpp and 1.20 GB for LocalAI. Those figures describe specific images in our environment. The LM Studio image was our test build, so it is particularly inappropriate to treat its size as the vendor's standard installer size.
All four local-runtime tests used a qwen2.5:3b Q4_K_M model of roughly 1.9 GB. Model storage and Docker-image storage answer different questions. Depending on how an installation stores its model, simply adding labels from unrelated measurements can double-count some bytes or leave other bytes out. Inspect the actual mounted volumes and artifacts in your deployment.
What to put in a capacity inventory
| Quantity | What to record | What it does not establish |
|---|---|---|
| Docker image | Exact image digest and observed local size | Complete installed footprint |
| Model artifact | File hash, quantization and size | Resident process memory |
| Extra backend | Version, origin and additional downloaded bytes | That future startup is offline-ready |
| Persistent data | Model cache, logs and working files | A fixed upper storage bound |
| Running memory | Process, container and host observations | A different machine's minimum RAM |
The LocalAI example
The LocalAI image used in our test did not contain the backend that ran the GGUF. We downloaded its llama-cpp backend separately; that download occupied 165 MB on disk. A comparison that calls the 1.20 GB image the entire LocalAI installation would omit a component we actually needed.
At startup the service also attempted to reach gallery and package-related hosts. With those requests blocked, the prepared installation still served the model. That result describes a prepared image with the required components available. It does not establish that a clean first installation can succeed with no network.
Inspect without deleting a working environment
Start by identifying the image and the volumes a running container actually uses. Docker's inspection and listing commands can help build an inventory. The following commands are read-only; use your container's real name in place of the example. Do not run cleanup or pruning commands as part of a measurement just to make a size number look smaller.
docker image ls --digests
docker inspect YOUR_CONTAINER
docker volume ls
docker system dfUse size to answer an operating question
For a small server, the important question may be how much storage is available during installation, when an old and a new image can both exist. For an offline package, it may be whether every model and provider dependency is already present. For a laptop, memory pressure during the intended workload may matter more than the initial download. Record the quantity that corresponds to the decision.
Our findings support a simple habit: label every size figure with what was counted and when. Preserve the image digest and the model identity alongside it. That produces a capacity comparison you can update after an upgrade instead of a headline that mixes disk, downloads and RAM.
Test conditions and sources
8-vCPU AMD EPYC 9354P cloud VM, each test limited to 3 cores and 10 GB RAM, no GPU, no internet (isolated Docker network). Local-model runs blocked external access. Hosted-model reruns explicitly allowed the Anthropic API. The machine was shared; generation ratios apply to their paired sessions and do not predict GPU or other-machine performance.
These are dated observations, not a claim about the latest release or every machine. Recommendations and example procedures are our interpretation of the recorded results.
- Ollama's recorded Docker image
- LocalAI image and separate backend
- llama.cpp test record
- LM Studio test record