Run Reflection Beam Locally on Windows 11, Mac and Kali Linux: GGUF Sizes From 103 GB, llama.cpp b11701, the "ollama run beam" Cloud Catch, SageMaker JumpStart Costs and the $1/$3 API

Reflection Beam's weights went public on October 16, 2026: 501 billion parameters, 23.4 billion active per token, Apache 2.0, free to download from Hugging Face in BF16, FP8 and NVFP4. You can run Beam locally today with llama.cpp release b11701 or newer, which added the Beam architecture the same day, and Unsloth's GGUF files. The catch is size: the smallest file is 103 GB, the sensible one (UD-Q4_K_XL) is 307 GB, and both need that much memory, not just disk. So a 128 GB desktop with a graphics card can run the 1-bit build slowly, a 512 GB Mac Studio can run the 4-bit build properly, and an ordinary laptop cannot run it at all. Two more surprises: "ollama run beam" does not run Beam on your computer, because the only official Ollama tag is beam:cloud, which sends your prompts to Ollama's servers. And the cheapest AWS machine that serves Beam costs $55.04 an hour, so one day of it buys about 440 million output tokens on OpenRouter, where Beam costs $1 per million input tokens and $3 per million output. This page has every file size, the exact commands for Windows 11, Kali Linux and Mac, the AWS route, the API route, and the fixes for the errors people are hitting on day one.

Jake's computer shop had been waiting for this one. Ten days ago he read that an American lab was releasing a big open coding model and asked Ethan, his developer friend, whether the shop's workstation could run it. "When the weights are out," Ethan said. On Friday morning the weights were out, Jake typed ollama run beam, it answered instantly, and he was delighted for about four minutes, until he unplugged the network cable and it stopped. This page is what Ethan showed him next: what actually runs on a desk, what it costs to rent, and when the API is simply the better deal.

New to running models on your own machine? Our free plain-English series explains weights, quantization and VRAM in an hour, and our Beam explainer from launch week covers who Reflection is and what the model was built for. This page assumes you want it running.

What changed on October 16, and what you can download

When Beam was announced on October 5, you could read about it and join a waitlist, and that was all. On October 16 Reflection published the weights on Hugging Face under the Apache 2.0 license, which means you can download, run, modify and sell products built on it without asking anyone, the same terms as the most permissive open models. Alongside the weights came a small helper model for faster generation, recipes for fine-tuning, and day-one support in the tools that serve big models: Transformers, vLLM, SGLang, Unsloth, Axolotl, TokenSpeed and NVIDIA Dynamo. The same day, llama.cpp merged support for Beam's architecture, which is the piece that matters most if you want it on your own computer, and Unsloth uploaded GGUF files, the format llama.cpp, LM Studio and most desktop tools read.

Here is what is in the box. The numbers you will use most are the active parameters (they decide speed) and the file sizes (they decide whether it fits).

The official files are for data-center GPUs: FP8 for H100 and H200 cards, NVFP4 for NVIDIA's Blackwell generation (B200, B300). If you are running on a desk, ignore them and go straight to the GGUF files below. If you are renting cloud GPUs, the official files are the right ones, and the vLLM section has the exact command.

"So it's free," Jake said. "The model is free," Ethan said. "The memory to hold it is the expensive part."

Can your computer run Beam? The honest memory math

The single rule for running any big model locally: the whole file has to fit in memory, meaning your graphics card's VRAM plus your system RAM together, with a few gigabytes to spare for the context and the operating system. Disk space is not enough; a model that spills onto the SSD runs at a few words per minute, which is not "slow," it is unusable.

Beam has one big thing going for it: only 23.4 billion of its 501 billion parameters are used for each token. That means you do not need the whole model on the graphics card. The trick every guide uses for models like this is to put the shared layers and the context on the GPU and leave the experts (the bulk of the file) in system RAM, where the CPU reads only the 8 experts each token needs. That is what the --cpu-moe flag in the commands below does. It turns "impossible" into "possible but slow" on a desktop with lots of RAM.

Here are Unsloth's GGUF files, what each needs, and the fastest speed it could possibly reach on a typical desktop. The speed column is a ceiling, not a promise: it is your memory bandwidth divided by the bytes each token has to read, and real speed lands below it.

How the ceiling column is worked out, so you can redo it for your own machine: divide the file size by 501.3 billion to get bytes per parameter, multiply by the 23.4 billion active parameters, and you get what each token reads. For UD-Q4_K_XL that is about 14.3 GB per token; for UD-IQ1_S about 4.8 GB. Dual-channel DDR5-5600 moves 89.6 GB a second, so 89.6 ÷ 14.3 is about 6 tokens a second at best. Put the same file in a Mac's unified memory, which is several times faster than desktop RAM, and the ceiling rises in proportion. That is why the Mac is the comfortable desk machine for this model and the PC is the patient one.

What this means in plain terms:

• A normal laptop (16 to 64 GB): no. Not with any file. Use the API or Ollama's cloud tag.
• A desktop with 128 GB RAM and a 24 GB card: yes, the 1-bit UD-IQ1_S, for experiments. Expect single-digit speed in practice and noticeably weaker answers than the 4-bit build. One-bit files of giant models are surprisingly usable for chat and drafts and unreliable for long, exact coding work.
• A desktop with 256 GB RAM: the 2-bit and 3-bit files. Most consumer motherboards top out at 256 GB (four 64 GB sticks), so this is as far as a home PC goes.
• A 512 GB Mac Studio: the recommended UD-Q4_K_XL with plenty of room for context. This is the best single box for running Beam at home.
• Anything bigger: rent it. The AWS section has the prices.

If you are deciding what to buy for local AI in general, our honest hardware tiers page is the place to start; Beam sits at the very top of that ladder.

Run Beam on Windows 11 with llama.cpp

On Windows the dependable route is llama.cpp's own prebuilt download. There is nothing to compile. You need a build from release b11701 or newer, because older builds do not know the Beam architecture and refuse to load the file.

1. Check your memory first. Press Ctrl + Shift + Esc, open the Performance tab, click Memory, and read the total. You need about 128 GB for UD-IQ1_S. If you see 32 or 64 GB, stop here and jump to the API section; nothing below will work.
2. Check free disk space. The 1-bit file is 103 GB and arrives in several parts. Put it on your fastest NVMe drive with at least 120 GB free.
3. Download llama.cpp. Go to the llama.cpp releases on GitHub (github.com/ggml-org/llama.cpp/releases), pick b11701 or any later release, and download the Windows x64 zip that matches your card: the CUDA build for NVIDIA, the Vulkan build for AMD or Intel graphics, or the CPU build if you have no graphics card. With the CUDA build, also download the matching CUDA runtime zip from the same release and unzip both into one folder, for example C:\llama.
4. Tell llama.cpp where to store the model. By default it caches downloads on your C: drive. To use a bigger drive, open PowerShell and run setx LLAMA_CACHE "D:\models", then close and reopen PowerShell.
5. Start the server. In PowerShell, go to the folder and run the command below. The first run downloads the file, which takes a while on any connection.

cd C:\llama
.\llama-server.exe -hf unsloth/Beam-1.0-501B-A23B-GGUF:UD-IQ1_S `
  --cpu-moe -ngl 99 -c 32768 --jinja `
  --temp 0.7 --top-p 0.99 --host 127.0.0.1 --port 8080

What each part does, so you can change it with confidence:

• -hf unsloth/Beam-1.0-501B-A23B-GGUF:UD-IQ1_S downloads that file from Hugging Face and loads it. Swap UD-IQ1_S for any name in the memory table.
• --cpu-moe keeps the expert weights in system RAM. Without it, llama.cpp tries to push as much as it can onto the GPU, and on a 24 GB card that ends in an out-of-memory error.
• -ngl 99 puts every remaining layer on the GPU. With --cpu-moe that means attention and the shared layers, which is exactly what you want on the card.
• -c 32768 sets a 32K-token context. Beam supports a million, but every extra token of context costs memory. Start at 32K, raise it once everything works.
• --jinja uses the chat template inside the file, which is how the Beam-specific "Modified Harmony" format and tool calls are handled correctly.
• --temp 0.7 --top-p 0.99 are the sampling settings Unsloth's evaluations used.

When the log says the server is listening, open http://127.0.0.1:8080 in your browser. You get llama.cpp's own chat page, and any app that speaks the OpenAI API can use http://127.0.0.1:8080/v1 as its base URL. If you have a GPU with more VRAM, replace --cpu-moe with --n-cpu-moe 40 (keep the experts of 40 layers in RAM, move the rest to the GPU) and lower the number until you run out of VRAM. Every expert layer you move onto the card makes generation a little faster.

There is a second speed lever that arrived the day before Beam's weights. llama.cpp v0.7.0 added --moe-cache-mib, a GPU cache for experts that live in system RAM: the experts used most recently are kept on the graphics card, so many tokens never have to fetch them from RAM at all. The llama.cpp team reports up to about 2.2x faster generation when experts are offloaded, which is exactly Beam's situation on a PC. Add it next to --cpu-moe and give it most of the VRAM left over after loading, in megabytes, for example --moe-cache-mib 12000 on a 24 GB card. If the load fails with an out-of-memory error, lower the number. Every build from b11701 on includes it.

Ethan's advice to Jake was blunt: "Run it once, ask it something you already know the answer to, and time it. If you can wait for that answer every time, keep it. If you can't, that's the API's job."

Run Beam on Kali Linux (or any Debian-based Linux)

On Kali you build llama.cpp from source, which takes about ten minutes and gives you a binary tuned for your CPU. These commands install the build tools, clone the code, and build with CUDA for an NVIDIA card. For AMD or Intel graphics, replace -DGGML_CUDA=ON with -DGGML_VULKAN=ON and install the Vulkan development package; for CPU only, drop the flag.

sudo apt update
sudo apt install -y build-essential cmake git libcurl4-openssl-dev nvidia-cuda-toolkit
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DLLAMA_CURL=ON
cmake --build build --config Release -j$(nproc)
./build/bin/llama-server --version

The last line prints the build number; it must be 11701 or higher. If you cloned before October 16, run git pull and build again. Then start the server the same way as on Windows:

export LLAMA_CACHE=/mnt/models     # a drive with 120 GB+ free
./build/bin/llama-server -hf unsloth/Beam-1.0-501B-A23B-GGUF:UD-IQ1_S \
  --cpu-moe -ngl 99 -c 32768 --jinja \
  --temp 0.7 --top-p 0.99 --host 127.0.0.1 --port 8080

Two Linux-specific habits help with a model this size. First, check that your RAM is actually free with free -g before you start; a browser with forty tabs can be the difference between loading and failing. Second, if the load fails with a memory error even though the numbers add up, the kernel may be refusing to lock that much memory; add --no-mmap only if you have RAM to spare, and otherwise leave the default memory mapping alone, which lets the operating system page the file in as needed.

Kali users often run inside a virtual machine. A VM gets only the memory you assign it, and almost no hypervisor on a desktop hands a guest 128 GB. For Beam, run llama.cpp on the host system, or on bare-metal Kali, and connect to it from the VM over the network.

Run Beam on a Mac

Apple Silicon is the friendliest desk hardware for Beam, because the GPU uses the same unified memory as the rest of the system. A 512 GB Mac Studio holds the recommended UD-Q4_K_XL (307 GB) with more than 150 GB left for context and macOS. The llama.cpp Beam support passed its Metal tests when it merged, so the Mac route is the same llama.cpp route.

brew install llama.cpp          # or: brew upgrade llama.cpp
llama-server --version           # must report build 11701 or newer
llama-server -hf unsloth/Beam-1.0-501B-A23B-GGUF:UD-Q4_K_XL \
  -ngl 99 -c 65536 --jinja --temp 0.7 --top-p 0.99 --port 8080

No --cpu-moe here: on a Mac everything already lives in one pool of memory, so you put the whole model on the GPU. If Homebrew has not picked up build 11701 yet, download the macOS Apple Silicon zip from the llama.cpp releases page, which includes it from b11701 on.

By default macOS lets the GPU use only part of the unified memory. If the load stops with a Metal allocation error on a 512 GB machine, raise the limit for the current session with sudo sysctl iogpu.wired_limit_mb=480000 (480 GB for the GPU, the rest for macOS) and try again. The setting resets when you restart.

What about MLX, Apple's own framework, which is usually the fastest way to run models on a Mac? As of October 17 there is no MLX build of Beam on Hugging Face. Beam's attention design (per-head output gates, interleaved sliding windows) needs new code in any framework, and llama.cpp got there first. When an MLX version appears, it will be worth switching for the speed.

A Mac with 128 GB or 192 GB can load the 1-bit or 2-bit files on the same commands, swapping the file name. A Mac with 64 GB or less cannot run Beam in any form.

The Ollama and LM Studio catch

This is where most people's first evening with Beam goes sideways, so it gets its own section.

Ollama: "ollama run beam" is the cloud version

Beam is in the Ollama library, and the only tag is beam:cloud. The :cloud suffix means Ollama runs the model on its own servers and streams the answer back to the Ollama app on your computer. It feels local, because you type into the same terminal and the same app, but your prompts leave your machine, it stops working without internet, and it counts against your Ollama account's cloud usage. That is exactly what Jake ran into when he unplugged the cable.

ollama run beam:cloud      # hosted by Ollama, needs internet and a signed-in account

For a lot of people that is the right answer: it is the easiest way to try Beam, with no download, on any laptop. Just know what it is. If you are working on code or documents that must not leave your machine, the cloud tag is not local AI.

For a truly local copy, Ollama can pull GGUF files straight from Hugging Face:

ollama run hf.co/unsloth/Beam-1.0-501B-A23B-GGUF:UD-IQ1_S

That needs the same memory as the llama.cpp route, and it needs an Ollama version whose engine knows the Beam architecture. If Ollama answers with an "unknown model architecture" or "unsupported" error, your Ollama is older than the architecture; update it, and if the newest version still refuses, use llama.cpp directly for now. If it answers that the model "requires more system memory than is available," the file is bigger than your free RAM; our Ollama memory error guide explains what the numbers mean, but for Beam the honest fix is a smaller file or a bigger machine.

LM Studio

LM Studio can open Unsloth's Beam repository directly from its model search (search for "Beam-1.0-501B-A23B-GGUF"). LM Studio runs GGUF files on its own bundled llama.cpp engine, so it can load Beam only once its runtime includes the b11701 architecture support. If the load fails with a "failed to load model" message, open the runtime settings, update the llama.cpp runtime, and try again. Our LM Studio "failed to load model" guide covers the other causes. LM Studio's memory estimate before loading is useful here: if it shows the model in red, believe it.

"So the button that says Beam isn't Beam on my machine," Jake said. "It's Beam on theirs," said Ethan. "Which is fine, as long as you know whose machine it is."

Serving Beam properly: vLLM on four B300 GPUs

If you want Beam for a team, an app or a coding agent that many people use at once, a desktop is the wrong tool. The production setup is the official NVFP4 weights on four NVIDIA B300 GPUs connected by NVLink, on Linux, served with vLLM. That is the hardware the serving recipe is written for. First download the weights and the drafter:

export MODEL_DIR=/data/beam
hf download reflection/Beam-1.0-501B-A23B-NVFP4   --local-dir "$MODEL_DIR/nvfp4"
hf download reflection/Beam-1.0-501B-A23B-DFlash2 --local-dir "$MODEL_DIR/dflash2"

Then start vLLM from its Beam container image. This is the full command, every flag included:

docker pull vllm/vllm-openai:reflection-beam
docker run --rm --init --name beam \
  --gpus '"device=0,1,2,3"' --shm-size=32g \
  -p 127.0.0.1:8000:8000 \
  --mount "type=bind,src=$MODEL_DIR,dst=/weights,readonly" \
  -e HF_HUB_OFFLINE=1 -e TRANSFORMERS_OFFLINE=1 \
  --entrypoint vllm vllm/vllm-openai:reflection-beam \
  serve /weights/nvfp4 \
  --host 0.0.0.0 --port 8000 \
  --served-model-name Beam-1.0-501B-A23B \
  --tensor-parallel-size 4 \
  --dtype bfloat16 \
  --max-model-len 262144 --max-num-seqs 8 \
  --gpu-memory-utilization 0.95 \
  --enable-prefix-caching \
  --enable-auto-tool-choice \
  --tool-call-parser beam --reasoning-parser beam \
  --default-chat-template-kwargs '{"allow_missing_thinking": false}' \
  --speculative-config '{"method":"dflash","model":"/weights/dflash2","num_speculative_tokens":8}'

Three flags deserve a word. --tool-call-parser beam and --reasoning-parser beam teach vLLM Beam's chat format, so tool calls come back as proper tool calls and the model's thinking comes back separately from its answer; leave them out and agents break in confusing ways. --max-model-len 262144 serves a 256K context rather than the full million, a sensible trade of context for capacity on four cards. And --speculative-config switches on the DFlash2 drafter, a 1.93-billion-parameter helper that guesses several tokens ahead while Beam checks them. Reflection reports a 2.3x to 3.0x speedup for a single user with greedy decoding (for example 288 to 874 tokens a second on a math benchmark), with smaller gains when many requests share the server.

Check it is up with two requests:

curl --fail-with-body http://127.0.0.1:8000/v1/models
curl --fail-with-body http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model": "Beam-1.0-501B-A23B", "messages": [{"role": "user", "content": "Explain tensor parallelism briefly."}], "max_tokens": 2048}'

On H100 or H200 cards, use the FP8 weights instead (reflection/Beam-1.0-501B-A23B-FP8, 468.72 GiB), which need eight cards rather than four. SGLang and TokenSpeed have equivalent recipes if your team already runs one of those.

Beam on AWS: SageMaker JumpStart and the real hourly cost

Beam arrived on AWS the same day as the weights. It is in Amazon SageMaker JumpStart in two Regions, US East (N. Virginia) and US East (Ohio), and AWS also announced it for its Trainium chips. It is not on Amazon Bedrock, so there is no pay-per-token AWS option yet: on AWS you rent the whole machine by the hour. If SageMaker is new to you, our plain-English SageMaker guide explains endpoints, and our Bedrock vs SageMaker page explains why the two charge so differently.

These are the machines Beam runs on in SageMaker, with the on-demand EC2 rate for the same instance in US East (N. Virginia). A SageMaker endpoint charges its own rate for the ml. version of each instance, which runs above the EC2 figure, so treat this column as the floor:

Here is the number that decides most people's plans. One day of the cheapest machine, $1,320.96, buys about 440 million output tokens on OpenRouter at $3 per million. A busy developer using a coding agent all day burns a few million. Renting your own Beam on AWS makes sense when you have a team keeping the endpoint busy, data that is not allowed to leave your AWS account, or a need to fine-tune. For one person, it is the most expensive way to use the model by a long way.

If you do want the endpoint, the quickest path is AWS's sample repository, which deploys Beam through JumpStart with one script:

1. Request the GPU quota first. New AWS accounts have a quota of zero for p5 endpoints. In the Service Quotas console, under Amazon SageMaker, request "ml.p5.48xlarge for endpoint usage" in us-east-1. Without this you get a ResourceLimitExceeded error at deploy time; our ResourceLimitExceeded guide walks through the request.
2. Clone the samples and go to the Beam folder.
3. Deploy the FP8 variant to a real-time endpoint and give it a name you will recognize on the bill.
4. Delete the endpoint the moment you finish testing. An idle endpoint bills exactly like a busy one.

git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git
cd sagemaker-genai-hosting-examples/01-models/ReflectionAI/Beam-1.0-501B-A23B-NVFP4/
python jumpstart_real_time.py --variant fp8 --endpoint-name reflection-beam-fp8-smoke

# when you are done, from any machine with the AWS CLI:
aws sagemaker delete-endpoint --endpoint-name reflection-beam-fp8-smoke --region us-east-1

The same folder has HyperPod scripts for teams running a SageMaker HyperPod cluster, including an option to serve with SGLang or vLLM instead of the JumpStart container. Google Cloud also offers Beam from day one, and Azure and Oracle are listed as coming soon.

Jake did the multiplication on the back of a parts invoice and slid it across the counter. "Thirteen hundred dollars a day." Ethan nodded. "For a team of fifty, that's cheap. For you, it's a new laptop every afternoon."

The cheap way: Beam through an API

For most readers, this is the section that ends up mattering. Two APIs serve Beam today, and both speak the OpenAI format, so any app or library that works with OpenAI works with Beam after you change two settings.

To use Reflection's own API, create a key at platform.reflection.ai under API Keys, save it as an environment variable, and call it with the OpenAI Python library:

pip install openai

# Windows PowerShell:  setx REFLECTION_API_KEY "your-key"
# macOS / Kali:        export REFLECTION_API_KEY="your-key"

import os
from openai import OpenAI

client = OpenAI(base_url="https://api.reflection.ai/openai/v1",
                api_key=os.environ["REFLECTION_API_KEY"])

r = client.chat.completions.create(
    model="Beam-1.0-501B-A23B",
    messages=[{"role": "user", "content": "Write a PowerShell one-liner that lists the 10 largest files in C:\\Users."}],
    reasoning_effort="medium",
)
print(r.choices[0].message.content)

Beam is a reasoning model: it thinks before it answers, and the thinking comes back in a separate reasoning_content field next to the answer. reasoning_effort controls how long it thinks, with five settings, low, medium, high, xhigh and max; leave it out to get your account's default. Higher effort means better answers on hard problems and more output tokens on the bill. Beam's selling point, by Reflection's account, is that it reaches the quality of leading open models with about a third of the reasoning tokens, which is why its $3 output price goes further than the number suggests.

For OpenRouter, the same code works with base_url="https://openrouter.ai/api/v1", an OpenRouter key, and model="reflection/beam-1.0-501b-a23b". The OpenRouter route is the one to pick if you already pay OpenRouter for other models, or if the free beta's limits get in your way.

And the same code works against your own llama.cpp server from the Windows or Mac sections: set base_url="http://127.0.0.1:8080/v1" and any string as the key. That is the real value of the OpenAI format: build your tool against the API this week, move it to your own hardware later without changing a line of logic.

Using Beam as a coding agent

Beam was built for agent work: reading a codebase, calling tools, running tests, fixing what fails. There are two ways to put it to work.

Mirror, Reflection's own coding agent

Mirror is a terminal coding agent built around Beam, installed with uv:

uv tool install reflection-mirror
export REFLECTION_API_KEY="your-key"
cd your-project
mirror

Mirror runs on macOS 15 or newer on Apple Silicon and on Linux with glibc 2.28 or newer (Kali qualifies). Native Windows is not supported. On Windows 11, install it inside WSL (Windows Subsystem for Linux) with an Ubuntu distribution, and it behaves as on Linux. The key is saved to ~/.mirror/reflection_api_key after the first run.

OpenCode and other agents

Agents that accept an OpenAI-compatible provider can use Beam too: OpenCode, Pi and Hermes Agent all work with a custom provider pointed at https://api.reflection.ai/openai/v1 and the model Beam-1.0-501B-A23B. Our OpenCode install guide shows where the custom-provider settings go. For a local setup, point the same provider at your llama.cpp server's /v1 address instead; tool calling works because llama.cpp's Beam support includes a parser for Beam's tool-call format, as long as you started the server with --jinja.

One honest warning for local agent use: agents send long prompts (the whole file, the tool list, the conversation) over and over. At desk speeds, prompt processing on a 1-bit Beam can take minutes per step. For agent work the API or a rented server is the practical choice; the desk copy is for chat, drafting and private documents.

What the numbers say now that the weights are out

With the weights, Reflection published scores for the full-precision model. These are Reflection's numbers, not independent results yet:

Two things to keep in mind when you read them. First, these are full-precision scores. The 1-bit and 2-bit files that fit on a desk lose some of that quality; the 4-bit UD-Q4_K_XL stays close, which is why it is the recommended file. Second, at launch Beam trailed Kimi K3, GLM-5.3 and DeepSeek V4.1 Flash on most of the coding tests where they shared a score, and its pitch was efficiency rather than the top spot. Nothing in the new numbers changes that picture: Beam is a strong, efficient, permissively licensed model, not the strongest open model. If you want to compare the alternatives that fit similar hardware, our GLM-5.3 local guide and our Kimi K3 page answer the same questions for those models.

What does set Beam apart is the license and the origin. Apache 2.0 with no usage restrictions, from a US lab, matters to companies whose legal teams will not approve models with custom licenses or from certain countries. For them, Beam may be the strongest model they are allowed to run, and that is a real reason to choose it.

Beam errors and fixes

These are the problems that come up on the first day, with the fix for each.

"unknown model architecture: 'beam'"

Your llama.cpp (or the llama.cpp inside LM Studio or Ollama) is older than release b11701. Download a newer release, or git pull and rebuild on Linux, then check with llama-server --version. This is the most common error on day one, because package managers and bundled runtimes lag the main project by days.

Out of memory, "failed to allocate" or the PC freezes while loading

The file plus context is bigger than your free memory. In order: make sure --cpu-moe is in the command, lower the context with -c 16384, close other programs, then move down one row in the memory table. If Windows starts swapping to disk (the drive light stays on, everything freezes), end the process from Task Manager; it will not recover by waiting.

It loads but runs at one word every few seconds

Part of the model is being read from disk instead of RAM, usually because the file is too close to your total memory. Check RAM use while it runs: if it sits at 100% and the disk is busy, choose a smaller file. Also check that the GPU is actually in use (Task Manager > Performance > GPU on Windows, nvidia-smi on Kali); if it shows no load, you downloaded the CPU build of llama.cpp by mistake.

The download stops or the file will not load after a broken download

Big GGUFs come in several parts, and a part interrupted halfway leaves a broken file. Delete the partial files from your LLAMA_CACHE folder (or the default cache) and run the command again; it resumes cleanly from a clean folder. On a slow connection, download the parts first with hf download unsloth/Beam-1.0-501B-A23B-GGUF --include "*UD-IQ1_S*" --local-dir D:\models\beam and then point -m at the first part.

Tool calls come back as plain text, or the thinking leaks into the answer

The server is not using Beam's chat template. Start llama.cpp with --jinja; on vLLM, include both --tool-call-parser beam and --reasoning-parser beam. A generic OpenAI chat template does not understand Beam's format.

"ollama run beam" works but nothing is downloaded

That is the cloud tag doing its job. See the Ollama section for the local alternative and what it needs.

Mirror will not install on Windows

Mirror does not support native Windows. Install WSL with wsl --install -d Ubuntu in an administrator PowerShell, restart, then install uv and Mirror inside Ubuntu.

SageMaker deploy fails with ResourceLimitExceeded

Your account's quota for the GPU endpoint instance is zero or too low. Request an increase for the exact instance type ("ml.p5.48xlarge for endpoint usage") in the Region you deploy to, and wait for approval before you try again.

Frequently asked questions

Jake did not buy a 512 GB Mac Studio. He kept beam:cloud for quick questions, set up the OpenRouter key for the quoting tool Ethan was building him, and put the 1-bit file on the workstation for the one job where privacy mattered: summarizing customer repair notes that never leave the shop. It answered slowly, and it answered well enough. "So I'm running it locally," Jake said. "For the part that has to be local," said Ethan. "That's the only part that ever needed to be."

Revision note. Written October 17, 2026, the day after Beam's weights went public. "Cut your coat according to your cloth," the proverb says; with a model this size, the cloth is your memory.