RunPod and Lambda Labs sell the same unit — dollars per GPU-hour on a named card — so the rate card is the least interesting part of the comparison. At the median rates behind the estimate model, an 8B QLoRA run of 22.5M training tokens is 1.0 GPU-hours on an H100 and costs $2.73; a 15% difference in the hourly rate is 41 cents on that run. Twenty minutes of cold start on the same card is 90 cents, a third of the run. What separates the two is mostly that second number.
Every rate below is an assumption from the same estimate model that drives the cost calculator, not a quote from either vendor. Neither vendor’s list price is reproduced here, because both change and a stale figure is worse than a variable: substitute their current rate into the same arithmetic and the tables hold.
Price per GPU-hour
Both vendors bill an hourly rate for a named card, so price per GPU-hour is not a differentiator on its own; the difference is pool structure. RunPod sells two pools: a community pool on third-party hosts and a datacentre pool. Lambda sells one datacentre pool with on-demand and reserved terms. The cheapest rate on each side is therefore not the same product, and comparing them in one table — a community-hosted card against a racked datacentre card — is the most common mistake in this decision.
Held to the median rate for the same card, here is what a run actually costs. The run is 5,000 examples at 1,500 tokens over 3 epochs, QLoRA rank 16 at 2,048-token sequences, batch 1, gradient checkpointing on.
| Run | Card | Fits | GPU-hours | Cost at median rate |
|---|---|---|---|---|
| 8B QLoRA, 22.5M tokens | RTX 4090 24GB | yes | 6.08 | $2.68 |
| 8B QLoRA, 22.5M tokens | A100 40GB | yes | 3.22 | $3.83 |
| 8B QLoRA, 22.5M tokens | A100 80GB | yes | 3.22 | $5.12 |
| 8B QLoRA, 22.5M tokens | H100 80GB | yes | 1.01 | $2.73 |
| 32B QLoRA, 22.5M tokens | RTX 4090 24GB | yes | 24.85 | $10.93 |
| 32B QLoRA, 22.5M tokens | A100 80GB | yes | 13.14 | $20.89 |
| 32B QLoRA, 22.5M tokens | H100 80GB | yes | 4.15 | $11.15 |
| 70B QLoRA, 22.5M tokens | A100 80GB | yes | 28.29 | $44.97 |
| 70B QLoRA, 22.5M tokens | H100 80GB | yes | 8.92 | $24.00 |
Two things fall out of that table and they matter more than either vendor’s rate. First, the card decides the run: 70B QLoRA needs 44.3GB of VRAM, so an A100 40GB is not a candidate at any price. Second, the per-token cost is not the per-hour cost: the A100 80GB is $0.227 per million training tokens on an 8B job where an RTX 4090 is $0.119, nearly twice the price for a card that is nominally the premium option.
The rate only starts to matter at scale. A 15% difference on a 6-hour 8B run is $0.40; on the 28-hour 70B run it is $6.75, worth an hour of comparison shopping. Work out your hours in the cost calculator before you compare vendors, because the answer usually barely depends on the vendor.
One more check before comparing anything: confirm both catalogues actually list the card you want. The 24GB tier covered on the 24GB GPU page mixes consumer cards with small datacentre parts, and not every provider stocks all of them. If only one side has the card, the comparison is over.
Availability and cold starts
The meter starts before your first training step, and on a short run the startup is a meaningful fraction of the bill. A cold start has three parts: instance boot and container image pull, model download, and dataset upload. Only the last is small.
Put numbers on it. Llama 3.1 70B in bf16 is 141GB of weights; over a 1 Gbps link that is about 19 minutes of transfer, and over 500 Mbps about 39 minutes. On an H100 at a $2.69 median rate, that is $0.90 to $1.75 of idle card against a $24 run — 4% to 7% for downloading weights you did not change. An 8B model in bf16 is 16GB, roughly 2.2 minutes at 1 Gbps.
The fix is the same on either platform: keep the weights and dataset on a persistent volume in the region where you rent, and mount them, so a cold start is a mount rather than a download. That is the largest setup-friction item here, and it is a property of your workflow rather than of the vendor.
Capacity is the part you cannot engineer around: both pools have variable availability, and the scarce cards are the same on both sides. Measure it yourself — pick the card and the hour you would really run at, start the same job three times, and record the wait from instance request to first optimiser step, including failed requests. Three attempts tell you more than an availability page, because availability is per-hour and the page you read at 10am says nothing about 2am.
If the run is long, treat capacity the way you would treat spot: checkpoint every N steps and keep a resume path. On a 28-hour 70B run, an eviction with no checkpoint is a $45 loss, which dwarfs every rate difference in this article.
Storage and persistence
Storage is rent, and the unit that decides the bill is GB-months, not GB. What you keep determines it, and for fine-tuning the answer should be very little.
| Artefact | Size | Keep it? |
|---|---|---|
| LoRA adapter, 8B, rank 16 | 32 MB | yes |
| LoRA adapter, 32B, rank 16 | 131 MB | yes |
| LoRA adapter, 70B, rank 16 | 282 MB | yes |
| Merged 8B weights, bf16 | 16.1 GB | only if you serve from it |
| Merged 70B weights, bf16 | 141 GB | only if you serve from it |
| Dataset, 50k examples × 1,500 tokens | ~0.4 GB as JSONL | yes |
The ratio is the argument: an adapter is 32MB and a merged 8B model is 16.1GB, so keeping every adapter you ever trained costs less than one merged checkpoint. Merged weights are worth storing only where you serve from them.
The line to read carefully on either pricing page is what happens to storage when the instance stops. Whether a stopped instance keeps its disk, whether that disk is billed while nothing runs, and whether local NVMe is wiped on terminate are three different questions, and getting them wrong is how a $3 run leaves a monthly charge behind. The pattern that works on both: persistent volume for the model and dataset, local disk for checkpoints you download and delete, and an explicit teardown step at the end of the job.
Egress is asymmetric in the same way it is everywhere. Pulling a 282MB adapter out is nothing. Pulling a merged 70B model is 141GB out, and that is a line item on the invoice.
Which to pick for a first run
Pick on the card and the cold start; the hourly rate is the tiebreaker, not the criterion.
- One 8B or 32B run, under $25 total. Either vendor, whichever has the card available now. The 32B run is 24.85 GPU-hours on a 4090 and 13.14 on an A100 80GB, so the card choice moves the bill by 2× and the vendor choice by cents.
- Weekly or repeated runs of the same config. Pick on persistence and automation — a mounted volume, a script that starts the job and shuts the instance down. At six hours per run a 15% rate difference is $0.40; re-uploading a model every week is $0.90 each time.
- 70B, or anything that needs more than 48GB. The card decides: 44.3GB of VRAM at rank 16 leaves 80GB cards as the sane target, and an H100 turns the job in 8.92 GPU-hours for $24 against 28.29 hours and $45 on an A100 80GB. Compare vendors only after the card is fixed.
- Compliance, invoicing or an existing datacentre relationship. One pool is easier to reason about than a two-pool catalogue, even at a higher rate.
The default that survives all four: for 8B to 32B QLoRA, rent the cheapest 24GB or 48GB card that fits your sequence length, mount your weights, checkpoint every N steps, and stop the instance the moment the run ends. The vendor question gets interesting when runs are long enough that an eviction, a cold start or a storage line can cost more than the compute. The cheapest GPU cloud page prices the storage and interruption lines in more detail, and the A100 vs H100 comparison covers the card decision that dominates this one.