一张生成的主视觉卡片,标题为“Beam 1.0 第零天:SGLang 配方”,副标题为“总计 501.3B,每个 token 唤醒 23.4B”。左侧卡片“SGLang 配方”列出“硬件:B300、GB300、H200”“低延迟:TP 配合块大小为 8 的 DFlash2 草稿模型”“高吞吐:关闭 DFlash2,TP + DPA”以及“Blackwell NVFP4:EP + FlashInfer MegaMoE”;右侧卡片“为什么重要”列出“501.3B 总计 / 23.4B 激活”“52 层,256 个专家”“1M token 上下文”以及“Apache 2.0,权重于 2026 年 10 月 16 日发布”。OrcaRouter 标志合成在图像下方的条带中,位于右下角。
Engineering & Research

在 Day Zero 提供 Beam 1.0 服务:SGLang 配方究竟锁定了什么

作者

Magnus Corvin

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

一个你可以下载的检查点,并不是一个你可以部署的模型,而两者之间的距离,通常要用数周的框架工作来衡量——这些工作由某个足够不耐烦的人完成。Reflection Beam 1.0 是罕见的情况:这些工作随权重一同到来。Reflection 于 2026 年 10 月 5 日发布了该模型;2026 年 10 月 16 日,权重、Apache 2.0 许可证、官方端点以及横跨七个推理栈的首日支持一同落地,而其中一个栈——SGLang,其项目账号在 16 日表示,它已在 Reflection 的生产环境中运行 Beam——发布了一份详细到足以让人与之争论的配方。

那份配方才是真正有意思的产物,比基准测试表更值得关注。一篇发布公告告诉你某个模型很好。而一张部署矩阵告诉你,要弄清楚这一点需要付出什么代价,以及在哪些环节你所做的选择会悄然决定你的延迟。Reflection Beam 1.0 的 SGLang 文档就是一个生成器:你选一个硬件平台和一种策略,它就会输出一条锁定版本的 Docker 命令。对于任何打算亲自运行它、而不是仅仅调用它的人来说,它逼着你走一遍的那些选项才是真正的看点。

配方拒绝隐藏的三个轴

该页面会先询问硬件平台、策略和量化方式,然后构建命令。这比大多数模型发布所承认的决策空间更小,而且每个维度都会带来实际影响:

• 硬件平台 — B300、GB300 或 H200。Blackwell 型号原生支持 NVFP4 构建;H200 则走 FP8 和 BF16 路径。这与 Reflection 发行说明中描述的最低要求相同,只是以下拉菜单形式重新表述。

• 策略——低延迟还是高吞吐,而这正是大多数部署默认设置出错的维度。低延迟会运行张量并行,并在块大小为 8 时启用 DFlash2 草稿器。高吞吐则会完全禁用 DFlash2。

• 量化 — NVFP4、FP8 或 BF16,它们必须与平台和策略相匹配,而不能随意自由组合。

这两个策略预设不是性能调节旋钮,而是算法的更换。投机解码是在解码延迟与每步额外的草稿模型计算之间做权衡;在块大小为 8、搭配 1.93B 参数草稿模型时,当你一次只服务一个用户,这笔权衡值得做,而当你进行激进批处理时,则应当拒绝。在高吞吐方案中关闭 DFlash2 不是降级,而是对另一个问题的正确答案。

配方不再可以互换之处

别只停在预设项上,页面接下来还记录了几处出于具体硬件原因而存在的配置划分,在你照抄看到的第一个 Docker 命令之前,值得先了解一下:

• H200 BF16 以自动静态内存比例运行 TP8。933.81 GiB 的 BF16 检查点无法容纳在更少的设备上,而且内存比例是计算得出的,而不是公开可调的——这意味着这是唯一一个不脱离受支持路径就无法手动调优的方案。

• 其他所有配方都使用张量并行加 DPA。这里的 DPA 是一种数据并行注意力安排,它将注意力与专家并行拆分解耦,这也是非 BF16 配方能够容忍 BF16 配方无法容忍的设备数量的原因。

• Blackwell NVFP4 还额外支持专家并行和 FlashInfer MegaMoE。这正是 Reflection 自家指南所指向的组合,而且只有当检查点是 273 GiB 的打包 4 位构建、而非 468.72 GiB 的 FP8 时,它才会变得可用。

实际结论是:“我们在 SGLang 上运行 Beam 1.0”并不是一句硬件层面的陈述。两个团队都可以这么说,实际却在运行不同的精度、不同的并行布局和不同的解码算法,而要想对比情况,唯一的办法就是把这三者都明确说出来。

“第零天”的价值是什么,以及它不是什么

权重发布当天就有框架支持,这是一个真实的信号,而且是一种特定类型的信号。SGLang 对 Beam 1.0 的支持之所以存在,是因为 Reflection 的工程师在发布之前就与 SGLang 社区展开了合作——这是 SGLang 项目在 10 月 16 日公开表示的,并且与 Reflection 将 SGLang 列入其 day-zero 合作伙伴之一的做法一致,与 Transformers、vLLM、Unsloth、Axolotl、TokenSpeed 和 NVIDIA Dynamo 并列,同时还提供了面向 SGLang、vLLM 和 TokenSpeed 的书面指南,以及面向 Kubernetes 的 Helm chart。

• 它所确立的 —— 一条有文档记录、持续维护的路径,从已发布的检查点通向可提供服务的端点,运行在明确指名的硬件上,且量化变体均已纳入考量。这确实超出了大多数开源发布在第一周所能做到的。

• 它无法确立的是——该配置是最优的,或者你将获得的吞吐量数字会与其他人一致。关于在 Reflection 投入生产的说法来自供应商和框架,是由实际提供该服务的人报告的。我们尚未看到对其的独立复现,也没有任何关于自托管 Beam 部署的第三方基准测试被发布。

这一区别在这里比平时更重要,因为这是一个拥有 5013 亿参数的稀疏专家混合模型,每个 token 激活 234 亿参数,而该架构的全部价值就在于,你的服务成本只是模型名称中那个数字的一小部分。框架支持所做的,是把这一说法从架构图转化为内存预算。它并不能把它转化为实测吞吐量数字,而且我们找不到任何第一方资料发布过其推理数据——发布信息中唯一具体的每秒 token 数描述的是在单个配备 8 块 B300 GPU 的节点上进行 LoRA 监督微调,那是一个训练步骤,而不是服务速率。

Screenshot of the SGLang cookbook page for Reflection Beam 1.0, showing the site's vendor sidebar with Reflection and "Beam 1.0 New" selected, and the deployment panel reading "Deploy Reflection Beam 1.0 with SGLang on B300, GB300, and H200: NVFP4, FP8, and BF16 recipes for low latency and high throughput", with the hardware platform options B300, GB300 and H200, and the strategy and quantisation controls.

自托管第零天技术栈实际具有的故障模式

有一种特定的出错方式,而问题并不在模型本身。它出现在第二周。一个为单一量化方案和单一并行布局构建的固定 Docker 镜像,并不能充当自身的回退方案:如果草稿模型与你的流量模式发生不良交互,如果驱动更新改变了显存比例所分配到的内容,或者如果你的容量被排在另一个租户后面排队,那么你手上就没有可回退的配置了——你拥有的是一次故障,而其中还端坐着一个能力出众的模型。

Beam 1.0 不在我们的路由之列,因此我们无法为你提供该服务,此处的任何内容都不应被解读为我们做出的可用性承诺。我们所能做的,是把回退方案放到有用的地方。OrcaRouter 让一个与 OpenAI 兼容的密钥即可运行 200 多个模型,按提供商的标价原样透传、不额外加价,并支持跨提供商自动故障转移,因此一个停止响应的自托管 Beam 试点项目只是一次路由变更,而非一起事故。Beam 部署最常替代的、且能通过该方式访问的模型,都附有公开的费率卡:

• GLM-5.2 — 每百万输入 token 1.40 美元,每百万输出 token 4.40 美元,上下文长度为 1,000,000 个 token。Reflection 自身的效率声明所对标的模型,也是 Beam 长上下文编码工作最直接的替代方案。

• Kimi K3 — 每百万输入 3.00 美元,缓存 0.30 美元,输出 15.00 美元,窗口大小为 1,048,576 个 token。Reflection 的发布文章承认,K3 在原始能力上仍然领先。

• Qwen3.8-Max — 每百万输入 2.00 美元、输出 6.00 美元,上下文窗口为 1,000,000 token,是面向希望获得同等能力却无需自建机架的团队的旗舰级专有选项。

A generated scoreboard titled "Beam 1.0 - the two recipe presets" comparing the SGLang low-latency and high-throughput configurations. Low-latency: tensor parallel, DFlash2 speculative draft at block size 8, NVFP4/FP8/BF16, reference hardware B300 or GB300, best for single-user latency, published throughput none by Reflection. High-throughput: tensor parallel plus DPA, speculative draft disabled, NVFP4/FP8/BF16, reference hardware B300, GB300 or H200, best for batched throughput, published throughput none by Reflection. The OrcaRouter logo is composited in the strip below the artwork, bottom right.

食谱仍然没有告诉你的事

有三个缺口值得点明,因为每一个都是你最终会在信息不如你所愿充分的情况下做出的决定。

首先是价格。Reflection 的端点有文档记录,并且与 OpenAI 兼容,其推理强度分为 max、xhigh、high、medium 和 low,强制推理默认以 max 为主导,而每个组织的限额在所有密钥之间共享。它没有公布每百万 token 的费率,因此 Beam 1.0 的效率论证无法作为一道算术题来完成。一个始终进行推理且默认采用最高强度的模型,会因输出 token 的定价是 1 美元还是 10 美元而成为不同的商业方案。

第二点是独立测量。Artificial Analysis 将该模型列为 Intelligence Index 30,没有速度数据,也没有价格,并记录其没有公开可用的 API——这是第三方的说法,表明托管服务尚未出现在衡量这些事物的人眼前。其唯一一个独立计得的效率数据点是真实的:Beam 在 AA 的 Intelligence Index 上生成了 7900 万个输出 token,而对比集的中位数为 1.3 亿。这支持了“推理 token 更少”的说法。但它并不能告诉你这些 token 的输出速度有多快。

第三点是版本漂移。已发布的配方是针对某个特定检查点和某个特定 SGLang 构建编写的,而草稿模型又有自己的仓库。只要其中任何一方发生变化,你在十月锁定的配方到了十一月就成了一套无人测试过的配置。要把那条 Docker 命令当作一个带有效期的起点,而不是一次部署。

Screenshot of the Hugging Face collection page for Reflection's Beam 1.0, listing the three repositories reflection/Beam-1.0-501B-A23B, reflection/Beam-1.0-501B-A23B-FP8 and reflection/Beam-1.0-501B-A23B-DFlash2 under the heading "Beam 1.0 - Reflection's first open-weight model, built for coding, reasoning, and agentic tasks".

谁应该现在对此采取行动,谁应该等待

如果你已经拥有 Blackwell 算力,SGLang 方案确实足以起步:四块 B300 是 NVFP4 的参考配置,显存计算已经公开,一致性测试套件也已存在,而下行风险仅限于工程时间。如果你不拥有硬件,这笔账仍然算不过来,因为托管选项没有费率表可与资本性采购相比较——而零日框架支持固然很好,却不能替代价格。

值得关注的,不是又一个宣布支持的框架,而是第一个既非来自 Reflection、也非来自某个框架项目的公开数字:在具名配置上做出的独立吞吐量测量,或者第一方端点上的价目表。这两者中的任何一个,都能把它从一次记录完备的实验,变成预算表上的一行。在那之前,对 10 月 16 日的正确解读是:硬工程部分已按期交付——而商业论证,才是仍在施工中的那部分。

这一切都并非假设:像本次这样的发布背后那些有据可查的 AI 故障与智能体事件,均收录于 OrcaRouter AI 事件档案库中,其中每条记录都附有自己的来源、严重程度、置信度评级和存疑标记。