# Fine-Tuning GPU-Hours Estimator: Compare Methods Side by Side

> Source: https://netray.co/tools/fine-tuning-gpu-hours-estimator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Estimate GPU-hours for LoRA, QLoRA, and full fine-tuning on the same model size and dataset, so you can compare method tradeoffs before choosing.

## Category

on-prem-ai

## Tool

**Kind:** calculator

**Inputs:**

#### Model size

**Key:** model_params_b

**Type:** number

**Default:** 14

**Min:** 0.5

**Max:** 405

**Step:** 0.5

**Unit:** B params

**Help:** Total parameters of the base model, or active parameters per token for mixture-of-experts models.

#### Dataset size

**Key:** dataset_tokens_m

**Type:** number

**Default:** 15

**Min:** 0.1

**Max:** 2000

**Step:** 0.5

**Unit:** M tokens

**Help:** Total training tokens before epoch multiplication.

#### Training epochs

**Key:** epochs

**Type:** number

**Default:** 3

**Min:** 1

**Max:** 10

**Step:** 1

**Unit:** epochs

#### Fine-tuning method

**Key:** method

**Type:** select

**Default:** 1

**Unit:** method

**Help:** Method determines the effective throughput multiplier used to estimate GPU-hours for this run.

**Options:**

##### LoRA (fastest, lowest memory)

**Value:** 1

##### QLoRA (slightly slower, lowest VRAM)

**Value:** 0.8

##### Full fine-tuning (slowest, highest memory)

**Value:** 0.25

#### Reference throughput (LoRA baseline)

**Key:** base_tokens_per_sec

**Type:** number

**Default:** 3200

**Min:** 200

**Max:** 40000

**Step:** 100

**Unit:** tokens/sec

**Help:** Achieved LoRA tokens per second per GPU at this model size on your target hardware. Other methods are scaled from this baseline.

#### GPU hourly rate

**Key:** gpu_hourly_rate

**Type:** select

**Default:** 3.5

**Unit:** $/hr

**Help:** Rented or amortized hourly cost per GPU.

**Options:**

##### A100 80GB ($2.00/hr)

**Value:** 2

##### H100 80GB ($3.50/hr)

**Value:** 3.5

##### H200 141GB ($4.50/hr)

**Value:** 4.5

**Outputs:**

#### Effective throughput for selected method

**Key:** effective_tokens_per_sec

**Expr:** base_tokens_per_sec * method

**Format:** number

**Description:** LoRA baseline throughput scaled by the selected method's relative speed.

#### Total tokens processed

**Key:** total_tokens

**Expr:** dataset_tokens_m * 1000000 * epochs

**Format:** number

**Description:** Dataset tokens times epochs, the actual training workload.

#### GPU-hours required

**Key:** gpu_hours

**Expr:** total_tokens / max(effective_tokens_per_sec, 1) / 3600

**Format:** hours

**Description:** GPU-hours for the selected method at this model size and dataset.

**Primary:** true

#### Total training cost

**Key:** training_cost

**Expr:** gpu_hours * gpu_hourly_rate

**Format:** currency

**Description:** GPU-hours multiplied by your hourly rate for the selected method.

**Primary:** true

#### Cost per million tokens trained

**Key:** cost_per_1m_tokens

**Expr:** training_cost / max(total_tokens / 1000000, 1)

**Format:** currency

**Description:** Unit cost for comparing across dataset sizes or future runs.

**Disclaimer:** Directional estimates. Change the method selector and rerun to compare LoRA, QLoRA, and full fine-tuning GPU-hours for the same job. Validate throughput with a short real benchmark before committing to a budget.

## Content

**Intro:** This free fine-tuning GPU-hours estimator lets you compare LoRA, QLoRA, and full fine-tuning GPU-hour requirements for the identical model size and dataset by switching a single method selector, and it is built for engineering leads who need a quick side-by-side before choosing a training approach. Enter model size, dataset tokens, epochs, and your LoRA baseline throughput, then toggle between methods to see how GPU-hours and cost scale. Running the same scenario through all three methods in a few clicks is the fastest way to see why LoRA and QLoRA dominate enterprise fine-tuning: the GPU-hour gap compounds with every additional epoch and every added billion parameters.

**Sections:**

#### How the method multiplier works

**Body:** Rather than modeling each method's memory architecture in full detail, this tool uses a relative throughput multiplier calibrated against real Axolotl and Unsloth benchmark data: LoRA is the 1.0x baseline, QLoRA runs at roughly 0.8x LoRA throughput due to the added overhead of dequantizing 4-bit weights on the fly during the forward pass, and full fine-tuning runs at roughly 0.25x due to the much larger memory traffic from updating every parameter's gradient and optimizer state. Enter your measured LoRA throughput once, then switch the method selector to see GPU-hours and cost recalculate instantly for the other two approaches on the identical workload.

**Bullets:**

- LoRA is the fastest and cheapest method for the large majority of enterprise fine-tuning tasks.
- QLoRA trades roughly 20% throughput for a 4x reduction in base model memory footprint.
- Full fine-tuning runs at roughly a quarter of LoRA throughput per GPU, before accounting for the extra GPUs it typically requires.
- The gap widens with every added epoch, since slower per-token throughput compounds across the full training run.

#### Reading the comparison

**Body:** Run your scenario once per method and note the GPU-hours for each. For most instruction fine-tuning and domain adaptation tasks at the 7B-70B scale, the LoRA and QLoRA numbers will differ by single-digit dollars while full fine-tuning differs by an order of magnitude, especially once you also account for full fine-tuning's typical multi-GPU requirement, which this simplified single-GPU-rate comparison does not even fully capture. That gap is the concrete number to bring into a build decision: unless you have specific evidence that a lower-capacity adapter method underperforms on your task, defaulting to LoRA or QLoRA is the financially disciplined choice.

#### What this estimator does not model

**Body:** This tool assumes a single GPU serves the job; for full fine-tuning at 13B parameters and above, add the multi-GPU cost multiplier from the QLoRA versus full fine-tuning calculator, since that method typically requires 4-8 GPUs working in parallel rather than one. It also does not model evaluation runs, checkpoint saving overhead, or the iteration cost of running a method multiple times to tune hyperparameters, all of which add 15-30% in practice. Use this tool for the relative comparison between methods, and use the dedicated LoRA and QLoRA calculators for a more complete absolute cost estimate once you have picked a method.

#### How Netray picks a fine-tuning method for each engagement

**Body:** Netray defaults to LoRA or QLoRA for essentially every fine-tuning engagement with aerospace, defense, and electronics manufacturing clients, and we run exactly this kind of side-by-side comparison during scoping so the client sees the cost tradeoff in concrete dollars rather than an abstract recommendation. Full fine-tuning appears in our engagements only when a documented evaluation gap demonstrates that adapter-based methods have plateaued below the required quality bar, which in practice is a small minority of projects.

**Cta:** Get a side-by-side method comparison for your specific model and dataset, with a hardware and budget recommendation.

**Faq:**

#### Why does QLoRA run slower than LoRA if it uses less memory?

**Answer:** QLoRA stores the frozen base model weights in 4-bit precision to save memory, but must dequantize them back to a higher precision on the fly during every forward and backward pass to perform the actual matrix multiplication. That dequantization step adds computational overhead that plain LoRA, which keeps weights in 16-bit precision throughout, does not incur. The tradeoff is deliberate: QLoRA sacrifices roughly 15-25% throughput to unlock training on hardware that could not otherwise fit the model at all.

#### Should I always trust the 0.25x multiplier for full fine-tuning?

**Answer:** Treat it as a starting estimate, not a guarantee. The real multiplier depends heavily on your sharding strategy, DeepSpeed ZeRO stage or FSDP configuration, and interconnect bandwidth between GPUs. Poorly configured multi-GPU full fine-tuning can run far slower than 0.25x of LoRA baseline due to communication overhead, while a well-tuned setup on fast interconnect might do somewhat better. Always benchmark a few hundred steps of your actual configuration before trusting any multiplier for a full budget commitment.

#### Does this tool account for the extra GPUs full fine-tuning needs?

**Answer:** Not automatically, since it reports GPU-hours per method assuming the same GPU count for a direct throughput comparison. To get a realistic total cost for full fine-tuning, multiply the resulting GPU-hours by the number of GPUs your model size actually requires, typically 4-8 for a 13B-70B model, since full fine-tuning's memory requirements force a multi-GPU cluster that LoRA and QLoRA usually do not need. The QLoRA versus full fine-tuning calculator models that multi-GPU cost explicitly.

## Search terms

fine-tuning GPU hours calculator, LoRA QLoRA full fine-tuning comparison, GPU hours estimator LLM training, fine-tuning method comparison calculator, training time estimator LLM, Axolotl GPU hours, fine-tuning compute planning

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json