Llama-CPP Parallel Agents --> fine for decode, but one agent's prefill will grind all other agents to a halt
Summary
A user reports that in Llama-CPP with parallel sub-agents, decode performance is great but a single agent's prefill (e.g., processing a web search) stalls all other agents, and asks for tuning suggestions.
Similar Articles
Help optimizing llama.cpp + Qwen 27B on RTX PRO 6000 Blackwell for coding agents
A user details their setup running Qwen 27B with llama.cpp on an RTX PRO 6000 Blackwell for local coding agents, compares performance to Claude models, and asks for help resolving frequent crashes and malformed response issues.
We have sub-agents at home
A developer shares a forked sub-agent repository for pi coding agent that works with a single local LLM slot and limited VRAM, using llama.cpp server and quantized models. The post also discusses performance with the Apex Qwen variant using MTP.
@no_stp_on_snek: while everyone is talking about @SpaceXAI , @AnthropicAI , and @OpenAI updates (but where @GoogleAI?)... went and teste…
A detailed comparison of Unsloth's NVFP4 quantized model inference performance between vLLM and llama.cpp, highlighting prefill speed advantages for vLLM but decode and caching advantages for llama.cpp in single-stream agent workloads.
If you use Open Code or other agenting programs you are leaving a lot of t/s if you don't actually use agents in parallel. Benchmark : RTX5090, Qwen3.6 35B loaded via LM studio with parallel tasks set to 8
Benchmark shows that running 4-5 parallel agents with LM Studio on RTX 5090 maximizes throughput, while more agents yield diminishing returns due to VRAM and compute splitting.
Fixing token latency in sequential agent loops and This "Parallel Tool Calling fix" worked well.
A fix for token latency in sequential agent loops is presented, where parallel tool calling improves performance in LLM agent systems.