Ollama num_predict instellen voor output limiet

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. Deze instelling telt alleen de output-tokens; de prompt wordt hierbij niet meegeteld. 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.

Dit is de volledige functionaliteit. De complexiteit zit in het feit dat Ollama drie afzonderlijke locaties biedt om deze waarde in te stellen, waarbij de instelling die het dichtst bij het verzoek staat voorrang krijgt. Vrijwel elk rapport waarin wordt gesteld dat "num_predict niets doet", is het gevolg van een instelling op een hoger niveau die stilletjes wordt overschreven door een andere laag.

num_predict is niet num_ctx

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

num_ctx bepaalt hoeveel 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 de grootte 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 terwijl 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.

Stel het eenmalig in 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.

Dit is de juiste laag voor een waarde die u wilt dat elke aanroeper overerft. 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 generatie-eindpunt 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 opgegeven, 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 sturen allemaal een options-object, ongeacht of ze hiervoor een invoerveld aan u tonen.

Stel het in 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 verzenden; 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 de uwe wordt genegeerd

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, gelden de ingebouwde standaardwaarden 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 bevestigt dit. Deze wordt echter 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 reactie 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 monitort 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 voorheen "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, aangezien het is gewijzigd. De referentie documenteerde de standaardwaarde lange tijd als 128 voordat de invoer eind 2024 werd gecorrigeerd, waardoor veel handleidingen nog steeds het oude getal herhalen. Lees de Modelfile parameter reference voor de versie die u daadwerkelijk gebruikt 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 outputlengte 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, waarbij er vele tegelijk worden verwerkt. Output-tokens worden één voor één geproduceerd, waarbij elk token een volledige doorloop van de modelgewichten vereist. Op een VPS zonder GPU wordt deze doorloop beperkt door de geheugenbandbreedte, waardoor één gegenereerd token aanzienlijk meer kost dan één prompt-token.

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 weergegeven in nanoseconden. In dit blok, dat het voorbeeldantwoord uit de Ollama API-documentatie bevat in plaats van een meting op 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. 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, kan een model dat is gebouwd voor snelle decodering, zoals Nemotron 3.5 Lightning op een VPS, de tijd terugwinnen die anders door een lage limiet wordt beschermd.

De berekening 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 een alinea wenste. Sommige modellen vertonen ook lussen, waarbij ze een zin herhalen totdat ze worden gestopt. Zonder limiet houdt dat ene verzoek een core bezet totdat het contextvenster vol is. num_predict is de instelling die dit begrenst; dit is vooral van belang op een kleine zelfgehoste Ollama VPS waar één lang verzoek de volledige capaciteit van de machine in beslag neemt.

Afgekapte uitvoer is meestal de limiet, niet een defect model

De symptomen lijken op een modelstoring. Een antwoord dat halverwege een zin stopt. JSON die niet kan worden geparseerd omdat de afsluitende accolade ontbreekt. 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, door het verzenden van het end-of-sequence token of door een match met een van de strings in uw stop-optie. length betekent dat de generatie is afgebroken omdat de ruimte op was. Wanneer u length ziet, vergelijk dan eval_count met uw limiet: een exacte match betekent dat num_predict het heeft gestopt, en een kleiner getal betekent dat het contextvenster als eerste vol was.

Wanneer u streamt, komen deze velden aan in het laatste fragment, het fragment dat "done": true bevat. Veel clientbibliotheken negeren dat fragment en geven alleen de tekst door aan uw code; daarom lijkt dezelfde afkapping onverklaarbaar binnen een applicatie, terwijl het duidelijk is onder curl. Als een bibliotheek dit verbergt, stuur dan één verzoek met curl om te achterhalen wat de server werkelijk heeft gerapporteerd.

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, dan heeft het model besloten dat het klaar was en verandert een grotere limiet niets. Korte antwoorden met stop zijn een prompting-probleem. 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 houdt het scherm immers in de gaten.
• 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 onvolledige output te parsen.
• Voor een coding agent hoort de waarde in de eigen configuratie van de agent 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 uit 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 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 limieten, 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 die in het model is opgeslagen overschrijdt. Plaats PARAMETER num_predict 512 in een Modelfile en stuur dat model vervolgens aan vanuit een chat-frontend 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 functioneert en verplaatst het onderzoek 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 deze exact overeenkomen, heeft num_predict het proces gestopt. Als eval_count kleiner is, is het contextvenster als eerste volgelopen. Bij streaming komen beide velden in het laatste chunk aan met "done": true, wat veel client-libraries 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. Dit 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 verandert een hogere limiet 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.