Ollama Modelfile aanpassen: systeemprompt en parameters
Wanneer je lokaal taalmodellen draait via Ollama, maak je standaard gebruik van de basisinstellingen die door de makers van het model of het Ollama-team zijn meegegeven. In veel praktische toepassingen is dat echter onvoldoende. Je wilt bijvoorbeeld dat een model zich standaard gedraagt als een specifieke assistent, dat de uitvoer deterministisch is, of dat de contextlengte wordt vergroot. Het telkens handmatig meegeven van uitgebreide instructies of runtime-parameters bij elke API-aanroep of chatsessie is omslachtig en foutgevoelig.
Hiervoor biedt Ollama het concept van de Modelfile. Een Modelfile is een simpel tekstbestand waarin je een basismodel instelt en combineert met een vaste configuratie, een custom systeemprompt en specifieke parameters. Door het bouwen van een Modelfile ontstaat een nieuw, lokaal geregistreerd model dat met al zijn specifieke eigenschappen in één keer opgeroepen kan worden. In deze gids behandelen we hoe een Modelfile is opgebouwd, welke instructies en parameters ter beschikking staan en hoe je deze effectief beheert.
Voor het downloaden van basismodellen of het installeren van de software zelf kun je de handleidingen raadplegen over modellen downloaden en beheren en Ollama op macOS installeren. Deze gids richt zich uitsluitend op de configuratie van Modelfiles.
Wat een Modelfile is en wat het niet is
Een Modelfile kan het beste worden vergeleken met een Dockerfile. Waar een Dockerfile de opbouw van een software-container beschrijft, beschrijft een Modelfile hoe een taalmodel geladen en aangestuurd moet worden. Het bestand bundelt de volgende elementen samen tot een nieuwe model-entiteit op jouw systeem:
- Het basismodel: De gewichten van het taalmodel (bijvoorbeeld Llama, Mistral of Qwen) of een verwijzing naar een lokaal GGUF-bestand.
- De systeemprompt: De permanente gedragsinstructies die aan de basis van elke interactie liggen.
- Sampling- en runtime-parameters: Instellingen zoals de temperatuur, contextgrootte en stop-sequenties.
- De chat-template: De exacte opmaak waarmee gebruikersinvoer, systeemprompts en modelreacties aan elkaar worden geknoopt.
Het is essentieel om te begrijpen wat een Modelfile niet is: een Modelfile is geen fine-tuning. Bij fine-tuning worden de interne gewichten van een neuraal netwerk via een intensief trainingsproces aangepast op basis van een dataset. Een Modelfile past geen enkele gewichtswaarde aan. Het verandert uitsluitend de context, de voorwaarden en de decodeerinstellingen waarmee de bestaande gewichten worden geraadpleegd. Het resultaat van een ollama create commando op basis van een Modelfile is dan ook een lichtgewicht pointer naar de bestaande gewichten plus een opgeslagen configuratieset.
De belangrijkste instructies in een Modelfile
Een Modelfile wordt opgebouwd met behulp van een reeks specifieke instructies. Elk van deze instructies vervult een eigen rol in de definitie van het model. Hieronder bespreken we de instructies die ertoe doen, voorzien van een voorbeeldregel.
FROM
De FROM-instructie definieert het fundament van je nieuwe model. Dit kan een bestaand Ollama-model zijn dat al op je systeem staat of automatisch wordt binnengehaald, of een rechtstreeks pad naar een lokaal GGUF-bestand.
FROM llama3.2:3b
Of bij gebruik van een lokaal bestand:
FROM ./custom-model-q4_k_m.gguf
SYSTEM
Met SYSTEM stel je de vaste systeemprompt in. Deze instructie geeft het model zijn rol, randvoorwaarden, taalvoorkeur of uitvoerformaat mee. Bij meerregelige teksten kun je gebruikmaken van drievoudige quotes.
SYSTEM """Je bent een professionele tekstredacteur. Corrigeer taalfouten en verbeter de leesbaarheid zonder de inhoudelijke betekenis te wijzigen."""
PARAMETER
De PARAMETER-instructie stelt specifieke waarden in voor de inference-engine van Ollama. Hiermee beïnvloed je direct hoe het model tokens selecteert en hoeveel geheugen het gebruikt. Je kunt meerdere PARAMETER-regels onder elkaar plaatsen.
PARAMETER temperature 0.2
TEMPLATE
De TEMPLATE-instructie geeft aan hoe de systeemprompt, de chatgeschiedenis en de gebruikersinvoer worden samengevoegd tot één lange string die aan het model wordt gevoerd. Dit gebruikt de Go-template syntax.
TEMPLATE """{{ .System }}
User: {{ .Prompt }}
Assistant:"""
ADAPTER
Met de ADAPTER-instructie kun je een losse LoRA-adapter (Low-Rank Adaptation) toepassen op het basismodel. Dit maakt het mogelijk om specifieke, fijn-afgestemde lagen over een bestaand basismodel te leggen.
ADAPTER ./my-custom-lora.bin
MESSAGE
De MESSAGE-instructie stelt je in staat om vooraf gedefinieerde dialogen aan te reiken (few-shot prompting). Dit helpt om het gewenste in- en uitvoerformaat aan het model te demonstreren voordat de gebruiker vragen stelt.
MESSAGE user Hoe maak ik een opsommingsteken in HTML?
MESSAGE assistant Gebruik de <li>-tag binnen een <ul>- of <ol>-element.
LICENSE
Met LICENSE kun je de licentievoorwaarden van het afgeleide model vastleggen. Dit is vooral van belang als je het opgebouwde model wilt exporteren of delen binnen een organisatie.
LICENSE """MIT License"""
In-depth: De belangrijkste PARAMETER-waarden
De werking van een taalmodel hangt sterk af van de parameters die de logit-verwerking en sampling sturen. In een Modelfile kun je deze parameters exact afstemmen op jouw toepassingsgebied.
| Parameter | Standaardrichting | Effect van te hoge waarde | Effect van te lage waarde |
|---|---|---|---|
temperature |
0.0 - 1.0 | Model wordt onsamenhangend en hallucineert. | Model wordt repetitief, star en rigide. |
top_p |
0.1 - 1.0 | Verhoogt de diversiteit, maar vermindert focus. | Beperkt het vocabulaire te sterk tot voorspelbare woorden. |
top_k |
1 - 100 | Laat zeldzame tokens toe; risico op grammaticafouten. | Sluit relevante synoniemen uit; antwoorden worden eentonig. |
repeat_penalty |
1.0 - 1.2 | Model vermijdt noodzakelijke herhalingen en synoniemen. | Model vervalt snel in herhalende lussen van woorden of zinnen. |
repeat_last_n |
0 - 256 | Controleert te ver terug; kost extra rekenkracht. | Controleert te kort terug; herhalingen op zinsniveau worden niet opgemerkt. |
num_ctx |
2048 - 131072 | Hoge geheugendruk; risico op terugval naar CPU. | Vroegtijdig verlies van informatie uit de conversatie. |
num_predict |
-1 (onbeperkt) | Antwoorden worden onnodig lang of blijven doorlopen. | Uitvoer wordt midden in een zin of redenering afgebroken. |
seed |
Willekeurig | Geen effect (is een specifiek geheel getal). | Geen effect (is een specifiek geheel getal). |
stop |
Modelafhankelijk | Geen direct bereik (strings). Stop op verkeerde tekens. | Model stopt niet waar gewenst en genereert extra rollen. |
Gedetailleerde analyse van de kernparameters
temperature: Deze parameter stuurt de willekeurigheid van de token-selectie. Een hoge temperatuur (bijv. 0.8 of hoger) zorgt ervoor dat het model minder waarschijnlijke tokens kiest, wat nuttig is voor creatieve taken. Een lage temperatuur (bijv. 0.1) dwingt het model om steeds de meest waarschijnlijke tokens te kiezen. Zet je de temperatuur op 0.0, dan schakelt het model over op zogenaamde 'greedy decoding'.
top_p en top_k: Dit zijn sampleringstechnieken om de token-selectie te beperken. top_k beperkt de keuze tot de top K meest waarschijnlijke volgende woorden. top_p (nucleus sampling) kijkt naar de cumulatieve waarschijnlijkheid: het kiest uit de kleinste verzameling tokens waarvan de opgetelde kans de waarde P bereikt. Het verlagen van top_p helpt om ruis uit de antwoorden te filteren.
repeat_penalty en repeat_last_n: De repeat_penalty bestraft tokens die recent al in de tekst zijn voorgekomen. Een waarde van 1.0 betekent geen straf. Een waarde van 1.15 ontmoedigt herhaling. De parameter repeat_last_n geeft aan hoeveel tokens het model terugkijkt om herhalingen vast te stellen (standaard vaak 64). Als je merkt dat een model vastloopt in een oneindige lus van dezelfde zinnen, verhoog je de repeat_penalty.
Het contextvenster (num_ctx) uitgelicht
Een van de belangrijkste instellingen in de Modelfile is num_ctx, waarmee de grootte van het contextvenster in aantallen tokens wordt ingesteld. Standaard hanteren veel modellen in Ollama een relatief klein venster van 2048 of 4096 tokens ter behoud van werkgeheugen. Moderne architecturen kunnen vaak 32.000 tot 128.000 tokens aan, maar het vergroten van deze waarde heeft directe gevolgen voor de hardwarebelasting.
Het verwerken van de context vereist dat het KV-cache (Key-Value cache) in het geheugen opgeslagen wordt. Naarmate num_ctx toeneemt, groeit het geheugengebruik kwadratisch of lineair afhankelijk van de aandachtsgrootte van het model. Wanneer de totale geheugenbehoefte (het model plus de KV-cache) het beschikbare videogeheugen (VRAM) van de videokaart overschrijdt, zal Ollama genoodzaakt zijn om een deel van de lagen van de GPU naar het systeemgeheugen (RAM) en de CPU te verplaatsen.
Het effect van deze verplaatsing is een dramatische daling in de verwerkingssnelheid (generatiesnelheid uitgedrukt in tokens per seconde). Je merkt dat dit gebeurt wanneer de verwerkingstijd voor het genereren van de eerste token (de 'time to first token' of prompt-evaluatieduur) enorm oploopt, of wanneer de ventilatoractiviteit van de GPU afneemt terwijl de CPU-belasting naar 100% piekt. Bepaal dus zorgvuldig hoeveel context je daadwerkelijk nodig hebt voor jouw toepassing en test dit op je lokale hardware. Meer achtergronden over hoe tokens verwerkt worden vind je op de pagina over tokenisatie uitgelegd.
Reproduceerbaarheid: seed en temperature 0
In veel softwaretoepassingen, geautomatiseerde pipelines of testomgevingen is willekeur ongewenst. Je wilt dat het model bij exact dezelfde invoer elke keer exact dezelfde uitvoer geeft. Dit is cruciaal bij het vergelijken van prompt-aanpassingen, automatische evaluaties of het genereren van gestructureerde data zoals JSON.
Om een model volledig deterministisch te maken, combineer je twee instellingen in de Modelfile:
PARAMETER temperature 0
PARAMETER seed 42
Door temperature op 0 te zetten, kiest het model bij elke stap steeds het token met de hoogste kans. De seed (een willekeurig gekozen geheel getal, zoals 42) zet de pseudo-willekeurige nummergenerator vast op een vast punt. Dit garandeert dat zolang de hardware-architectuur en de softwareversie gelijk blijven, de uitvoer identiek is. Dit principe staat centraal bij het uitvoeren van gestructureerde tests; lees hierover meer op de pagina over reproduceerbaarheid in benchmarks.
Stop-sequenties instellen
De parameter stop geeft aan op welke specifieke karakterreeksen de inference-engine de generatie onmiddellijk moet afbreken. Zodra het model de opgegeven stop-sequentie genereert, stopt het proces en wordt de stop-sequentie zelf niet aan de gebruiker getoond.
Het handmatig instellen van stop-sequenties is van groot belang bij het bouwen van gestructureerde toepassingen, agents of chat-interfaces waar duidelijke rolscheidingen gelden. Een voorbeeld van stop-sequenties in een Modelfile:
PARAMETER stop "<|im_end|>"
PARAMETER stop "Gebruiker:"
PARAMETER stop "---"
Wees voorzichtig met het kiezen van stop-sequenties. Als je een stop-sequentie instelt die ook in normale tekstuitvoer kan voorkomen (zoals een enkele punt, een spatie of een veelgebruikt woord), zal het model de reactie halverwege abrupt afkappen. Gebruik daarom uitsluitend unieke tokens of duidelijke scheidingstekens die niet in het inhoudelijke antwoord thuishoren.
Systeemprompts schrijven voor kleinere lokale modellen
Het schrijven van een systeemprompt voor een lokaal model van 3B, 7B of 8B parameters vereist een andere aanpak dan het instrueren van hele grote cloudmodellen. Kleiner modellen hebben een beperkter vermogen om complexe, verhalende of tegenstrijdige instructies correct te verwerken en te onthouden gedurende een conversatie.
Wanneer een systeemprompt voor een klein model te lang of te verhalend is, treedt er vaak 'instruction drift' op: het model vergeet de randvoorwaarden of raakt in de war over de prioriteiten. Meer diepgaande adviezen hierover worden behandeld op de pagina over prompting voor kleinere modellen.
Hanteer bij het opstellen van de SYSTEM-instructie in een Modelfile de volgende uitgangspunten:
- Kort en concreet: Beperk de prompt tot de kern. Vermijd uitvoerige achtergrondverhalen of beleefdheidsvormen.
- Gebiedende wijs: Gebruik directe opdrachten (bijv. "Vertaal de tekst", "Antwoord in JSON", "Gebruik maximaal 50 woorden").
- Expliciete uitvoereisen: Vermeld direct wat wel en wat absoluut niet mag (bijv. "Geef geen inleiding of afsluiting").
- Structuur via opsommingen: Gebruik heldere afbakeningssymbolen of genummerde regels binnen de systeemprompt.
Als je wilt dat het model specifiek in het Nederlands van hoge kwaliteit antwoordt, bekijk dan de richtlijnen over beter Nederlands genereren met lokale LLM's.
Praktijkvoorbeeld 1: Nederlandstalige samenvat-assistent
Hieronder staat een compleet uitgewerkt voorbeeld van een Modelfile, ontworpen om van lange teksten een beknopte, Nederlandstalige samenvatting te maken volgens vaste regels.
Maak een bestand genaamd Modelfile.samenvatting en voeg de volgende inhoud toe:
# Basismodel specificeren
FROM llama3.2:3b
# Sampling parameters afstellen voor gestructureerde, stabiele uitvoer
PARAMETER temperature 0.2
PARAMETER top_p 0.9
PARAMETER repeat_penalty 1.1
PARAMETER num_ctx 8192
# Vaste systeemprompt
SYSTEM """Je bent een gespecialiseerde assistent voor het samenvatten van Nederlandstalige documenten.
Hanteer altijd de volgende regels:
1. Geen inleiding of beleefdheden, begin direct met de samenvatting.
2. Schrijf in helder, professioneel Nederlands.
3. Structureer de samenvatting in maximaal 3 kernpunten met bullet points.
4. Houd de totale lengte onder de 150 woorden.
5. Gebruik uitsluitend informatie uit de opgegeven brontekst."""
Toelichting per regel
FROM llama3.2:3b: Maakt gebruik van een compact basismodel dat snel draait op lokale hardware.PARAMETER temperature 0.2: Zorgt dat het model dicht bij de feiten blijft en niet creatief gaat uitweiden.PARAMETER top_p 0.9: Filtert extreem onwaarschijnlijke woorden uit, wat de grammatica ten goede komt.PARAMETER repeat_penalty 1.1: Voorkomt dat het model zinnen uit de brontekst letterlijk blijft herhalen.PARAMETER num_ctx 8192: Verhoogt het contextvenster naar 8192 tokens, zodat er langere artikelen ingevoerd kunnen worden.SYSTEM """...""": Geeft een strikte, korte en gebiedende instructie mee voor het gewenste gedrag en formaat.
Het model bouwen en uitvoeren
Open je terminal in de map waar het bestand staat en voer het onderstaande commando uit om het model aan te maken onder de naam samenvatter:v1:
ollama create samenvatter:v1 -f ./Modelfile.samenvatting
Nadat het proces is voltooid, kun je het model direct starten en testen:
ollama run samenvatter:v1
Praktijkvoorbeeld 2: Deterministische code-assistent
In dit tweede voorbeeld passen we alleen de parameters van het basismodel aan zonder een systeemprompt op te leggen. Dit is uitermate geschikt wanneer je het originele gedrag en de chat-instructies van het basismodel wilt behouden, maar strikte, reproduceerbare uitvoer wilt afdwingen voor bijvoorbeeld code-generatie.
Maak een bestand genaamd Modelfile.code-strict met de volgende inhoud:
FROM qwen2.5-coder:7b
# Volledig deterministische instellingen
PARAMETER temperature 0.0
PARAMETER seed 1234
PARAMETER top_k 10
PARAMETER num_ctx 16384
PARAMETER stop "```"
Bouw dit model via de terminal:
ollama create code-strict:v1 -f ./Modelfile.code-strict
Dit model zal nu bij elke aanroep met dezelfde prompt exact dezelfde code opleveren, zonder variatie in de syntaxis of toelichting, wat ideaal is voor integratie in IDE's of geautomatiseerde tests. Kijk op lokale LLM in VS Code integreren voor toepassingen hiervan.
Praktische Ollama-commando's voor het beheer van modellen
Het werken met Modelfiles omvat een reeks CLI-commando's in Ollama. Hier zijn de belangrijkste opdrachten voor het dagelijks beheer:
1. Een nieuw model maken (ollama create)
Hiermee compileer je de Modelfile naar een nieuw lokaal geregistreerd model.
ollama create mijn-model:v1 -f ./Modelfile
2. De configuratie van een model inspecteren (ollama show)
Als je wilt controleren welke parameters, systeemprompt of licentie een opgebouwd model bevat, gebruik je ollama show met de gewenste vlag:
# Toon de volledige Modelfile
ollama show --modelfile samenvatter:v1
# Toon alleen de systeemprompt
ollama show --system samenvatter:v1
# Toon de toegepaste template
ollama show --template samenvatter:v1
3. Een bestaande Modelfile als startpunt uitlezen
Een handige manier om een eigen Modelfile te schrijven is door de Modelfile van een bestaand basismodel op te vragen en deze naar een bestand op te slaan. Zo zie je direct welke template het model standaard gebruikt:
ollama show --modelfile llama3.2:3b > Modelfile.basis
Vervolgens kun je dit bestand bewerken en aanpassen aan je eigen wensen.
4. Het model draaien en testen
Start een interactieve chatsessie met je aangepaste model:
ollama run samenvatter:v1
5. Modellen opruimen (ollama rm)
Wanneer een experimentele versie van een model niet meer nodig is, verwijder je het eenvoudig van je systeem:
ollama rm samenvatter:v1
Waarschuwing: Pas de TEMPLATE-instructie niet zomaar aan
Het is verleidelijk om de TEMPLATE-instructie in een Modelfile handmatig te herschrijven. De waarschuwing hiervoor is helder: doe dit alleen als je exact weet hoe het basismodel is getraind. Neem in bijna alle gevallen de bestaande template van het basismodel over.
Elk taalmodel (zoals Llama 3, Mistral of ChatML) is tijdens de alignment-fase (RLHF/SFT) getraind met zeer specifieke controle-tokens om de rollen van `system`, `user` en `assistant` van elkaar te scheiden. Wanneer je deze structuur handmatig wijzigt of vervangt door een zelfbedacht formaat, herkent het model de rolscheidingen niet meer. Dit leidt vaak tot subtiele kwaliteitsachteruitgang, zoals:
- Het model blijft de rol van de gebruiker doorschrijven in plaats van te stoppen.
- De
SYSTEM-prompt wordt volledig genegeerd. - Er verschijnen vreemde opmaaktekens of controle-tokens midden in het antwoord.
Als je een Modelfile opbouwt vanaf een standaard Ollama-basismodel (via FROM modelnaam), neemt Ollama de correcte template automatisch over. Raak de TEMPLATE-instructie dus niet aan, tenzij je een kaal GGUF-bestand importeert dat nog geen template-metadata bevat.
Beheer van Modelfiles in de praktijk
Aangezien een Modelfile een plat tekstbestand is, leent het zich uitstekend voor professioneel versiebeheer. Hanteer de volgende richtlijnen voor het effectief beheren van je Modelfiles binnen projecten:
- Gebruik versiebeheer (Git): Sla je Modelfiles op in de Git-repository van het project waarin ze gebruikt worden. Dit maakt wijzigingen in prompts en parameters inzichtelijk en herleidbaar. Zie voor verdere verdieping het artikel over prompt-versiebeheer in de praktijk.
- Hanteer een heldere naamgevingsconventie: Geef het opgebouwde model altijd een versiesuffix mee bij het aanmaken (bijvoorbeeld
analyse-assistent:v1.0ofcode-gen:2026-08). Zo voorkom je dat een automatische update een werkende configuratie ongemerkt overschrijft. - Voer regressietests uit: Stel een vaste set van minstens 5 tot 10 testprompts op. Voer deze exact gelijke prompts uit na elke aanpassing in de Modelfile om te verifiëren of de kwaliteit verbetert en er geen ongewenste neveneffecten optreden.


