Use cases/Lanes Compute/Spin up multi-node H100 clusters

Spin up multi-node H100 clusters

Get a multi-node H100 cluster with InfiniBand and NVLink for large training and fine-tuning runs.

Some runs do not fit on one node. Lanes Compute provisions multi-node clusters with the interconnect that makes distributed training actually scale.

Lanes Compute is in limited early access and rents exactly this shape of hardware: H100 nodes joined over fast InfiniBand, NVLink within each node, stood up for a run and torn down after it. H200 SXM is available when a run calls for it, billing is per second, and reserved capacity covers runs that hold a cluster for weeks.

How Lanes Compute does it

  • Multi-node H100. Several nodes wired together for one big run. The same cluster shape serves large training jobs and large fine-tunes, and it grows from a single box to several as the run demands.
  • Fast interconnect. InfiniBand between nodes and NVLink within them. Distributed training synchronizes GPUs constantly, and when links are slow the added nodes spend their time waiting instead of working. The interconnect is what turns more hardware into more progress.
  • Bring your own stack. DeepSpeed, PyTorch distributed, JAX, and more. Jobs run in your own containers, anything that runs in a container works, and scaling across boxes needs no extra setup on the cluster side.
  • On demand. Stand the cluster up for the run and take it down after. Billing is per second and ends at teardown, with reserved capacity available when a run will keep the cluster for a long stretch.

Long runs lean on storage as much as interconnect. Datasets and checkpoints live on persistent network volumes, so a run can checkpoint, release the cluster, and resume later on a fresh one without re-staging data. A pause costs nothing while the environment is down.

Why it matters

Large runs need bandwidth between GPUs, not just more GPUs. The interconnect is the point, and it is there when the run needs it.

Owning this class of hardware is a commitment measured in quarters, and for many teams the big runs are occasional. Renting per run inverts the math: the cluster exists exactly as long as the run does, and the money that would have funded idle nodes funds more runs instead.

Set it up

  1. Request access. Fill in the request access form and say the job is multi-node. Lanes Compute is in limited early access.
  2. Describe the run. Model and data size, framework, how long the cluster is needed, on demand or reserved. Tell us what you need and the hardware is matched to it.
  3. Get onboarded. Usually within a day or two.
  4. Run the loop. Stand the cluster up, train, checkpoint to your volumes, tear it down. The next run starts from the checkpoint rather than from scratch.

Where this breaks without Lanes

Teams with occasional large runs are caught between three arrangements that all lose. A single box caps the run size no matter how long you wait. An owned cluster prices its idle months into every run. And loose cloud GPUs without a fast interconnect add card count while the cards wait on each other. A rented cluster with real interconnect is the missing fourth option.

Further reading

See Lanes Compute.