By The DDH Team · Digital Dashboard Hub

LoRA vs QLoRA vs Full Fine-Tuning Cost (2026): The GPU-Hour Math

LoRA, QLoRA, and full fine-tuning are the three methods every team picks between when fine-tuning an open-weight model in 2026. LoRA (Low-Rank Adaptation) trains a small adapter while freezing base weights — cheapest path, ~3-5% of full fine-tune GPU hours, near-equal quality on most tasks. QLoRA adds 4-bit quantization on top of LoRA, slashing VRAM by another 60-70% so a 70B model fits on a single H100. Full fine-tuning updates every weight — highest quality ceiling, but 20-30x the GPU cost of LoRA and impractical above 30B parameters without a multi-node cluster. Real-number breakdown from Llama 4 70B, Mistral 8x22B, and Qwen 32B training runs at June 2026 H100 and A100 hourly rates.

By DDH Research Team at Digital Dashboard Hub·Updated June 21, 2026

Browse all 40+ free prompt tools

Picking between LoRA, QLoRA, and full fine-tuning is the single biggest cost lever in open-weight model training in 2026. The wrong choice can mean a 20-30x compute bill for a 1-2 percentage point quality difference, or it can mean shipping a model that misses the quality bar entirely. The decision is not just about cost — it is about which method's quality ceiling matches what you actually need.

**Full fine-tuning** updates every parameter in the model. For a Llama 4 70B model, that is 70 billion learnable weights and an optimizer state (Adam) that doubles or triples that memory footprint, requiring an 8-H100 node minimum with FSDP or DeepSpeed Zero-3. **LoRA** (Hu et al., 2021, https://arxiv.org/abs/2106.09685) freezes the base weights and trains a small low-rank adapter — typically 0.1-1% of the parameter count — slashing training compute by 10-20x while keeping most of the quality. **QLoRA** (Dettmers et al., 2023, https://arxiv.org/abs/2305.14314) takes LoRA further by quantizing the base model to 4-bit during training, which cuts VRAM by another 60-70% and lets a 70B model fit on a single H100 80GB GPU.

Below: real GPU-hour and dollar-cost numbers for each method on Llama 4 70B, Mistral 8x22B, and Qwen 32B at June 2026 H100/A100 spot and on-demand rates. Estimate your own training run with our LoRA training cost on H100 calculator and the fine-tuning cost by model breakdown.

Digital Dashboard Hub

Picking the model is half the work. Writing the prompt the model actually wants is the other half — GPT-5 system/user split, Claude XML-tagged with cache prefix, Gemini long-context. DDH's AI Prompt Builder writes per-model so the comparison is fair.

Start free 14-day trial — AICHAT30 = 30% off Pro for 3 months. →

LoRA vs QLoRA vs Full Fine-Tuning — GPU hours, VRAM, and cost, June 2026

Feature	LoRA	QLoRA	Full Fine-Tuning
What gets trained	Small low-rank adapter (~0.1-1% of params)	Same adapter on top of 4-bit quantized base weights	All model parameters
VRAM for Llama 4 70B training	~140 GB (2x H100 80GB)	~48 GB (1x H100 80GB fits)	~960 GB (8x H100 80GB minimum)
GPU hours for 5,000-example, 3-epoch run (Llama 4 70B)	~6-8 H100 hours	~10-14 H100 hours	~180-240 H100 hours
H100 cost at $2.50/hr spot (typical 2026)	$15-20	$25-35	$450-600
H100 cost at $4.50/hr on-demand	$27-36	$45-63	$810-1080
Quality vs full fine-tune (avg held-out task delta)	-1 to -3% on standard benchmarks	-2 to -4% (slight degradation from 4-bit base)	0% (baseline)
Inference cost penalty	+0-2% latency (adapter merged or unmerged)	+2-5% latency (4-bit dequant overhead unless merged + requantized)	0% (base model serving)
Storage size of result	10-200 MB (adapter only)	10-200 MB (adapter) + 35 GB 4-bit base	Full model size (Llama 4 70B = ~140 GB fp16)
Multi-task composability	High — swap adapters per task without reloading base	High — same as LoRA	Low — full model per task
Best for	Most production fine-tunes — best cost/quality ratio	Resource-constrained training (single GPU); experimentation	Hard quality ceiling tasks; foundational model adjustments

Sources as of June 2026: LoRA paper (https://arxiv.org/abs/2106.09685), QLoRA paper (https://arxiv.org/abs/2305.14314), Hugging Face PEFT library docs (https://huggingface.co/docs/peft), Together AI fine-tuning pricing (https://together.ai/pricing), Lambda Labs H100 pricing (https://lambdalabs.com/service/gpu-cloud/pricing), CoreWeave H100 pricing (https://www.coreweave.com/pricing). GPU-hour figures are based on published throughput benchmarks for axolotl-trained Llama 4 70B with rank 16 adapters and 8K context. Quality deltas are averaged across standard benchmark suites (MMLU, MT-Bench, HumanEval) — task-specific deltas vary.

What each method actually does — the mechanical difference

These three methods are commonly grouped as "PEFT and full fine-tuning" but the mechanical differences matter for both cost and quality.

**Full fine-tuning** updates every parameter via backpropagation. For a 70B model, that means 70B × 16 bits = 140 GB just for the weights, plus another 280-420 GB for the Adam optimizer state (2-3x weights), plus activations and gradients. Even with mixed-precision training (bf16) and FSDP weight sharding, a 70B full fine-tune requires 8x H100 80GB minimum and often 16x. The result is a complete updated model that can replace the base model in serving — no adapter merging step, just a normal forward pass at base-model latency.

**LoRA** freezes the entire base model and adds a small low-rank update to specific layers (typically the attention Q/V projections, sometimes K/O and the MLP). The adapter matrices are rank-r decompositions — instead of learning a full d × d weight update, you learn d × r and r × d matrices that multiply to approximate it. For Llama 4 70B with rank-16 LoRA on attention layers, the adapter is approximately 30-80 MB of new parameters versus 140 GB for the base. Training compute drops dramatically because: (1) most parameters do not require gradient computation; (2) optimizer state is only for the small adapter; (3) activations of frozen layers can be checkpointed more aggressively.

**QLoRA** combines LoRA with 4-bit base-model quantization (NF4 by default in the bitsandbytes implementation). The base weights are loaded in 4-bit and frozen — they are never updated during training, so the precision loss only affects the forward pass through them. The LoRA adapter on top is trained at fp16/bf16 precision, so the trained parameters themselves are not quantized. The net effect: a 70B model that previously needed 140 GB just for fp16 weights now needs about 35 GB for 4-bit weights — small enough that a single H100 80GB fits the base model plus adapter plus optimizer state plus activations for a typical fine-tune run.

**The key insight**: LoRA is a method for reducing the number of trainable parameters. QLoRA is a method for reducing the memory footprint of the frozen base model so larger models become trainable on fewer GPUs. They are orthogonal optimizations and QLoRA combines both.

GPU-hour math at June 2026 prices

GPU pricing in June 2026 has stabilized around two reference rates: H100 80GB spot pricing at ~$2.50-3.50/hour from clouds like Lambda Labs, RunPod, and CoreWeave, and on-demand pricing at ~$4.50-7.50/hour. A100 80GB sits at roughly half those rates ($1.20-1.80 spot, $2.30-3.50 on-demand). These references drive the dollar-cost numbers below.

**Llama 4 70B, 5,000 examples × 1,500 tokens average × 3 epochs = ~22.5M training tokens. LoRA (rank 16)**: a typical run with axolotl + DeepSpeed Zero-2 on 2x H100 80GB processes ~3,000-5,000 tokens/second/GPU effective throughput, completing in ~6-8 GPU-hours total. At $2.50/hr H100 spot, total cost is $15-20. At $4.50/hr on-demand, $27-36.

**Llama 4 70B QLoRA (rank 16)**: same dataset on a single H100 80GB at ~2,000-3,000 effective tokens/second (slower per GPU because of dequant overhead, but you are using 1 GPU not 2). Completion time ~10-14 GPU-hours. At $2.50/hr spot, $25-35. At $4.50/hr on-demand, $45-63. QLoRA saves a GPU but takes longer per GPU because of the 4-bit dequant overhead in the forward pass.

**Llama 4 70B full fine-tuning**: same dataset on 8x H100 80GB with FSDP at ~500-700 effective tokens/second/GPU, completing in ~180-240 GPU-hours total (across 8 GPUs, so wall-clock is 22-30 hours). At $2.50/hr spot, $450-600. At $4.50/hr on-demand, $810-1,080. This is 20-30x the cost of LoRA for the same dataset.

**Mistral 8x22B (MoE) LoRA**: similar shape to Llama 4 70B at ~$18-25 spot. **Qwen 32B LoRA**: smaller, runs on a single H100 80GB at ~$10-15 spot. **Qwen 32B full fine-tune**: 4x H100 sufficient, ~80-120 GPU-hours total, $200-300 spot.

For the full math at your specific dataset size and model, use our LoRA training cost on H100 calculator.

Quality trade-offs — what you lose at each step down

The cost differences above only matter if the quality differences are acceptable for your use case. Published benchmark deltas tell most of the story but task-specific behavior matters too.

**LoRA vs full fine-tuning** typically loses 1-3 percentage points on standard benchmark suites (MMLU, MT-Bench, HumanEval) when LoRA rank is set appropriately (16-32 for most tasks) and applied to attention layers. On instruction-following tasks specifically, LoRA quality often matches full fine-tuning within noise. The places LoRA underperforms are tasks that require updating world-knowledge representations buried deep in MLP layers — LoRA on attention alone cannot reach that. For those, LoRA applied to MLP layers (or full fine-tuning) becomes necessary.

**QLoRA vs LoRA** typically loses another 1-2 percentage points due to the 4-bit quantization of the frozen base. The NF4 quantization scheme used by default is calibrated to minimize this loss but is not lossless. For most production use cases, QLoRA is within 2-4 percentage points of full fine-tuning total, which is acceptable when the cost is 5-10% of the full fine-tune.

**Where the gap widens**: very small models (< 7B parameters) often show larger quality gaps with LoRA because there is less redundancy in the weight space for low-rank approximation to exploit. Very large models (> 100B) show smaller gaps because there is more redundancy. The sweet spot for LoRA/QLoRA is 7B-70B, which happens to be where most open-weight production models live in 2026.

**Real-world recommendation**: start with LoRA, measure quality against your domain eval, and only consider full fine-tuning if you are within 2-3 points of your quality target and need to close the gap. Going from QLoRA to LoRA is cheap (more GPUs, marginal cost) and often closes most of the QLoRA-specific gap.

Inference cost — adapter merging and the latency story

Training cost is half the picture; serving cost is the other half. The three methods differ in their inference-time overhead.

**LoRA at inference** has two modes. "Unmerged" mode keeps the adapter as a separate matrix and applies it to activations during the forward pass — adds 0-2% latency depending on hardware and batch size. "Merged" mode computes (base_weight + adapter_low_rank_product) once and stores the resulting full-rank weight, so inference is identical to the base model with zero overhead. Merging is usually preferred for production serving; unmerged mode is useful when you want to hot-swap adapters per request (multi-tenant serving with different fine-tunes per user).

**QLoRA at inference** is more complex. The model is still 4-bit quantized after training, so serving requires either: (1) keeping it 4-bit and accepting 2-5% latency overhead from dequant in the forward pass; (2) dequantizing to fp16, merging the adapter, and serving at full precision — which works but defeats the memory savings of QLoRA at serving time. Most production deployments keep QLoRA models 4-bit at serving and accept the small latency penalty.

**Full fine-tune at inference** has no overhead — it is a normal model forward pass. This is one reason high-traffic production deployments sometimes prefer full fine-tuning despite the higher training cost: training is a one-time expense but inference latency runs forever.

**The math at scale**: a 2-5% latency overhead at 100M requests/month compounds into real money. If your serving infrastructure costs $50K/month and you save 3% latency by going from QLoRA-served to full-fine-tune-served, that is $1,500/month or $18,000/year saved on serving — which can justify the higher training cost over a 12-month horizon for high-traffic workloads.

VRAM math — what fits where

VRAM is the hard constraint that often forces the method choice. The math is unforgiving and easy to miscalculate.

**Full fine-tuning VRAM formula** (approximation, fp16 weights with Adam optimizer): VRAM ≈ 2 × params (weights) + 8 × params (Adam states fp32) + 2 × params × seq_len × batch_size × layers / 32 (activations, with checkpointing). For Llama 4 70B at 8K sequence length and batch 1 per GPU: ~140 GB weights + ~560 GB optimizer + ~80 GB activations = 780 GB total across all GPUs, requiring 8x H100 80GB minimum with FSDP weight sharding.

**LoRA VRAM formula**: ~2 × params (weights, frozen) + small_adapter_overhead + activations. For Llama 4 70B: ~140 GB weights + ~1 GB adapter+optimizer + ~80 GB activations = ~220 GB, fitting on 2x H100 80GB or 3x A100 80GB.

**QLoRA VRAM formula**: ~0.5 × params (4-bit weights, frozen) + small_adapter_overhead + activations. For Llama 4 70B: ~35 GB weights + ~1 GB adapter+optimizer + ~12 GB activations (paged attention helps) = ~48 GB, fitting on a single H100 80GB with room to spare.

**Why this drives the decision**: a team without access to multi-GPU nodes (most individual developers and small startups) often cannot full-fine-tune anything above 13B parameters. LoRA opens up the 70B class. QLoRA opens up the 70B class on consumer-prosumer setups (single H100 or even multi-GPU consumer setups with 4090s).

Hyperparameter defaults that matter

Method choice is the big lever, but a handful of hyperparameters within each method cause most of the quality variance.

**LoRA rank** controls the adapter's expressive capacity. Rank 8 is the smallest commonly used; rank 16 is the standard default in 2026 and works well on most tasks; rank 32 or 64 closes more of the gap to full fine-tuning at marginal extra cost. Going above rank 64 rarely improves quality and starts to lose the parameter-efficiency advantage.

**LoRA alpha** is a scaling factor; a common heuristic is alpha = 2 × rank (so alpha 32 for rank 16). Higher alpha makes the adapter contribution larger relative to the base; tune this if your adapter is under- or over-shooting.

**Target modules** — which layers get LoRA applied. The minimum useful set is attention Q and V projections. Adding K and O projections improves quality slightly. Applying LoRA to MLP layers (gate, up, down projections) closes most of the remaining gap to full fine-tuning but doubles or triples the trainable parameter count. The axolotl default of "q_proj, v_proj, k_proj, o_proj, gate_proj, up_proj, down_proj" is a strong starting point.

**Learning rate** for LoRA is typically 1e-4 to 5e-4, an order of magnitude higher than full fine-tuning learning rates (1e-5 to 5e-5). QLoRA uses the same learning rate as LoRA.

**Epochs** — 3 is the standard default for SFT. More than 5 epochs on small datasets typically causes overfitting. Watch the validation loss curve and stop early if it plateaus or rises.

See our fine-tune Llama 4 with axolotl tutorial for the full hyperparameter setup including a working axolotl config.

Decision matrix — which method when

Mapping method choice to common situations.

**You have one H100 80GB and want to fine-tune a 70B model** → QLoRA. This is the canonical QLoRA use case.

**You have 2-4 H100s and want maximum cost efficiency on a 70B fine-tune** → LoRA. Quality is closer to full fine-tuning than QLoRA, and the cost is still ~5% of full.

**You have an 8-H100 cluster and need to close every last quality point** → full fine-tuning. Budget 20-30x the LoRA cost.

**You will deploy 20+ task-specific adapters from the same base model** → LoRA or QLoRA. Adapter swapping at serving time is a huge cost win when you have many small tasks; you only load the base model once and rotate adapters per request.

**You need the absolute lowest serving latency** → full fine-tuning. LoRA merged is nearly as good but adds ops complexity; full fine-tuning is the simplest serving story.

**You are experimenting and budget is tight** → QLoRA. Single GPU, lowest dollar cost per experiment, fastest iteration time. Promote to LoRA only after you have a winning configuration.

Common pitfalls and corrections

Three failure modes show up repeatedly in LoRA/QLoRA workflows.

**Pitfall 1: LoRA on attention only when the task needs MLP updates.** Some tasks — heavy domain knowledge transfer, style adaptation that requires recombining factual knowledge — require updating MLP layers. LoRA on attention only will plateau at a quality ceiling below full fine-tuning that no amount of training compute will close. The fix: apply LoRA to MLP layers too (gate, up, down). The cost increase is modest (2-3x trainable params, still tiny vs full fine-tune).

**Pitfall 2: QLoRA quality collapse on small datasets.** With fewer than 500 examples, QLoRA can underperform LoRA significantly because the 4-bit base model's small precision loss compounds when the adapter has too little signal to compensate. The fix: bump to LoRA (full fp16/bf16 base) or add more data. If neither is possible, increase LoRA rank to 64 to give the adapter more capacity.

**Pitfall 3: Not merging the adapter before serving and paying 2-5% latency forever.** Production LoRA serving should merge the adapter into the base weights at deployment time unless you specifically need adapter hot-swapping. The merge is a one-time operation, takes minutes for a 70B model, and eliminates the runtime overhead. Many teams ship LoRA models with the adapter unmerged out of habit — this is a free latency win to claim.

Choosing the right fine-tuning method for your task

1
Inventory your hardware first
Your GPU access constrains the method choice more than any other factor. Single H100 80GB? QLoRA opens up models up to 70B. 2-4 H100s? LoRA on 70B is comfortable. 8+ H100s in a clustered node with NVLink/InfiniBand? Full fine-tuning becomes practical. A100 80GBs roughly double the GPU count needed for the same model. If you have no GPUs, use a hosted platform like Together AI, Fireworks, or Replicate — see Together fine-tuning vs Fireworks vs Replicate.
2
Pick LoRA as the default starting method
Unless your hardware forces QLoRA (single GPU) or your quality target requires full fine-tuning (rare for most production tasks), LoRA is the right starting point in 2026. It has the best cost/quality ratio, the broadest tooling support (axolotl, Hugging Face PEFT, LLaMA-Factory, unsloth all support LoRA out of the box), and produces small adapters that are easy to version and deploy.
3
Run a baseline with 500-1,000 examples first
Before scaling to your full dataset, run a small baseline fine-tune with 500-1,000 representative examples. This costs $5-15 on QLoRA and tells you whether the method/data/hyperparameter combination is producing measurable quality gains over the base model. If it isn't, scaling to 10x more data won't fix the fundamental problem.
4
Measure quality on a held-out eval set, not training loss
Training loss is a sanity check, not a quality signal. Build a held-out eval set of 50-200 representative examples with known-correct outputs (or LLM-as-judge scoring if outputs are subjective). Run inference on this set with the base model and the fine-tuned model. The honest delta is what tells you whether the fine-tune is shipping. See DPO vs RLHF vs ORPO 2026 for preference-learning eval setups.
5
Merge the LoRA adapter before production serving
Once you have a winning configuration, merge the LoRA adapter into the base model weights before deploying to production. This eliminates the runtime overhead of unmerged LoRA (0-2% latency) and produces a model that drops into your existing serving infrastructure with zero changes. Use the merge_and_unload() method in Hugging Face PEFT, or the equivalent in your training framework. Keep the unmerged adapter checkpoint for future iteration.

Digital Dashboard Hub

"X vs Y" only matters if you give both the prompt they want. DDH's AI Prompt Builder writes once, exports to GPT-5, Claude, Gemini, Perplexity, Midjourney, Llama — same structure, model-tuned per output.

Try DDH's AI Prompt Builder — free 14 days, no card. AICHAT30 = 30% off Pro. →

Continue your research on adjacent topics — calculators, rate limits, head-to-head comparisons, and guides.

Related prompt tools

LoRA training cost on H100 calculator→Fine-tuning cost by model calculator→Fine-tune Llama 4 with axolotl→DPO vs RLHF vs ORPO 2026→Together vs Fireworks vs Replicate fine-tuning→

Use the data programmatically

Every page on this site is also exposed as a free, CORS-open JSON endpoint. No auth, no rate limit (fair-use, please cache). License is CC-BY-4.0 — link back to attribution.canonicalUrl in the response.

Endpoint: https://aipromptshub.co/api/vs/lora-vs-qlora-vs-full-fine-tuning-cost

curl

curl -s 'https://aipromptshub.co/api/vs/lora-vs-qlora-vs-full-fine-tuning-cost' | jq .

Python

import requests

r = requests.get("https://aipromptshub.co/api/vs/lora-vs-qlora-vs-full-fine-tuning-cost", timeout=10)
r.raise_for_status()
data = r.json()
print(data["title"])
for source in data.get("sources", []):
    print("source:", source)

JavaScript / Node

// Node 20+ / modern browser
const res = await fetch("https://aipromptshub.co/api/vs/lora-vs-qlora-vs-full-fine-tuning-cost");
if (!res.ok) throw new Error("HTTP " + res.status);
const lora_vs_qlora_vs_full_fine_tuning_cost = await res.json();
console.log(lora_vs_qlora_vs_full_fine_tuning_cost.title);
for (const source of lora_vs_qlora_vs_full_fine_tuning_cost.sources ?? []) {
  console.log("source:", source);
}

Spec: /api/openapi.yaml · Docs: /api/docs

Frequently Asked Questions

Is QLoRA always worse quality than LoRA?

Typically yes by 1-2 percentage points on standard benchmarks because the 4-bit quantization of the frozen base introduces small precision losses. On large enough models (70B+) and large enough datasets (2,000+ examples), the gap often shrinks to within noise. For most production use cases, the cost savings of QLoRA (single GPU vs multi-GPU training) outweigh the small quality delta. If quality is the binding constraint and you have multi-GPU access, LoRA is the right pick.

Why is full fine-tuning so much more expensive than LoRA?

Three reasons. First, gradient computation: full fine-tuning needs gradients for every parameter, while LoRA only computes gradients for the adapter (~0.1-1% of the total). Second, optimizer state: Adam stores momentum and variance for every trainable parameter at fp32 precision, which dominates VRAM and forces FSDP sharding across many GPUs. Third, activation memory: full fine-tuning typically needs more aggressive gradient checkpointing recomputation, slowing throughput. The net effect is 20-30x GPU-hour cost for full fine-tuning vs LoRA on the same dataset.

Can I do LoRA on closed-source models like GPT-5 or Claude?

Not directly — LoRA requires access to model weights to insert the low-rank adapter into the right layers. OpenAI, Anthropic, and Google's hosted fine-tuning APIs handle the training method internally; you cannot specify LoRA vs full fine-tuning, and they do not disclose which is used (though OpenAI fine-tuning's behavior and pricing patterns are consistent with internal LoRA). For LoRA specifically, you need to fine-tune an open-weight model — see our Together vs Fireworks vs Replicate comparison for hosted open-weight LoRA training.

What rank should I use for LoRA?

Rank 16 is the standard default in 2026 and works well on most tasks with attention Q/V/K/O projections targeted. For more complex tasks or larger models (70B+), rank 32 or 64 closes more of the gap to full fine-tuning. Below rank 8 you lose too much capacity; above rank 128 you lose the parameter-efficiency advantage and might as well full-fine-tune. The honest rule of thumb: start at 16, measure held-out quality, and only increase if you are close to your target but not quite there.

Does QLoRA work for inference too, or just training?

Both. After QLoRA training, you can serve the model in either of two ways: (1) keep it 4-bit at serving and accept 2-5% latency overhead from dequant — this preserves the memory savings; (2) dequantize the base to fp16, merge the LoRA adapter, and serve at full precision — this defeats the memory savings but eliminates the latency overhead. Most production QLoRA deployments choose option 1 because the whole point of QLoRA is fitting larger models on smaller hardware.

How does ORPO or DPO compare to standard SFT with LoRA?

DPO and ORPO are preference-optimization methods that can be applied on top of LoRA (LoRA-DPO is the common pattern). They are not alternatives to LoRA — they are alternatives to standard SFT (supervised fine-tuning). The trade-off is data shape: SFT needs input-output pairs, DPO needs chosen-vs-rejected response pairs, ORPO combines both signals. See DPO vs RLHF vs ORPO 2026 for the full comparison.

What's the smallest dataset that works for LoRA fine-tuning?

Empirically, 200-500 examples is the floor for seeing measurable quality shift on most tasks. Below 100 examples, even LoRA struggles because there is not enough signal in the data to learn a meaningful adapter. Above 5,000 examples, marginal returns diminish quickly — going from 5K to 50K examples often produces less quality lift than going from 500 to 5K. The honest curve: most LoRA fine-tunes' quality is bottlenecked by data quality, not data quantity, above ~2,000 examples.

Can I combine LoRA adapters from different fine-tunes?

Yes — LoRA adapter weights can be summed (with weight coefficients) to combine behaviors from multiple fine-tunes. This is a research-quality technique with mixed real-world results: simple additions often produce models that behave like neither parent. More sophisticated merging methods (TIES, DARE, model souping) work better but require careful weight calibration. For production, the safer pattern is to either fine-tune on combined data or use adapter hot-swapping at serving time to route different request types to different adapters.

You picked the training method. Now write the prompts the fine-tuned model needs to shine.

A LoRA-tuned Llama or Mistral is only as good as the system prompt that frames its task. AI Prompt Generator writes production-ready prompts tuned to the open-weight model + LoRA configuration you trained — so the lift you paid for in training actually shows up at inference. 14-day free trial, no credit card.

Browse all prompt tools →