Home/Solutions/Fine-tuning
From LoRA and QLoRA all the way to full training. Your checkpoint sits on a persistent volume independent of the pod, you don't pay for seconds that don't work, and the hard budget cap stops the job — not the invoice.
You pay per second and stop whenever you want. No commitment.
Your work probably looks like this
Fine-tuning takes a long time, and every long job hits something eventually. The items below are not problems we invented; they are the three places anyone renting cheap GPUs already knows.
A container's disk is ephemeral. When the pod goes down, nine hours of training go with it; all you are left with is your terminal history.
The price of a cheap card is usually uncertain reliability. The driver locks up at 03:00, and in the morning you find both a stopped job and a bill that kept running.
A stopped pod's disk keeps billing, and a forgotten experiment stays open for weeks. At the end of the month the number is twice your estimate.
The Kaldera answer
These are not marketing lines but three separate pieces running inside the product: a health gate, a budget enforcer and per-second metering.
The health probe runs every 15 seconds. Seconds that fail it never enter the bill — not as a discount, but as a line item that does not exist. A correction found after the period closes shows up as a refund line.
The cap is not a warning bar but an enforcement mechanism. Notifications arrive at 80% and 95%; when the cap is reached, pods are paused, not deleted. The disk stays, the checkpoint stays, you raise the limit and carry on.
If training took 9 hours 14 minutes you do not pay for 10 hours. If you cancelled a trial run after 4 minutes you pay for 4 minutes. The live counter in the console ticks up second by second.
The flow
The volume lives independently of the pod. Even if the pod is deleted, /vol stays; a new pod attaches to the same volume. Writing checkpoints to the container disk is the one real mistake.
The marketplace sorts by price, scorecard and region. The default sort is not cheapest but best-scored: price, reliability and network are weighed together. On a long training run that choice matters.
Alongside the org cap you can define a per-pod cap. That is how a trial run is stopped from accidentally spreading over a week.
Log stream, GPU/VRAM/temperature telemetry and the spend counter are on the same screen. The intervals where the health check failed are marked on the chart — unbilled time is visible to the eye.
On an unhealthy node the metering stops, an incident record is written and the job can be moved to another host. Because the volume is unchanged, you resume from the last checkpoint rather than from zero.
When you delete the pod the compute charge ends. If you keep the volume only storage keeps billing, and that row appears separately on the invoice — it is not hidden.
Fictional scenario
The flow below is not a real customer: it is an illustrative example constructed to show how the product works. The figures are examples too.
Choosing a GPU
In fine-tuning, picking a card is a question of fitting before it is a question of speed: do the model, the optimizer state and the activations fit in VRAM? What follows is a rough direction; quantization, LoRA rank, context length and gradient checkpointing all change the table.
| GPU | VRAM | Work it handles comfortably (example) | Example starting price |
|---|---|---|---|
| RTX 4090 | 24 GB | 7B–8B QLoRA, 13B LoRA (short context), diffusion fine-tuning | $0.42/hr |
| RTX A6000 | 48 GB | 13B LoRA comfortably, 7B full fine-tune, long-context experiments | $0.88/hr |
| H100 SXM | 80 GB | 70B QLoRA, 13B full training, serious speed with bf16 | $2.19/hr |
These are example prices and are illustrative; they move with supply and demand in the marketplace. The pool also holds intermediate steps such as the L40S (48 GB) and the A100 PCIe (80 GB) — the full list is on the Pricing page.
The volume is independent of the pod, stored encrypted, and stays when the pod is deleted. Details: Persistent Storage.
Offer search, scorecard score, region pinning and image selection: GPU Pods.
Honest limits
The product is in Phase 0: one account, one API and one invoice on top of provider pools. The list below is today's reality, not an advertisement for the roadmap.
Our phase schedule is written in our technical plan: Phase 0 broker MVP, Phase 1 our own supply, Phase 2 serverless inference, Phase 3 sovereignty and the Verified tier. If a feature says "soon" here, it does not exist today; we do not describe things as present when they are not.
FAQ
No, they are billed. The guarantee covers the health of the infrastructure: if the GPU, driver, network or host goes down, those seconds never enter the bill. If your code OOMs or your script errors out, the GPU is up and running and the charge applies. The exact definition of the boundary will be written in the documentation; rather than hiding this distinction, we write it down.
On the persistent volume, encrypted. Secrets and environment variables never land on the host disk in plain text, images are signed, and the host cannot see inside the container. An audited "Verified" tier for sensitive workloads is a Phase 3 matter.
You do not. When the cap is reached the pod is paused, not deleted: the disk and volume stay in place and you get a notification. You raise the limit and continue where you left off. Storage for the paused pod keeps billing as a separate line item, and that row is visible on the billing screen.
Not today. Multi-GPU training on a single machine works; for distributed training across nodes, the "Clusters" product is on the roadmap and carries a "soon" badge in the nav. We do not make promises without fixing a date.
Because it is a marketplace price: supply is set by hosts and integrated providers, and competition pushes it down. We take a 15% commission on top and write that everywhere. The figures on this site are illustrative; the live ones appear in the console.
Get started
Create a persistent volume, set your cap, pick your card. You don't pay for seconds that don't work — behind that sentence sit a health gate, a refund line item and an incident record.
The console runs on the local development address: localhost:3000