What Speed Looks Like on a Pile of Old Computers
RAMDeck benchmark results from a lab built out of hardware most people would call spare parts.
People keep asking for tokens per second, so here are all of ours. Every test ran on modest or old hardware on purpose. We chose weak machines to show what RAMDeck can do and that it scales, not to set a speed record. If raw speed is your goal, buy a GPU. If you want to run models that don’t fit on any machine you own, keep reading.
The Test Bench
| Device | Specs |
|---|---|
| Mac mini | Apple M4, 16GB |
| MacBook | Apple M3, 16GB |
| MacBook (Intel) | 2017 model, 12GB |
| Acer laptop | 2019 model, 12GB, spinning HDD, no GPU |
| Mini PC | Beelink SER5 Max, 32GB RAM, RTX 3060 with 12GB VRAM |
| Phone | Samsung Galaxy S24+ |
Each test used a subset of these devices. The Acer laptop was the primary node in most runs, which means the weakest machine we own carried the model.
The Results
| Model | Type | Devices | Speed |
|---|---|---|---|
| Qwen2.5-Coder 7B | Dense | Acer primary, mini PC GPU doing the work, Mac coding from another room | 43-44 tok/s (Watch) |
| Qwen3.5 13B | Dense | Acer, mini PC, Mac mini | 11-14 tok/s, reaching 19 after sharding improvements (Watch) |
| Qwen3.5 13B plus phone | Dense | Same three plus the S24+ on Wi-Fi | 14 down to 11 tok/s (Watch) |
| Qwen3.8 27B | Dense | Acer, mini PC, Mac mini, phone | 1.92 tok/s (Watch) |
| Qwen3-Coder-Next REAP 40B (25+ GB) | MoE | Mini PC as primary, Mac mini, Acer | 16 tok/s, 3.6s latency, 2.5 minute load (Watch) |
| gpt-oss 120B (60+GB) | MoE | All six in the cluster, five holding layers | 1.37 tok/s (Watch) |
Why Dense Matters
A dense model activates all of its parameters for every token, while a mixture-of-experts (MoE) model routes each token through a small subset of experts. Three of our runs used dense models: the 7B, the 13B and the 27B.
The 27B is the hard case. Qwen3.8-27B is dense, so all 27 billion parameters take part in every token. A 12GB Acer laptop from 2019 can’t hold its roughly 16GB alone. With that laptop as primary, the model sat fully in pooled RAM across four devices and ran at 1.92 tok/s.
That is the difference between pooled RAM and SSD swap. Watch the Acer laptop pull off the 27B Dense run here. SSD offloading works best on MoE models, because only a small share of experts is needed per token. A dense model has no such shortcut. Stream 16GB of weights from a disk for every token and even a fast NVMe drive spends seconds per token before any computing happens. (That last figure is our own back-of-envelope estimate, not a measurement.)
The MoE Runs
The two biggest runs used sparse models, and we say so. The REAP 40B has 40B total parameters and 3B active per token. At roughly 25GB, none of our devices could hold it alone. With the RTX 3060 mini PC as primary, it loaded across the network in about two and a half minutes and ran at 16 tok/s (Watch Video).
gpt-oss-120b has about 117B total parameters and 5.1B active. Six devices joined the cluster: the Acer, Mac mini M4, MacBook M3, the 2017 Intel MacBook, the SER5 Max and the S24+. The model fit across five of them, so the 2017 MacBook sat in the cluster without receiving any layers. RAMDeck used only what the model needed. The run came in at 1.37 tok/s.
The Stress Test: 40 Hours of Chaos
Running a 120B model for two minutes is a party trick. Running it for two days across a house on consumer Wi-Fi is an engineering problem. Laptops close their lids, phones go to sleep, and Windows forces unexpected updates.
To test RAMDeck’s orchestration, we left the gpt-oss-120b model running continuously on the 6-node cluster for over 40 hours. Here is what happened:
- Phone went offline: Overnight the phone dropped its connection (because it is a phone and it kills background tasks) but the node survived untouched. This was because the phone was not carrying much of overall weight of the model (~2% of the total model size was on the phone). Watch the overnight survival update here.
- The Ghost Node: At one point, the MacBook M3 closed its lid and went into macOS “Dark Wake” mode. Its Python control agent went to sleep, causing it to drop completely off the RAMDeck dashboard. But the C++ data plane kept the TCP socket alive. The cluster didn’t panic or crash—it just kept generating tokens by streaming tensors directly into the sleeping Mac’s Metal RAM. Watch the cluster survive as the network shrinks.
- The Autonomous Heal: When that Mac eventually severed the connection completely hours later, the primary engine crashed. Instead of requiring human intervention, the RAMDeck coordinator instantly detected the failure, pruned the offline Mac from the topology, swept the entire network for zombie ports, and seamlessly respawned the model using the remaining healthy nodes.
- The Power Cut: Our primary node (the Windows Mini PC) suffered an abrupt hardware power cut at 8:11 AM due to a maintenance cycle. When power was restored 40 minutes later, the RAMDeck service booted automatically, discovered the network cluster, re-established handshakes, and began rebuilding the 60GB tensor graph over Wi-Fi.
Zero command lines. Zero manual restarts. The cluster simply refused to die. When you pool consumer hardware, failure isn’t a possibility—it’s a guarantee. RAMDeck is built under the assumption that your devices will betray you, and it handles it gracefully.
How to Read These Numbers
Two things move the numbers most. The primary node matters: put your strongest machine in that seat and speeds climb. And wired Ethernet beats Wi-Fi, mostly because of latency, not bandwidth.
You can see this exact tradeoff in the 13B model results. When we added the Galaxy S24+ phone over Wi-Fi, the speed dropped from 14-19 tok/s down to 11 tok/s. Why? Because introducing a Wi-Fi node adds network latency to the tensor pipeline. If the model already fits in your wired cluster, adding a phone will slow it down. But if the model doesn’t fit, that phone’s 1.6GB of pooled RAM is what saves the run from crashing (check this video). You are explicitly trading pure speed for raw capacity.
A GPU workstation will always be faster, but that misses the point entirely. RAMDeck is the difference between 0 tokens per second (a fatal Out-of-Memory crash) and 1.9 tokens per second. It takes you from literally impossible to possible, using the computers you already own. Every cluster ships with a one-click benchmark so you can measure your own numbers.
RAMDeck is live on Indiegogo: back the campaign.
-The TradeMAV Team