one GPU network on two kinds of host

Consumer GPUs where density already exists. Carrier-tower GPUs where carrier-grade coverage matters, tested on UK tower sites. Orchestrated as a single network.

two kinds of host

Homes carry the density: hardware already bought, plugged in and cooled. Towers carry the certainty: 168 live game sessions over 20 days on UK tower sites.

the nearest qualified node

Every node near the player is checked for GPU capability and free capacity, not distance alone, so the one that drops out here sits closer than the one that wins.

the session is a live line

State stays on the line: input up, frames back, from a node down the street. A data centre 500 km away spends 5 milliseconds in glass before it computes anything.

none of this hardware is ours

The house belongs to the operator, the tower to the carrier. Ours is the layer that turns them into one machine, and lets one card carry several sessions.

one machine

HyperOrch treats both kinds of host as one computer. Your workload can too.

two kinds of host, and we own neither

density

homes

Gaming hardware sits bought, plugged in and cooled before we arrive. The operator owns the machine, so cooling, bandwidth and real estate are never ours.

certainty

towers

Carrier sites come pre-powered and cooled at four to seven cents a kilowatt hour. 168 live game sessions ran over 20 days on UK tower sites.

ours

the layer

Three components, built by us, and the only part of this picture we own.

built for stateful sessions

the same open connection carries a live conversation

The clearest evidence comes from the market itself: in 2026 the largest cloud-gaming services capped play hours or cut features. That is not a pricing choice. It is the cost of GPUs that sit waiting for the evening peak.

YOM

sessions

stateful: one player on one live connection, input up and frames back for the whole session

middleware

hardware encoding (NVENC) and WebRTC streaming built in, so the buyer ships no streaming stack

latency

each session placed on the nearest qualifying node; sub-10 ms one-way is the target

content security

a container per session, destroyed when it ends, on an encrypted node disk; unreleased builds only on capacity YOM controls

overflow

rented cloud GPUs take the overflow where operator supply is thin

defensibility

patent-pending technology across the secure boot medium, pixel streaming and orchestration

stateless GPU networks

sessions

GPU-hours, mostly batch and stateless inference

middleware

raw GPU rental

latency

latency tolerant by design

content security

the buyer secures its own workload

overflow

the buyer's problem

defensibility

commodity aggregation

three components, one network

the orchestrator

HyperOrch

The control plane. It checks every node near the player for GPU capability and free capacity, and places the session on the nearest one that qualifies, so the player gets the shortest path the network can offer.

Five steps from a click to a paid operator, the same route the world above takes.

  1. request

    Press play in the browser. Nothing to install.

  2. match

    The nearest qualified node takes it.

    HyperOrch
  3. boot

    A fresh container for this player, destroyed when the session ends.

    NodeOS
  4. stream

    Frames encoded on the GPU and sent over WebRTC; input comes back up.

    Universal Streamer
  5. settle

    The fee is split and the operator is paid.

the runtime

NodeOS

Each player gets a Docker container with GPU access (NVIDIA Container Toolkit), destroyed when the session ends, so nothing carries over. Windows titles run through Proton, and the host agent pulls its work, so a node opens no inbound ports.

the last meter

Universal Streamer

Each session runs on the GPU's hardware encoder (NVENC) and streams over WebRTC to the browser, so players install nothing and the title needs no change.

what runs on it, and what it costs

live network

the network, live

Every green point is a host machine, sized by the sessions it served. Every line is real sessions between a player area and a host. Player positions are rounded to about 110 km.

measured
host machines offline players sessions52 host machines · 16,100 sessions · last 30 days · measured as of 10 Oct, 00:00 UTC

every figure comes with its method

15ms

median one-way latency, players within 50 km of a node

Median one-way latency (half the WebRTC round trip), last 30 days, players within 50 km of the node, measured as of 10 Oct, 00:00 UTC. The figure the rest of the site quotes.

40.5ms

median, all sessions

The same measurement over every session in the window, including players far from any node.

Full benchmark detail on the source of truth page.

read the docs or bring a workload

The docs go one level deeper on every component above. If you would rather test it than read it, tell us what you want to run.