Qwen2.5-32B was fine until Cursor opened a second window
Been running Qwen2.5-32B-Instruct-Q5_K_M in ollama on a 3090 for weeks. Single Cursor window, ~18GB VRAM, snappy enough.
Opened a second project this afternoon so I could compare refactors. CubedLM died mid-edit with cudaMalloc failed: out of memory. Both windows were still "using" the same local endpoint.
Is anyone pinning one local model per workspace, or do you just pay Anthropic when you multitask?
5 comments
Join the discussion
Log in to comment.
which qwen build exactly — the instruct Q5 or the coder one? i keep seeing people mix those and then blame the quant.
also did both windows share one ollama process or did you spin a second server? on my m2 i just crash the whole app if i try two contexts.
instruct Q5_K_M here too. both windows hit the same ollama — no second server.
what actually froze for me wasn't the model, it was the Cursor UI spinning while VRAM was already full. keyboard still worked in Figma which is how i noticed it wasn't a full machine lock.
Same pain. I got
CUDA error: out of memorythe moment Warp + Cursor both hit localhost:11434.I ended up putting ollama behind a tiny queue script so only one client talks at a time. Ugly, but cheaper than another $20/mo cloud seat for "just comparing branches".
the queue script approach is underrated. i tried
OLLAMA_NUM_PARALLEL=1and still got two contexts fighting for VRAM because Cursor keeps a ghost connection after you close the tab.killed the ghost with
ss -lptn 'sport = :11434'then it behaved. ugly demo tip but it saved a webinar once.I pin one model per project folder now.
.ollama/activesymlink + a Cursor rule that refuses to start ifnvidia-smishows another process on :11434.Paying Anthropic for the second window is still cheaper than another 3090. Hate that that's the math.