Serving Beam 1.0 on Day Zero: What the SGLang Recipe Actually Pins Down

A checkpoint you can download is not a model you can deploy, and the distance between the two is normally measured in weeks of framework work done by whoever is impatient enough to do it. Reflection Beam 1.0 is the rare case where that work arrived with the weights. Reflection announced the model on 5 October 2026; on 16 October 2026 the weights, the Apache 2.0 licence, a first-party endpoint and day-zero support across seven inference stacks all landed together, and one of those stacks — SGLang, whose own project account said on the 16th that it serves Beam in production at Reflection — shipped a recipe detailed enough to argue with.

That recipe is the interesting artefact, more than the benchmark table. A launch post tells you a model is good. A deployment matrix tells you what it costs to find out, and where the choices you make will quietly determine your latency. Reflection Beam 1.0's SGLang documentation is a generator: you pick a hardware platform and a strategy, and it emits a pinned Docker command. The options it forces you through are the actual news for anyone who intends to run this rather than call it.

The three axes the recipe refuses to hide

The page asks for hardware platform, strategy and quantisation, then builds the command. That is a smaller decision space than most model releases admit to, and each axis has a real consequence:

• Hardware platform — B300, GB300 or H200. The Blackwell parts take the NVFP4 build natively; H200 is the FP8 and BF16 path. This is the same floor Reflection's release notes describe, restated as a dropdown.

• Strategy — low-latency or high-throughput, and this is the axis most deployments get wrong by default. Low-latency runs tensor parallelism with the DFlash2 drafter enabled at block size 8. High-throughput disables DFlash2 entirely.

• Quantisation — NVFP4, FP8 or BF16, which have to line up with the platform and the strategy rather than being freely combinable.

The two strategy presets are not a performance dial, they are a change of algorithm. Speculative decoding trades decode latency against extra draft-model work per step; at block size 8 with a 1.93B-parameter drafter, that trade is worth taking when you are serving one user at a time and worth refusing when you are batching aggressively. Turning DFlash2 off for the high-throughput recipe is not a downgrade, it is the correct answer to a different question.

Where the recipes stop being interchangeable

Read past the presets and the page documents a handful of configuration splits that exist for concrete hardware reasons, and they are worth knowing before you copy the first Docker command you see:

• H200 BF16 runs TP8 with an automatic static memory fraction. The 933.81 GiB BF16 checkpoint does not fit on fewer devices, and the memory fraction is computed rather than exposed — which means this is the one recipe you cannot hand-tune without leaving the supported path.

• Every other recipe uses tensor parallelism plus DPA. DPA here is the data-parallel attention arrangement that decouples attention from the expert-parallel split, and it is why the non-BF16 recipes tolerate device counts the BF16 one does not.

• Blackwell NVFP4 additionally enables expert parallelism and FlashInfer MegaMoE. This is the combination Reflection's own guides point at, and it only becomes available once the checkpoint is the packed 4-bit build at 273 GiB rather than FP8 at 468.72 GiB.

The practical upshot: "we run Beam 1.0 on SGLang" is not a hardware statement. Two teams can both say it while running different precisions, different parallelism layouts and different decoding algorithms, and the only way to compare notes is to name all three.

What "day zero" is worth, and what it is not

Framework support on the day weights ship is a real signal, and it is a specific kind of signal. SGLang's support for Beam 1.0 exists because Reflection's engineers worked with the SGLang community ahead of the release — that is what the SGLang project said publicly on 16 October, and it is consistent with Reflection naming SGLang among its day-zero partners alongside Transformers, vLLM, Unsloth, Axolotl, TokenSpeed and N​VIDIA Dynamo, with written recipes for SGLang, vLLM and TokenSpeed plus a Helm chart for Kubernetes.

• What it establishes — a documented, maintained path from the published checkpoint to a served endpoint, on named hardware, with the quantisation variants accounted for. That is genuinely more than most open releases manage in week one.

• What it does not establish — that the configuration is optimal, or that the throughput numbers you will get match anyone else's. The production-at-Reflection claim is the vendor's and the framework's, reported by the people doing the serving. We have not seen an independent reproduction of it, and no third-party benchmark of a self-hosted Beam deployment has been published.

That distinction matters more here than usual, because this is a 501.3-billion-parameter sparse mixture of experts with 23.4 billion parameters active per token, and the entire value of the architecture is that your serving cost is a fraction of the model's name. Framework support is what converts that claim from an architecture diagram into a memory budget. It does not convert it into a measured throughput figure, and no first-party material we could find publishes one for inference — the only concrete tokens-per-second number in the release describes LoRA supervised fine-tuning on a single node of 8 B300 GPUs, which is a training step, not a serving rate.

The failure mode a self-hosted day-zero stack actually has

There is a specific way this goes wrong, and it is not the model. It is the second week. A pinned Docker image built for one quantisation and one parallelism layout is not a fallback for itself: if the drafter has a bad interaction with your traffic pattern, if a driver update changes what the memory fraction allocates, or if your capacity is queued behind another tenant, you do not have a configuration left to fall back to — you have an outage with a very capable model sitting in 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 put the fallback somewhere useful. OrcaRouter runs one OpenAI-compatible key across 200-plus models with the provider's list price passed through and nothing added, and automatic failover across providers, so a self-hosted Beam pilot that stops answering is a routing change rather than an incident. The models a Beam deployment is most often replacing, and which are reachable that way, come with published rate cards:

• GLM-5.2 — $1.40 per million input tokens and $4.40 per million output with a 1,000,000-token context. The model Reflection's own efficiency claim is measured against, and the most direct substitute for Beam's long-context coding work.

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

• Qwen3.8-Max — $2.00 per million input and $6.00 output at a 1,000,000-token window, the flagship-tier proprietary option for teams who want the capability without the rack.

What the recipe still does not tell you

Three gaps are worth naming, because each one is a decision you will end up making with less information than you would like.

The first is price. Reflection's endpoint is documented and O​penAI-compatible, with reasoning efforts of max, xhigh, high, medium and low, mandatory reasoning led by a default of max, and per-organisation limits shared across every key. It has no published per-million-token rate, so the efficiency case for Beam 1.0 cannot be finished as an arithmetic exercise. A model that always reasons and defaults to maximum effort is a different commercial proposition depending on whether the output token is priced at one dollar or ten.

The second is independent measurement. Artificial Analysis lists the model with an Intelligence Index of 30, no speed figure and no price, and records no publicly available API for it — which is a third-party statement that the hosted surface is not yet visible to the people who measure these things. Its one independently counted efficiency datapoint is real: Beam generated 79M output tokens across AA's Intelligence Index against a median of 130M for the comparison set. That supports the "fewer reasoning tokens" claim. It does not tell you how fast the tokens come out.

The third is version drift. The published recipes are written against a specific checkpoint and a specific SGLang build, and the drafter is its own repository. When either moves, the recipe you pinned in October is a configuration nobody has tested in November. Treat the Docker command as a starting point with an expiry date, not as a deployment.

Who should act on this now, and who should wait

If you already own the Blackwell capacity, the SGLang recipe is genuinely enough to start: four B300s is the reference NVFP4 configuration, the memory math is published, the conformance suite exists, and the downside is bounded to engineering time. If you do not own the hardware, the calculation still does not close, because the hosted option has no rate card to compare against a capital purchase — and the day-zero framework support, as good as it is, is not a substitute for a price.

The thing to watch is not another framework announcing support. It is the first published number that did not come from Reflection or from a framework project: an independent throughput measurement on a named configuration, or a rate card on the first-party endpoint. Either one turns this from a well-documented experiment into a line item. Until then, the correct reading of 16 October is that the hard engineering shipped on schedule — and the commercial case is the part still under construction.

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.