Google Cloud published support and optimized configurations on October 17 for running Beam, Reflection's open-weight model for coding, reasoning, and AI agents. The package includes solutions based on llm-d and NVIDIA Dynamo, configuration files for Google's infrastructure, and evaluation tools. The announcement concerns executing the model on cloud resources and managing long sessions involving numerous successive calls.
Beam has approximately 501 billion parameters in total and activates approximately 23 billion for each token processed, according to Reflection's published model card. It uses a mixture-of-experts architecture. The model receives and generates text, was developed predominantly for English, and supports a context of one million tokens. This represents the amount of information usable within an interaction's context, separately from the model's parameter count.
Open weights and three numerical variants
Reflection publishes Beam's weights under the Apache 2.0 license in BF16, FP8, and NVFP4 variants. These names identify different numerical representations of the model. The card describes commercial and research uses, including text generation, software development, long-running agentic tasks, and summarization. Model adaptation, fine-tuning, and quantization are also envisaged within the published license.
Listed capabilities include working on issues within software projects, using command-line tools, and integration with coding agent environments. The model is intended for interactions in which a task involves several steps, tool calls, and interpretation of returned results. The card mentions MCP-based tool integration and code generation across multiple programming languages.
In such a workflow, an application sends requests and information from connected tools to the model, then receives responses for the next step in the task. Publication of the weights and serving configurations is relevant to custom applications with AI integration, because the technical team can manage the model and the infrastructure on which it runs. Google's announcement describes the components needed to run it on the cloud platform.
The model card lists June 30, 2026 as the knowledge cutoff. Reflection describes a corpus including web content, source code, technical documentation, reference material, and data obtained through commercial agreements. The company mentions quality filtering, deduplication, and evaluation decontamination within the model preparation process.
Two configurations for inference infrastructure
The Google Cloud package pairs llm-d with vLLM and NVIDIA Dynamo with SGLang. Configurations are published in code repositories, while the announcement also points to Model Garden in the Gemini platform. Files include Kubernetes manifests, routing configuration, and benchmarking scripts. They are intended for deployment within a GKE cluster and use GPU infrastructure to serve the model.
The hardware platforms described are A4X Max instances with NVIDIA GB300 NVL72 and G4 virtual machines with NVIDIA RTX PRO 6000. Google explains the optimizations in the context of running multiple agent sessions concurrently. Within these sessions, each stage can add file reads, code differences, compiler messages, or tool results to the shared conversation history.
A growing history increases the amount of information that must be processed before the next response is produced. Google's presentation calls this stage prefill. Token generation then follows in the decode stage. The configurations separate these types of work, allowing requests containing substantial context to be handled separately from the continuous production of responses in active sessions.
Context reuse is addressed across the serving system
Routing considers the context already held by each model replica and its current load. A request continuing the same session can be directed to the replica that already has the necessary information cached. The technical purpose described by Google is to reduce repeated processing of the same history, instead of distributing successive requests without taking context into account.
The configuration also uses tiered memory for the KV cache, the structure holding intermediate information from the context. Active data remains in GPU memory, while reusable blocks can be moved into system RAM and local SSD storage. Google describes this mechanism for situations in which several long conversations exceed the capacity available directly on the accelerators.
Other components include separating prefill and decode across different resources, distributing the model's experts, and speculative decoding. The announcement names DFlash2 for this last optimization category. These interventions concern the system serving the model and the sequence of calls, while Beam's parameter count and architecture are characteristics of the model itself.
Published results use separate reference configurations
Google Cloud reports, based on customer benchmarking, up to five times higher throughput and up to eight times lower latency for the optimized A4X Max configuration. For G4, the company lists up to twice the throughput and up to eight times lower latency. The values are presented against reference deployments on the same hardware.
The tests described use NVIDIA Dynamo with 32 GB300 NVL72 GPUs on A4X Max and llm-d with eight RTX PRO 6000 GPUs on G4. Google states that the two configurations are not directly comparable. The charts track the effect of optimizations within each configuration, including routing, caching, and the separation of processing stages, as the number of concurrent sessions increases.
Reflection separately publishes results for coding, reasoning, and tool-use tasks in its model card for each numerical variant. Those evaluations describe model capabilities, while the Google Cloud benchmarks describe the serving system. The announced package makes available the weights, configurations, and scripts used for deployment, keeping model evaluation separate from measurement of the infrastructure running it.
