Context: On Linux, containers run natively — they share the host's kernel directly. On macOS, they can't (containers need a Linux kernel underneath), so tools like Podman and Docker Desktop quietly run a small Linux virtual machine in the background and put your containers inside that. Every container on a Mac is really sharing a fixed slice of memory carved out for that VM, not your Mac's full RAM — which matters a lot once something inside the container needs more memory than the VM itself was given.
Ran: Started Ollama as a container with Podman, exposed on a different port (11435) than the native app already running:
podman run -d --name ollama-container -p 11435:11434 ollama/ollama
podman exec -it ollama-container ollama pull llama3.2:1b
podman exec -it ollama-container ollama run llama3.2:1b
The pull succeeded (after one transient network retry on the first attempt). Loading the model didn't:
Error: 500 Internal Server Error: model requires more system memory (1.3 GiB) than is available (620.8 MiB)
podman machine list showed why — the VM backing every Podman container on this machine was set to just 2GiB total, for the OS, runtime, and every container combined. After host overhead, only ~620MB was actually free — well under the ~1.3GB this model needs.
Fixed by resizing the VM itself (has to be stopped first):
podman machine stop
podman machine set --memory 4096
podman machine start
Restarting the VM also stopped the container, which then wouldn't exec into ("container state improper") until explicitly restarted:
podman start ollama-container
podman exec -it ollama-container ollama run llama3.2:1b
That worked — asked it "what is kubernetes?" to force a real response, then checked memory with Podman's equivalent of docker stats:
podman stats ollama-container --no-stream
Result:
| Entry 01 (bare metal, native Ollama app) | Containerized (Podman) | |
|---|---|---|
| Process memory | ~1.24 GB RSS | 1.663 GB |
| Processor | 100% GPU (Metal) | CPU only (no Metal passthrough in a container) |
The container used about 34% more memory than the same model running natively — 1.663GB vs. 1.24GB. Some of that gap is Podman/Ollama server overhead inside the container; some is likely the lack of GPU acceleration forcing more CPU-side memory use, though that's an inference from the numbers rather than something directly measured here — worth a more controlled comparison in a future entry rather than treating it as confirmed. Either way, "same model, same memory" turned out to be false: containerizing an inference workload isn't memory-neutral.
Takeaway: The actual resource request to set for a containerized version of this model should be closer to 1.663GB than the 1.24GB bare-metal number from Entry 01 — the container overhead is real, not negligible, and sizing a Kubernetes pod off bare-metal numbers alone would under-provision it. Also worth remembering for local dev: Podman's VM has its own fixed memory ceiling independent of your Mac's total RAM, and that's the first thing to check before assuming a model itself is too large to run.
Top comments (0)