Use cases/Lanes Compute/Train models on on-demand GPUs

Train models on on-demand GPUs

Spin up the GPUs a training run needs, from a single A100 to multi-node H100 clusters, and pay only while it runs.

Training is bursty. You need a lot of GPU for a while, then nothing. Owning hardware for the peak is wasteful. Lanes Compute lets you rent exactly what a run needs, when it needs it.

Lanes Compute is a GPU service in limited early access. A100, H100, and H200 SXM are available today, from one card to multi-node clusters, with capacity taken on demand or reserved for longer runs. Billing is per second: you pay while the environment is live and nothing once it is torn down.

How Lanes Compute does it

  • Any GPU. From a single A100 up to H100 and H200, on demand. L40S and other options cover lighter jobs, and no choice is permanent: pick the card per run, and pick differently for the next one.
  • Scale to the run. One card for a small model, a multi-node cluster for a big one. Clusters are wired together over fast InfiniBand between nodes, with NVLink within each node, so added hardware turns into training throughput rather than communication stalls.
  • Fast storage. Persistent, fast storage so data loading is not the bottleneck. Datasets and checkpoints live on network volumes that persist between runs, so a stopped run resumes from its last checkpoint rather than from a fresh copy of the data.
  • Per-second billing. Pay while the run is up, not for idle time. The meter stops at teardown, and for runs that will hold hardware for weeks, reserved capacity is available.

Why it matters

You match spend to the run instead of to a peak you rarely hit, and the hardware is there when the run is ready.

That changes how training gets scheduled. Owned hardware pushes teams to queue runs so the boxes stay busy, which means the queue, not the research, sets the pace. Per-second rental removes the queue: each run gets its own environment, sized to it, stood up when the code is ready. The bill afterwards reads as a record of runs, which makes cost per experiment a number you can actually see.

Set it up

  1. Request access. Lanes Compute is in limited early access. Fill in the request access form and say what you plan to train.
  2. Describe the run. Model and data size, framework, single card or cluster, on demand or reserved. That is enough to get matched to hardware.
  3. Get onboarded. Usually within a day or two.
  4. Run the loop. Stand up the environment, mount your volumes, train, checkpoint, tear down. The next run starts from the checkpoint, and billing stops the moment the environment is gone.
The alternative is sizing for the peak. A team that owns eight GPUs for one heavy monthly run pays for them the other twenty-nine days, and a fixed cloud reservation is the same arithmetic with a different owner. Training demand is spiky, and the bill should follow the spikes.

Further reading

See Lanes Compute.