SFT, DPO, GRPO: drie manieren om een model te fine-tunen en wanneer u welke kiest

Wanneer een bedrijf besluit een eigen taalmodel te fine-tunen, is de eerste vraag doorgaans: "Hoeveel data hebben we nodig?" De betere vraag is: "Wat willen we aan het model veranderen — en welk trainingsdoel hoort daarbij?" SFT, DPO en GRPO zijn drie verschillende antwoorden op drie verschillende problemen. De juiste methode kiezen vóórdat u data gaat verzamelen, bepaalt of het project over zes maanden werkt of niet.

Dit artikel legt niet uit hoe u een trainingsframework installeert. Het legt uit wat elke methode doet, wanneer u die inzet, hoeveel data er werkelijk nodig is, en waarom de volgorde SFT → DPO → GRPO geen toeval is.

Basis: wat is LoRA en wat is een trainingsdoel — twee verschillende concepten

Voordat we de methoden vergelijken, is het belangrijk twee zaken te onderscheiden die in discussies vaak door elkaar lopen.

LoRA (Low-Rank Adaptation) en QLoRA (de via kwantisatie gecomprimeerde variant) zijn *mechanismen* — een manier om een model fysiek aan te passen zonder alle gewichten te wijzigen. In plaats daarvan traint u kleine adaptermatrices die bovenop de bestaande modelgewichten worden gelegd. Hierdoor past het geheel in veel minder GPU-geheugen: een gewoon 7B-model kunt u met QLoRA fine-tunen op een GPU met ~9 GB VRAM, terwijl volledige fine-tuning ~70–120 GB zou vergen. Een uitgebreider vergelijking van deze mechanismen vindt u in het artikel LoRA vs QLoRA vs full fine-tuning.

SFT, DPO en GRPO zijn daarentegen *trainingsdoelen* — ze bepalen wat het model leert. Net als LoRA is ook volledige fine-tuning een mechanisme. U kunt SFT met LoRA doen, SFT met volledige fine-tuning, DPO met QLoRA — de combinaties zijn vrij te kiezen. In de praktijk gebeurt de meeste domeingerichte projecten tegenwoordig met LoRA of QLoRA, simpelweg om economische redenen, maar het trainingsdoel blijft de wezenlijke beslissing.

SFT — supervised fine-tuning: het model het juiste formaat en gedrag aanleren

SFT (supervised fine-tuning, leren onder begeleiding) is de basismethode. U geeft het model een invoer en de gewenste uitvoer, waarna het model deze paren leert nabootsen. Het is in wezen een verlengstuk van de pre-training: het model leert van voorbeelden in het formaat (prompt → antwoord).

SFT beantwoordt de vraag: *"Hoe moet het model reageren op dit type taak?"*

Wanneer SFT gebruiken

SFT is de juiste keuze wanneer:

• Het model de juiste kennis heeft, maar in het verkeerde formaat antwoordt (te lang, te beknopt, verkeerde taal, verkeerde structuur)
• U het model domeinspecifiek jargon, terminologie of communicatiestijl wilt aanleren
• U een duidelijk omschreven taak heeft met consistente patronen — denk aan documentclassificatie, entiteitsextractie, het genereren van rapporten op basis van een template
• U het gedrag van een sterker model wilt distilleren naar een kleiner model (de teacher genereert voorbeelden, de student wordt getraind)

SFT fungeert ook als basis voor alle vervolgmethoden. Een base model zonder SFT is niet betrouwbaar verder te verfijnen met DPO of GRPO — daar kom ik hieronder op terug.

Hoeveel data heeft SFT nodig

Onderzoek heeft aangetoond dat 1.000 hoogwaardige voorbeelden een aanzienlijk beter resultaat kunnen opleveren dan 100.000 voorbeelden van lage kwaliteit. Maar voor productiesystemen is een typische datasetomvang eerder 10.000–100.000 paren, omdat u de lange staart aan invoervarianten wilt dekken die in de praktijk opduiken.

Het praktische minimum voor betrouwbare resultaten in een domeinproject ligt rond de 5.000 kwalitatief goede voorbeelden die de meeste thematische gebieden beslaan waarmee het model te maken krijgt. Onder deze drempel kan het model zijn gedrag verbeteren op data die het gezien heeft, maar faalt het op varianten die het niet heeft gezien.

Voor gereguleerde sectoren (juridisch, medisch, farmacie) geldt een strengere regel: de dataset moet elke jurisdictie en elk documenttype dekken waarmee het model gaat werken. Gedeeltelijke dekking produceert een model dat met grote zekerheid antwoord geeft, ook op gebieden waar het onvoldoende trainingsvoorbeelden voor heeft — dat is slechter dan het probleem onbehandeld laten.

Wat SFT niet oplost

SFT leert het model geen *beoordeling* — het weet niet dat het ene antwoord beter is dan het andere, alleen dat zo'n antwoord bestaat. Als het model de neiging heeft om onzorgvuldig te antwoorden, te beknopt te zijn waar dat schadelijk is, of bepaalde soorten vragen te vermijden, lost SFT dat op zichzelf niet op. Daarvoor dient DPO.

DPO — direct preference optimization: het model aanleren wat beter is

DPO (direct preference optimization) traint via preferentieparen — bij elke prompt heeft u twee antwoorden: winner (het geprefereerde) en loser (het minder geprefereerde). Het model leert zijn antwoorddistributie richting de winner en weg van de loser te sturen.

DPO is een vereenvoudigde variant van het oorspronkelijke RLHF (reinforcement learning from human feedback) — het vereist geen apart reward-model, wat het een stuk goedkoper en stabieler maakt om te trainen.

DPO beantwoordt de vraag: *"Hoe moet het model beslissen wanneer er meerdere mogelijke antwoorden zijn?"*

Wanneer DPO gebruiken

DPO is de juiste keuze wanneer:

• U gedefinieerde voorkeuren heeft: wat is een beter antwoord en wat een slechter (human-verified of gevalideerd via een geautomatiseerd proces)
• U de neiging van het model om op een bepaalde ongewenste manier te antwoorden wilt verminderen — te passief, te lang, met te veel hedging-zinnen
• U de communicatietoon wilt bijstellen zonder de trainingsdata volledig te herschrijven
• U al een SFT-basis heeft en de alignment van het model verder wilt verbeteren

Hoeveel data heeft DPO nodig

Het minimaal aanbevolen aantal is ~2.000 preferentieparen met human-verified winner/loser-beoordeling. Dit is geen willekeurig getal — onder deze drempel is het preferencesignaal niet betrouwbaar te scheiden van ruis in de distributie, en kan het model overfitten op artefacten van specifieke beoordelaars.

Voor goede generalisatie wilt u een ruimere dekking: 5.000–10.000 paren die verschillende prompttypen en scenario's bestrijken, is een gangbaar productiedoel.

Belangrijker dan het getal is de kwaliteit van de beoordeling. Als winner/loser-paren inconsistent of op basis van onduidelijke criteria worden beoordeeld, leert het model een inconsistent beleid. Vóór het verzamelen van data is het essentieel een heldere rubric te hebben — wat maakt een antwoord concreet beter.

Volgorde: SFT vóór DPO is verplicht

DPO wordt toegepast op een model dat SFT heeft doorlopen — niet rechtstreeks op een base model. De reden is praktisch: een base model produceert te grote variabiliteit in antwoorden, en het DPO-signaal "verdunt" — het model heeft geen stabiele gedragsbasis waarop het preferencegradient effectief kan werken.

In de praktijk ziet het er zo uit:

1. 1.Base model → SFT → instruction-tuned model (kan consistent antwoorden op bepaalde taaptypen)
2. 2.Instruction-tuned model → DPO → aligned model (prefereert betere antwoorden boven slechtere)

SFT overslaan en DPO direct op een base model toepassen levert doorgaans instabiele resultaten op, of een model dat geen instructies volgt.

GRPO — group relative policy optimization: het model leren redeneren

GRPO (group relative policy optimization) is een methode uit de familie RL-from-rewards (reinforcement learning met beloningen). In plaats van preferentieparen krijgt het model een verifieerbare taak — een wiskundige vergelijking, een logisch probleem, een coderingsopgave — en ontvangt het een beloning op basis van de objectieve juistheid van zijn uitvoer.

GRPO kreeg bekendheid na de release van DeepSeek R1, waarbij het werd gebruikt voor reasoning-gerichte fine-tuning. Het belangrijkste voordeel ten opzichte van het oudere PPO (proximal policy optimization): GRPO vereist geen apart critic-model, wat de VRAM-vereisten verlaagt en de trainingspipeline vereenvoudigt.

GRPO beantwoordt de vraag: *"Hoe leert u een model beter te redeneren op taken waarbij het juiste antwoord verifieerbaar is?"*

Wanneer GRPO gebruiken

GRPO is de juiste keuze wanneer:

• U taken heeft met verifieerbare antwoorden — wiskunde, code, logica, SQL-query's, extractie van gestructureerde data met gouden annotatie
• U het redeneren wilt verbeteren — het vermogen van het model om meerdere stappen te doorlopen zonder context te verliezen
• U wilt dat het model chain-of-thought (redeneerketens) genereert op taken waar dat waardevol is
• U een omgeving heeft waarin de juistheid van de uitvoer automatisch beoordeeld kan worden, zonder menselijke beoordelaar

GRPO is doorgaans de derde stap in de pipeline, niet de eerste. Het model moet een solide SFT-basis hebben en idealiter ook DPO-alignment, voordat RL-training effectief werkt.

Hoeveel data heeft GRPO nodig

Het minimum zijn ~1.000 gescoorde trajecten — prompts met een verifieerbaar antwoord en een werkend beloningssignaal. De nadruk ligt op "verifieerbaar": de beloning moet consistent en automatisch berekend kunnen worden. Als de beloning afhankelijk is van subjectieve beoordeling, levert RL-training instabiele resultaten op.

In de praktijk wordt GRPO uitgevoerd op kleinere, gerichte datasets (duizenden, niet honderdduizenden) — omdat het beloningssignaal intensiever is dan een supervised signaal. Daar staat tegenover dat het verzamelen van verifieerbare beloningen duur is: u moet een metriek definiëren, een evaluator schrijven en garanderen dat de evaluator zelf geen fouten maakt.

De experimentele status van GRPO

GRPO is een actief onderzoeksgebied. Er bestaan meerdere varianten (DAPO en andere) en de community onderzoekt actief waar precies de grenzen liggen. Voor de meeste domeinprojecten in een B2B-omgeving is GRPO alleen relevant als:

• U werkt aan reasoning-zware taken (complexe analyses, meerdere regels code, technische diagnose)
• U de capaciteit heeft om een beloningsfunctie te schrijven en te valideren
• Het team ervaring heeft met RL-training — het debuggen van RL is aanzienlijk complexer dan het debuggen van SFT

Voor de meeste domeinadaptaties (stijl, terminologie, formaat) is SFT + DPO voldoende en veel stabieler.

De drie methoden naast elkaar — snelle vergelijking

SFT — supervised fine-tuning: - Invoer: (prompt, gewenst antwoord) paren - Leert: formaat, stijl, terminologie, gedrag bij specifieke taken - Minimum data: ~5.000 kwalitatief goede paren voor een domeinproductiesysteem - Volgorde: altijd de eerste stap

DPO — direct preference optimization: - Invoer: (prompt, winner-antwoord, loser-antwoord) drietallen - Leert: welk antwoord geprefereerd is, alignment, verbetering van toon en besluitvorming - Minimum data: ~2.000 human-verified preferentieparen - Volgorde: na SFT, niet vanuit een base model

GRPO — group relative policy optimization: - Invoer: prompt + automatisch beloningssignaal (verifieerbare juistheid) - Leert: redeneren, chain-of-thought, nauwkeurigheid op verifieerbare taken - Minimum data: ~1.000 gescoorde trajecten met werkende evaluator - Volgorde: na SFT (en idealiter DPO) als derde stap

Catastrofisch vergeten — de verborgen kostprijs van elke fine-tuning

Elke methode draagt het risico van catastrofisch vergeten (catastrophic forgetting): een model dat intensief getraind wordt op een smalle domein, kan degraderen op vaardigheden die niet in de trainingsdata voorkwamen. In de praktijk betekent dit: een model dat uitblinkt in het genereren van technische rapporten, kan slechter worden in het omgaan met conversatievragen of logisch redeneren buiten het domein.

PEFT-mechanismen zoals LoRA beperken dit effect, omdat ze slechts een klein deel van de gewichten aanpassen — maar ze elimineren het niet. Mitigatie in de praktijk:

1. 1.Meng domeindata in de trainingsdataset met algemene voorbeelden (5–15 % van de algemene mix)
2. 2.Evalueer het model na elke trainingsrun buiten het domein — niet alleen op domeinbenchmarks
3. 3.Bewaar de modelversie van vóór de fine-tuning als fallback

Een meer gedetailleerde blik op hoe u meet of fine-tuning heeft geholpen of geschaad, vindt u in het artikel Hoe meten of fine-tuning geholpen heeft.

Pipeline in de praktijk: van base model naar productie-deployment

In B2B-projecten waarbij we een domeinmodel hebben ingezet, ziet de typische aanpak er als volgt uit:

Fase 1 — keuze van de basis. U kiest een geschikt open-weight model (Qwen, Llama, Mistral-familie) op basis van VRAM-capaciteit en de vereiste contextlengte. Voor de meeste domeingerichte taken is een 7B–14B model de optimale prijs-prestatieverhouding. Met een GPU van 24 GB VRAM (bijv. RTX 3090/4090) werkt QLoRA 7B comfortabel; voor een 13B-model past het net. Meer over modelkeuze en GPU-sizing leest u in het artikel Welke GPU voor LLM-inferentie.

Fase 2 — verzamelen van SFT-data. U brengt de taaptypen, het gewenste antwoordformaat en de terminologie in kaart. U verzamelt of genereert 5.000–50.000 paren. Voor domeinprojecten is een goed recept: 150–200 hoogwaardige, door mensen aangemaakte seed-voorbeelden, uitgebreid met een factor 10–100 via een sterk frontier-model (Claude, GPT als teacher). Het resultaat controleert u door een steekproef handmatig te annoteren.

Fase 3 — SFT-run. Training met LoRA of QLoRA, doorgaans enkele epochs. Op een A100-GPU een kwestie van uren, niet dagen. De ruwe cloudkosten liggen in de orde van tientallen euro's per run bij een 7B-model en 10.000 voorbeelden — afhankelijk van de provider en de gebruikte GPU.

Fase 4 — evaluatie en beslissing. Een testset die alle taaptypen dekt. Als de resultaten voldoen, gaat het model naar productie. Zo niet — analyseer waar het faalt; voeg niet blindelings data toe.

Fase 5 (optioneel) — DPO. Als u de capaciteit heeft om preferentieparen te verzamelen en het model specifiek gedrag vertoont dat u wilt veranderen (niet alleen ontbrekende kennis), is DPO de juiste vervolgstap.

Fase 6 (gespecialiseerd) — GRPO. Alleen als u werkt aan een reasoning-zwaar use-case en een verifieerbaar beloningssignaal beschikbaar heeft.

Wanneer u niet moet fine-tunen

Fine-tuning is niet het antwoord op elk probleem. We hebben projecten gezien waarbij een bedrijf weken investeerde in SFT en het resultaat slechter was dan een eenvoudige RAG-pipeline met een goed prompt. Stel uzelf vóór fine-tuning de volgende vragen:

• Ligt het probleem bij wat het model niet weet (feiten, documenten) — dan is RAG efficiënter en goedkoper. Fine-tuning leert het model geen betrouwbare nieuwe feiten, het verandert alleen gedrag.
• Ligt het probleem bij een slecht formaat of een verkeerde stijl in de antwoorden — dan kan een betere systeemprompt voldoende zijn, vóórdat u in een dataset investeert.
• Heeft u voldoende kwalitatieve data om het domein te dekken — zo niet, produceert fine-tuning een model dat met zekerheid antwoord geeft, ook waar het geen basis voor heeft.

Het beslissingskader voor RAG versus fine-tuning wordt uitgebreider behandeld in het afzonderlijke artikel RAG vs fine-tuning — wanneer wat.

Veelgestelde vragen

Kan ik DPO direct vanuit een base model uitvoeren, zonder SFT?

Technisch gezien wel, maar het resultaat is doorgaans instabiel. Een base model produceert te variabele uitvoer — het DPO-gradient kan niet effectief werken omdat het model geen consistente gedragsbasis heeft. In de praktijk heeft u vrijwel altijd minimaal een SFT-pass nodig vóór DPO.

Is GRPO geschikt voor bedrijfsprojecten buiten de technologiesector?

GRPO is sterk waar u verifieerbare antwoorden heeft — wiskunde, code, gestructureerde extracties met gouden annotatie. Voor de meeste B2B-use-cases (klantenservice, documentatieassistent, rapportage) is SFT + DPO voldoende en veel eenvoudiger te implementeren en te debuggen. We raden GRPO alleen aan als het team ervaring heeft met RL-training.

Wat kost fine-tuning in de cloud voor een 7B-model?

Ruwe schatting: een SFT-run op 10.000 voorbeelden duurt op een A100-GPU in de orde van uren, met kosten in de tientallen euro's (bij goedkopere providers) tot de lagere honderden euro's (hyperscalers). De werkelijke projectkosten hangen af van het aantal iteraties, de datasetomvang en hoe vaak de training wordt herhaald na datawijzigingen. De grotere kostenpost is doorgaans het verzamelen en annoteren van data, niet de training zelf.

Wat is catastrofisch vergeten en hoe voorkomt u het?

Catastrofisch vergeten treedt op wanneer fine-tuning op een smal domein de algemene vaardigheden van het model aantast — bijvoorbeeld logisch redeneren of conversationele capaciteiten buiten het domein. U beperkt het door domeindata te mengen met algemene voorbeelden (5–15 % van de algemene mix in de dataset), het LoRA/QLoRA-mechanisme te gebruiken (minder agressieve aanpassing van de gewichten) en het model na elke trainingsrun regelmatig buiten het domein te evalueren.

Welk open-weight model raadt u aan als basis voor domein-SFT?

Voor de meeste domeinprojecten in 2026 zijn modellen uit de Qwen-, Llama- of Mistral-families in het bereik van 7B–14B een goede basis. De keuze hangt af van de contextlengte, de licentie en welk base model compatibel is met uw trainingsframework. Voor specifieke aanbevelingen met cijfers, zie Hoe een LLM-model kiezen.

*Overweegt u een eigen model te fine-tunen en weet u niet waar te beginnen — SFT, DPO of een andere methode — dan doorlopen we graag samen met u een concreet use-case en stellen we een realistisch plan op. Neem contact op via mp-is.eu of plan direct een consultatie in.*