AI-model finetunen: hoeveel kan je eigen computer aan?

Eén enkele consumenten-GPU of moderne Mac met Apple Silicon kan een bruikbaar AI-model finetunen. In de praktijk ligt de bovengrens meestal tussen 3 en 14 miljard parameters, waarbij 8 miljard parameters voor de meeste thuissystemen de beste balans biedt.

Stem de modelgrootte af op het beschikbare geheugen

Controleer het GPU-geheugen voordat u modellen downloadt of trainingstools installeert. Bij NVIDIA-hardware draait het om de beschikbare dedicated VRAM; bij Apple Silicon om het beschikbare unified memory.

Deze waarden gaan uit van QLoRA, waarbij het basismodel met 4-bits precisie wordt geladen en een kleine adapter wordt getraind. Training met volledige precisie vereist veel meer geheugen.

Een grafische kaart met 6 GB kan overweg met een 3B-model, maar de geheugenruimte blijft krap. Waarschijnlijk moet u kortere sequenties, kleine batches en gradient checkpointing gebruiken.

Een GPU met 10 tot 12 GB VRAM kan doorgaans een gekwantiseerd 7B- of 8B-model aan. Die capaciteit is voldoende voor bruikbare instruction following, zonder dat elk experiment de hele nacht hoeft te draaien.

Bij unified memory van Apple is extra voorzichtigheid geboden. Het besturingssysteem, de applicaties, het model en het trainingsproces delen allemaal dezelfde geheugenpool. Een Mac met 16 GB stelt dus niet de volledige 16 GB beschikbaar voor training.

Systeem-RAM kan GPU-geheugen niet volledig vervangen. Sommige tools kunnen modellagen naar RAM verplaatsen, maar de benodigde gegevensoverdracht maakt de training aanzienlijk trager.

Begrijp waar het geheugen aan opgaat

Begin met een globale berekening van de modelgewichten:

Het bestand met de ruwe gewichten vormt slechts een deel van de totale geheugenbehoefte. Training vereist daarnaast geheugen voor activaties, gradients, adapterparameters, tijdelijke buffers en de huidige batch.

Daarom past een 8B-model met 16-bits gewichten niet comfortabel op een GPU met 16 GB. Alleen de gewichten nemen al ongeveer 16 GB in beslag, nog voordat de training begint.

Kwantisatie slaat modelgewichten met minder bits op. QLoRA houdt het bevroren basismodel normaal gesproken op 4-bits precisie, terwijl adapterberekeningen waar nodig met een hogere precisie worden uitgevoerd.

De sequentielengte kan meer invloed op het geheugenverbruik hebben dan u misschien verwacht. Training met voorbeelden van 4.096 tokens kan aanzienlijk meer geheugen gebruiken dan training met voorbeelden van 512 tokens, ook al is het model zelf niet veranderd.

De batchgrootte heeft een vergelijkbaar effect. Door de batchgrootte per apparaat te verlagen en gradient accumulation te gebruiken, bespaart u meestal geheugen terwijl u toch een grotere effectieve batch behoudt.

Ook schijfruimte is van belang. Een lokale trainingsrun kan het basismodel, de gekwantiseerde cache, de dataset, adaptercheckpoints, logs en samengevoegde uitvoer opslaan. Reserveer minstens enkele keren de grootte van het gedownloade model als u regelmatig checkpoints wilt bewaren.

Door alleen het beste checkpoint te behouden, voorkomt u dat een kleine SSD tijdens herhaalde tests volloopt.

Wat LoRA en QLoRA daadwerkelijk veranderen

Stel u het basismodel voor als een grote, bevroren matrix en de LoRA-adapter als een kleine correctie ernaast. Bij de meeste LoRA-workflows worden de oorspronkelijke basisgewichten tijdens de training niet herschreven.

LoRA, oftewel Low-Rank Adaptation, voegt kleine trainbare matrices toe aan geselecteerde modellagen. Deze matrices leren hoe het model zijn antwoorden moet aanpassen aan de trainingsvoorbeelden.

De resulterende adapter is vaak kleiner dan 1 procent van het basismodel. Een team kan één basismodel behouden en verschillende adapters laden voor supportantwoorden, codebeoordeling, documentclassificatie of een andere afgebakende taak.

Die scheiding maakt terugdraaien ook eenvoudig. Verwijder de adapter en het oorspronkelijke modelgedrag keert terug.

QLoRA combineert LoRA met een 4-bits gekwantiseerd basismodel. Iets dat in 16-bits vorm ongeveer 16 GB inneemt, past na 4-bits kwantisatie en overhead van de indeling mogelijk binnen circa 5 tot 7 GB.

Het bespaarde geheugen biedt ruimte voor langere voorbeelden, hogere adapter-ranks of een krachtiger basismodel. Die wijzigingen kunnen belangrijker zijn dan het behoud van alle bevroren basisgewichten met 16-bits precisie.

QLoRA is het praktische uitgangspunt voor consumenten-GPU's. Standaard-LoRA met 16-bits precisie blijft zinvol wanneer er voldoende geheugen beschikbaar is en trainingssnelheid belangrijker is dan een groter model kunnen gebruiken.

Bij volledige fine-tuning wordt elke modelparameter bijgewerkt. Dit vereist veel meer geheugen, levert grote checkpoints op en vergroot het risico dat een beperkte dataset het algemene modelgedrag aantast.

Voor een eerste lokaal fine-tuningproject loont volledige fine-tuning zelden. Met LoRA en QLoRA zijn mislukte experimenten goedkoper en eenvoudiger met elkaar te vergelijken.

Kies de juiste modelindeling en trainingsstack

Download een model in safetensors of in een indeling die rechtstreeks door Apples MLX wordt ondersteund. Begin niet met het GGUF-bestand dat desktopchatapplicaties gebruiken.

Een GGUF-download kan probleemloos werken in een chatinterface, maar toch mislukken in een standaardtrainer. De gewichten zijn door de kwantisatie voor inferentie al aangepast en verpakt voor een andere runtime.

Bewaar de oorspronkelijke model-ID bij elke adapter. De adapter is afhankelijk van de modelarchitectuur, laagnamen, tokenizer en vaak ook van de exacte basisrevisie.

Een adapter die voor het ene 8B-model is getraind, kan niet zonder risico aan een ander 8B-model worden gekoppeld. Een gelijk aantal parameters betekent niet dat de interne modelstructuren compatibel zijn.

NVIDIA-systemen gebruiken doorgaans Hugging Face Transformers, PEFT, TRL en bitsandbytes. Systemen met Apple Silicon kunnen MLX examples of compatibele MLX-trainingstools gebruiken.

Het gebruiksgemak van een framework verandert niets aan de geheugenlimiet. Tools kunnen kwantisatie en het laden van checkpoints automatiseren, maar ze kunnen een 27B-model niet praktisch bruikbaar maken op een machine waarop een 8B-model maar net past.

Voor teams die rond het model een bredere lokale stack bouwen, gelden dezelfde afwegingen rond opslag en onderhoud als bij zelfgehoste productiviteitstools.

Bouw de dataset voordat u het model finetunet

Begin met een kleine dataset die precies laat zien welk gedrag het model moet leren. Twintig uitstekende voorbeelden zijn voor een eerste test waardevoller dan duizenden inconsistente records.

Een eenvoudige dataset in chatstijl kan bijvoorbeeld deze records bevatten:

jsonCopy
{"messages":[{"role":"system","content":"You classify support tickets using one category and one urgency level."},{"role":"user","content":"Payroll exports fail with error 503 for every department."},{"role":"assistant","content":"category: integration_failure\nurgency: high"}]}
{"messages":[{"role":"system","content":"You classify support tickets using one category and one urgency level."},{"role":"user","content":"Please add dark mode to the reporting dashboard."},{"role":"assistant","content":"category: feature_request\nurgency: low"}]}

Elk voorbeeld definieert de verwachte invoer en de exacte structuur van de uitvoer. Als het gewenste productieantwoord categorieën in kleine letters en twee regels gebruikt, moet elk trainingsantwoord dat patroon volgen.

Tegenstrijdige voorbeelden zorgen ervoor dat de adapter onverenigbaar gedrag gaat middelen. Als een ticket in het ene record een hoge urgentie heeft en in het andere een lage, leert het model onzekerheid aan.

Verwijder dubbele voorbeelden vóór de training. Herhaalde records kunnen ertoe leiden dat het model formuleringen uit het hoofd leert in plaats van het bredere beslispatroon te begrijpen.

Houd validatieprompts buiten de trainingsdataset. Testen met prompts die het model al heeft gezien, meet herinnering en niet of het nieuwe gedrag generaliseert.

De dataset heeft ook negatieve voorbeelden en grensgevallen nodig. Als een classifier incidenten van feature requests moet onderscheiden, voeg dan ambigue tickets toe waarin zowel operationele als productgerichte taal voorkomt.

Fine-tuning kan feiten aanleren, omdat de adapter verandert hoe het model invoer naar uitvoer vertaalt. Toch kan een kleine dataset geen exacte reproductie, volledige dekking of actuele informatie garanderen.

Stabiele interne terminologie, antwoordstructuren, beslisregels en terugkerende feiten lenen zich hier goed voor. Prijzen, voorraden, beleidsregels of incidentstatussen die vaak veranderen, kunt u beter opvragen zodra een verzoek binnenkomt.

Voer een test uit die bewijst dat het model is veranderd

Vergelijk het basismodel en het gefinetunede model met identieke prompts, generatie-instellingen en systeeminstructies. Als de uitvoer voor het beoogde gedrag niet verschilt, maken foutloze trainingslogs de run nog niet succesvol.

Gebruik een testprompt die het belangrijkste gedrag controleert:

Classificatietest

textCopy
Classify this ticket using one category and one urgency level: "Our SSO certificate expires tomorrow and users already see intermittent login failures."

Gebruik een tweede prompt om te controleren of het model nog steeds kan generaliseren:

Grensgevaltest

textCopy
Classify this ticket using one category and one urgency level: "The export works, but finance wants an option to schedule it every Friday."

Noteer beide resultaten in een eenvoudig evaluatieoverzicht:

De eerste prompt controleert of de adapter de gevraagde indeling heeft geleerd. De tweede controleert of de adapter het onderscheid begrijpt, in plaats van alleen woorden zoals export te hebben onthouden.

De derde test beschermt tegen overtraining. Een model dat de nieuwe stijl volgt maar repetitief, rigide of onsamenhangend wordt, heeft te veel algemene capaciteiten ingeruild voor de afgebakende taak.

Gebruik voor beide versies dezelfde temperatuur- en samplinginstellingen. Anders kunnen willekeurige verschillen in de gegenereerde tekst ten onrechte op trainingsverbeteringen lijken.

Veelvoorkomende fouten wijzen meestal terug naar de data- of geheugeninstellingen:

Wat vaak wordt vergeten: controleer of de adapter tijdens de inferentie daadwerkelijk is ingeschakeld. Als het basismodel correct wordt geladen maar de adapter niet wordt gekoppeld, ontstaat een overtuigende maar betekenisloze vergelijking.

Bewaar bij elke run de ID en revisie van het basismodel, de tokenizer, de datasetversie, de adapterinstellingen en de evaluatieprompts. Zonder die gegevens wordt het lastig om een goed resultaat te reproduceren.

Fine-tuning versus RAG is geen keuze tussen het een of het ander

Gebruik fine-tuning wanneer het model anders moet antwoorden. Gebruik retrieval-augmented generation, oftewel RAG, wanneer het model actuele of bronspecifieke informatie in de prompt nodig heeft.

Fine-tuning kan feiten opslaan, met name stabiele feiten die consequent in meerdere voorbeelden terugkomen. Het probleem is het onderhoud: om een aangeleerd feit te corrigeren of te verwijderen, is een nieuwe trainingsrun nodig, zonder garantie dat het feit volledig wordt gewist.

RAG voegt geselecteerde documenten tijdens een verzoek aan de prompt toe. Daarmee ondersteunt het actuele gegevens en bronverwijzingen, maar retrieval kan irrelevante passages opleveren of het juiste document missen.

De twee methoden lossen verschillende onderdelen van hetzelfde systeem op. Een gefinetunede adapter kan de antwoordstructuur en terminologie afdwingen, terwijl RAG actuele procedures, klantgegevens of beleidsteksten aanlevert.

Een supportassistent is een duidelijk voorbeeld. De adapter kan het model leren om een vaste incidentsamenvatting te geven, terwijl retrieval de nieuwste servicestatus en accountgegevens aanlevert.

Wanneer lokale fine-tuning de moeite waard is

Kies voor lokale training wanneer gegevensprivacy, reproduceerbare experimenten of doorlopend gebruik van adapters belangrijker zijn dan de benodigde installatietijd.

Voor een lokale run betaalt u geen GPU-kosten per gebruikseenheid, al brengen elektriciteit, hardwareslijtage en personeelsuren nog steeds kosten met zich mee.

Lokale fine-tuning houdt datasets en checkpoints bovendien weg van trainingsservers van derden. Dat kan de interne gegevensverwerking vereenvoudigen, maar maakt toegangscontroles, encryptie en bewaarbeleid niet overbodig.

Een gratis Google Colab-sessie is een redelijk alternatief voor een machine met 8 GB systeem-RAM of zonder ondersteunde GPU. Sessielimieten, beschikbaarheid van hardware, behoud van opslag en verbroken verbindingen maken deze optie minder voorspelbaar dan lokale hardware.

Het huren van een cloud-GPU is zinvol wanneer u kortstondig een groter model wilt testen. Dat kan goedkoper zijn dan hardware aanschaffen voor één experiment, maar bij herhaalde runs en opgeslagen checkpoints kunnen de kosten snel oplopen.

Lokale fine-tuning is minder zinvol als de gewenste feiten dagelijks veranderen. Een systeem voor documentretrieval of een betere prompt is doorgaans goedkoper in onderhoud.

Het voegt ook weinig toe als het basismodel de taak al betrouwbaar uitvoert. Test eerst verschillende directe prompts voordat u een dataset bouwt. De kleinste trainingstaak is immers de training die u kunt vermijden.

Implementatiechecklist

Begin hier

Controleer de beschikbare GPU-VRAM of het unified memory van Apple en kies vervolgens één modelgrootte uit de hardwaretabel. Houd de eerste run op maximaal 8 miljard parameters, tenzij de machine meer dan 16 GB beschikbaar heeft.

Snel resultaat

• Schrijf 20 foutloze trainingsvoorbeelden voor één meetbaar gedrag en reserveer daarna 5 andere voorbeelden voor evaluatie.
• Voer vóór de training dezelfde 5 evaluatieprompts uit op het basismodel en noteer de exacte uitvoer.

De diepte in

• Train één QLoRA-adapter, sla alle instellingen op en eis verbetering bij ten minste 4 van de 5 gereserveerde prompts.
• Herhaal de run met één gecontroleerde wijziging, zoals de kwaliteit van de dataset, de sequentielengte of de adapter-rank. Verander niet meerdere variabelen tegelijk.

Nuttige informatiebronnen

• Hugging Face PEFT Documentation - Officiële richtlijnen voor LoRA-adapters en parameter-efficiënte training.
• Transformers bitsandbytes Quantization - Officiële documentatie voor het laden van modellen met 8-bits en 4-bits precisie.
• TRL SFT Trainer - Officiële documentatie voor supervised fine-tuning met TRL SFT Trainer.
• Apple MLX LoRA Examples - Officiële LoRA-voorbeelden en trainingsscripts voor Apple Silicon.
• Google Colab FAQ - Officiële informatie over gratis sessies, limieten en beschikbare rekenkracht.

Kortom

Met ongeveer 6 GB geheugen kunt u een 3B- tot 4B-model finetunen. Met ongeveer 10 GB worden 7B- tot 8B-modellen haalbaar, terwijl 16 tot 20 GB de deur opent naar modellen van 12B tot 14B.

Voor de meeste persoonlijke workstations is een 8B-model dat met QLoRA wordt getraind het meest praktische doel. Het is groot genoeg om bruikbare gedragsveranderingen te realiseren en klein genoeg om zonder gespecialiseerde infrastructuur te testen.

De dataset bepaalt of de adapter een echte vaardigheid leert of alleen de toon van het model verandert. Vergelijk de uitvoer van het basismodel en het gefinetunede model naast elkaar, met prompts die nooit in de training zijn gebruikt.

Stem het model af op de machine, kies één afgebakend gedrag en behandel de eerste run als een experiment. Het doel is geen perfect model. Het gaat om duidelijk bewijs dat een kleine adapter het model op verzoek anders kan laten reageren.