5010亿总参数每个Token激活约230亿。两个数字放在一起很容易让人心动既有大模型的规模又只动用一小部分参数普通显卡是不是也有机会先别急着看显卡价格。一张简单的计算表就能说明这里最容易混淆的地方。2026年10月5日Reflection公布Beam。这是一款面向编程、推理和智能体任务的稀疏混合专家模型也就是MoE。按照官方披露的数据它拥有501B总参数、23B激活参数二者的比例约为4.59%。来源Reflection官方公告截至本文核对公告时Beam仍处于早期访问阶段。官方计划在10月稍后开放权重及相关开发资料当前可以申请提前体验。来源Reflection官方公告激活不到5%描述的是每个Token参与计算的参数比例。理解这一点需要把“参与计算”和“保存权重”分开。在稀疏MoE模型中路由机制会为Token选择部分专家参与计算。不同Token可能走不同路径其余专家的权重仍然属于模型的一部分。Hugging Face的MoE技术说明也指出这类架构可以降低相对于同总参数量稠密模型的计算需求但完整保存专家权重仍需要较大的内存空间。来源Hugging Face技术说明可以把它想象成一个工具库每次修东西只拿几件工具库里其他工具依然需要地方存放。所以看到“23B激活参数”不能直接把完整模型的权重体积按23B来算。先算权重本身就能看出数量级。下面是一组理论估算假设5010亿个参数全部按相同位宽紧密存储只计算原始权重数据量。假设每个参数占用原始权重数据量16位即2字节约1002GB8位即1字节约501GB4位即0.5字节约250.5GB以4位为例5010亿 × 4 ÷ 8 2505亿字节约250.5GB。这里采用十进制GB1GB等于10亿字节。这张表是参数量与位宽的算术换算不代表Beam已经提供这些量化版本也不是实测文件大小或最低显存要求。实际部署还涉及量化元数据、运行时缓存、临时缓冲区以及权重如何分布和加载。它能回答的是即使只激活一小部分参数完整模型的存储规模仍然可能很大。计算更省与部署门槛更低需要分别验证。对于本地部署用户最关心的问题通常非常具体现有设备能否加载首个回答要等多久持续生成速度能达到多少以及长对话是否容易超出资源限制。这些答案无法只从激活参数量推出来。对于提供在线服务的团队关注点还会进一步变化。单人使用时表现流畅并不意味着多用户同时请求时也能保持相同体验。实际吞吐、延迟和任务完成质量需要在明确的配置下测试。因此Beam后续值得关注的是权重开放后能否出现可复现的部署结果使用什么硬件、什么精度、什么上下文长度最终得到什么速度与质量。这样的信息才能把发布公告里的数字变成开发者可以采用的方案。对这次亮相我更感兴趣的一点是它给了我们一个重新理解模型规格的机会。总参数量、激活参数量、权重位宽分别回答不同的问题。把它们放到同一张表里才能更接近模型的实际使用条件。下一次看到“数千亿参数只激活几十亿”的模型介绍可以先做两步算清激活比例再按明确的存储假设估算权重体积。4.59%很吸引人。算清另外95.41%的权重放在哪里才开始接近部署问题。