A GPU Across the Internet Joined 122B Inference
A Blackwell workstation in another city dialed one outbound 443 connection and computed experts for a live 122B decode — byte-identical to a local run, and paid in KVR for the work it did.
What happened: a 122B decode running on an AMD backbone in one place sent its per-token expert work to an NVIDIA GB10 (Grace Blackwell) machine in another city — over a single outbound WebSocket on port 443 — and got back expert outputs that produced the exact same tokens as computing locally. No tunnel, no port-forwarding, no inbound firewall hole. The remote box earned KVR for the bytes it served.
Kvasir's premise is *whatever hardware shows up* — including hardware behind carrier NAT, on the public internet, in a different city. Qwen3.5-122B-A10B carries 86% of its weight in 12,544 independent experts (48 layers × 256, top-8), each a 5.3 MB pure function. That grain is what lets a distant, unrelated machine hold a slice and contribute. The open question was never *can we split it* — it was *can a worker across the open internet actually participate in a live decode, correctly and accountably*. Now it has.
No tunnel, no inbound ports
The remote worker opens one connection — outbound wss:// to the public gateway on 443, the only port carrier NAT and CDN edges reliably pass. The gateway doesn't parse the stream; it raw-splices the WebSocket to the LAN-only hub, which bridges it to the backbone's expert-dispatch listener. Both ends dialed outward and met in the middle. The worker exposes zero inbound ports and needs no public address.
Two outbound dials, spliced into one ordinary dispatch stream.
remote worker ──outbound 443──▶ wss://gate.kvasir-ai.net ◀──── backbone (LAN) (GB10, another city) raw WS splice → hub → dispatch listener per token: backbone → (cur rows, expert ids) → worker → expert partials → backbone
The router decides once; the math regroups exactly
The backbone runs the router once and authoritatively; the worker is a pure (hidden, ids) → out function. So moving that function across a continent changes *where* the multiply happens, not *what* it computes. On a live 122B decode with layer-0 experts served remotely: the greedy token stream was 8/8 identical (" Paris."), logit cosine 0.99773, argmax match. This is the same router-authority property that keeps CUDA↔ROCm↔CPU discrete decisions invariant — heterogeneous backends stay bounded by continuous error, never a catastrophic branch.
Why the swarm is a throughput fabric, not a low-latency decoder
Serial per-token dispatch pays a round trip per step. Measured: with a direct link (13 ms RTT) the throughput overhead was 1.2% (4.220 → 4.169 tok/s); routed through a CDN edge on 443 it was ~28%. We publish that honestly, because it points at the design truth — a WAN swarm is RTT-bound, so its strength isn't the latency of one stream but aggregate capacity. Batching amortizes the round trip: batched expert dispatch reaches 77× the per-token throughput at batch 512. Bytes are headroom; round-trips are the thing to hide — which is the subject of the companion roadmap post.
Metered bytes become KVR
Participation is worthless if it isn't accountable. The relay meters the bytes bridged per session into the hub's contribution ledger; the gateway polls that ledger and delta-credits KVR to the worker's own wallet — non-custodial, like everything else. The first cross-internet session actually accrued: 1.28 MB of work → 1.277952 units → 0.00895 KVR in pending rewards. Small, and that's the point — it's real, per-work settlement, not a participation trophy.
The same outbound-443 path is exactly how a phone joins: a Galaxy S25 has already computed 122B experts over it (8/8 identical tokens, cosine 0.99992). A frontier-scale model, served by a backbone in one place, a datacenter GPU in another city, and a phone in someone's pocket — all producing the same tokens, each paid for its share. What's next is making the WAN round trip cheap; that roadmap is grounded in others' production numbers and our own measurements.