Benchmarks
How fast can Beam start containers, microVMs, mount images and read files?
Results
TTI (time to interactive) in seconds, lower is better
- ComputeSDK's benchmark, 100 at once0.55smedian
- Beam's harness, 100 at once0.68sp95 0.90s
TTI, or time to interactive, runs from the create call until the new sandbox's first command has answered. First row: the median in ComputeSDK's weekly burst benchmark, which ComputeSDK runs across providers. Second row: Beam's own harness, which also checks the command's output. Production, June 26, 2026: 100 sandboxes launched at once (debian:bookworm-slim, 0.1 CPU, 192 MB) after a warm-up burst, so the machines already had the image mounted, and all 100 answered. Beam's client ran outside the region, so the figure includes the trip to the gateway. ComputeSDK's results
Inside a start
Milliseconds at the median, lower is better
- Mount the image5 msp95 8 ms
- Set up mounts and the overlay2 msp95 6 ms
- Set up the network7 msp95 10 ms
- Start the first process5 msp95 9 ms
- The sandbox's process manager answers49 msp95 84 ms
Production, June 26, 2026: the 100 sandboxes of Beam's row above, timed by the platform's own spans, so the client's location doesn't enter into it. From the gateway accepting a request to its container running took 300 ms at the median and 472 ms at p95. Most of what the bars leave out is time spent queued, in the scheduler's batch and on the worker. In a burst with no warm-up, where some machines mounted the image fresh, the mount's p95 was 143 ms.
Placements per second as load grows, higher is better
- Up to 1,000 sandboxes running1047/s
- Up to 10,000 sandboxes running1015/s
Beam's staging cluster, October 11, 2026, one run. It starts sandboxes on workers that take every request through the control plane and skip starting the container, so a figure is the scheduler's own rate. Sandboxes were added in bursts, to 1,000, 2,000, 5,000, 8,000 and 10,000 running, and each level was held before the next. A row is the rate of the burst that reached its level: 1,000 placements for the first row and 2,000 for the second. The three bursts between them placed 1573, 1505 and 1527 a second. Every create succeeded, 10,000 of 10,000, and no request was left waiting. Ten real sandboxes were started on the cluster's own machines at each level, to show what that load does to a start: they took 0.51s at the median with 1,000 running and 0.50s with 10,000, against 0.50s for 30 starts before the run. The gateway was a single replica running a build with scheduler changes that have not been released, and the control plane's Redis was one small node.
Seconds until a new container's first command answers, lower is better
- 50 MB image, docker pull and run~2.8s
- 50 MB image on Beam~0.6snew machine
- 3.3 GB image, docker pull and run~21s
- 3.3 GB image on Beam~2.0snew machine
- 9.7 GB image, docker pull and run~90s
- 9.7 GB image on Beam~3.7snew machine
A pull downloads and unpacks every layer of an image onto a machine before its first container can start, so the wait grows with the image, and every machine that hasn't run the image waits again. Beam indexes an image once into CLIP, its image format. A worker fetches that index and mounts it through FUSE, and the container starts. The image's bytes arrive while it runs: from the worker's own disk, from the cache the workers serve to each other, or from the registry. Production, October 11, 2026, with three public images named by the compressed size a pull downloads: python:3.11-slim (50 MB), PyTorch 2.15 with CUDA (3.3 GB) and vLLM 0.33 (9.7 GB). Gray rows: docker pull and then docker run of one command, inside a new Beam microVM (4 CPUs, 16 GiB) whose Docker store was empty, timed from the start of the pull until the command's output was read back. Each is the median of its pulls: two of the 50 MB image, three of the 3.3 GB one and two of the 9.7 GB one (82s and 97s). Pulled, the 9.7 GB image took 35 GB of disk, so its pulls ran in VMs with a 100 GiB disk. Beam rows: one sandbox (2 CPUs) created from the same image on a machine that didn't have it mounted, and that was missing the two large images' layers, timed from the create call until its first command's output was read back. That is one start per image. On a machine that had the image mounted, it took 0.35s for the 3.3 GB image (median of 10 starts) and 0.33s for the 9.7 GB one (5 starts). Beam had indexed each image once beforehand, which took 74s for the 3.3 GB image. The client was a laptop outside the cluster. CLIP, the image format
Until a program has imported its library
Seconds until PyTorch or vLLM is imported, lower is better
- 3.3 GB, docker pull, then the import~22s
- 3.3 GB on Beam, new machine~37s
- 3.3 GB on Beam, mounted before~2.7s
- 9.7 GB, docker pull, then the import~93s
- 9.7 GB on Beam, new machine~61s
- 9.7 GB on Beam, mounted before~6.1s
The same starts in production on October 11, 2026, timed until a program had imported the image's library: import torch in the 3.3 GB image, import vllm in the 9.7 GB one. Mounting an image moves its cost from the start to the first read, so these are the rows for a program that needs most of a large image at once. On a machine new to the image the worker fetched the layers from the registry while the container ran, in 30s and 49s, and the import waited for them. That took longer than the pull for the 3.3 GB image and less for the 9.7 GB one. Started as a microVM on the machine that had run the pulls, the 3.3 GB image finished its import at 31s. The rows for a machine that had the image mounted are the median of 10 starts and of 5. With the image already pulled, docker run reached the same point in 2.2s for the 3.3 GB image, and in 4.4s and 7.9s for the 9.7 GB one. No machine in these runs found an image's layers in another worker's cache. In a burst on June 17, 2026, three workers new to a 265 MB image did: 100 sandboxes answered in 1.31s at the median, having read at least 14.9 MB of the image, 9.9 MB of it through that cache.
Seconds until the image can start a container, lower is better
- Cold build, one small Python package3.8s5 builds
- Cold build, PyTorch (CPU wheel)11.7s5 builds
- Rebuild of an unchanged recipe0.007s10 rebuilds
Beam's staging cluster, October 11, 2026, one run. A build starts from Beam's base image with Python 3.11 and installs a recipe's packages through the SDK's Image.build(), timed from the build request until the image can start a container. First row: the requests package. Second row: PyTorch 2.6 as its CPU wheel, a 170 MiB download. A cold build changes one command ahead of the install each time, so that no earlier build is reused, and each cold row is the median of five builds. The first build of each recipe was the slowest: 21.9s for the small one, whose build worker pulled the base image first, and 18.0s for PyTorch, which downloaded the wheel. The four builds after it reused the base image's layers and the packages already downloaded, and took 3.5s to 4.2s and 11.5s to 14.3s. In those four PyTorch builds the install took 4s, and publishing what it added to the image, 248 MiB in three layers, took 6.1s to 8.7s. A rebuild sends a recipe that is already built, and Beam finds the image and answers without building it again. Each of the ten builds was rebuilt once: 7 ms at the median and 32 ms at the most. The client was a machine in the cluster's region, so little of any figure is the trip to the gateway.
Megabytes per second read, higher is better
- 10 GiB file through FUSE, in memory4.1 GB/s99% of host
- 10 GiB file, from another worker1,386 MB/s95% of link
Beam's staging cluster, October 11, 2026: one read per row of a 10 GiB file on a Volume, with nothing read from object storage. First row: a sandbox with 4 CPUs and 8 GiB reading the file with dd through the Volume's FUSE mount, after an earlier read had left it in the machine's cache and in memory. The worker itself, the host in that row's note, read it through the same mount at 4,133 MB/s, and across 36 runs between May 27 and June 3 the sandbox's median was 4,107 MB/s. Second row: a worker reading the file from another machine's cache over four connections, with the contents checked by SHA-256, while the link between the two machines carried 1,455 MB/s. Over two connections that read ran at 938 MB/s at the median of 20 runs, about three quarters of the link.
A 4 GiB file and the link itself
Megabytes per second, higher is better
- 4 GiB file through FUSE1,374 MB/s87% of host
- 4 GiB file, from another worker1,345 MB/s93% of link
- The network link itself1,455 MB/s
The same run on Beam's staging cluster, May 31, 2026, with a 4 GiB file. In the sandbox it read at 1,374 MB/s against the worker's 1,585, and across 24 runs at anything from 463 to 4,308 MB/s, depending on how much of the file was still in memory rather than on the cache's disk. The gray row is what the network carried between the same two machines in the same run, with no cache in the path. A second run that day reached 92% of the link with the 1 GiB file and 93% with the 4 GiB one.
Seconds until the VM answers, lower is better
- New VM from a cached image0.53sp95 0.89s
- Resume a paused VM, RAM intact0.71sp95 1.16s
- Wake a paused VM with an HTTP request1.22sp95 1.38s
Production, October 11, 2026: 30 VMs, one at a time, each created with the CLI's defaults (Ubuntu 24.04 with a desktop, 4 CPUs, 8 GiB), then paused, resumed, paused again, woken by an HTTP request and deleted. A new or resumed VM counts as started when the gateway has checked that it takes commands, which is the time the CLI prints as VM ready. Its first command's output was read back at 0.80s for a new VM and 1.04s for a resumed one, at the median, and the resumed VM's command read a value written to memory before the pause. The wake is one GET on a new connection to a server that was running before the pause, timed until its body was read back. The client was a laptop outside the cluster, about 30 ms from the gateway.
How Beam works
Beam is built around an open source control plane which aggregates and networks machines from many places: Kubernetes clusters, bare metal servers rented from cloud and GPU providers, and machines you bring yourself. Every machine runs the same worker, which carries the runtime, the mounts and the cache that the benchmarks above measure.
Control plane. Turns each call into a container request and places it on a worker with room for it, using the free CPU, memory and GPUs that workers have already reported.
Pools. A pool is a set of machines with the same hardware configuration, such as CPU-only, RTX 4090 or H100. A machine outside the cluster joins by running an agent, and its worker's token reaches only the worker API. A private pool runs only your workspace.
Worker. Each machine runs a worker binary, which starts your code in a microVM or a container on mounts fed by an embedded cache, with object storage and OCI registries behind the cache.
Storage. Object storage and OCI registries are the source of truth for images, volumes and disk layers. A distributed cache and custom FUSE filesystem make that data available to user containers or microVMs.
Why it's fast
- Placing container and microVM requests does not wait on a cloud API. Our scheduler and control plane are optimized for fast, bursty requests. Workers report their free capacity to the control plane, and the scheduler is able to place a whole batch of requests at once.
- An image is mounted, not pulled. A pull downloads and unpacks a whole image before anything starts, on every machine that is new to it. Beam indexes each image once into CLIP, its own image format. A worker mounts that index through FUSE and the container starts. The image's bytes arrive while it runs, from the nearest copy, so a first command answers in seconds (or less) whatever the image's size.
- Data comes from the nearest copy. Every worker serves a content-addressed cache from its own disk. A read is served from the machine's own disk, then from another worker's cache, and from object storage only when neither has it. Images, volumes and disk layers all take that path, at any provider.
- Reads skip the copies. An image never changes, so its mount answers a read with a file descriptor into the cache, which the kernel splices from directly. A worker serving another machine hands pages to the socket with sendfile.
- A microVM boots from the same mounts as a container. A Cloud Hypervisor guest reaches the host's image mount over virtio-fs instead of copying it into a disk, its disks are copy-on-write layers (using QCOW2), and a paused VM resumes from its saved memory instead of booting from a disk.
- A snapshot skips the boot and restores on any compatible machine. A sandbox or endpoint started from a memory snapshot begins with its processes already running. Snapshots are kept in object storage, so one restores on any worker with the same CPU features and GPU model, not only the machine that took it.
How we measure
- The timer covers what a user waits for. It starts when the client sends the request and stops when the result has been read back and checked. A sandbox counts as started when its first command's output matches, not when the API reports it running. That is its time to interactive. A VM counts as started when the gateway has checked that it takes commands, which is the time the CLI prints as VM ready.
- The p95 is beside each bar where there are enough samples for one.
- Volume reads A cached volume read counts as a cache read only when the file's contents have been checked by hash and nothing was read from object storage during it.
- Other providers' numbers aren't ours to publish. ComputeSDK runs one sandbox benchmark across providers every week and publishes all of the results.
Pay as you go
billed by the second
Time it yourself
Sign up, install the CLI, and start a sandbox or a VM from your terminal or your coding agent.