vibehacker
Discuss
Sam Nguyen
4 hours ago

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.

  • Kenji Watanabepro

    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.

    • Quiet Ship

      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?

  • Liam O'Connor

    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?

    • theo

      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 stop before bed. learned that the hard way.

  • Nadia Petrova

    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.

More like this

View all