Self-Hosting Beam 501B: The Weights Are Open. The Release Channels Are Not There Yet.

Reflection released Beam on 16 October: a mixture-of-experts model with 501.3B total and 23.4B active parameters, a 1M-token context, text in and text out, and an Apache 2.0 license (the LICENSE file in the repository is the Apache License, Version 2.0). Hugging Face's launch post pitches it at teams that want a frontier-scale model on their own hardware, and lists day-0 support in transformers, vLLM and SGLang.

For anyone self-hosting an LLM, the license is the easy part. The question is which runtime you can install today without building from a branch, and what it costs in memory. Going by the package indexes, pull requests and file listings, as of the morning of 17 October one of those paths is a released package.

What shipped, and what it weighs on disk

Three official checkpoints went up, and the Hub API reports their safetensors totals exactly:

• BF16: 1,002.7 GB, which matches the launch post's figure of about 1 TB.
• FP8: 503.3 GB. The launch post points Hopper and Ampere owners at this one but never gives its size.
• NVFP4: 293.6 GB. The launch post says about 280 GB. That gap is 13.6 GB, and on a two-GPU deployment it is not rounding.

The config file explains why long context is cheap. Of the 52 layers, 9 use full attention and 43 use a 512-token sliding window, so only 9 layers keep keys and values for the whole sequence. The vLLM post puts that at 36 KiB per token in BF16 and 18 KiB in FP8, or roughly 18 GiB of FP8 cache for a single 1M-token sequence. For one long sequence, the weights set the hardware bill. Concurrency is another matter, below.

Which runtime can load it today

transformers. Version 5.20.1 landed on PyPI on 16 October and its source tree includes a beam model package. This is the one released package with the architecture in it. For serving, though, the Hugging Face post itself points to the vLLM and SGLang recipes.

vLLM. The vLLM post tells you to run the Docker tag vllm/vllm-openai:reflection-beam, serving the NVFP4 checkpoint with four-way tensor parallelism. That tag was last pushed at 08:17 UTC on 16 October, for amd64 and arm64. The model code behind it lives in two pull requests, 61978 and 62074, and both were still open when I checked; the first says it depends on FlashInfer nightly, and the second splits out a version that does not. The latest tagged vLLM release, v0.31.0, is dated 5 October. So pip install vllm does not get you Beam. A named image built from a branch does.

llama.cpp. Support arrived in pull request 30670, opened by the GitHub user danielhanchen and merged at 22:07 UTC on 16 October. Its description says it began as a draft because the weights were not yet public, and reports conversion and generation tested on CUDA. The first build containing it is b11701. The tagged v0.7.0 release from 15 October is 32 commits behind the merge, and Homebrew's stable llama.cpp is still 0.7.0. The Unsloth GGUF repository was last modified at 13:23 UTC, nearly nine hours before the merge, and its README has no instructions for running the files and names no minimum llama.cpp build. Two more GGUF repositories, from AtomicChat and DevQuasar, appeared the same day.

Ollama. The library page lists exactly one tag, beam:cloud. Ollama's post describes it as running on Ollama Cloud with zero data retention, free for a limited time. Useful for evaluation; not self-hosting.

I did not check SGLang's model code. Its deployment cookbook pull request was still open.

The memory math for a single node

Hugging Face says two 180 GB B200s hold the NVFP4 weights with little room left, and to plan for four. The measured size shows why. The vLLM recipe sets 128 concurrent sequences with an FP8 cache. At 32K tokens each, that is 77.3 GB of cache on top of 293.6 GB of weights, or 371 GB. That is more than the 360 GB of two B200s before activations or the sliding-window buffers are counted. One 1M-token sequence fits: 313 GB.

The GGUF route trades GPU class for memory. Unsloth's dynamic quants run from 103.1 GB for UD-IQ1_S to 532.8 GB for Q8_0. UD-Q2_K_XL is 186.9 GB and UD-Q4_K_XL is 306.5 GB. At four bits, the GGUF is larger than the official NVFP4 checkpoint. Anything that leaves room for a cache on a machine with less than 300 GB sits at three bits or below. The benchmark table on the model card covers BF16, FP8 and NVFP4 only, so there are no published task scores for those levels.

What it breaks, and the verdict

Nothing breaks, because nothing existed before. The cost is operational: today, every fast Beam deployment runs software that is not in a release. The vLLM image is built from code still under review, and the llama.cpp build you would need is newer than any packaged channel. Whatever you benchmark on the image now is not guaranteed to match the model code that eventually merges.

My central claim: as of 17 October, transformers 5.20.1 is the only released package that can load Beam, and every other self-hosting path means building from a branch or after a release. This is wrong as soon as vLLM merges Beam support and tags a release, Homebrew moves past 0.7.0, or Ollama publishes a tag without cloud in its name.

The verdict: evaluate now, on the cloud tag or a rented Blackwell node. Hold any production self-hosting commitment until the model code is in a tagged vLLM release. The build, buy or fine-tune question for an open-weight model of this size is mostly a question about who maintains the serving stack, and right now that is a branch.

Checks to run before ordering hardware

1. Confirm your llama.cpp build contains the Beam merge. A status of identical or behind means it does, and ahead means it does not:

gh api repos/ggml-org/llama.cpp/compare/v0.7.0...01fc3aae846caa644f0cee360f108d4c48e4aaa1 --jq .status

Swap v0.7.0 for your build tag. Today it prints ahead for v0.7.0 and b11700, identical for b11701, and behind for b11706.

1. Price the weights from the Hub, not from a launch post. This prints 293654927078 bytes for the NVFP4 repository:

curl -s 'https://huggingface.co/api/models/reflection/Beam-1.0-501B-A23B-NVFP4?blobs=true' | jq '[.siblings[].size] | add'

1. Add the cache: 18,432 bytes per token per sequence in FP8, times your context, times your concurrency. If weights plus cache come within 10 percent of total GPU memory, add a GPU. Activations and the sliding-window buffers are not in that sum.