AWS Machine Learning Blog · 2026/10/16 23:23:10

Reflection AI 发布开源权重编码模型 Beam,支持 AWS 部署

出处作者 / 发布主体:Clement Perrot原标题:Introducing Reflection Beam: an open-weight model for agentic coding on AWS
68AI 研判分
核心综述

Reflection AI 推出名为 Beam 的开源权重大模型,专为智能体编程和长周期任务设计。该模型拥有 5010 亿总参数与 230 亿激活参数,现已通过 Amazon SageMaker JumpStart 提供托管部署选项,并支持 Kubernetes 原生控制。

报道全文原始报道全文

本文目录17 个章节

Reflection AI 推出了 Beam,这是一款面向智能体编程(agentic coding)及长周期任务(如代码维护、工具调用、结果解读和多步骤工作流执行)的开放权重模型。通过开放权重发布,开发者和研究人员能够掌控运行时环境、部署架构以及定制化流程。

在本文中,我们将阐述 Reflection 的愿景,并展示如何在 AWS 上部署 Beam。你可以从 Amazon SageMaker JumpStart 实时端点入手,采用全托管路径;当需要对分布式 GPU 基础设施进行 Kubernetes 原生控制时,可结合 Amazon SageMaker HyperPod Inference 与 JumpStart、SGLang 或 vLLM 使用。此外,我们还将解释 Beam 的 5010 亿总参数如何影响检查点存储、权重内存、分片策略和并行化方案,而其 230 亿激活参数又如何决定每 token 的计算量。

上线初期,Beam 已在 Amazon SageMaker JumpStart 中提供,支持美国东部(弗吉尼亚北部)和美国东部(俄亥俄州)区域。

Reflection 对开放智能的愿景

Reflection 的使命是通过开放模型权重、公开发表的研究成果以及开源软件,让智能向所有人开放且易于获取。其完整 AI 技术栈涵盖模型、核心软件、生产基础设施及应用层。Beam 将这一理念带给构建软件工程系统和智能体系统的开发者。

关于 Reflection Beam

Beam 是一款稀疏混合专家(sparse mixture-of-experts, MoE)模型,旨在解决软件问题、修改代码、调用工具并根据中间结果采取行动。该模型拥有 5010 亿总参数和 230 亿激活参数,Reflection 报告其有效上下文长度为 100 万 tokens。

Reflection 通过 Hugging Face 以 Apache 2.0 许可证发布 Beam 的权重。Beam 1.0 提供 BF16、FP8 和 NVFP4 三种检查点变体。这些格式具有不同的内存占用量和硬件兼容性。你可以使用 AWS 托管的 JumpStart 容器配置来部署模型,也可以在 AWS 环境中利用 SGLang 或 vLLM 对模型进行检查和定制。

理解部署架构

选择符合你控制和扩展需求的服务路径。

  1. 当你希望使用 AWS 托管的模型包、端点和调用 API,而无需自行运维 Kubernetes 时,请从 SageMaker JumpStart 实时端点开始。
  2. 当你希望在由 Amazon Elastic Kubernetes Service (Amazon EKS) 编排的 HyperPod 集群上使用 AWS 托管容器和模型配置时,请使用 HyperPod Inference 上的 JumpStart。
  3. 当你需要控制服务镜像、运行时参数、量化或分布式执行时,请在 HyperPod Inference 上使用 SGLang 或 vLLM。
  4. 根据检查点存储、权重内存、KV 缓存、上下文长度、批处理大小、运行时开销以及支持的并行策略来规划部署规模。
  5. 定义预期的并发量和延迟目标,然后根据实测的工作负载行为配置副本数、缓存、路由和自动伸缩。

JumpStart 实时路径将模型、容器和端点封装在托管部署工作流之后。HyperPod 路径则暴露了集群和服务运行时,使你可以控制分布式执行、缓存、路由和伸缩。

下图展示了 HyperPod 路径所使用的组件。Beam 模型可通过 SageMaker JumpStart、Hugging Face Hub 或可选的 Amazon Simple Storage Service (Amazon S3) 镜像源获取。分布式工作节点使用 AWS 托管的 JumpStart 容器,或自定义的 SGLang 或 vLLM 运行时。

显示 Beam 架构的图表:Beam 源自 SageMaker JumpStart、Hugging Face Hub 或可选的 Amazon S3 镜像,进入 Amazon SageMaker HyperPod Inference;其中 Inference Operator 管理本地模型和镜像缓存,Inference Gateway 和 Endpoint Picker 将请求路由至由 Amazon CloudWatch 监控的分布式 JumpStart、SGLang 或 vLLM 工作节点。

图 1:基于 Amazon SageMaker HyperPod Inference 的 Beam 分布式部署

前提条件

你需要:

  • 一个 AWS 账户,具备所选 SageMaker 部署路径及其支持的 AWS Identity and Access Management (IAM)、网络和存储资源的权限。
  • 通过 SageMaker JumpStart 或 Hugging Face 上其中一个 Beam 1.0 检查点仓库访问 Beam 模型的权限。
  • 接受模型条款,安装 AWS Command Line Interface (AWS CLI),并使用 Python 3.11 或更高版本。
  • 支持特定 Beam 配置的 GPU 配额和容量。

规划并获取 GPU 容量

Beam 模型总计 5010 亿参数需要多 GPU 部署。BF16 格式对权重显存的需求最大,因此需规划一个多节点配置,确保聚合 GPU 显存足以容纳权重及运行时开销。对于 FP8 格式,请使用配备 NVIDIA H100 GPU 的 ml.p5.48xlarge 实例,或配备 H200 GPU 的 ml.p5e.48xlarge 和 ml.p5en.48xlarge 实例。对于 NVFP4 格式,请使用配备 NVIDIA B200 GPU 的 ml.p6-b200.48xlarge 实例。请确认发布的检查点(checkpoint)、运行时环境以及并行布局支持所选的实例类型。

  1. 计算单个副本的权重、KV cache 及运行时开销所需的显存,并通过负载测试验证该估算值。
  2. 选择支持所需加速实例类型的 AWS Region。
  3. 检查服务配额(service quota)以及所选实例类型的可用容量。如有可用资源,优先使用按需容量;若为计划性任务,可使用 SageMaker training plan 作为短期预留。
  4. 预留镜像传输、权重下载、分片加载及运行时初始化所需的时间。

路径 1:通过 SageMaker JumpStart 实时端点快速上手

当你希望以最短路径从模型目录部署到托管 HTTPS 端点时,应首先使用 JumpStart 实时端点。该示例通过一条感知变体(variant-aware)的命令,支持 BF16、FP8 和 NVFP4 模型 ID。其 README 文件和 Python 脚本是支持的实例类型、请求架构、部署命令及清理命令的唯一权威来源。

  1. 克隆示例仓库。
BASH
git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git
  1. 进入 SageMaker JumpStart 部署示例目录。
BASH
cd sagemaker-genai-hosting-examples/01-models/ReflectionAI/Beam-1.0-501B-A23B-NVFP4/
  1. 创建并激活 Python 虚拟环境。
BASH
python3 -m venv .venv
source .venv/bin/activate
  1. 安装示例依赖项。
BASH
python -m pip install -r requirements.txt
  1. 运行针对 FP8 格式的受限部署、调用及清理生命周期。
BASH
python jumpstart_real_time.py \
--variant fp8 \
--endpoint-name reflection-beam-fp8-smoke

该命令会部署 FP8 端点,发送一个简短请求,打印响应结果,并清理端点。若要选择其他检查点变体,请使用 bf16 或 nvfp4;若省略 --variant 参数,默认使用 NVFP4。若需保持端点持续运行,请参考 README 中提供的 Python 函数。

路径 2:使用 SageMaker HyperPod Inference 部署

当你需要对分布式 GPU 基础设施进行 Kubernetes 原生控制时,请使用 HyperPod Inference。你可以使用 AWS 托管的 JumpStart 容器配置,或者通过 SGLang 或 vLLM 部署 Beam。HyperPod Inference 部署示例 README 及其配置文件是已发布清单、模型和镜像标识符、支持的运行时版本以及命令的唯一权威来源。

在开始之前,请配置 kubectl 以访问由 EKS 编排的 HyperPod 集群,该集群需包含 HyperPod Inference Operator 及所需的附加组件(add-ons)。你还需要集群虚拟私有云 (VPC)、子网、安全组、对选定 Beam 和运行时工件的访问权限,以及如果启用模型缓存所需的本地 NVMe 容量。如果选定的仓库需要身份验证,请使用隔离的 Hugging Face 访问令牌。

对于开发和实验,请从 Hugging Face Hub 部署固定版本的 Beam。对于生产环境部署和模型缓存,请将检查点复制到 Amazon S3 或 Amazon FSx。HyperPod 模型和镜像缓存 可以将权重预加载到节点本地的 NVMe 存储中,并预先拉取服务镜像。

HyperPod Inference Gateway 提供兼容 OpenAI 的接口,并在副本之间路由请求。HyperPod Inference 还支持 托管分层 KV 缓存和智能路由。这些功能属于 2026 年推出的 Amazon SageMaker Inference 能力。

下图详细展示了模型准备和运行时请求流程。当启用模型缓存时,Inference Operator 会使用选定的权重和服务镜像预热符合条件的节点。在运行时,Inference Gateway 和 Endpoint Picker 可以将每个请求定向到合适的 JumpStart 管理副本、SGLang 副本或 vLLM 副本。

Detailed HyperPod flow showing the Inference Gateway, Endpoint Picker, routing signals, Inference Operator, host-local model cache, and JumpStart-managed, SGLang, or vLLM replicas.

图 2:HyperPod 模型缓存与请求路由

准备部署工件

使用不可变输入,以确保能够复现部署和性能结果。

  1. 使用部署示例中记录的 JumpStart 模型版本。
  2. 对于自定义运行时,选择 BF16、FP8 或 NVFP4 检查点。
  3. 对于自定义运行时,在示例发布配置中保留公开的 Beam commit SHA 和镜像摘要。
  4. 仅当集群无法拉取上游镜像或组织要求使用经批准的注册表时,才将发布的镜像镜像到私有的 Amazon Elastic Container Registry (Amazon ECR) 仓库中。
  5. 确保令牌、生成的密钥、私有模型 ID、注册表凭据以及未公开的结果不存储在代码仓库中。

选择服务路径

除非工作负载需要特定的推理运行时或配置,否则请从 SageMaker JumpStart 开始。

服务路径适用场景您管理的内容
SageMaker JumpStart希望使用 AWS 托管的容器和模型配置,以减少运行时维护工作。选择 Beam 模型版本、支持的实例类型、端点配置和扩展策略。
SGLang 或 vLLM需要特定的推理运行时或配置,例如自定义运行时参数、解析器、量化或并行设置。固定支持的运行时镜像、模型修订版、解析器配置和分布式执行设置。

使用 SageMaker JumpStart 进行部署

SageMaker JumpStart 减少了容器集成工作,同时 HyperPod 仍保持对集群容量、扩展性和可观测性的控制。

  1. 在 SageMaker Studio 中,打开 JumpStart 模型目录。
  2. 在 所有公共模型 下,选择 Beam。
  3. 选择 SageMaker HyperPod 作为部署目标。
  4. 选择集群和 Kubernetes 命名空间。
  5. 输入端点名称,然后选择 部署。
  6. 在使用已发布的 JumpStart 请求模式调用端点之前,确认部署状态。

对于基础设施即代码(IaC)工作流,请使用 HyperPod 示例中已发布的 JumpStart 配置。在配置部署之前,你可以查看 reflection-beam-jumpstart.yaml manifest template。

  1. 克隆示例仓库,并进入 HyperPod Beam 目录。
BASH
git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git
cd sagemaker-genai-hosting-examples/SageMakerHyperpod/reflection-beam/
  1. 创建 README 中描述的本地配置文件。
BASH
cp config/deployment.env.example config/deployment.env
cp config/release.env.example config/release.env
  1. 在更改集群之前,验证 JumpStart 配置。
BASH
python hyperpod_tool.py \
  --config config/deployment.env \
  --config config/release.env \
  validate jumpstart
  1. 部署 JumpStart 配置。
BASH
python hyperpod_tool.py \
  --config config/deployment.env \
  --config config/release.env \
  deploy jumpstart \
  --timeout-seconds 1800

该辅助工具会渲染并应用已发布的 JumpStartModel 资源,而无需将填充后的发布值写入磁盘。

使用 SGLang 或 vLLM 进行部署

当你需要直接控制服务运行时,请选择 SGLang 或 vLLM。在配置部署之前,请查看 reflection-beam-sglang.yaml manifest template 或 reflection-beam-vllm.yaml manifest template。示例的 README 文件仍是已发布值和命令的权威来源。

  1. 克隆示例仓库。
BASH
git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git
  1. 进入 HyperPod Beam 目录。
BASH
cd sagemaker-genai-hosting-examples/SageMakerHyperpod/reflection-beam/
  1. 创建 README 中描述的本地配置文件。
BASH
cp config/deployment.env.example config/deployment.env
cp config/release.env.example config/release.env
  1. 在更改集群之前,验证所选配置。
BASH
python hyperpod_tool.py \
  --config config/deployment.env \
  --config config/release.env \
  validate sglang
  1. 部署 Beam,并等待其进入终态。
BASH
python hyperpod_tool.py \
  --config config/deployment.env \
  --config config/release.env \
  deploy sglang \
  --timeout-seconds 1800

将 sglang 替换为 vllm 以使用 vLLM。该辅助工具会验证所选配置,应用渲染后的清单(manifest),且不会将发布值写入磁盘,随后以固定超时时间进行等待,并在部署失败时打印诊断信息。

调用 Beam

使用已发布的模型请求架构调用 JumpStart 端点。对于 SGLang 或 vLLM,请使用 HyperPod 示例中包含的有界冒烟测试。

调用已部署的端点

  1. 安装示例客户端依赖项。
BASH
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt
  1. 使用推荐的初始采样设置运行私有健康检查和简短请求。
BASH
python hyperpod_tool.py \
--config config/deployment.env \
smoke sglang \
--prompt "List three checks for a healthy model deployment." \
--temperature 1.0 \
--top-p 0.7

对于 vLLM 部署,请将 sglang 替换为 vllm。该辅助工具会选择一个就绪的工作节点,开启临时端口转发,检查端点健康状况,发送请求,然后关闭端口转发。

响应类似于以下内容:

TEXT
1. Confirm that the endpoint reports ready.
2. Send a short inference request.
3. Review the service logs for startup errors.

对于经过身份验证的 Inference Gateway,请使用 HyperPod 示例 README 中的 bearer-token 流程。请勿将凭据保留在源代码、清单文件或命令历史记录中。

测量与调优性能

  1. 在预期并发量下,使用重复且具有代表性的编码和工具调用请求测试每个服务路径。
  2. 记录 Beam 模型版本、镜像摘要、实例类型、精度、上下文长度、并行度、服务参数、缓存状态以及测试重复次数。
  3. 测量请求成功率、p50 和 p95 首令牌延迟(time to first token)、每输出令牌耗时、端到端延迟以及聚合输出令牌每秒吞吐量(throughput)。
  4. 根据这些结果调整批处理大小、KV cache 分配、副本数量、自动扩缩容以及模型和镜像缓存策略。
  5. 在更改精度或量化方式后,重新检查输出质量。

清理资源

完成测试后删除相关资源,以避免产生持续费用。

  1. 对于 SageMaker JumpStart 实时端点,请按照 SageMaker JumpStart 部署示例 README 中的清理说明操作。
  2. 对于在 Amazon SageMaker HyperPod Inference 上运行的 JumpStart、SGLang 或 vLLM,请按照 HyperPod Inference 部署示例 README 中的清理说明操作。
  3. 删除为本次演练创建的专用 HyperPod 集群或 Amazon EKS 集群。
  4. 删除未使用的缓存权重、镜像制品、负载均衡器、日志组、临时 IAM 角色以及捕获的推理数据。

结论

Reflection Beam 为开发者提供了一款专为智能体编码(agentic coding)和多步骤任务设计的开放权重模型。若需完全托管的部署方案,可从 SageMaker JumpStart 实时端点开始。当您需要 Kubernetes 原生基础设施控制权但无需管理服务容器时,可结合使用 SageMaker HyperPod Inference 与 JumpStart;若需要自定义运行时,则可选择 SGLang 或 vLLM。

请使用 SageMaker JumpStart 部署示例 或 HyperPod Inference 部署示例,并按照其中的说明进行操作。

如需了解更多关于 Reflection AI 及其开放智能愿景的信息,请访问 Reflection AI 并阅读 Introducing Beam。

资源