Reflection's Beam gives developers downloadable model weights under Apache 2.0. That is useful for teams that need control over a model's deployment or customization, but it is a very different proposition from installing a small assistant on a laptop.
Google Cloud's launch guide describes roughly 501 billion total parameters, with about 23 billion active per token, and BF16, FP8 and NVFP4 checkpoints.
The active count describes computation for a token. The total count remains important when estimating how much memory the weights occupy.
Reflection's October 5 introduction initially offered early access while the weights and developer artifacts were still due later in the month. The downloadable model card and October 16 deployment guidance describe the later release. The initial announcement therefore predates availability of the weights.
Calculate the bare weights first
These are approximate decimal storage calculations from 501 billion parameters and the named nominal bit widths. They exclude scales, metadata, runtime memory, cached context and other overhead. They are starting bounds, not hardware recommendations.
| Nominal representation | Bare parameter storage |
|---|---|
| 16 bits per parameter | About 1,002 GB |
| 8 bits per parameter | About 501 GB |
| 4 bits per parameter | About 250.5 GB |
A machine advertising that much aggregate memory is not automatically ready to serve the model. The supported serving software, memory layout and communication between devices also affect whether the workload runs at an acceptable speed.
Reflection's model card gives more precise counts of 501.3 billion total parameters and 23.4 billion active parameters, and lists a one-million-token context window. The rounded storage estimates above use 501 billion. That small rounding difference does not explain away the extra memory needed for the serving system.
The card describes text input and text output. A workflow that begins with a scanned invoice or a photograph therefore needs another step to turn that material into suitable input. Include that component, its data handling and its cost in a deployment comparison. An open model's advertised coding ability does not make every file format a supported input.
Compare control with the work it creates
Self-hosting can make sense when a team has a defined reason to manage the weights: a customization requirement, an approved deployment environment, or a workload large enough to justify operating the service. It also creates a continuing job. Someone must maintain the serving stack, monitor failures and plan updates.
A managed endpoint can remove some of that work, but introduces its own access, data-handling and billing terms. Evaluate those terms against the specific task. An open license on weights does not determine how a separate hosted service retains requests or charges for them.
| Route | Question to settle before a trial |
|---|---|
| Run the weights yourself | Who operates the hardware and serving stack? |
| Use a managed deployment | Which party handles data and bills the requests? |
| Keep an existing model | What measurable problem would a switch solve? |
Workload and serving costs
For a coding workload, setup, tool use and output review all contribute to the cost of a completed task. A model that produces the first answer quickly may still take several attempts to complete the job.
Concurrency changes the memory requirement. Long conversations need more cached context, so a single short prompt tells you little about a busy service supporting several users at once. Deployment comparisons need the same input and success criteria to be meaningful.
Google and Reflection publish performance gains for particular serving configurations. Those comparisons depend on the hardware and baseline. Read the setup attached to the chart before turning a vendor's multiplier into an expected saving for your own system.
Checkpoint format, serving software, hardware and concurrency all affect the total charge. A smaller or already-running model may remain the economical choice if Beam does not improve completion of the workload enough to cover its serving costs.
