Introducing Reflection Beam: an open-weight mannequin for agentic coding on AWS

Reflection AI launched Beam, an open-weight mannequin for agentic coding and long-horizon duties resembling sustaining code, utilizing instruments, deciphering outcomes, and finishing multi-step workflows. The open-weight launch provides builders and researchers management over the runtime, deployment surroundings, and customization course of.

On this put up, we clarify Reflection’s imaginative and prescient and present how one can deploy Beam on AWS. Begin with an Amazon SageMaker JumpStart real-time endpoint for a completely managed path. While you want Kubernetes-native management over distributed GPU infrastructure, use Amazon SageMaker HyperPod Inference with JumpStart, SGLang, or vLLM. We additionally clarify how Beam’s 501 billion whole parameters form checkpoint storage, weight reminiscence, sharding, and parallelism, whereas its 23 billion energetic parameters affect per-token compute.

At launch, Beam is offered in Amazon SageMaker JumpStart in US East (N. Virginia) and US East (Ohio).

Reflection’s imaginative and prescient for open intelligence

Reflection’s mission is to make intelligence open and accessible to all via open mannequin weights, printed analysis, and open supply software program. Its full AI stack spans fashions, core software program, manufacturing infrastructure, and purposes. Beam brings this strategy to builders constructing software program engineering and agentic programs.

About Reflection Beam

Beam is a sparse mixture-of-experts mannequin for resolving software program points, modifying code, calling instruments, and performing on intermediate outcomes. It has 501 billion whole parameters and 23 billion energetic parameters, and Reflection experiences an efficient context size of 1 million tokens.

Reflection releases Beam’s weights via Hugging Face underneath the Apache 2.0 license. Beam 1.0 is offered in BF16, FP8, and NVFP4 checkpoint variants. These codecs present completely different reminiscence footprints and {hardware} compatibility. You may deploy the mannequin with the AWS managed JumpStart container configuration or examine and customise the mannequin with SGLang or vLLM in your AWS surroundings.

Perceive the deployment structure

Select the serving path that meets your management and scaling necessities.

1. Begin with a SageMaker JumpStart real-time endpoint if you need an AWS managed mannequin package deal, endpoint, and invocation API with out working Kubernetes.
2. Use JumpStart on HyperPod Inference if you need the AWS managed container and mannequin configuration on a HyperPod cluster orchestrated by Amazon Elastic Kubernetes Service (Amazon EKS).
3. Use SGLang or vLLM on HyperPod Inference when it’s worthwhile to management the serving picture, runtime arguments, quantization, or distributed execution.
4. Dimension the deployment for checkpoint storage, weight reminiscence, KV cache, context size, batching, runtime overhead, and the supported parallelism.
5. Outline the anticipated concurrency and latency targets, then configure replicas, caching, routing, and autoscaling from measured workload habits.

The JumpStart real-time path packages the mannequin, container, and endpoint behind a managed deployment workflow. The HyperPod path exposes the cluster and serving runtime so that you could management distributed execution, caching, routing, and scaling.

The next diagram reveals the parts utilized by the HyperPod path. Beam might be sourced via SageMaker JumpStart, Hugging Face Hub, or an non-obligatory Amazon Easy Storage Service (Amazon S3) mirror. The distributed employees use the AWS managed JumpStart container or a customized SGLang or vLLM runtime.

Stipulations

You want:

• An AWS account with permissions to your chosen SageMaker deployment path and its supporting AWS Id and Entry Administration (IAM), networking, and storage sources.
• Entry to Beam via SageMaker JumpStart or one of many Beam 1.0 checkpoint repositories on Hugging Face.
• Acceptance of the mannequin phrases, the AWS Command Line Interface (AWS CLI), and Python 3.11 or later.
• GPU quota and capability for a supported Beam configuration.

Plan and procure GPU capability

Beam’s 501 billion whole parameters require a multi-GPU deployment. BF16 has the biggest weight-memory requirement, so plan a multi-node configuration with sufficient combination GPU reminiscence for the weights and runtime overhead. For FP8, use ml.p5.48xlarge with NVIDIA H100 GPUs or ml.p5e.48xlarge and ml.p5en.48xlarge with H200 GPUs. For NVFP4, use ml.p6-b200.48xlarge with NVIDIA B200 GPUs. Affirm that the launched checkpoint, runtime, and parallel format assist the chosen occasion sort.

1. Calculate reminiscence for weights, KV cache, and runtime overhead for one duplicate, then affirm the estimate with a load take a look at.
2. Select an AWS Area that helps the required accelerated occasion.
3. Examine the service quota and obtainable capability for the chosen occasion sort. Use on-demand capability when obtainable, or use a SageMaker coaching plan as a short-term reservation for scheduled work.
4. Permit time for picture switch, weight obtain, shard loading, and runtime initialization.

Path 1: Get began with a SageMaker JumpStart real-time endpoint

Use a JumpStart real-time endpoint first if you need the shortest path from the mannequin catalog to a managed HTTPS endpoint. The pattern helps the BF16, FP8, and NVFP4 mannequin IDs via one variant-aware command. Its README and Python file are the supply of fact for supported occasion sorts, request schema, deployment command, and cleanup command.

1. Clone the pattern repository.

   git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git

2. Enter the SageMaker JumpStart deployment pattern listing.

   cd sagemaker-genai-hosting-examples/01-models/ReflectionAI/Beam-1.0-501B-A23B-NVFP4/

3. Create and activate a Python digital surroundings.

   python3 -m venv .venv
   supply .venv/bin/activate

4. Set up the pattern dependency.

   python -m pip set up -r necessities.txt

5. Run the bounded deployment, invocation, and cleanup lifecycle for FP8.

   python jumpstart_real_time.py 
   --variant fp8 
   --endpoint-name reflection-beam-fp8-smoke

   The command deploys the FP8 endpoint, sends a brief request, prints the response, and cleans up the endpoint. Use bf16 or nvfp4 to pick one other checkpoint variant; NVFP4 is the default if you omit --variant. Use the Python capabilities within the README when it’s worthwhile to hold an endpoint working.

Path 2: Deploy with SageMaker HyperPod Inference

Use HyperPod Inference if you want Kubernetes-native management over distributed GPU infrastructure. You should use the AWS managed JumpStart container configuration or deploy Beam with SGLang or vLLM. The HyperPod Inference deployment sample README and its configuration information are the supply of fact for launched manifests, mannequin and picture identifiers, supported runtime variations, and instructions.

Earlier than you start, configure kubectl entry to an EKS-orchestrated HyperPod cluster with the HyperPod Inference Operator and required add-ons. You additionally want the cluster digital personal cloud (VPC), subnets, safety teams, entry to the chosen Beam and runtime artifacts, and native NVMe capability if you happen to allow mannequin caching. Use an remoted Hugging Face entry token if the chosen repository requires authentication.

Deploy a pinned Beam revision from Hugging Face Hub for improvement and experimentation. For manufacturing deployments and mannequin caching, copy the checkpoint to Amazon S3 or Amazon FSx. HyperPod mannequin and picture caching can preload weights onto node-local NVMe storage and pre-pull the serving picture.

The HyperPod Inference Gateway gives an OpenAI-compatible interface and routes requests throughout replicas. HyperPod Inference additionally helps managed tiered KV caching and clever routing. These are among the many Amazon SageMaker Inference capabilities launched in 2026.

The subsequent diagram expands the mannequin preparation and runtime request circulate. When mannequin caching is enabled, the Inference Operator warms eligible nodes with the chosen weights and serving picture. At runtime, the Inference Gateway and Endpoint Picker can direct every request to an appropriate JumpStart-managed, SGLang, or vLLM duplicate.

Determine 2: HyperPod mannequin caching and request routing

Put together deployment artifacts

Use immutable inputs so that you could reproduce deployment and efficiency outcomes.

1. Use the JumpStart mannequin launch recorded within the deployment pattern.
2. Select the BF16, FP8, or NVFP4 checkpoint for a customized runtime.
3. For a customized runtime, hold the general public Beam commit SHA and picture digest within the pattern launch configuration.
4. Mirror the launched picture into a non-public Amazon Elastic Container Registry (Amazon ECR) repository solely when your cluster can not pull the upstream picture or your group requires an accepted registry.
5. Hold tokens, generated secrets and techniques, personal mannequin IDs, registry credentials, and unpublished outcomes out of the repository.

Select a serving path

Begin with SageMaker JumpStart until your workload requires a selected inference runtime or configuration.

Deploy with SageMaker JumpStart

SageMaker JumpStart reduces container integration work whereas HyperPod retains management over cluster capability, scaling, and observability.

1. In SageMaker Studio, open the JumpStart mannequin catalog.
2. Below All public fashions, select Beam.
3. Select SageMaker HyperPod because the deployment goal.
4. Choose the cluster and Kubernetes namespace.
5. Enter an endpoint title, and select Deploy.
6. Affirm the deployment standing earlier than invoking the endpoint with the launched JumpStart request schema.

For an infrastructure-as-code workflow, use the launched JumpStart configuration within the HyperPod pattern. You may examine the reflection-beam-jumpstart.yaml manifest template earlier than configuring the deployment.

1. Clone the pattern repository, and enter the HyperPod Beam listing.

   git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git
   cd sagemaker-genai-hosting-examples/SageMakerHyperpod/reflection-beam/

2. Create the native configuration information described within the README.

   cp config/deployment.env.instance config/deployment.env
   cp config/launch.env.instance config/launch.env

3. Validate the JumpStart configuration earlier than altering the cluster.

   python hyperpod_tool.py 
     --config config/deployment.env 
     --config config/launch.env 
     validate jumpstart

4. Deploy the JumpStart configuration.

   python hyperpod_tool.py 
     --config config/deployment.env 
     --config config/launch.env 
     deploy jumpstart 
     --timeout-seconds 1800

The helper renders and applies the launched JumpStartModel useful resource with out writing populated launch values to disk.

Deploy with SGLang or vLLM

Select SGLang or vLLM if you want direct management over the serving runtime. Earlier than configuring the deployment, examine the reflection-beam-sglang.yaml manifest template or the reflection-beam-vllm.yaml manifest template. The pattern README stays the supply of fact for launched values and instructions.

1. Clone the pattern repository.

   git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git

2. Enter the HyperPod Beam listing.

   cd sagemaker-genai-hosting-examples/SageMakerHyperpod/reflection-beam/

3. Create the native configuration information described within the README.

   cp config/deployment.env.instance config/deployment.env
   cp config/launch.env.instance config/launch.env

4. Validate the chosen configuration earlier than altering the cluster.

   python hyperpod_tool.py 
     --config config/deployment.env 
     --config config/launch.env 
     validate sglang

5. Deploy Beam, and anticipate a terminal deployment state.

   python hyperpod_tool.py 
     --config config/deployment.env 
     --config config/launch.env 
     deploy sglang 
     --timeout-seconds 1800

   Exchange sglang with vllm to make use of vLLM. The helper validates the chosen settings, applies the rendered manifest with out writing launch values to disk, waits with a set timeout, and prints diagnostics if deployment fails.

Invoke Beam

Invoke JumpStart endpoints with the launched mannequin request schema. For SGLang or vLLM, use the bounded smoke take a look at included within the HyperPod pattern.

Invoke the deployed endpoint

1. Set up the pattern consumer dependency.

   python3 -m venv .venv
   supply .venv/bin/activate
   python -m pip set up -r necessities.txt

2. Run a non-public well being test and quick request with the really useful beginning sampling settings.

   python hyperpod_tool.py 
   --config config/deployment.env 
   smoke sglang 
   --prompt "Listing three checks for a wholesome mannequin deployment." 
   --temperature 1.0 
   --top-p 0.7

   Exchange sglang with vllm for a vLLM deployment. The helper selects a prepared employee, opens a brief port-forward, checks endpoint well being, sends the request, and closes the port-forward.

The response resembles the next:

1. Affirm that the endpoint experiences prepared.
2. Ship a brief inference request.
3. Assessment the service logs for startup errors.

For an authenticated Inference Gateway, use the bearer-token process within the HyperPod pattern README. Hold credentials out of supply code, manifests, and command historical past.

Measure and tune efficiency

1. Check every serving path with repeated, consultant coding and tool-use requests on the anticipated concurrency.
2. File the Beam mannequin model, picture digest, occasion sort, precision, context size, parallelism, serving arguments, cache state, and take a look at repetitions.
3. Measure request success price, p50 and p95 time to first token, time per output token, end-to-end latency, and combination output tokens per second.
4. Tune batch measurement, KV cache allocation, duplicate depend, autoscaling, and mannequin and picture caching from these outcomes.
5. Recheck output high quality after altering precision or quantization.

Clear up

Delete sources if you end testing to keep away from ongoing prices.

1. For a SageMaker JumpStart real-time endpoint, observe the cleanup directions within the SageMaker JumpStart deployment pattern README.
2. For JumpStart, SGLang, or vLLM on Amazon SageMaker HyperPod Inference, observe the cleanup directions within the HyperPod Inference deployment pattern README.
3. Delete a devoted HyperPod or Amazon EKS cluster created for the walkthrough.
4. Delete unused cached weights, mirrored artifacts, load balancers, log teams, non permanent IAM roles, and captured inference knowledge.

Conclusion

Reflection Beam provides builders an open-weight mannequin designed for agentic coding and multi-step duties. Begin with a SageMaker JumpStart real-time endpoint for a completely managed deployment. Use SageMaker HyperPod Inference with JumpStart if you want Kubernetes-native infrastructure management with out managing the serving container, or select SGLang or vLLM if you want a customized runtime.

Use the SageMaker JumpStart deployment sample or the HyperPod Inference deployment sample, then observe the directions.

To study extra about Reflection AI and its imaginative and prescient for open intelligence, go to Reflection AI and browse Introducing Beam.

Assets

In regards to the authors