Reflection Beam: Store the Whole Model, Not 23B
MODELS & COSTS
Reflection Beam: Store the Whole Model, Not 23B
Beam's active parameter count is 23B, while its total is 501B. Routing can reduce the work performed for a token without removing the other experts from storage. That is why the memory calculation starts with 501B, before discussing a computer to host it.
In this article
On October 5, Reflection introduced Beam, a sparse Mixture-of-Experts model aimed at coding and reasoning. As of October 6, its public weights are still due later this month. My storage calculation is already sobering: 501B weights at a hypothetical uniform 4 bits each take 250.5GB before any runtime overhead.
Release status at the analysis date
Reflection is still doing final evaluations and red-teaming. It offers an early-access signup, while the weights, model card and technical report are promised for later October. Apache 2.0 is the announced license for that upcoming weight release. I would check the actual repository and license files when they arrive.
| Item | Status checked October 6 |
|---|---|
| Trying Beam | Early-access signup; an early version is available to select users. |
| Public weights | Planned for later October; not yet available through the announced release. |
| License | Apache 2.0 announced for the forthcoming weights. |
| Deployment details | Wait for the checkpoint, model card and documented inference setup. |
That matters if your plan is to test it on a workstation this weekend. A preview account and a self-hosted checkpoint give you different kinds of access. Today’s announcement does not supply a verified consumer memory minimum, a tested 4-bit package or a recipe I can reproduce locally. This article is my reading of the sources and the capacity math; I have not run Beam.
Active computation versus stored weights
In a Mixture-of-Experts model, a router selects part of the model for a token. The Hugging Face MoE explanation draws the useful distinction: sparse activation reduces the work done at a step, while the full collection of experts still creates a substantial weight-storage requirement. Different tokens can need different experts.
For Beam’s announced sizes, 23 ÷ 501 × 100 = 4.59%. That is an active-parameter fraction, not the percentage of memory the complete model occupies. The remaining parameters are not a pile of files you can simply discard while preserving the same model.
Dividing the total count by the active count gives about 21.8. It would be a mistake to turn that into “21.8 times faster.” A dense model with the same total parameter count would be a different model, and actual token generation also depends on attention, weight movement, routing and the software implementation.
I covered a smaller version of this problem in 35B MoE Memory Planning: What 3B Active Does Not Tell You. Beam makes the distinction harder to ignore: a compute-friendly active count can coexist with a very large collection of weights.
Raw payload at different precisions
I started with the least complicated calculation possible: parameter count times bytes per stored value. Uniform 16-bit storage gives 1,002GB; 8-bit gives 501GB; 4-bit gives 250.5GB. These are decimal gigabytes of raw weight values. They are not measured checkpoint sizes or minimum system requirements.
Quantization can reduce weight memory, but a usable package has more to it than packing every parameter into half a byte. Some tensors may keep higher precision; quantization formats also have their own metadata and scales. The eventual quality and implementation matter as much as the nominal bit count. There is no validated Beam 4-bit release behind this example.
To make the raw number less abstract, here is what happens if I subtract it from three hypothetical budgets. Each budget is assumed to be memory actually available for the model, expressed in decimal GB. It is not a recommendation for a particular computer.
| Available budget | After 250.5GB of raw 4-bit weights |
|---|---|
| 128GB | 122.5GB short |
| 192GB | 58.5GB short |
| 256GB | 5.5GB left before every other allocation |
The positive remainder in the 256GB example is only a storage subtraction. A serving process also needs KV cache for conversation and tool history, temporary buffers and other allocations. Until a checkpoint is loaded in a specified runtime, that row cannot be used as a minimum-memory recommendation.
Units can change the apparent margin, too. The same 250.5GB is about 233.3GiB. A available 256GiB budget is about 274.9GB, leaving roughly 24.4GB before overhead. Check the bytes your system and runtime actually expose rather than treating every “256GB” label as the same measurement.
A server operator has more options than fitting everything on one accelerator. Expert parallelism can distribute experts across GPUs, with tokens routed to the workers that hold them. Offloading can shift weights into other memory tiers.
Those approaches add communication or data movement, so aggregate capacity alone does not establish good latency. The vLLM documentation illustrates the general technique; it does not confirm support for unreleased Beam weights.
Inference claims and the coding bill
I would want a cost per successfully completed task before answering that. Active parameters help explain one part of the work. A model that takes longer reasoning paths, retries more often or waits on tools can still make an agent expensive. For a coding workflow, the useful denominator is a correct fix that passes its tests.
Reflection estimates generation compute as 2 × active parameters × generated tokens per attempt, including reasoning tokens. Its method excludes prompt prefill, context-dependent attention and serving overhead. That is a useful approximate compute lens, but it does not measure a provider’s bill or the seconds you spend waiting.
I read the chart as an announcement snapshot. The source does not pin down every rival checkpoint and setting, and Terminal Bench v2.1 is the exact test version shown here. It should not be treated as the latest benchmark leaderboard or a controlled ranking of today’s API endpoints.
The alternatives are real deployment options: Qwen3.8-Max has a documented API and newer snapshot, GLM-5.3 has published weights and serving instructions, and DeepSeek V4.1 Flash is live on its API. That does not update the numbers in Reflection’s table. It means a team choosing a model today can evaluate available systems while Beam’s public release is still pending.
Once access permits it, I would use the same repository task, test suite and agent tool permissions, then record completion rate, total input and output tokens, retries and elapsed time. A cheap successful run would count for more than a favorable FLOPs estimate. For self-hosting, I would add peak memory and throughput at a stated concurrency. Those measurements remain to be done.
Beam is interesting to me because sparse models can offer operators a different balance of capacity and computation. Public weights under the promised license would make that balance easier to inspect and adapt. The release files and working inference stack will decide how useful that opportunity becomes.
Even the hypothetical four-bit payload runs into hundreds of gigabytes. Before buying a machine for Beam, check the released files, supported quantization and a deployment that reports complete memory use. The active count does not answer those questions or predict serving speed.
File size, quantization support and measured serving behavior will make the local-deployment question answerable. The arithmetic here is an early capacity check, with the missing runtime costs left visible.
Related on this blog: Mistral Large 4: Half-Price API, Weights Still to Come
Comments
Post a Comment