Quantized KV Cache Helps Six of My Nine Models and Actively Hurts the Two Newest Ones
Nine models on one pinned build, three cache types each. Where quantizing the KV cache pays, where it costs, and what runs at all on 128GB.
Engineering's view on local frontier AI — what actually runs on hardware you control.
Nine models on one pinned build, three cache types each. Where quantizing the KV cache pays, where it costs, and what runs at all on 128GB.
A Fedora upgrade turned into an attribution run. Five builds from one base, and the one patch that removes the dense flash attention collapse at depth.
A reader's fork makes quantized KV cache faster than f16 on Strix Halo. Verified on a 128GB box up to the full 262k native context. His cache-spill theory for the dense cliff survived half its test, and the failed half is the interesting part.
Two guides said turn the IOMMU off. I was the outlier running it on. Measured: +34 to +38% dense prompt processing. Plus five more tips, mostly busted, and one that crashes the GPU.
Same box, same build, one flag: +41% for the MoE model, -51% for the dense one. The Strix Halo tuning tips, measured and ranked, including the ones that failed.
Same box, same models, same flags, three builds in three weeks. What moved, what broke, and the routine that keeps my numbers honest.
A proven production setup you can copy: BIOS values, kernel params, working systemd units, and real benchmark numbers.
The instinct is to wait for the next box. In a memory crunch, that's backwards. How to read the buy-or-wait question for Strix Halo, DGX Spark, and Mac Studio.
A buyer's guide to local LLM hardware, ranked by the one spec that actually decides generation speed: memory bandwidth. Plus where ROCm really stands on Strix Halo.
On June 8, AMD opened pre-orders for a $3,999 box built around the exact chip I've run in production since the start of the year, marketed on full ROCm support, with one of its own demos running on the exact model my board can't load under ROCm.
The Bosgame M5's ROCm bug is board-specific, not chip-specific — so firmware is the obvious lever. I flashed Bosgame's newest official BIOS hoping to dodge it. It didn't work, and the negative narrows where the fault actually lives.
kmarble showed ROCm decode collapses 64% at full context on Strix Halo, and ROCm+MTP cures it. My board can't run ROCm. The Vulkan half reproduces the drop — but the MTP sweet spot from last week walks left at depth: by 76k, drafting too deep is slower than no speculation at all.
Until May 19, the llama.cpp speculative-decoding default was 16. On Qwen3.6's single MTP head, that default cost up to 75% of generation throughput. Here's where the real sweet spots are — and why they're architecture-specific.
We promised a ROCm 7.x revisit. We got a comprehensive workaround sweep instead. Both are useful.
The headline isn't where Vulkan wins. It's where ROCm doesn't run at all.