DeepSeek V4.1-Flash vs Reflection Beam is the head-to-head this post settles — an open-weight MoE inference cost comparison built for self-hosters. It is a different axis entirely from our Claude Code vs Codex Terminal-Bench 4.0 comparison: that piece measured score-per-dollar on agents, while this one prices what each model costs you in memory, hardware topology, and engine support.
The two contenders bracket the last few weeks — their weight releases landed about five weeks apart. DeepSeek announced DeepSeek-V4.1-Flash, a 552B-backbone MoE with an asymmetric 8B/16B active-parameter design, on September 10, 2026 — the day its new pricing took effect — put it live on the DeepSeek API, and started routing V4-Pro requests to it from September 14; a refreshed 1017 checkpoint followed on Hugging Face on October 17. Reflection teased Beam as a preview on October 5, then released the weights of its first open-weight model — a 501B-parameter sparse MoE with 23B active parameters — on October 16, eleven days after the preview, under Apache 2.0. DeepSeek open-sourced DeepInfer, the inference framework behind V4.1-Flash’s service, in the same week the Beam weights landed; the repo’s most recent push was October 21, and it is Apache 2.0. Both launch stories promise efficiency. This post prices them against a self-hoster’s actual question: what does it cost to serve?
A note on method up front: every figure below is attributed to its source, and vendor throughput claims are labeled as vendor-claimed. Where sources disagree, we present both and never average them. Where we couldn’t verify something in this run, it’s marked [UNVERIFIED].
The box score: DeepSeek V4.1-Flash vs Reflection Beam, two very different MoE philosophies
DeepSeek-V4.1-Flash (Hugging Face model card) is 552B backbone parameters, contexts up to one million tokens, MIT-licensed. Its defining trick is a Causal Encoder-Decoder (CED) architecture: a 20-layer causal encoder followed by a 20-layer decoder, where the decoder’s global KV cache is projected from the final encoder hidden states rather than from each decoder layer’s own states. That lets it activate only 8B parameters per token during prefill and 16B during decode — an asymmetry aimed at input-heavy agentic workloads, where prompts dwarf completions. Add a vision encoder for native multimodality, a 196B-parameter “Engram” conditional-memory component sparsely accessed by token lookup, and DSpark speculative decoding.
Beam (Reflection launch post) is a 501B total / 23B active sparse MoE with a 1M-token context window, built for coding, reasoning, and agentic workloads. Per the vLLM write-up: 52 layers, of which 43 use sliding-window attention over the last 512 tokens and 9 attend over the full context with no positional encoding; 256 routed experts per MoE layer with no shared expert, routed DeepSeek-V3-style. Reflection says it trained on 23.8T tokens and ran a 4-week RL campaign on 10.5K NVIDIA GB300 GPUs.
Both are efficiency stories, aimed at different bottlenecks: DeepSeek compresses the context side (KV cache), Reflection the weights and generation side (sparse experts, quantization, block speculative drafting).
Axis 1: The weights set the entry price for a Reflection Beam 501B serving deployment
Before any cache math, you have to pay for the weights and house them.
Beam’s checkpoints weigh, summed from Hugging Face file listings and cross-checked against Reflection’s download page by SXZ.io: BF16 at 1,002.7 GB, FP8 at 503.3 GB, NVFP4 at 293.6 GB, plus a 3.9 GB DFlash2 drafter. The analysis’s arithmetic against config.json confirms the headline: 49 MoE layers × 256 experts = 493.25B of expert weights, 98.40% of the model — which is why quantizing only the routed experts gets the whole model down to ~294 GB.
The practical consequence: Reflection’s validated serving unit is four B300 GPUs for NVFP4, FP8 fits eight H200s, and the vLLM recipe’s minimums are weights plus 20% headroom — 353 GB for NVFP4, 604 GB for FP8. All Apache 2.0, license verified by SXZ.io, with the model card explicitly not prohibiting distillation, fine-tuning, or quantization.
For DeepSeek-V4.1-Flash, the Hugging Face Hub API for the October 17 -1017 checkpoint puts the total download at 510.3 GB (475.3 GiB) across 83 files (the main-model repo holds 90 files, same ≈510.3 GB total), fetched 2026-10-23 — and warmctl.io describes the 1017 checkpoint as 476 GB: FP4 experts, FP8 everything else, with two Engram lookup tables amounting to about 40% of the checkpoint. What the sources specify further is precision and topology — and this is the axis the “cheapest 500B model to self-host” question actually turns on. Per the DeepInfer deployment Q&A, MoE routed-expert weights and indexer KV run in MXFP4; per the HF model card, the main KV cache runs in FP4. Per DeepSeek’s own deployment Q&A in the DeepInfer repo, the recommended deployment is not a single node: prefill runs on “ordinary 8-GPU machines” while decode wants “ordinary 64–128-GPU supernodes,” and DeepSeek’s announcement page openly asks “Planning a large-scale deployment with 2,000 GPUs + a storage cluster? Let’s talk.” The smallest efficient unit, by DeepSeek’s own Q&A math, is 64 GPUs of prefill plus 64 of decode — though a minimal 1P + 1D rig is technically deployable.
That’s the first economics split: Beam is sized for a rack you can buy; V4.1-Flash’s open deployment story is sized for a supernode.
Axis 2: KV cache memory efficiency — the trade goes the other way
If the weights favor Beam, the KV cache math strongly favors DeepSeek. This is where the CED design pays, and it’s the reason KV cache memory efficiency is the core argument for Flash’s architecture. (For a primer on why per-token cache size drives fleet economics, see our analysis of AI chip memory costs and HBM dominance.)
Per the model card, CSA2 assigns each attention layer a static Full/Reindex/Reuse mode to share KV across layers; combined with FP4 main KV caching, the global KV cache shrinks to 890 bytes per token — roughly 1/4 of DeepSeek-V4-Flash. DeepSeek’s announcement restates this as economics: versus the previous generation, V4.1-Flash’s KV needs 1/4 the HBM and 1/8 the SSD storage. The SSD half comes from SWA Bounded Replay: instead of persisting sliding-window KV to disk, the model recomputes only the most recent 128 tokens (cost constant in context length, per the deployment Q&A).
Beam, in contrast, keeps only 9 of 52 layers global, but those sum to 36 KiB/token in BF16, 18 KiB in FP8 (vLLM’s post; SXZ.io reproduces the figure from config: 36.08/18.04 GiB at 1M tokens) — roughly 20× DeepSeek per token in FP8 (≈41× against the BF16 figure). DeepSeek stores KV on a dedicated 3FS SSD cluster sized, per the deployment Q&A, at about 14.4 TB per online GPU with >72-hour retention (TTL: 3 days agent, 7 days chatbot).
What each trade buys: Beam’s cache is a rounding error next to the weights — at 256K tokens it’s under 10 GiB BF16 against a 273.5 GiB checkpoint, so capacity planning is mostly a weights problem. DeepSeek’s cache is almost free per token, but capturing that at fleet scale requires the storage-cluster architecture DeepSeek built — and did not ship in the open release.
Axis 3: The serving stacks — the DeepInfer framework vs upstream vLLM
DeepInfer is the framework that “powers DeepSeek’s large-scale production services” (README), originally built primarily on vLLM, Apache 2.0, supporting NVIDIA SM100 GPUs and Huawei Ascend 950 NPUs. Its feature list is serious: Attention DP / balanced CP, MoE EP with EPLB, DSpark confidence-scheduled verification (+4–7% throughput at the production operating point in DeepSeek’s own offline benchmark, vendor-claimed), SWA bounded replay, batch-invariant and deterministic inference, structured outputs, asynchronous scheduling.
Read the fine print, though. The README explicitly notes what is not in the release: a KV cache system, VE/prefill/decode disaggregation, and load balancing across data-parallel replicas — with the disaggregation bullet qualified by “most required engine functionality is already implemented,” i.e. what’s missing is the service plumbing around working engine parts. The deployment Q&A says the KV cache management and load-balancing components are “tightly coupled to our internal infrastructure, so that code is not yet fully open-sourced.” The open artifact is the kernel-and-engine core; the cluster-level plumbing that makes 14.4-TB-per-GPU storage and 64+64-GPU topology work is a documented design, not a downloadable system. Prerequisites (Python 3.12, CUDA 13 or CANN 9.2) and SM100-only NVIDIA support narrow who can run it today. Vendor-claimed scale figures — 155T tokens/day on one cluster and $38 per GPU-hour revenue at valley pricing — are DeepSeek’s production receipts about its own infrastructure, not results reproducible from the open code.
vLLM, meanwhile, serves both models — which is why the question of vLLM DeepSeek vs Reflection Beam throughput has a single-harness answer on the DeepSeek side. Its V4.1-Flash coverage predates DeepInfer’s release: a vLLM team post (“DeepSeek-V4.1-Flash on vLLM: 5× Agentic Throughput Since Day 0,” October 7) plus a B300 recipe cover the model, and the vLLM team reports decode throughput within 6% of DeepInfer’s published curve across batch sizes 8–256 on 32×GB200 (Wide-EP) — vLLM’s own measurement, not an independent audit; the within-6% figure itself comes from the vLLM team’s X post, and note the setups differ (vLLM’s test: 131K context, nextn=3, 32×GB200 Wide-EP; DeepInfer’s published curve: 64-GPU EP64/DP64). A self-hoster can therefore run one engine for both contenders.
Beam’s serving story is also upstream-first. The vLLM day-0 post documents full feature support (reasoning, tool calling, structured outputs) with tensor, data, or expert parallelism; 2.71× faster batch-1 decode (8.95 → 3.30 ms per step, TP8) and 1.87× faster prefill versus vLLM’s own first implementation; DFlash2 adaptive verification adding +10.8% throughput at concurrency 128; and Attention DP + MegaMoE reaching 168.8K input tokens/second peak prefill on 4×GB300, 1.71× above tensor parallelism — all vLLM’s own benchmarks. One honesty flag from SXZ.io: day-0 support shipped via the vllm/vllm-openai:reflection-beam Docker image, not in a released vLLM version, per the registry check at v0.32.0 (October 18). SGLang also ships a cookbook.
The honest-claims section: DeepSeek V4.1-Flash vs Reflection Beam throughput, no averaging
This is the section most vendor-vs-vendor posts skip.
Claims of DeepSeek (vendor-claimed): 1/4 HBM and 1/8 SSD KV cache versus its previous generation; 890 bytes/token global KV; +4–7% decode throughput from DSpark; 155T tokens/day and $38/GPU-hour on the production cluster. Critically, the DeepInfer release itself ships no public throughput leaderboard: its README contains Pareto-curve images (4 SM100 GPUs prefill, 64 decode) with no absolute numbers in text, plus a run_sweep.sh to reproduce. DeepSeek’s own prefill figure, 82–89K tokens/s per GPU, comes from that internal-benchmark setting. But independent third-party serving measurements now exist, so this is no longer a gap to hedge:
The independent benchmark (warmctl.io, published and updated October 21, 2026, byline Kirill Bespalov): DeepInfer at commit 8b16149 (October 20) versus vLLM 0.31.1rc1 — the image of vLLM’s B300 recipe — on DeepSeek-V4.1-Flash-1017, one 8×B300 node, with DeepSeek’s recommended settings for DeepInfer (bounded replay, EP8×DP8, DSpark with 5 draft tokens). vLLM decoded at 65.0K output tok/s with short prompts and 55.0K at 1K→1K, versus DeepInfer’s 36.4K and 27.9K — a 1.8–2.0× vLLM lead on decode and 4.0× at 8K→1K — and prefilled 658K input tok/s against DeepInfer’s 72K, a 9.2× gap (8.2× at 32K prompts). warmctl’s summary, in its words: with the settings DeepSeek recommends, DeepInfer “is not the faster engine” on a single node, and “we could not reproduce DeepSeek’s number on one node” — DeepSeek’s 9×-higher prefill curve comes from a different setup (4-GPU prefill groups, forced expert load balancing, prompt suffixes on a cached context).
A second independent datapoint: InferenceX by SemiAnalysis published measured V4.1-Flash serving numbers on H200 (fp4, 26 benchmarked configurations, run dates September 21 through October 20, 2026), with a headline of 29,147 tokens/s per GPU at 50 tok/s per user.
Claims of vLLM (measured by the vLLM team, not an independent audit): 2.71× batch-1 decode and 1.87× prefill over vLLM’s own first implementation — a relative claim about their optimization work; 708 tokens/s single-request decode with DFlash2 on TP8; 168.8K tok/s peak prefill input throughput; ~88K total tok/s per GPU on the AgentX replay benchmark at 96 concurrent with 91–96% cache-hit rates. We cite these as vLLM’s and only theirs.
The SXZ.io critique (independent, third party to both): the framing that Beam “needs the memory of a 501B model but runs at the speed of a 23B one” (Hugging Face’s launch post) holds for a single request, not for batched serving. Each token routes to 8 of 256 experts, so more tokens sharing a step means more experts touched: the analysis estimates that at 64 tokens per step, roughly 86.9% of a layer’s experts are read — near 257 GB of weights per step on NVFP4 — with the explicit caveat “I measured nothing.” Reflection’s own drafter-card measurements show the same effect outwardly: 288 tokens/s for one request, ~123 tokens/s each at 32 concurrent on 4×B300. Separately, SXZ.io documents that Reflection’s own serving guides run at 256K context and 8 concurrent requests, making the 1M headline “a window length rather than a result the vendor has published.”
Four sources now, four positions, deliberately not averaged: vLLM’s 708 tok/s single-request figure and the vendor’s ~123 tok/s per request at 32 concurrent come from different setups — different drafter configs, hardware, prompts — and quoting either as the Beam speed is exactly the mistake the critique describes.
The serving-economics table
Every figure in the DeepSeek V4.1-Flash vs Reflection Beam table below comes from the attributed sources above; where they disagree, both are shown and never averaged.
| Dimension | DeepSeek-V4.1-Flash | Beam |
|---|---|---|
| Total / active params | 552B backbone + 196B Engram (HF card); 8B prefill / 16B decode active | 501.3B / 23.43B active (SXZ.io from config) |
| License | MIT (HF card) | Apache 2.0, no distillation prohibition (SXZ.io verified) |
| Checkpoint sizes | ≈510.3 GB / 475.3 GiB (-1017: 83 files; main repo: 90 files), FP4 experts + FP8 rest (HF Hub API, fetched 2026-10-23; warmctl.io) | 1,002.7 GB BF16 / 503.3 GB FP8 / 293.6 GB NVFP4 (SXZ.io) |
| KV cache per token | 890 B global, FP4 main KV (HF card); SWA KV not persisted to SSD | 36 KiB/token BF16; 18 KiB FP8 (vLLM post, SXZ.io) |
| KV at 1M context | ~0.9 GB | ~36 GiB (BF16) / ~18 GiB (FP8) |
| Practical context ceiling | 1M claimed; TTL 3–7 days in production (DS Q&A) | 1M claimed; vendor guides run 256K / 8 requests (SXZ.io) |
| Recommended serving unit | 64+64 GPUs (prefill + decode, Wide-EP); SM100 or Ascend 950 (DeepInfer Q&A) | 4×B300 NVFP4 validated unit; FP8 on 8×H200 (Reflection docs via SXZ.io) |
| Engine support | vLLM (day-0 post 2026-10-07 + B300 recipe) and DeepInfer (Apache 2.0, vLLM-derived; KV cache system, P/D disaggregation, load balancing not in release) | Day-0 in vLLM via Docker image + SGLang cookbook; not yet in a release (SXZ.io) |
| Parallelism | Attention DP/balanced CP, MoE EP+EPLB, Wide-EP decode; no TP/CP (Q&A) | TP, DP, EP; Attention DP+MegaMoE; DFlash2 (vLLM post) |
| Fleet storage | ~14.4 TB SSD per GPU on dedicated 3FS cluster (Q&A) | Cache minor next to weights; no storage cluster |
DeepSeek V4.1-Flash vs Reflection Beam: a caveated verdict
This comparison can’t be settled on paper — you can’t compare the two as purchased, only as deployed. And honest limits apply:
For a small-to-mid fleet, Beam is the only one of the two you can actually stand up. ~294 GB of NVFP4 weights on four B300s, day-0 support in two open frameworks, Apache 2.0 with no strings. SXZ.io’s critique is the essential corrective, not a disqualification: size capacity from the concurrency rows (Reflection’s own ~123 tok/s per request at 32 concurrent), not the single-request headline — and treat 1M-token serving as unproven until you’ve run your own long prompts.
For a genuinely massive, agentic, input-heavy service, DeepSeek’s design has the stronger cost theory. Asymmetric 8B/16B activation, ~0.9 GB of KV per million tokens, and week-long SSD cache retention are a coherent answer for a fleet where repeated prefills dominate. But the open release is the engine core only — the KV cache system, disaggregation, and load balancing that make the thesis real are described, not shipped — and DeepInfer targets SM100/Ascend 950 with a 64+64-GPU recommended floor. And the claim that no independent measurement exists no longer stands: on October 21, warmctl.io ran DeepInfer on someone else’s hardware — one 8×B300 node with DeepSeek’s recommended settings — and measured it at 1.8–2.0× slower than vLLM on decode and ~9× slower on prefill, unable to reproduce DeepSeek’s number on one node. An independent measurement now exists, and on a single node it undercuts the case rather than supporting it.
What we still can’t know: whether the two are in the same quality tier under identical harnesses — vendor self-reported tables cross poorly (per SXZ.io, Beam beats DeepSeek-V4.1-Flash on 2 of 9 shared rows in the vendors’ own tables, but cross-table comparisons are noise-prone) — the serving-throughput gap on the DeepSeek side now has independent numbers (warmctl.io on 8×B300, InferenceX on H200), but those measure engines, not model quality. [UNVERIFIED: independent same-harness quality comparison of Beam vs DeepSeek-V4.1-Flash]. Still unpublished and most useful: a same-harness quality comparison, and DeepInfer’s run_sweep.sh and the vLLM recipe side by side on rack-scale hardware — warmctl’s single-node head-to-head covered only part of that ground.
Decision guide
In one line, the DeepSeek V4.1-Flash vs Reflection Beam call for most self-hosters: Beam is the only one of the two ~500B MoEs you can stand up today — everything below follows from that.
- You have 4–8 Blackwell/Hopper GPUs and need an agentic-coding fleet now: Beam. NVFP4 on 4×B300 (validated) or FP8 on 8×H200, vLLM’s Docker image with DFlash2, and expectations set from concurrency, not single-request latency.
- You serve an API where prompts massively outweigh completions (agent platforms, RAG at scale): the DeepSeek design thesis matches you — but running it yourself today means SM100-class hardware at supernode scale plus building the missing cache/storage layer. For most such teams, the honest interim answer is DeepSeek’s own hosted API, where the CED savings are already priced in — the announcement also puts off-peak API rates at 50% of peak.
- You need 1M-token contexts as a guaranteed property: neither vendor has published verifiable serving results at that length — DeepSeek’s is a claimed target with a storage-system story, Beam’s a window length with guides at 256K. Test your own long prompts before sizing a fleet around either.
- You need maximum ecosystem flexibility: Beam today (two open engines, 17+ hosted providers listed by SXZ.io, no-distillation-prohibition Apache 2.0). DeepInfer’s dual-vendor support (Ascend 950 alongside SM100) is distinctive and worth watching — DeepSeek says inference code for future models will land in the framework.
- You want to bet on openness of the architecture, not just the weights: DeepInfer’s Apache-2.0 release of a production serving core — kernels, schedulers, EPLB, Wide-EP — is arguably the more historically significant artifact, even incomplete. Its gaps are the roadmap to watch.
Sources, cited per claim rather than averaged. Data fetched 2026-10-23.
References and further reading
- DeepSeek-V4.1-Flash announcement — DeepSeek API docs, 2026-09-10
- DeepSeek-V4.1-Flash model card — Hugging Face (MIT)
- DeepSeek-V4.1-Flash-1017 checkpoint — Hugging Face, 2026-10-17
- HF Hub API file listing for V4.1-Flash — checkpoint size data
- DeepInfer repository — GitHub, Apache 2.0, last push 2026-10-21
- DeepInfer deployment Q&A — DeepSeek’s own deployment guidance
- vLLM: DeepSeek-V4.1-Flash on vLLM — 5× Agentic Throughput Since Day 0 — vLLM blog, 2026-10-07 (and the vLLM team’s X post with the within-6% decode-throughput claim)
- Reflection Beam launch post — Reflection AI, 2026-10-16
- vLLM: Serving Reflection Beam from Day 0 — vLLM blog, 2026-10-16
- SGLang — Beam cookbook included
- warmctl.io’s independent 8×B300 benchmark: DeepInfer vs vLLM — 2026-10-21, Kirill Bespalov
- InferenceX: DeepSeek-V4.1-Flash on H200 — SemiAnalysis measurements
- SXZ.io’s independent analysis of Beam’s 501B memory budget and 256K serving guides — 2026-10-18
Please let us know if you enjoyed this blog post. Share it with others to spread the knowledge! If you believe any images in this post infringe your copyright, please contact us promptly so we can remove them.