Wanneer een bedrijf besluit zijn eigen LLM te fine-tunen, is de eerste vraag doorgaans niet "hoe?" maar "hebben we de hardware daarvoor?". Het antwoord hangt af van welke methode u kiest. Het verschil tussen full fine-tuning en QLoRA kan voor een 7B-model meer dan tienvoudig zijn in benodigde VRAM — en dat bepaalt of de training verloopt op één RTX 4090 of een gehuurd A100-cluster vereist.
Dit artikel behandelt de drie belangrijkste aanpakken — LoRA, QLoRA en full fine-tuning — vanuit een praktisch implementatieperspectief. U krijgt concrete cijfers, een beslissingskader en waarschuwingen voor situaties waar de goedkopere methode tekortschiet.
Basisconcepten voor wie begint
Voordat we naar de cijfers gaan, een korte verankering:
Full fine-tuning werkt alle gewichten van het model bij. Voor een 7B-model betekent dat het trainen van 7 miljard parameters — en het in het geheugen houden van gradiënten en optimizer states.
LoRA (Low-Rank Adaptation) bevriest de oorspronkelijke gewichten en voegt kleine "adapter"-matrices toe met een lage rang (rank). De training raakt alleen deze adapters, die ordes van grootte kleiner zijn dan het oorspronkelijke model.
QLoRA (Quantized LoRA) gaat een stap verder: de bevroren gewichten van het basismodel worden gekwantiseerd naar 4-bit, waardoor hun geheugenvoetafdruk radicaal afneemt. De LoRA-adapters blijven echter in hogere precisie (BF16). De training verloopt op gedekwantiseerde waarden — wat een lichte vertraging oplevert, maar een enorme VRAM-besparing.
De bepalende cijfers: VRAM per methode
Dit zijn geverifieerde cijfers voor dense modellen (dus niet MoE-architecturen zoals Llama 4 of Qwen3, waarbij de vereisten aanzienlijk hoger zijn door het laden van alle experts):
Voor een 7B-model in FP16/BF16: - Full fine-tuning: ~67 GB VRAM - LoRA: ~15 GB VRAM - QLoRA 8-bit: ~9 GB VRAM - QLoRA 4-bit: ~5 GB VRAM
Voor een 13B-model: - Full fine-tuning: ~125 GB VRAM - LoRA: ~28 GB VRAM - QLoRA 8-bit: ~17 GB VRAM - QLoRA 4-bit: ~9 GB VRAM
Voor een 70B-model: - Full fine-tuning: ~672 GB VRAM — praktisch buiten bereik voor een single-node setup - LoRA: ~146 GB VRAM — minimaal 2× A100 80GB - QLoRA 8-bit: ~88 GB VRAM — één A100 80GB met krappe marges - QLoRA 4-bit: ~46 GB VRAM — één A100 80GB comfortabel
Vuistregel voor full FT: reken ruwweg 10–16 GB VRAM per miljard parameters — de onderkant van het bereik (~10 GB, zoals in de tabel) geldt bij een 8-bit optimizer met gradient checkpointing, de bovenkant (~16 GB) bij klassiek 32-bit Adam. Het getal omvat optimizer states, gradiënten en activaties.
Een belangrijk detail: fine-tuning vereist ordes van grootte meer geheugen dan inferentie van hetzelfde model. Een 7B-model draait op 8 GB voor inferentie, maar LoRA-training ervan vereist ~15 GB. Dit is de bron van de meest voorkomende verrassing in de praktijk — "het model draait toch gewoon, waarom crasht de training?"
Wanneer welke methode zinvol is
QLoRA 4-bit is het startpunt voor iedereen zonder een dedicated trainingsserver. Een 7B-model in QLoRA 4-bit draait comfortabel op een RTX 3090 of RTX 4090 (24 GB) en met gradient checkpointing (nog eens ~30% VRAM-besparing tegen een overhead van +2% langzamere training) haalt het ook een RTX 3060 12 GB. Voor verkennend werk, proof-of-concept en instructieafstemming op kleine datasets (duizenden voorbeelden) is QLoRA 4-bit een verstandige keuze.
LoRA in FP16 is een stap omhoog in kwaliteit en in vereisten. Voor een 7B-model hebt u ~15 GB nodig — dus een RTX 4090 of A100 40GB. De kwaliteit is indicatief 90–95% van full fine-tuning. Voor de meeste domeinspecifieke taken (classificatie, extractie, instructieafstemming op bedrijfsdocumentatie) is LoRA FP16 het optimale compromis.
Full fine-tuning bevelen we aan in drie concrete gevallen: 1. Redeneren, wiskunde en coderen, waar een verschil van 5% in kwaliteit significant is 2. Continual learning — opeenvolgende fine-tunings op meerdere domeinen (hier heeft LoRA structurele zwakheden, zie hieronder) 3. Fundamentele gedragswijziging van het model, niet alleen domeinaanpassing
Voor bedrijfsimplementaties in de categorie "chatbot over eigen documentatie" of "classificatie van meldingen" is full fine-tuning doorgaans overbodig en duur. We hebben tientallen projecten gezien waarbij QLoRA of LoRA de vereiste kwaliteit bereikten tegen een fractie van de kosten.
Beslissingskader in de praktijk
Beantwoord deze vragen in volgorde om uw beslisraam te verkleinen:
1. Welk model plant u te trainen? Dense 7B of 13B: u hebt flexibiliteit. Dense 70B: QLoRA 4-bit op een A100 80GB is de realistische toegangspoort. MoE-modellen (bijv. Llama 4, Qwen3): de VRAM-vereisten liggen aanzienlijk hoger dan de actieve parameters suggereren — verifieer de concrete cijfers voor elk model vóór de hardware-planning.
2. Wat is uw doel? Instructieafstemming, domeinaanpassing, toonwijziging → LoRA of QLoRA. Redeneren, coderen, wiskunde → overweeg full FT of minimaal een hogere rank LoRA + DoRA. Sequentieel continual learning → full FT (LoRA heeft hier aangetoonde problemen).
3. Hebt u voldoende data? Voor supervised fine-tuning (SFT) zijn duizenden kwalitatieve voorbeelden het aanbevolen minimum — op voorwaarde dat ze de belangrijkste onderwerpen van het domein dekken. Trainen op onvoldoende data produceert een model dat vol vertrouwen antwoord geeft vanuit lacunes. Dat is een slechter resultaat dan een basismodel dat "dat weet ik niet" kan zeggen. De data quality gate is vóór de training belangrijker dan de keuze van de methode.
4. Wat is uw deploymentplan?
QLoRA 4-bit wordt gebruikt tijdens de training, niet in productie. Na de training wordt de adapter samengevoegd met het basismodel en gedeployed in normale precisie (BF16/FP16) — of opnieuw gekwantiseerd voor productie-serving (GGUF voor llama.cpp, AWQ/GPTQ voor vLLM). "QLoRA production model" is een misnomer die u tegenkomt in documentatie én projectplannen.
LoRA-hyperparameters: ruimte voor optimalisatie
Rank (r) is de belangrijkste hefboom. Hogere rank = meer traineerbare parameters = potentieel betere kwaliteit, maar ook meer geheugen en risico op overfitting bij kleine datasets.
Geverifieerde aanbevelingen:
- rank=4 tot rank=8: eenvoudige taken (classificatie, sjabloonantwoorden), kleine datasets
- rank=16 tot rank=32: complexere instructieafstemming, domeinaanpassing
- rank=64 en hoger: alleen wanneer u grote data én hardware-reserve hebt; hogere rank verhoogt ook het risico op "intruder dimensions" (zie hieronder)
Alpha (α) wordt standaard ingesteld op dezelfde waarde als rank, of op 2× rank. Voor de rsLoRA-variant is de theoretisch onderbouwde waarde α/√r.
Target modules: we bevelen aan te trainen op all-linear lagen — q_proj, k_proj, v_proj, o_proj plus gate_proj, up_proj, down_proj. Beperken tot alleen de attention-lagen is een ouder patroon uit 2023 dat nieuwere frameworks achter zich hebben gelaten.
DoRA en andere PEFT-varianten
DoRA (Weight-Decomposed LoRA) decomponentiseert de gewichtsupdate in magnitude en richting. In de praktijk overbrugt het ~de helft van het kwaliteitsverschil tussen LoRA en full FT, met slechts +5–10% VRAM-overhead. Beschikbaar in de PEFT-bibliotheek, Unsloth en Axolotl. Voor projecten waarbij LoRA tekortschiet maar full FT budgettair buiten bereik is, is DoRA de logische volgende stap.
GaLore optimaliseert de training rechtstreeks in de gradientruimte met lage rang — zonder expliciete adaptermatrix. De resultaten zijn vergelijkbaar met full FT bij aanzienlijk lager geheugengebruik, maar de implementatie is technisch veeleisender.
Voor doorsnee bedrijfsprojecten bevelen we aan: start met LoRA of QLoRA; schiet dat tekort, probeer dan DoRA voordat u naar full FT overschakelt.
Wat we weten over kwaliteit: intruder dimensions
Het onderzoekspaper "LoRA vs Full Fine-tuning: An Illusion of Equivalence" (2024) bracht een belangrijke waarschuwing: LoRA en full FT bereiken oppervlakkig vergelijkbare resultaten, maar via een ander mechanisme.
LoRA creëert zogenaamde "intruder dimensions" — nieuwe hoog-rankende singuliere vectoren die niet bestaan in het basismodel. Deze interfereren met de oorspronkelijke representatieruimte, wat zich uit bij continual learning — dat wil zeggen wanneer u het model sequentieel traint op meerdere domeinen. LoRA vertoont in dat scenario uitgesproken catastrofaal vergeten vergeleken met full FT.
Voor eenmalige fine-tuning op één domein (wat 90% van de bedrijfscases betreft) is deze beperking praktisch irrelevant. Als u echter van plan bent het model doorlopend bij te schaven op nieuwe data of nieuwe domeinen, is full FT of continual learning met een replay buffer de veiligere aanpak.
Verwant artikel: SFT, DPO, GRPO — welke methode wanneer
Frameworks in 2026
Vier tools dekken de volledige stack en concurreren op de details:
`Unsloth` is het snelste single-GPU-framework — 2–5× sneller dan de standaard HuggingFace-pipeline bij ~70% VRAM-besparing ten opzichte van full fine-tuning. Triton-fused kernels, gradient checkpointing als standaard, ondersteuning voor Qwen3, Llama 4 en MoE-architecturen. Open source voor single-GPU; multi-GPU gedistribueerde training valt achter de Unsloth Pro-abonnementsgrens.
`TRL` van HuggingFace is de standaard voor alignment-methoden — SFT, DPO, GRPO, ORPO in één bibliotheek. Goed gedocumenteerd, geïntegreerd in het Transformers-ecosysteem.
`Axolotl` is een YAML-gedreven productie-pipeline — geschikt voor het opschalen naar meerdere GPU's en complexere pipelines (QAT, sequence parallelism, reward modeling). Voor projecten waarbij een herhaalbare, geversioneerde trainingsopzet vereist is.
`LLaMA-Factory` combineert GUI en CLI en ondersteunt het breedste modelaanbod — geschikt voor teams waarbij de training niet uitsluitend door ML-engineers wordt uitgevoerd.
Praktische keuze: voor een intern proof-of-concept begint u met Unsloth (laagste instapdrempel, snelste iteratie). Voor een productiepipeline met opschaling overweegt u Axolotl. Voor alignment-experimenten (DPO/GRPO) kiest u TRL.
Meer over het evalueren van resultaten: Hoe meet u of fine-tuning heeft geholpen
Wat u doet met een getrainde adapter
Een LoRA-adapter is een klein bestand (doorgaans enkele tot tientallen MB) dat onafhankelijk van het basismodel kan worden gedeeld en geversioneerd. Voor deployment hebt u twee opties:
Samenvoegen met het basismodel: peft.merge_and_unload() voegt de adaptermatrices samen met de oorspronkelijke gewichten. Het resultaat is een volwaardig model zonder runtime-overhead. Aanbevolen voor productie.
Runtime loading: de adapter wordt dynamisch geladen tijdens inferentie. Flexibel bij experimenten (meerdere adapters voor hetzelfde basismodel), maar voegt latency toe.
Na het samenvoegen kunt u het model kwantiseren voor efficiëntere serving — GGUF voor llama.cpp en Ollama, AWQ of GPTQ voor vLLM. Dit is de standaard productiestroom: training in QLoRA 4-bit → adapter samenvoegen → kwantiseren voor serving.
Verwante onderwerpen: Kwantisatie van LLM's (GGUF, AWQ, GPTQ) en Klein gefinetuned vs. groot basismodel
Veelgestelde vragen
Is QLoRA alleen een goedkopere versie van LoRA? Niet helemaal. QLoRA kwantiseert de bevroren gewichten van het basismodel naar 4-bit, terwijl de LoRA-adapters in BF16 blijven. Het mechanisme verschilt en de training is ~20–30% langzamer door de dekwantisatie-overhead. QLoRA is niet gratis — het is een afweging tussen VRAM en snelheid, niet simpelweg korting op kwaliteit.
Kan ik een QLoRA 4-bit model rechtstreeks in productie inzetten? Niet direct. De aanduiding QLoRA 4-bit verwijst naar het trainingsproces, niet naar het productiemodel. Na de training wordt de adapter samengevoegd met het basismodel en gedeployed in standaardprecisie, eventueel opnieuw gekwantiseerd voor efficiënte serving (GGUF, AWQ). "QLoRA production model" is een misnomer.
Waarom heeft full fine-tuning zoveel meer VRAM nodig dan inferentie? Omdat de training veel meer in het geheugen houdt dan alleen de gewichten: gradiënten (even groot als de gewichten), optimizer states (bij Adam 2× de gewichten extra) en activaties voor terugpropagatie. Een 7B-model draait voor inferentie op 8 GB; LoRA-training ervan vereist ~15 GB; full FT ~67 GB.
Wanneer schiet LoRA tekort en is full fine-tuning nodig? In drie gevallen: (1) redeneren, wiskunde, coderen — waar een kwaliteitsverschil van 5% significant is, (2) continual learning met opeenvolgende fine-tunings op meerdere domeinen (LoRA vertoont hier meer catastrofaal vergeten), (3) fundamentele gedragswijziging van het model die verder gaat dan domeinaanpassing.
Betekent een hogere LoRA-rank altijd een beter resultaat?
Niet automatisch. Een hogere rank verhoogt het geheugengebruik en de trainingstijd, maar vergroot bij kleine datasets eerder het risico op overfitting. Een hogere rank produceert ook meer "intruder dimensions", wat catastrofaal vergeten kan versterken. Voor instructieafstemming is rank=16 of rank=32 doorgaans voldoende.
Conclusie
*De keuze tussen LoRA, QLoRA en full fine-tuning is in de eerste plaats een hardwarebeslissing — en pas in de tweede plaats een kwaliteitsvraag. Voor de overgrote meerderheid van bedrijfscases (domeinspecifieke chatbots, classificatie, extractie uit documenten) bereiken LoRA of QLoRA de vereiste kwaliteit tegen een fractie van de kosten. Reserveer full fine-tuning voor situaties waar die vijf procent er werkelijk toe doen. Bij MP Industrial Solutions helpen we bedrijven deze keuze te maken op basis van concrete data — van datasetanalyse via hardwareselectie tot deployment. Als u uw eerste fine-tuning overweegt of wilt verifiëren of uw huidige opzet zinvol is, kijken we graag naar uw specifieke situatie.*