![Sådan finetuner du en LLM: Metoder, frameworks og trin-for-trin-kode [2026]](/_next/image?url=https%3A%2F%2Fmedia.techsy.io%2Ftechsy-io%2Fhero-137-1200x630.webp&w=3840&q=75)
Finetuning af en LLM betyder, at du tager en fortrænet model og træner den på dine specifikke data, så den løser din opgave bedre, end nogen prompt nogensinde kunne. Adgangsbarrieren er kollapset: QLoRA + Unsloth lader dig nu finetune en 8B-parameter-model på et 12 GB forbruger-GPU for under 1 $ i cloudomkostninger.
Denne guide dækker hele rejsen – hvornår du skal finetune (vs. RAG eller prompt engineering), hvilken metode og hvilket framework du skal vælge, hvordan du forbereder dit datasæt, en copy-paste Llama 3-gennemgang, reelle prisscenarier og deployment.
Finetuning på et øjeblik
Før du binder dig til noget, er her det hurtige overblik:
| Attribut | Detalje |
|---|---|
| Hvad det er | Træning af en fortrænet LLM på opgavespecifikke data for at forbedre ydelsen |
| Hvornår det bruges | Når prompt engineering og RAG ikke er nok til dit use case |
| Mest populære metode | QLoRA (4-bit kvantiseret LoRA), håndterer 90 % af finetuning på forbruger-GPU |
| Hurtigste framework (2026) | Unsloth (2-5x hurtigere, 70 % mindre VRAM end standardtræning) |
| Minimum hardware | 12 GB VRAM GPU (RTX 3060) med QLoRA |
| Billigste cloudmulighed | ~$0,34/time på RunPod (RTX 4090) |
| Datasætstørrelse | 100-10.000 eksempler (500+ anbefales til produktion) |
| Træningstid | 30 min - 8 timer afhængigt af modelstørrelse og datasæt |
| Bedste basismodeller (2026) | Llama 3.x, Qwen 2.5, Mistral, Gemma 2, Phi-4 |
| Vigtigste risiko | Katastrofal glemmen (modellen mister generel viden) |
| Alternativ | RAG til videnshentning, prompt engineering til simple opgaver |
Lad os nu finde ud af, om finetuning faktisk er det rigtige træk for dit projekt.
Hvornår skal du finetune en LLM? (vs. RAG vs. prompt engineering)
Det er spørgsmålet, de fleste udviklere springer over – og det koster dem uger af spildt arbejde. Finetuning er kraftfuldt, men det er ikke altid det rigtige værktøj. Her er en ramme til at beslutte det.
| Tilgang | Bedst når | Begrænsninger | Pris |
|---|---|---|---|
| Prompt engineering | Simpel formatering, toneændringer, few-shot-eksempler virker | Begrænset af kontekstvindu, inkonsistent på komplekse opgaver | Gratis (kun API-omkostninger) |
| RAG | Du skal forespørge ekstern eller ofte skiftende viden | Hentekvaliteten varierer, tilføjer latenstid | Moderat (vektor-DB + embedding-omkostninger) |
| Finetuning | Du har brug for konsistent adfærd, domænespecifikt sprog eller streng formatoverholdelse | Kræver træningsdata, risiko for katastrofal glemmen | GPU-tid + datasætsforberedelse |
| Hybrid (RAG + finetuning) | Du har brug for specialiseret adfærd OG ekstern viden | Mest kompleks at bygge og vedligeholde | Kombineret |
Beslutningen koges ned til, hvad du forsøger at ændre. Her er reelle scenarier:
| Scenarie | Anbefalet tilgang | Hvorfor |
|---|---|---|
| Kundeservicebot med produktviden | RAG | Viden ændrer sig ofte, prompts håndterer tonen |
| Medicinsk kodning med ICD-10-overholdelse | Finetuning | Strenge formatkrav, domænespecifik terminologi |
| Virksomhedsassistent med firmadata + specifik tone | Hybrid | Kræver både hentning og konsistent adfærd |
| Pålidelig JSON-outputformatering | Finetuning | Billigere og mere pålidelig end at kæmpe med prompts |
| Chatbot der taler som dit brand | Finetuning | Adfærds- og stilændringer kræver opdatering af vægte |
Hvis du vælger den rigtige AI-stack til din SaaS, er denne beslutningsramme trin ét. Mange teams bygger komplekse RAG-pipelines, når en finetuning med 500 eksempler ville give dem mere konsistente resultater med lavere latenstid.
Dom: Finetun, når du har brug for, at modellen konsekvent opfører sig anderledes, ikke bare ved andre ting. Hvis du kun har brug for ny viden, er RAG billigere og nemmere at vedligeholde. Hvis du har brug for begge dele, så gå hybrid.
Hvordan fungerer LLM-finetuning? Fuld vs. LoRA vs. QLoRA
Der er tre hovedtilgange, og de adskiller sig markant i hardwarekrav, pris og kvalitet. At forstå afvejningerne sparer dig for enten at overinvestere eller underlevere.
Fuld finetuning (når budgettet er ligegyldigt)
Fuld finetuning opdaterer hver eneste parameter i modellen. Det giver de bedst mulige resultater, men kræver enorme ressourcer – cirka 100+ GB VRAM til en 7B-model (du skal gemme modellen, optimertilstande og gradienter samtidig). Det er H100-klyngeterræn. Medmindre du er i et vel finansieret laboratorium, så spring dette over.
LoRA: PEFT-revolutionen
LoRA (Low-Rank Adaptation) fryser basismodellen og tilføjer små trænbare matricer kaldet adaptere. I stedet for at opdatere en enorm vægtmatrix W direkte, dekomponerer LoRA opdateringen i to små matricer A og B, hvor rang r er meget mindre end modeldimensionen. Resultatet: du træner cirka 1-2 % af de oprindelige parametre, mens du bevarer 98-99 % af kvaliteten fra fuld finetuning.
Hugging Face peft-biblioteket er standardimplementeringen. LoRA-adaptere er typisk 50-200 MB – småbitte sammenlignet med den fulde model.
QLoRA: Finetuning for alle
QLoRA tager LoRA et skridt videre. Den indlæser basismodellen i 4-bit præcision ved hjælp af en særlig datatype kaldet NormalFloat4 (NF4) og anvender derefter LoRA-adaptere ovenpå. 4-bit kvantiseringen skærer VRAM-forbruget med yderligere ~25 % sammenlignet med standard-LoRA, mens kvaliteten forbliver næsten identisk.
Det er det, der gør finetuning tilgængelig. En 7B-model, der kræver 100+ GB til fuld finetuning, får plads i 12 GB med QLoRA.
| Metode | VRAM (7B-model) | Kvalitet vs. basis | Træningshastighed | Adapterstørrelse | Use case |
|---|---|---|---|---|---|
| Fuld finetuning | 100+ GB | Bedst | Langsomst | Fuld model (~14 GB) | Virksomheder med H100-klynger |
| LoRA | ~16 GB | 98-99 % af fuld | 2x hurtigere | ~50-200 MB | Teams med A100/RTX 4090 |
| QLoRA | ~12 GB | 97-99 % af fuld | Hurtigst (med Unsloth) | ~50-200 MB | Soloudviklere, forbruger-GPU'er |
Dom: For 90 % af udviklere er QLoRA det rigtige valg. Kvalitetsforskellen fra fuld finetuning er ubetydelig for de fleste opgaver, og hardwarebesparelserne er enorme. Start der og opskaler kun, hvis dine evalueringsmetrikker kræver det.
Hvilket finetuning-framework skal du bruge i 2026?
Valget af framework betyder mere, end de fleste er klar over. Det rigtige sparer dig for timers opsætning og speeder træningen markant op. Her er, hvordan de fire store muligheder sammenlignes.
| Framework | GitHub-stjerner | Hastighed | Bedst til | Modelsupport | Læringskurve |
|---|---|---|---|---|---|
| Unsloth | 54K+ | 2-5x hurtigere | Single-GPU-hastighed, QLoRA | Llama, Mistral, Qwen, Gemma, Phi | Lav |
| LLaMA-Factory | 68K+ | Basis | Bredeste modelsupport, web-UI | 100+ modeller | Lav (GUI) |
| TRL (Hugging Face) | 18K+ | Basis | RLHF/DPO/GRPO, HF-økosystem | Alle HF-modeller | Middel |
| Axolotl | 11K+ | Basis | Reproducerbarhed, multi-GPU | Større modeller | Høj (YAML-konfiguration) |
Her er den hurtige anbefaling:
- Første finetuning? Brug Unsloth. Hurtigste træning, nemmeste opsætning, gratis Colab-notebooks til at komme i gang med det samme.
- Brug for et web-UI uden kode? Brug LLaMA-Factory. Dets LLaMA-Board GUI lader dig konfigurere og starte træning fra en browser.
- Laver du alignment (RLHF, DPO, GRPO)? Brug TRL. Det er Hugging Face-standarden for præferencebaseret træning, og v0.15.0 (marts 2026) tilføjede native GRPO-support.
- Kører du produktionspipelines på multi-GPU? Brug Axolotl. YAML-baserede konfigurationer gør eksperimenter reproducerbare og auditerbare.
Et nyttigt trick: Unsloth og LLaMA-Factory kan kombineres. LLaMA-Factory understøtter Unsloth som træningsbackend, hvilket giver dig GUI-bekvemmeligheden med Unsloths hastighedsoptimeringer. Teams der bygger AI-agenter som bruger finetunede modeller, starter ofte med Unsloth til hurtig iteration og skifter derefter til Axolotl til produktionsreproducerbarhed.
Hvordan forbereder du et finetuning-datasæt?
Datakvalitet er den enkelt største faktor for succes med finetuning. Et velkurateret datasæt med 500 eksempler vil næsten hver gang overgå et støjende datasæt med 10.000 eksempler.
Datasætformater
De to dominerende formater er chat (OpenAI-kompatibelt) og instruction (Alpaca-stil). Her er, hvordan hvert format ser ud i JSONL-format:
Chatformat (anbefalet til de fleste use cases):
{"messages": [{"role": "system", "content": "You are a customer support agent for Acme Inc. Be helpful, concise, and always reference the user's order number."}, {"role": "user", "content": "I ordered a laptop 3 days ago (order #4821) and it still says processing."}, {"role": "assistant", "content": "I can see order #4821 is currently in our warehouse being prepared for shipment. Laptops typically ship within 3-5 business days. You should receive a tracking number by tomorrow. Would you like me to flag this for priority processing?"}]}
{"messages": [{"role": "system", "content": "You are a customer support agent for Acme Inc. Be helpful, concise, and always reference the user's order number."}, {"role": "user", "content": "Can I return my keyboard? Order #3019, bought it last week."}, {"role": "assistant", "content": "Absolutely! Order #3019 is within our 30-day return window. I'll email you a prepaid return label right now. Once we receive the keyboard, your refund will process within 2-3 business days."}]}
{"messages": [{"role": "system", "content": "You are a customer support agent for Acme Inc. Be helpful, concise, and always reference the user's order number."}, {"role": "user", "content": "My monitor arrived cracked. Order #5573."}, {"role": "assistant", "content": "I'm sorry about that! For order #5573, I'm initiating an immediate replacement shipment -- no need to return the damaged unit. The new monitor will ship today with express delivery. You'll get a tracking email within the hour."}]}Instruction-format (Alpaca-stil):
{"instruction": "Summarize the following customer complaint in one sentence.", "input": "I've been waiting 2 weeks for my refund and nobody responds to my emails. This is the worst customer service I've ever experienced.", "output": "Customer is frustrated by a 2-week delay in receiving their refund and lack of email response from support."}
{"instruction": "Classify the sentiment of this review.", "input": "The product works fine but shipping took forever.", "output": "Mixed (positive product, negative shipping)"}Retningslinjer for datasætstørrelse
Hvor mange data har du egentlig brug for? Det afhænger af opgavens kompleksitet:
- 50-100 eksempler – proof of concept, nok til at teste om finetuning hjælper
- 500-1.000 eksempler – nyttigt til de fleste enkeltstående opgaver (klassificering, ekstraktion, formatering)
- 5.000-10.000 eksempler – produktionskvalitetsresultater til komplekse opgaver
- 10.000+ eksempler – aftagende afkast, medmindre din opgave har høj variabilitet
Tjekliste for datakvalitet
Før træning skal du validere dit datasæt mod disse kriterier:
- Konsistent formatering på tværs af alle eksempler (samme systemprompt, samme outputstruktur)
- Mangfoldige eksempler der dækker kanttilfælde og fejltilstande
- Ingen modsigelser (lær ikke modellen at sige både "ja" og "nej" til samme inputmønster)
- Balanceret fordeling af outputtyper (hvis du laver klassificering, må 90 % af eksemplerne ikke ligge i én klasse)
- Fjern duplikerede eller næsten duplikerede poster
Pro-tip: Brug GPT-4 eller Claude til at generere indledende syntetiske træningsdata og forfin derefter med menneskelig gennemgang. 500 syntetiske eksempler i høj kvalitet overgår ofte 5.000 støjende virkelige eksempler. Metas finetuning-guide anbefaler denne tilgang til at bootstrappe datasæt.
Trin-for-trin: Finetun Llama 3 8B med QLoRA og Unsloth
Her er den komplette gennemgang. Hver kodeblok er klar til copy-paste – du kan køre det i en gratis Google Colab-notebook eller på enhver maskine med 12+ GB VRAM.
Trin 1: Installer Unsloth
pip install unslothDet var det. Unsloth håndterer alle afhængighederne (transformers, peft, trl, bitsandbytes) automatisk.
Trin 2: Indlæs basismodellen i 4-bit
from unsloth import FastLanguageModel
# Load Llama 3.1 8B in 4-bit quantization
model, tokenizer = FastLanguageModel.from_pretrained(
model_name="unsloth/Meta-Llama-3.1-8B-bnb-4bit",
max_seq_length=2048,
load_in_4bit=True,
)Dette downloader den 4-bit kvantiserede model (~4 GB) og indlæser den i GPU-hukommelsen. På en RTX 3060 (12 GB) har du masser af plads til træning.
Trin 3: Konfigurer LoRA-adaptere
# Add LoRA adapters to the model
model = FastLanguageModel.get_peft_model(
model,
r=16, # LoRA rank -- 16 is the sweet spot for most tasks
target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
"gate_proj", "up_proj", "down_proj"],
lora_alpha=16, # Scaling factor (usually equal to r)
lora_dropout=0, # Unsloth optimizes for 0 dropout
bias="none",
)Med r=16 træner du cirka 40 millioner parametre ud af 8 milliarder – mindre end 0,5 % af modellen. Det er magien ved LoRA.
Trin 4: Indlæs dit datasæt
from datasets import load_dataset
# Load your JSONL dataset from Hugging Face Hub or local file
dataset = load_dataset("json", data_files="train.jsonl", split="train")
# Format into chat template
def format_chat(example):
text = tokenizer.apply_chat_template(
example["messages"],
tokenize=False,
add_generation_prompt=False,
)
return {"text": text}
dataset = dataset.map(format_chat)Dette tager JSONL-chatformatet fra forrige afsnit og anvender Llama 3's chat-skabelon. Tokenizeren håndterer alle specialtokens (<|begin_of_text|>, <|eot_id|> osv.).
Trin 5: Konfigurer og kør træning
from trl import SFTTrainer
from transformers import TrainingArguments
from unsloth import is_bfloat16_supported
trainer = SFTTrainer(
model=model,
train_dataset=dataset,
dataset_text_field="text",
max_seq_length=2048,
args=TrainingArguments(
per_device_train_batch_size=2,
gradient_accumulation_steps=4, # Effective batch size = 8
warmup_steps=5,
max_steps=60, # Adjust based on dataset size
learning_rate=2e-4, # Standard for QLoRA
fp16=not is_bfloat16_supported(),
bf16=is_bfloat16_supported(),
logging_steps=1,
output_dir="outputs",
seed=42,
),
)
# Start training
trainer.train()Vigtige hyperparametre at forstå:
- Learning rate (2e-4): Standarden for QLoRA. Gå lavere (2e-5), hvis du ser modellen glemme generelle evner.
- Batchstørrelse (2) x gradientakkumulering (4): Effektiv batchstørrelse på 8. Øg gradient_accumulation, hvis dit GPU løber tør for hukommelse.
- max_steps (60): For 500 eksempler er det cirka 1 epoke. Start med 1-3 epoker og hold øje med valideringstab.
- Rang r (16): Lavere (4-8) til simple opgaver, højere (32-64) til komplekse opgaver. 16 er en sikker standard.
Trin 6: Gem og test
# Save the LoRA adapters (small -- ~50-200 MB)
model.save_pretrained("my-fine-tuned-model")
tokenizer.save_pretrained("my-fine-tuned-model")
# Quick inference test
FastLanguageModel.for_inference(model)
inputs = tokenizer(
[tokenizer.apply_chat_template(
[{"role": "user", "content": "I need to return order #7742"}],
tokenize=False,
add_generation_prompt=True,
)],
return_tensors="pt",
).to("cuda")
outputs = model.generate(**inputs, max_new_tokens=256)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))Det er hele pipelinen. På en RTX 4090 med Unsloth tager træning af 500 eksempler cirka 15-30 minutter. På en gratis Colab T4 skal du forvente 1-2 timer.
Hvad med API-baseret finetuning? (OpenAI, Google, Mistral)
Ikke alle vil administrere GPU'er. API-udbydere lader dig finetune gennem et simpelt upload-og-træn-workflow. Her er, hvordan de sammenlignes med at køre det selv.
| Udbyder | Modeller | Min. eksempler | Pris (1.000 eksempler) | Download vægte? | Databeskyttelse |
|---|---|---|---|---|---|
| OpenAI | GPT-4o, GPT-4o-mini | 10 | ~$3-25 | Nej | Data kan bruges til træning |
| Google Vertex AI | Gemma, Gemini | 100 | ~$5-30 | Kun Gemma | GCP-kontroller |
| Mistral (La Plateforme) | Mistral-modeller | 100 | ~$4-20 | Nej | EU-datalokalitet |
| Together AI | Åbne modeller (Llama osv.) | 50 | ~$2-15 | Ja (åbne modeller) | Data opbevares ikke |
| Lokalt (Unsloth/LLaMA-Factory) | Enhver åben model | 1 | Kun GPU-omkostninger ($0-27) | Ja (du ejer alt) | Fuld fortrolighed |
Hvornår API-finetuning giver mening: Du skal iterere hurtigt, dit datasæt er lille, du vil ikke administrere infrastruktur, eller du har specifikt brug for en lukket model som GPT-4o.
Hvornår lokal finetuning vinder: Databeskyttelse betyder noget (sundhed, finans, jura), du træner ofte, du vil eje og eksportere vægtene, eller du optimerer til pris i skala.
Dom: API-finetuning er den hurtigste vej til en proof of concept. Lokal finetuning er den billigste vej til produktion. De fleste teams prototyper på en API og skifter derefter til lokal Unsloth, når de har valideret tilgangen.
Hvor meget koster det at finetune en LLM?
Fortællingen om, at "finetuning er dyrt", sidder fast i 2023. Her er, hvad det faktisk koster i dag.
| Scenarie | Model | Metode | GPU | Træningstid | Samlet pris |
|---|---|---|---|---|---|
| Hobby / læring | Llama 3 8B | QLoRA | Eget RTX 3060 (12 GB) | 2-4 timer | $0 (elektricitet) |
| Gratis cloud | Llama 3 8B | QLoRA | Google Colab T4 (gratis) | 3-5 timer | $0 |
| Startup | Llama 3 8B | QLoRA + Unsloth | RunPod RTX 4090 ($0,34/time) | 1-2 timer | $0,35-0,70 |
| Produktion | Llama 3 70B | QLoRA | RunPod A100 80GB ($3,39/time) | 5-8 timer | $17-27 |
| Virksomhed | Llama 3 70B | Fuld finetuning | 4x H100 ($13,56/time) | 20-40 timer | $270-540 |
| API (intet GPU) | GPT-4o-mini | OpenAI API | N/A | ~30 min | $3-25 |
Priskurven flader hurtigt ud. En startup der finetuner en 8B-model på RunPod bruger mindre på træning end på en enkelt kop kaffe. Selv 70B-produktionsscenariet ligger under $30 – det er én måneds daglige frokostbudget for en juniorudvikler.
Cloud-GPU-udbydere der er værd at sammenligne: RunPod (bedste spotpriser), Lambda (pålidelige on-demand H100'er), Vast.ai (billigst, men varierende kvalitet) og Modal (serverless, betaling pr. sekund).
"VRAM Requirements by Model Size and Method"
Datatable
| "Model Size" | "Full Fine-Tune" | "LoRA" | "QLoRA" |
|---|---|---|---|
| "7B" | 100 | 16 | 12 |
| "13B" | 200 | 32 | 24 |
| "70B" | 560 | 80 | 48 |
Diagrammet ovenfor viser, hvorfor QLoRA ændrede spillet. En 7B-model, der krævede en multi-GPU-klynge til fuld finetuning, får nu plads på en bærbar-GPU. 70B-modellen går fra "kun cloud" til en enkelt A100.
Dom: Du kan finetune en produktionskvalitets 8B-model for under $1. Prisbarrieren for finetuning er væk. Den reelle omkostning er tiden til datasætsforberedelse.
Hvordan evaluerer du en finetunet model?
Træning er kun halvdelen af arbejdet. Uden ordentlig evaluering kan du ikke afgøre, om din finetunede model faktisk blev bedre, eller om den bare memoriserede dine træningsdata.
Automatiserede metrikker
Følg disse under og efter træning:
- Træningstab / perplexity: Bør falde støt og derefter flade ud. Hvis det falder til næsten nul, overfitter du.
- Opgavespecifikke metrikker: Nøjagtighed (klassificering), BLEU/ROUGE (opsummering), eksakt match (ekstraktion), F1 (multi-label). Vælg den metrik der matcher din opgave.
Menneskelig evaluering
Tal fanger ikke alt. Til generative opgaver:
- A/B-test: Vis basismodellens vs. finetunet output side om side. Få 3-5 evaluatorer til at vælge det bedste svar på tværs af 50+ eksempler. Følg sejrsraten.
- Likert-skala-bedømmelse: Bedøm outputs på relevans (1-5), nøjagtighed (1-5) og tone (1-5). Beregn gennemsnitlig forbedring i forhold til basismodellen.
Tjek for katastrofal glemmen
Det er den, de fleste udviklere springer over. Kør din model på et generelt benchmark som MMLU eller HellaSwag efter finetuning. Hvis scorene falder mere end 2-3 point, har din model mistet for meget generel viden. Løsningen: sænk din learning rate, reducer epoker eller skift til LoRA (som fryser basisvægtene).
Praktisk regel: Hold altid 10-20 % af dit datasæt tilbage som et testsæt. Evaluer aldrig på træningsdata – det fortæller dig intet om ydelse i den virkelige verden.
Hvordan deployer du en finetunet model?
Træningen er færdig. Nu skal du serve den. De fleste guides springer denne del helt over.
Trin 1: Flet LoRA-adaptere
Hvis du brugte LoRA eller QLoRA, så flet adapterne tilbage i basismodellen til inferens:
# Merge adapters into base model
model.merge_and_unload()
model.save_pretrained("merged-model")
tokenizer.save_pretrained("merged-model")Trin 2: Vælg din deployment-vej
Lokal udvikling og test, Ollama:
# Convert to GGUF format (Ollama's native format)
python llama.cpp/convert_hf_to_gguf.py merged-model --outfile model.gguf --outtype q4_k_m
# Create an Ollama model
ollama create my-fine-tuned-model -f Modelfile
ollama run my-fine-tuned-modelProduktionsserving, vLLM:
# Start an OpenAI-compatible API server
python -m vllm.entrypoints.openai.api_server \
--model merged-model \
--host 0.0.0.0 \
--port 8000Serverless (nul infrastruktur): Upload din model til Together AI, Fireworks eller Modal. Du får et API-endpoint uden at administrere servere. Prisen skalerer med brugen.
Avanceret: Multi-adapter-serving
Her er et mønster, flere teams burde bruge: hold én basismodel indlæst i hukommelsen og skift LoRA-adaptere pr. forespørgsel. Du kan serve en kundeservice-adapter, en kodegennemgangs-adapter og en opsummeringsadapter – alt sammen fra et enkelt GPU. vLLM understøtter dette native med --enable-lora-flaget.
Klar til at implementere? Se vores Bedste LLM-finetuning-værktøjer og -platforme [kommer snart] for en dybere sammenligning af deploymentmuligheder.
Hvad er de mest almindelige finetuning-fejl?
Efter at have hjulpet teams med at fejlfinde snesevis af finetuning-kørsler er det disse fejl, der dukker op igen og igen.
1. Overfitting på små datasæt. Du træner i 10 epoker på 200 eksempler, træningstabet rammer næsten nul, og modellen efteraber dine træningsdata ordret. Løsning: maks. 1-3 epoker, brug et valideringssæt og hold øje med kløften mellem træningstab og evalueringstab.
2. Katastrofal glemmen. Modellen nailer din specifikke opgave, men kan ikke længere føre en basal samtale. Løsning: brug LoRA/QLoRA (fryser basisvægte), hold learning rates lave (2e-5 til fuld finetuning, 2e-4 til QLoRA) og evaluer på generelle benchmarks før deployment.
3. Elendig datakvalitet. Inkonsekvent formatering, modsigelser mellem eksempler eller dubletter. Modellen lærer støjen. Løsning: rens dine data før træning. Altid. Brug mere tid på datakurering end på hyperparametertuning.
4. Starter med en for stor model. Teams springer til 70B, fordi "større er bedre", og har derefter ikke råd til GPU-omkostningerne. Løsning: start med 8B. Hvis 8B med gode data ikke kan løse din opgave, kan 70B med de samme data sandsynligvis heller ikke. Opkaler datakvaliteten først, derefter modelstørrelsen.
5. Ingen evalueringspipeline. Træning uden et tilbageholdt testsæt og derefter deployment baseret på mavefornemmelse. Løsning: opdel dine data 80/10/10 (train/val/test), før du starter. Sammenlign med basismodellen på hvert testeksempel.
6. Learning rate for høj. Ødelægger den fortrænede viden i de første par trin. Modellen outputter vrøvl. Løsning: start på 2e-4 til QLoRA, 2e-5 til fuld finetuning. Hvis outputs forringes, så gå lavere.
Hvordan Techsy griber LLM-finetuning an
Hos Techsy følger vi en streng eskaleringsvej for hvert AI-projekt: prompt engineering først, RAG derefter, finetuning kun når dataene beviser, at det er nødvendigt. De fleste kundeprojekter kræver faktisk ikke finetuning – veludformede prompts eller en RAG-pipeline løser problemet til lavere pris og kompleksitet.
Når finetuning er det rigtige valg, er vores proces:
- Datasætaudit – Vi gennemgår kundens data for kvalitet, dækning og formatering. Hvis vi ikke har nok eksempler, hjælper vi med at opbygge et syntetisk datasæt ved hjælp af GPT-4 eller Claude med menneskelig gennemgang.
- Framework-valg – Unsloth + QLoRA til 90 % af startup-projekter. Axolotl til kunder der har brug for reproducerbare multi-GPU-produktionspipelines.
- Træning og evaluering – Vi træner altid med et tilbageholdt testsæt og benchmark'er mod basismodellen. Hvis den finetunede model ikke målbart forbedrer målmetrikken, deployer vi den ikke.
- Deployment – vLLM til produktionsserving, multi-adapter-mønstre når kunder har brug for flere specialiserede modeller fra et enkelt GPU.
Vi har leveret finetunede modeller til startups, der ikke havde råd til virksomheds-GPU-budgetter – QLoRA på RunPod holder omkostningerne under $30 selv for 70B-modeller.
Brug for hjælp til at finetune en LLM til dit use case? Vi hjælper teams med at komme fra rå data til deployet model. Få en gratis konsultation
Ofte stillede spørgsmål om LLM-finetuning
Hvad er LLM-finetuning?
LLM-finetuning er processen med at træne en fortrænet sprogmodel på dine egne opgavespecifikke data, så den løser den opgave bedre. Du lærer i bund og grund modellen nye adfærdsmønstre, formater eller domæneekspertise, som generisk prompting ikke kan opnå pålideligt.
Hvornår skal jeg finetune vs. bruge RAG?
Finetun, når du har brug for, at modellen opfører sig anderledes – konsistent outputformat, domænespecifikt sprog, bestemt tone. Brug RAG, når modellen skal vide forskellige ting, især hvis den viden ændrer sig ofte. For mange produktionssystemer fungerer en hybrid tilgang bedst.
Hvor meget koster det at finetune en LLM?
Alt fra $0 til $540 afhængigt af skala. De fleste individuelle udviklere bruger under $1 med QLoRA på en RunPod RTX 4090 ($0,34/time). En 70B-produktionsmodel på en A100 koster $17-27. Fuld finetuning på H100-klynger kører $270-540. API-finetuning (OpenAI) koster $3-25 for 1.000 eksempler.
Kan jeg finetune en LLM på min bærbare?
Ja, hvis din bærbare har et GPU med 12+ GB VRAM. En RTX 3060 bærbar-GPU håndterer 8B-modeller med QLoRA. Apple Silicon Macs med 16+ GB samlet hukommelse kan også finetune via MLX, selvom det er langsommere end CUDA. Til større modeller får du brug for cloud-GPU'er.
Hvad er forskellen mellem LoRA og QLoRA?
Begge tilføjer små trænbare adapterlag, mens de fryser basismodellen. Forskellen: QLoRA kvantiserer også basismodellen til 4-bit præcision (NF4-datatype), hvilket reducerer VRAM-forbruget med ~25 % sammenlignet med standard-LoRA. Kvaliteten er næsten identisk – QLoRA opnår 97-99 % af kvaliteten fra fuld finetuning.
Hvor mange træningseksempler har jeg brug for?
Det afhænger af opgavens kompleksitet. 50-100 eksempler er nok til en proof of concept. 500-1.000 eksempler giver nyttige resultater for de fleste enkeltstående opgaver. 5.000-10.000 eksempler leverer produktionskvalitet til komplekse opgaver. Over 10.000 rammer du aftagende afkast, medmindre opgaven har ekstremt høj variabilitet.
Hvilken basismodel skal jeg finetune i 2026?
Llama 3.x til generelle opgaver (bedste samlede kvalitet/størrelse-forhold). Mistral til europæiske sprog og effektiv inferens. Qwen 2.5 til flersprogede og kodeopgaver. Phi-4 når du har brug for det mindst mulige fodaftryk. Gemma 2 til Google-økosystemintegration.
Hvad er GRPO, og hvorfor betyder det noget?
GRPO (Group Relative Policy Optimization), introduceret af DeepSeek, er en efterfølger til RLHF til alignment-træning. Den vigtigste fordel: det kræver ikke træning af en separat belønningsmodel, hvilket skærer de beregningsmæssige omkostninger cirka i halve. TRL v0.15.0 understøtter GRPO native, hvilket gør det tilgængeligt for alle der bruger Hugging Face-økosystemet.
Hvordan forhindrer jeg katastrofal glemmen?
Brug LoRA eller QLoRA i stedet for fuld finetuning – de fryser basismodellens vægte, hvilket bevarer generel viden. Hold din learning rate lav (2e-4 til QLoRA, 2e-5 til fuld). Træn i så få epoker som nødvendigt (1-3 er normalt nok). Kør din model på generelle benchmarks (MMLU, HellaSwag) efter træning for at verificere, at den ikke er gået tilbage.
Kan jeg finetune og derefter bruge RAG sammen?
Absolut, og mange produktionssystemer gør præcis det. Finetun til adfærds- og formatkonsistens og forbind derefter RAG til opdateret videnshentning. Den finetunede model er bedre til at bruge den hentede kontekst, fordi den forstår dit domænes sprog og outputkrav.
Hvor lang tid tager finetuning?
For de fleste projekter, 30 minutter til 8 timer. En 8B-model med 500 eksempler på Unsloth + RTX 4090 er færdig på 15-30 minutter. Den samme opgave på en gratis Colab T4 tager 1-2 timer. 70B-modeller på A100'er tager 5-8 timer. Fuld finetuning på multi-GPU-opsætninger kan tage 20-40 timer.
Er OpenAI's finetuning-API det værd?
Til hurtig prototyping, ja. Du kan uploade en JSONL-fil og have en finetunet GPT-4o-mini på 30 minutter uden nogen GPU-opsætning. Til produktion er lokal finetuning normalt bedre: du ejer vægtene, kontrollerer din databeskyttelse, og omkostningerne er lavere i skala. De fleste teams starter med API'en for at validere tilgangen og migrerer derefter til lokal.
Konklusion
Finetuning af en LLM er ikke længere den sorte magi, det var for to år siden. Her er de vigtigste pointer:
- Start med QLoRA + Unsloth – det håndterer 90 % af use cases på forbrugerhardware
- Gode data slår en større model hver eneste gang. Brug din energi på datasætskvalitet, ikke GPU-opgraderinger.
- Prisbarrieren er væk – finetun en 8B-model for under $1 på cloud-GPU'er
- Evaluer altid mod basismodellen før deployment. Hvis den ikke er målbart bedre, så lad være med at sende den ud.
- Overvej RAG først – finetun kun når du har brug for, at modellen opfører sig anderledes, ikke bare ved andre ting
Klar til at implementere? Se vores Bedste LLM-finetuning-værktøjer og -platforme [kommer snart] for en detaljeret sammenligning af træningsframeworks og deploymentmuligheder.
Hvis du fandt denne guide nyttig, så tjek vores gennemgang om at vælge den rigtige AI-stack for de bredere arkitekturbeslutninger omkring AI-drevne produkter.
Kilder
- Unsloth GitHub-repository – finetuning-framework med 2-5x hastighedsforbedringer
- Hugging Face TRL-dokumentation – SFTTrainer, DPO og GRPO-implementering
- Hugging Face PEFT-dokumentation – LoRA og parametereffektiv finetuning
- QLoRA-paper (Dettmers et al., 2023) – forskning i 4-bit NormalFloat-kvantisering
- LoRA-paper (Hu et al., 2021) – low-rank adaptation af store sprogmodeller
- OpenAI finetuning-API-dokumentation – API-baseret finetuning-workflow
- RunPod GPU Cloud-priser – cloud-GPU-prisreference
- vLLM-dokumentation – produktionsserving af LLM'er
- Meta Llama finetuning-guide – officielle Llama-træningsanbefalinger
- DeepSeekMath-paper (GRPO) – Group Relative Policy Optimization