{"schemaVersion":1,"id":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope","title":"MoE expert pruning: active parameters, memory budgets, and HOPE","description":"Why sparse computation does not imply a small deployment, how pairwise expert scores change pruning decisions, and what to measure before serving a compressed MoE.","language":"en","datePublished":"2026-11-09","dateModified":null,"contentFormat":"text/markdown","content":"AI/ML\n\n# MoE expert pruning: active parameters, memory budgets, and HOPE\n\n2026-11-097 min read\n\n[Lucio Durán](<https://lucioduran.com/>)\nEngineering Manager & AI Solutions Architect\n\nAlso available in: [Español](<https://lucioduran.com/es/blog/moe-expert-pruning-memory-budgets-hope>)\n\n## A timely reason to revisit MoE memory\n\nAmazon published its [HOPE engineering explanation](<https://huggingface.co/blog/amazon/higher-order-pruning-experts>) on November 9, 2026. The [paper](<https://arxiv.org/abs/2609.18916v3>) first appeared in September. Today's publication makes expert pruning a timely deployment topic, without turning an earlier research result into a new release.\n\nThe useful question is concrete: when a model activates only a fraction of its parameters for each token, why can it still need so much memory?\n\nIn a mixture-of-experts (MoE) layer, a router selects several expert networks and combines their outputs.\n\nActive parameters describe computation along a selected path. Capacity planning must also account for parameters available to other paths, request state, and temporary allocations. An expert that is idle for one token can still occupy memory.\n\nThis article develops a memory example and a small selection experiment, followed by a proposed evaluation protocol. It does not report a local reproduction of HOPE or a GPU benchmark.\n\n## Separate four memory budgets\n\nStart with an inventory for a fixed model revision, numerical format, serving engine, and workload:\n\n| Budget | What belongs there | What to inspect |\n| --- | --- | --- |\n| Checkpoint storage | Serialized weights and quantization metadata | Actual files, rather than the model's parameter label |\n| Resident weights | Expert and non-expert tensors placed on each device | Placement, replication, precision, and offloading |\n| Request state | KV cache and other persistent per-request state | Context length, simultaneous requests, and cache policy |\n| Runtime headroom | Temporary tensors, kernels, communication buffers, allocator slack | Peak allocation during the real workload |\n\nThese categories overlap across implementations, so define the accounting boundary before adding measurements. Do not add a framework's total reserved memory to its allocated memory: those are overlapping measurements.\n\nFor a deliberately invented capacity example, assume 80 GiB of resident expert weights and 16 GiB of everything else at a fixed request profile. Removing half of those expert bytes leaves:\n\n```text\nbefore = 80 + 16 = 96 GiB\nafter  = 40 + 16 = 56 GiB\nsaved  = 40 / 96 = approximately 41.7%\n```\n\nThe reduction is 50% of expert storage and 41.7% of this hypothetical total. Neither number predicts tokens per second. The remaining 16 GiB was held constant only to make the arithmetic explicit; real runtime allocations can change after pruning.\n\nOffloading and expert parallelism change where weights live and when they move. They do not make the storage obligation disappear. Likewise, reclaimed capacity can support longer requests only if the serving system can use it without hitting another constraint.\n\nThe existing articles on [quantization](<https://lucioduran.com/blog/llm-quantization-gptq-awq-gguf-compared>) and [KV cache and batching](<https://lucioduran.com/blog/llm-inference-optimization-kv-cache-paged-attention>) cover adjacent mechanisms. A deployment can combine them, but their benefits must be measured together.\n\n## Why independent scores can choose the wrong set\n\nHOPE selects a removal set through a quadratic objective, ` p^T F p `, with a fixed removal count. Pairwise terms influence the choice. Its error analysis separates substitution from renormalization; the surrogate is not a direct guarantee on total error or task quality. [Paper, section 3 and appendix A](<https://arxiv.org/html/2609.18916v3#S3>)\n\nHere is an independent arithmetic example. Suppose three synthetic contribution magnitudes, A, B, and C, are observed on two samples:\n\n| Sample | A | B | C |\n| --- | --- | --- | --- |\n| 1 | 1 | 1 | 0 |\n| 2 | 0 | 0 | 1.5 |\n\nDefine the cost of a removal set as the average squared sum of its contributions. This is an illustrative objective, not measured model damage.\n\nScored alone, A and B each cost 0.5; C costs 1.125. Removing the two lowest individual scores selects A and B. Together, however, their contributions coincide: their joint cost is 2. Removing A and C costs 1.625.\n\nThe disagreement comes from the cross term in ` (a + b)^2 `. Ranking individual squares cannot represent it. It does not establish that A and B understand the same subject, cooperate causally, or should always survive together.\n\n## A runnable selection example\n\nThe following uses only Python's standard library. It enumerates every pair for this tiny example and asserts the expected results.\n\n```python\nfrom itertools import combinations\n\nnames = (\"A\", \"B\", \"C\")\nsamples = ((1.0, 1.0, 0.0), (0.0, 0.0, 1.5))\n\ndef removal_cost(indices):\n    return sum(\n        sum(sample[index] for index in indices) ** 2\n        for sample in samples\n    ) / len(samples)\n\nindividual = sorted(range(len(names)), key=lambda i: removal_cost((i,)))\nindependent = tuple(sorted(individual[:2]))\njoint = min(combinations(range(len(names)), 2), key=removal_cost)\n\nassert independent == (0, 1)\nassert joint == (0, 2)\nassert removal_cost(independent) == 2.0\nassert removal_cost(joint) == 1.625\n\nfor selected in (independent, joint):\n    print(tuple(names[i] for i in selected), removal_cost(selected))\n```\n\nExpected output, verified locally:\n\n```text\n('A', 'B') 2.0\n('A', 'C') 1.625\n```\n\nB and C tie with A and C. Iteration order picks A and C; there is no unique winner. Exhaustive enumeration is suitable for three candidates, not a proposed large-model optimizer. The example omits routing replacements, renormalization, and interactions between layers.\n\nThe [published solver](<https://github.com/awslabs/HOPE/blob/f335c52d6dd2e97a3d2611c08b950386d43fb529/hope/solve.py>) instead uses continuous relaxation and rounding, without certifying a global optimum. It also normalizes pair statistics by co-selection counts. Our example averages over all samples. Those choices produce different objectives; this example is not an implementation of the released algorithm.\n\n## Turn compression into a controlled comparison\n\nBefore collecting calibration data, write down the decision the experiment must support. For example: fit a model on a smaller device configuration while retaining acceptable correctness on a particular workload.\n\nKeep calibration, configuration selection, and final evaluation separate. A coding-heavy calibration set should not silently become the definition of acceptable behavior for a multilingual support workload. Preserve rare tasks as named evaluation slices instead of allowing their failures to disappear inside an average.\n\nI would compare the original checkpoint, a simple independent-score pruning baseline, and the pairwise method at identical removal counts. If quantization is part of deployment, evaluate each candidate at that same precision as well. Keep the tokenizer, prompts, decoding settings, serving engine, and request schedule fixed wherever the comparison permits.\n\n| Measurement | Proposed acceptance question |\n| --- | --- |\n| Task correctness by slice | Which required behaviors regress, and by how much? |\n| Failed tool calls and invalid outputs | Does compression break execution contracts? |\n| Resident and peak device memory | Does the candidate fit with realistic headroom? |\n| Time to first token and time per output token | Which phase changes under the same load? |\n| Completed requests per unit time | Does the same service objective support more work? |\n| Calibration and preparation cost | Is preparing the checkpoint worthwhile at the expected usage? |\n\nFor noisy measurements, retain per-request observations and repeat runs. For stochastic answers, compare the same tasks across multiple samples. Report the distribution and uncertainty rather than choosing the best run.\n\nThe released [pruning code](<https://github.com/awslabs/HOPE/blob/f335c52d6dd2e97a3d2611c08b950386d43fb529/hope/prune.py>) preserves the original top-k routing count. Fewer stored experts therefore do not imply proportionally fewer expert evaluations per token. That is a specific reason to separate memory savings from speed claims.\n\n## Read benchmark gains with their denominator attached\n\nFor Qwen3.5-35B-A3B at 50% pruning, the authors report SWE-Bench Pro scores of 42.3 for HOPE, 41.8 unpruned, and 36.2 for REAP. These are their reported results, not measurements from this article. [Published comparison](<https://huggingface.co/blog/amazon/higher-order-pruning-experts>)\n\nA difference of 6.1 score points against another compressed model answers a different question from improvement against the original checkpoint. Neither comparison establishes lower latency, a universal quality improvement, or the outcome of a different calibration distribution.\n\nThe practical release artifact should include the exact source model and code revisions, calibration identity, removal set, checkpoint hashes, evaluation configuration, and rejected cases. Keep the original checkpoint available for rollback and test restoration before depending on the compressed artifact.\n\nChoose a candidate only after it satisfies the memory target and the workload's quality limits. If it saves memory but misses an essential task slice, the deployment constraint has not been solved.\n\n## Frequently asked questions\n\n### Does removing half the experts halve inference latency?\n\nNo. Expert count alone does not determine the work per token, attention cost, communication, or scheduling. Measure the compressed checkpoint on the intended serving stack.\n\n### Is the Python example a reproduction of HOPE?\n\nNo. It exhaustively scores three synthetic contributions to illustrate why independent rankings and joint selection can disagree. It does not load a model or reproduce the published solver.\n\n### Were the reported model benchmarks independently reproduced for this article?\n\nNo. Model benchmark figures are attributed to their authors. Only the small, dependency-free arithmetic example was executed locally.\n\n## Tips\n\n1. Separate checkpoint bytes, resident weights, KV cache, and peak runtime memory. A percentage without a denominator is a poor capacity plan.\n2. Freeze calibration and evaluation sets before selecting experts. Rare production tasks deserve their own acceptance checks.\n3. Measure latency at the same workload and concurrency. Extra memory capacity and faster requests are different outcomes.\n\n- mixture-of-experts\n- llm-inference\n- model-compression\n- expert-pruning\n- hope\n- evaluation\n\n[Back to Blog](<https://lucioduran.com/blog>)","headings":[{"level":1,"text":"MoE expert pruning: active parameters, memory budgets, and HOPE","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#title"},{"level":2,"text":"A timely reason to revisit MoE memory","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#a-timely-reason-to-revisit-moe-memory"},{"level":2,"text":"Separate four memory budgets","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#separate-four-memory-budgets"},{"level":2,"text":"Why independent scores can choose the wrong set","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#why-independent-scores-can-choose-the-wrong-set"},{"level":2,"text":"A runnable selection example","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#a-runnable-selection-example"},{"level":2,"text":"Turn compression into a controlled comparison","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#turn-compression-into-a-controlled-comparison"},{"level":2,"text":"Read benchmark gains with their denominator attached","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#read-benchmark-gains-with-their-denominator-attached"},{"level":2,"text":"Frequently asked questions","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#questions"},{"level":3,"text":"Does removing half the experts halve inference latency?","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#question-1"},{"level":3,"text":"Is the Python example a reproduction of HOPE?","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#question-2"},{"level":3,"text":"Were the reported model benchmarks independently reproduced for this article?","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#question-3"},{"level":2,"text":"Tips","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#article-tips"}],"sections":[{"heading":"MoE expert pruning: active parameters, memory budgets, and HOPE","level":1,"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope","content":"AI/ML"},{"heading":"MoE expert pruning: active parameters, memory budgets, and HOPE","level":1,"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#title","content":"2026-11-097 min read\n\n[Lucio Durán](<https://lucioduran.com/>)\nEngineering Manager & AI Solutions Architect\n\nAlso available in: [Español](<https://lucioduran.com/es/blog/moe-expert-pruning-memory-budgets-hope>)"},{"heading":"A timely reason to revisit MoE memory","level":2,"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#a-timely-reason-to-revisit-moe-memory","content":"Amazon published its [HOPE engineering explanation](<https://huggingface.co/blog/amazon/higher-order-pruning-experts>) on November 9, 2026. The [paper](<https://arxiv.org/abs/2609.18916v3>) first appeared in September. Today's publication makes expert pruning a timely deployment topic, without turning an earlier research result into a new release.\n\nThe useful question is concrete: when a model activates only a fraction of its parameters for each token, why can it still need so much memory?\n\nIn a mixture-of-experts (MoE) layer, a router selects several expert networks and combines their outputs.\n\nActive parameters describe computation along a selected path. Capacity planning must also account for parameters available to other paths, request state, and temporary allocations. An expert that is idle for one token can still occupy memory.\n\nThis article develops a memory example and a small selection experiment, followed by a proposed evaluation protocol. It does not report a local reproduction of HOPE or a GPU benchmark."},{"heading":"Separate four memory budgets","level":2,"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#separate-four-memory-budgets","content":"Start with an inventory for a fixed model revision, numerical format, serving engine, and workload:\n\n| Budget | What belongs there | What to inspect |\n| --- | --- | --- |\n| Checkpoint storage | Serialized weights and quantization metadata | Actual files, rather than the model's parameter label |\n| Resident weights | Expert and non-expert tensors placed on each device | Placement, replication, precision, and offloading |\n| Request state | KV cache and other persistent per-request state | Context length, simultaneous requests, and cache policy |\n| Runtime headroom | Temporary tensors, kernels, communication buffers, allocator slack | Peak allocation during the real workload |\n\nThese categories overlap across implementations, so define the accounting boundary before adding measurements. Do not add a framework's total reserved memory to its allocated memory: those are overlapping measurements.\n\nFor a deliberately invented capacity example, assume 80 GiB of resident expert weights and 16 GiB of everything else at a fixed request profile. Removing half of those expert bytes leaves:\n\n```text\nbefore = 80 + 16 = 96 GiB\nafter  = 40 + 16 = 56 GiB\nsaved  = 40 / 96 = approximately 41.7%\n```\n\nThe reduction is 50% of expert storage and 41.7% of this hypothetical total. Neither number predicts tokens per second. The remaining 16 GiB was held constant only to make the arithmetic explicit; real runtime allocations can change after pruning.\n\nOffloading and expert parallelism change where weights live and when they move. They do not make the storage obligation disappear. Likewise, reclaimed capacity can support longer requests only if the serving system can use it without hitting another constraint.\n\nThe existing articles on [quantization](<https://lucioduran.com/blog/llm-quantization-gptq-awq-gguf-compared>) and [KV cache and batching](<https://lucioduran.com/blog/llm-inference-optimization-kv-cache-paged-attention>) cover adjacent mechanisms. A deployment can combine them, but their benefits must be measured together."},{"heading":"Why independent scores can choose the wrong set","level":2,"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#why-independent-scores-can-choose-the-wrong-set","content":"HOPE selects a removal set through a quadratic objective, ` p^T F p `, with a fixed removal count. Pairwise terms influence the choice. Its error analysis separates substitution from renormalization; the surrogate is not a direct guarantee on total error or task quality. [Paper, section 3 and appendix A](<https://arxiv.org/html/2609.18916v3#S3>)\n\nHere is an independent arithmetic example. Suppose three synthetic contribution magnitudes, A, B, and C, are observed on two samples:\n\n| Sample | A | B | C |\n| --- | --- | --- | --- |\n| 1 | 1 | 1 | 0 |\n| 2 | 0 | 0 | 1.5 |\n\nDefine the cost of a removal set as the average squared sum of its contributions. This is an illustrative objective, not measured model damage.\n\nScored alone, A and B each cost 0.5; C costs 1.125. Removing the two lowest individual scores selects A and B. Together, however, their contributions coincide: their joint cost is 2. Removing A and C costs 1.625.\n\nThe disagreement comes from the cross term in ` (a + b)^2 `. Ranking individual squares cannot represent it. It does not establish that A and B understand the same subject, cooperate causally, or should always survive together."},{"heading":"A runnable selection example","level":2,"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#a-runnable-selection-example","content":"The following uses only Python's standard library. It enumerates every pair for this tiny example and asserts the expected results.\n\n```python\nfrom itertools import combinations\n\nnames = (\"A\", \"B\", \"C\")\nsamples = ((1.0, 1.0, 0.0), (0.0, 0.0, 1.5))\n\ndef removal_cost(indices):\n    return sum(\n        sum(sample[index] for index in indices) ** 2\n        for sample in samples\n    ) / len(samples)\n\nindividual = sorted(range(len(names)), key=lambda i: removal_cost((i,)))\nindependent = tuple(sorted(individual[:2]))\njoint = min(combinations(range(len(names)), 2), key=removal_cost)\n\nassert independent == (0, 1)\nassert joint == (0, 2)\nassert removal_cost(independent) == 2.0\nassert removal_cost(joint) == 1.625\n\nfor selected in (independent, joint):\n    print(tuple(names[i] for i in selected), removal_cost(selected))\n```\n\nExpected output, verified locally:\n\n```text\n('A', 'B') 2.0\n('A', 'C') 1.625\n```\n\nB and C tie with A and C. Iteration order picks A and C; there is no unique winner. Exhaustive enumeration is suitable for three candidates, not a proposed large-model optimizer. The example omits routing replacements, renormalization, and interactions between layers.\n\nThe [published solver](<https://github.com/awslabs/HOPE/blob/f335c52d6dd2e97a3d2611c08b950386d43fb529/hope/solve.py>) instead uses continuous relaxation and rounding, without certifying a global optimum. It also normalizes pair statistics by co-selection counts. Our example averages over all samples. Those choices produce different objectives; this example is not an implementation of the released algorithm."},{"heading":"Turn compression into a controlled comparison","level":2,"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#turn-compression-into-a-controlled-comparison","content":"Before collecting calibration data, write down the decision the experiment must support. For example: fit a model on a smaller device configuration while retaining acceptable correctness on a particular workload.\n\nKeep calibration, configuration selection, and final evaluation separate. A coding-heavy calibration set should not silently become the definition of acceptable behavior for a multilingual support workload. Preserve rare tasks as named evaluation slices instead of allowing their failures to disappear inside an average.\n\nI would compare the original checkpoint, a simple independent-score pruning baseline, and the pairwise method at identical removal counts. If quantization is part of deployment, evaluate each candidate at that same precision as well. Keep the tokenizer, prompts, decoding settings, serving engine, and request schedule fixed wherever the comparison permits.\n\n| Measurement | Proposed acceptance question |\n| --- | --- |\n| Task correctness by slice | Which required behaviors regress, and by how much? |\n| Failed tool calls and invalid outputs | Does compression break execution contracts? |\n| Resident and peak device memory | Does the candidate fit with realistic headroom? |\n| Time to first token and time per output token | Which phase changes under the same load? |\n| Completed requests per unit time | Does the same service objective support more work? |\n| Calibration and preparation cost | Is preparing the checkpoint worthwhile at the expected usage? |\n\nFor noisy measurements, retain per-request observations and repeat runs. For stochastic answers, compare the same tasks across multiple samples. Report the distribution and uncertainty rather than choosing the best run.\n\nThe released [pruning code](<https://github.com/awslabs/HOPE/blob/f335c52d6dd2e97a3d2611c08b950386d43fb529/hope/prune.py>) preserves the original top-k routing count. Fewer stored experts therefore do not imply proportionally fewer expert evaluations per token. That is a specific reason to separate memory savings from speed claims."},{"heading":"Read benchmark gains with their denominator attached","level":2,"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#read-benchmark-gains-with-their-denominator-attached","content":"For Qwen3.5-35B-A3B at 50% pruning, the authors report SWE-Bench Pro scores of 42.3 for HOPE, 41.8 unpruned, and 36.2 for REAP. These are their reported results, not measurements from this article. [Published comparison](<https://huggingface.co/blog/amazon/higher-order-pruning-experts>)\n\nA difference of 6.1 score points against another compressed model answers a different question from improvement against the original checkpoint. Neither comparison establishes lower latency, a universal quality improvement, or the outcome of a different calibration distribution.\n\nThe practical release artifact should include the exact source model and code revisions, calibration identity, removal set, checkpoint hashes, evaluation configuration, and rejected cases. Keep the original checkpoint available for rollback and test restoration before depending on the compressed artifact.\n\nChoose a candidate only after it satisfies the memory target and the workload's quality limits. If it saves memory but misses an essential task slice, the deployment constraint has not been solved."},{"heading":"Frequently asked questions","level":2,"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#questions","content":""},{"heading":"Does removing half the experts halve inference latency?","level":3,"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#question-1","content":"No. Expert count alone does not determine the work per token, attention cost, communication, or scheduling. Measure the compressed checkpoint on the intended serving stack."},{"heading":"Is the Python example a reproduction of HOPE?","level":3,"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#question-2","content":"No. It exhaustively scores three synthetic contributions to illustrate why independent rankings and joint selection can disagree. It does not load a model or reproduce the published solver."},{"heading":"Were the reported model benchmarks independently reproduced for this article?","level":3,"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#question-3","content":"No. Model benchmark figures are attributed to their authors. Only the small, dependency-free arithmetic example was executed locally."},{"heading":"Tips","level":2,"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#article-tips","content":"1. Separate checkpoint bytes, resident weights, KV cache, and peak runtime memory. A percentage without a denominator is a poor capacity plan.\n2. Freeze calibration and evaluation sets before selecting experts. Rare production tasks deserve their own acceptance checks.\n3. Measure latency at the same workload and concurrency. Extra memory capacity and faster requests are different outcomes.\n\n- mixture-of-experts\n- llm-inference\n- model-compression\n- expert-pruning\n- hope\n- evaluation\n\n[Back to Blog](<https://lucioduran.com/blog>)"}],"links":[{"text":"Lucio Durán","url":"https://lucioduran.com/"},{"text":"Español","url":"https://lucioduran.com/es/blog/moe-expert-pruning-memory-budgets-hope"},{"text":"HOPE engineering explanation","url":"https://huggingface.co/blog/amazon/higher-order-pruning-experts"},{"text":"paper","url":"https://arxiv.org/abs/2609.18916v3"},{"text":"quantization","url":"https://lucioduran.com/blog/llm-quantization-gptq-awq-gguf-compared"},{"text":"KV cache and batching","url":"https://lucioduran.com/blog/llm-inference-optimization-kv-cache-paged-attention"},{"text":"Paper, section 3 and appendix A","url":"https://arxiv.org/html/2609.18916v3#S3"},{"text":"published solver","url":"https://github.com/awslabs/HOPE/blob/f335c52d6dd2e97a3d2611c08b950386d43fb529/hope/solve.py"},{"text":"pruning code","url":"https://github.com/awslabs/HOPE/blob/f335c52d6dd2e97a3d2611c08b950386d43fb529/hope/prune.py"},{"text":"Published comparison","url":"https://huggingface.co/blog/amazon/higher-order-pruning-experts"},{"text":"Back to Blog","url":"https://lucioduran.com/blog"}],"structuredData":[{"@context":"https://schema.org","@graph":[{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com/"},{"@type":"WebSite","@id":"https://lucioduran.com/#website","url":"https://lucioduran.com/","name":"Lucio Durán","inLanguage":["en","es"],"publisher":{"@id":"https://lucioduran.com/#person"}},{"@type":"WebPage","@id":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#page","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope","name":"MoE expert pruning: active parameters, memory budgets, and HOPE | Lucio Durán","description":"Why sparse computation does not imply a small deployment, how pairwise expert scores change pruning decisions, and what to measure before serving a compressed MoE.","inLanguage":"en","author":{"@id":"https://lucioduran.com/#person"},"publisher":{"@id":"https://lucioduran.com/#person"},"isPartOf":{"@id":"https://lucioduran.com/#website"},"isAccessibleForFree":true,"datePublished":"2026-11-09","mainEntity":{"@id":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#article"},"breadcrumb":{"@id":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#breadcrumb"}},{"@type":"BlogPosting","@id":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#article","mainEntityOfPage":{"@id":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#page"},"headline":"MoE expert pruning: active parameters, memory budgets, and HOPE","description":"Why sparse computation does not imply a small deployment, how pairwise expert scores change pruning decisions, and what to measure before serving a compressed MoE.","datePublished":"2026-11-09","author":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"publisher":{"@id":"https://lucioduran.com/#person"},"url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope","inLanguage":"en","isPartOf":{"@id":"https://lucioduran.com/blog#blog"},"articleSection":"AI/ML","keywords":"mixture-of-experts, llm-inference, model-compression, expert-pruning, hope, evaluation","wordCount":1229,"timeRequired":"PT7M","workTranslation":[{"@type":"BlogPosting","@id":"https://lucioduran.com/es/blog/moe-expert-pruning-memory-budgets-hope#article","inLanguage":"es","url":"https://lucioduran.com/es/blog/moe-expert-pruning-memory-budgets-hope"}],"isAccessibleForFree":true},{"@type":"Blog","@id":"https://lucioduran.com/blog#blog","url":"https://lucioduran.com/blog","name":"Blog","inLanguage":"en","author":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com/"},"publisher":{"@id":"https://lucioduran.com/#person"},"isPartOf":{"@id":"https://lucioduran.com/#website"}},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://lucioduran.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://lucioduran.com/blog"},{"@type":"ListItem","position":3,"name":"MoE expert pruning: active parameters, memory budgets, and HOPE","item":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope"}],"@id":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#breadcrumb"},{"@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Does removing half the experts halve inference latency?","acceptedAnswer":{"@type":"Answer","text":"No. Expert count alone does not determine the work per token, attention cost, communication, or scheduling. Measure the compressed checkpoint on the intended serving stack."}},{"@type":"Question","name":"Is the Python example a reproduction of HOPE?","acceptedAnswer":{"@type":"Answer","text":"No. It exhaustively scores three synthetic contributions to illustrate why independent rankings and joint selection can disagree. It does not load a model or reproduce the published solver."}},{"@type":"Question","name":"Were the reported model benchmarks independently reproduced for this article?","acceptedAnswer":{"@type":"Answer","text":"No. Model benchmark figures are attributed to their authors. Only the small, dependency-free arithmetic example was executed locally."}}],"@id":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#questions","url":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#questions","inLanguage":"en","isPartOf":{"@id":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope#page"},"author":{"@id":"https://lucioduran.com/#person"}}]}],"contentHash":"a1c6167bb43d2cd9bcb3ee76a73bb2452dfa25f10dac5cd4408f937f71a93d9b","provenance":{"method":"Deterministic serialization of the server-rendered main element","source":"https://lucioduran.com/blog/moe-expert-pruning-memory-budgets-hope","hashAlgorithm":"sha256","hashScope":"JSON document fields before contentHash and provenance","sourceHTMLBytes":61879,"contentBytes":10770}}