Reflection 发布 Beam 501B 开源模型，支持 1M tokens 上下文

Beam by Reflection 已在 Hugging Face 上线！这是美国新实验室 Reflection 推出的首款模型，而且是开放模型！它是一个拥有 501B 参数的混合专家（MoE）模型（每个 token 激活 23B 参数），支持文本输入，拥有 1M token 的上下文窗口，并采用 Apache 2.0 许可证发布。

Beam 专注于编程和智能体应用场景。它面向希望在自有硬件、基础设施或云端运行前沿规模模型，并根据自身应用场景对其进行定制的团队。Beam 配备了专用的开源 Rust 运行框架，能够充分发挥模型的性能。

Beam 提供原生的 transformers 实现，也支持 vLLM 和 SGLang 等下游库。我们与 Reflection 团队合作，为你提供推理、SFT（监督微调）和 RL（强化学习）方案，助你根据需求使用该模型进行开发。除了从第一天起就支持 transformers、SGLang 和 vLLM，本文还将介绍如何运行和后训练该模型，以及我们用它构建了什么。

简而言之

• 拥有 501B 参数、每个 token 激活 23B 参数的 MoE 大语言模型。52 层，每个 MoE 层有 256 个专家，每个 token 路由至 8 个专家。
• 文本输入、文本输出，拥有1M token 的上下文窗口。
• 检查点格式：BF16、FP8，以及 NVFP4
• 推理过程可以跨轮次保留在上下文中（preserve_thinking），并支持采用专用语法的工具调用。模型支持五种推理强度值："low"、"medium"（默认）、"high"、"xhigh" 和 "max"。
• 分词器中的响应模板。
• 搭配 DFlash2 的推测解码草稿模型
• 从第一天起即可使用的库：transformers、SGLang、vLLM。使用 Miles 进行全参数 RL。
• 随附基于 Rust 的自定义运行框架。
• Apache 2.0。

使用 Beam 构建

Reflection 将向使用 Beam 的优秀项目发放价值 $10,000 的 Hub 积分。你只需创建一个项目并将其分享到 Hub：

• 你可以在 Spaces 上制作一个使用 Beam 模型的演示
• 你可以针对自己喜欢的硬件对其进行量化
• 你可以为自己喜欢的问题生成合成数据集
• 你可以为 Beam 构建 RL 环境，或构建一个使用 Beam 的 RL 环境
• 你可以对 Beam 进行基准测试并分享结果。
• 你也可以带给我们惊喜！

如果你使用 Beam 构建了项目，就将其分享到 Hub，即有机会赢得 $10,000。你只需构建 Space、模型或数据集仓库，并分享到模型仓库页面。我们会收集所有链接，选出优秀项目，并将积分发放至相应的 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 个专家，因此模型处理每个 token 时实际计算的参数量约为 23B。全部 256 个专家都保留在内存中，因此部署所需的内存相当于一个 501B 模型，但运行速度相当于一个 23B 模型。BF16 检查点采用 safetensors 格式，大小约为 1 TB。NVFP4 检查点面向 NVIDIA Blackwell GPU，将大多数参数存储为 4 位精度，部分参数则保留 BF16 精度以保证准确性。模型库中还有 FP8 检查点，非常适合 Hopper 和 Ampere 系列芯片。

如果你想自行部署 Beam，可以查看下面的 vLLM 或 SGLang 配方。

残差流

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

Beam 将输入嵌入视为第 1 步。在第 k 步，它以权重 1/sqrt(k) 加入子层输出，并以权重 sqrt((k-1)/k) 保留现有流。两个权重的平方和为 1，因此从第一层到最后一层，流的尺度始终保持不变。经过全部 104 次相加后，在最终隐藏状态中，每个子层输出和输入嵌入的权重都相同。

每个子层前后也都进行归一化，最终 logits 会经过以 FP32 计算、阈值为 ±30 的 tanh 软截断。实现会明确指定哪些计算使用 FP32：路由器、SwiGLU 乘积、归一化、RoPE、查询缩放和软截断。

长上下文

混合注意力适用于长上下文。每一层为每个 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 检查点，它保留了 BF16 检查点的大部分质量。NVFP4 将部分权重存储为 4 位，因此可将 BF16 格式下的 501B 参数从 1 TB 压缩至约 280 GB。Blackwell GPU 可原生运行 NVFP4，但 H200 等早于 Blackwell 的 GPU 无法运行。FP8 检查点适用于早于 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。

Transformers

安装最新版本的 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 受训时生成的结构一致。聊天模板可以预先写入部分 assistant 回合，而解析器需要能够看到这部分内容。

工具调用

完整的工具调用示例

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，解析器会将每个参数转换为声明的类型。

多 GPU 和多节点

Beam 的配置定义了专家并行方案。专家并行会将每个专家放置在一台设备上。注意力层、稠密层、嵌入层和 LM head 则会在每台设备上复制。这部分共有 8B 个参数，即 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={}
    ),
)

在 16 块 H200 GPU 上使用 torchrun 启动脚本。这样每块 GPU 会容纳 78 GB 权重。如果使用 8 块 GPU，每块则需容纳 139 GB，而 H200 的容量为 141 GB，几乎没有剩余空间。设备数量必须能整除专家数量 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。如需了解其他服务配置，请参阅建议的 vLLM Beam 配置方案。

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 上，则改用 8 张 H200 上的 FP8 检查点。只需更改三个标志：检查点、张量并行大小（8 而非 4），以及注意力后端（使用 fa3 而非 trtllm_mha；后者需要 Blackwell）：

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 推理服务提供商平台上线，由 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 配置方案，你可以从目录中一键部署到推理端点，选择FP8或NVFP4；也可以使用 hf cli 安装，命令如下：

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

我们的测试

我们通过 Reflection 平台，在五项任务上分别以低和高推理力度运行了一次 Reflection Beam-501B-A23B，并分享了一些体验式评测。这些是体验式评测，并非基准测试。如果你打算使用 Beam，这是试用它、观察它在特定用例中的表现的好方法，也能让你了解它在哪些方面表现出色、哪些方面有所不足。

下面概述了我们运行的提示词以及来自 hub 的输出轨迹。完整的输入、输出、API 使用情况、任务样例、评分器和对话轨迹都在这个公开的 Hugging Face 存储桶中。

* 低推理力度下的长上下文回答正确还原了所有代码行为，也正确引用了全部六处源代码。不过，回答未采用指定解析器的格式，因此这在一定程度上是提示词存在歧义。

† 低推理力度下返回了正确答案，但没有提供所要求的证明。高推理力度下给出了正确的单位根证明，并经独立审核。

不必只听我们说。深入查看存储桶，根据你的用例或项目改写提示词，并充分测试 Beam 的能力。

Beam 的后训练

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

使用 TRL 进行监督微调

使用 TRL 的 SFTTrainer 进行监督微调，是让 Beam 适配你自己的数据最快的方法。为控制内存占用，我们使用 PEFT 训练 LoRA 适配器，而不是更新全部 501B 个参数： 我们使用 TRL 的 SFTTrainer，让 Beam 实现一个简单目标：用用户要求的语言进行推理。我们使用 LoRA 在 Multilingual-Thinking 上进行微调，只训练一小组适配器权重，同时冻结基础模型。

该方案结合了加载时的模型分片、专家并行、FlashAttention 4 和序列打包。LoRA SFT 可在配备 8 块 B300 GPU 的单个节点上运行，速度约为每秒 19,000 个 token。相应的 H100 配置使用四个节点。

在 Multilingual-Thinking 上训练一个 epoch 后，Beam 在 16 个留出提示中的 16 个都使用了指定语言进行推理；基础模型则为 16 个中的 3 个。此项小规模评测衡量的是语言遵循情况，而非推理本身的正确性。

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

使用 Miles 进行 GRPO

Reflection 和 RadixArk 构建了一套方案，使用 Miles 以 BF16 进行 GRPO 训练。你可以更新整个模型，也可以使用 LoRA 训练适配器，同时冻结基础权重。Megatron 负责训练，SGLang 负责生成 rollout；每次更新后，Miles 都会将新权重发布到 rollout 引擎。我们审阅了这套方案。

该方案在 DAPO-Math-17K 上运行 GRPO，并在 AIME25 上进行评估。构建镜像、下载数据，然后将作业提交到由十二个 8x 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

一次 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。

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：智能体必须根据编译后的可执行文件和文档重建程序，且无法查看源代码或评测器的测试。每种设置的 API 令牌上限均为 8M，每项任务的求解时间限制均为两小时，并由其中的智能体共享。我们保存了实现快照，并使用 ProgramBench-Tests 数据集中的固定隐藏测试集对其进行评测。

我们的得分与延迟关系图显示了通过测试的平均比例。时间轴采用模型令牌的固定参考速率加上实测工具耗时，而非实际墙钟时间。我们最初运行了五项任务。当前图表展示的是事后选出的 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-bit 主干模型训练了 LoRA 适配器和决策头，共三个 epoch。

作为基线，我们向未经适配的模型提供完整的分诊策略和工单，不给示例，并要求它以 JSON 格式生成三个决策。在相同的 320 个合成测试工单上，微调后的决策模型有 76.25% 的工单三项答案全部正确，而提示式零样本模型的这一比例为 4.69%。工单平均延迟从 1,218.06 ms 降至 102.58 ms，提速 11.9×。

如果你想亲自试试这项实验，请查看 资源存储桶，其中包含数据、代码、检查点和结果。

总结

Beam 是一个 501B 开源模型，你可以在自己的硬件上运行并进行修改。从 BF16 检查点开始，或尝试其中一种量化版本：FP8、NVFP4。如果你用 Beam 构建了什么，请在讨论选项卡中分享。