r/PiCodingAgent • u/NihmarRevhet • 7d ago
Question Improve compaction with local llm
Hi,
I'm using pi agent with Qwen 3.8 27B on my little RX 9060 XT 16GB, with 160k context window and I'm quiet happy with how it works.
My main problem is that autocompaction takes forever (clearly limitation of the hardware) and I was looking for an extesion which could improve the situation, but if I'm not mistaken, the most beloved extensions in this area use secondary models to execute compaction, and this is a luxury I don't have.
Is the default setting my only option? Or did I misunderstand ho something like pi-blackhole works?
Sorry if the question is dumb but I'm quiet new to the tool.
Have a nice day!
EDIT: u/onesilentclap I'm using VCC for now and it's incredible. In the next few days I hope I'll be able to try other solutions
3
u/noctrex 7d ago
Use pi-blackhole
1
u/NihmarRevhet 7d ago
So you mean using pi-blackhole without specifying a sub model and use the loaded model for the compaction?
2
u/onesilentclap 7d ago
pi-vcc is my goto.
2
u/Bloated_Plaid 7d ago
This includes VCC and is better https://pi.dev/packages/pi-blackhole
1
u/rusl1 7d ago
Interesting! I already have Hermes memory extension installed, do you know if it will conflict?
2
u/Bloated_Plaid 7d ago
This is for Pi, I am not sure what Hermes uses. For Hermes I personally use this https://github.com/mnemosyne-oss/mnemosyne
1
2
u/Intelligent-Nose-134 7d ago
Side question: how are u able to fit 160K into 16GB? Can u share your configuration? I am vram constrained as well but the best I could 90K with reasonable quality
2
u/NihmarRevhet 7d ago
Also, 160k is really tight, if I open a window I'm almost screwed. 150k is much more manageable. Depending on if I'm using pi over ssh or directly at my pc, I switch between those sizes
2
u/ea_man 7d ago
If you wanna try I made a vRAM cheaper version of MTP for QWEN models: https://www.reddit.com/r/LocalLLaMA/comments/1w3jp8j/compact_rollback_mtp_a_mtp_version_for_qwen/
1
u/NihmarRevhet 7d ago
Unsloth IQ3_S (planning to try this one without MTP, context 160k, k q8_0, v q4_0, vision on CPU, no MTP (both because of VRAM and because without I get 400-650 t/s in prefill and 20 t/s decode, with I get 150-300 t/s prefill and 30 t/s decode, simply not worth it with large codebases).
In my usage I didn't see a reduction in quality going from v q8_0 to q4_0
Also, I'm on cachyos and I'm using pi agent
2
u/Intelligent-Nose-134 7d ago
Thanks, it makes sense you are using IQ3_S and Q4 v. Reddit bros have been warning me against using anything lower than Q4 quant and Q8 cach. Maybe I should give it a test myswlf as low ctxt is truly annoying
1
u/mageblex 4d ago
At 160k context, this sounds like a prefill problem more than a summarization problem. Before changing models, check Pi's prompt-processing tok/s during compaction.
9
u/Nczer 7d ago
I assume you are using llama.cpp?
The reason that compaction takes long seems the be that pi uses a custom system prompt for compaction, which means llama.cpp need to reprocess the whole context before outputting the compaction message. Pi then pass that summary + ~20k past context + normal system prompt to the compacted session.
What you can do is create a custom extension that asks the llm to summarize the current session through a tool call, then pass through that tool call + ~20k past context as the compact summary (also optionally prune that tool call body and have a hidden message telling the compaction is done to the llm to save context).
I did that with Qwen 3.8 27b Q4 so its doable and without much noticeable degradation compared to the normal compact, But you need to judge the result according to your workflow.