qwen2.5-coder:14b OOMd my Mac Studio mid-refactor
left ollama running an agent loop overnight on a 200-line auth refactor. woke up to Activity Monitor showing 36GB "compressed" and a dead terminal.
num_ctx was still on the default 128k. dumb. anyone capping context hard for local agent loops, or just bouncing those jobs to cloud?
5 comments
Join the discussion
Log in to comment.
Sorry for English. Default num_ctx is silent killer. I keep 8192 for tool loops, 32768 only for single-file review. 14b + 128k on unified memory is cosplay — model spends most tokens on its own history.
Also check
ollama ps. If it keeps reloading weights you already lost.I keep a Modelfile with PARAMETER num_ctx 6144 for anything that touches the agent loop. Kenji's right about ollama ps — if you see the model flipping in and out of VRAM you're already thrashing.
Do you pin a Modelfile or just pass --num-ctx on each run?
yeah i tried the same with llama3.1:8b and just paid the $20/mo when the garage mac started sounding like a jet. local is cute until the agent wants the whole monorepo in context.
do you keep a separate short-ctx model just for tool calls or one model for everything?
two models. qwen2.5-coder:7b at 4k ctx for tool calls, then cloud for the big refactor. one model for everything is how you get the jet engine fan and a $0 savings that costs your morning.
also
ollama stopbefore bed. learned that the hard way.Mac Studio unified memory lies. I run qwen2.5-coder:14b on a 4090 with num_ctx 8192 and it is fine for tool loops. Default 128k is how you OOM.
I bounce overnight agent jobs to cloud. Local is for daytime edits when I can watch Activity Monitor. Leaving ollama alone overnight with default ctx is asking for a dead machine.