Fine-tuning a 70B model costs roughly $1 to $2 of GPU time per million training tokens, or about $20 for a 20-million-token LoRA run. On Nodus the cheapest setup per token is LoRA on one B200, listed at $5.50/hr, even though one A100 80 GB is a fifth of that hourly price. Treat these as planning numbers from FLOP math at 30% utilization; the real bill depends mostly on how many tokens you train and how many runs you throw away.
How do you estimate the cost of a 70B fine-tune?
Count the math, divide by the speed you will really get, then multiply by the hourly rate. Training a transformer takes about 6 floating-point operations per parameter per token, the rule from Kaplan et al.'s scaling-laws paper: 2 for the forward pass and 4 for the backward pass.
Fine-tuning changes that count in two ways, and this is our arithmetic, not a published benchmark. LoRA freezes the base model, so the backward pass skips the weight gradients for 70 billion parameters and drops from 4 to about 2 operations per parameter. Gradient checkpointing, which is on by default in the Nodus sft runtime and needed at this size, runs the forward pass a second time to save memory. That adds 2 more.
- LoRA and QLoRA: 2 forward + 2 recompute + 2 backward = 6 operations per parameter per token.
- Full fine-tuning: 2 forward + 2 recompute + 4 backward = 8 operations per parameter per token.
Llama 3.3 70B has 70.55 billion parameters, per the weight files on its Hugging Face page. So each training token costs about 423 billion operations with LoRA and 564 billion with full fine-tuning. The formula we use for every number below:
GPU-hours = (ops per param x 70.55e9 x training tokens) / (peak FLOPS x 0.30 x 3,600)
cost = GPU-hours x hourly price per GPU
The 30% is utilization: the share of peak speed a real job sustains. Our LLM training cost post back-solved 25% for Meta's Llama 3.1 70B run and recommends planning at 30% until you measure your own.
Which GPU setups can fine-tune a 70B model?
Memory decides the setup before price does. Our 70B VRAM guide works out the training state for each method with one 4,096-token sequence. It comes to about 50 GB for QLoRA, 152 GB for LoRA, 766 GB for full fine-tuning with 8-bit Adam and 1,189 GB with standard AdamW. That leaves five setups worth pricing.
| Method | Setup | Dense BF16 peak | Listed price per hour |
|---|---|---|---|
| QLoRA | 1 x A100 80 GB | 312 TFLOPS | $1.09 |
| QLoRA | 1 x H100 SXM | 989 TFLOPS | $2.60 |
| LoRA | 1 x B200 | 2,250 TFLOPS | $5.50 |
| Full, AdamW | 8 x B200 | 18,000 TFLOPS | $44.00 |
| Full, 8-bit Adam | 8 x H200 | 7,912 TFLOPS | $28.74 |
Prices checked November 5, 2026 on the Nodus pricing page. Peaks are NVIDIA's dense figures: half the sparse numbers on the A100 and H100 pages, and half of the 36 PFLOPS that the HGX platform page lists for an 8-GPU B200 board. The H200 has the same tensor math as the H100.
What does one 70B fine-tuning run cost?
About $20 for LoRA and $37 for full fine-tuning, on a typical small dataset. Our worked example is 10,000 examples of about 1,000 tokens each, trained for 2 epochs: 20 million training tokens. We add 15 minutes of billed startup per run for pulling the 141 GB of weights and loading them, the same allowance as our Llama on H100 cost post.
| Setup | Hours on the clock | Training cost | With 15 min startup |
|---|---|---|---|
| QLoRA, 1 x A100 80 GB | 25.1 | $27.39 | $27.66 |
| QLoRA, 1 x H100 SXM | 7.9 | $20.61 | $21.26 |
| LoRA, 1 x B200 | 3.5 | $19.16 | $20.54 |
| Full AdamW, 8 x B200 | 0.6 | $25.55 | $36.55 |
| Full 8-bit Adam, 8 x H200 | 1.3 | $37.97 | $45.16 |

Full fine-tuning costs less than twice LoRA in GPU time; startup on eight GPUs is what pushes it up.
Two caveats keep this honest. The QLoRA rows are a floor. QLoRA converts each 4-bit block back to 16-bit for every matrix multiply, and we have not measured that overhead, so expect those runs to take longer. And 30% is a planning figure; at 15% every training cost doubles.
The surprise is how little the method moves the bill. Full fine-tuning does a third more math per token than LoRA, and the B200s are the cheapest math per dollar either way. What full fine-tuning really costs you is memory: eight GPUs instead of one, and a 15-minute startup that bills $11 at $44/hr before the first step.
Why is one B200 cheaper per token than one A100?
Because per-token cost follows the hourly price divided by the GPU's speed, not the hourly price alone. Divide each listed rate by its dense BF16 peak in petaFLOPS and you get what one petaFLOP of peak math costs per hour.

The B200 has the highest hourly rate and the lowest price per unit of math.
The B200 comes out at $2.44, the H100 at $2.63, the A100 80 GB at $3.49 and the H200 at $3.63. That is why the A100 row above costs more despite its $1.09 rate: it is 7.2 times slower than a B200 at peak, and only 5.05 times cheaper per hour. Our LoRA vs QLoRA post gives the same break-even from the other side: QLoRA on an A100 only wins if it finishes in under 5.05 times the B200's hours.
Our rule for 70B: among the setups whose memory fits, pick the lowest price per petaFLOPS, then check that the run is long enough for startup not to matter. The H200 only makes sense for full fine-tuning with 8-bit Adam, where its 141 GB per GPU is what lets eight of them hold the state.
How does the cost grow with more training data?
Linearly, so cost per million training tokens is the number to budget with. At 30% utilization, the five setups cost $0.96 (LoRA, B200), $1.03 (QLoRA, H100), $1.28 (full, 8 x B200), $1.37 (QLoRA, A100) and $1.90 (full, 8 x H200) per million training tokens, before startup.

Startup matters at 20 million tokens; at 500 million it is noise and only the per-token rate counts.
A 100-million-token run costs $97.19 with LoRA on a B200 and $138.75 with full fine-tuning on eight. At 500 million tokens those become $480.44 and $649.76. The gap between methods grows in dollars but stays near the same ratio, because both setups pay the same price per petaFLOPS and differ only in operations per token.
What else ends up on the bill?
The runs you throw away usually cost more than the one you keep. A first 70B fine-tune almost never ships: you try a learning rate, a LoRA rank, a different data mix. If you budget three to five runs, the 20-million-token LoRA project above costs $62 to $103 in GPU time, not $21.
Three other lines are worth planning for:
- Evaluation. Scoring checkpoints on a held-out set means more forward passes, each about a third of a LoRA training step's math per token.
- Lost work. A run that loses its machine without a recent checkpoint pays for the same hours twice. The
sftruntime saves a recovery checkpoint every 200 steps by default (saveSteps), and the job resumes from the last one. - Idle time. A machine left running after training finishes bills at the full rate. A Nodus TrainingJob runs as a Job to completion and releases its GPUs when it ends.
We have not counted storage for datasets and adapters here. A LoRA adapter for a 70B model is small next to the 141 GB base, so the weights you keep add little.
How do you run a 70B LoRA fine-tune on Nodus?
Write a TrainingJob, price it with a dry run, then start it with a cap. This manifest is the LoRA example from the Nodus training guide with Llama 3.3 70B pinned to its current Hugging Face commit and one B200 under resources. Llama weights are gated, so you accept Meta's license on the model page first and store your Hugging Face token as a Secret.
apiVersion: nodus.dev/v1beta1
kind: TrainingJob
metadata:
name: llama-70b-lora
spec:
runtime: nodus/sft
model:
uri: hf://meta-llama/Llama-3.3-70B-Instruct@6f6073b423013f6a7d4d9f39144961bfbfbc386b
secret: hf-token
data:
volume: support-chats
path: chats.jsonl
format: JSONL
columns: {prompt: question, completion: answer}
parameters:
method: LoRA
epochs: 2
lora: {r: 16, alpha: 32}
resources: {gpu: {type: [B200], count: 1}}
maxCostUSD: "30.00"
$ pip install nodus-compute
$ nodus login
$ nodus apply -f sft.yaml --dry-run -o yaml
$ nodus apply -f sft.yaml
TrainingJobs are Beta, and we have not run this exact manifest, so read the dry run's estimate before you start. maxCostUSD suspends the run at a checkpoint if spending reaches the cap, and raising the cap resumes the same run. Once it trains, nodus describe tj/llama-70b-lora shows real throughput. Put that number into the formula above in place of the 30% guess.
FAQ
Can you fine-tune a 70B model for under $10?
Not with a useful dataset at list rates. At about $1 per million training tokens, $10 buys roughly 10 million tokens on a B200 before startup, which is 5,000 examples of 1,000 tokens for 2 epochs. That can be enough for a narrow format or style task.
Is it cheaper to fine-tune a 70B model or an 8B model?
The 8B model, by close to 9 times per token, since the math scales with parameter count. Fine-tune the 8B first. Move to 70B only if the 8B result misses your quality bar on held-out examples.
How do you get a real cost estimate before the run starts?
The Nodus dry run multiplies your steps by the runtime's measured seconds per step on the slowest GPU type you allowed. For a GPU without a published step time, set spec.expectedDuration to your own figure, such as the hours from the formula in this post.
Should you use spot capacity for a 70B fine-tune?
Only if a lost machine costs you minutes, which frequent checkpoints make possible. On Nodus a compatible single-host TrainingJob can set placement.interruptible: Allow and resume from its last recovery checkpoint. Jobs that need a Secret, such as gated Llama weights pulled with a token, stay on dedicated capacity.
Originally published on the Nodus blog.
Top comments (0)