RAMDeck can spread a model across computers. It cannot turn their memory into one fast pool
Layer splitting can make a model fit. Network latency, unequal devices and benchmark choices determine whether the result is useful.
RAMDeck's promise is attractive to anyone with a drawer of retired hardware: use several computers to run a local AI model that will not fit on one of them. The project is drawing attention with a proposed $109 hub, but the more revealing evidence is in its own software documentation and benchmarks. Adding a machine can increase available capacity while making generation slower.
The project's explanation describes distributing work across devices through a local network. Its public code repository also matters: the useful capability is not simply a physical box that turns unrelated memory chips into one conventional RAM bank. Software allocates parts of the model and coordinates computation between machines.
The weights stay put; intermediate results travel
In a layer-distributed arrangement, each participating machine holds assigned model weights and processes its portion of the computation. Intermediate activations pass to the next participant. This differs from constantly copying the entire model across the network for every generated token.
It also differs from installing more RAM in a single computer. The remote processor still has to perform its work, and the network introduces delay. A fast machine can spend time waiting for a slower one. More aggregate capacity therefore answers “will it fit?” without necessarily answering “will it feel responsive?”
The RAMDeck FAQ recommends wired networking and describes platform-specific participation. Its licensing explanation is equally important: the project calls its code source-available, with a Commons Clause addition, rather than claiming an unrestricted open-source licence. The ability to inspect and run code should not be confused with permission for every commercial redistribution.
The project's own numbers expose the tradeoff
RAMDeck's published benchmark table includes a dense 27-billion-parameter model running at 1.92 tokens per second across four devices. Another test uses a roughly 17GB Qwen3-Coder mixture-of-experts model across an RTX 3060 system and an M4 Mac mini, reporting approximately 39 tokens per second. These are developer measurements, not GeekRadar tests, and they are not a controlled comparison between model sizes.
A dense model uses all its parameters in the computation for each token. A mixture-of-experts model selects a subset of experts, so its total parameter count does not describe the active workload in the same way. Hardware, quantization, context and distribution also differ. Reading those two results as “30B is faster than 27B” would miss nearly everything that explains them.
The same table reports a smaller model slowing after a phone joined over Wi-Fi. That is a useful counterexample to the assumption that every additional device is an upgrade. A phone's contribution must be worth its communication and processing costs; RAM that exists somewhere on the network is not automatically fast RAM for the job.
A hub has to earn its convenience
The crowdfunding proposition should be judged separately from the underlying ability to distribute inference. A finished hub might simplify discovery, connections and administration. Those conveniences could be valuable, but a campaign is not proof of delivery or of performance on a buyer's particular collection of machines.
For an experimenter, the sensible starting point is the available software and a model with known memory requirements. For someone who needs reliable interactive speed, the first question is whether one suitable machine would be simpler and faster. RAMDeck's most defensible promise is access to models that otherwise cannot fit. Turning a pile of computers into a better conversation partner remains a much more demanding claim than adding up their memory stickers.
