Reflection AI Beam 发布测试：更少 Token 能否胜过更大的开放模型

Reflection AI 以 Apache 2.0 协议发布了 Beam 的 5010 亿参数权重，将其“Token 效率”主张变成开发者可独立验证的对象。Reflection AI Beam 此次发布瞄准编程、推理和智能体工作负载，同时每个 Token 仅激活 230 亿参数。

此次发布之所以重要，是因为 Reflection 并未宣称 Beam 胜过所有更大的模型。它的论点更为聚焦，也更具商业相关性：模型可以通过生成更少的推理 Token，降低完成工作的成本。

这让 Beam 与 GLM、Qwen、Kimi 和 DeepSeek 等中国开放模型形成竞争。它也使 Reflection 的策略区别于 Meta 对更大美国开放权重模型的侧重。竞争不再只关乎基准测试分数或 Token 价格，而在于模型完成一项有用任务前究竟消耗多少总计算资源。

Reflection 表示，强化学习让 Beam 学会避免不必要的 Token，同时不放弃棘手问题。这一说法有足够合理性，值得关注，但相关证据目前大多仍由厂商提供。企业如今已获得权重、模型卡和部署工具，可以对其进行更深入的审查。

Reflection AI Beam 发布不只是模型预览

Reflection 已将 Beam 从一款承诺开放的模型，推进为开发者可下载、检查、自定义并自行运行的权重。

该公司于 2026 年 10 月 16 日发布 Beam 权重，距离模型首次亮相过去了 11 天。其发布公告称，这些权重可通过 Hugging Face 以 Apache 2.0 许可证获取。

Apache 2.0 是一种宽松的软件许可证，通常允许修改、再分发和商业使用，同时保留通知和专利条款。相比仅通过 API 发布，或受限制性商业条款约束的模型，它让企业拥有显著更多的控制权。

Beam 是一种稀疏混合专家模型，意味着它包含许多专门化的参数组，但每个 Token 只激活其中一部分。根据已发布的 Beam 模型卡，它总计拥有 5013 亿参数，其中 234 亿为激活参数。

该模型跨 52 层包含 256 位专家，其中包括三层稠密层和 49 层混合专家层。它接收文本、生成文本，并支持 100 万 Token 的上下文窗口。Reflection 表示，Beam 主要面向英语开发，其知识截止日期设为 2026 年 6 月 30 日。

公司发布了 BF16、FP8 和 NVFP4 版本。这些数值格式以不同方式在精度、存储和部署要求之间进行权衡。因此，团队可以选择更匹配自身基础设施的检查点，而不必依赖单一固定表示。

Reflection 还发布了一款用于推测解码的小型草稿模型。这种技术让更快的辅助模型先提出若干 Token，再由主模型进行验证。主模型保留对最终接收输出的控制权，而草稿模型能够提高生成速度。

这套组合使此次发布远不止于一项基准测试公告。开发者可以检查配置、比较数值版本、测试许可证，并将 Beam 接入受支持的推理系统。

Reflection 也在推广一种“面向智能体的开放操作系统”。这一说法涵盖模型周围的部署容器、推理集成、自定义工作流和智能体框架。据该公司称，发布时已包含超过 40 个合作伙伴和集成。

这类配套软件很重要，因为仅有开放权重并不能构成可用的企业系统。团队仍需要服务软件、监控、安全控制、评估工具，以及连接智能体实际执行工作的环境。

新的张力由此开始。Reflection 让模型可检查且可进行商业适配，但 Beam 仍是一个非常庞大的系统。开放访问消除了许可障碍，却没有免除运行它所需的工程工作。

Reflection 为何训练 Beam 使用更少 Token

Beam 的核心机制是强化学习：奖励成功完成的工作，同时惩罚不必要的推理 Token。

强化学习，即 RL，通过让模型反复尝试并获得奖励或惩罚来进行训练。Reflection 表示，其后训练系统推动 Beam 在获得正确答案的同时，减少无谓冗长的推理。

这听起来很简单，但过于激进的 Token 惩罚可能导致错误行为。模型可能通过放弃、跳过关键步骤，或给出一个看似自信的捷径来最小化输出。只有模型仍能可靠完成任务时，更短的推理才有价值。

Reflection 联合创始人兼首席技术官 Ioannis Antonoglou 在一篇详细的效率分析中描述了这一失效模式。他表示，采用朴素惩罚机制训练的模型可能会学会不去解决任务，因为沉默比持续推理更便宜。

Reflection 的应对方式是扩大规模。该公司称，Beam 的高计算量 RL 阶段在四周内使用 10,500 块 Nvidia GB300 GPU，生成了超过 1 亿次 rollout。一次 rollout 是一次完整的问题求解尝试，用于生成训练反馈。

公司还表示，Beam 在来自网络材料和专有授权数据集的 23.8 万亿 Token 上进行了预训练。这些数字来自 Reflection 的训练详情，而非独立训练审计。

这一机制改变了买方看待推理效率的方式。模型的实际成本不只取决于每百万 Token 的标价，还取决于系统完成任务前读取和生成了多少 Token。

对于修复软件的智能体而言，输出可能包括计划、工具调用、命令结果、错误分析、重试以及最终说明。即便单个 Token 并非最便宜，如果模型需要更少尝试，或写出更少的私有推理，它仍可能消耗更少计算资源。

架构带来了另一项效率杠杆。Beam 每个 Token 仅激活其 5010 亿参数中的约 230 亿。这比在每次前向传播中使用全部参数所需的计算量低得多，尽管完整模型仍必须可供服务系统访问。

Reflection 表示，Beam 在达到与领先开放模型相当质量的同时，推理时使用的推理 Token 约少三倍。在 Terminal-Bench 2.1 上，VentureBeat 根据 Reflection 的图表估算，Beam 每次尝试大约生成 25,000 个 Token。在该比较中，GLM-5.2 使用约 80,000 个 Token，同时取得相近分数。

在 DeepSWE 上，差距更小，据称 Beam 生成的 Token 略多于 GLM-5.2 的一半。这种差异很重要。Token 效率并不是一种可原封不动迁移至每种工作负载的普适属性。

Reflection 进一步以激活参数数量乘以生成 Token 数来估算推理计算量。按这种方法，Beam 获得双重优势：它每个 Token 激活的参数更少，并声称每完成一项任务生成的 Token 也更少。

不过，这一估算未计入提示处理、取决于上下文长度的注意力成本，以及服务开销。这些遗漏对编程智能体尤其重要，因为它们往往要接收大型代码库、文档和冗长的操作历史。

因此，Beam 的 Token 纪律是一项可测试的机制，而非已经确定的经济结论。开放权重让独立评估者有机会判断：更短的推理何时代表真正效率，何时又掩盖了未完成的工作。

Beam 以任务成本向中国开放模型施压

Reflection 挑战中国开放模型的角度是已完成任务的效率，而非宣称拥有无可争议的基准领先地位。

中国实验室通过发布企业可自定义或经由竞争供应商部署的高能力模型，已在开放权重 AI 领域建立了强势地位。DeepSeek、阿里巴巴的 Qwen 团队、Z.ai 和 Moonshot AI 扩大了封闭美国 API 之外可获得的性能范围。

Beam 瞄准的是同样的实际角色。Reflection 将其描述为适用于编程和智能体工作负载的主力模型，尤其适合在大量工具交互中消耗可观 Token 预算的任务。

该公司的自有结果显示，Beam 接近若干领先开放模型，但并非始终领先。其最终模型卡显示，BF16 版本在 Terminal-Bench 2.1 上获得 80.1%。Reflection 的对比表列出，DeepSeek V4.1 Flash 为 90.6%，Kimi K3 为 88.3%，Qwen 3.8 Max 为 86.6%。

这些数字削弱了任何关于 Beam 已经取代中国替代方案的宽泛说法。但它们也让 Reflection 的实际论点更清晰：如果 Beam 能以显著更少的计算量产出足够好的结果，它无需赢得每一项原始分数。

Reflection 报告称，Beam 在 SWE-bench Verified 上达到 81.6%，该测试衡量模型能否解决选定 GitHub 代码库中的真实软件问题。它还报告在 SWE Bench Pro v1 上达到 66.1%，在 DeepSWE v1.1 上达到 43.3%。

所有这些结果都需要结合背景理解。基准表现取决于智能体框架、可用工具、采样设置、重试预算和评估规则。Reflection 表示，其模型卡评估使用了 0.7 的 temperature 和 0.99 的 top-p。

已发布的检查点为更有价值的比较创造了机会。独立团队可以在相同的智能体框架、代码库集合、工具权限和停止条件下运行 Beam 及竞争模型。

这种方法揭示的不只是排行榜位置。它将显示每个系统需要多少次尝试、引入回归的频率、仍需要多少人工审查，以及每个被接受的修复消耗多少基础设施时间。

Beam 还通过许可方式向竞争者施压。Apache 2.0 为商业试验、修改和再分发提供了企业熟悉的基础。一些名义上的开放权重模型则附带额外限制、品牌要求，或针对大型服务提供商的单独条款。

宽松许可证并不意味着 Beam 在最严格意义上完全开源。Reflection 发布了权重和配套软件，但没有发布完整训练数据，也没有提供从头复现模型所需的每一项细节。

因此，“开放权重”是更准确的描述。用户可以检查和修改训练好的参数，却无法仅凭已发布材料独立重建整个开发过程。

对于美国企业而言，Beam 提供了另一种可在组织控制下部署的选择。当团队需要数据隔离、定制化行为、可预测的版本管理，或更换服务提供商的能力时，这一点可能很重要。

实际竞争将在真实系统内部展开。一家公司可能会为最困难的编程工作选择得分更高的模型，并将 Beam 用于 Token 消耗占主导的高频任务。另一家公司则可能因其基础设施占用超过节省的成本而拒绝 Beam。

Reflection 对中国开源模型的挑战，建立在这种工作负载层面的计算之上。它不仅是在问 Beam 是否能给出更好的答案，而是在问 Beam 是否能以更少的总体计算投入给出可接受的答案。

更少的推理 Token 并不保证账单更低

Reflection 展示了一个可能颇具价值的效率信号，但尚未证明在独立的企业工作负载中，其端到端成本更低。

生成的 Token 只是推理的一部分。编码代理可能会反复加载代码库上下文、工具说明、测试输出和此前操作。在模型写出下一个 Token 之前，处理这些输入就可能消耗大量算力。

Reflection 公布的估算未包含提示词预填充、依赖上下文的注意力计算以及服务开销。该公司在对这项计算的说明中也承认了这些局限。

实现质量带来了另一个变量。竞争模型可能受益于更成熟的内核、更好的内存调度、更广泛的服务商支持，或针对特定加速器优化的服务软件。

Reflection 产品副总裁 Joe Spisak 承认，较低的 Token 和计算量未必会直接转化为更低的账单。他指出，Qwen 或 DeepSeek 的部署可能使用更高效的内核，即为特定硬件优化的底层例程。

这一区别至关重要。活跃参数为每个生成 Token 的工作量提供了粗略衡量，但无法涵盖每一次内存传输、通信步骤、缓存操作或利用率瓶颈。

Beam 的 5010 亿总参数量也带来了显著的部署负担。尽管每个 Token 仅激活 230 亿参数，自托管系统仍需访问完整检查点及其路由结构。

低精度版本可降低存储需求，但不会让 Beam 变成可在笔记本电脑上运行的模型。企业通常仍需要可观的加速器容量、专用托管服务或托管服务商。

百万 Token 上下文窗口也有类似的细微之处。大上下文容量可帮助代理处理大量代码、文档或运营历史，但并不意味着填满该窗口成本低廉，或能持续提升性能。

长上下文可能增加延迟、加剧内存压力，并让模型接触无关信息。团队仍需要检索和上下文管理系统来挑选正确证据，而不是把所有可用内容一股脑发送过去。

基准测试的归属也是另一个问题。目前大多数突出的 Beam 数据都来自 Reflection 的模型卡或对比图表。权重允许外部验证，但这一过程需要时间。

独立评测者应测试 Token 优势在提示词、推理引擎、数值格式和代理框架发生变化时是否依然存在。他们还应衡量较短推理是否更常导致遗漏，从而需要再次尝试。

安全性也需要同等程度的审视。发布权重让下游用户拥有更多控制权，但也将更多责任转移给部署者。企业必须决定模型如何访问代码、凭据、浏览器、命令行和生产系统。

代理的风险不只取决于文本模型。工具权限、沙箱、审批关卡、日志记录和回滚机制，决定了错误操作会影响什么。

Reflection 表示 Beam 已接受安全评估和红队测试。其发布内容包含安全文档，但模型卡页面仍称更全面的技术报告即将发布。这为进一步披露训练方法和可复现性留下了空间。

早期使用案例颇具前景，但仍有限。Reflection 强调了一个互动式密室逃脱代理、单页 Web 项目和小型浏览器游戏。这些演示展示了工具使用和编码流畅性，而非持续的企业级可靠性。

目前可信的说法是，Beam 以可检查的权重提出了一个有趣的效率假设。更强的说法——即它能在不牺牲任务完成质量的前提下降低总生产成本——仍需要独立证据支持。

开放权重将控制权交还给企业团队

Beam 以 Apache 2.0 发布，扩大了买方的控制权，但企业仍需要运营纪律，才能将这种控制权转化为价值。

仅提供 API 的模型要求客户接受服务商的托管环境、更新节奏、日志政策和可用性。开放权重让团队能够选择模型运行地点以及版本变更时机。

这种控制能力可支持受监管部署、私有代码分析，或处理敏感文档的内部代理。公司还可以针对自身术语、工作流程和工具约定对模型进行微调。

定制化也带来了自身的评估负担。每一项修改都可能改变推理质量、安全行为以及与服务优化的兼容性。团队在替换生产环境中使用的检查点之前，需要进行可重复的测试。

Beam 周边的集成在一定程度上解决了这一问题。Reflection 表示，其合作伙伴生态系统涵盖推理系统、云平台、定制工具、安全服务和代理框架。

该公司希望模型成为更广泛开放代理技术栈的内核。这一定位认识到，企业很少孤立地购买一个模型。它们购买的是必须能够观察上下文、采取行动并产出可审计结果的系统。

对开发者而言，最直接的使用场景是可控实验。团队可以选取一组有代表性的编码或运营任务，然后在相同条件下，将 Beam 与现有模型进行比较。

有用的衡量指标包括完成率、生成 Token、输入 Token、实际耗时、加速器利用率、重试次数、人工修正以及每项被接受任务的总成本。仅衡量输出 Token，将会复制原始说法的狭隘性。

知识密集型代理还需要另一层测试。模型可能推理高效，却仍会在接收到过时、不完整或选择不当的组织上下文时失败。

构建此类系统的团队需要围绕模型建立可靠的检索和证据管理能力。维护良好的AI 知识库可以改善代理所见的信息，而评估则决定它是否能正确使用这些证据。

企业还应将模型所有权与运营独立性区分开来。下载 Beam 消除了对单一托管 API 的依赖，但大规模部署仍可能高度依赖某家云服务商、推理引擎或加速器平台。

Apache 2.0 在许可层面让切换和定制更加容易，但并不保证能在每种硬件配置或服务技术栈之间实现可移植性。

尽管如此，这一发布仍增强了企业的议价能力。团队可以在托管服务商之间协商，保留经过验证的检查点，或在自己控制的环境中运行模型。

随着代理从回答问题转向修改代码、操作软件和协调多步骤工作流，这种议价能力会愈发重要。稳定、可检查的模型能够支持比未经客户批准便更新的端点更严格的变更控制。

因此，即使另一款模型仍保持最高分，Beam 依然具有重要意义。其价值主张结合了可接受的能力、更低的宣称推理消耗、宽松的权重许可，以及部署生态系统。

这种组合能否胜出取决于执行。Reflection 必须让 Beam 易于服务，而独立用户必须确认其效率优势能否在公司偏好的基准测试之外延续。

三个信号将决定 Beam 的效率是否成立

下一阶段关注的是可复现的任务经济性，而不是又一轮厂商图表。

第一个信号将是独立基准测试复现。评估者需要在相同的框架、工具、提示词和重试规则下运行 Beam 与竞争性开源模型。若 Beam 能在使用更少生成 Token 的同时保持相近的完成质量，Reflection 的核心论点就会更具可信度。

第二个信号将是生产部署数据。企业和托管合作伙伴应报告吞吐量、延迟、基础设施利用率、失败率和被接受任务成本。若服务开销抵消了 Beam 的 Token 优势，即便模型依然具备能力，其经济性理由也会被削弱。

第三个信号将是围绕已发布权重的开发者采用情况。微调版本、量化版本、框架支持和可复现的企业案例研究，将显示 Reflection 的开放代理技术栈能否超越发布合作伙伴阶段继续发展。若采用疲弱，则可能表明 Beam 的规模或运营复杂性限制了其影响范围。

Reflection AI Beam 的发布让开发者获得了足够的访问权限，可以验证每一项主张，而非接受一场封闭演示。这正是它目前最重要的贡献。

考虑使用 Beam 的团队应从边界明确的工作负载开始，并衡量完整结果，包括重试和人工修正。真正有用的问题并不是 Beam 单独来看是否写出更少的 Token，而是这些更短的轨迹是否能以更低的总成本产出可靠的工作。