Voordat je code aanraakt: wat je echt nodig hebt om een LLM te trainen
Een taalmodel vanaf nul trainen is niet een script downloaden en op enter drukken. Het is een engineeringproject met drie fronten die je moet oplossen vóór de eerste regel: data, rekenkracht en evaluatie. Volgens de officiële documentatie van frameworks zoals PyTorch en Hugging Face komen de meeste mislukkingen in trainingsprojecten niet door de code, maar door een gebrekkige planning van het corpus en een slecht gedimensioneerde infrastructuur.
Dit artikel beschrijft een stapsgewijze configuratie ervan uitgaande dat je een klein of middelgroot model wilt bouwen (tussen 100M en 1.500M parameters) voor een specifiek domein, niet een concurrent van de grote generalistische modellen. Als je doel een model van 70B parameters met enorme meertalige data is, wordt het budget in miljoenen dollars gemeten en schiet deze tutorial tekort: erken dat vanaf het begin.
Stap 1: definitie van de scope en het rekenkrachtbudget
Voordat je de tokenizer schrijft, bepaal je de grootte van het model op basis van de beschikbare GPU’s. De vuistregel die in de industrie wordt gebruikt, relateert trainingstokens aan parameters: een goed getraind model verbruikt doorgaans tussen 20 en 100 keer meer tokens dan parameters. Voor een model van 125M parameters is een corpus van 2.500M tot 10.000M tokens redelijk.
Schatting van VRAM en tijd
Het geheugen dat nodig is tijdens de training hangt niet alleen af van de grootte van het model. De toestanden van de AdamW-optimizer vermenigvuldigen het gewicht van het model in gemengde precisie met vier. Een model van 125M parameters kan tussen 2 en 3 GB verbruiken alleen al aan optimizer-toestanden, plus activaties en gradiënten. Op een GPU van 24 GB kun je modellen tot 300-400M parameters trainen met een kleine batch en gradient checkpointing.
Een veelgemaakte fout die ik bij beginnende teams heb gezien: aannemen dat een consumenten-RTX 4090 het mogelijk maakt een model van 1B parameters te trainen zonder technieken voor geheugenbesparing. De realiteit is dat de training na enkele stappen stopt door OOM (out of memory), en de debugtijd overtreft de trainingstijd.
Stap 2: opbouw en opschoning van het corpus
De dataset is het meest waardevolle en het meest verwaarloosde bezit. Voor een domeinmodel (juridisch, medisch, technisch, klantenservice) heb je tussen 1.000 en 10.000 miljoen tokens aan tekst van kwaliteit nodig. Als je vanaf nul begint, moet de opschoningspipeline het volgende omvatten:
- Deduplicatie op document- en paragraafniveau met MinHash of SimHash. Zonder dit memoriseert het model en raakt het overfit op herhaalde zinnen.
- Taalfiltering met een lichte classifier (fastText werkt goed) om inhoud te verwijderen die geen Spaans is als dat je domein is.
- Verwijdering van boilerplate (navigatiemenu’s, cookie-meldingen, footers) die het trainingssignaal vergiftigen.
- Heuristische kwaliteitscontrole: ratio van alfabetische tekens, gemiddelde zinslengte, aanwezigheid van n-gram-herhalingen.
Volgens sectorstudies over publieke datasets zoals C4 en The Pile wordt tussen 40% en 60% van de ruwe tekst na opschoning weggegooid. Plan de opslag daarop: een corpus van 10.000M tokens in platte tekst neemt ongeveer 40 GB in beslag.
Stap 3: domeinspecifieke tokenizer
Hergebruik de tokenizer van GPT-2 of Llama niet als je domein een eigen vocabulaire heeft. Een BPE-tokenizer die op je corpus is getraind, vermindert het aantal tokens per document en versnelt de training. De configuratie met de tokenizers-bibliotheek van Hugging Face is eenvoudig:
from tokenizers import Tokenizer, models, trainers, pre_tokenizers
tokenizer = Tokenizer(models.BPE(unk_token=»[UNK]»))
tokenizer.pre_tokenizer = pre_tokenizers.ByteLevel(add_prefix_space=False)
trainer = trainers.BpeTrainer(vocab_size=32000, special_tokens=[«[PAD]»,»[UNK]»,»[BOS]»,»[EOS]»])
tokenizer.train_from_iterator(corpus_iter, trainer=trainer)
tokenizer.save(«tokenizer_dominio.json»)
Een vocabulaire tussen 32.000 en 50.000 tokens dekt algemeen Spaans goed. Voor technische domeinen met veel acroniemen kun je 48.000 overwegen. Controleer de compressieratio: als je tokenizer gemiddeld meer dan 1,4 tokens per woord genereert, heb je waarschijnlijk meer vocabulaire nodig of een representatiever trainingscorpus.
Stap 4: architectuur van het model en initiële configuratie
Voor een model vanaf nul is een decoder-only architectuur van het GPT-type de standaard. De configuratie moet coherent zijn: verborgen dimensie (d_model), aantal lagen, attention-heads en feed-forward-dimensie. Een regel die werkt: feed-forward = 4 × d_model, en een aantal heads zodanig dat de dimensie per head 64 of 128 is.
Voorbeeldconfiguratie voor een model van 125M
{
«vocab_size»: 32000,
«hidden_size»: 768,
«num_hidden_layers»: 12,
«num_attention_heads»: 12,
«intermediate_size»: 3072,
«max_position_embeddings»: 1024,
«hidden_act»: «gelu»,
«dropout»: 0.1
}
Met deze configuratie heeft het model ongeveer 125M parameters. Als je GPU 16 GB heeft, verlaag je de batch per apparaat naar 8 en gebruik je gradiëntaccumulatie van 4 voor een effectieve batch van 32. De typische initiële learning rate is 3e-4 met een cosinus-scheduler en warmup van 2.000 stappen.
Stap 5: trainingsloop met PyTorch en Accelerate
De minimaal levensvatbare configuratie gebruikt transformers met Trainer of een handmatige loop met accelerate. Voor volledige controle heeft de handmatige loop de voorkeur. De kritieke punten:
- Gemengde precisie (fp16 of bf16) met torch.cuda.amp. Op Ampere-GPU’s of hoger is bf16 stabieler.
- Gradient checkpointing geactiveerd als het model niet in het geheugen past.
- Opslaan van checkpoints elke 500 stappen, niet elke epoch. Bij grote modellen kan één epoch onhaalbaar zijn.
- Evaluatie van perplexiteit op een validatieset van 5% van het corpus.
Een detail dat je alleen in de praktijk leert: de loss kan stabiel lijken, maar de validatieperplexiteit kan divergeren als het validatiecorpus een andere distributie heeft. Zorg ervoor dat de validatie willekeurig uit hetzelfde schone corpus wordt gehaald, niet uit een andere bron.
Stap 6: evaluatie en alarmsignalen
Perplexiteit is niet genoeg. Je moet het model evalueren op concrete taken: tekstgeneratie, classificatie of vraagbeantwoording. Voor een klein model gebruik je lichte benchmarks zoals een subset van de redeneertaak of handmatige generatietests met prompts uit je domein.
Signalen dat er iets misgaat:
- Loss die daalt maar incoherente generatie: waarschijnlijk overfitting door duplicaten in het corpus.
- Validatieperplexiteit die na een minimum stijgt: learning rate te hoog of corpus te klein voor de grootte van het model.
- Herhalingen in de generatie: gebrek aan diversiteit in het corpus of slecht getrainde tokenizer.
Stap 7: fine-tuning en deployment
Een basismodel dat vanaf nul is getraind, volgt geen instructies op. Voor praktisch gebruik heb je een instructiefase of supervised fine-tuning nodig met vraag-antwoordparen uit je domein. Deze fase is lichter: tussen 10.000 en 100.000 voorbeelden van kwaliteit zijn doorgaans voldoende voor een klein model.
Deployment met vLLM of llama.cpp maakt het mogelijk het model te serveren met kwantisering naar 8 of 4 bits, wat de VRAM-vereisten vermindert. Een model van 125M gekwantiseerd naar 4 bits neemt minder dan 100 MB in beslag en kan op CPU draaien, hoewel de latentie hoger zal zijn.
Beperkingen die je moet accepteren
Vanaf nul trainen garandeert geen kwaliteit. Een model van 125M dat met 5.000M Spaanse tokens is getraind, zal beperkte feitelijke kennis hebben en vaak hallucineren. Het concurreert niet met grotere voorgetrainde modellen. Als je doel een algemene conversationele assistent is, is fine-tuning van een bestaand model efficiënter in kosten en tijd. Trainen vanaf nul is zinvol wanneer je volledige controle nodig hebt over het vocabulaire, de licentie of de architectuur, of wanneer je trainingsdynamieken onderzoekt.
Volgens de officiële documentatie van PyTorch en de gidsen van Hugging Face kan de kosten van een training van 125M parameters met 5.000M tokens op één enkele GPU van 24 GB variëren van meerdere dagen tot een week, afhankelijk van de throughput. Er zijn geen snelwegen: de datapipeline kost evenveel tijd als de training.
Als je besluit door te gaan, begin dan met een corpus van 500M tokens en een model van 50M parameters. Valideer de volledige pipeline voordat je opschaalt. De ervaring leert dat 80% van de fouten in de eerste 24 uur van de training verschijnt en gemakkelijker te corrigeren is met een klein model.