Your training and serving code already works. Lanes Compute is a place to run it, not a framework to rewrite it in. Bring the stack you have.
Lanes Compute is a GPU service in limited early access, and its contract is deliberately thin. You hand it a container; it supplies A100, H100, or H200 SXM cards to run it on, singly or as multi-node clusters, billed per second. The CLI and API exist to drive hardware from your existing tooling, not to reshape your code around a platform.
How Lanes Compute does it
- Standard frameworks. PyTorch, JAX, vLLM, Axolotl, DeepSpeed, and more. Those are examples, not a compatibility list: anything that runs in a container works out of the box.
- Your own containers. Run the environment you already build and test. The image you validate locally is the image that runs on the cluster, same dependencies, same versions, same behavior.
- Any GPU. Match the hardware to what your stack expects. L40S for lighter work, A100 through H200 SXM above it, and multi-node clusters over InfiniBand and NVLink when the workload spans boxes.
- No lock-in. It is your code on rented hardware, nothing more. Moving in means running your container; moving out means running it somewhere else. Nothing accumulates that would need unwinding later.
The same holds for data. Datasets and checkpoints sit on persistent network volumes you control, in a region you choose, and Lanes does not train on your data or share it. What you produce on rented cards stays as portable as the container that made it.
Why it matters
You keep your tools and pipelines. Only the hardware is rented, so moving a workload in or out is easy.
That portability keeps the relationship honest. A platform you can leave in an afternoon has to stay worth using, and a stack that never bent to fit one vendor can follow prices, hardware generations, and your own architecture changes wherever they lead.
Set it up
- Request access. Lanes Compute is in limited early access; request it through the form on the Compute page.
- Describe the stack. The frameworks and containers you run and the GPUs they expect. Describe it as it is; nothing needs converting first.
- Get onboarded. Usually within a day or two.
- Run what you have. Bring the container, mount volumes for data and checkpoints, run, tear down. Billing stops at teardown.
Where this breaks without Lanes
Some GPU platforms are frameworks in disguise. Code gets adapted to their runtime to run at all, and the adaptation reaches into entry points, packaging, and storage access. The convenience is real, and so is the exit cost: when pricing, limits, or priorities change, the workload cannot leave without being rewritten a second time. A thin contract, your container on rented cards, never takes that debt on.
Further reading
- Fine-tune LLMs: bring-your-own-stack applied to tuning runs.
- Run inference and model serving: the same container contract at serving time.
- Lanes Compute vs Modal: a thin container contract next to a serverless runtime.