Run fine-tuning, batch inference, and reinforcement learning as durable jobs across lower-cost GPUs. Set the budget; slipa routes across providers, checkpoints the work, and recovers the job when a spot machine disappears.
Reading live prices
Lowest hourly quote per provider, per card.
Serverless GPU platforms are built for instant starts and rapid scale. Those guarantees matter for online inference; they matter less for fine-tuning, batch inference, and RL jobs that can wait or recover. You still pay the premium.
slipa makes lower-cost spot capacity usable for those jobs. Submit the workload once; the machine can change while the budget, progress, and result stay with the job.
Submit through the CLI or console. slipa turns the workload spec, budget, and image into one durable job, then owns the provider changes underneath it.
one workload in
$ slipa run finetune \
--model meta-llama/Llama-3.1-8B \
--dataset tatsu-lab/alpaca \
--method qlora \
--max-budget 5.00slipa prices the completed run, not just the cheapest GPU-hour. Available capacity, GPU count, and modelled throughput all affect the choice.
These are modelled ranges, not customer results. They use observed provider price spreads against comparable RunPod or Lambda on-demand capacity. Actual savings depend on hardware availability, runtime, and checkpoint cadence.
When a spot GPU is reclaimed, slipa verifies the newest complete checkpoint, finds replacement capacity, and resumes there. Only work since the last verified checkpoint is repeated. You submit one job even when it runs on more than one provider.
Nothing is held or billed while replacement capacity is acquired.
Queued
Each tick is a checkpoint manifest. The tall amber one is the last that verified — the point the run comes back to.
Work discarded. Everything computed since that manifest, thrown away on the eviction. This is the real cost of a reclaim, and it is bounded by how often you checkpoint.
No GPU held. The gap between losing one card and acquiring the next. Nothing is billed here.
slipa can wait for a better price or move a job between providers without stopping for approval. It cannot spend past the cap you set.
How is this different from running on spot myself?
The scripts are easy; the failure handling is not. What takes the time is proving a checkpoint is complete before you trust it, catching the shutdown signal in time to save, and deciding whether a cheaper quote elsewhere is worth moving for. That is the part slipa is.
What workloads fit slipa today?
Long-running, asynchronous jobs that can tolerate a short pause: LoRA and QLoRA fine-tuning, batch inference, RL rollouts, and RL fine-tuning. You can use a managed workload or bring a publicly pullable container image.
Is slipa for real-time inference?
No. slipa does not replace an online serving layer today. It is built for batch and asynchronous GPU jobs where cost matters more than an always-warm endpoint.
What if there is no spot capacity for the GPU I need?
The job waits and keeps retrying rather than failing. You can also set a price you are willing to pay and an amount of time to wait for it, and the job will sit until the market reaches your number or the clock runs out.
Why not use a serverless GPU platform?
Serverless platforms are built to start and scale request-driven compute quickly. slipa is built to lower the completed cost of a long-running job by routing across providers and recovering through interruptions. You submit one workload instead of managing accounts, machines, and recovery across vendors.
Can I bring my own image?
Yes. Every supported workload accepts a publicly pullable container image. Private registry credentials are not supported in the private beta.
What does private beta cost?
There is no billing or platform fee during private beta. We are working with a small number of design partners before announcing commercial pricing. Spend is still tracked against the cap you set for each job.
Tell us the workload, GPU class, and what you spend today.