---
title: "Wat ik heb geleerd door mijn eigen model te trainen"
author: "Jakub Ćwirlej"
id: training-lessons
language: nl
url: "https://jakubcwirlej.com/nl/articles/training-lessons.md"
page: "https://jakubcwirlej.com/nl/ai-dev/"
translations:
  pl: "https://jakubcwirlej.com/pl/articles/training-lessons.md"
  en: "https://jakubcwirlej.com/articles/training-lessons.md"
  fr: "https://jakubcwirlej.com/fr/articles/training-lessons.md"
updated: 2026-10-14
words: 2651
summary: "Tien praktische lessen uit de ervaring van de auteur met het zelf trainen van taalmodellen. Ze gaan over te optimistische rekenschattingen, klein beginnen, voortdurende monitoring, geïsoleerde wijzigingen en ablatietests, de keuze van data, realistische verwachtingen, geduld tijdens plateaus en de behoefte aan meer dan één GPU. Hij besluit dat kleine, gespecialiseerde modellen van individuele makers nog steeds zinvol zijn."
summary_type: editorial
---

# Wat ik heb geleerd door mijn eigen model te trainen

Jakub Ćwirlej · taal van de tekst: NL · 2651 woorden

## Samenvatting (redactioneel)

Tien praktische lessen uit de ervaring van de auteur met het zelf trainen van taalmodellen. Ze gaan over te optimistische rekenschattingen, klein beginnen, voortdurende monitoring, geïsoleerde wijzigingen en ablatietests, de keuze van data, realistische verwachtingen, geduld tijdens plateaus en de behoefte aan meer dan één GPU. Hij besluit dat kleine, gespecialiseerde modellen van individuele makers nog steeds zinvol zijn.

## Kernpunten (redactioneel)

- De werkelijke benutting van de hardware (MFU) ligt ver onder wat de specificaties suggereren; zijn eerste model, met 1.5B parameters, bleef ondergetraind.
- Normen volgen en de antwoorden dag na dag vergelijken brengt problemen aan het licht die de loss niet laat zien; hij stapte over van AdamW naar MuonH.
- Verander één ding tegelijk; hij moest zijn dataset maar liefst drie keer van nul opbouwen.
- Vaardigheden groeien vaak sprongsgewijs na lange plateaus, en monitoring van de top10 kan vooruitgang tonen die de top1 verbergt.
- Kleine, smalle modellen die lokaal of op een CPU draaien, kunnen voordeliger zijn dan de grootste modellen, en er zelf een trainen is de beste manier om te begrijpen hoe AI werkt.

## Volledige tekst (de woorden van de auteur)

### 1. Berekeningen op papier vallen altijd te optimistisch uit

Bij het trainen van een model denken we vanzelf aan het proces van machine learning – het werk dat krachtige Nvidia-clusters in datacenters voor ons doen, of, als we meer geluk hebben, ons eigen loeikrachtige werkstation. Bij het lezen van de specificaties vergeet je makkelijk dat de reële MFU (Model FLOPs Utilization) veel lager ligt dan het marketingmateriaal van de kaartfabrikant doet vermoeden. Afhankelijk van de architectuur en de details haal je met je hardware slechts een fractie van de rekenkracht uit het silicium. Wat heb je eraan dat de kaart in FP4 rekent, als dat bij het trainen van een basismodel vanaf nul niet stabiel werkt, of als zakken onder BF16 bij de breedte van jouw model geen enkel voordeel oplevert?

Het is geen makkelijk moment wanneer je beseft dat je het geplande model niet binnen de beoogde tijd kunt trainen, en zelfs niet in de buurt van de beoogde omvang. Zeker niet als je er weken over hebt gedaan om op het punt te komen waar je met trainen kunt beginnen, en dan ineens blijkt dat het hele plan onrealistisch was. Op papier klopte toch alles! De eerste reflex is zoeken naar optimalisatiemethoden – torch compile, autocast, flash attention, FLCE, heads en minibatches waarvan de grootte is afgestemd op wat CUDA het liefst heeft. Dat werkt allemaal, maar de fysica van silicium laat zich niet bedotten. Als je een klein model traint, werkt de geringe breedte ervan tegen je. Als je je de training van een groot model niet kunt veroorloven, kun je je ook niet veroorloven het maximum uit je GPU te halen. Het kan dagen duren voor je je kaart optimaal benut, en als je TPS (Tokens Per Second) tijdens de training uiteindelijk 30-40% lager uitvalt dan je oorspronkelijk had berekend, scheelt dat dagen of zelfs weken rekentijd.

### 2. Begin altijd op de kleinst mogelijke schaal waarop je je ideeën kunt valideren

Mijn eerste model had 1.5B parameters en ik kon het amper tot drie keer Chinchilla trainen. Bij de bouw ervan maakte ik veel fouten, maar het werkte toch. Dat het zo weinig bruikbaar was, kwam vooral door ondertraining. Had ik met hetzelfde budget een tien keer kleiner model getraind, dan had ik kunnen uitpakken met een goed getraind en bruikbaar model. Ik had tijd gehad om te testen en had zeker veel fouten vermeden, waardoor ik een betere architectuur had kunnen bouwen. Grootte doet er natuurlijk toe, maar data, architectuur en rekenefficiëntie doen er nog meer toe. De kans dat je een goed model ontwerpt op basis van de literatuur, zonder tests en zonder vergissingen, is ongeveer zo groot als de kans op de jackpot in de lotto.

### 3. Een model traint zichzelf niet

Een model trainen klinkt tof, maar het is een stuk saaier dan je zou denken. In werkelijkheid is het grotendeels een proces van voortdurend experimenten opzetten, metingen doen, de resultaten van het model analyseren en oplossingen zoeken voor problemen die onderweg opduiken. Constant, de klok rond, dag na dag. Als je geen voldoening kunt halen uit kleine ontdekkingen en kleine successen, kan het je al snel te saai worden. En toch is het juist de ijzeren consequentie in het meten die alles bepaalt. Zelfs met goed gekozen trainingsparameters kan na verloop van tijd blijken dat ons model nieuwe data nodig heeft of degradeert op een manier die op het eerste gezicht moeilijk te zien is. Dat merk je niet zonder goede monitoring en voortdurende tests, en hoe minder vaak je ze doet, hoe meer tijd je verliest als het model zich ongewenst begint te gedragen.

Neem een veelvoorkomend scenario. Na een paar dagen training merk je dat het model steeds kortere antwoorden geeft en daarbij steeds zelfverzekerder wordt. De loss en de held-outset zien er goed uit, maar er is iets mis met het model. Als je de normen voortdurend analyseert en de antwoorden van het model elke dag vergelijkt met die van gisteren, kun je snel zien dat de logits oplopen en doorhebben dat het model een steeds grotere waarschijnlijkheid toekent aan bepaalde tokens. Die arrogantie is een truc van de luie optimizer – AdamW heeft een manier gevonden om ons te bedriegen: in plaats van het model iets te leren, drukt hij de loss langs een andere weg. Als je dat na een paar dagen opmerkt, verlies je misschien enkele tientallen dollars; als je de training laat lopen in de hoop dat die Nvidia-kaart al het werk wel doet, kun je honderden of duizenden dollars kwijt zijn en is het model misschien niet meer te redden.

Zelf heb ik wekenlang toegekeken hoe Adam de normen van mijn modellen opblies en zo de effectieve learning rate (LR) verlaagde, en dat ondanks de toegepaste QK-norm en een weight decay van 0.1. De training vertraagde, wat me tot wanhoop dreef, want zoals we weten geldt hier de stelling van Pythagoras: een groeiende gewichtsvector is met een constante LR steeds moeilijker te roteren. Het probleem is goed beschreven in de literatuur, maar zolang je het niet zelf ziet, begrijp je niet waarom je beter een andere optimizer kunt gebruiken. AdamW heeft tenslotte al honderden modellen helpen trainen. Ik koos uiteindelijk voor MuonH, en dat was een van de betere beslissingen die ik heb genomen. Natuurlijk kun je veel van dat soort dingen halen uit de literatuur, uit handboeken of door de papers op arXiv te volgen, maar je weet nooit hoe het bij jou zal uitpakken. Veel oplossingen die in theorie goed gedocumenteerde voordelen zouden moeten opleveren, werkten bij mij niet. Je komt er pas achter als je het zelf uitprobeert, en daarvoor moet je de vinger aan de pols houden en de vooruitgang op de voet volgen.

### 4. Voer altijd maar één wijziging tegelijk door en doe ablatietests

De afgelopen maanden heb ik honderden kleine modellen getest – zowel klassieke transformers als mijn eigen ideeën... en vandaag weet ik dat ik te weinig heb getest. Omdat ik te snel vooruit wilde, verloor ik onnodig tijd. Aantal lagen, FFN-ratio, d_model, weight tying, grootte van de heads, aantal KV-heads, batch, optimizer, recurrentie, ijlheid (sparsity), trainingsdata – er zijn tientallen factoren die het gedrag van een model beïnvloeden, en de mogelijke combinaties leveren duizenden mogelijke architecturen op. En hoewel in grote lijnen alles werkt zoals je zou verwachten na het lezen van je eerste handboek over AI-engineering, weet je niet waar je staat zolang je je eigen architectuur niet zelf hebt getest. Intussen leiden kleine wijzigingen vaak tot grote verschillen in rekenefficiëntie en benchmarks, en dat bij dezelfde dataset en batchgrootte. Als je wijzigingen niet geïsoleerd doorvoert, raak je makkelijk de draad kwijt. Ik heb die fout zelf vaak gemaakt. Niet dat de aanpassingen slecht waren. Al waren ze dat vaak wel. Het echte probleem was dat ik, als ik dan echt een stap vooruit zette, niet kon zeggen aan welke wijziging ik dat te danken had.

### 5. Begin bij de data

Hugging Face biedt een onvoorstelbare hoeveelheid trainingsdata, zeker gemeten aan de behoeften van een klein model. Je zou denken dat de zaak daarmee geregeld is: die data liggen binnen handbereik, in hoeveelheden die de behoeften van welk zolderkamerproject ook ruim overstijgen. Maar de selectie van data is veel belangrijker dan het aanvankelijk lijkt. En het feit dat ze al in kant-en-klare datasets zijn gebundeld, maakt het helemaal niet makkelijker. Dan is er nog de keuze van de juiste tokenizer, van de talen die je het model wilt leren, of van de verhoudingen. Bijvoorbeeld: hoeveel procent van de data uit code moet bestaan, hoeveel uit wiskunde en hoeveel uit natuurlijke taal. Vervolgens: in welke domeinen ons model zich moet specialiseren. Hoe dieper je het bos in gaat, hoe meer mogelijkheden. Zelf moest ik mijn dataset maar liefst drie keer van nul opbouwen. Ik had ook een paar kleinere missers, zoals een lek van het instruct-template dat ik bij het voorbereiden van de data niet had opgemerkt. Elke keer dwong zo'n vergissing me de training uren of zelfs dagen terug te draaien.

### 6. Verwacht niet te veel

Als je ziet hoe grote en kleinere labs telkens weer de grenzen verleggen van wat AI kan, krijg je makkelijk de indruk dat het trainen van een bruikbaar model eigenlijk een eenvoudige zaak is. Er zijn echter redenen waarom het verleggen van die grenzen miljarden dollars kost. Dat jouw model met een menselijke stem begint te praten of goede resultaten haalt op populaire benchmarks, zegt niets over zijn uiteindelijke kwaliteit of bruikbaarheid. Modellen leren aan het begin, in de eerste dagen van de training, heel snel, maar de strijd om elk volgend procentje in de resultaten vraagt vindingrijkheid, aandacht en doorzettingsvermogen. Zeker als je dagenlang ziet hoe het model op een plateau blijft hangen of zelfs achteruitgaat. Bovendien zeggen populaire benchmarks weinig over de werkelijke mogelijkheden van een model. Je model kan goed zijn in Python en uitstekend scoren op HumanEval en MBPP, maar als het geen kennis heeft van de nieuwste bibliotheken, zal zijn bruikbaarheid in de echte wereld matig zijn.

### 7. Wapen je met geduld

Veel vaardigheden van modellen groeien sprongsgewijs. Het goed beschreven fenomeen grokking wordt vaak voorafgegaan door een langdurig plateau dat dagen kan aanhouden. Wanneer je ziet dat het model geen enkele vooruitgang boekt, terwijl je voor elk uur training dollars moet betalen voor gehuurde rekenkracht of op zijn minst voor de stroom, ga je al snel twijfelen. Je denkt: ‘Het model heeft zijn capacity bereikt, meer leert het niet’, of ‘De grote labs die tot 1000x Chinchilla trainen, gebruiken vast een paar trucs.’ Maar vaardigheden groeien vaak sprongsgewijs. Het model hoeft maar te leren een of andere functie correct af te sluiten, en ineens springt het aantal geslaagde opgaven in MBPP van één naar meer dan tien. Vaak boekt het model ook echte vooruitgang, maar als je om te besparen alleen de top1 van de antwoorden monitort in plaats van de top10, merk je dat misschien lange tijd helemaal niet. Het model moet leren meer zekerheid toe te kennen, en dat kost tijd.

### 8. Eén kaart is niet genoeg

Je zou denken dat alleen je budget je nog beperkt als je over een H100 of een RTX PRO 6000 (96 GB) beschikt. Het probleem is dat training voortdurende tests en metingen vergt, die je helpen inschatten in welk stadium je zit. Een extra GPU kan ook nodig zijn om extra trainingsdata te genereren. Zelf boekte ik aanzienlijke vooruitgang door mijn model te trainen met de STaR-methode, waarbij mijn eigen model een grote hoeveelheid opgaven genereert en de correcte daarvan aan de dataset worden toegevoegd, en met een dataset met voorbeelden van vertalingen tussen programmeertalen

Training op een krachtige kaart onderbreken zodat het model antwoorden kan genereren is erg duur en gewoonweg niet rendabel, en ernaast genereren – ook al laat het VRAM dat toe – kan een ernstig risico vormen. Het laatste wat je wilt, is na drie dagen, als de resultaten van het model achteruitgaan, ontdekken dat er tijdens het genereren naast de training op de kaart bijvoorbeeld een kortstondige ‘uithongering’ van de dataloader is opgetreden, waardoor de loss stilletjes niet meer daalde. Zulke dingen zijn in een later stadium van de training vaak bijzonder moeilijk op te sporen, zelfs als je monitoring hebt die je waarschuwt voor pieken in de normen.

### 9. Begin met iets eenvoudigs

Aan mijn eerste model begon ik vanuit de intuïtie dat je bij het trainen van een LLM de eigen activaties van het model kunt benutten, en dat het volgen ervan tijdens het leren zou moeten helpen om een slimmer en waarheidsgetrouwer model te bouwen. Vandaag kan ik me alleen maar over mezelf verbazen: wat was die aanpak naïef. Niet omdat ik nu denk dat het onmogelijk is, maar omdat ik ben gaan experimenteren met iets wat me boven het hoofd groeide, zonder enig idee van hoe het trainen van een LLM in zijn werk gaat. Ik moest me een enorme hoeveelheid kennis eigen maken en tegelijk zowel oplossingen uit de architectuur van klassieke transformers testen als mijn eigen ideeën, die – zo bleek na verloop van tijd – grotendeels onuitvoerbaar waren.

Daarbij stuitte ik op een hele reeks problemen – het activatiesignaal van de SwiGLU-gates verloor na normalisatie zijn betekenis, en zonder normalisatie gebruikte AdamW mijn modificaties om de normen van het model op te blazen. Pas na verloop van tijd begreep ik dat veel van de voordelen die ik in mijn eerste model had gevonden, voortkwamen uit een fenomeen dat leek op ruisregularisatie. Bovendien was het berekenen van de Gini uit de activaties van de SwiGLU-gates zelf rekenintensief: het voegde enkele procenten extra compute toe, die zich niet terugbetaalden in kwaliteit.

Momenteel train ik een klein model van 160M in een standaardarchitectuur, dat gespecialiseerd is in coderen. Dat was de beste beslissing die ik kon nemen, want zo gaf ik mezelf de kans iets te maken dat echt bruikbaar kan zijn. En de eerste resultaten van het model laten zien dat ik niet voor niets uit mijn fouten heb geleerd.

### 10. Bouw geen model dat goed moet zijn in alles

Gezien de astronomische kosten en de haalbaarheid zelf heeft het vandaag, om puur economische redenen, totaal geen zin dat één persoon of een kleine organisatie een model voor algemeen gebruik bouwt. De concurrentie met de reuzen, of zelfs met kleinere labs die open modellen uitbrengen, is niet te winnen zonder enorme investeringen en ervaring. Maar dat betekent helemaal niet dat het bouwen van eigen modellen zinloos is.

Je kunt je honderden toepassingen voorstellen waarin kleine modellen, van de grond af getraind of bijgetraind op unieke data, een voorsprong zullen hebben op de reuzen – en die voorsprong hoeft niet per se in kennis te liggen. Het is al genoeg dat het model snel is en lokaal kan draaien in de browser, of op de processor van een willekeurig werkstation. Voor specifieke, smalle toepassingen kan het veel rendabeler zijn een micromodel van enkele honderden miljoenen parameters te gebruiken dan de krachtigste beschikbare modellen van OpenAI of Anthropic in te zetten. Het gaat niet alleen om de kosten. Al is het verschil kolossaal. Een model dat gespecialiseerd is in een smal domein, is niet alleen veel makkelijker te trainen, maar ook te controleren en af te stemmen op de behoeften van de gebruiker. Maar het allerbelangrijkste: het is een taak die binnen het bereik ligt van een gewoon mens die bereid is zo'n uitdaging aan te gaan.

De modellen van de grote labs worden getraind op duizenden zeer dure chips. Een voorbeeld: voor het trainen van een model van de klasse Llama 3 400B was een cluster van 16.000 H100-kaarten nodig. De kosten liepen in de tientallen miljoenen dollars. De training van de nieuwste GPT Astra heeft de lat waarschijnlijk nog veel hoger gelegd. Aangezien de hele sector op krediet groeit, en grootschalige implementatie van AI bij de huidige API-kosten en kwesties rond gegevensbeveiliging bedrijfseconomisch vaak moeilijk te verdedigen is, mag je verwachten dat kleine modellen op lange termijn een steeds grotere rol zullen spelen. Kleine modellen zullen ook steeds efficiënter worden. Het zou me niet verbazen als we in de toekomst voor de meeste taken genoeg hebben aan een model van zo'n 7B parameters. Het barsten van de ‘AI-bubbel’, waarover in de media steeds vaker wordt gesproken, kan dat proces alleen maar versnellen.

Daarom vind ik het bouwen van kleine modellen diep zinvol. Ten eerste is er geen betere manier om te begrijpen hoe AI werkt dan je eigen model te trainen. Ten tweede: hoewel in grote labs de ontwikkeling van AI steeds vaker in handen is van... AI zelf, mag je verwachten dat de mensheid, als ze veiligheid serieus neemt, controle en menselijk toezicht op het trainingsproces zal eisen. Daarvoor is begrip nodig van hoe dat proces in de praktijk verloopt. Natuurlijk worden we vandaag, zodra we LinkedIn openen, overspoeld met posts over kunstmatige intelligentie van de meest uiteenlopende specialisten die tutorials en opleidingen aanbieden. Maar hoeveel van hen hebben echt hun eigen model getraind?

---

Jakub Ćwirlej — Journalist die met AI bouwt · op de site: https://jakubcwirlej.com/nl/ai-dev/
Volledige context: https://jakubcwirlej.com/context/nl.md · https://jakubcwirlej.com/llms.txt