Most "decentralised AI" stops at the demo. A big model runs in one company's datacentre, a token is charged, and the word decentralised is doing a lot of work. We want the opposite, and we are blunt about the aim: the biggest open model in the world, owned by no one and served by everyone. Its weights live nowhere in particular. It runs on the graphics cards people already have under their desks. Every card that joins adds capacity to the whole, and earns its operator QBC for the work it can prove it did. The payment and the proof of correct work settle on chain, so you never have to trust the node you never met.
This post is the honest engineering account of how that can work, what we have built, and what it still needs before it is live. Maturity labels throughout are exact: designed, built, or live. None of what follows is live yet, and we will say so plainly.
The model, and the wall
The target is a Kimi-K3-class open model: about 2.8 trillion parameters, roughly 60 transformer layers, 896 routed experts per layer, of which only 16 (plus 2 shared) fire for any given token. It ships in MXFP4, a 4-bit microscaling format. That sparsity, only 16 of 896 experts active, turns out to be the whole story.
The naive wall is memory. We built an MXFP4 codec in our runtime and measured the real number: 4.25 bits per parameter once you include the block scale, which is about 24.8 GB for a single layer. A whole model is roughly 1.4 TB. No consumer card holds a layer, let alone the model. A rented datacentre holds it, but then you are back to one owner, one point of failure, and a six-figure monthly bill. That is the thing we refuse.
The pipeline axis
The decentralised move is to shard by layer, not by expert-all-to-all. Each node
holds a slice of the layers. A token's hidden state, a small [batch, tokens, hidden] tensor, hops from node to node, one hop per layer boundary. We measured
that hop at 14 to 28 KB per token. Compare that with the roughly 13 MB per token
an expert-parallel all-to-all would push across the wire, and you can see why one
is feasible over the public internet and the other forces a datacentre.
The primitive is real and tested: a layer-range server that runs its slice and passes activations on, proven byte-for-byte equivalent to a single-box forward across three shards over real peer-to-peer TCP. That part is built.
The 12 GB question
Here is where it gets interesting, and where an owner constraint made the design better. The requirement was blunt: it has to run on a 12 GB card, the common RTX 3060 / 3080 Ti / 4070 tier, not a scarce 32 GB professional card. A 24.8 GB layer does not fit 12 GB. So does the whole idea collapse?
No, because MoE is sparse. Only 16 of 896 experts run per token. So a node keeps the full set of experts in ordinary system RAM (about 21 GB, which a 32 GB box holds comfortably) and its GPU holds only the attention, the router, the shared experts, and the small working set of experts that actually fire. We budgeted it against a 12 GB card and the answer is striking: a whole layer uses about 3 GB of VRAM. The 12 GB constraint is not even the binding one. The real gate is system RAM, not video memory.
Two techniques make it hold up under load, and we were honest with ourselves about both by running an adversarial review against the design:
- Prefill looks fatal at first. Over a long prompt, the set of experts that get touched grows to nearly all 896, so "stream only the active experts" degenerates to moving the whole layer. The fix is to process the layer expert-by-expert: for each expert that is hit, stream its 23 MB once, run every token routed to it, then evict. The bytes moved are bounded by a single pass and are independent of how long the prompt is. Peak VRAM stays around 2 GB.
- Decode can skip the transfer entirely. The active experts already sit in RAM, so a 12 GB node can compute those 16 experts on the CPU and move only the tiny activations, never the weights.
This part is designed and partially built: the sparse expert dispatch that runs only the selected experts is written and tested; the GPU placement layer that streams and computes under those two strategies is specified and budgeted, and needs real multi-GPU hardware to benchmark.
Honest performance
This is not interactive chat, and we will not pretend it is. It is the asynchronous, agentic tier: think of a large model working through a task in the background. Expect roughly 0.1 to 0.3 tokens per second on a single stream over real internet latency, around 11 tokens per second aggregate across a full pipeline serving many streams at once, and a time-to-first-token of a minute or two on a long prompt. For a frontier-scale model running on volunteer hardware that nobody paid a datacentre for, that is a remarkable place to be. For a chat box, it is not, and the fast single-node model that answers qbc.network today stays exactly where it is.
Why the network gets stronger with every node
Here is the part that makes this different from renting a datacentre. A datacentre is a fixed thing that one company owns and pays for. This is the opposite: a living network that gets more capable the more people join it. Be precise about what "more nodes" buys, because we will not overclaim it.
A single request will not get faster, because its latency is set by physics: the token still has to walk every layer in order, one hop at a time. What grows with the fleet is everything else, and it is the part that matters:
- Capacity. Every extra node that hosts a layer range is another lane. More nodes means more requests served in parallel, so aggregate throughput climbs roughly in step with the fleet.
- Resilience. Each layer range is served by several nodes. Add more and any one dropping out stops mattering, and the slowest node stops being the whole pipeline's bottleneck. The network heals around failure instead of halting on it.
- Reach. A bigger fleet can hold a bigger model. The ceiling on model size is not one card's memory, it is how many cards are willing to each hold a slice. A network of tens of thousands of ordinary GPUs can, between them, serve something no single datacentre rack could.
- Ownership. No operator holds the whole model, so no operator can switch it off, gate it, or quietly swap the weights. The model belongs to the set of people running it, and the on-chain root is what they all agree it is.
And every one of those nodes is paid. Joining is not charity or a leaderboard score, it is work that earns QBC, settled per token against a signed, on-chain proof that the work was actually done. That is the flywheel: more nodes make the network faster and larger and harder to kill, the network pays them for it, and the payment pulls in more nodes.
Proof and payment, on chain
Decentralised serving is only worth anything if you can trust the node you never met. Two mechanisms, both built as primitives:
- Verify before you load. Each layer, and each expert subset, commits to its weights through a Merkle tree whose root is anchored on chain. A node fetching its slice checks that the blob it downloaded is the one the network agreed on, before it ever runs it. The commitment binds the layer index and the expert range, so a node cannot quietly serve the wrong slice.
- No single point of failure, and no impostors. Every layer range is served by several nodes; if one drops mid-request, the client reroutes to another and the result is identical. And a node cannot advertise a slice it does not actually host: adverts are signed, and a reroute target is checked before it is ever handed your activations.
The economics reuse the on-chain serving-reward machinery the network already runs, extended so that payment settles per hop against a signed commitment, not against a promise. Nodes are paid per token they actually, provably served.
What is built, and what it still needs
Built and unit-tested: the MXFP4 codec, the sparse expert dispatch, the pipeline layer server and its wiring into the node, the redundancy and reroute, the signed adverts, and the on-chain per-layer commitment. All of it is public in our repositories.
Not yet live, and honestly gated on two things money and code cannot conjure: the model weights have to be mirrored and sharded, and a fleet of volunteer 12 GB nodes has to exist. Serving a 2.8T model needs real nodes running real hardware, and a cross-machine, cross-architecture test to prove the numbers before anyone should believe a live claim. We are building toward exactly that test, not around it.
That is the standard we hold ourselves to: the version of this that survives a skeptic reading the code. When it is live, we will show you the block, the root, and the tokens, and you will be able to check every one.