One Model, Two Machines: We Split a Neural Network Across Mismatched Hardware and It Thought Anyway
We asked a question to a model whose brain was physically split across two different computers — half its layers on a gaming GPU, the other half on an idle ARM box across the room, the two of them passing half-finished thoughts back and forth over the same network your printer uses.
It answered:
The speed of light is approximately 300,000 kilometers per second.
Read that again with the right emphasis: the two halves of the model's mind were on separate machines, of different processor architectures, and the thought still came out whole. Then it did it three more times — the capital of France, the capital of Japan, what water is made of — all correct, all generated with the layers executing on both computers simultaneously.
That is the entire point of this post. Everything else is how, and why it matters more than it sounds.
The fork in the road everyone accepts
Say "I want to run a big model at home" out loud and watch the conversation split into exactly two options: rent time on someone's GPU cluster, or shrink the model until it fits on your one machine. Pay rent forever, or accept something smaller than you wanted.
There has always been a third road, and almost nobody drives it because it's supposed to be too hard: don't rent, don't shrink — pool. Take the model that's too big for any single box you own, and run it across several boxes you own. Tonight we drove down that road far enough to prove it's paved.
The receipt
Two computers, chosen to be as mismatched as possible on purpose:
| Machine A (coordinator) | Machine B (worker) | |
|---|---|---|
| Role | runs the first layers | runs the last layers |
| Chip | consumer x86 gaming GPU | ARM processor, no matching GPU stack |
| Link | ordinary local network — round-trip ~1 millisecond |
We took a 27-billion-parameter model, sliced its layers into two groups, put one group on each machine, and ran inference. The model produced coherent, correct answers at roughly 10 tokens per second, with the worker machine genuinely executing its share of the network — not caching, not faking, actually computing layers and handing the results back.
Two machines. Two architectures. One mind. It worked on the first honest try.
Three reasons it's "supposed" to be impossible — and what each really is
"They speak different languages." One machine is x86, the other ARM — normally two incompatible worlds. But the remote-compute layer serializes the intermediate math into a chip-neutral wire format; it doesn't care what's on the other end as long as both were built from the same source. We rebuilt the open-source inference engine on both machines with its remote mode switched on, and x86 and ARM shook hands immediately.
"The network will make it slower than one machine." This is the real risk, and we refused to hand-wave it. A split model ships intermediate results back and forth on every step; if each hop costs 10 milliseconds, the overhead drowns the actual thinking and you'd have been better off on one box. So before writing a line of the interesting code, we measured the round-trip on our actual network. It came back at about one millisecond. That single number is what flipped the whole project from "maybe" to "go." Measure the load-bearing assumption first — always.
"You need a bespoke distributed framework." We assumed we'd build a distributed runtime from scratch. We started to. Then we caught ourselves: the capability was already sitting inside the open-source engine we run — it just needed to be compiled in. The recurring lesson of this whole effort: before you build a parallel tool, check whether the one in your hand already does it.
Why this specific result matters
Because it quietly moves a line that decides who gets to build with frontier models.
If the only way to serve a genuinely large model is a datacenter, then the frontier belongs to whoever owns the datacenter — full stop. But if a handful of people with ordinary machines — a gaming rig here, a workstation there, a dev box that's otherwise idle — can combine them into something that holds a model none of them could run alone, the frontier becomes a thing a community builds for itself.
And the scaling property points the right way. Add a third machine and you can hold a bigger model, or serve more people at once. Add a tenth. The ceiling on model size stops being "the biggest single GPU you can afford" and becomes "how much hardware the group is willing to pool." More machines means more capacity. That is the whole thesis of a community supercomputer, and tonight was its first working cell.
What we are not claiming
The fastest way to lose your credibility is to oversell the demo, so here is exactly what this was and wasn't:
- Same-network, not internet-scale — yet. The ~1 ms round-trip holds for machines on one fast local network: your rack, a few boxes in a building, a low-latency pool. Spread the same split across the public internet at 50–100 ms and the naive version becomes a pessimization. Closing that gap (bigger, less chatty layer-groups; pipelining many requests to hide latency) is real work we haven't done. It's an optimization on top of a thing that already works — not a precondition.
- The slow half was a CPU. The ARM box did its layers on its processor, which is why we were at ~10 tokens/second and not ~100. Put a GPU on both ends and the number moves a lot.
- It's a reproducible script, not a product — yet. The next step is turning tonight's manual sequence into one command: your machine joins the pool, advertises what it can offer, and starts contributing — no SSH, no build steps, no config. That packaging is what we're building now.
None of those caveats touch the core fact, which is the one we came for: a single model's layers, executing on two different computers at once, producing coherent thought.
Where this goes
The demo is one cell of a much bigger organism we're building in the open: a network where anyone can contribute the machine they already own, the collective serves models larger than any single member's hardware, and lending your idle compute earns you a stake in the shared result. Tonight proved the hardest-sounding piece of it — split a real model across real, mismatched machines and get a real answer back.
The third road exists. It's shorter than everyone told you. And it goes exactly where we hoped.
We're publishing the reproducible proof and hardening the one-command tooling in the open. If pooling the hardware you already own into something bigger than any one box sounds like your kind of problem — this is the part of the roadmap we're most excited to build with you.