[Nihmar]

Measures llama.cpp's GPU cache for host-resident MoE experts (--moe-cache-mib, ggml-org/llama.cpp#29887). It is not in our pin (v0.6.0), so this uses v0.7.0 @ 620d2225cc, built like build-hip-pin, as a preview of the next refresh (#396); the pin does not move here.

Summary (bench/results/moe-cache-542.txt, decode t/s, greedy, same prompt ids, KV q4/q4):

scenario	llama.cpp no cache	llama.cpp cache (best cell)	omphalos plain	omphalos best cell
edit-cc	39.1	46.2	68.7	97.7 (MTP + n-gram)
edit-py	36.7	142.7 (n-gram)	73.8	90.2 (MTP)
prose	40.3	48.6	88.1	95.4 (MTP)

• llama.cpp's cache: plain decode +10-21 %, prefill −14…−39 %.
• omphalos stays 1.6-1.8x ahead on plain decode.
• On edit-py, llama.cpp's text is a long copy of the file, so its n-gram drafts win. omphalos' MoE verification costs ~6.5 ms per verified row against ~2.8 ms for llama.cpp, tracked in perf: MoE verification grouped by expert - each selected expert read once per block, bit-identical to decode #551.
• One omphalos cell (MTP + n-gram, edit-cc) stalled ~8 s right after the llama.cpp cells freed ~19 GB of pinned RAM. The rerun gave the same text at 97.7 t/s; the table uses the rerun and the file records both.

Whether llama.cpp's cache design helps omphalos's own expert cache is studied in #550.

Closes #542

🤖 Generated with Claude Code