Which checks must pass before pruning two experts that see under 1% of traffic?

**Low utilization does not mean low importance.** A 1%-traffic expert may be the model's only path for a specific tail distribution: a minority language, a niche code construct, an unusual document type. The checklist has four parts. - **Validate the traffic sample.** A week of utilization stats might miss seasonal queries or rare workload types. Audit the sample against your full production distribution including tail use cases. - **Ablate and evaluate per-domain.** Mask the two experts during inference (route their tokens to the next-best alternatives). Measure on benchmarks broken down by domain, not just average perplexity. Average metrics hide tail regressions. - **Stress tail inputs.** Test on rare tokens, code in unusual languages, mathematical content, low-resource languages, anything that might rely on rare experts. - **Trace renormalized routing.** When you remove an expert, the router's softmax over remaining experts redistributes its probability mass. Look at which alternative experts inherit the load and whether they are well-suited for the previously-pruned tokens. The two wrong answers are confounds. Retraining from scratch defeats the purpose of working from an existing checkpoint. Raising top-k changes compute cost and routing behavior simultaneously, so you cannot attribute any measured impact to the pruning itself.

**The right four checks line up against four risks of naive pruning.** - **Risk: unrepresentative sample.** A 1% utilization measurement from a one-week window may exclude seasonal traffic, low-volume tenants, or workload types that batch infrequently. Audit the sample for coverage of every documented use case before deciding the 1% is structural. - **Risk: average metrics hide tail.** Aggregate perplexity rises by less than 0.1 when you remove two rarely-used experts, because they handled 1% of tokens. But a per-domain breakdown might show a 30% regression on Vietnamese tokens or a 10% regression on regex-heavy code. Always evaluate on domain-stratified benchmarks under ablation. - **Risk: tail specialization.** Rare experts are often the only path for tail content. Stress-test on the inputs your customers care about that are low-frequency overall. - **Risk: routing redistribution.** After pruning, the router renormalizes its softmax over the remaining experts. The previously-pruned tokens flow to whichever expert had the next-highest score. That next-highest may be a poor fit. Inspect the routing shift before committing. The two wrong options. **Retraining from scratch** turns expert pruning into a different exercise. The point of pruning is to shrink an existing checkpoint without retraining. **Raising top-k preemptively** changes routing diversity and compute cost. This confounds any measurement of pruning impact. It is a separate intervention, not a preparation.