Reflection 发布 501B 开放模型 Beam,支持自托管定制与扩展
Welcome Beam: a 501B open model you can own, customize, and scale
Reflection 发布 501B 参数的开放模型 Beam,采用 MoE 架构,每 token 激活 23B 参数,上下文窗口 1M tokens,基于 Apache 2.0 许可。
Beam 以 Apache 2.0 开放 501B MoE 权重并给出多后端部署与微调 recipe,便于团队迁移到自有硬件。

Reflection 推出的 Beam 现已上线 Hugging Face!它是来自美国新实验室 Reflection 的首个模型,并且是开源的。它是一个混合专家(MoE)模型,拥有 5010 亿参数(每个 token 激活 230 亿),支持文本输入,具有 100 万 token 的上下文窗口,并以 Apache 2.0 许可证发布。
Beam 专注于 编码 和 智能体 用例。它适用于希望在自有硬件、基础设施或云环境中使用前沿规模模型,并希望针对自身用例进行定制的团队。Beam 附带一个专用的基于 Rust 的开源框架,以提供该模型的最佳性能。
Beam 拥有原生的 transformers 实现,以及 vLLM 和 SGLang 等下游库。我们与 Reflection 团队合作,为您提供了推理、SFT(监督微调)和 RL(强化学习)方案,以便您根据需求构建基于该模型的应用。除了 transformers、SGLang 和 vLLM 的 Day-0 支持外,本文还展示了如何运行它、如何进行后训练,以及我们用它构建了什么。
摘要
- 5010 亿参数的 MoE 大语言模型,每个 token 激活 230 亿参数。52 层,每个 MoE 层 256 个专家,每个 token 路由 8 个。
- 文本输入,文本输出,具有 100 万 token 的上下文窗口。
- 检查点格式:BF16、FP8 和 NVFP4
- 能够跨轮次保持在上下文中的推理(
preserve_thinking),以及带有专用语法的工具调用。该模型支持五种推理值:"low"、"medium"(默认)、"high"、"xhigh" 和 "max"。- 分词器中的响应模板。
- 带有 DFlash2 的推测解码草稿模型
- Day-0 库:transformers、SGLang、vLLM。使用 Miles 进行全参数 RL。
- 附带一个 基于 Rust 的自定义框架。
- Apache 2.0。
使用 Beam 构建
Reflection 将向使用 Beam 的最佳项目发放 10,000 美元的 Hub 积分。您只需制作一个项目,并在 Hub 上分享即可:
- 您可以制作一个在 Spaces 上使用 Beam 模型的演示
- 您可以将其量化以适配您喜欢的硬件
- 您可以为您喜欢的难题生成合成数据集
- 您可以为 Beam 构建或针对 Beam 构建一个 RL 环境
- 您可以对 Beam 进行基准测试并分享结果。
- 您可以给我们一个惊喜!
如果您使用 Beam 构建了某些东西,请在 Hub 上分享以有机会赢得 10,000 美元。您只需构建 space、模型或数据集仓库,并在 模型仓库页面 上分享。我们将收集所有链接,选出最佳项目,并向您的 Hub 账户发送积分。
什么是 Beam?
Beam 是一个专为长上下文(100 万上下文长度)推理和智能体工作而构建的纯文本模型。它是一个稀疏 MoE 模型,每个 token 仅由网络的一小部分计算,因此它能在保持大模型容量的同时,以远小于它的模型的速度运行。

注意力机制
解码器有 52 层,隐藏层大小为 5,120。大多数层使用对前 512 个 token 的滑动窗口注意力;每第六层以及最后一层则关注完整上下文。这提供了 43 个滑动窗口层和 9 个全局层。

注意力块内部(两种层类型)
这两类层对位置的处理方式不同。滑动窗口层使用 RoPE,因为在短窗口内相对位置最为重要。全局层不使用位置编码。相反,每个查询(query)都会乘以一个随可见 token 数量缓慢增长的标量,(1 + (pos + 1) / 2048) ** 0.1。它起到温度的作用:随着上下文变长,softmax 保持其精度,而不是变得平坦。实现中称此为可扩展 softmax 查询缩放(scalable-softmax query scaling)。
注意力机制采用分组查询注意力(grouped-query attention),包含 48 个查询头和 8 个键值头,并对查询和键应用 RMSNorm。一个从层输入计算得出的学习型 sigmoid 门控,在输出投影之前缩放每个头的每个通道。
混合专家(Mixture of Experts)
前 3 层使用稠密的 SwiGLU MLP。其余 49 层将其替换为包含 256 个专家的混合专家(Mixture-of-Experts)模块,每个专家都是一个中间大小为 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 检查点约为 1 TB,采用 safetensors 格式。NVFP4 检查点将大多数参数以 4 位精度存储,用于 NVIDIA Blackwell GPU,部分参数保留为 BF16 以保证精度。Hub 上还有 FP8 检查点,非常适合 Hopper 和 Ampere 系列芯片。
如果你想自行部署 Beam,请查看下面的 vLLM 或 SGLang 配置。
残差流(Residual Stream)
残差连接是最具特色的部分。标准 transformer 以权重 1 将每个子层输出添加到流中,因此流随深度增加而增长。

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

每个子层在前后也都经过归一化,最终 logits 通过 ±30 的 tanh 软上限(softcap)处理,以 FP32 计算。实现中固定了以 FP32 计算的位置:路由器、SwiGLU 乘积、归一化、RoPE、查询缩放和软上限。
长上下文(Long Context)
混合注意力机制在长上下文中表现良好。每层缓存 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 动态缓存。
基准测试结果(Benchmark Results)
以下是 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/ context management | 76.8% | 76.7% | 75.6% |
| DeepSearchQA w/ context management | 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 (index) - 仅公开部分 | 10.8 | 8.8 | 9.8 |
硬件要求
部署该模型最实用的方式是提供 NVFP4 检查点,它保留了 bf16 检查点的大部分质量。NVFP4 将部分权重存储为 4 位,从而将 BF16 下的 501B 参数从 1 TB 缩小到约 280 GB。Blackwell GPU 原生支持 NVFP4,但 Blackwell 之前的 GPU(如 H200)不支持。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 最简单的方式是文本生成流水线:
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]
流水线返回整个对话。最后一条消息是 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"
)
Chat
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 可能是数字或字符串。使用工具模式后,解析器会将每个参数转换为其声明的类型。
多 GPU 和多节点
Beam 的配置定义了一个专家并行计划。专家并行将每个专家放在一个设备上。注意力机制、密集层、嵌入和 LM 头在每个设备上复制。这是 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={}
),
)
使用 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。有关额外的服务配置,请参阅 针对 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 Beam-501B-A23B 在五个任务上的“氛围评估”(vibe evals),每个任务在 Reflection 平台上分别以低推理努力和高推理努力运行一次。这些是氛围评估,而非基准测试。如果你计划使用 Beam,这是一个很好的方式来“踩踩刹车”(kick the tires),看看它在特定用例中的表现,以及重要的是,它在哪里胜在哪里败。
以下是我们运行的提示词概览以及来自 hub 的输出轨迹。完整的输入、输出、API 使用情况、任务夹具、评分器和对话轨迹位于 这个公开的 Hugging Face 存储桶 中。
| 类别 | 提示词描述 | 低推理(token 数) | 高推理(token 数) |
|---|---|---|---|
| 多步工具调用 | 执行 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 |
* 低推理的长上下文响应正确获取了所有代码行为和所有六个源引用。然而,响应不符合解析器的格式,因此这部分是提示词歧义所致。
† 低推理返回了正确答案,但省略了要求的理由。高推理提供了一个正确的单位根证明,并经过独立审查。
不要只听我们说。深入挖掘 存储桶,根据你的用例或项目重写,并将 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 个上做到这一点。这一小规模评估衡量的是语言遵循度,而非推理本身的正确性。

训练损失(左)和平均 token 准确率(右),来自在 open-r1/Mixture-of-Thought 推理子集上单独进行的 500 步运行,使用一个 8-GPU B300 节点。这些训练指标来自官方 TRL 示例 PR。
使用 Miles 进行 GRPO
Reflection 和 RadixArk 构建了一个配方,使用 Miles 以 BF16 格式通过 GRPO 训练模型。您可以更新完整模型,或使用 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 上进行评估。构建镜像,下载数据,并将任务提交到由十二个 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,配合序列并行和全重计算。
优化器: 恒定学习率 1e-6 的 Adam。梯度为 BF16,主权重为 FP32,动量为 BF16。优化器状态通过节点本地 NVMe 流式传输,因此每个训练器节点需要 2 TB 的临时空间。
评估: 每五次 rollout 在 AIME25 上评估一次,每题 8 个样本。每二十次保存一个检查点。

下一个 rollout 在当前 rollout 训练期间生成,因此响应滞后一次更新。添加 --resume 以从最后一个检查点继续。execute-colocate 在八个节点上运行相同配方,每块 GPU 轮流进行训练和服务。
使用 LoRA 训练
你也可以在四个 8× H200 节点上运行 GRPO 配合 LoRA: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 美元。你只需构建一个空间、模型或数据集仓库,并将其分享到 模型仓库页面。为了给你灵感,这里有一些我们构建的内容。
嘿 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 作业上运行,通过 Reflection 的平台 API 进行推理。
对于任务,我们使用了 ProgramBench:智能体必须根据其编译的可执行文件和文档重建程序,而无需查看其源代码或评估者的测试。每种设置都有相同的 8M API 令牌上限和每个任务两小时的求解器限制,在其智能体之间共享。我们保存了实现快照,并根据来自 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% 的情况下三个答案全部正确,而提示零样本(prompted zero-shot)仅为 4.69%。平均工单延迟从 1,218.06 ms 降至 102.58 ms,实现了 11.9 倍的加速。

如果你想亲自尝试这个实验,请查看 artifact bucket,其中包含数据、代码、检查点和结果。
总结
Beam 是一个 501B 的开放模型,你可以在自己的硬件上运行并修改它。从 BF16 检查点开始,或者尝试其中一种量化版本 FP8, NVFP4。如果你用 Beam 构建了某些东西,请在 discussions tab 中分享。
来源:Hugging Face Blog · huggingface.co