§ Platform / Distributed compute
Pool your devices. Pool your lab. Pool the crowd.
One mechanism turns the devices you can reach into a working cohort: a job — a program plus a declared way to split it, a declared way to combine the results, and a rule for who may take part — is broken into pieces, a Pool of peers computes them, and every result is verified before it counts. The same mechanism spans your own machines, a consortium of signed institutions, and an open crowd of strangers — three levels of trust the platform never blends.
One mechanism, from solo to swarm
Distributed compute here is not a family of subsystems; it is one thing. A Job is fixed and identified by its contents: a program, a declared rule for where the work splits, a declared rule for how the results combine, and a policy for who may take part. Every piece carries the exact inputs it was handed and its own reproducible slice of randomness, so any peer can recompute exactly the piece it was given — a piece that never comes back is simply re-issued, never lost.
One shape covers data-parallel training, parameter sweeps, ensembles, k-fold validation, Monte-Carlo simulation, and batch analysis. A pool of one device is an ordinary solo run on exactly the same code path — pooling never weakens the offline core, and nothing you build ever depends on someone else showing up. Work that must cross devices in a fixed order — where one machine's output is the next machine's input — is deliberately a separate mechanism rather than being forced into this one.
Your devices, a consortium, or the open crowd — never blended
Every pool declares who may join, and the three answers are never collapsed into one vague trust slider. Your own devices — laptop, desktop, workstation — join as one cohort: full trust, no consent friction. A consortium is built from institutionally signed members; it is the only setting in which safety-critical or regulated work may run at all. An open crowd is anonymous strangers: pure compute, restricted to inputs that are already public, spot-checked at an unpredictable rate, and capped by a budget you set.
Lending compute and co-editing are different acts, and the platform keeps them apart: a stranger can lend you a GPU while reading none of your data and writing none of your document — working on the same document together is live collaboration, a separate decision. The honesty runs the other way too: a peer that executes your work necessarily holds what it computes on, so a model or a dataset you mark confidential refuses the open crowd outright. The wider trust machinery lives on security.
Sweeps, simulations, and batch analysis are first-class
Idle laptops and workstations fuse into one cluster that runs any work you can cut into independent pieces — a parameter sweep, an ensemble, k-fold validation, a Monte-Carlo simulation, a batch analysis over a large dataset — with no training machinery involved at all: independent pieces, a plain declared way to combine them, no gradients anywhere. Whichever peer is free takes the next piece, so a slow peer, a peer that disappears, and a peer that fails are one recovered case rather than three separate patches.
Inputs spread between peers rather than fanning out one by one from a single source, so a large dataset does not become the bottleneck. Results are folded in only after they have passed verification — you cannot un-fold a bad sample from a running mean — and long simulations stream through accumulators of constant size instead of piling up millions of samples in memory. A sweep fills in piece by piece while it runs; the distributed-compute guide walks one end to end.
What pools well — and what honestly doesn't
Different work scales differently. The table says so out loud.
| Workload | Scales | The honest reason |
|---|---|---|
| Parameter sweeps & batch analysis | near-linear — thousands of peers | Independent pieces, no waiting; whoever is free takes the next one, so a straggler and a failure are the same recovered case. |
| Monte-Carlo & ensembles | near-linear | Independent seeds; folded into a constant-size accumulator only after verification. |
| Training that stays in step | sub-linear — tens of stable peers | Everyone waits for the slowest; it grows by syncing less often, never by deeper coordination. |
| Federated learning | by participants | Grows the cohort and the statistical power — never the wall-clock speed. |
| Models too big for one device | split the model itself | Copying the model to more devices adds throughput, not room; fitting it means splitting the model across them — the planner names how. |
No numeric speedup is promised anywhere on this page — the named mechanisms (sending smaller updates, overlapping computation with communication, giving faster devices bigger pieces) are the claim.
Near-linear speedup to thousands of peers is real — and precisely scoped: it holds for work whose pieces never have to wait for each other. Training that stays in step is sub-linear, held by slow peers and by people closing their laptops to roughly tens of stable peers, and it grows by syncing less often rather than by deeper coordination. Churn, not the mathematics, is the dominant cost of pooling.
Two more limits survive into every sentence on this page. Pooling multiplies throughput, not capacity: a model too large for one device is still too large for ten copies of it — fitting it means splitting the model itself across devices, and the planner names which. And a browser tab in the background is frozen, not computing: a contribution counts on a foregrounded, dedicated, or plugged-in device. We promise mechanisms, never multipliers — the rest lives in honest limits.
“Serverless” describes the data, never the coordination
A browser tab cannot accept an incoming connection, so a coordinator is in the loop for every join and every reconnect. Its role is stated precisely: never load-bearing for correctness, and never needed for solo work, which runs fully offline — but genuinely needed to keep a pool working over time. Coordination crosses a server; your tensors do not: the bulk of the bytes move device to device, and on most home and mobile networks that connection is direct.
Behind a corporate firewall — the locked-down institutional setting — a direct connection usually fails and traffic falls back to a relay. For that setting the relay is the steady state, and we say so instead of rounding it up to “device to device”. One rule holds at every scale: only peers ever combine a result — the coordinator sequences and elects, it never sums — and a large pool spreads its coordination out rather than funnelling everything through one point.
Federated learning is a setting, not a subsystem
Federated learning is the same job in a different setting: each participating site keeps its raw data, trains on its own hardware, and sends only model updates, which a declared strategy averages. The strategies are ordinary catalog content, not engine code: FedAvg, FedProx, SCAFFOLD, DiLoCo, and the FedAdam family for stable consortia; FedBuff and gossip for fleets of devices that come and go; Ditto, FedPer, and clustered federation for the common case where one global model is the wrong goal. Writing a new one is ordinary authoring.
The recipe lives in Model View beside every other training setting — the strategy, who takes part each round, how much each update is clipped and how much noise it carries, and a live privacy-budget meter you can watch. The engineering is concrete: a federated language-model run exchanges small adapters instead of full weights — roughly a thousand times less to send — and compressing those updates without losing what they carry is what makes ordinary home connections workable at all.
The privacy claim is stated at two levels, because they differ. “Raw data never leaves the device” is true of the bytes, and the format the update is sent in enforces it: there is no field a raw sample could travel in. But an update is a function of the data — sometimes a reversible one — so the guarantee about the information holds only with a floor that is always on: every update that leaves a pool beyond your own devices is clipped and carries accounted privacy noise, charged against a budget that refuses to overspend, with secure aggregation layered on where the cohort allows it — required between institutions, and never a substitute for the noise. Regulated cohorts run in a consortium, and nowhere else.
Counted by verified work — never by the clock
| Capability | Status | What it means |
|---|---|---|
| Volunteer pooling | live today | Own devices, volunteers, consortia — every accepted piece produces a record; no money moves. |
| The contribution ledger | live today | A chained, tamper-evident history — an entry is minted by verification, never by elapsed time. |
| Capacity offers | live today | Advertise a machine's idle hardware and the hours it is free — and browse jobs looking for compute. |
| Paying for compute time | a named next step | Escrow, a forfeitable deposit, and a provider bond ship together as one unit — or not at all. |
| The Copilot and money | barred by construction | No assistant — ours or yours — can create a paid pool or move money; it is refused by the way the system is built, not by a setting. |
None of this machinery is waiting in a drawer: the volunteer pool exercises every part of it today — paying for compute adds payment rails, never new mechanics.
Acceptance and counting are the same boundary. A result enters the ledger only after it has been verified — recomputed against the reference within a declared tolerance, spot-checked at moments a peer cannot predict, or agreed by several peers where no reference applies — and every accepted unit produces a contribution record whose cost the planner derives from the work itself, never from what the contributor claims. Elapsed time is never counted: it can be faked, it pays for slowness, and it is blind to whether the answer was right. In an open crowd the resulting guarantee is probabilistic, economic, and auditable — never cryptographic and absolute.
What runs today is the volunteer economy: pools of your own devices, of volunteers, and of consortia — contribution records, a contribution history, and capacity offers through which a machine advertises idle hardware and browses jobs looking for compute. That is the supply side of a market for compute time, which does not exist yet: paying for it is a named next step and ships as one indivisible unit — escrow, a deposit that can be forfeited, a provider bond — because paying out without deterring fraud would make cheating profitable. It is a different thing from the Marketplace, which sells packs, models, and datasets, and never sells compute. And one rule holds on every plan: computation on your own device is never counted at all.