Home›Products›Clusters
Joining several nodes into a single training job. We cannot do that today, and we are not going to act as if we can — this page explains why it is hard and in what order it will arrive.
The email address is a placeholder; the mailbox opens soon.
Today's limit
The difference is technically large and easily blurred in marketing. So we write the two out separately.
You can rent 2, 4 or 8 GPUs in the same machine as a single pod. Communication between the cards runs over the machine's own bus; PyTorch's single-node distributed training (DDP, FSDP) works here without trouble. For most fine-tuning work, this is what you need.
Joining the sixty-four GPUs of eight machines into one training run is a different product: it needs a dedicated inter-node network, simultaneous placement and shared failure handling. Nothing like that exists in our pool; when it does, it will be written here.
What you can do today
Narrow the filter by GPU count, rent it as a single pod, start single-node distributed training. Per-second billing and the hard budget cap apply here exactly as elsewhere.
The engineering reality
The hard part of a cluster is not finding GPUs; it is the space between them. There are four separate problems, and all four depend on the quality of the supply.
In multi-node training, gradients are gathered across every node at each step. That traffic does not travel over an ordinary internet connection but over InfiniBand or a high-speed RDMA fabric; inside a machine, NVLink connects the cards to each other. This fabric is a property of the data center, not of a machine — two nice cards in different cities do not make a cluster.
When you rent a single pod, one suitable offer is enough. In a cluster, all eight nodes must be up at the same time, in the same data center, on the same fabric, for the same duration. On scattered supply that is not the sum of eight separate rentals but an all-or-nothing placement problem.
If a single node goes down, one pod goes down. In a cluster, if one node goes down the whole run stops. "You don't pay for seconds that don't work" is a far heavier promise here: what is at stake is not only the failed node's seconds but the seconds of every node waiting on it. We will not sell that before we can measure it.
For a single pod, the broker layer can say "whose GPU spins underneath is our job to handle". In a cluster it cannot: which node hangs off which switch directly determines training speed. The abstraction contradicts the product itself.
Verified tier
Across the rest of the marketplace we can work on the assumption of an untrusted host: the container isolates, secrets never land on the host's disk, the scorecard weeds out bad machines. For a cluster that is not enough.
A host can say "I have InfiniBand"; in a cluster that has to be measured, verified and continuously monitored. The Verified tier carries exactly that audit: data centers verified on site.
Holding eight nodes at once requires a commitment on the supply side. On a spot marketplace that commitment does not exist; on an SLA-backed tier it does. That is also why cluster pricing will work differently from spot offer pricing.
Today's scorecard measures a single machine's uptime, benchmark consistency and network. What has to be measured for a cluster is inter-node bandwidth and the latency distribution — a new family of measurements, a new scorecard.
The Verified tier and audited data centers fall under Phase 3 in our technical plan; because clusters depend on it, they cannot come before it. On the sovereignty page we write out separately which commitment holds today and which is planned.
The order
The phase order comes from our technical plan and is a plan, not a commitment. We give no dates because we have no date we could be held to; if the order slips, we will write it in the changelog.
Let's talk
How many nodes, which model, for how long — write to us. Those answers will decide who we build the cluster for and at what scale. In the meantime, let's see how far you get on a single node.
The mailbox opens soon.