AIDiveForge field notes · Evidence recorded October 15–16, 2026
We observed 1.6–2.2 GB in the model processes running one 3B GGUF. Those numbers are not whole-system RAM requirements or a recommendation for a particular laptop.
The narrow question the measurements answer
We ran qwen2.5:3b as a roughly 1.9 GB Q4_K_M GGUF on a CPU-only cloud VM. Each container was limited to three CPU cores and 10 GB of RAM. The published snapshot records memory used by the model process. It does not measure an entire desktop, the minimum memory needed to boot an operating system or a safe capacity limit for many simultaneous requests.
This distinction is easy to lose when comparing a model download size with a computer's advertised RAM. A compressed or quantized file on disk, the resident memory of a process and the machine's total memory pressure are separate observations. The operating system, runtime, request buffers and other applications also need room.
The process observations
| Runtime | Recorded model-process memory | Scope |
|---|---|---|
| llama.cpp | 1.6 GB | Our dated CPU test |
| LocalAI | 1.7 GB | Our dated CPU test |
| LM Studio / llmster | 2.0 GB | Our dated CPU test |
| Ollama | 2.2 GB | Our dated CPU test |
What this does not tell you
We did not sweep every context length, add multiple concurrent users, run a GPU configuration or measure a memory-constrained desktop until it failed. You cannot extrapolate these figures linearly into a reliable requirement for a much larger model. Even an apparently comfortable model-process number can coexist with host swapping or a container being killed for exceeding its memory limit.
The model's usable context also matters. In the agent tests, the server capped a requested 65,536-token context at 32,768. A capacity plan based only on the requested value would not describe the configuration that actually ran. Record the effective context and what the runtime reports after loading.
Make a memory budget you can verify
If a workflow mixes inference with a coding agent, include the agent's process and tool activity as well. Our agent task scores are not a memory benchmark. They answer whether simple file tasks completed under the model configuration, not how many agents a machine can support at once.
- Write down the model file, quantization, effective context and number of concurrent requests.
- Measure a quiet system first, then record process, container and whole-system memory while the real workload runs.
- Check for swapping, out-of-memory events and unexpected model unloads.
- Repeat with the longest realistic input and the other applications you will keep open.
- Leave measured headroom instead of treating one successful request as a capacity limit.
The next useful comparison
Use these observations to establish an initial measurement plan for a small local model. If your question is whether a particular computer will run your workload comfortably, collect the missing whole-system evidence on that computer. Our runtime comparisons and context guide provide the other variables to keep fixed.
A credible RAM recommendation should say what was measured, at what context and concurrency, and what happened near the limit. Until those tests exist, the honest statement is the process-memory observation rather than a purchase recommendation.
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.