Reflection AI announced Beam on October 5, 2026. It is a sparse mixture-of-experts model with 501 billion total parameters and 23 billion active per token, text-only, aimed at coding, reasoning and agentic work. The weights are not out yet. The blog says Beam is "undergoing final red-teaming and evaluations," that a select group gets early access, and that the weights, technical report and model card follow "later this month" under Apache 2.0. When I checked Hugging Face this evening, there was nothing to pull.

So this isn’t a "download it and run it" post. I’m writing it anyway because the announcement is unusually specific about the infrastructure that produced the model: how many GPUs, how long, how often things broke, how fast weights moved across the fleet, and how much capacity was lost. Most model launches give you a benchmark table and a vibe. This one gives you numbers an operator can compare against their own cluster.

The model, as described

From the Reflection post and TechCrunch’s coverage:

  • 501B total / 23B active, sparse MoE with fine-grained routed experts. The expert count and top-k aren’t given.
  • 52 layers (from the residual-stream figure caption), with interleaved local and global attention.
  • 23.8 trillion pretraining tokens; the effective context is extended to 1M tokens during midtraining.
  • Numerics choices: SandwichNorm, elementwise attention gating, a depth-based residual scaling scheme, and FP32 residual accumulation.
  • Load balancing builds on auxiliary-loss-free balancing, with cosine decay on expert-bias updates plus sequence-level balancing. Reflection says the busiest expert’s load, averaged across MoE layers, is 1.04× at the end of pretraining.

For scale, TechCrunch puts GLM-5.2 at roughly 744B total and 40B active. Reflection’s headline claim is that Beam scores comparably to GLM-5.2 on advanced reasoning while using "3–4× less inference compute."

Read the efficiency claim carefully

That 3–4× figure isn’t a serving measurement, and the post says so. It is estimated as FLOPs ≈ 2 × active parameters × mean generated tokens per attempt. That counts reasoning and answer tokens and excludes prefill, context-dependent attention and serving overhead. Other models’ eval numbers come from Artificial Analysis and DataCurve. It’s a fair first-order way to compare reasoning models, since active parameters times tokens drives decode cost. But a long agentic trajectory at 256K or 1M context spends real time on attention and KV cache, and this formula leaves both out. I’d treat it as "Beam uses fewer tokens at a smaller active size," not as a cost-per-task number.

The benchmark table is also vendor-reported, with many cells marked NR. On Reflection’s own numbers, Beam reports 80.9 on SWE-bench Verified, 80.1 on Terminal-Bench 2.1 (GLM-5.2 at 81.0, DeepSeek V4.1 Flash at 90.6), and 90.5 on GPQA Diamond. The post itself says frontier open models like Kimi K3 "remain ahead on raw capability." TechCrunch notes that none of these scores had been independently verified. I’m not going to rank anything on that table until the weights are public and third parties have run it.

The part I actually care about: the training fleet

Pretraining. Reflection says Beam was pretrained end to end in under four weeks on 6,144 NVIDIA GB300 GPUs in NVL72 systems. The stack is mostly in-house: a topology-aware, Kubernetes-based scheduler, a node lifecycle system with continuous health monitoring, and a silent data corruption (SDC) detector that can trigger semi-autonomous rewinds and restarts. The run needed nine semi-automatic rewinds, attributed either to non-deterministic gradient-norm spikes or to suspected SDCs. Goodput, defined as the share of wall-clock time spent on steps kept in the final model, "reached 92.3% towards the end." I’d note the wording: that is the late-run figure, not the average over the whole run.

Two things stand out to me. First, SDC is named right alongside gradient spikes as a reason to rewind a frontier run. If you operate large training runs without a detector, some of your unexplained loss spikes may be exactly this. Second, they define goodput as retained steps over wall clock. That’s the honest definition, because work lost to a rewind counts against you, and it’s the one I’d want vendors and neoclouds to quote.

Reinforcement learning. The RL campaign ran on 10.5K GB300 GPUs for four weeks and generated more than 100 million rollouts with a 256K maximum context. About 1.3 billion sandboxes were used for training and grading. The operational detail:

  • Average 110K concurrent rollouts, fully asynchronous, with each token tagged by the policy version that produced it. Reflection says learning stayed stable with one-day-old samples, 107 weight versions behind the current policy.
  • Inference-to-training GPU ratios from 3.9:1 to 5.4:1. Most of the RL fleet was doing inference. The trainer was resized across five GPU mesh configurations within one lineage without losing state.
  • Weight distribution: a median of about 12 seconds for new weights to reach the inference fleet. Weights move across racks over RoCE and are then shared within the rack over NVLink. Compared with every replica pulling directly, Reflection says this cut cross-rack traffic by 75% and made fleet-wide adoption 2.2× faster.
  • 71 inference incidents were handled without stopping the training run. Median recovery was eight minutes, and lost capacity was 0.02% of elapsed serving GPU-minutes.
  • Sandboxes: up to 170K concurrent, more than one billion creation requests across 20+ clusters, two clouds and four regions, with 90% ready in under 10 seconds.
  • Trainer packing kept batches 99.99% full on average. Per-GPU trainer throughput stayed within 1.5% as mean rollout length grew almost 70%.

All of these are self-reported, and there’s no tech report yet to check the methods against. Even so, they’re the right metrics to publish, and they point at the bottlenecks I’d expect in any agentic RL setup. The 3.9–5.4:1 ratio says plainly that agentic RL is an inference-serving problem with a trainer attached. The 12-second weight push is the number that sets how stale your rollouts get. And the sandbox numbers (170K concurrent, 90% under 10 s) show that the CPU-side container fleet is as much a scheduling problem as the GPUs.

The weight-distribution design is also the same pattern I’d reach for when serving: send one copy per rack over the scale-out network, then share it within the rack over NVLink, rather than having every replica pull from object storage or the trainer. It’s a different problem from the one in this morning’s vLLM 0.31 fast-restart post, which keeps weights resident on a single node. Both treat getting weights onto GPUs as a cost worth engineering down.

What’s missing

  • No weights, model card or tech report yet. No precision for the released checkpoint, no expert count or top-k, no KV-cache layout for the local/global attention mix, and no head dimensions. All of that drives the serving plan.
  • No serving numbers. No tokens/s, no TTFT, no minimum hardware. The post promises "integration with a broad range of open source libraries" at launch, but names none.
  • Benchmarks and efficiency are vendor-reported, and the efficiency estimate excludes prefill and attention by construction.
  • Goodput is a late-run figure, and "under four weeks" is approximate.

What I’d test when the weights land

  1. Footprint. My own arithmetic, not a vendor figure: 501B parameters is about 501 GB at one byte per weight before KV cache, so a single 8-GPU H200- or Blackwell-class node looks plausible at FP8, while BF16 at roughly 1 TB gets tight once KV cache is added. I’d check whatever precision actually ships against that.
  2. Long-context decode. Interleaved local/global attention should shrink KV growth versus all-global layers. I’d measure KV bytes per token and decode throughput at 128K, 256K and 1M in vLLM and SGLang, once either supports it.
  3. Token efficiency on my own tasks. Mean generated tokens per solved agentic task at each reasoning-effort setting. That is the input to Reflection’s FLOPs estimate, and I can measure it directly.
  4. Expert-parallel balance. If the 1.04× peak expert load holds on real traffic, EP all-to-all imbalance should be mild. I’d log per-expert token counts under coding versus chat traffic before choosing an EP width.

Until then, Beam is a well-documented announcement rather than something I can run. The infrastructure numbers are worth reading now. The model can wait for its weights and the tech report.

Create-only. Specs from Reflection’s October 5, 2026 Beam announcement and TechCrunch’s coverage. Update when the weights, technical report, or model card ship.

Sources: Reflection: Introducing Beam · TechCrunch.

Anpoo Sivanadi, Staff Software Engineer