Run Reflection Beam on Day 0: Google Cloud, AWS SageMaker, or Ollama

Three day-0 runtimes for Reflection Beam: Google Cloud cache-aware serving, Amazon SageMaker, and Ollama Cloud, beside the 501B and 23B-active model shape. — Same Apache 2.0 Beam checkpoints, three operators. The 5x mark is Google Cloud’s October 16, 2026 customer-benchmark ceiling for A4X Max throughput versus a baseline on that hardware.

Reflection’s Beam, a sparse mixture-of-experts model for software work and multi-step tool use, has three documented ways to run as of October 16, 2026. Google Cloud published day-0 serving recipes for long coding sessions. AWS published SageMaker JumpStart and HyperPod paths. Ollama opened beam:cloud, free for a limited time, and says that endpoint keeps full zero data retention.

The Google Cloud, AWS, and Ollama posts agree on the model shape. Beam has about 501 billion total parameters and about 23 billion active parameters per token. Google Cloud and Ollama describe a context window of about 1 million tokens. AWS calls that figure Reflection’s reported effective context length. Weights ship under Apache 2.0 as BF16, FP8, and NVFP4. Google Cloud calls Beam text-native and says it plugs into harnesses teams already run, naming Reflection’s Mirror CLI, Claude Code, Hermes, and OpenCode. Background is in Beam 1.0 and open-weight models that can drive a harness.

Google Cloud Blog post announcing day-0 support for Reflection Beam. — Google Cloud Blog, October 16, 2026: the infrastructure post on day-0 Beam serving with llm-d and NVIDIA Dynamo. The capture is that publisher page. · Original source

Where a coding session spends compute

Google Cloud separates model efficiency from serving efficiency. Beam activates about 23 billion parameters per token and, Google says, reaches solutions with 3x to 4x fewer reasoning tokens than comparable open-weight models. A harness still calls the model dozens of times. Each turn appends file reads, diffs, compiler logs, and tool output until the shared history reaches tens or hundreds of thousands of tokens. Cost per completed task is the frame for that bill.

Google’s stateless round-robin baseline, on a standard Kubernetes deployment, sends Turn 15 to a different replica than Turn 14 and prefills the historical prompt again. Long sessions also fill GPU memory, the engine evicts KV blocks, and the next turn recomputes them. The day-0 recipes try to keep the shorter reasoning trace at cluster scale.

Google Cloud: keep the prefix warm

Google pairs Beam with llm-d (vLLM) and NVIDIA Dynamo (SGLang) on AI Hypercomputer. Joe Spisak, Reflection’s VP of Product and Head of Open Source, is quoted on up to 5x higher performance and 8x lower latency. Those hardware figures are customer benchmarks against a same-hardware baseline:

A4X Max (NVIDIA GB300 NVL72): up to 5x throughput and 8x lower latency.
G4 (NVIDIA RTX PRO 6000): up to 2x throughput and 8x lower latency.

Dynamo’s chart uses an A4X Max fleet of 32 GB300 NVL72 GPUs. The llm-d chart uses a G4 fleet of 8 RTX PRO 6000 GPUs. Read each chart against its own hardware baseline. More replicas raise the gain because the router can hit more warm caches and split prefill from decode.

Routing on GKE tracks prefixes and queue depth, then sends the next turn to the replica holding that prefix, with turn-priority flow control. Prefill and decode run in separate pools, with expert parallelism on the 23 billion active parameters, data-parallel attention, Blackwell NVFP4, and DFlash2 speculative decoding. Evicted KV blocks move from GPU memory to host DRAM and local NVMe through vLLM’s OffloadingConnector or SGLang’s HiCache. Manifests and benchmark scripts are in AI-Hypercomputer/gpu-recipes and Model Garden.

Diagram of Beam request routing. The prefix router sends a cached prefix to warm-replica prefill and an uncached prefix to the prefill pool. Both transfer KV cache into the decode pool. Active KV stays in GPU memory, and evicted blocks overflow to host DRAM and local SSD. — Cached prefixes are prefilled only for the new turn on the warm replica. Uncached prefixes take the full prompt through the prefill pool. Both paths hand KV cache to decode. Warm blocks evicted from GPU memory overflow to host DRAM and local SSD. Drawn from Google Cloud’s October 16, 2026 description of llm-d and NVIDIA Dynamo serving for Beam.

AWS: prerequisites, then a billable smoke test

At launch, JumpStart lists Beam in US East (N. Virginia) and US East (Ohio). Before any command, the AWS walkthrough requires an AWS account with SageMaker permissions for IAM, networking, and storage; Beam access through JumpStart or a Hugging Face checkpoint plus acceptance of the model terms; the AWS CLI; Python 3.11 or later; and GPU quota and capacity. In aws-samples/sagemaker-genai-hosting-examples, under 01-models/ReflectionAI/Beam-1.0-501B-A23B-NVFP4/, create a virtual environment and run python -m pip install -r requirements.txt.

The command below provisions a billable GPU endpoint, sends one short request, and deletes the endpoint. Charges continue until deletion is confirmed. Follow the sample README cleanup, and delete any cluster, cached weights, or mirrored artifacts the test created.

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

NVFP4 is the default when --variant is omitted. bf16 and nvfp4 select the other checkpoints. Keep an endpoint only through the README’s long-lived helpers. That README lists supported instances and the request schema.

JumpStart real-time is the managed HTTPS endpoint: you choose variant, instance, and scaling. JumpStart on HyperPod places that container on your cluster: you manage cluster, namespace, and endpoint. SGLang or vLLM is for custom runtime arguments: you pin the image digest, model revision, and parallelism.

BF16 needs the most weight memory and a multi-node plan. FP8 targets ml.p5.48xlarge (H100) or ml.p5e.48xlarge and ml.p5en.48xlarge (H200). NVFP4 targets ml.p6-b200.48xlarge (B200). Budget weights, KV cache, and runtime overhead per replica, then confirm with a load test. Copy checkpoints to Amazon S3 or FSx for a durable deploy. hyperpod_tool.py can validate a config, deploy it, and smoke-test at temperature 1.0 and top-p 0.7.

Ollama Cloud

Ollama serves Beam as beam:cloud for a limited free period and says the endpoint runs with full zero data retention together with Reflection. The route stays on Ollama Cloud.

ollama run beam:cloud
ollama launch claude --model beam:cloud
ollama launch codex --model beam:cloud
ollama launch opencode --model beam:cloud

Those lines target Claude Code, Codex, and OpenCode. The free window and the retention statement apply to this hosted route. Apache 2.0 lets you move the same BF16, FP8, or NVFP4 checkpoints to Google Cloud or AWS for a private replica. Own the loop, rent the model is a checklist for that handoff.

What the weight drop adds

SiliconANGLE, updated 18:52 EDT on October 16, reports that Reflection published fine-tuning recipes, capability and safety checks, serving configs, fused kernels, and a drafter model for speculative decoding, with further self-distillation recipes planned afterward. The deployment record is the Google Cloud and AWS posts above. The weight-release write-up is Beam’s open weights and training recipes.

Which path to run first

Use Ollama before buying GPU quota, and record the free window and zero-retention claim. Use JumpStart in N. Virginia or Ohio only after the prerequisites above, then confirm the smoke-test endpoint is deleted. Use HyperPod when you must pin the image digest and checkpoint, and mirror weights to S3 or FSx. Use Google Cloud when prefill dominates, and quote 5x only for the A4X Max customer benchmark and 2x only for the G4 customer benchmark, each against its own baseline. After a precision change, rerun a short quality check.