Ollama num_predict instellen voor output limieten

Wat num_predict doet in Ollama

num_predict is de optie in Ollama die het aantal tokens beperkt dat een model in één antwoord mag genereren. Het telt alleen de output-tokens, dus de prompt wordt hier niet in meegerekend. Wanneer het model de limiet bereikt, stopt de generatie direct, soms midden in een woord, en wordt het antwoord geretourneerd met done_reason ingesteld op length.

Dat is de volledige functionaliteit. De complexiteit zit in het feit dat Ollama drie afzonderlijke plaatsen biedt om de waarde in te stellen, waarbij de instelling die het dichtst bij het verzoek staat voorrang krijgt. Vrijwel elk rapport waarin wordt beweerd dat "num_predict niets doet", is het gevolg van de ene laag die stilletjes een andere overschrijft.

num_predict is niet hetzelfde als num_ctx

Deze twee opties worden in Ollama vaker verward dan elk ander paar, en deze verwarring kost veel tijd bij het debuggen.

num_ctx bepaalt hoeveel de het model kan lezen. Dit is de grootte van het contextvenster, dat de prompt bevat plus alles wat tot nu toe is gegenereerd. Het verhogen hiervan kost geheugen, omdat de key/value-cache die het model voor deze tokens bijhoudt, meegroeit met het venster. Het bepalen van num_ctx voor uw hardware is een aparte taak met eigen faalmodi.

num_predict bepaalt hoeveel het model zal schrijven. Dit is een stopregel, geen reservering. Het verhogen hiervan kost tijd in plaats van RAM, en er wordt vooraf niets gereserveerd.

Ze komen op één punt samen. Gegenereerde tokens belanden in het contextvenster zodra ze worden geproduceerd, dus een antwoord kan ook stoppen omdat het venster vol is in plaats van omdat uw limiet is bereikt. Ollama rapporteert length in beide gevallen, dus het getal dat ze onderscheidt is eval_count, wat verderop wordt behandeld.

Instellen met een Modelfile

Een Modelfile verwerkt de waarde in een model dat u aanmaakt. Schrijf het bestand:

FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 512

Bouw het vervolgens en lees terug wat u heeft gebouwd:

ollama create qwen3-capped -f Modelfile
ollama show --parameters qwen3-capped

ollama show --parameters print één regel per opgeslagen parameter met de bijbehorende waarde. Als num_predict ontbreekt in die uitvoer, bevat het model geen ingebouwde limiet en is de standaardwaarde van Ollama van toepassing. ollama show --modelfile qwen3-capped print de volledige definitie; dit is tevens de snelste manier om de parameters te kopiëren waarmee een bestaand model wordt geleverd. Het op deze manier aanmaken van een gelimiteerd model kost vrijwel geen extra schijfruimte, omdat het nieuwe item de weight blobs hergebruikt die het basismodel al heeft gedownload in plaats van ze te kopiëren. Het is nuttig om te weten waar Ollama deze blobs bewaart voordat de root-schijf van een VPS volloopt.

Dit is de juiste laag voor een waarde die elke aanroeper moet overerven. Het is de verkeerde laag als u verwacht dat de waarde definitief is, want dat is deze niet.

Stel dit per verzoek in via het options-object

Elk generation-endpoint accepteert een options-object, en num_predict wordt hierbinnen geplaatst:

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "prompt": "Explain what a reverse proxy does.",
  "stream": false,
  "options": { "num_predict": 128 }
}'

/api/chat gebruikt dezelfde options-sleutel met dezelfde betekenis. Een waarde die hier wordt ingesteld, is uitsluitend van toepassing op die specifieke aanroep. Dit is de laag die uw tools gebruiken: een chat-interface, een script, een SDK-wrapper of een coding agent. Ze versturen allemaal een options-object, ongeacht of ze hiervoor een invoerveld aan u tonen.

Instellen voor één sessie met de /set parameter

Binnen ollama run stelt de interactieve sessie opties in voor de rest van die sessie:

>>> /set parameter num_predict 256
>>> /show parameters

/show parameters toont wat de sessie met uw volgende bericht zal versturen; dit is de snelste manier om te bevestigen dat een wijziging is doorgevoerd. De waarde blijft behouden totdat u /bye typt. Om de instellingen te bewaren, schrijft /save qwen3-capped de huidige sessie, inclusief parameters, weg als een nieuw model. Niets wat u hier /set bereikt een andere client.

Welke instelling wint en waarom die van u genegeerd lijkt te worden

De volgorde is kort. Opties die met het verzoek worden meegestuurd, krijgen voorrang op alles. Een PARAMETER num_predict-regel in de Modelfile van het model is de fallback die wordt gebruikt wanneer het verzoek geen waarde bevat. Als beide ontbreken, geldt de ingebouwde standaardwaarde van Ollama.

/set parameter is geen derde regel. De interactieve sessie is een API-client, dus wat u daar instelt, wordt verzonden als de options van dat verzoek. Dat is precies de reden waarom het de Modelfile voor de sessie overschrijft.

Dit verklaart het volgende probleem. U voegt PARAMETER num_predict 512 toe, bouwt het model opnieuw op, en antwoorden bevatten nog steeds duizenden tokens. Uw instelling is aanwezig en ollama show --parameters bewijst dit. Deze wordt bij elk verzoek overschreven, omdat de client zijn eigen options-object met een eigen getal meestuurt; vaak een getal dat u maanden geleden in een instellingenscherm hebt ingevoerd en bent vergeten. ollama show leest het opgeslagen model. Het kan u niet tonen wat er via HTTP binnenkomt.

Controleer de serverzijde met één commando. Verstuur een verzoek dat een lang antwoord genereert, dwing een lage limiet af en lees twee velden uit:

curl -s http://localhost:11434/api/generate -d '{
  "model": "qwen3-capped",
  "prompt": "Describe the Linux boot process in detail.",
  "stream": false,
  "options": { "num_predict": 32 }
}' | jq '.done_reason, .eval_count'

Dit zou "length" en 32 moeten afdrukken. Installeer jq eerst met sudo apt install -y jq als dit ontbreekt. Een antwoord van "length" en 32 betekent dat de server de optie respecteert en dat uw applicatie iets anders verstuurt. Voor het eigen logboek van de server over een verzoek, herstart u deze met OLLAMA_DEBUG=1 in de omgeving en bekijkt u journalctl -u ollama -f terwijl uw applicatie ermee communiceert.

Negatieve waarden en de getallen die u niet moet kopiëren

num_predict accepteert ook negatieve waarden; dit zijn sentinels in plaats van aantallen. Eén negatieve waarde betekent "geen limiet, blijf genereren". Een andere waarde betekende "vul de resterende context". Sinds augustus 2026 geeft de Ollama Modelfile-referentie de standaardwaarde aan als -1, oneindige generatie, en eerdere versies van dezelfde tabel vermeldden ook -2 voor het vullen van de context.

Beschouw dit alles als versieafhankelijk, omdat het is gewijzigd. De referentie documenteerde de standaardwaarde lange tijd als 128 voordat het item eind 2024 werd gecorrigeerd, dus veel handleidingen herhalen nog steeds het oude getal. Lees de Modelfile parameter reference voor de versie die u daadwerkelijk draait en bevestig het gedrag vervolgens met de eval_count-controle hierboven. Een waarde die u op uw eigen systeem heeft geverifieerd, is betrouwbaarder dan een waarde die u ergens leest, inclusief dit bericht.

Waarom uitvoerlengte de voornaamste kostenpost is op een VPS zonder GPU

Generatie bestaat uit twee fasen met sterk uiteenlopende snelheden. Prompt-tokens worden in batches geëvalueerd, vele tegelijk. Output-tokens worden één voor één geproduceerd, waarbij elk token een volledige pass over de modelgewichten vereist. Op een VPS zonder GPU wordt die pass beperkt door de geheugenbandbreedte, waardoor één gegenereerd token veel meer kost dan één prompt-token. Omdat bij die pass elk gewicht moet worden gelezen, bepaalt het aantal bytes per gewicht de bovengrens van uw token-snelheid. Dit is de reden waarom een q4-build sneller decodeert dan hetzelfde model in q8 of fp16.

Vraag om een antwoord zonder streaming en de cijfers worden direct duidelijk:

"prompt_eval_count": 26,
"prompt_eval_duration": 107345000,
"eval_count": 237,
"eval_duration": 4289432000

De tijdsduur is in nanoseconden. In dat blok, wat het voorbeeldantwoord uit de Ollama API-documentatie is en geen meting van een specifieke server, duurden 26 prompt-tokens ongeveer 0,1 seconde, terwijl 237 output-tokens ongeveer 4,3 seconden in beslag namen. Uw eigen generatiesnelheid is eval_count gedeeld door eval_duration omgerekend naar seconden, en het is de moeite waard om tokens per seconde op uw eigen hardware te meten voordat u andere instellingen optimaliseert. Die snelheid hangt evenzeer af van het model als van de machine. Als lange antwoorden de werkelijke kostenpost zijn, wint een model dat is gebouwd voor snelle decodering, zoals Nemotron 3.5 Lightning op een VPS, de tijd terug die een lage limiet anders zou moeten beschermen.

De rekensom doet de rest. Bij 8 tokens per seconde houdt een antwoord van 2.000 tokens de machine meer dan vier minuten bezet, en het model heeft geen idee dat u slechts om een alinea vroeg. Een redenerend model besteedt een deel van dat budget aan denken voordat het een woord schrijft waar u om vroeg. Dat denken wordt, net als al het andere, token voor token gegenereerd, dus de redeneerinspanning waar u om vraagt is een andere factor in dezelfde kostenpost. Sommige modellen raken ook in een lus en herhalen een zin totdat iets ze stopt. Zonder limiet houdt dat ene verzoek een core bezet totdat het contextvenster vol is. num_predict is de instelling die dit begrenst, wat het belangrijkst is op een kleine zelfgehoste Ollama VPS waar één lang verzoek de volledige machine in beslag neemt.

Afgeknotte uitvoer is meestal de limiet, niet een defect model

De symptomen lijken op een modelstoring. Een antwoord dat midden in een zin stopt. JSON die niet kan worden geparseerd omdat de afsluitende accolade nooit is aangekomen. De reflex is om het model of de kwantisatie de schuld te geven. Lees eerst het antwoord.

done_reason beantwoordt de vraag direct. stop betekent dat het model uit zichzelf is gestopt, hetzij door het end-of-sequence token uit te zenden, hetzij door overeen te komen met een van de strings in uw stop-optie. length betekent dat de generatie is afgebroken omdat er geen ruimte meer was. Wanneer u length ziet, vergelijk dan eval_count met uw limiet: een exacte overeenkomst betekent dat num_predict het heeft gestopt, en een kleiner getal betekent dat het contextvenster als eerste vol was.

Wanneer u streamt, komen die velden aan in het laatste fragment, het fragment dat "done": true bevat. Veel clientbibliotheken verwerpen dat fragment en geven uw code alleen de tekst, wat de reden is waarom dezelfde afknotting onverklaarbaar lijkt binnen een applicatie en overduidelijk is onder curl. Als een bibliotheek het verbergt, stuur dan één verzoek met curl om erachter te komen wat de server werkelijk zei.

Eén punt extra bespaart u een verspilde middag. Het verhogen van num_predict zorgt er niet voor dat een model meer schrijft. Het verwijdert alleen een plafond. Als een antwoord eindigt op 200 tokens met done_reason van stop, heeft het model besloten dat het klaar was, en een grotere limiet verandert niets. Korte antwoorden met stop zijn een promptprobleem. Korte antwoorden met length zijn een limietprobleem.

Een waarde kiezen

• Laat de limiet voor interactieve chats onbeperkt en druk op Ctrl+C om een uit de hand gelopen antwoord te stoppen. U kijkt immers zelf mee op het scherm.
• Stel voor gescripte taken altijd een limiet in. Een onbeperkte generatie binnen een lus is de reden dat een batchtaak die tien minuten zou moeten duren, de volgende ochtend nog steeds draait.
• Stel voor gestructureerde output de limiet in boven het grootste geldige document dat u verwacht. Behandel done_reason van length vervolgens als een harde fout en probeer het opnieuw, in plaats van de incomplete output te parsen.
• Voor een coding agent hoort de waarde in de configuratie van de agent zelf thuis, omdat de agent bij elk verzoek zijn eigen opties meestuurt. Een coding agent naar Ollama laten wijzen beschrijft waar deze instellingen zich bevinden.

De limiet telt tokens, geen woorden of tekens, dus schat deze niet. Genereer één representatief antwoord zonder limiet, lees eval_count af en stel de limiet ruim daarboven in. Modelfamilies tokeniseren op verschillende manieren; een waarde die past bij een Llama-model kan hetzelfde antwoord van een Qwen 3-model op dezelfde VPS afkappen.

FAQ

Wat is het verschil tussen num_ctx en num_predict in Ollama?

num_ctx is de grootte van het contextvenster; dit bepaalt hoeveel de het model kan lezen: de prompt plus alles wat tot nu toe is gegenereerd. Dit kost geheugen, omdat de key/value-cache hiermee meegroeit. num_predict bepaalt hoeveel tokens het model in één antwoord mag schrijven. Dit kost tijd in plaats van geheugen en er wordt vooraf niets gereserveerd. Gegenereerde tokens tellen mee voor beide, dus een antwoord kan door beide worden afgebroken.

Waarom lijkt mijn instelling voor num_predict te worden genegeerd?

Omdat een waarde die met het verzoek wordt meegestuurd, een waarde overschrijft die in het model is opgeslagen. Plaats PARAMETER num_predict 512 in een Modelfile en stuur dat model vervolgens aan vanuit een chat-interface of een coding agent; de client stuurt dan zijn eigen options-object waarvan het getal voorrang krijgt. ollama show --parameters toont nog steeds uw waarde, omdat dit het opgeslagen model leest en niet kan zien wat er via HTTP binnenkomt. Stuur één verzoek met curl via "options": {"num_predict": 32} en controleer of eval_count terugkomt als 32; dit bevestigt dat de server zelf correct werkt en verplaatst de zoektocht naar uw applicatie.

Hoe kan ik zien of mijn uitvoer is afgebroken door num_predict?

Stuur het verzoek met "stream": false en lees done_reason. Een waarde van stop betekent dat het model uit zichzelf is gestopt. Een waarde van length betekent dat de ruimte op was. Vergelijk vervolgens eval_count met uw limiet: als ze exact overeenkomen, heeft num_predict het proces gestopt, en als eval_count kleiner is, is het contextvenster als eerste volgelopen. Bij streaming komen beide velden in het laatste fragment binnen met "done": true, wat veel client-bibliotheken weggooien voordat uw code het ziet.

Wat is de standaardwaarde van num_predict?

Lees dit af van uw eigen installatie in plaats van uit een artikel. Sinds augustus 2026 geeft de Ollama Modelfile-referentie de standaardwaarde aan als -1, wat betekent dat de generatie niet is begrensd. Dat item werd eind 2024 gecorrigeerd na jarenlang 128 te hebben gedocumenteerd. Negatieve waarden zijn sentinels in plaats van aantallen, en oudere versies van dezelfde tabel vermeldden ook -2 voor het opvullen van de resterende context. Controleer de Modelfile parameter reference voor uw versie en bevestig dit vervolgens met ollama show --parameters en één curl-verzoek.

Zorgt het verhogen van num_predict ervoor dat het model langere antwoorden schrijft?

Nee. Het verwijdert alleen een plafond. Als een antwoord eindigt met done_reason van stop, heeft het model besloten dat het klaar is, en een hogere limiet verandert niets. De lengte is in dat geval een kwestie van prompting: vraag om een specifieke structuur, een aantal secties of een bepaald detailniveau. Verhoog num_predict alleen wanneer done_reason terugkomt als length.