live wire
▸AI · EAGLE-4 0.1.4 fixes multi-GPU vLLM collective ordering during startupEAGLE-4▸SECURITY: Apache Camel 4.23.0, 4.22.2 and 4.18.5 fix eight component vulnerabilitiesApache Camel▸AI · Red Hat shows DRA doubles llm-d KV-cache throughput by aligning GPUs and RDMA NICsRed Hat Developer▸Red Hat Developer Hub 1.9.10 ships as a Critical security updateRed Hat errata▸OpenShift Dev Spaces 3.31 adds live editor switching and DevWorkspace Operator 1.0Red Hat documentation▸OpenShift Pipelines 1.24.1 tightens Manual Approval Gate RBAC and approval integrityRed Hat release notes▸AI · Red Hat survey: 97% of UK CIOs trust agent security, but 43% can trace data flowsRed Hat▸JAVA · IBM and Kaggle launch a living benchmark for agentic Java framework migrationsIBM Research▸AI · Red Hat tests policy-derived data controls for AI agentsRed Hat▸Apache Camel pattern turns routes into bounded LLM tools and MCP servicesRed Hat Developer▸Atos tunes small models on OpenShift AI for structured German-language analysisRed Hat Developer▸Red Hat publishes checklist for evaluating third-party OpenShift applicationsRed Hat Developer▸SECURITY · OpenShift 4.21.40 patches OpenSSL, OpenSSH and PCRE2 flawsRed Hat Product Security▸SECURITY · Apache Camel fixes A2A webhook SSRF gap in 4.22.2 and 4.23.0 (Oct. 23)Apache Camel▸AI · EAGLE-4 0.1.4 fixes multi-GPU vLLM collective ordering during startupEAGLE-4▸SECURITY: Apache Camel 4.23.0, 4.22.2 and 4.18.5 fix eight component vulnerabilitiesApache Camel▸AI · Red Hat shows DRA doubles llm-d KV-cache throughput by aligning GPUs and RDMA NICsRed Hat Developer▸Red Hat Developer Hub 1.9.10 ships as a Critical security updateRed Hat errata▸OpenShift Dev Spaces 3.31 adds live editor switching and DevWorkspace Operator 1.0Red Hat documentation▸OpenShift Pipelines 1.24.1 tightens Manual Approval Gate RBAC and approval integrityRed Hat release notes▸AI · Red Hat survey: 97% of UK CIOs trust agent security, but 43% can trace data flowsRed Hat▸JAVA · IBM and Kaggle launch a living benchmark for agentic Java framework migrationsIBM Research▸AI · Red Hat tests policy-derived data controls for AI agentsRed Hat▸Apache Camel pattern turns routes into bounded LLM tools and MCP servicesRed Hat Developer▸Atos tunes small models on OpenShift AI for structured German-language analysisRed Hat Developer▸Red Hat publishes checklist for evaluating third-party OpenShift applicationsRed Hat Developer▸SECURITY · OpenShift 4.21.40 patches OpenSSL, OpenSSH and PCRE2 flawsRed Hat Product Security▸SECURITY · Apache Camel fixes A2A webhook SSRF gap in 4.22.2 and 4.23.0 (Oct. 23)Apache Camel
upstreambeat.ai
guideAI

vLLM’s Beam recipe exposes the hardware and serving trade-offs behind a 501B MoE

The deployment guide fits Reflection Beam on four Blackwell or eight Hopper GPUs, but relies on an unreleased vLLM build and CUDA-only kernels.

By The News Desk· Oct 20, 2026the quick take — two AI hosts go live when you do

Reflection AI’s Beam is a 501-billion-parameter mixture-of-experts model, but only 23 billion parameters are active for each token. A new vLLM Recipes deployment guide turns that architecture into concrete serving choices across NVIDIA Hopper and Blackwell systems.

What the recipe makes deployable

The guide covers three checkpoints: a 294 GB NVFP4 variant, a 503 GB FP8 variant and a 1,003 GB BF16 variant. vLLM recommends the NVFP4 checkpoint on four B200 or B300 GPUs, or eight H100s; FP8 targets eight H200s; BF16 needs eight B200 or B300 GPUs. The model combines sliding-window and full-attention layers, supports a 1,048,576-token context window, and uses Harmony-format reasoning and tool calls.

For Blackwell, the default NVFP4 command uses tensor parallelism across four GPUs. The guide says that layout consumes about 73 GB of weights per GPU, leaving enough capacity for long contexts and allowing two replicas on an eight-GPU node. On H100, the same checkpoint uses eight GPUs and explicitly selects the Marlin MoE backend because the recipe’s measurements found it faster than vLLM’s default choice.

The important boundary

Beam support has not shipped in a regular vLLM release. The recipe requires the project’s vllm/vllm-openai:reflection-beam image and says Beam’s kernels, including its expert-parallel custom all-reduce, are CUDA-only. Teams should treat the recipe as an ahead-of-release integration path rather than evidence of portable, generally released support.

The first Blackwell start can also take about 10 minutes while FlashInfer autotunes its MoE kernel. That sits close to vLLM’s default 600-second engine-ready timeout, so the generated Docker command raises the timeout to 3,600 seconds.

How to choose a serving layout

For a straightforward single-node deployment, the guide recommends tensor parallelism. For prefill-heavy traffic at high concurrency, it documents data-parallel attention with expert parallelism and FlashInfer’s CuTe DSL NVFP4 MegaMoE kernel. That path is limited to Blackwell and does not support tensor-plus-expert parallelism.

The optional DFlash2 speculative drafter is aimed at higher-throughput decoding under load. It adds about 1.7 GB per GPU, can propose up to 15 tokens and defaults to seven in the recipe. vLLM cautions that acceptance depends on natural-language input, so operators should benchmark with representative text rather than random-token datasets.

The practical takeaway is not merely that Beam fits. The recipe identifies which quantization, backend and parallelism choices make it fit—and where the current integration remains experimental.

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.