The cheapest GPU is the one you are not paying for while it sits idle. Lanes Compute lets you pick the right card for each job and bills by the second.
Lanes Compute is a GPU service in limited early access. The range runs from light inference cards up to the current training generation, from one card to multi-node clusters.
The billing model fits in a sentence: you pay while an environment is live and nothing once it is torn down. The Compute FAQ covers the rest, including reserved capacity for longer runs.
How Lanes Compute does it
- Right-size. The card is chosen per job rather than per quarter: an eval pass takes a lighter card, a fine-tune takes a heavier one, and neither decision binds the next.
- Per-second billing. Pay for exactly the time you use. Environments spin up in seconds and bill by the second, so a quick experiment costs cents and a two-hour job is billed as two hours, with nothing owed after teardown.
- Scale up and down. More GPUs for a big run, fewer for a small one. Capacity is on demand for bursts, reserved for longer runs, and multi-node when a job outgrows one box. Scaling is a per-job decision, made as often as the work changes shape.
- Nothing idle. Release compute the moment a job finishes. Teardown does not lose the work: datasets and checkpoints persist on network volumes, so releasing hardware is the default move, not a risk.
Why it matters
Spend tracks the work, not a fixed reservation you rarely fill.
The two halves only work together. Per-second billing on an oversized card still overpays every second it runs, and the right card on a standing reservation still bills through idle nights.
Which card, and for how long, are the two questions that set a GPU bill. Right-sizing plus per-second billing answers both per job rather than once per contract.
Set it up
- Request access. Lanes Compute is in limited early access; request it through the form on the Compute page.
- Describe the mix. The jobs of a typical week, from quick evals to training runs, and the frameworks behind them.
- Get onboarded. Usually within a day or two.
- Size per job. Spin up the card each job needs, run it, tear it down. The bill afterwards reads as a list of jobs, which is what makes over-provisioning visible enough to stop.
Further reading
- Batch processing and experiments: the workload where per-second billing shows up first.
- Run inference and model serving: right-sizing applied to a steady workload.
- Lanes Compute vs Vast.ai: two takes on pay-for-what-you-use GPUs.