5010亿参数开放模型Beam亮相

Beam 专注于编程和智能体应用场景。它面向希望在自有硬件、基础设施或云环境中运行前沿规模模型，并针对自身应用场景进行定制的团队。Beam 还附带一套专用的开源 Rust 执行框架，旨在充分发挥模型性能。

Beam 在 transformers 中有原生实现，也获得了 vLLM 和 SGLang 等下游库的支持。我们与 Reflection 团队合作，提供了推理、SFT（监督微调）和 RL（强化学习）实践方案，方便你根据自身需求使用这个模型进行开发。除了 transformers、SGLang 和 vLLM 在发布首日提供的支持，本文还将介绍如何运行 Beam、如何对其进行后训练，以及我们用它构建了什么。

这是一个拥有 5010 亿参数的混合专家（MoE）大语言模型，每个 token 激活 230 亿参数。模型共有 52 层，每个 MoE 层包含 256 个专家，每个 token 会路由到其中 8 个专家。

文本输入、文本输出，上下文窗口为 100 万 token。

检查点格式：BF16、FP8 和 NVFP4。

支持跨轮次在上下文中保留推理内容（preserve_thinking），并通过专用语法支持工具调用。模型支持五种推理强度取值："low"、"medium"（默认）、"high"、"xhigh" 和 "max"。

分词器内置响应模板。

提供基于 DFlash2 的推测解码草稿模型。

发布首日支持的库：transformers、SGLang、vLLM。可使用 Miles 进行全参数 RL。

附带基于 Rust 的定制执行框架。

Reflection 将向使用 Beam 的优秀项目发放价值 10,000 美元的 Hub 额度。你只需要做出一个作品，并在 Hub 上分享：

你可以在 Spaces 上制作一个使用 Beam 模型的演示应用。

你可以针对自己喜欢的硬件对模型进行量化。

你可以为自己感兴趣的问题生成合成数据集。

你可以使用 Beam 构建 RL 环境，或者为 Beam 构建 RL 环境。

你可以对 Beam 进行基准测试并分享结果。

你也可以给我们带来惊喜！

如果你用 Beam 构建了作品，就将其分享到 Hub，有机会赢取价值 10,000 美元的额度。你只需要创建 Space、模型或数据集仓库，并将其分享到模型的仓库页面。我们会收集所有链接，选出最优秀的项目，并将额度发放到对应的 Hub 账户。

Beam 是一个纯文本模型，专为长上下文（100 万上下文长度）推理和智能体任务打造。它采用稀疏 MoE 架构，每个 token 只由网络中的一小部分参与计算，因此既保留了大模型的容量，又能以小得多的模型的速度运行。

解码器共有 52 层，隐藏维度为 5,120。大多数层使用滑动窗口注意力，关注前面的 512 个 token；每隔六层以及最后一层则关注完整上下文。因此，模型共有 43 个滑动窗口层和 9 个全局层。

注意力模块内部（适用于两种层类型）

这两种层处理位置信息的方式不同。滑动窗口层使用 RoPE，因为在短窗口内，相对位置最为重要。全局层不使用位置编码，而是将每个查询乘以一个随可见 token 数量缓慢增大的缩放因子，计算公式为 (1 + (pos + 1) / 2048) ** 0.1。它起到温度调节的作用：随着上下文变长，softmax 仍能保持区分度，而不会趋于平坦。实现中将这一机制称为 scalable-softmax 查询缩放。

注意力采用分组查询注意力，包含 48 个查询头和 8 个键值头，并对查询和键应用 RMSNorm。在输出投影之前，一个根据该层输入计算得到的可学习 sigmoid 门控，会对每个注意力头的每个通道进行缩放。

前 3 层使用稠密的 SwiGLU MLP。其余 49 层则用包含 256 个专家的混合专家模块替代它，每个专家都是一个中间维度为 2,560 的 SwiGLU MLP，约有 3,900 万参数。专家占模型总参数量的 98.4%。

路由器采用 DeepSeek-V3 的分组受限方案。它通过 sigmoid 为全部 256 个专家打分，将专家分成 8 组，每组 32 个，保留得分最高的 4 组（各组按组内最高的两个得分之和排名），再从这些组中选出得分最高的 8 个专家。Beam 的分组规模与 DeepSeek-V3 相同，但没有共享专家。专家输出使用归一化后的路由权重进行加权组合，再乘以 2.5。

每个 token 只运行 8 个专家，因此模型计算每个 token 时使用约 230 亿参数。全部 256 个专家都驻留在内存中，因此部署时需要容纳 5010 亿参数模型的内存容量，但运行速度相当于一个 230 亿参数的模型。BF16 检查点采用 safetensors 格式，大小约为 1 TB。NVFP4 检查点面向 NVIDIA Blackwell GPU，将大多数参数以 4 位精度存储，同时保留部分参数为 BF16，以保证准确性。Hub 上还提供 FP8 检查点，非常适合 Hopper 和 Ampere 系列芯片。

如果你想自行部署 Beam，请参考下文的 vLLM 或 SGLang 实践方案。

残差连接是其中最具特色的部分。标准 Transformer 会以权重 1 将每个子层的输出加到残差流上，因此残差流的幅度会随深度增加而增长。

Beam 将输入嵌入计为第 1 步。在第 k 步，它以 1/sqrt(k) 的权重加入子层输出，并以 sqrt((k-1)/k) 的权重保留已有的残差流。这两个权重的平方和为 1，因此从第一层到最后一层，残差流都保持恒定的尺度。在完成全部 104 次相加后，每个子层输出和输入嵌入在最终隐藏状态中都具有相同的权重。

每个子层前后也都会进行归一化，最终的 logits 则通过一个以 ±30 为界的 tanh 软截断，计算采用 FP32。实现中明确规定了使用 FP32 计算的部分：路由器、SwiGLU 乘积、归一化、RoPE、查询缩放和软截断。

混合注意力非常适合长上下文。每层为每个 token 缓存 2 × 8 个 KV 头 × 128 维 = 2,048 个数值。如果全部 52 层都保留每个 token，缓存就会以每个 token 208 KiB 的速度增长。实际只有 9 个全局层保留完整序列。43 个滑动窗口层各自只保留固定的 512 个 token 窗口，缓存不再增长。因此，缓存每增加一个 token 只增长 36 KiB，约为朴素方案的六分之一。

这些数据以单条序列为单位，采用 BF16 精度和 transformers 动态缓存。

以下是 Reflection 团队提供的不同精度下的基准测试结果。

硬件要求

最实用的模型部署方式是使用 NVFP4 检查点，它保留了 BF16 检查点的大部分模型质量。NVFP4 以 4 位精度存储部分权重，从而将 5010 亿参数在 BF16 下约 1 TB 的体积缩减至约 280 GB。Blackwell GPU 原生支持 NVFP4，但 H200 等早于 Blackwell 的 GPU 不支持。FP8 检查点适合早于 Blackwell 的 GPU。

一张 B200 拥有 180 GB HBM3e 显存，因此两张（360 GB）就能容纳 Beam 的权重，但留给激活值和 KV 缓存的空间不多。建议配置四张 B200（720 GB），这样就能为长上下文和并发请求留出充足空间。你也可以在完整的 8×B200 节点上部署，或使用两张各有 288 GB 显存的 B300，甚至可以使用 8×RTX Pro 6000。如果没有 Blackwell 硬件，可以通过 Inference Providers（无服务器推理服务）试用 Reflection。

Beam 在发布首日便获得了 transformers、SGLang 和 vLLM 的支持。

安装最新版本的 transformers。

pip install -U "transformers>=5.20.1"

运行 Beam 最简单的方法是使用 text-generation pipeline：

from transformers import pipeline

pipe = pipeline(
    "text-generation", model="reflection/Beam-1.0-501B-A23B", device_map="auto"
)

messages = [
    {"role": "user", "content": "Write a limerick about Python exceptions."}
]
output = pipe(messages, max_new_tokens=2000)
output[0]["generated_text"][-1]

pipeline 会返回完整的对话。最后一条消息是 Beam 的回复，已经由响应模板解析完毕。

如果需要更底层的控制，可以使用 AutoModelForCausalLM 和 AutoTokenizer。

from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "reflection/Beam-1.0-501B-A23B"
tokenizer = AutoTokenizer.from_pretrained(model_id)

model = AutoModelForCausalLM.from_pretrained(
    model_id, dtype="auto", device_map="auto"
)

messages = [
    {"role": "system", "content": "You should only answer with a number."},
    {"role": "user", "content": "What is 17 * 23?"},
]

inputs = tokenizer.apply_chat_template(
    messages,
    add_generation_prompt=True,
    tokenize=True,
    return_dict=True,
    return_tensors="pt",
    reasoning_effort="medium" # by default
).to(model.device)

input_len = inputs["input_ids"].shape[-1]

outputs = model.generate(**inputs, max_new_tokens=2000)

tokenizer.parse_response(
    outputs[0][input_len:], prefix=inputs["input_ids"][0]
)

Beam 的分词器自带响应模板。parse_response 会读取这个模板，将原始输出转换为消息字典，把推理、答案和工具调用分别放在独立字段中。这样就无需像往常那样，用正则表达式拆分推理、答案和工具调用。而且，解析规则随分词器一同提供，因此解析后的结构与 Beam 训练时学习生成的结构一致。聊天模板可能会预先填入助手轮次的部分内容，解析器也需要看到这部分内容。

def get_weather(city: str, unit: str = "celsius"):
    """
    Get the current weather for a city.

Args:
        city: The city to look up.
        unit: Temperature unit, "celsius" or "fahrenheit".
    """
    ...

tools = [get_weather]
messages = [
    {"role": "user", "content": "I land in Paris tonight. Do I need a coat?"}
]

inputs = tokenizer.apply_chat_template(
    messages,
    tools=tools,
    add_generation_prompt=True,
    tokenize=True,
    return_dict=True,
    return_tensors="pt",
).to(model.device)

input_len = inputs["input_ids"].shape[-1]
outputs = model.generate(**inputs, max_new_tokens=1000)

message = tokenizer.parse_response(
    outputs[0][input_len:], prefix=inputs["input_ids"][0], tools=tools
)
message.get("tool_calls")

也要将 tools 传给 parse_response。Beam 使用自己的 XML 风格语法，内联写入工具调用参数，因此一个不带引号的 7 既可能是数字，也可能是字符串。有了工具的 schema，解析器就能将每个参数转换为其声明的类型。

Beam 的配置定义了专家并行方案。专家并行会将每个专家放到一台设备上。注意力模块、稠密层、嵌入层和 LM head 则会在每台设备上各保留一份副本。这些部分共有 80 亿参数，使用 BF16 时占用 16 GB。使用 DistributedConfig 加载模型：

import os

from transformers import AutoModelForCausalLM
from transformers.distributed import DistributedConfig

model = AutoModelForCausalLM.from_pretrained(
    "reflection/Beam-1.0-501B-A23B",
    distributed_config=DistributedConfig(
        tp_size=int(os.environ["WORLD_SIZE"]), ep_size=int(os.environ["WORLD_SIZE"]), tp_plan={}
    ),
)

使用 torchrun 在 16 张 H200 GPU 上启动脚本。这样，每张卡会承载 78 GB 的权重。如果使用 8 张 GPU，每张卡就要承载 139 GB，在显存为 141 GB 的 H200 上几乎没有剩余空间。设备数量必须能整除专家数量 256。

vLLM 在 Beam 发布首日就已提供支持。下面的命令通过 16 张 GPU（两个各配备 8 张 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。更多推理服务配置，请参阅拟议中的 Beam vLLM 配置方案。

SGLang 同样在 Beam 发布首日就已提供支持。我们建议部署时使用 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 上，则使用 8 张 H200 部署 FP8 检查点。只需更改三个参数：检查点、张量并行规模（从 4 改为 8），以及注意力后端（从需要 Blackwell 的 trtllm_mha 改为 fa3）：

python -m sglang.launch_server \
--model-path reflection/Beam-1.0-501B-A23B-FP8 \
--served-model-name beam \
--tp 8 \
--attention-backend fa3 \
--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

Beam 已在 Hugging Face Inference Providers 上提供，由 Baseten、Fireworks 和 Together 提供算力支持，后续还会有更多服务商加入。

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://router.huggingface.co/v1",
    api_key=os.environ["HF_TOKEN"],
)

completion = client.chat.completions.create(
    model="reflection/Beam-1.0-501B-A23B:auto",
    messages=[{"role": "user", "content": "What is the capital of France?"}],
)

print(completion.choices[0].message)

我们已经准备好 Beam 的部署方案，你可以在 Inference Endpoints 的目录中一键部署 FP8 或 NVFP4 版本，也可以通过 hf CLI 安装：

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

我们分享了 Reflection Beam-501B-A23B 在五项任务上的一些直观评测结果：通过 Reflection 平台，分别以低、高推理强度各运行一次。这些是直观评测，并非基准测试。如果你打算使用 Beam，这是上手试用、了解它在具体用例中表现的好方法，尤其能帮助你看清它的优势和不足。

下面概述了我们使用的提示词，以及 Hub 上的输出轨迹。完整的输入、输出、API 使用情况、任务测试材料、评分器和对话轨迹，都放在这个公开的 Hugging Face 存储桶中。

* 低推理强度下的长上下文回答，正确解释了所有代码行为，六处来源引用也全部正确。不过，回答没有遵循解析器要求的格式，这在一定程度上源于提示词存在歧义。

† 低推理强度下返回了正确答案，但省略了要求提供的论证。高推理强度下给出了正确的单位根证明，并经过独立复核。

不必只听我们怎么说。深入查看存储桶中的内容，针对你的用例或项目改写这些任务，试探 Beam 的能力极限。

你可以针对自己的用例微调 Beam。这里，我们分享一些使用 TRL 和 Miles 的示例，帮助你开始进行监督微调和强化学习。

让 Beam 适配自有数据，最快的方法是使用 TRL 的 SFTTrainer 进行监督微调。为控制显存占用，我们通过 PEFT 训练 LoRA 适配器，而不是更新全部 5010 亿参数。我们使用 TRL 的 SFTTrainer，让 Beam 适应一个简单目标：始终使用用户要求的语言进行推理。我们在 Multilingual-Thinking 上进行了 LoRA 微调，在冻结基础模型的同时，只训练少量适配器权重。

这套配置结合了加载时的模型分片、专家并行、FlashAttention 4 和序列打包。LoRA SFT 可以在配备 8 张 B300 GPU 的单个节点上完成，吞吐量约为每秒 19,000 个 token。对应的 H100 配置则需要四个节点。

在 Multilingual-Thinking 上训练一个 epoch 后，Beam 在 16 个留出测试提示词中，全部使用了指定语言进行推理；基础模型则只有 3 个。这项小规模评估衡量的是对语言要求的遵循程度，而非推理本身的正确性。

在另一次独立训练中，我们使用单个配备 8 张 B300 GPU 的节点，在 open-r1/Mixture-of-Thought 的一个推理子集上训练了 500 步。图中展示了训练损失（左）和平均 token 准确率（右）。这些训练指标来自 TRL 官方示例 PR。

Reflection 和 RadixArk 共同构建了一套方案，在 Miles 中使用 BF16 精度，通过 GRPO 训练模型。你可以更新整个模型，也可以冻结基础权重，使用 LoRA 训练适配器。Megatron 负责训练，SGLang 负责生成采样轨迹，Miles 则在每次更新后，将新权重发布到采样引擎。我们审阅了这套方案。

这套方案在 DAPO-Math-17K 上运行 GRPO，并在 AIME25 上进行评估。构建镜像、下载数据，然后将任务提交到由 12 个节点组成、每个节点配备 8 张 H200 的 Ray 集群：

docker build -f docker/Dockerfile.beam -t miles-beam .

python scripts/run_beam.py prepare \
  --model-id reflection/Beam-1.0-501B-A23B \
  --model-dir /root/models/Beam \
  --data-dir /data/datasets

export MASTER_ADDR=10.0.0.1
export RAY_ADDRESS=http://${MASTER_ADDR}:8265

python scripts/run_beam.py execute \
  --model-dir /root/models/Beam \
  --data-dir /data/datasets \
  --output-dir /root/shared_data/beam-run \
  --num-rollout 100

一次采样过程包含以下步骤：

采样：向模型传入 32 条提示词，每条生成 8 个回答。两个 SGLang 引擎分别使用 16 张 GPU，负责生成采样轨迹。

评分：将方框内的答案与标签进行核对，并对接近长度上限的回答施加轻度惩罚。

更新：对全部 256 个样本执行一次优化器更新。使用组相对优势和截断重要性采样，不施加 KL 或熵惩罚。

并行训练：张量并行度为 8，专家并行度为 8，数据并行度为 8，同时启用序列并行和完全重计算。

优化器：使用 Adam，学习率恒定为 1e-6。梯度采用 BF16，主权重采用 FP32，矩估计采用 BF16。优化器状态通过节点本地 NVMe 流式读写，因此每个训练节点需要 2 TB 的临时存储空间。

评估：每完成五轮 rollout，就在 AIME25 上评估一次，每道题采样八次。每二十轮保存一个检查点。

当前一轮训练时，会同时生成下一轮 rollout，因此生成响应所用的模型会落后一次参数更新。添加 --resume 可从上一个检查点继续。execute-colocate 会在八个节点上运行相同的训练方案，每块 GPU 轮流承担训练和推理服务。

你也可以在四个各配备 8 块 H200 的节点上，结合 LoRA 运行 GRPO：16 块 GPU 用于训练，16 块用于 rollout。该方案冻结基础权重，在 Beam 的注意力层、稠密 MLP 层和专家层上训练秩为 16 的适配器。只有适配器权重会同步到 SGLang，优化器状态则保留在 GPU 显存中，无需再将优化器状态卸载到 NVMe。

python scripts/run_beam_lora.py execute \
  --model-dir /root/models/Beam \
  --data-dir /data/datasets \
  --output-dir /root/shared_data/beam-run \
  --num-rollout 100

用 Beam 构建：演示项目

如果你用 Beam 构建了项目，可以将它分享到 Hub，就有机会赢取 10,000 美元。你只需创建一个 Space、模型或数据集仓库，并在该模型的仓库页面上分享。为了给你一些灵感，下面介绍几个我们构建的项目。

嘿，Beam，构建一个在本地运行的原生 macOS 应用！

在 Hugging Face，我们喜欢能够在对应硬件上原生运行的开放本地模型，但在 Mac 上构建原生应用并不容易！来看看 Beam 能否帮上忙。

我们让 Beam 构建一个原生 macOS 应用，将语音转换为文本，并方便地插入光标所在位置。我们希望使用 MLX 充分发挥 Mac Metal 的性能，并使用 Parakeet 模型实现出色的语音转文字效果。

Build BeamSpeak, a native macOS menu bar dictation app with a compact recording pill and no main window or account.

Use ⌘⇧Space to start and stop microphone recording, showing elapsed time, microphone level, and transcription status. Run speech recognition entirely locally using a Hugging Face model, preferably Parakeet v3 through MLX, and keep the model loaded between recordings. Paste the transcript into the original app if it remains focused and Accessibility permission is granted; otherwise copy it to the clipboard, preserving newer clipboard changes and never pressing Enter. Handle permissions, cancellation, silence, errors, a two-minute recording limit, and temporary audio cleanup. Deliver source code, a runnable BeamSpeak.app, setup instructions, and verification of offline transcription, the physical shortcut, microphone capture, and text delivery.

我们使用 Beam 搭配 Pi 编程框架，构建了最初的原生 macOS 菜单栏应用，通过 MLX 运行 Parakeet。保存的运行记录包含后续提示词；最终源码还包含后来由 Codex 完成的修复。上面的提示词是构建需求的精简版本。

你可以在这份轨迹记录中查看 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,300 起事件的合成数据集，并按事件簇划分为训练集、校准集和测试集。我们在 Science Slurm 集群的一块 H100 80GB 上，使用 4 位骨干模型，训练了一个 LoRA 适配器和一个决策头，共训练三个轮次。

作为基线，我们将完整的分诊策略和工单提供给未经适配的模型，不给示例，并要求它以 JSON 格式生成三项决策。在相同的 320 张合成测试工单上，微调后的决策模型有 76.25% 的工单三项答案全部正确，而基线为 4