Beam 1.0 on Four B300s: The Serving Math, and the Throughput Claim Nobody Published

The number worth pausing on in Reflection's Beam 1.0 release is not 501 billion. It is four. A model with 501.3 billion total parameters and 23.4 billion active per token now fits on a single server with four N​VIDIA B300 GPUs on NVLink, and the distance between those two figures — about 4.7 per cent of the model awake on any given token — is the whole reason a checkpoint of this size is downloadable by anyone who does not own a cluster. Reflection published the weights on 16 October 2026 under Apache 2.0, and the launch material is unusually specific about what it takes to serve them: four B300 GPUs on NVLink for the NVFP4 build, eight H200s for FP8, and eight B200s or B300s for BF16. That hardware table is more interesting than the benchmark table, because it is the part a reader can actually check against their own procurement sheet.

It is also the part that separates Beam 1.0 from the models it is measured against. Kimi K3 and GLM-5.2 are served behind APIs and their weights either are not public or come with a different set of conditions; Qwen3.8-Max is proprietary at the flagship tier. Beam's pitch is that the hard half of that trade — a frontier-adjacent model available to download — shipped, and that the serving cost is a rack rather than a data centre.

What actually landed on 16 October

Reflection's "Beam is now available" post is dated 16 October 2026, eleven days after the model was announced on 5 October. Four artefacts shipped, and the precisions matter more than the headline:

• BF16 — 501.3B parameters, 933.81 GiB on disk, 188 safetensors shards. The reference precision; the benchmark table's first column.

• FP8 — the same parameter count in E4M3, 468.72 GiB. Quantised with N​VIDIA ModelOpt. Recommended for Hopper and older hardware.

• NVFP4 — a packed 4-bit build at 273 GiB. This is the one Reflection's own serving guides tell you to download, and the only one that runs natively on Blackwell without a dequantisation penalty.

• DFlash2 — a 1.93B-parameter speculative-decoding drafter, published as its own repository and wired into the sample commands as a separate weight set.

The architecture behind those checkpoints is a sparse mixture of experts: 52 layers, of which 3 are dense and 49 are MoE, 256 experts per MoE layer, gated grouped-query attention mixed with sliding-window attention, and a 152,000-token vocabulary. Text in, text out, 1M-token context on the model card, 131,072 tokens of maximum output on the API. Knowledge cutoff 30 June 2026.

The throughput figure that is not in the documentation

A number has been circulating with this release since day zero: more than 70,000 output tokens per second per GPU on Blackwell Ultra. It is an attractive figure and it is worth being precise about where it does and does not appear. It is not in Reflection's launch post, not in the model card, not in the Hugging Face release notes, and not in the developer documentation. We could not find it in any first-party source.

What the vendor material does document is relative rather than absolute. The model card's single efficiency claim is that Beam "reaches comparable solution quality to leading open models using approximately 3x fewer inference-time reasoning tokens," and the launch post frames the same idea as "more intelligence per token." The one throughput-shaped number the release does publish is a measured speedup rather than a rate: the DFlash2 drafter lifts decode speed by 1.7× to 3.0× over Beam alone, measured on the NVFP4 checkpoint across four B300s, with acceptance lengths of 4.11 to 5.88 tokens out of a maximum of eight. That is a ratio against Beam's own baseline, so it says nothing about absolute tokens per second per GPU — it will not settle the 70,000 figure either way.

There is one independent signal that the efficiency claim is not pure marketing. Artificial Analysis measured Beam 1.0 at 79M output tokens across the Intelligence Index, against a median of 130M for the models it compares to — ranked #10 of 46 on that measure. That is a third party counting generated tokens and finding Beam more frugal than most of the field, which is a weaker claim than a per-GPU throughput figure and a much better-supported one.

What four B300s actually buy you, in memory

The serving documentation is the most useful thing Reflection published, because it answers questions a benchmark table never asks. Three numbers stand out.

• KV cache footprint — the vLLM and N​VIDIA Dynamo recipes both default to an FP8 E4M3 cache with a 64-token page size, which the vLLM recipe notes doubles to roughly 14M to 28M tokens of cacheable context on eight H200s running the FP8 checkpoint. That is the number to size a deployment against; a three-GPU plan fails long before the cache does.

• The NVFP4 checkpoint quantises only the routed experts. Attention, dense MLPs, the router, embeddings and the LM head stay in BF16, which is why the file is 273 GiB rather than the 250-odd a full 4-bit pass would give you. On Blackwell it runs W4A4; on Hopper, vLLM serves the FP4 experts through Marlin with BF16 activations.

• The NVFP4 checkpoint on four B300s is the reference configuration, and the SGLang recipe ships as a pinned Docker image with tensor parallelism set to 4, the DFlash2 drafter enabled at block size 8, and speculative decoding configured alongside FP8 KV cache.

There is also a verification tool. The open-source beam-verifier CLI runs a conformance suite against any live Beam endpoint — request contract, response contract, tool protocol — and then evaluates it on the main benchmarks so you can compare your own deployment, or a provider's, against Reflection's reference scores. For a model whose benchmark table is entirely vendor-reported, shipping the harness that lets a buyer reproduce it is a more meaningful commitment than any single number in that table.

Day-zero framework support is the other half of the deployment story, and it is broader than most open releases manage: Transformers, vLLM, SGLang, Unsloth, Axolotl, TokenSpeed, and N​VIDIA Dynamo, with step-by-step recipes for SGLang, vLLM and TokenSpeed plus a Helm chart for Kubernetes. On the training side Reflection names the stacks it built the workflows with — NeMo RL and AutoModel and Megatron Bridge from N​VIDIA, Miles from RadixArk, TRL from Hugging Face, SkyRL from Anyscale and Axolotl — and publishes its RL runbook numbers rather than a hardware figure for them: 10.5K GB300 GPUs over four weeks, more than 100 million rollouts, a 256K-token maximum context during training, and roughly 1.3 billion sandboxes.

The API exists, and it still has no price

Alongside the weights there is a first-party endpoint at api.reflection.ai with an O​penAI-compatible surface and the model ID Beam-1.0-501B-A23B. It carries a documented contract: mandatory reasoning with efforts of max, xhigh, high, medium and low, where max is the default; structured outputs and tool calling; organisation-wide rate limits measured in requests and tokens per minute and per UTC day, shared across every project and key so that adding a key does not raise them; and a 429 response that sets x-should-retry false once a daily allowance is spent, which is the detail that stops a naive retry loop from spinning until midnight.

The docs do not carry a per-million-token price, and neither does the announcement. That single omission is what makes the efficiency argument unfinishable for a buyer: a model that always reasons, defaults to maximum effort, and claims three times fewer reasoning tokens is a different commercial proposition at one dollar per million output tokens than at ten, and nobody outside Reflection can currently say which it is. Self-hosting removes the question entirely and replaces it with a capital number, which is at least a number you can compute.

Where this leaves a team that wants to try it

Beam 1.0 is not one of our routes, so we cannot serve it for you, and nothing here should be read as an availability claim from us. What we can do is make the evaluation cheap. If the decision in front of you is whether to spend a quarter of engineering time on a two-week Beam pilot, the useful move is to keep production on a model with a published rate card and a service history while the pilot runs, and to have the fallback already wired. OrcaRouter runs one OpenAI-compatible key across 200-plus models with the provider's list price passed through and nothing added, so a vendor price cut reaches your bill the same day, and automatic failover means a pilot that turns out to be unavailable next month is a routing change rather than a migration.

The models closest to Beam on the workloads it targets are all reachable that way. The three worth pricing the pilot against, off our own catalogue:

• GLM-5.2 — 1,000,000-token context, $1.40 per million input tokens and $4.40 per million output. The model Reflection's own efficiency claim is measured against.

• Kimi K3 — 1,048,576-token context, $3.00 per million input tokens, $0.30 cached, $15.00 output. Reflection's launch post concedes K3 remains ahead on raw capability.

• Qwen3.8-Max — 1,000,000-token context, $2.00 per million input and $6.00 output, the 2-trillion-parameter class Beam claims its largest efficiency advantage over.

The three things to watch

The first is the price. Until Reflection publishes a rate card, the efficiency thesis is a hypothesis about compute rather than a fact about money, and the comparison against GLM-5.2 or Kimi K3 stays an argument about methodology.

The second is an independent throughput measurement. Artificial Analysis currently lists Beam with an Intelligence Index of 30 and no speed and no price, because it records "No publicly available API" for the model. When that changes, the per-GPU question gets an answer that did not originate with the vendor.

The third is whether the verifier gets used. A conformance suite that nobody runs is documentation; a conformance suite that a dozen deployments publish results from is a benchmark. Beam 1.0 shipped the tool on day zero. Whether it ships the numbers is the part that is still open.

None of that is hypothetical: the documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.