What Is Fine-Tuning? LLM Customization Explained for Enterprises

Fine-Tuning Definition: What It Actually Means

In short

Fine-tuning is the process of continuing the training of a pre-trained LLM on a smaller, labeled, task-specific dataset so that the model's weights are adjusted to perform better on a targeted domain, format, or task.

Fine-tuning is the process of further training a pre-trained large language model on a smaller, task-specific dataset to adapt its behavior, tone, or domain knowledge. It modifies model weights to improve performance on targeted tasks without training from scratch.

To understand why this matters, it helps to separate two distinct training phases that every modern LLM goes through.

Pre-Training vs Fine-Tuning: The Core Distinction

Pre-training teaches a model language by ingesting billions of tokens from the internet — books, websites, code, research papers. The model learns grammar, reasoning patterns, and world knowledge at enormous scale and cost.

Fine-tuning takes that general-purpose model and specializes it. Think of it this way: pre-training is a medical degree; fine-tuning is a surgical residency. The foundational knowledge is already there — fine-tuning sharpens it for a specific context.

The critical distinction from prompt engineering: fine-tuning physically modifies model weights. Prompt engineering only changes what the model sees at inference time. Both influence output, but only fine-tuning makes structural changes to the model itself.

The concept of transfer learning — on which fine-tuning is based — has deep roots in deep learning. It was established in computer vision during the ImageNet era (around 2014) before migrating to NLP via BERT (Devlin et al., Google, 2018), which demonstrated that a pre-trained language model could be fine-tuned with minimal task-specific data to achieve state-of-the-art results across a wide range of NLP benchmarks.

Fine-tuning is categorized by how many parameters it updates: full fine-tuning updates every weight in the model, while parameter-efficient fine-tuning (PEFT) updates only a small, strategically chosen subset. The techniques section below covers this split in detail.

Other Names You'll Encounter

Vendor documentation and research papers use several overlapping terms. Here is what each means:

• Model adaptation: The broad concept of adjusting a pre-trained model for a new context — fine-tuning is the primary mechanism.
• Task-specific training: A synonym for fine-tuning when the goal is a narrow, well-defined task (e.g., named-entity recognition, classification).
• Transfer learning fine-tuning: The full technical name that situates fine-tuning within the transfer learning paradigm originating in computer vision.
• Instruction tuning: A specific fine-tuning variant where training data consists of (instruction, response) pairs. This is what powers InstructGPT, GPT-4, Llama-2-chat, and Mistral-Instruct.
• Domain adaptation: The broader ML objective — fine-tuning is the mechanism LLMs use to achieve it. You adapt a general model to a specific domain (legal, medical, financial) by fine-tuning on domain-specific data.

Understanding these terms prevents confusion when evaluating vendors or reading model documentation. They all describe the same underlying mechanism with different emphases.

The Three Main Fine-Tuning Techniques Enterprises Use

In short

Enterprises primarily use three fine-tuning approaches: supervised fine-tuning (SFT) for labeled task data, reinforcement learning from human feedback (RLHF) for alignment, and parameter-efficient fine-tuning (PEFT) methods like LoRA to reduce compute cost.

Three paradigms dominate enterprise fine-tuning today. Each involves a different training mechanism, data requirement, and cost profile — choosing the right one is the first real decision in any fine-tuning project.

1. Supervised Fine-Tuning (SFT)

SFT is the baseline approach. You provide labeled input-output pairs — a question and its correct answer, a document and its summary, a prompt and the desired response — and the model is trained to predict the output given the input using standard cross-entropy loss.

It requires no reward model, no human preference rankings, and no reinforcement learning infrastructure. That makes it the natural entry point for most enterprises.

• Data required: 1,000–100,000 labeled input-output pairs (Databricks, 2024).
• Typical use case: A legal firm fine-tuning a GPT-class model on contract review Q&A pairs to enforce specific output formats and legal terminology.
• Limitation: SFT optimizes for mimicking the training data. If your labels have gaps or inconsistencies, the model learns those gaps too.

Instruction Tuning: The Enterprise-Friendly SFT Variant

Instruction tuning is a specific, widely-used form of SFT where training data consists of (instruction, response) pairs rather than raw text continuation. This format is what powers InstructGPT, GPT-4, Llama-2-chat, and Mistral-Instruct.

For enterprises, it is the most accessible path to customizing an open-source base model — such as Llama 3 or Mistral 7B — for internal tools.

• Format: "Summarize this contract clause in plain language." → [desired output]
• Why it works: Models trained on instruction-response pairs generalize better to new instructions than models trained on raw text continuation.
• Open-source advantage: Llama 3 and Mistral 7B are commonly instruction-tuned on-premises, keeping sensitive data off third-party infrastructure.

2. Reinforcement Learning from Human Feedback (RLHF)

RLHF adds a second training loop on top of SFT. Human annotators rank model outputs from best to worst; those rankings train a separate reward model; that reward model then guides the LLM via reinforcement learning (specifically, Proximal Policy Optimization, or PPO) toward higher-reward outputs.

This is how OpenAI aligned ChatGPT, as documented by Ouyang et al. at NeurIPS 2022. It is significantly more resource-intensive than SFT and requires ongoing human annotation capacity.

• Best for: Aligning a customer service bot to specific brand tone, reducing harmful outputs, or enforcing safety guardrails at scale.
• Limitation: High cost, long iteration cycles, and complex infrastructure. Typically reserved for model developers or large enterprises with dedicated ML teams.
• Not the default: Most enterprise use cases do not require RLHF. If your goal is domain adaptation rather than behavioral alignment, SFT or LoRA will suffice.

3. Parameter-Efficient Fine-Tuning (PEFT) — LoRA and QLoRA

PEFT methods fine-tune a model without updating all of its weights. Instead, small trainable modules are injected into or alongside the existing weight matrices — the original weights remain frozen.

LoRA (Low-Rank Adaptation, Hu et al., 2022) is the dominant PEFT method in production. It injects trainable low-rank matrices into specific transformer layers, reducing trainable parameters by up to 99% versus full fine-tuning with minimal performance degradation, according to the Wang et al. Springer survey (2025).

• LoRA: Adds small rank-decomposed matrices to attention layers. The base model weights are untouched and reusable. Multiple LoRA adapters can be swapped on the same base model for different tasks.
• QLoRA: Extends LoRA by quantizing the base model to 4-bit precision, dramatically reducing GPU memory requirements. Enables fine-tuning large models on a single consumer-grade GPU — ideal for edge deployment or tight cloud budgets.
• Semantic knowledge tuning (SKT): An emerging PEFT variant (Prottasha et al., Nature, 2024) that integrates semantic structure into the fine-tuning process for further efficiency gains on knowledge-intensive tasks.

In Alice Labs' experience across 100+ enterprise AI implementations, LoRA is the most common entry point for clients new to fine-tuning. It fits within existing cloud GPU budgets — typically a single A100 or equivalent — without requiring a dedicated ML infrastructure team.

Fine-Tuning vs RAG: How to Choose

In short

Fine-tuning embeds knowledge into model weights and is best for stable behavioral patterns; RAG retrieves knowledge at inference time and is better for dynamic, frequently-updated information. Most enterprise use cases are better served by RAG first.

The fine-tuning vs RAG decision is the most consequential architectural choice in enterprise LLM deployment. Getting it wrong costs months of effort and significant compute budget.

The core difference: fine-tuning bakes knowledge into model weights; RAG retrieves knowledge at inference time from an external document store. These are not competing approaches — they solve different problems.

When Fine-Tuning Is the Right Choice

Fine-tuning is the right investment when you need the model to behave differently, not just know different things. Specific signals that point toward fine-tuning:

• Consistent output format: You need the model to always return structured JSON, a specific document template, or a proprietary response schema.
• Domain vocabulary and tone: Your domain uses specialized terminology (legal, medical, engineering) that the base model handles inconsistently.
• Latency constraints: RAG adds retrieval latency; a fine-tuned model can respond without a retrieval round-trip.
• High-volume, narrow tasks: Classification, extraction, or translation at scale where the task definition is fixed and the data is stable.
• Smaller, cheaper serving: A fine-tuned 7B model can outperform a generic 70B model on a narrow task, with dramatically lower inference cost.

When RAG Outperforms Fine-Tuning

RAG outperforms fine-tuning for knowledge-retrieval tasks where facts change frequently. This is one of the most consistent findings in enterprise AI deployment — and one of the most commonly ignored.

• Frequently updated information: Product catalogs, policy documents, pricing, legal regulations. Fine-tuning would require retraining every time data changes; RAG updates via index refresh.
• Long-tail knowledge: Large document corpora where coverage breadth matters more than behavioral consistency.
• Source attribution requirements: RAG can cite specific retrieved documents; fine-tuned models cannot reliably attribute their outputs to source material.
• Budget and timeline constraints: RAG pipelines can be production-ready in days. Fine-tuning projects typically take weeks to months end-to-end.

For a deeper dive into retrieval-augmented generation architecture and when to deploy it, see our guide on what is RAG.

Can You Combine Fine-Tuning and RAG?

Yes — and in mature enterprise deployments, combining them is common. The pattern: fine-tune a base model for consistent behavior, format, and domain tone, then add a RAG layer on top to inject current factual knowledge at inference time.

This architecture gives you the behavioral consistency of fine-tuning with the factual freshness of RAG. It is also the most complex and expensive to operate — Alice Labs recommends it only for teams with established MLOps infrastructure. For more on operational tooling, see our primer on what is MLOps.

Fine-Tuning vs Prompt Engineering vs Distillation

In short

Prompt engineering is faster and cheaper but limited to the context window; distillation compresses a large model's knowledge into a smaller one; fine-tuning is the middle path — it changes model behavior permanently with moderate data and cost.

Fine-tuning sits in the middle of a spectrum of LLM adaptation techniques. Understanding where it fits helps enterprises avoid over-engineering (reaching for fine-tuning when prompt engineering suffices) and under-engineering (using prompt hacks when the problem requires weight-level change).

Prompt Engineering: Start Here, Not with Fine-Tuning

Prompt engineering — crafting the system prompt, few-shot examples, and instruction structure — costs nothing beyond model API calls. For a large fraction of enterprise use cases, it is sufficient.

Alice Labs' standard recommendation: exhaust prompt engineering options before committing to fine-tuning. In our experience across 100+ enterprise implementations, structured prompting with few-shot examples resolves the majority of quality complaints that teams initially attribute to needing a fine-tuned model.

• Prompt engineering wins when: The task is well-defined, latency tolerance is moderate, and the model's base capabilities are close to the target behavior.
• Prompt engineering breaks down when: The desired behavior cannot be described in a prompt (e.g., mimicking a very specific writing style across thousands of examples), or when context-window limits prevent including sufficient few-shot examples.

Distillation: A Different Optimization Goal

Knowledge distillation trains a smaller "student" model to replicate the outputs of a larger "teacher" model. The goal is compression and efficiency — not domain specialization.

Distillation and fine-tuning are often confused because both involve training on labeled data. The distinction: fine-tuning adapts a model to a new domain using task-specific labels; distillation trains a model to mimic another model's probability distributions.

• Use distillation when: You have a high-performing large model (e.g., GPT-4) and need to deploy a smaller, cheaper version that approximates its behavior.
• Use fine-tuning when: You need to specialize any model — large or small — on domain-specific behavior that the base model does not exhibit.
• Combined approach: Distill a large model, then fine-tune the student. This is increasingly common in enterprise deployments targeting edge or on-premises inference.

Google's Machine Learning Crash Course (2024) frames these three techniques — fine-tuning, distillation, and prompt engineering — as complementary tools in the LLM adaptation toolkit, each optimizing for a different constraint: behavior, size, or speed.

Enterprise Fine-Tuning Use Cases: Where It Delivers ROI

In short

Fine-tuning delivers clear ROI in enterprises when the task is narrow, the data is available, the behavior is stable, and the volume justifies the training investment — typically legal, financial, customer service, and internal tooling contexts.

Fine-tuning is not a universal upgrade — it is a targeted investment. The use cases where it reliably delivers ROI share four characteristics: narrow task definition, available labeled data, stable behavior requirements, and sufficient inference volume to amortize training cost.

Legal and Financial Services

These sectors generate large volumes of structured, expert-reviewed documents — exactly the labeled data fine-tuning needs. Common deployments:

• Contract review and clause extraction: Fine-tune on annotated contracts to extract specific clause types (liability, termination, jurisdiction) in a consistent format. A generic LLM will miss firm-specific terminology; a fine-tuned model encodes it.
• Regulatory document summarization: Fine-tune on pairs of regulatory texts and approved summaries to match the firm's compliance communication standards.
• Financial report generation: Fine-tune on historical analyst reports to produce outputs that match the firm's house style and numerical formatting conventions.

For enterprises operating under EU AI Act obligations, fine-tuned models used in high-risk contexts require additional documentation. See our EU AI Act compliance checklist for the relevant requirements.

Customer Service and Internal Tooling

Customer-facing AI with a defined brand voice is a strong fine-tuning candidate — not because RAG cannot handle the knowledge retrieval, but because fine-tuning enforces consistent tone at the model level rather than relying on system prompt compliance.

• Brand voice enforcement: Fine-tune on approved customer service transcripts to embed tone, formality level, and response structure into the model weights.
• Intent classification: Fine-tune a small model (7B–13B) as a classifier that routes customer queries to the right workflow. Faster and cheaper than using a large general model for every routing decision.
• Internal knowledge base Q&A: Combine fine-tuning (for format and tone) with RAG (for current policies) — the hybrid architecture described in the previous section.

Code Generation and Technical Documentation

Organizations with proprietary codebases, internal APIs, or non-public frameworks benefit significantly from fine-tuning. A base model has no knowledge of your internal library; a fine-tuned model trained on your codebase does.

• Internal API completion: Fine-tune on code examples using your proprietary APIs so the model suggests correct function signatures and parameters.
• Code review automation: Fine-tune on annotated code review pairs to produce comments that match your engineering team's standards.
• Documentation generation: Fine-tune on existing doc-code pairs to generate documentation that matches your organization's style and level of technical detail.

For teams building AI-assisted developer tooling, our roundup of the best AI coding agents in 2026 covers where fine-tuned models fit within the broader agentic architecture.

Data Requirements and Quality Standards for Fine-Tuning

In short

Effective supervised fine-tuning requires 1,000–100,000 labeled examples, but dataset quality — consistency, relevance, and label accuracy — predicts outcomes more reliably than dataset size alone.

Databricks' practical LLM fine-tuning guide (2024) puts the effective range for supervised fine-tuning at 1,000–100,000 labeled examples. But that range is misleading without a quality framework — 1,000 carefully curated examples will outperform 50,000 inconsistent ones.

Harada et al. (HuggingFace, 2025) found that dataset composition and mid-layer weight adjustments are the strongest predictors of fine-tuning success. This has direct implications for how enterprises should budget their data preparation effort.

Data Quality Standards That Predict Success

• Label consistency: The same input should always map to the same output category or format. Inconsistent labels are the single most common cause of fine-tuning failure in enterprise projects.
• Representative coverage: Training data must cover the full distribution of inputs the model will see in production. Models fine-tuned on narrow slices of the input space fail unpredictably on edge cases.
• Correct format: For instruction tuning, each example must follow the exact instruction-response template the model will use at inference time. Format mismatches degrade performance significantly.
• Minimal noise: Remove duplicate examples, truncated outputs, and examples where the "correct" answer is ambiguous or contested.
• Domain balance: If your use case spans multiple sub-domains (e.g., contract types in a legal context), ensure proportional representation across the training set.

Data Sourcing Strategies for Enterprises

Most enterprises do not have 10,000 labeled examples sitting in a database. Practical sourcing strategies:

• Expert annotation: Have domain experts (lawyers, analysts, engineers) produce or validate input-output pairs. High quality, high cost — budget 30–60 minutes per example for complex tasks.
• Synthetic data generation: Use a large model (GPT-4, Claude 3) to generate training examples, then have domain experts review a sample for quality. Reduces annotation cost by 60–80% in typical enterprise projects.
• Log mining: If your organization already deploys an LLM, mine approved outputs from production logs. Filter for high-confidence, human-reviewed responses.
• Existing documents: Convert existing structured documents (templates, approved responses, annotated contracts) into instruction-response pairs. Often underutilized and immediately available.

Data governance matters here. Fine-tuning encodes training data into model weights — any sensitive data included in training is effectively embedded in the model. Establish a data governance review before including any customer, patient, or confidential business data. Our EU AI Act compliance checklist covers data handling requirements for AI systems used in regulated contexts.

Fine-Tuning Costs and Timelines: What to Budget

In short

A typical LoRA fine-tuning project for a 7B–13B model costs $500–$5,000 in compute and takes 4–12 weeks end-to-end including data preparation, training, evaluation, and deployment — with data preparation consuming the majority of the timeline.

Cost and timeline are the two factors that most frequently surprise enterprises entering their first fine-tuning project. The GPU training run is the cheapest and fastest part. The expensive, slow work is everything around it.

Compute Costs by Model Size and Method

• LoRA on a 7B model (e.g., Mistral 7B, Llama 3 8B): Fits on a single A100 80GB GPU. Cloud cost: $50–$300 for the training run, depending on dataset size and number of epochs.
• QLoRA on a 13B model: Fits on a single A100 with 4-bit quantization. Cloud cost: $100–$500.
• Full fine-tuning on a 7B model: Requires 2–4 A100s. Cloud cost: $500–$2,000.
• Full fine-tuning on a 70B model: Requires 8–16 A100s. Cloud cost: $5,000–$20,000+ per run.
• RLHF at scale: Requires reward model training + PPO training loop. Full pipeline: $20,000–$200,000+ depending on annotation volume and model size.

Total Project Timeline

The compute cost above reflects only the training run. A complete fine-tuning project has five phases, each with its own timeline:

• 1. Problem definition and baseline evaluation (1–2 weeks): Define the exact task, establish a benchmark using the base model and prompt engineering, and confirm that fine-tuning is the right approach.
• 2. Data sourcing and preparation (2–6 weeks): The longest phase in most projects. Includes annotation, quality review, format normalization, and train/validation/test splitting.
• 3. Training and hyperparameter tuning (3–7 days): LoRA training on a 7B model with 10,000 examples typically completes in 2–6 hours. Multiple runs are needed for hyperparameter search.
• 4. Evaluation and iteration (1–3 weeks): Automated metrics (perplexity, F1, ROUGE) plus human evaluation on a held-out test set. Often requires returning to data preparation after the first evaluation cycle.
• 5. Deployment and monitoring setup (1–2 weeks): Integrating the fine-tuned model into production infrastructure, setting up A/B testing, and establishing drift monitoring.

Total end-to-end: 4–12 weeks for a well-scoped LoRA fine-tuning project. RLHF or full fine-tuning projects typically run 3–6 months.

For enterprises assessing whether this investment is justified, our AI ROI calculator provides a structured framework for modeling returns on AI implementation projects.

When Not to Fine-Tune: The Cases to Skip It

In short

Skip fine-tuning when prompt engineering or RAG can solve the problem, when your dataset is too small or low-quality, when the knowledge changes frequently, or when your team lacks the MLOps infrastructure to maintain a fine-tuned model in production.

Fine-tuning has clear costs: data preparation time, compute budget, and ongoing maintenance of a model artifact that will drift relative to the base model over time. Before committing, validate that the problem actually requires it.

Five Situations Where Fine-Tuning Is the Wrong Choice

• The problem is a prompt engineering problem: If the base model can produce the target output when given clear instructions and 3–5 few-shot examples, you do not need fine-tuning. Test structured prompting first — it is free and takes hours, not weeks.
• Your knowledge changes frequently: If the "knowledge" you want the model to have — product specs, pricing, policies — updates more than once per quarter, fine-tuning will require constant retraining. RAG is the correct architecture.
• You have fewer than 500 high-quality labeled examples: Below this threshold, fine-tuning is unlikely to meaningfully outperform few-shot prompting and risks overfitting to your small training set.
• You lack MLOps infrastructure: A fine-tuned model is a software artifact that requires versioning, deployment pipelines, monitoring, and retraining schedules. If your organization does not have this infrastructure in place, the operational overhead will exceed the performance benefit. Our MLOps primer covers what is required.
• Your use case is exploratory: Fine-tuning locks in a specific task definition. If you are still discovering what the AI should do, a fine-tuned model will encode the wrong behavior. Use prompt engineering during exploration, fine-tune when requirements are stable.

A Simple Decision Framework

Use this decision sequence before any fine-tuning project:

1. Can structured prompt engineering (with few-shot examples) achieve ≥80% of the target quality? → If yes, ship the prompt.
2. Is the primary problem "the model doesn't know the right facts"? → If yes, implement RAG before fine-tuning.
3. Do you have 1,000+ high-quality, consistently labeled examples? → If no, invest in data collection before training.
4. Does your team have the MLOps capacity to maintain a fine-tuned model? → If no, evaluate managed fine-tuning services or adjust scope.
5. Is the task definition stable (unlikely to change significantly in 6 months)? → If no, continue with prompt engineering until requirements stabilize.

If you pass all five checks, fine-tuning is justified. For teams that are unsure where they stand, our analysis of why AI projects fail covers the most common decision errors in enterprise AI deployments.

How Alice Labs Approaches Fine-Tuning Decisions

In short

Alice Labs evaluates fine-tuning as a last resort after prompt engineering and RAG — in 100+ enterprise implementations, the majority of client needs are met without fine-tuning, and those that do require it almost always use LoRA on open-source models.

Across 100+ enterprise AI implementations in Sweden and Europe, Alice Labs has developed a consistent approach to fine-tuning decisions. The short version: we recommend it less often than clients initially expect, and we get better results because of that discipline.

Our Evaluation Sequence

Every AI implementation engagement at Alice Labs follows the same adaptation sequence before fine-tuning is considered:

1. Baseline with the best available API model: Establish what GPT-4o or Claude 3.5 can achieve on the task with zero customization.
2. Structured prompt engineering: Invest 1–2 weeks in system prompt design, few-shot example curation, and output format specification. This phase resolves the majority of quality gaps.
3. RAG pipeline (if knowledge retrieval is involved): Build a retrieval layer over the client's document corpus. Evaluate whether retrieval-augmented outputs meet the quality bar.
4. Fine-tuning evaluation: Only if steps 1–3 leave a measurable, business-critical quality gap do we proceed to fine-tuning scoping.

What We Actually Fine-Tune in Practice

When fine-tuning is warranted, our implementations almost always use LoRA on open-source base models — specifically Llama 3 (8B or 70B) or Mistral 7B. The reasons are consistent across clients:

• Data privacy: Enterprise clients in regulated industries (finance, legal, healthcare) cannot send training data to third-party APIs. Open-source models trained on-premises or in private cloud keep data within the client's infrastructure boundary.
• Cost control: LoRA on a 7B model runs on a single A100. Clients with existing cloud GPU agreements can complete a training run for under $300.
• Adapter portability: LoRA adapters are small (typically 10–100MB) and portable. Clients can maintain multiple task-specific adapters on the same base model, switching between them at serving time.
• Iteration speed: LoRA training runs are fast enough (2–6 hours for typical enterprise datasets) that teams can iterate on data quality and hyperparameters within a single sprint cycle.

The consistent lesson from our implementations: fine-tuning is a precision tool. Applying it to the right problem at the right time delivers significant results. Applying it as a default solution creates expensive maintenance overhead without proportional quality gains.

For enterprises evaluating where fine-tuning fits in a broader AI strategy, our enterprise AI strategy framework provides a structured approach to prioritizing AI investments across the organization.

Frequently Asked Questions: Fine-Tuning LLMs

In short

Common enterprise questions about LLM fine-tuning — covering cost, data requirements, technique selection, and how fine-tuning compares to RAG and prompt engineering.

How much data do I need to fine-tune an LLM?

Effective supervised fine-tuning typically requires 1,000–100,000 labeled input-output examples (Databricks, 2024). For narrow, well-defined tasks (classification, extraction), 1,000–5,000 high-quality examples are often sufficient. For complex generation tasks, 10,000+ examples improve consistency. Quality matters more than size: 1,000 clean, consistent examples outperform 50,000 noisy ones.

How much does fine-tuning an LLM cost?

LoRA fine-tuning on a 7B model (Mistral, Llama 3 8B) costs $50–$300 in cloud compute per training run on a single A100 GPU. Full fine-tuning on a 70B model can cost $5,000–$20,000 per run. Total project cost — including data preparation, evaluation, and deployment — typically ranges from $5,000 to $50,000 for an enterprise LoRA project, depending on data sourcing complexity.

Is fine-tuning better than RAG?

Neither is universally better — they solve different problems. Fine-tuning is better for stable behavioral patterns, consistent output formats, and domain tone. RAG is better for dynamic, document-based knowledge that changes frequently. Most enterprise use cases should implement RAG first and fine-tune only if a behavioral quality gap remains after RAG is in place.

Should I use LoRA or full fine-tuning?

LoRA for almost all enterprise use cases. It reduces trainable parameters by up to 99% versus full fine-tuning, with minimal performance degradation on most tasks (Wang et al., Springer, 2025). Full fine-tuning is only justified when task-specific performance differences are measurable and significant — typically for highly specialized domains where LoRA consistently underperforms after multiple hyperparameter sweeps.

How long does a fine-tuning project take?

A well-scoped LoRA fine-tuning project takes 4–12 weeks end-to-end. Data preparation (2–6 weeks) is typically the longest phase. The actual training run for a 7B model on 10,000 examples completes in 2–6 hours. RLHF or full fine-tuning projects typically run 3–6 months including annotation infrastructure setup.

Should I fine-tune an open-source model or use an API fine-tuning service?

Open-source models (Llama 3, Mistral) are preferable for enterprises with data privacy requirements or significant inference volume. API fine-tuning services (OpenAI, Google) offer faster setup but require sending training data to a third party and impose ongoing per-token serving costs. For regulated industries, open-source fine-tuning on private infrastructure is typically the right choice.

Why do fine-tuning projects fail?

The most common failure modes: inconsistent training labels (the model learns the noise), insufficient data coverage (fails on production edge cases), and unclear task definition (training data encodes the wrong behavior). Harada et al. (HuggingFace, 2025) identify dataset composition as the strongest predictor of failure — enterprises under-invest in data quality review relative to compute spend.

Does fine-tuning a model create EU AI Act obligations?

It can. If you fine-tune a general-purpose AI model and deploy it in a high-risk context (as defined by the EU AI Act), you may take on obligations that were previously the model provider's responsibility. Fine-tuning does not automatically change risk classification, but it can affect conformity assessment requirements and documentation obligations. See our EU AI Act compliance checklist for specifics.