Beam 1.0 VRAM requirements at Q4 and 1M context

Beam 1.0 needs about 351 GB in this Q4_K_M, 1,048,576 token, batch one scenario. The Q4 weights take 281 GB of that and the KV cache takes 38.7 GB.

Beam 1.0 is Reflection's open weight sparse mixture of experts model, with 501B total parameters and 23B active for each token. The 23B figure describes compute. Memory follows the 501B. The router picks 8 of the 256 experts per token and can pick different ones on the next token, so every expert has to stay resident if you want full speed. This page budgets all of them at Q4_K_M, which the calculator treats as 0.56 bytes per parameter, then adds an FP16 KV cache for one sequence and a 10% runtime allowance. That gives 351.2 GB. It's a planning figure, not a measured footprint, and the next sections show which parts of it move when you change the context.

By TechCompare · Updated

Total VRAM required
351 GB
Beam 1.0 501B (MoE) at Q4_K_M
Weights
281 GB
501B params
KV cache
38.7 GB
1024K tokens, FP16 KV

Calculator

Estimated VRAM required

351 GB

501B params at Q4_K_M, 1,048,576 token context, batch 1, inference.

Weights
281 GB
KV cache
38.7 GB
Overhead
31.9 GB

Estimate accuracy: Planning estimate. Rounded model counts, tensor formats, cache packing, and workspace can change actual allocation. Confirm the exact checkpoint and serving engine with a load test.

Beam 1.0 has 9 full attention layers and 43 layers with a 512 token sliding window, all with 8 KV heads at head dim 128. Only the full layers grow with context. All-resident weights include the full 501B pool.

Hardware that fits

Apple entries show installed unified memory separately from a model budget based on an 8 GB reserve. That budget is a planning heuristic, not a fixed hardware limit.

No single GPU in our catalog has enough memory. Multi-GPU or CPU offload required.

How this is calculated

The architecture is what makes this page different from most 1M context models. Beam has 52 layers with hidden size 5120, and every attention layer uses 8 KV heads at head dimension 128. Only 9 of the layers use full attention. That's every sixth layer starting at layer 5, plus layer 51. The other 43 look back over a 512 token window and nothing more. Those 43 layers hold a fixed amount of cache no matter how long the session runs. Only the 9 full layers grow, at 36,950 bytes per token in FP16. At 1,048,576 tokens that adds up to 38.7 GB, and at 262,144 tokens it's 9.8 GB. At 32K it's 1.3 GB, and at 8K just 0.39 GB, mostly the window layers' fixed buffers. The totals follow: 319 GB at 256K, 310 GB at 32K and 351 GB at the full 1M. The cache is the smaller part of the budget at every context this model supports. Cutting context helps, but it only trims the edge of a budget that the weights set. Batch changes that picture, because each extra sequence needs its own cache while the weights are shared. Four sessions at 256K come to 352 GB in this estimate. The estimate leaves out prompt processing buffers, communication workspace for splitting the model across cards, and any framework allocations beyond the 10% allowance, so measure peak memory on your own stack at the context you plan to serve.

Verdict

Plan Beam 1.0 as a multi card or multi node deployment and treat the context length as a small adjustment. At the full 1M scenario the estimate takes 4 cards of a nominal 96 GB each, and at 32K it still takes 310 GB. Eight cards of 96 GB give 768 GB in total, which clears the full context figure on paper. Four such cards hold the short context case on paper but not the million token one. Uneven sharding, per card runtime overhead and the serving engine's support for this architecture all decide whether a paper fit becomes a working setup. The weights come in BF16, FP8 and NVFP4 releases, so pick a release first and compare its file size with the 281 GB used here before buying hardware.

More Beam scenarios

Kimi K3.1 Pro at Q4_K_M
A 2.78T expert pool with 24 latent attention layers and fixed state in the other 69.
View details ➜
Mistral Large 4 at Q4_K_M
A 1T expert pool with 63 latent cache owners and 44 layers that also store an index key.
View details ➜
Muse Spark Open at Q4_K_M
Only 16 of its 62 layers grow with context, and the other 46 hold a 2,048 token window.
View details ➜

Frequently asked questions

How much VRAM does Beam 1.0 need at Q4?
This calculator estimates about 351 GB for one sequence at 1,048,576 tokens, with 281 GB of Q4_K_M weights, 38.7 GB of FP16 cache and 31.9 GB of runtime allowance. At 32K the same setup comes to 310 GB. Both figures assume every expert is loaded and that your engine accepts a 4 bit version of the checkpoint.
Beam 1.0 only activates 23B parameters, so why plan for 501B?
The 23B figure is how many parameters work on one token. Routing sends the next token to a different set of 8 experts out of 256, so the whole pool has to be reachable quickly. Offloading experts to system memory or storage is a different design with its own bandwidth limits. This page's all-resident mode doesn't model that, so use it only for the case where the experts live in GPU memory.
Why is the 1M context cache so small for a model this size?
Of the 52 layers, 43 use a 512 token sliding window, so their cache stops growing almost immediately. Only the 9 full attention layers keep every token. That's why going from 256K to 1M adds 32 GB to the total instead of a number close to the weight size. Full attention models with the same head layout would carry that growth in every layer.
How many 96 GB GPUs does Beam 1.0 take?
The estimate at 1M context is 351 GB, which is 4 cards of a nominal 96 GB. That count only divides the total by the card size. Real tensor or expert parallel layouts need headroom on every card, and some layouts need a card count that divides the layer or expert count evenly. Treat the number as a floor and test the layout your engine supports.
Should I use the FP8 or NVFP4 release instead of a Q4 conversion?
Reflection publishes BF16, FP8 and NVFP4 releases. An 8 bit copy of the weights alone would be about 501 GB, against 281 GB for the Q4_K_M planning figure here. The NVFP4 release is also a 4 bit format, so read its file size and hardware notes on the model page. Whether it matches this Q4 estimate depends on which tensors the release keeps at higher precision.
What does this estimate leave out?
It leaves out prompt processing activations, communication buffers between cards, the engine's own allocations and any speculative decoding components. The 10% allowance is a rule of thumb and not a cap. Run a realistic prompt at your target context and watch peak memory on each card before you commit to a hardware plan.