Hugging Face 发布 Beam:501B 开源模型,支持 1M 上下文与自托管
Welcome Beam: a 501B open model you can own, customize, and scale
Hugging Face 发布 Beam,一个 501B 参数的稀疏 MoE 开源模型,面向 1M 上下文的长文本推理与智能体任务,每个 token 仅激活约 23B 参数。模型采用 52 层混合注意力,43 层为 512 token 滑动窗口、9 层为全局注意力,KV cache 每 token 增长 36 KiB,约为全注意力方案的六分之一。官方提供 BF16、FP8 和 NVFP4 三种 checkpoint,NVFP4 可将权重从约 1 TB 压缩到约 280 GB,并已获 transformers、vLLM 和 SGLang 的 day-0 支持。
推荐理由
精选AI 评分 78
原文给出 501B 稀疏 MoE 模型的架构取舍与多精度部署方案,可据此判断自托管长上下文推理的硬件门槛。
主题
正文 · AI 翻译
使用 Beam 构建
Reflection 将为使用 Beam 的最佳项目提供 10,000 美元的 Hub 额度。你只需做出一个作品,并在 Hub 上分享:
你可以做一个在 Spaces 上使用 Beam 模型的演示
你可以为你的硬件对它进行量化
你可以为你关注的问题生成合成数据集
你可以用 Beam 构建或为 Beam 构建一个 RL 环境
你可以对 Beam 进行基准测试并分享结果。
你也可以给我们一个惊喜!
如果你用 Beam 构建了作品,就在 Hub 上分享,有机会赢得 10,000 美元。你只需构建 space、model 或 dataset 仓库,并在模型仓库页面上分享。我们会收集所有链接,选出最佳作品,并将额度发送到你的 Hub 账户。
什么是 Beam?
Beam 是一个纯文本模型,专为长上下文(1M 上下文长度)推理和智能体工作而构建。它是一个稀疏 MoE 模型,每个 token 仅由网络的一小部分计算,因此它以小得多的模型的速度运行,同时保持大模型的容量。
注意力
解码器有 52 层,隐藏大小为 5,120。大多数层对前 512 个 token 使用滑动窗口注意力;每第六层以及最后一层关注完整上下文。这样就有 43 个滑动窗口层和 9 个全局层。
注意力块内部(两种层类型)
这两种层对位置的处理方式不同。滑动窗口层使用 RoPE,因为在短窗口内相对位置最重要。全局层不使用位置编码。相反,每个查询都乘以一个随可见 token 数量缓慢增长的缩放因子 (1 + (pos + 1) / 2048) ** 0.1。它起到温度的作用:softmax 在上下文变长时保持其精度,而不是变得平坦。实现中称之为可扩展 softmax 查询缩放。
注意力使用分组查询注意力,有 48 个查询头和 8 个键值头,并对查询和键使用 RMSNorm。一个从层输入计算出的学习 sigmoid 门在输出投影之前缩放每个头的每个通道。
专家混合
前 3 层使用稠密 SwiGLU MLP。其余 49 层将其替换为包含 256 个专家的专家混合块,每个专家是一个中间大小为 2,560 的 SwiGLU MLP,约 39M 参数。专家占模型参数的 98.4%。
路由器遵循 DeepSeek-V3 的分组限制方案。它用 sigmoid 为所有 256 个专家打分,将它们分成 8 组、每组 32 个,保留最好的 4 组(按每组前两个分数之和排名),然后在其中选出前 8 个专家。Beam 使用与 DeepSeek-V3 相同的组大小,但没有共享专家。专家输出用归一化的路由器权重组合,并缩放 2.5 倍。
每个 token 只运行 8 个专家,因此模型用约 23B 参数计算每个 token。所有 256 个专家都保留在内存中,因此部署需要 501B 模型的内存,但以 23B 模型的速度运行。BF16 checkpoint 以 safetensors 格式约为 1 TB。NVFP4 checkpoint 为 NVIDIA Blackwell GPU 以 4 位精度存储大多数参数,部分参数保留为 BF16 以保证准确性。Hub 上还有 FP8 checkpoint,非常适合 Hopper 和 Ampere 系列芯片。
如果你想自己部署 Beam,请查看下面的 vLLM 或 SGLang 配方。
残差流
残差连接是最独特的部分。标准 transformer 以权重 1 将每个子层输出加到流中,因此流随深度增长。
Beam 将输入嵌入计为第 1 步。在第 k 步,它以权重 1/sqrt(k) 加上子层输出,并以权重 sqrt((k-1)/k) 保留现有流。两个权重的平方和为 1,因此流从第一层到最后一层保持恒定尺度。在所有 104 次加法之后,每个子层输出和输入嵌入在最终隐藏状态中具有相同的权重。
每个子层在前后也都进行归一化,最终 logits 通过 ±30 的 tanh softcap,以 FP32 计算。实现固定了以 FP32 计算的位置:路由器、SwiGLU 乘积、归一化、RoPE、查询缩放和 softcap。
长上下文
混合注意力在长上下文下效果很好。每层为每个 token 缓存 2 x 8 个 KV 头 x 128 维 = 2,048 个值。如果所有 52 层都保留每个 token,缓存将每个 token 增长 208 KiB。只有 9 个全局层保留整个序列。43 个滑动窗口层各保持固定的 512 token 窗口并停止增长。因此缓存每个 token 增长 36 KiB,约为朴素速率的六分之一。
这些数字是每个序列的,采用 BF16,使用 transformers 动态缓存。
基准测试结果
以下是不同精度级别的基准测试结果,由 Reflection 团队提供。
硬件要求
服务该模型最实用的方式是服务 NVFP4 checkpoint,它保留了 bf16 checkpoint 的大部分质量。NVFP4 以 4 位存储部分权重,这样将 BF16 中的 501B 参数从 1 TB 缩小到约 280 GB。Blackwell GPU 原生运行 NVFP4,但比 Blackwell 更旧的 GPU(如 H200)不能。FP8 checkpoint 适用于比 Blackwell 更旧的 GPU。
一块 B200 有 180 GB HBM3e,因此两块(360 GB)可以容纳 Beam 权重,留给激活和 KV 缓存的空间很少。计划使用四块 B200(720 GB),为长上下文和并发请求留出充足空间。你也可以在完整的 8xB200 节点上服务,或在两块各 288 GB 的 B300 上,甚至 8xRTX Pro 6000。如果你没有 Blackwell 硬件,请使用 Inference Providers(无服务器)测试 Reflection。
推理支持
Beam 在 transformers、SGLang 和 vLLM 中提供 day-0 支持。
Transformers
安装最新版本的 transformers。
运行 Beam 最简单的方法是 text-generation pipeline:
该 pipeline 返回整个聊天。最后一条消息是 Beam 的回复,已由响应模板解析。
再往下一层,使用 AutoModelForCausalLM 和 AutoTokenizer。
聊天
Beam 的 tokenizer 带有一个响应模板。parse_response 会读取它,并将原始输出转换为消息字典,其中推理、答案以及任何工具调用分别放在不同字段中。这样就避免了通常用正则表达式从工具调用中拆分推理和答案的做法。而且这些规则随 tokenizer 一起提供,因此解析出的结构与 Beam 训练时生成的结构一致。聊天模板可以预先写入助手回合的一部分内容,解析器需要看到这部分内容。
工具调用
同样将 tools 传给 parse_response。Beam 以内联方式、用它自己的 XML 风格语法写入工具调用参数,因此一个裸的 7 既可能是数字,也可能是字符串。有了工具 schema,解析器会将每个参数转换为声明的类型。
多 GPU 与多节点
Beam 的配置定义了一个专家并行方案。专家并行将每个专家放在一个设备上。注意力、稠密层、嵌入和 LM head 在每个设备上复制。这部分是 8B 参数,在 BF16 下为 16 GB。使用 DistributedConfig 加载模型:
用 torchrun 在 16 块 H200 GPU 上启动脚本。这样每块 GPU 持有 78 GB 权重。若用 8 块 GPU,每块将持有 139 GB,这在 141 GB 的 H200 上不留任何空间。设备数量必须能整除专家数量 256。
vLLM
Beam 在 vLLM 中提供 day-0 支持。下面的命令通过张量并行在 16 块 GPU(两个 8x H200 节点)上服务 BF16 checkpoint,并暴露一个 OpenAI 兼容 API:
为了更快的生成,添加 DFlash2 投机解码。一个小型草稿模型最多提前提出 15 个 token,Beam 在一次前向传播中检查它们全部,因此每一步可以接受多个 token。代价是草稿模型需要少量额外内存:
这两个命令都会启动一个 OpenAI 兼容服务器,因此你可以将任何 OpenAI 客户端指向 http://localhost:8000/v1 。有关更多服务配置,请参阅为 vLLM 提议的 Beam recipe 。
SGLang
Beam 在 SGLang 中也提供 day-0 支持。我们建议使用 DFlash2 投机解码来服务它,下面两个命令都会开启该功能。在 Blackwell 上,NVFP4 checkpoint 可容纳于 4 块 B300:
在 Hopper GPU 上,改用 8 块 H200 上的 FP8 checkpoint。只有三个标志改变:checkpoint、张量并行大小(8 而不是 4)以及注意力后端(fa3 而不是需要 Blackwell 的 trtllm_mha):
推理提供商
Beam 已在 Hugging Face Inference Providers 上可用,由 Baseten、Fireworks 和 Together 提供支持,后续还会有更多。
推理端点
我们已为你设置好一个 Beam recipe,可从目录中在 Inference Endpoints 中一键部署 FP8 或 NVFP4 版本,或像这样用 hf cli 安装:
我们测试了什么
我们分享一些 Reflection Beam-501B-A23B 在五项任务上的 vibe evals,每项分别在低和高推理努力下各运行一次,通过 Reflection 平台进行。这些是 vibe evals,不是基准测试。如果你计划使用 Beam,这是很好的试驾方式,可以看看它在特定用例上的表现,重要的是,看看它在哪里胜出、在哪里失败。
下面是我们在 hub 中运行的提示词和输出轨迹概览。完整的输入、输出、API 使用情况、任务夹具、评分器和对话轨迹都在这个公开的 Hugging Face bucket 中。
* Low 的长上下文响应把所有代码行为和全部六个来源引用都做对了。然而,该响应不符合解析器的格式,因此这在一定程度上是提示词歧义。
† Low 返回了正确答案,但省略了所要求的论证。High 提供了一个正确的单位根证明,并经过独立审查。
不要只听我们的一面之词。深入 bucket ,针对你的用例或项目重写,并将 Beam 推向极限。
对 Beam 进行后训练
你可以针对自己的用例微调 Beam。这里我们分享一些 TRL 和 Miles 中的示例,帮助你开始监督微调和强化学习。
使用 TRL 进行 SFT
将 Beam 适配到你自己的数据的最快方法是使用 TRL 的 SFTTrainer 进行监督微调。为了保持内存可控,我们使用 PEFT 训练 LoRA 适配器,而不是更新全部 501B 参数:我们使用 TRL 的 SFTTrainer 将 Beam 适配到一个简单目标:将其推理保持在用户请求的语言中。我们在 Multilingual-Thinking 上用 LoRA 进行微调,这会在保持基础模型冻结的同时训练一小部分适配器权重。
该设置结合了加载时的模型分片、专家并行、FlashAttention 4 和序列打包。LoRA SFT 可在单个具有 8 块 B300 GPU 的节点上运行,达到约每秒 19,000 个 token。相应的 H100 设置使用四个节点。
在 Multilingual-Thinking 上训练一个 epoch 后,Beam 在 16 个留出提示中的 16 个上用请求的语言进行推理,而基础模型为 16 个中的 3 个。这个小评估衡量的是语言遵循性,而不是推理本身的正确性。
在 open-r1/Mixture-of-Thought 的推理子集上单独进行 500 步训练期间的训练损失(左)和平均 token 准确率(右),使用一个 8-GPU B300 节点。这些训练指标来自官方 TRL 示例 PR 。
使用 Miles 进行 GRPO
Reflection 与 RadixArk 构建了一套配方,在 Miles 中用 BF16 通过 GRPO 训练模型。你可以更新完整模型,也可以使用 LoRA 训练适配器,同时保持基础权重冻结。Megatron 负责训练,SGLang 生成 rollout,Miles 在每次更新后将新权重发布到 rollout 引擎。我们审查了这套配方。
该配方在 DAPO-Math-17K 上运行 GRPO,并在 AIME25 上评估。构建镜像、下载数据,然后将作业提交到由十二个 8x H200 节点组成的 Ray 集群:
一次 rollout 中会发生什么:
采样:将 32 个提示传给模型,每个提示生成 8 个响应。两个 SGLang 引擎各使用 16 块 GPU 提供 rollout 服务。
评分:将框选答案与标签进行核对,并对接近长度限制的响应施加软惩罚。
更新:对所有 256 个样本执行一次优化器步骤。使用组相对优势和截断重要性采样,不使用 KL 或熵惩罚。
并行训练:张量并行 8、专家并行 8、数据并行 8,并启用序列并行和完全重计算。
优化器:Adam,恒定学习率 1e-6。梯度使用 BF16,主权重使用 FP32,动量使用 BF16。优化器状态通过节点本地 NVMe 流式传输,因此每个训练节点需要 2 TB 暂存空间。
评估:每五次 rollout 在 AIME25 上评估一次,每个问题八个样本。每二十次保存一个检查点。
下一次 rollout 在当前 rollout 训练时生成,因此响应会落后一次更新。添加 --resume 可从上一个检查点继续。execute-colocate 在八个节点上运行同一配方,每块 GPU 轮流进行训练和服务。
使用 LoRA 训练
你也可以在四个 8× H200 节点上使用 LoRA 运行 GRPO:16 块 GPU 用于训练,16 块用于 rollout。该配方在 Beam 的注意力、稠密 MLP 和专家层上训练 rank-16 适配器,同时保持基础权重冻结。只有适配器权重会与 SGLang 同步,优化器状态保留在 GPU 内存中,因此无需将优化器卸载到 NVMe。
使用 Beam 构建:演示
如果你用 Beam 构建了作品,请在 Hub 上分享,有机会赢取 10,000 美元。你只需构建一个 space、模型或数据集仓库,并在模型仓库页面上分享即可。为了给你灵感,以下是我们构建的一些作品。
嘿 Beam,构建一个原生本地 MacOS 应用程序!
在 Hugging Face,我们喜欢能在其硬件上原生运行的开放本地模型,但在 Mac 上构建原生应用可能很难!让我们看看 Beam 能否帮到我们。
我们让 Beam 构建一个原生 MacOS 应用程序,将语音转换为文本,并方便地将其放到光标处。我们希望使用 MLX 充分发挥 Mac Metal 的性能,并使用 Parakeet 模型实现出色的语音转文本。
我们使用 Beam 配合 Pi 编码工具构建了初始的原生 macOS 菜单栏应用,通过 MLX 运行 Parakeet。保存的运行记录包含后续提示;最终源代码还包含后来的 Codex 修复。上面的提示是构建需求的精简版本。
你可以在该 trace 中查看 Beam 如何在 pi 中构建此应用的智能体轨迹。如果你想试用该演示,请下载源代码或阅读设置说明。
嘿 Beam,如何在多个智能体上扩展?
我们想看看 Beam 能否通过将编程任务拆分给多个智能体来更快取得进展。我们将 Beam 与开源 Pi 编码智能体配对,并比较了三种设置:1. 一个智能体独自工作;2. 五个持久对等体通过共享 Git 仓库协作;3. 一个主智能体将工作委派给异步子智能体。该测试框架在 Hugging Face jobs 上运行,推理通过 Reflection 的平台 API 进行。
对于任务,我们使用了 ProgramBench:智能体必须根据编译后的可执行文件和文档重建程序,而不能查看其源代码或评估器的测试。每种设置都有相同的 800 万 API token 上限和每个任务两小时的求解器限制,由其所有智能体共享。我们保存了实现快照,并对照 ProgramBench-Tests 数据集中的固定隐藏测试套件进行评估。
我们的分数-延迟图显示了通过测试的平均比例。时间轴使用模型 token 的固定参考速率加上测得的工具时间,而不是实际经过的墙钟时间。我们最初运行了五个任务。当前图表显示了 jq、xsv、FIGlet 和 hexyl 的事后子集;ripgrep 在三种设置中均被排除,因为对其保存的产物进行评分太慢。已发布的结果保留了全部 15 个原始回合。
你可以在 Trackio 仪表板中检查运行记录、探索已发布的结果数据,并复用该研究测试框架。
嘿 Beam,为我的代码库微调一个决策模型!
决策模型目前非常流行,因为它们速度极快,并且在许多用例中很实用。我们从 Beam 开始,然后在 Beam 配额用完后,在 Pi 中继续使用 GLM-5.3,为开发者事件分诊训练和评估一个自定义决策模型。
我们想看看编码智能体能否将事件分诊策略转化为一个小型、快速的决策模型。任务是读取开发者事件,并选择负责团队、其严重程度,以及是否应立即通知某人。使用 Unsloth,我们对 Qwen3.5-0.8B 进行了微调,以直接对这些选择进行评分。
首先,该工作流构建了一个合成数据集,其中包含 2.3k 个事件,按事件集群划分为训练、校准和测试集。我们在 Science Slurm 集群的一台 H100 80GB 上,使用 4 位骨干网络,对 LoRA 适配器和决策头进行了三个 epoch 的训练。
作为基线,我们将完整的分诊策略和工单输入未适配的模型,不提供示例,并要求它以 JSON 形式生成三个决策。在相同的 320 个合成测试工单上,微调后的决策模型在 76.25% 的工单上三个答案全部正确,而零样本提示仅为 4.69%。平均工单延迟从 1,218.06 ms 降至 102.58 ms,加速 11.9 倍。
如果你想亲自尝试这个实验,请查看 artifact bucket,其中包含数据、代码、检查点和结果。
总结
Beam 是一个 501B 的开源模型,你可以在自己的硬件上运行并修改它。从 BF16 检查点开始,或尝试 FP8、NVFP4 量化版本之一。如果你用 Beam 构建了东西,请在 discussions 标签页中分享。
本文提到的模型 3
reflection/Beam-1.0-501B-A23B
reflection/Beam-1.0-501B-A23B-FP8
reflection/Beam-1.0-501B-A23B-NVFP4
本文提到的数据集 2
HuggingFaceH4/Multilingual-Thinking
programbench/ProgramBench-Tests
本文提到的 Spaces 1
Beam + Pi ProgramBench
展示可下载数据的交互式基准测试结果
我们博客中的更多文章
跨 HF Jobs 使用 LoRA 的异步 GRPO:一个 bucket、一个代理,无需 NCCL
本文提到的模型 3
reflection/Beam-1.0-501B-A23B
reflection/Beam-1.0-501B-A23B-FP8
reflection/Beam-1.0-501B-A23B-NVFP4
本文提到的数据集 2
HuggingFaceH4/Multilingual-Thinking
programbench/ProgramBench-Tests
本文提到的 Spaces 1
Beam + Pi ProgramBench
展示可下载数据的交互式基准测试结果