Reflection Beam 1.0:501B 开放 MoE 模型,支持 1M 上下文,Apache 2.0 许可

Reflection 的 Beam-1.0-501B-A23B 是一个 501B 参数的开放混合专家模型,每个 token 激活 23B 参数,支持 1M token 的上下文窗口,并采用 Apache 2.0 许可。这是美国新实验室 Reflection 推出的首个模型,其重要性在于它面向前沿规模的编码和智能体工作负载,同时可以在团队已有的硬件上进行部署和微调。

Beam 仅支持文本输入和输出。它附带一个专用的开源 Rust 工具链,原生支持 transformers,并在发布首日即集成 vLLM 和 SGLang。Hugging Face 和 Reflection 还发布了该模型的推理、监督微调(SFT)和强化学习(RL)配方。

关键规格一览

Beam 是一个稀疏 MoE 模型,运行速度接近更小的模型,同时保留大模型的容量,因为每个 token 仅由网络的一部分计算。

  • 总参数 501B,每个 token 激活 23B
  • 52 层,每个 MoE 层 256 个专家,每个 token 路由 8 个
  • 文本输入输出,支持 1M token 上下文窗口
  • 检查点格式:BF16、FP8 和 NVFP4
  • 推理努力级别:"low"、"medium"(默认)、"high"、"xhigh" 和 "max"
  • 通过 preserve_thinking 支持跨轮次保留推理
  • 专用语法支持工具调用
  • 响应模板存储在 tokenizer 中
  • 使用 DFlash2 的推测解码草稿模型
  • 首日库:transformers、SGLang、vLLM;使用 Miles 进行全参数 RL
  • Apache 2.0 许可

架构:混合注意力、分组专家和恒定规模残差流

Beam 的解码器有 52 层,隐藏大小为 5,120。前 3 层使用密集 SwiGLU MLP;其余 49 层用混合专家块替换。

混合注意力:43 层滑动窗口和 9 层全局

大多数层使用滑动窗口注意力,覆盖前 512 个 token。每第六层以及最后一层关注完整上下文。这产生了 43 层滑动窗口和 9 层全局。

两种层类型对位置的处理不同。滑动窗口层使用 RoPE,因为相对位置在短窗口内最重要。全局层不使用任何位置编码。相反,每个查询乘以一个缩放因子,该因子随可见 token 数量缓慢增长,(1 + (pos + 1) / 2048) ** 0.1。实现称之为可扩展 softmax 查询缩放,它充当温度,使 softmax 在上下文变长时保持精度,而不是变得平坦。

注意力使用分组查询注意力,48 个查询头和 8 个键值头,对查询和键应用 RMSNorm。一个从层输入计算的学习 sigmoid 门控,在输出投影前缩放每个头的每个通道。

混合专家:256 个专家,每个 token 路由 8 个

每个 49 个 MoE 层包含 256 个专家,每个专家是一个 SwiGLU MLP,中间大小为 2,560,约 39M 参数。专家占模型参数的 98.4%。

路由器遵循 DeepSeek-V3 的组限制方案。它用 sigmoid 对所有 256 个专家打分,将它们分成 8 组,每组 32 个,保留按每组前两个分数之和排序的最佳 4 组,然后从中选择前 8 个专家。Beam 使用与 DeepSeek-V3 相同的组大小,但没有共享专家。专家输出与归一化的路由器权重结合,并缩放 2.5。

由于每个 token 只运行 8 个专家,模型每个 token 计算约 23B 参数。所有 256 个专家都保留在内存中,因此部署需要 501B 模型的内存,但运行速度与 23B 模型相当。BF16 检查点约为 1 TB(safetensors 格式)。NVFP4 检查点将大多数参数存储为 4 位精度,适用于 NVIDIA Blackwell GPU,部分参数保留 BF16 以保证准确性。FP8 检查点也可在 Hub 上获取,并描述为适合 Hopper 和 Ampere 系列芯片。

残差流:深度相关权重保持隐藏状态恒定规模

Beam 的残差连接是其最独特的架构特征。标准 transformer 将每个子层输出以权重 1 添加到流中,因此流随深度增长。

Beam 将输入嵌入计为第 1 步。在第 k 步,它以权重 1/sqrt(k) 添加子层输出,并以权重 sqrt((k-1)/k) 保留现有流。两个权重的平方和为 1,因此流从第一层到最后一层保持恒定规模。在所有 104 次添加之后,每个子层输出和输入嵌入在最终隐藏状态中具有相同的权重。

每个子层在前后都进行归一化,最终 logits 通过 tanh softcap 在 ±30,以 FP32 计算。实现固定了 FP32 计算的位置:路由器、SwiGLU 乘积、归一化、RoPE、查询缩放和 softcap。

长上下文:KV 缓存以约六分之一的速度增长

混合注意力使 Beam 的 1M token 上下文变得实用。每层缓存 2 x 8 KV 头 x 128 维 = 每个 token 2,048 个值。如果所有 52 层都保留每个 token,缓存将每个 token 增长 208 KiB。只有 9 个全局层保留整个序列;43 个滑动窗口层每个保留固定的 512 token 窗口并停止增长。因此缓存每个 token 增长 36 KiB,约为朴素速率的六分之一。

上下文 如果所有 52 层都是全局 Beam
32K tokens 6.5 GiB 1.2 GiB
128K tokens 26 GiB 4.6 GiB
完整上下文(1M) 208 GiB 36.08 GiB

这些数字是每个序列的,BF16,使用 transformers 动态缓存。

BF16、FP8 和 NVFP4 的基准测试结果

以下结果由 Reflection 团队提供。量化在三种检查点格式中损失很少的准确性。

基准 Beam (BF16) Beam (FP8) Beam (NVFP4)
智能体编码 / 终端
DeepSWE v1.1 43.3% 43.0% 42.7%
SWE Bench Pro v2-Hard 76.5% 78.4% 78.6%
SWE Bench Pro v1 66.1% 65.9% 65.6%
Terminal Bench v2.1 80.1% 78.9% 78.2%
SWE Atlas Codebase QnA 31.8% 32.2% 31.4%
SWEBench Multilingual 78.3% 78.1% 77.5%
SWEBench Verified 81.6% 80.2% 80.7%
推理
AIME 2026 97.7% 98.0% 97.5%
HLE (无工具) 36.0% 36.0% 34.8%
HLE (带工具) 51.1% 51.1% 51.1%
SciCode 49.2% 48.3% 46.9%
CriPT AA 16.3% 17.4% 15.4%
GPQA Diamond 90.6% 90.3% 89.3%
LiveCodeBench 88.3% 88.1% 87.4%
工具调用 / 搜索
AutomationBench (仅公开子集) 39.3 38.2 39.8%
MCP Atlas 80.8% 81.5% 80.5%
Tau3 Banking 36.1% 36.8% 35.4%
BrowseComp w/ 上下文管理 76.8% 76.7% 75.6%
DeepSearchQA w/ 上下文管理 80.5% 79.6% 81.1%
通用能力
AA-LCR 78.2% 79.4% 78.7%
LongBench v2 67.5% 67.6% 67.2%
IFBench 79.6% 80.7% 79.2%
AA Omniscience (索引,仅公开子集) 10.8 8.8 9.8

硬件要求:NVFP4 是最实用的服务路径

服务 Beam 最实用的方式是使用 NVFP4 检查点,它将 501B 参数从 BF16 的 1 TB 缩小到约 280 GB,同时保留 BF16 检查点的大部分质量。Blackwell GPU 原生运行 NVFP4,但比 Blackwell 更旧的 GPU(如 H200)无法运行。FP8 检查点是前 Blackwell 硬件的选择。

B200 有 180 GB 的 HBM3e,因此两个(360 GB)可以容纳 Beam 权重,但几乎没有空间留给激活和 KV 缓存。建议规划四个 B200(720 GB),为长上下文和并发请求留出空间。Beam 也可以在完整的 8xB200 节点、两个 B300(每个 288 GB)或 8xRTX Pro 6000 上服务。没有 Blackwell 硬件的团队可以通过 Hugging Face Inference Providers 测试模型。

推理支持:transformers、vLLM 和 SGLang 首日支持

Beam 在 transformers、SGLang 和 vLLM 中具有首日支持。

Transformers

安装最新的 transformers 版本:

pip install -U "transformers>=5.20.1"

最简单的入口是文本生成管道,它返回整个聊天,Beam 的回复已由响应模板解析。对于更底层的控制,使用 AutoModelForCausalLM 和 AutoTokenizer。

Beam 的 tokenizer 带有响应模板。parse_response 读取它并将原始输出转换为消息字典,将推理、答案和任何工具调用放在单独的字段中,避免了通常用于拆分推理、答案和工具调用的正则表达式。由于规则随 tokenizer 一起提供,解析的结构与 Beam 训练时产生的结构匹配。聊天模板可以预写部分助手轮次,解析器需要看到这些。

对于工具调用,将 tools 也传递给 parse_response。Beam 以自己 XML 风格的语法内联编写工具调用参数,因此裸的 7 可能是数字或字符串;使用工具模式,解析器将每个参数转换为其声明的类型。

Transformers 中的多 GPU 和多节点

Beam 的配置定义了专家并行计划。专家并行将每个专家放在一个设备上,而注意力、密集层、嵌入和 LM 头在每个设备上复制——即 8B 参数,或 BF16 中的 16 GB。加载使用 DistributedConfig,tp_size 和 ep_size 设置为世界大小。使用 torchrun 在 16 个 H200 GPU 上启动意味着每个 GPU 持有 78 GB 权重;使用 8 个 GPU 每个将持有 139 GB,这在 141 GB 的 H200 上没有剩余空间。设备数量必须能整除专家数量 256。

vLLM

Beam 在 vLLM 中具有首日支持。此命令使用张量并行在 16 个 GPU(两个 8x H200 节点)上服务 BF16 检查点,并暴露 OpenAI 兼容 API:

vllm serve reflection/Beam-1.0-501B-A23B --tensor-parallel-size 16 --served-model-name beam

为了更快的生成,添加 DFlash2 推测解码。一个小型草稿模型提前提出最多 15 个 token,Beam 在一次前向传递中检查它们,因此每一步可以接受多个 token。代价是草稿模型需要一点额外内存:

vllm serve reflection/Beam-1.0-501B-A23B \
  --tensor-parallel-size 16 \
  --speculative-config '{ "method": "dflash", "model": "reflection/dflash2-drafter-preview", "num_speculative_tokens": 15 }'

两个命令都启动 OpenAI 兼容服务器,因此任何 OpenAI 客户端都可以指向 http://localhost:8000/v1。

SGLang

Beam 在 SGLang 中也有首日支持,推荐的配置开启 DFlash2 推测解码。在 Blackwell 上,NVFP4 检查点适合 4 个 B300:

python -m sglang.launch_server \
--model-path reflection/Beam-1.0-501B-A23B-NVFP4 \
--served-model-name beam \
--tp 4 \
--attention-backend trtllm_mha \
--page-size 64 \
--context-length 1048576 \
--mem-fraction-static 0.85 \
--enable-unified-memory \
--speculative-algorithm DFLASH \
--speculative-draft-model-path reflection/Beam-1.0-501B-A23B-DFlash2 \
--speculative-dflash-block-size 8 \
--tool-call-parser beam --reasoning-parser beam \
--host 0.0.0.0 --port 30000

在 Hopper GPU 上,改用 FP8 检查点,在 8 个 H200 上运行。只有三个标志改变:检查点、张量并行大小(8 而不是 4)和注意力后端(fa3 而不是 trtllm_mha,后者需要 Blackwell)。

Inference Providers 和 Inference Endpoints

Beam 可在 Hugging Face Inference Providers 上使用,由 Baseten、Fireworks 和 Together 提供支持,更多即将推出。可通过 OpenAI 兼容路由器在 https://router.huggingface.co/v1 使用模型 ID reflection/Beam-1.0-501B-A23B:auto 访问。

Hugging Face 还设置了一个 Beam 配方,用于从目录中一键部署到 Inference Endpoints,支持 FP8 或 NVFP4,或通过 hf CLI:

hf endpoints catalog deploy --repo reflection/Beam-1.0-501B-A23B --name beam

Vibe 评估:五个任务在低和高推理努力下

Hugging Face 运行了它所谓的 vibe 评估——不是基准——在五个任务上,每个任务在低和高推理努力下各一次,通过 Reflection 平台。完整的输入、输出、API 使用、任务夹具、评分器和对话轨迹都在一个公共 Hugging Face 存储桶中。

类别 提示描述 低推理(tokens) 高推理(tokens)
多步工具调用 完成 ORD-742:比较库存、预订、附加费和到达日期;预订最便宜的合格仓库。 通过,544 通过,811
代码库上的长上下文检索 从三个完整源文件推导 Click 命令配置和两个调用结果;引用六个实现符号。 失败,1,613 通过,5,007
沙箱中的终端任务 检查和修复 CSV 账本 CLI;修复所有错误,保留测试,运行测试和 CLI 检查。 通过,582 通过,1,548
数学推理(AIME 风格) {1, …, 16} 的八个元素子集中有多少个的和能被 17 整除?给出理由。 部分,829 通过,2,809
结构化输出 将乱序的修订日志转换为严格的 JSON:合并补丁、取消、空值、日期、货币和总计。 通过,1,040 通过,2,088

来源中记录了两个注意事项。在低努力的长上下文任务中,响应获得了所有代码行为和所有六个源引用,但不符合解析器的格式,作者部分归因于提示歧义。在低努力的数学任务中,模型返回了正确答案,但省略了要求的理由;高努力运行提供了正确的单位根证明,并经过独立审查。

后训练:使用 TRL 进行 SFT,使用 Miles 进行 GRPO

Beam 可以针对自定义用例进行微调,Hugging Face 发布了 TRL 和 Miles 中的示例,用于监督微调和强化学习。

使用 TRL 进行 SFT

将 Beam 适应您自己数据的最快方法是使用 TRL 的 SFTTrainer 进行监督微调。为了保持内存可控,发布的示例使用 PEFT 训练 LoRA 适配器,而不是更新所有 501B 参数。目标是在用户请求的语言中保持 Beam 的推理,使用 LoRA 在 Multilingual-Thinking 数据集上进行微调,这训练了一小组适配器权重,同时保持基础模型冻结。

设置结合了加载时的模型分片、专家并行、FlashAttention 4 和序列打包。LoRA SFT 适合单个节点,8 个 B300 GPU,达到约 19,000 tokens/秒;相应的 H100 设置使用四个节点。

在 Multilingual-Thinking 的一个 epoch 后,Beam 在 16/16 个保留提示中以请求的语言推理,而基础模型为 3/16。来源指出这个小评估衡量语言遵循,而不是推理本身的正确性。

使用 Miles 进行 GRPO

Reflection 和 RadixArk 构建了一个配方,使用 Miles 在 BF16 中训练模型。它可以更新完整模型或使用 LoRA 训练适配器,同时保持基础权重冻结。Megatron 训练,SGLang 生成 rollout,Miles 在每次更新后将新权重发布到 rollout 引擎。

工作负载 参考配置
推理 / 评估,BF16 每个引擎 16x H200
全参数 GRPO,BF16 (Miles) 96x H200:64 训练,32 rollout。或 64x H200 共置。
LoRA GRPO,BF16 (Miles) 32x H200:16 训练,16 rollout。
全参数 GRPO,BF16,128-token 上下文 (Miles) 48x H200:32 训练,16 rollout。Reflection 和 RadixArk 首先在真实检查点上验证的设置。

该配方在 DAPO-Math-17K 上运行 GRPO,并在 AIME25 上评估。rollout 工作如下:

  • 采样: 32 个提示传递给模型,每个 8 个响应。两个 SGLang 引擎在 16 个 GPU 上服务 rollout。
  • 评分: 框住的答案与标签检查,对接近长度限制的响应有软惩罚。
  • 更新: 对所有 256 个样本执行一个优化器步骤,使用组相对优势,截断重要性采样,无 KL 或熵惩罚。
  • 并行训练: 张量并行 8,专家并行 8,数据并行 8,序列并行和完全重计算。
  • 优化器: Adam,常数 1e-6。梯度 BF16,主权重 FP32,矩 BF16。优化器状态通过节点本地 NVMe 流式传输,因此每个训练节点需要 2 TB 的暂存空间。
  • 评估: 每五个 rollout 评估 AIME25,每个问题八个样本。每二十个保存一个检查点。

下一个 rollout 在当前训练时生成,因此响应落后一个更新。添加 --resume 从最后一个检查点继续,execute-colocate 在八个节点上运行相同的配方,每个 GPU 轮流训练和服务。

全参数 GRPO 将 AIME 2025 准确率从 46.25% 提高到 55.8%,输出限制为 4,000 tokens。LoRA GRPO 在 Beam 的注意力、密集 MLP 和专家层上训练 rank-16 适配器,将 AIME 2025 准确率从 42.9% 提高到 64.2%,同时平均输出长度从 3,188 降至 2,197 tokens。在 LoRA 配方中,只有适配器权重与 SGLang 同步,优化器状态保留在 GPU 内存中,消除了 NVMe 优化器卸载的需要。

Hugging Face 使用 Beam 构建的内容

Hugging Face 运行了三个演示项目,展示 Beam 作为编码和智能体模型的能力。

原生 macOS 听写应用

Beam 被要求构建 BeamSpeak,一个原生 macOS 菜单栏听写应用,具有紧凑的录音胶囊,没有主窗口或账户。该应用使用 ⌘⇧Space 开始和停止麦克风录音,显示经过的时间、麦克风电平和转录状态,并完全在本地使用 Parakeet v3 通过 MLX 运行语音识别,在录音之间保持模型加载。如果原始应用保持焦点并授予辅助功能权限,它将转录粘贴到原始应用中,否则复制到剪贴板而不按 Enter。构建使用了 Beam 和 Pi 编码工具链;保存的运行包括后续提示,最终源代码还包括后来的 Codex 修复。

ProgramBench 上的多智能体扩展

为了测试 Beam 是否通过将编程任务拆分到多个智能体来取得更快的进展,Hugging Face 将 Beam 与开源 Pi 编码智能体配对,并比较了三种设置:一个智能体单独工作,五个持久对等体通过共享 Git 仓库协作,以及一个主导智能体将工作委托给异步子智能体。工具链在 Hugging Face 作业上运行,推理通过 Reflection 的平台 API。

任务来自 ProgramBench,智能体必须从其编译的可执行文件和文档中重新创建程序,而看不到源代码或评估器的测试。每种设置都有相同的 8M API token 上限和每个任务两小时的求解器限制,在其智能体之间共享。发布的结果保留了所有 15 个原始片段,尽管当前图表显示 jq、xsv、FIGlet 和 hexyl 的事后子集;ripgrep 在所有三种设置中被排除,因为对其保存的工件进行评分太慢。时间轴使用模型 token 的固定参考速率加上测量的工具时间,而不是经过的墙钟时间。

微调的事件分类决策模型

Hugging Face 测试了编码智能体是否可以将事件分类策略转换为一个小型、快速的决策模型。任务是阅读开发人员事件并选择负责团队、严重性以及是否应立即 ping 某人。工作流从 Beam 开始,然后在 Beam 配额用完后继续使用 GLM-5.3 在 Pi 中。

使用 Unsloth,团队微调了 Qwen3.5-0.8B 来直接评分这些选择。工作流首先构建了一个包含 2.3k 事件的合成数据集,按事件集群拆分用于训练、校准和测试,然后训练 LoRA 适配器和决策头三个 epoch,使用 4 位骨干,在一个 H100 80GB 上,在 Science Slurm 集群上。作为基线,未适应的模型被提示完整的分类策略和工单,没有示例,并要求生成三个决策作为 JSON。在相同的 320 个合成测试工单上,微调的决策模型在 76.25% 的情况下所有三个答案都正确,而提示零样本为 4.69%,平均工单延迟从 1,218.06 ms 降至 102.58 ms——11.9 倍加速。

使用 Beam 构建:$10,000 Hub 积分计划

Reflection 为使用 Beam 的最佳项目提供 $10,000 的 Hugging Face Hub 积分。要参与,构建一个 Space、模型或数据集仓库,并在模型的仓库页面上分享。建议的项目类型包括在 Spaces 上使用 Beam 的演示、针对您最喜欢的硬件的量化、针对特定问题的合成数据集、使用 Beam 构建的 RL 环境,或共享结果的 Beam 基准。

Beam 对开放模型部署的意义

Beam 的意义在于它将前沿规模的参数置于 Apache 2.0 许可下,并提供不需要前沿规模集群的部署路径。每个 token 23B 激活参数、KV 缓存以约六分之一的速度增长,以及约 280 GB 的 NVFP4 检查点的组合,使得四 B200 配置成为服务的实际目标,FP8 在 H200 上作为前 Blackwell 替代方案。

该模型仅支持文本,面向编码和智能体工作,而不是通用多模态使用。其工具选择——tokenizer 中的响应模板、专用工具调用语法、五个推理努力级别,以及用于跨轮次推理的 preserve_thinking——都面向多步智能体循环,而不是单轮聊天。

Sources