Reflection Beam：501B存、23B醒，自托管者必读

Reflection Beam 发布：一个 501B 参数的 MoE 开源模型

Reflection AI 于 10 月 5 日发布 Beam，这是一款 501B 参数的开源权重 MoE（Apache 2.0，权重将在本月晚些时候公开），支持 1M token 上下文窗口。新闻标题都在喊「501B」，但对自托管和部署模型的人来说，真正有用的数字恰恰藏在标题之外。

据 Reflection AI 的公告及 TechCrunch、marktechpost.com 等来源的报道，Beam 的核心卖点并非「跑分第一」，而是一个成本比：推理能力与 GLM-5.2 相当，但推理计算量大约只有后者的 1/3 到 1/4。这个说法基于 Reflection 自己的基准估算，并非实测的美元成本。权重发布当天，你完全可以自己复现验证。

真正重要的数字

理解 Beam 的关键在于区分「存储」和「激活」：

指标	数值
总参数量	501B（必须全部驻留内存）
每 token 激活参数	23B（决定每 token 计算量）
上下文	默认 256K，中训练扩展后可达 1M
服务占用	8-bit 约 500GB，4-bit 约一半
权重许可	Apache 2.0，本月晚些时候发布

MoE 路由意味着每个 token 只有约 4.6% 的网络被唤醒。推理账单跟着 23B 走，而不是 501B。但显存账单跟着完整的 501B 走——仓库里的东西照样要算数。在社区量化版本出现之前，这是多 GPU 服务器级模型，不是工作站能跑的东西。

MoE（Mixture of Experts，混合专家）是一种稀疏激活的模型架构：模型内部包含多个并行的「专家」子网络，外加一个路由网络。每个 token 进入模型后，路由器会根据其表示挑选出得分最高的若干专家（通常 2 到 8 个），只让这些专家参与计算，其余专家保持沉默。这就是为什么 501B 的 Beam 每个 token 只激活 23B——约 4.6% 的网络。

这种设计把「知识容量」和「计算开销」解耦开来：更多专家意味着更多可存储的知识，但单 token 的计算量只由被激活的那部分决定。代价是显存：所有专家的权重都必须常驻，即使某个 token 用不到它们。此外，MoE 对显存带宽和专家并行通信的要求很高，跨设备路由会带来额外的调度开销，这也是部署 MoE 比同规模稠密模型更复杂的原因。

与竞品的对比（公司自报，尚未独立验证）

Reflection 公布的基准数据如下，均未经第三方独立验证：

• SWE-bench Verified：80.9，对比 Nemotron 3 Ultra 的 70.7
• Terminal Bench v2.1：80.1，对比 GLM-5.2 的 81.0，对比 DeepSeek^广告 V4.1 Flash 的 90.6
• DeepSWE v1.1：44.4，落后于 GLM-5.3（61.0）和 Kimi K3（68.0）

从跑分看，Beam 并非全面领先。Terminal Bench 上与 GLM-5.2 基本持平，DeepSWE 上明显落后，SWE-bench 上则有较大优势。这也印证了 Reflection 的定位：不争「最强」，争「同等能力下更省算力」。

这周就能动手做的事

不管 Beam 最终表现如何，以下三件事对任何自托管 MoE 的团队都适用：

1. 先搭评测框架。在本地跑通 SWE-bench Verified 和 Terminal Bench，对接你当前服务的开源模型。等 Beam 权重落地，直接替换上去测——「3-4 倍成本比」这个说法是可测试的，那就去测。
2. 建立每 token 成本模型。激活参数（23B）决定计算成本，总参数（501B）决定显存成本。把这两个数字都放进你的基础设施表格里，这套方法对所有 MoE 都通用，不限于 Beam。
3. 不要基于未发布的权重规划生产。权重、技术报告、模型卡、微调工具全是「本月晚些时候」。用可下载的模型搭好服务路径，把 Beam 当作一个候选替换项对待。

值得关注的工程细节

据 Reflection 公布的信息，Beam 的训练配置有几个值得留意的地方：

• 预训练：23.8T token，使用 6,144 块 GB300 GPU，耗时不到 4 周，约 48 token/参数，正好落在业界趋同的计算最优比例上。
• 强化学习：10,500 块 GB300 GPU 训练 4 周，超过 1 亿次 rollout。有意思的是，浏览能力在没有混合浏览任务的情况下提升了——这是跨智能体领域的真实迁移。
• 安全对齐：独立的对齐教师模型与 RL 教师通过多教师在线策略蒸馏加审慎对齐合并。具体评测结果还需等技术报告。

「计算最优」指在给定训练算力预算下，让模型参数量与训练 token 数量按特定比例配置，使最终模型的损失最小。Chinchilla 缩放定律给出的经典经验值约为每个参数对应 20 个 token；此后业界在大规模训练中普遍观察到 40 到 60 之间的比例，部分原因是推理成本随参数量上升，而过训练（用更多 token 训练更小的模型）能让模型在部署时更便宜。

Beam 的 23.8T 训练 token 对应 501B 总参数，约为 48 token/参数，正好落在这一区间。需要注意的是，MoE 的「有效参数量」应按激活参数而非总参数来衡量，因此这一比例若以 23B 激活量计算会高得多——这反映出 MoE 在训练效率与推理效率之间做了一种不同于稠密模型的权衡。

开源权重竞争的新标尺

Beam 的发布传递了一个信号：开源权重模型的竞争指标正在从「能力」转向「成本」。501B 的总参数量制造了话题，但 23B 的激活量才是决定谁能真正用得起的关键。

对自托管者而言，这意味着评估模型时的维度需要更新——不仅要看跑分，还要算清每 token 的计算成本和全量参数的显存门槛。Reflection 提出的 3-4 倍成本比如果成立，会改变不少团队的模型选型逻辑；但在权重实际发布、第三方复现验证之前，保持审慎。

先验证，再采用。

「开源权重」（open-weight）与「开源模型」（open-source model）在法律和实践中并不等同。开源权重通常只公布训练完成后的模型参数文件，使用者可以下载、微调、自托管，但训练数据、训练代码、数据处理流程往往不公开，因此难以完全复现或审计。Beam 采用 Apache 2.0 许可发布权重，属于较为宽松的授权：允许商用、修改和再分发，仅需保留版权声明。

这与 OSI 定义的开源软件有实质区别——后者要求提供源代码及构建方式。对自托管团队而言，权重开源已经足够支撑私有部署与微调；但如果需要审计数据来源、安全对齐过程或训练细节，仍需依赖技术报告等附带材料，而这恰恰是 Beam 目前尚待补全的部分。