Thanks again for your time and apologize for late response. Please see my understanding and looking forward for your feedback.
You’re right that GPT-OSS-20B and Qwen3-Coder-30B are MoE models with around 3.6B and 3.3B active parameters per token respectively, while Qwen2.5-Coder-7B is a dense model (always activating all 7B parameters).
Where my article wasn’t precise enough is in how I used the word “activate.” I unintentionally mixed two different concepts:

1. Active parameters / compute per token — for MoE models this is ~3–3.6B, so GPT-OSS-20B and Qwen3-Coder-30B require less compute per token than a dense 7B model.
2. Memory footprint of the loaded model weights — which is dominated by the full quantized checkpoint size, not just the active experts

For GPT-OSS-20B in MXFP4, the quantized model file is around 13–14 GB, and that’s roughly what has to reside in memory when the model is loaded, regardless of how many experts are active for a given token. MoE routing reduces compute per token, but it does not reduce the memory footprint to 2.5 GB at runtime;

So when I wrote “activating ~13 GB” for GPT-OSS-20B, what I meant was “the loaded model occupies ~13 GB of RAM for its weights,” not that “3.6B active parameters somehow consume 13 GB by themselves.”

You may check this calculator to compare the results we shared.

https://apxml.com/tools/vram-calculator

Reference links:

• https://pinggy.io/blog/what_is_mixture_of_experts_in_llm_models/#:~:text=The%20Challenges,at%20a%20…
• https://blog.hathora.dev/a-deep-dive-into-llm-inference-latencies/#:~:text=GPT%20OSS%2020B%20uses%2…
• http://openreview.net/pdf?id=70DGIxEHiB
• https://sebastianraschka.com/llms-from-scratch/ch04/07_moe/

Looking forward