The number in a model name — 1b, 3b — is parameter count, roughly the tunable values inside the model that encode whatever it's learned. More parameters, generally, means better reasoning, at the cost of more memory and slower responses. I wanted an actual number for that tradeoff instead of just nodding along to the general idea, so I pulled the 3-billion-parameter sibling of Entry 01's model and put them side by side.
One thing that tripped me up almost immediately, worth flagging since it'll trip you up too: ollama run <model> drops you into an interactive chat session — the >>> prompt — which is a completely different context from your regular shell. I typed ollama ps straight into that chat by habit and got a confused response back from the model instead of the process table I wanted. Small mistake, but a genuinely useful one to make once, since it makes the shell-vs-chat distinction click in a way reading about it never would.
Loaded the 3b model, captured the same ollama ps / ps aux numbers from Entry 01, then asked it the same pod-status question from Entry 02 — this time against the plain 3b model, not the constrained oc-mentor build.
1b (Entry 01) |
3b |
|
|---|---|---|
ollama ps size |
1.5 GB | 2.5 GB |
| Process RSS | ~1.24 GB | ~2.47 GB |
| Parameters | 1B | 3B |
Tripling the parameters roughly doubled the memory. Not 1:1, which matters if you're ballparking resource requests for something bigger down the line — the scaling isn't linear in the direction you'd naively assume.
The answer to the pod-status question was the more interesting result, honestly. Since this was the plain 3b model, not the constrained one from Entry 02, it came back as a long, hedge-everything explanation using kubectl — not oc. Which makes sense once you think about it: the tight, single-command behavior from Entry 02 came from the system prompt, not from anything about model size. Take the constraint away and even a bigger model just reverts to whatever its training leaned toward, which apparently is kubectl over oc.
$ ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
llama3.2:3b a80c4f17acd5 2.5 GB 100% GPU 4096 4 minutes from now
$ ps aux | grep ollama
flyers 94626 0.2 15.1 438021552 2531232 ?? S llama-server --model ... -c 4096
flyers 1905 0.0 0.4 436904528 60864 ?? S ollama serve
So: more parameters bought real memory cost (roughly 2x for 3x the params) but bought nothing in terms of domain-specific behavior on its own. If you want oc-only, single-command answers, that's still a system-prompt problem, not a model-size problem — no amount of scaling up fixes it for free.
Correction (Aug 19, 2026): the 1b baseline referenced above is Q8_0 quantization, not an unspecified default — see Entry 04 for the full breakdown across quantization levels.
Top comments (0)