Observation notebook · Anya · 2026 · MoE branch
Experts, not layers
SpecimenGemma-26B-A4B · Huihui4-8B-A4B · MoE
Statuspivot-explainer · surgery in-flight · revised 2026-06-21
Sourcerouter-diff · REAP teardown (no fixed-seed eval yet)

Every other specimen in this lab treats a layer as the thing you operate on. Point the same machinery at a Mixture-of-Experts model and it stops working — and the way it stops working is informative enough to be its own result. This is the page where the line forks.

The working hypothesis coming in: a layer is the universal unit of surgery, duplicate, prune, or damp one and capability moves, on any architecture. It held across every dense specimen, Granite, MiniCPM5, where a layer genuinely is a unit of computation you can amplify. On an MoE it doesn't. Duplicating a block re-runs the router and double-applies expert selection on an uncalibrated residual: the router sees an input distribution it was never trained on, null rates explode, strict scores floor. It's not "no effect," it's "actively breaks the routing." Hypothesis retired for MoE: the unit of capacity here is the expert, not the layer, so the line forks to the expert axis, and the rest of this page is that work.

§1The wall

Whole-layer surgery has no purchase on a Mixture-of-Experts model, for two distinct reasons. Duplication corrupts routing: a duplicated MoE block is mechanically destructive. And pruning is the wrong axis, not harmful: pruning an MoE layer is an output-compliance fix, unclogging a stalled output valve so the model emits a clean letter or number, not a reasoning fix.

Whether the unclogged output is correct depends entirely on whether the latent capability was already there. On factual multiple-choice (latent), unclogging surfaces a real answer the model knew (a genuine, large gain). On 16-digit arithmetic (not latent), unclogging just produces confident, well-formatted garbage: the strict phantom. Same mechanism, opposite verdict, decided by latent-knowledge presence — the exact compliance-not-capability pattern, here as the whole story rather than a footnote.

The reason is structural: on an MoE the unit of capacity is the expert, distributed across hundreds of them (~8 active per token), not the layer. To touch what the model actually knows, you have to operate on experts.

↳ a layer is a computation you can repeat; an expert bank is a routed lookup you can't repeat without breaking the route

The layer is the wrong handle on a Mixture-of-Experts model Two diagrams. On a dense model, duplicating a layer amplifies a unit of computation and capability shifts. On a mixture-of-experts model, the layer is a router selecting a few of many experts; duplicating the whole layer re-runs the router on a shifted input, mis-fires the expert selection, and breaks the output. The operable unit on an MoE is the expert, not the layer. The layer is the wrong handle A layer is a computation you can repeat. An expert bank is a routed lookup you can’t repeat without breaking the route. Dense · duplicate a layer → amplify layer L dup L L′ (copy) ✓ capability shifts the unit of compute is repeated — a layer can be amplified. MoE · the same dup re-runs the router residual in router ■ ~8 of ~128 experts lit per token dup → router re-runs on an uncalibrated residual router′ wrong experts — null rates explode ✗ routing breaks the route can’t be repeated — the operable unit is the expert, not the layer. Dense surgery works because a layer is a unit of computation you can duplicate. On an MoE the layer is a router + expert bank; duplicating it re-runs the router on a shifted residual, mis-fires selection, and breaks the output. To touch what the model knows, operate on the expert — the unit of capacity — not the layer.
The layer is the wrong handle on a Mixture-of-Experts model On a dense model, duplicating a layer amplifies a unit of computation and capability shifts. On a mixture-of-experts model, the layer is a router selecting a few of many experts; duplicating the whole layer re-runs the router on a shifted input, mis-fires the expert selection, and breaks the output. The operable unit on an MoE is the expert, not the layer. The layer is the wrong handle A layer is a computation you can repeat; an expert bank is a route you can’t repeat unbroken. Dense · duplicate a layer → amplify layer L dup L L′ ✓ capability shifts MoE · the same dup re-runs the router router ■ ~8 of ~128 experts lit per token dup → router re-runs on an uncalibrated residual router′ wrong experts — null rates explode ✗ routing breaks Dense surgery works because a layer is a unit of computation you can duplicate. On an MoE the layer is a router + expert bank; duplicating it re-runs the router on a shifted residual and breaks the output. The operable unit of capacity is the expert, not the layer.
Fig 1 — the layer is the wrong handle. Dense (left): duplicate a layer, amplify a unit of computation, capability shifts. MoE (right): duplicate the layer, re-run the router on a shifted residual, mis-fire the expert selection, break the output.
source §"The wall" · rys_reap.mdtype schematic — no data pullsafety shape/lightness + ✓/✗, not red/green

§2The expert-surgery toolkit

Three operations on the expert axis, three different jobs. REAP is a functional-importance cut: it measures each expert's data-conditioned contribution (gate weight × output, aggregated over a calibration set) and culls the low-saliency ones. That's a "what does the model actually use" cut, the opposite of the geometric cosine/delta scans the dense work uses.

TechniqueWhat it doesUse case
REAP · prunedelete low-utility experts (router-weighted activation pruning)shrink total params
ExpertClone · mergeblend similar expertsdensify, preserve knowledge
SEC · cloneoverwrite junk slots with copies of specialist expertsbias routing toward specialists, no retraining

REAP's published headline (Cerebras, arXiv 2510.13999) is 50% expert compression, near-lossless on code for very large MoEs (Qwen3-Coder-480B, Kimi-K2), with pruning beating merging on generative tasks because merging loses routing control. The lab's own datapoints below deliberately go deeper than that documented window, into the degraded-but-usable regime. The two concrete results that follow are an SEC replay and a REAP teardown; the lab's own runs of both are still ahead.

§3You can steal a clone map by diffing routers

Someone had surgically re-biased an MoE's routing toward its specialist experts, shipped the result, and withheld the how. xpressai published a modified MoE (the live card is Qwen3.6-35B-A3B-ExpertClone-Logic), but the implementation repo is not publicly accessible (and not on the Wayback Machine as of 2026-06), so the profiling methodology is permanently opaque. That opacity is what makes the router-diff method necessary: without it, the surgery couldn't be recovered at all.

You don't need their code to replay the surgery, because of one architectural fact: the router tensor (ffn_gate_inp.weight) is F32 in every quant of the same base. In the cloned file, the victim router columns were overwritten with the donor's — so they now match the donor. Therefore a router column that matches base is a donor (untouched); a column that differs from base is a victim (overwritten). Donor→victim direction falls out definitively, no guessing.

Run that diff and you recover the clone map — 39 of 40 layers cleanly (layer 39 was genuinely untouched), with victim indices systematically small (0–17, the low-firing experts) and donors spread (1–229), which independently confirms a "lowest-total-firing expert as victim" selection rule. Then replay it: 39 × 4 = 156 mmap slab copies onto a runnable pre-quantized IQ2_M of the same base, near-instant, quant-agnostic. You've reproduced a gatekept model's surgery on hardware you own, without their code.

↳ victims hug the low-index slots across 39 of 40 layers; layer 39 is entirely donor

Recovering a clone map by diffing routers against the base model A grid of expert slots by layer. Cells are marked by whether each router column matches the base model or differs from it. Columns that differ — the overwritten victims — cluster in the low-index slots across 39 of 40 layers, while one layer is entirely unchanged. Because the router is full-precision in every quant, diffing it against the base recovers exactly which experts were cloned where, without the original surgery code. Recovering a clone map from the routers The router (ffn_gate_inp.weight) is F32 in every quant — so diffing it against the base recovers exactly which experts were overwritten. the diff rule column == base → donor (untouched) column ≠ base → victim (overwritten    with donor’s column) donor → victim direction falls out definitively — no guessing. 39 of 40 layers recovered cleanly. 4 victims/layer, all in low slots 0–17; donors spread 1–229. → confirms a “lowest-    firing expert = victim”    selection rule. donor field — ~226 untouched experts/layer slots 0–17 expert slot index → (0 … 229) layer 0 → 39 L0 L19 L38 L39 — untouched (all donor) victim (router column differs from base) donor field (column matches base) Replay: 39 × 4 = 156 mmap slab copies onto a runnable IQ2_M — a gatekept surgery, reproduced.
Recovering a clone map by diffing routers against the base model A grid of expert slots by layer. Cells are marked by whether each router column matches the base model or differs from it. Columns that differ — the overwritten victims — cluster in the low-index slots across 39 of 40 layers, while one layer is entirely unchanged. Because the router is full-precision in every quant, diffing it against the base recovers exactly which experts were cloned where, without the original surgery code. Recovering a clone map from routers The router is F32 in every quant — diff it against the base to recover which experts were overwritten. == base → donor ≠ base → victim donor field — ~226 untouched/layer 0–17 expert slot index → (0 … 229) layer 0 → 39 L39 untouched 39 of 40 layers recovered cleanly 4 victims/layer, all in low slots 0–17; donors spread 1–229 → confirms “lowest-firing = victim”. Replay: 39 × 4 = 156 mmap slab copies onto a runnable IQ2_M — a gatekept surgery, reproduced on hardware you own, without their code.
Fig 2 — recovering a clone map from the routers. Because the router is full-precision in every quant, diffing it against base recovers exactly which experts were cloned where, without the original surgery code.
source ffn_gate_inp.weight diff vs basegenerated 2026-06note exact per-layer victim columns illustrative (structure real, columns not claimed)
A strong clone doesn't visibly stumble on eyeball prompts — so the SEC delta is real-but-sub-perceptual, exactly where ad-hoc evaluation fails and the calibrated seed-paired battery earns its keep. The router-diff replay · §3 · capability eval still preliminary

§4Deep expert excision is usable below parity

You can't A/B a 100B→30B retention on a 16 GB Mac (you can't run the 100B base), so the locally-obtainable verdict is usability, not parity. There's one clean, unconfounded datapoint, read straight off a published model's own card.

huihui-ai/Huihui4-8B-A4B is a REAP of gemma-4-26B-A4B-it: experts 128→32 (75% culled), 8 active/token, all 30 layers intact, a pure count-prune. The param math checks out exactly: base routed-expert 22.84B + fixed 2.40B = 25.23B; cull to 32 → routed 5.71B + unchanged 2.40B = 8.10B, dead-on the "8B" label. The 26→8B ratio is only 3.1× despite a 4× expert cut because fixed overhead (attention, dense FFN, embeddings, router, norms) doesn't scale with expert count.

The unconfounded number, from their own perplexity eval: straight 128→32 prune, 0 SFT steps, PPL 1.596 → 2.483 (+55%). Degraded, but not broken: 75% of the experts are gone and it's still a functioning model. The baseline that makes that interesting isn't the unpruned model (you can't run that on 16 GB), it's non-existence. The real comparison is "a degraded version you can actually run" vs. "nothing at all," which is why a +55% PPL hit reads as intriguing rather than disqualifying: this is an accessibility result, not a capability claim.

↳ the only measured point sits past the estimated cliff, yet well above the broken floor

The REAP usability window A curve of model capability against the fraction of experts pruned. Capability holds well through roughly 30 to 50 percent pruning, declines past a cliff near 60 percent where pruning exceeds what the router was trained for, and at 75 percent — the Huihui teardown point — perplexity has risen 55 percent but the model still functions, sitting well above the broken floor. The REAP usability window Expert pruning is graceful to ~30–50%, then a cliff past the trained router-k. One measured point: Huihui at 75% cull. 1.00.80.50.2 retained capability (inv. PPL, base = 1.0) 020406080 % of experts pruned graceful ~30–50% cliff ≈60% past trained router-k estimated from REAP literature (soft band, not measured) base = 1.0 · can’t run 100B on 16GB → parity untestable “broken” floor Huihui4-8B (measured) 75% cull · PPL 1.60→2.48 (+55%) degraded, not broken estimated window (literature) measured datapoint (Huihui card) estimated cliff (router-k limit) The only measured point sits past the cliff (75% cull) yet well above the broken floor — deep excision lands a usable, sub-parity model. The real baseline isn’t the unpruned model (un-runnable on 16GB) — it’s non-existence. An accessibility result, not a capability claim.
The REAP usability window A curve of model capability against the fraction of experts pruned. Capability holds well through roughly 30 to 50 percent pruning, declines past a cliff near 60 percent where pruning exceeds what the router was trained for, and at 75 percent — the Huihui teardown point — perplexity has risen 55 percent but the model still functions, sitting well above the broken floor. The REAP usability window Pruning is graceful to ~30–50%, then a cliff past the trained router-k. One measured point: Huihui. 1.00.80.50.2 retained cap. (inv. PPL, base = 1.0) 020406080 % of experts pruned graceful cliff ≈60% estimated (REAP lit, soft band) base=1.0 · parity untestable on 16GB “broken” floor Huihui4-8B 75% cull (measured) PPL +55%, not broken estimated window (literature) measured datapoint (Huihui card) estimated cliff (router-k limit) The only measured point sits past the cliff (75% cull) yet well above the broken floor — deep excision lands a usable, sub-parity model. The real baseline isn’t the unpruned model (un-runnable on 16GB) — it’s non-existence. An accessibility result, not a capability claim.
Fig 3 — the REAP usability window. The graceful window (~30–50%) and the cliff (~60%, past the trained router-k) are drawn as a soft band — estimated from the REAP literature, not measured here. The only measured point is Huihui at 75% cull.
source Huihui4-8B-A4B card + REAP arXiv 2510.13999measured 1 point (75% cull, PPL +55%)band estimated from literature, not measured

Grader-skepticism note: their post-SFT PPL drops below the 128-expert base (1.004 < 1.596), which tempts a read where 32 experts beat 128. That's false: the SFT and the PPL eval are on the same 500 samples, eval-on-train-distribution leakage (memorising a narrow thinking-format), not genuine superiority. The defensible claim is the 0-step +55% number; the sub-base number is an eval-leakage artifact and shouldn't be cited.

§5Why this is the live direction for consumer ML

A 250B dense model is dead in the water locally (250 GB working set). A 250B MoE with mmap + expert offload has a working set of ~10 GB, because only the active experts are hot: tractable at ~1–3 tok/s for cold-NVMe pages. MoE + REAP + local is the one regime where a consumer machine gets to touch frontier-scale models at all.

The standing hypothesis (speculative: plausible mechanism, untested in this lab): active params, not total, may be the intelligence proxy, up to the trained router-k. Pruning total to 30–40B while keeping ~6–10B active per token might gain per-token quality: remaining experts get hit more often, the router is less stretched. The supporting datapoint, a 35→14B-A3B reaped model "nearly keeping up" with full siblings, is an eyeball read, not a paired eval — so this stays a hypothesis, not a finding. The tax: a reaped older base loses to a newer dense one (generational gains > REAP preservation), so the workflow only pays on current-SOTA bases and has to be re-run per base update.

The engine direction matches the rest of the lab's evolution: the refined surgery line is live-MLX-module patching, not GGUF slab-rewriting — which is also why ragged per-layer expert counts (the elegant "let a global saliency threshold decide each layer's count" version of REAP) are a dead end in stock GGUF (a single global n_expert scalar) and a natural fit in MLX.

Caveats

The router-diff method is solid; what it hasn't produced yet is a quantified capability result. SEC extraction and the lab's own REAP run are still open: read this page as a working log of a pivot in progress, not a finished result.

Build notes & method

The MoE branch of the vivisection lab — where the dense-model machinery (Granite, MiniCPM5) hits its limit and the unit of surgery changes from the layer to the expert. Router-diff runs against full-precision ffn_gate_inp.weight tensors in pre-quantized GGUFs; teardown numbers read off published model cards. Built and run locally on a 16 GB Mac Mini. The inferential harness that makes the sub-perceptual deltas measurable is the methods writeup.