{ "schema_version": 1, "builder_plan": { "scenario": "A self-hosted model uses more compute or memory than your workload can justify.", "change": "Check for a usable pruned checkpoint and runtime support before attempting model surgery.", "baseline": "The original unpruned model at the same precision, context, and load.", "steps": [ "Locate the paper's implementation and check its license, model support, data needs, and hardware requirements. Stop here if you cannot obtain the required artifacts.", "Save a small set of representative product tasks and expected outcomes. Keep evaluation tasks out of any training or tuning, and choose quality and cost limits before running.", "Run the baseline and the proposed change on identical inputs. Keep other settings fixed and repeat paired runs to expose variation.", "Save per-task outputs, failures, timings, and all usage costs. Review regressions before expanding the test." ], "measure": "Task quality, actual GPU memory, serving throughput, and preparation cost.", "decision": "Keep the change only if it meets your preselected quality and latency limits and improves the metric you care about after setup and operating costs. Otherwise retain the baseline. This is an exploration plan, not a validated recommendation." }, "builder_review": null, "arxiv_id": "2609.25809", "title": "You Only Need 2/3 of the Chosen Experts: An Empirical Study of Dynamic Expert Pruning in Fine-Grained MoE LLMs", "summary": "The method replaces full per-token expert activation in fine-grained MoE models with a truncated top-k routing that uniformly keeps roughly two thirds of the selected experts, implemented as a one-integer configuration change. It costs only the dropped expert computation (no extra memory, retraining, or auxiliary scorers), with up to ~1.2% average quality loss at conservative budgets, though more sophisticated dynamic allocation rules add code complexity for under 1% gain at those budgets. It can fail under aggressive pruning on generative tasks such as math and code, on smaller or multimodal checkpoints that are more pruning-sensitive, and it provides no benefit when the deployed model is dense rather than a fine-grained MoE.", "rationale": "The reader gains a near-free inference speedup, but only if they actually serve fine-grained MoE checkpoints, so workload- and model-specific validation is required before adoption.", "technique": "Uniform expert truncation in fine-grained MoE LLMs", "family": "esparsidade_e_poda", "recommendation": "testar", "published": "2026-09-22", "as_of": "2026-10-18", "editorial_status": "indexed", "source_url": "https://arxiv.org/abs/2609.25809", "independent_implementations": 1, "total_implementations": 2, "stars": 4, "citations": 0, "claims": [ { "claim_id": "claim-01", "statement": "The method replaces full per-token expert activation in fine-grained MoE models with a truncated top-k routing that uniformly keeps roughly two thirds of the selected experts, implemented as a one-integer configuration change. It costs only the dropped expert computation (no extra memory, retraining, or auxiliary scorers), with up to ~1.2% average quality loss at conservative budgets, though more sophisticated dynamic allocation rules add code complexity for under 1% gain at those budgets. It can fail under aggressive pruning on generative tasks such as math and code, on smaller or multimodal checkpoints that are more pruning-sensitive, and it provides no benefit when the deployed model is dense rather than a fine-grained MoE.", "basis": "inferred", "result": "", "baseline": "", "conditions": "", "source_url": "https://arxiv.org/abs/2609.25809", "source_page": null, "source_excerpt": "" }, { "claim_id": "claim-02", "statement": "Retaining about two thirds of selected experts preserves 98.8% of unpruned performance on average and yields 1.2-1.7x measured speedup across two serving backends.", "basis": "inferred", "result": "", "baseline": "", "conditions": "", "source_url": "https://arxiv.org/abs/2609.25809", "source_page": null, "source_excerpt": "" } ], "exposure_map": [ { "dimension": "quality", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "compute", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "latency", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "operations", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "compatibility", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "security", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "data_and_training", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "reproducibility", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" } ], "risks": [], "minimum_test": [], "open_questions": [], "independent_tests": [], "lab_reproductions": [], "report_available": false, "validation_tier": "unknown", "evidence_tier": "unknown", "infrastructure_basis": "unknown", "equations": [], "equations_status": "not_fetched", "core_kind": "", "equations_fetched_at": "", "equations_source_url": "", "equations_source_sha256": "", "exposures_reviewed_at": "", "exposures_source_sha256": "" }