Self-hosting Reflection's newly released Beam starts with a 273 GiB download for its smallest official checkpoint, NVFP4. That's the storage requirement for a coding model that activates 23 billion parameters per token. Its download guide starts with four B300 GPUs connected by NVLink. For developers considering self-hosting, that hardware requirement deserves attention before the benchmark scores.
Reflection has released the instruction-tuned model with 501 billion total parameters and a one-million-token context window. It takes text in and produces text out, with coding and tool use among its intended workloads. The model card describes a model developed predominantly for English. This release gives teams access to the weights, but running them means choosing a serving configuration with its own memory and context limits.
Eight experts work while the rest stay in memory
Beam routes each token through eight of its 256 experts. That reduces the computation needed for a token, while the other experts remain available for subsequent tokens. Hugging Face's launch walkthrough explains the distinction: the active parameter count describes how much of the network computes a token, while deployment still needs space for the full model. Treating 23B as the memory requirement would leave most of the weights unaccounted for.
Reflection lists these checkpoint sizes in its download documentation. These are storage figures, before the running server allocates working memory:
| Official format | Download size |
|---|---|
| NVFP4 | 273 GiB |
| FP8 | 468.72 GiB |
| BF16 | 933.81 GiB |
The smallest version also needs more explanation than the label "4-bit" supplies. Reflection's quantization documentation says it compresses the routed expert networks, which contain most of Beam's parameters. Attention and the dense networks retain their original BF16 precision, as do several other components. NVFP4 therefore describes a mixed-precision checkpoint, rather than every number in the model occupying four bits.
Native NVFP4 execution requires NVIDIA Blackwell hardware, according to that same technical guide. It validates four B300s per model copy and explicitly says that count isn't a minimum requirement. Hugging Face separately recommends four B200s to leave room for long contexts and concurrent requests. A configuration that holds the weights still needs enough spare memory to do useful work.
Beam does economize on conversation memory. Its published configuration has 43 attention layers limited to a sliding window of 512 tokens and nine layers that attend across the full sequence. Most layers therefore avoid keeping an ever-growing history. That design reduces one source of memory growth without shrinking the collection of experts that the server must load.
The serving recipe changes what you can use
Day-one vLLM support comes with a packaging detail. The merged Beam recipe pull request says support hadn't shipped in a regular release or nightly wheel at launch. Its installation path uses the dedicated vllm/vllm-openai:reflection-beam Docker image. Developers starting from an existing vLLM installation need to check the build, rather than assume that downloading the checkpoint completes the setup.
The recipe's validation record is narrower than its list of eligible hardware. It reports testing the release NVFP4 checkpoint on four B300s, while the H200 results used prototype checkpoints. Its one-million-token check recalled inserted material from three positions in a long prompt. Those are useful engineering checks, but they don't establish that every listed GPU configuration has passed equivalent tests or that arbitrary questions over a million tokens will be answered correctly. The distinctions are documented in the pull request.
Reflection's own vLLM walkthrough illustrates another choice. Its four-B300 development configuration sets --max-model-len 262144 and allows eight concurrent requests. The model's advertised context capacity doesn't automatically become the context limit of every endpoint. A team copying that recipe would start with a 262,144-token limit, then need to test any increase against available memory and its workload.
Hugging Face's FP8 endpoint catalog makes the tradeoff visible in money. The recipe displayed when checked uses eight A100 GPUs with 640GB of GPU memory, costs $20 per running replica per hour, and sets a 131,072-token model limit. At that rate, keeping one replica running for 24 hours would cost $480. Scale-to-zero can stop replica billing while idle, although the catalog warns that waking the endpoint takes time. This is one hosted configuration's price, not a universal cost for Beam.
A 708-token-per-second result has a workload attached
The vLLM team's launch measurements report 708 output tokens per second for a single request using eight-way tensor parallelism and the DFlash2 speculative decoder. DFlash2 proposes blocks of tokens for Beam to check together, allowing an accepted block to advance generation faster than checking one token per step.
That result comes from a predictable-text subset of NVIDIA's SPEED-Bench, largely code completion and text sorting, with roughly 1,000-token prompts and greedy decoding. The authors warn that open-ended chat should have lower draft acceptance. Their results table also separates concurrency: adaptive verification barely changes single-request throughput, but improves aggregate output throughput by 10.8% at 128 concurrent requests. A developer sizing a service needs the matching workload and concurrency level before using either figure in a capacity estimate.
Check the precision you intend to deploy
Reflection's benchmark table reports SWE-bench Verified scores of 81.6% for BF16, 80.2% for FP8 and 80.7% for NVFP4. SciCode falls from 49.2% in BF16 to 46.9% in NVFP4. On SWE Bench Pro v2-Hard, however, NVFP4 scores 78.6%, above BF16's 76.5%. These are Reflection's evaluations, not measurements made by MrKeyoor. They show why the smallest checkpoint needs its own assessment: changes in precision don't produce an identical effect across tasks.
Application settings matter too. Reflection's reasoning guide says Beam always reasons and accepts five effort levels, from low through max. Reasoning tokens count toward the completion limit. If that limit expires before the answer begins, the response can finish with length and no answer content. An application that budgets only for the visible reply can therefore fail even when the server has enough memory to run the model.
Conversation handling adds a compatibility requirement. The hosted API requires previous assistant messages to retain their reasoning, including during tool-call exchanges. Removing that field can produce an HTTP 400 error. Reflection's self-hosted vLLM recipe also enables a setting that rejects missing reasoning. Anyone adapting an existing chat client should check how it stores assistant messages before treating API compatibility as settled.
Test the endpoint before paying for a benchmark run
Reflection supplies a Beam Verifier that separates API conformance from model evaluation. Its functional tests cover tool exchanges and structured output, including streamed responses. The documentation expects those checks to pass before a benchmark run. For an installed verifier and an endpoint using the model name from Reflection's serving guide, the check is:
beam-verifier verify \
--base-url http://localhost:8000/v1 \
--model-name Beam-1.0-501B-A23B
Access to the weights gives teams room to change the model as well as serve it. The repository includes an Apache 2.0 license, whose terms permit modification and redistribution subject to its conditions. A team can therefore distribute its modified model under those conditions, while choosing its own hosting arrangement. It still needs to test that version against the tasks it expects the model to perform.
The next evidence to watch is repeated testing of release checkpoints on the hardware developers can obtain. The vLLM recipe records where validation still relied on prototypes, and Beam Verifier provides a way to check a particular endpoint. Before reserving a server for longer runs, establish that it preserves tool calls correctly, completes answers within your token budget and passes representative tasks at the precision you can afford to keep loaded.