很多开发者看到模型卡里的117B parameters with 5.1B active parameters第一反应是“这个数到底怎么算出来的”。本文就用gpt-oss-120b做一个完整示范如何仅凭config.json里的关键字段推导出 MoE 模型的总参数量、每 token 激活参数量以及为什么你自己算出来的数字有时会和官方只差一点但不完全一样。关键词MoE、active parameters、config.json、gpt-oss-120b、模型卡、Hugging Face、参数量估算、推理成本很多人看 MoE 模型时最容易被一句话吸引117B parameters with 5.1B active parameters这句话很有信息量但也很容易让人误解。常见误区有三个以为117B就意味着每个 token 都会走完 117B 参数以为5.1B active就等价于“这个模型推理成本和一个 5B dense 模型差不多”以为只要看模型卡不需要自己核对如果你是做模型选型、推理优化、服务部署或者只是想更扎实地理解一个 MoE 模型那么我非常建议你掌握一项能力自己根据config.json去核对模型卡里的 active parameters。这篇文章我会以 openai/gpt-oss-120b 为例把整个过程走一遍并顺手补充一些对开发者非常有价值、但模型卡里通常不会直说的信息。一、先说结论gpt-oss-120b 的 active params 怎么看gpt-oss-120b的模型卡写的是117B parameters5.1B active parameters它的 config.json 里关键字段是{hidden_size:2880,intermediate_size:2880,num_hidden_layers:36,num_local_experts:128,num_experts_per_tok:4,num_attention_heads:64,num_key_value_heads:8,head_dim:64,vocab_size:201088}这几个字段已经足够让我们抓住本质一共有36层每层有128个 expert每个 token 在每层只会路由到4个 expert所以每层只会激活4 / 128 3.125%的 expert 参数最终核算下来总参数量约为116.83B四舍五入后就是模型卡里的117B按官方口径统计的 active parameters 约为5.13B四舍五入后就是5.1B换句话说模型卡这两个数字并不是“营销数字”而是可以从配置和结构中推出来的。二、为什么开发者要学会自己核对 active parameters因为active parameters这个指标虽然常见但并不是一个全行业绝对统一的口径。不同团队在统计时可能会有以下差异是否把embedding算进 active params是否把lm_head算进去是否把 router、norm、bias 这种“小而常开”的模块算进去是按“单步前向参与计算”的口径还是按“主干 被选中的专家”口径这就导致一个现象你自己算出来的结果往往不是“错”而是“统计口径不同”。所以学会核对 active params 的价值不只是为了验证模型卡更是为了判断一个模型真实的每 token 计算规模理解它为什么“总参数很大但单步推理没那么大”评估它和 dense 模型相比的部署意义分清“显存占用”“吞吐成本”“理论激活量”到底在说什么三、核对 active parameters第一步先找哪些字段对于大多数 Transformer MoE 模型你先看config.json里下面这些字段1. 与 MoE 路由直接相关num_local_expertsnum_experts_per_tok这两个字段决定每层一共有多少个专家每个 token 每层会命中多少个专家对gpt-oss-120b来说num_local_experts 128num_experts_per_tok 4意思就是每层 128 个 expert但每个 token 每层只激活其中 4 个。2. 与 expert 大小相关hidden_sizeintermediate_size这两个字段决定 expert 的 MLP 有多大。对gpt-oss-120b来说hidden_size 2880intermediate_size 28803. 与层数相关num_hidden_layers对gpt-oss-120b来说num_hidden_layers 364. 与 dense attention 主干相关num_attention_headsnum_key_value_headshead_dim这些字段决定 attention 的 Q/K/V/O 投影规模也会影响“总参数量”和“active params 中始终开启的 dense 部分”。5. 与 embedding / 输出头相关vocab_sizehidden_sizetie_word_embeddings这几个字段决定 embedding 和lm_head的规模。这里有一个重要提醒很多人只算了 expert 部分然后说“这就是 active params”。这通常是不完整的。因为 attention、router、norm、embedding 等模块也会参与每一步前向。四、第二步先算单个 expert 有多少参数MoE 模型最关键的地方是先弄清楚一个 expert 到底有多大在gpt-oss这类结构里expert 本质上是一个带门控的 MLP。如果从结构上理解它大致相当于一个gate_proj一个up_proj一个down_proj对应的参数量可以近似写成expert_params ≈ hidden_size * intermediate_size hidden_size * intermediate_size intermediate_size * hidden_size 3 * hidden_size * intermediate_size如果再把 bias 算进去会多一点点但主量级还是由上面这个3 * h * i决定。对于gpt-oss-120bhidden_size 2880 intermediate_size 2880 expert_params ≈ 3 * 2880 * 2880 24,883,200再加上 bias 后精确值约为24,891,840也就是单个 expert 大约 2489 万参数。五、第三步算每层会激活多少 expert 参数现在我们已经知道每层有128个 expert每个 token 每层只激活4个 expert每个 expert 约24.89M参数那么每层被激活的 expert 参数量大约就是active_expert_params_per_layer 4 * 24,891,840 99,567,360也就是每层大约激活 9957 万 expert 参数。再乘以36层active_expert_params_total 36 * 99,567,360 3,584,424,960约等于3.58B这一步很关键因为很多人看到 MoE 会先问“那是不是每个 token 只走 3.58B 参数”答案是还不止。因为除了被选中的 experts还有 dense 的 attention 主干、router、norm、embedding 等模块也一直在工作。六、第四步把始终开启的 dense 部分也加进去MoE 模型并不是“除了 expert 之外什么都没有”。gpt-oss-120b每一层还有这些固定参与前向的部分self-attention 的q_projk_projv_projo_projrouter两个 RMSNormattention 中一些小参数这些 dense 主干参数虽然远小于全部 experts但它们是每层都一定会参与计算的。对gpt-oss-120b进行核算后可以得到36 层 dense transformer 主干约0.97Bembedding 约0.58B于是active_params ≈ 激活的 experts dense transformer 主干 embedding ≈ 3.58B 0.97B 0.58B ≈ 5.13B这就是模型卡里5.1B active parameters的来源。七、那为什么有时候你会算出 5.7B而不是 5.1B这正是 active params 最值得开发者注意的地方。如果你把lm_head也算进“每步前向实际参与”的参数中那么gpt-oss-120b还要再加上lm_head hidden_size * vocab_size 2880 * 201088 ≈ 0.58B这时你会得到一个更大的数字5.13B 0.58B ≈ 5.71B也就是说按官方常见口径gpt-oss-120b是5.1B active按“连 lm_head 也算进去”的严格前向口径它更接近5.7B这两者并不矛盾只是口径不同。所以以后你再看任何模型卡里的 active params都建议先问自己一句这个 active params究竟有没有把 embedding、lm_head、router、norm 一起算进去八、总参数量为什么是 117B现在再看总参数量就很容易理解了。总参数量不是“每次激活多少”而是模型一共持有多少参数。对gpt-oss-120b来说总参数量由以下部分组成embedding36 层 attention 主干36 层 router / norm36 层全部128个 experts最终lm_head核算下来大约是116.83B四舍五入就是117B所以这两个数字可以这样理解117B说的是“这个模型总共装了多少参数”5.1B说的是“每个 token 实际只会动用其中一小部分参数”九、只看 config.json什么时候够用什么时候不够用这里有一个很重要的经验判断。只看config.json就够用的场景如果一个 MoE 模型满足下面这些条件那么只看配置通常就足以做高可信度估算MoE 结构比较标准expert 是典型的gate/up/down三段 MLPhidden_size、intermediate_size、num_experts_per_tok等字段清晰没有额外共享 expert、残差 expert、特殊并行分支这时你完全可以通过单 expert 参数 - 每层激活 expert 参数 - 全层累计 - 再加 dense 主干把 active params 估出来。只看config.json不够用的场景如果你遇到以下情况就最好顺手打开一次实现代码配置里写了intermediate_size但 expert 实际不是标准 3 段 MLP有shared_expert或shared_mlp有num_experts_per_tok但还有额外 dense FFN 分支并行存在一个 block 里不只是一个 MoE MLP有 fused projection单从名字看不清矩阵形状简单说config.json能告诉你“结构有多大”但不一定能 100% 告诉你“矩阵具体怎么摆”。对于gpt-oss-120b如果进一步看实现会发现它的 expert 是gate_up_proj: [hidden_size, 2 * intermediate_size] down_proj: [intermediate_size, hidden_size]这和我们上面使用的3 * hidden_size * intermediate_size推导是一致的。十、给开发者最有帮助的一点active params 不等于真实推理成本这是很多工程讨论里最容易混淆的一点。active parameters很重要但它并不是部署成本的唯一指标。1. active params 更接近“每 token 参与计算的参数量”它能帮助你理解每个 token 大概有多少参数参与乘加为什么 MoE 可以做到“总参数很大但单步计算没那么大”为什么同等 active params 下MoE 可能比 dense 模型更有能力2. 但它不等于真实延迟真实延迟还会受到这些因素影响expert 路由带来的 gather / scatter 开销多卡 expert parallel 的通信成本attention 计算和上下文长度KV cache 读写batch sizesequence lengthkernel 实现质量量化方式所以你不能简单说“5.1B active所以它就等于一个 5B dense 模型的推理成本。”这在工程上通常是不成立的。3. total params 更接近“模型存储规模和权重驻留规模”117B total params更影响权重总占用模型加载体积是否能装进单卡 / 多卡分片和并行策略而5.1B active更影响单步 token 计算规模理论 FLOPs 量级对吞吐与时延的直觉判断一个非常实用的理解方式是total params决定“你要把多大的模型搬上车”active params决定“每次踩油门时真正有多少部件在发力”十一、为什么量化不会改变参数量口径gpt-oss-120b的配置里还写了quantization_config:{quant_method:mxfp4}这说明它的部分权重采用了量化表示。但要注意量化改变的是参数存储精度不改变参数个数。所以117B total params还是117B5.1B active params还是5.1B量化会显著影响显存占用带宽压力实际吞吐但不会改变模型卡里的参数“个数”统计。十二、一个可复用的通用核对模板以后你看到任何 MoE 模型卡只要它公布了config.json都可以按下面这个顺序核对。第一步确认是不是标准 MoE重点看这些字段num_local_expertsnum_experts_per_tokhidden_sizeintermediate_sizenum_hidden_layers第二步估算单 expert 参数量如果是标准门控 MLP可先用近似公式expert_params ≈ 3 * hidden_size * intermediate_size如果要更精确就把 bias 也加上或者去看实现里矩阵的精确 shape。第三步估算每层激活参数active_expert_params_per_layer num_experts_per_tok * expert_params第四步乘总层数active_expert_params_total num_hidden_layers * active_expert_params_per_layer第五步加上始终开启的 dense 部分包括但不限于attention Q/K/V/Orouternormembedding有时还要考虑lm_head第六步明确你的统计口径最后一定要说明你有没有算 embedding你有没有算 lm_head你有没有算 router / norm / bias这一步非常关键否则同一个模型不同人算出来的数字会看起来“互相矛盾”。十三、附一个简单 Python 脚本快速估算 gpt-oss-120b如果你只是想快速验证一个数量级可以直接用下面这个脚本。vocab_size201088hidden_size2880intermediate_size2880num_hidden_layers36num_local_experts128num_experts_per_tok4num_attention_heads64num_key_value_heads8head_dim64# embedding / lm_headembedvocab_size*hidden_size lm_headhidden_size*vocab_size final_normhidden_size# 单层 attentionq_projhidden_size*(num_attention_heads*head_dim)(num_attention_heads*head_dim)k_projhidden_size*(num_key_value_heads*head_dim)(num_key_value_heads*head_dim)v_projhidden_size*(num_key_value_heads*head_dim)(num_key_value_heads*head_dim)o_proj(num_attention_heads*head_dim)*hidden_sizehidden_size# norm / routernormshidden_sizehidden_size routernum_local_experts*hidden_sizenum_local_experts# 单个 expertper_expert(hidden_size*(2*intermediate_size)(2*intermediate_size)intermediate_size*hidden_sizehidden_size)# 每层all_experts_per_layernum_local_experts*per_expert active_experts_per_layernum_experts_per_tok*per_expert per_layer_denseq_projk_projv_projo_projnormsrouter total_params(embednum_hidden_layers*(per_layer_denseall_experts_per_layer)final_normlm_head)active_params_official_style(embednum_hidden_layers*(per_layer_denseactive_experts_per_layer)final_norm)active_params_with_lm_headactive_params_official_stylelm_headprint(ftotal params:{total_params/1e9:.2f}B)print(factive params (official-style):{active_params_official_style/1e9:.2f}B)print(factive params (with lm_head):{active_params_with_lm_head/1e9:.2f}B)运行后你会得到接近下面的结果total params: 116.83B active params (official-style): 5.13B active params (with lm_head): 5.71B十四、顺手对比一下 gpt-oss-20b你会更容易看懂 120bgpt-oss-20b的配置很有意思hidden_size 2880intermediate_size 2880num_hidden_layers 24num_local_experts 32num_experts_per_tok 4也就是说它和120b的单个 expert 大小其实是一样的区别主要在于层数更少24层 vs36层每层总专家数更少32个 vs128个这会导致一个很有意思的结果20b的总参数量远小于120b但它每层激活的 expert 数量同样是4所以它的 active / total 比例会明显更高粗略核算gpt-oss-20b总参数约20.91B如果采用“包含 embedding但不包含 lm_head”这套和gpt-oss-120b一致的官方口径那么 active params 约为3.61B四舍五入后正好就是模型卡里的3.6B active这个对照其实很有价值因为它说明gpt-oss系列的模型卡口径大概率是统一的统计 active params 时包含 embedding但不包含 lm_head这说明一个很重要的事实MoE 模型的“总参数变大”未必意味着“每 token 激活参数同比例变大”因为它可能主要是在加 experts 的总池子而不是增加 top-k。这也是 MoE 架构非常有吸引力的原因之一。十五、最后总结以后怎么最快判断模型卡的 active params 靠不靠谱以后你看到一个 MoE 模型卡不妨直接按下面这套方法走先看num_local_experts和num_experts_per_tok确认每层到底激活多少 expert。再看hidden_size和intermediate_size估单个 expert 大小。乘上层数得到全部激活 expert 参数。再把 attention、router、norm、embedding 加回来。最后确认口径里是否包含lm_head。如果这样算出来和模型卡差得不多比如只差几个亿以内通常不是你算错了而是四舍五入差异是否统计 bias是否统计 embedding是否统计 lm_head官方采用了更偏工程化的 active 口径真正重要的不是把数字抠到一模一样而是你是否已经理解这个模型为什么是这个数量级。一旦你掌握了这套方法以后无论是看 Mixtral、DeepSeek、Qwen MoE还是别的开源专家模型都会比只看模型卡踏实得多。十六、给工程实践者的最终建议如果你的目标是选型或部署而不是单纯看热闹我建议把下面三件事分开看total params决定模型总体规模、装载成本、权重驻留压力active params决定每 token 理论参与计算的参数规模real latency / throughput决定真实服务体验受实现、并行、通信、KV cache、量化等多因素共同影响这三者经常相关但绝不等价。所以最稳妥的工程心智模型是先用config.json算结构规模再用真实 benchmark 验证部署表现。前者帮你建立判断后者帮你避免踩坑。如果你愿意我下一篇还可以继续整理成一篇姊妹篇如何根据config.json判断一个模型是不是“强推理模型”如何快速看懂 dense 模型与 MoE 模型的真实部署差异如何用同一套方法核对 Mixtral、DeepSeek、Qwen MoE 的 active params