Reflection AI推出了Beam，这是一款面向智能体编程和长程任务的开放权重模型。AWS的介绍文章将其应用范围描述为维护和修改代码、解决软件问题、调用工具、理解中间结果，以及完成多步骤工作流程。这些任务覆盖从代码操作到工具反馈处理的连续过程，也是文章讨论模型部署与测试时所采用的工作负载背景。

在发布时，Beam已通过Amazon SageMaker JumpStart在美国东部的北弗吉尼亚和俄亥俄两个区域提供。所给材料对发布时可用区域的说明仅涉及这两处，因此，部署规划仍需结合目标区域支持的实例、账户配额与实际容量，不能仅凭模型已进入JumpStart目录就确定所有资源均已就绪。

模型规模、上下文与权重开放

Beam采用稀疏混合专家架构，总参数量为5010亿，活跃参数量为230亿。这两个数字对应不同的资源规划问题：总参数量关系到检查点存储、权重内存、分片和并行部署；活跃参数量则影响每个token的计算需求。对于准备自行部署的团队，较小的活跃参数量并不意味着可以按照这一数字规划全部权重的存储与内存。

Reflection表示，Beam的有效上下文长度达到100万token。这一数据属于公司的说明，所给证据没有独立验证。文章也没有提供实测基准分数、延迟、吞吐量、成本或与其他模型的对比，因此，模型规模和上下文声明不能直接替代具体工作负载下的性能测量。

Reflection通过Hugging Face以Apache 2.0许可发布Beam 1.0权重，提供BF16、FP8和NVFP4三种检查点变体。不同变体具有不同的内存占用与硬件兼容要求。选择精度时，需要把检查点、运行时与并行布局一同考虑；文章还建议，在调整精度或量化方式之后重新检查输出质量。

Reflection将开放权重、公开研究和开源软件视为实现开放、可访问智能的组成部分，其AI技术栈涵盖模型、核心软件、生产基础设施和应用。对开发者与研究者而言，此次权重发布所提供的具体控制权包括选择运行时、部署环境，以及进行定制。文章随后介绍的不同部署路径，也围绕这些控制需求展开。

从托管端点到自定义运行时

AWS文章列出三种模型服务方式。第一种是SageMaker JumpStart托管实时端点，使用者无需自行运行Kubernetes。第二种是在由Amazon EKS编排的HyperPod Inference集群上使用JumpStart，由AWS管理容器和模型配置。第三种是在HyperPod Inference上使用SGLang或vLLM，以控制服务镜像、运行时参数、量化方式和分布式执行。

这三条路径的区别主要体现在服务环境的管理方式和可调整范围。托管端点对应无需运营Kubernetes的需求；HyperPod上的JumpStart保留集群部署方式，同时采用AWS管理的配置；SGLang或vLLM路径则面向需要自行控制推理软件与执行设置的情况。文章没有提供三者之间的实测速度或成本排名。

JumpStart实时部署示例通过识别变体的命令支持BF16、FP8和NVFP4，默认选择NVFP4。文章展示的FP8命令会创建端点、发送一条简短请求、打印响应，然后清理端点。示例README另有用于保持端点运行的Python函数，因此，运行演示时需要理解其清理行为，持续运行的部署则应使用相应函数。

先准备权限、集群与GPU容量

文章列出的基础条件包括：拥有适当SageMaker、IAM、网络和存储权限的AWS账户；获得模型访问权限并接受模型条款；安装AWS CLI；使用Python 3.11或更新版本；以及具备受支持GPU的配额和实际容量。这些条件共同决定部署是否具备执行基础，模型访问权限本身并不涵盖全部基础设施要求。

使用HyperPod还需要通过kubectl访问由EKS编排的集群，准备HyperPod Inference Operator及所需附加组件，并完成网络配置和模型产物访问设置。如果启用模型缓存，还必须提供节点本地NVMe容量。缓存配置因此也属于资源规划的一部分，而不只是部署完成后的软件选项。

Beam需要多块GPU，文章建议为BF16规划多节点配置。FP8对应的实例包括配备H100的ml.p5.48xlarge，以及配备H200的ml.p5e.48xlarge和ml.p5en.48xlarge；NVFP4则列出配备B200的ml.p6-b200.48xlarge。这些配置的适用性取决于检查点、运行时和并行布局的兼容关系，不能视为无条件通用配置。

容量预算不仅要覆盖模型权重，也要计入KV缓存和运行时开销。文章还要求考虑区域实例支持、配额与负载测试，容量来源可以是按需资源或SageMaker训练计划。对部署团队而言，实例型号只是规划中的一项，实际请求规模与并发条件仍需纳入测试和配置调整。

模型来源、缓存与可复现部署

HyperPod路径可以从JumpStart、Hugging Face Hub或可选的S3镜像获取Beam。AWS建议开发阶段固定Hugging Face修订版本，并在生产和模型缓存场景中将检查点复制到S3或FSx。固定修订版本与明确模型产物来源，也与文章随后提出的不可变模型发布、检查点修订和镜像摘要要求相衔接。

HyperPod模型缓存能够预先把权重加载到节点本地NVMe，并提前拉取服务镜像。其Inference Gateway提供兼容OpenAI的接口，在多个副本之间路由请求。文章还介绍了托管分层KV缓存和智能路由支持。这些功能构成部署与请求处理的配置选项，但材料没有给出启用它们后的具体性能增幅。

部署可通过SageMaker Studio中的JumpStart目录完成，也可使用示例配置和清单。文章建议使用不可变的模型发布版本、检查点修订版本和镜像摘要，以明确部署所采用的产物。示例辅助工具能够验证配置并应用清单，而且不会把填入具体发布值后的内容写入磁盘。

自定义运行时的部署辅助工具使用固定超时，并在失败时输出诊断信息。SGLang或vLLM的基础连通性测试会选择一个已就绪的工作节点，临时转发端口，检查健康状态，发送请求，随后关闭端口转发连接。这套流程检查服务是否能够响应；文章另外要求进行代表实际任务的重复测试，以评价预期并发下的表现。

用实际任务测量，并清理测试资源

AWS建议重复运行具有代表性的编程与工具调用任务，并让测试覆盖预期并发量，同时记录模型和运行时配置。需要测量的指标包括请求成功率、首个token等待时间的p50与p95、每个输出token的耗时、端到端延迟，以及整体每秒输出token数。配置记录与测量结果应配套保留，作为后续调整的依据。

文章建议根据这些测量调整批处理、KV缓存、副本数量、自动扩缩容和缓存设置，并在精度或量化改变后再次核查输出质量。所给材料提供的是部署方法与验证建议，没有给出独立性能结论。测试结束后，还应删除测试资源和不再使用的产物，避免继续产生费用；这一清理要求也与实时端点示例中的自动删除步骤相呼应。