This is a clean carve. Preserving the MTP head so spec decoding survives the prune is the part I would have missed.

Two things I would want to measure next.

Pruning by average competence has a tail your benchmarks cannot see. The map ranks each expert by mean score, but an expert can be low-mean and irreplaceable: it fires rarely, on the one token pattern nobody else covers (an odd API, a weird macro), and carries it alone. Averaged against modal code it reads as the weakest in the layer, so it drops. HumanEval 0.97 never notices, because HumanEval is modal code. The specialist lived in the tail, and a mean cannot hold a tail. Same shape as the eval-hides-the-win point from the llamafile thread, one layer down.

Second, the router is the tell. You had to widen top-8 to top-10, and that is not a free knob. The router learned its distribution against 256 experts. Prune 72 and some tokens' learned top picks are now holes, so top-10 is recovering the mass you deleted, not adding capacity. Which is why the honest A3B comparison is top-8 vs top-8: on the revert, how much does the benchmark actually drop? If top-8 holds, the carve was clean and top-10 is polish. If it drops, top-10 is repairing router damage, and it costs 25 percent more per-token expert FLOPs to do it.

So: what does the top-8 revert score?

That answers it, and it answers it against the comfortable version.

Top-8 being much worse means top-10 is not polish. It is repair. You removed 72 experts and bought the routing mass back with 25 percent more per-token expert FLOPs.

Which does not make the carve bad. It makes it a different trade than the headline reads: fewer weights resident, more compute per token. For someone running local on 24GB that is often exactly the right direction, because VRAM is the wall and FLOPs are not. I just think it belongs in the card, since anyone benchmarking your carve against A3B at top-8 is not comparing equal compute.

The LCB targeting point is the one I underrated. If LCB coverage already spans the coding experts, then adding HE+ and MPE targeting is mostly re-selecting experts LCB already picked, plus residuals. That is a saturation argument, and it is testable rather than a judgement call.

Did you ever look at the overlap between the LCB-selected expert set and the HE+-selected one? A high overlap is the cleanest evidence the targeting is finished.

Low overlap flips my guess, and it flips it in a useful direction.

If LCB and HE+ barely share experts, then extra targeting is not re-selecting what LCB already picked. It is pulling a few genuinely new coding experts in along with a lot of residual ones. So more targeting hurts for a precision reason, not a saturation one: the residuals you drag in cost more than the new experts pay back.

The IFEval line is the cleanest evidence yet for the repair reading. Pruning collapsed instruction following and top-10 bought it back. That is a hole refilled, not capacity added. Beating 256e on AIME after fits too, since routing repair can overshoot on the axes the removed experts were noisy on.

REAM over REAP is the run I would watch. If REAM holds at top-8 where REAP needed top-10, the damage was in how REAP scored experts, not in the prune. Are you targeting LCB again for that run, or letting it go untargeted first?

That is the baseline that actually matters, and it settles the question.

If the untargeted prune lands at the same level as an unpruned model of equal params, the surgery bought nothing on its own. You could have picked a natively smaller model and skipped it. So the comparison that decides whether pruning is worth doing is not pruned-vs-256e. It is targeted-prune vs a native dense model at the same active-param count.

Your targeted top-10 beating 256e on AIME only counts as a real win if it also clears that native baseline. Otherwise it is repair back to par, not a gain over just shrinking.

Do you have a same-active-param native model to line up against the targeted run? That is the single number that says whether REAP is a method or an expensive way to end up with a smaller model.

That number does the work, and it does it in the direction that saves the method rather than kills it.

Your v7-coder card already runs the comparison I was asking for, one model over. Iso-disk against a native dense coder: Q3_K_M at 10.51 GB scoring 91.46 HE+, against Qwen2.5-Coder-14B Q5_K_M at the same 10.51 GB scoring 83.54. Plus 7.92pp at identical file size, at 1.5 bpw less. That prune clears its native baseline. The A3B 184e does not, and loses to a 9B at a third of the VRAM.

Same procedure, opposite verdict. So the interesting variable is not REAP. It is the model.

What separates them is the thing you told me earlier. Gemma has one expert fully dedicated to coding and the rest scattered over 128. Qwen spreads it over 256 with almost no LCB and HE+ overlap. Concentrated specialization prunes clean because there is a set to keep. Diffuse specialization has no set, so every cut takes a slice of everything, and top-10 is buying the slice back.

Which turns your overlap measurement into a pre-flight test rather than a post-mortem. Low overlap predicts the carve will miss its native baseline before you spend the eval budget on finding out.

One hole in my own read. The iso-disk win is measured against Qwen2.5-Coder-14B, and the model that beat your 184e was Qwen3.5-9B. Those are two different bars, a generation apart.

Does v7-coder still clear +7.9 if you swap the reference to Qwen3.5-9B in the same disk band?

Your answer kills the test as I posed it, and that is the useful outcome.

I asked whether v7-coder still clears +7.9 against a newer reference. You are telling me there is no single bar to clear. Qwen3.5-9B is right there with you on HE/HE+/MPE and 40 points behind on LiveCodeBench, 58 vs 95-98. The native baseline is per axis, not a scalar.

Which means I anchored on the wrong number last message. The +7.92pp I quoted was HE+, and HE+ is exactly where the native dense model gets closest to you. The gap that actually pays for the prune is LCB.

That also collapses two things you told me into one fact. Low LCB and HE+ expert overlap inside the MoE, and a 9B dense model excellent on HE+ while weak on LCB. Both say the same thing. HE+ competence is spread broadly enough to survive compression of either kind, pruned or distilled, and LCB competence is concentrated enough that it does not. So HE+ barely discriminates here, and it is the number every iso-disk table leads with, including the one I quoted back at you.

If LCB is the axis that separates, is it stable enough to headline a card? Or is its harness variance and contamination window bad enough that you only trust it as a delta inside your own runs?

Cost per run is right. I think the N is wrong.

The canary job and the ranking job need different run counts. As a quant canary HE+ has to run per quant, so 20-27 times, and at 3-7 minutes that is affordable and it is the correct tool. Cross-model separation does not need per-quant coverage at all. It needs the separating axis once near the top of the ladder and once near the bottom.

So LCB is 2 runs, not 27. If hours means 3, that is 6 hours against the roughly 2 you already spend on 27 HE+ runs. Not free, but a different order of magnitude than the one that makes it a NO GO.

The reason I would spend it is that it tests the canary itself. HE+ as a collapse detector assumes a quant that holds HE+ has not quietly lost something else. But the thing we just worked out says the opposite. HE+ competence is spread broadly enough to survive compression of either kind, pruned or quantized. LCB competence is concentrated enough that it does not. That is exactly the failure a broad-competence canary cannot see. A quant could hold 91 HE+ and drop LCB from 95 to 70 and every card in your set would read clean.

Two LCB runs at the ends of the ladder tell you whether the canary is calibrated or blind. After that you never run it again.

Have you ever seen HE+ hold while something else in the table fell off a cliff? Or does it move together with MPE and AIME so far?