Fine-Tuning Cost Calculator (GPU-Hours vs Managed API)

Because the cost math is the same either way: cost = GPU-hours × hourly price, and GPU-hours come from your dataset size and measured throughput. What LoRA changes is the inputs, not the formula — it updates far fewer weights, so it typically trains at higher tokens/second and fits in much less VRAM, meaning fewer or smaller GPUs. That is why the method selector only updates the suggested throughput and GPU-count defaults: pick LoRA, measure your actual run, and the lower hours and smaller cluster show up in the numbers by themselves.

They are rough, order-of-magnitude starting points — for example ~3,000 tokens/second for an 8B LoRA on one H100, or ~800 tokens/second aggregate for a full 70B fine-tune on 8× H100 — not benchmarks of your workload. Real training throughput moves by multiples with sequence length, batch size, precision (bf16 vs fp8), gradient checkpointing, and how well tensor or data parallelism scales on your interconnect. Run a short timed job on a slice of your data, divide tokens processed by seconds elapsed, and enter that. GPU prices are snapshot rates as of 2026-07 — verify current pricing before committing.

Everything except the compute bill of one successful training run. On the self-managed side it excludes storage and data transfer, cluster setup and babysitting time, failed and repeated runs, hyperparameter sweeps (each sweep is another full run — multiply accordingly), and the engineering hours that often dwarf an $11 GPU bill. On both sides it excludes data preparation and the cost of serving the fine-tuned model afterwards, which usually exceeds training cost over the model's life. Treat the output as the floor of one experiment, not the budget for a fine-tuning project. This is an estimate, not financial advice.