Ollama num_predict: Ausgabelänge begrenzen

Bedeutung von num_predict in Ollama

num_predict ist die Ollama-Option, die begrenzt, wie viele Tokens ein Modell in einer einzelnen Antwort generieren darf. Gezählt werden nur die Ausgabe-Tokens. Der Prompt wird daher nicht auf dieses Limit angerechnet. Wenn das Modell das Limit erreicht, stoppt die Generierung an dieser Stelle, möglicherweise mitten in einem Wort. Die Antwort enthält dann für done_reason den Wert length.

Das ist die gesamte Funktion. Die Schwierigkeit besteht darin, dass Ollama drei separate Stellen zum Festlegen dieses Werts bietet. Es gilt die Einstellung, die der Anfrage am nächsten liegt. Fast jeder Bericht, dass „num_predict nichts bewirkt“, beruht darauf, dass eine Ebene eine andere stillschweigend überschreibt.

num_predict ist nicht num_ctx

Diese beiden Optionen werden in Ollama häufiger als jedes andere Paar verwechselt. Die Verwechslung kostet bei der Fehlersuche viel Zeit.

num_ctx legt fest, wie viel das Modell lesen kann. Es ist die Größe des Kontextfensters. Dieses enthält den Prompt und alles, was bisher erzeugt wurde. Ein größeres Kontextfenster benötigt mehr Speicher, weil der Key/Value-Cache des Modells für diese Tokens mit dem Fenster wächst. num_ctx für Ihre Hardware dimensionieren ist eine separate Aufgabe mit eigenen Fehlerursachen.

num_predict legt fest, wie viel das Modell schreiben wird. Es ist eine Abbruchbedingung und keine Speicherzuweisung. Ein höherer Wert kostet Zeit, aber keinen zusätzlichen RAM. Im Voraus wird kein Speicher reserviert.

Beide Werte wirken an einer Stelle zusammen. Erzeugte Tokens werden während der Ausgabe in das Kontextfenster aufgenommen. Eine Antwort kann daher auch enden, weil das Fenster voll ist und nicht weil Ihr Limit erreicht wurde. Ollama meldet in beiden Fällen length. Die Zahl, die zwischen den beiden Fällen unterscheidet, ist eval_count. Darauf wird weiter unten eingegangen.

Einmalig mit einer Modelfile festlegen

Eine Modelfile übernimmt den Wert dauerhaft in ein von Ihnen erstelltes Modell. Schreiben Sie die Datei:

FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 512

Erstellen Sie anschließend das Modell und lesen Sie den übernommenen Wert aus:

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

ollama show --parameters gibt für jeden gespeicherten Parameter eine Zeile mit seinem Wert aus. Wenn num_predict in dieser Ausgabe fehlt, enthält das Modell keine festgelegte Obergrenze, und es gilt der Standardwert von Ollama. ollama show --modelfile qwen3-capped gibt die vollständige Definition aus. Das ist auch der schnellste Weg, die Parameter zu kopieren, mit denen ein vorhandenes Modell bereits ausgeliefert wird.

Diese Ebene ist für einen Wert geeignet, den jeder Aufrufer übernehmen soll. Sie ist nicht geeignet, wenn der Wert endgültig sein soll, denn das ist er nicht.

Für jede Anfrage im Optionsobjekt festlegen

Jeder Generierungsendpunkt akzeptiert ein options-Objekt. num_predict wird darin angegeben:

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 verwendet denselben options-Schlüssel mit derselben Bedeutung. Ein Wert an dieser Stelle gilt nur für diesen einen Aufruf und für nichts anderes. Das ist die Ebene, die Ihre Tools verwenden: ein Chat-Frontend, ein Skript, ein SDK-Wrapper oder ein Coding-Agent. Sie senden alle ein options-Objekt, unabhängig davon, ob sie dafür ein Eingabefeld anzeigen.

Legen Sie es für eine Sitzung mit /set parameter fest

Innerhalb von ollama run legt die interaktive Sitzung Optionen für den Rest dieser Sitzung fest:

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

/show parameters zeigt an, was die Sitzung mit Ihrer nächsten Nachricht senden wird. Damit lässt sich am schnellsten prüfen, ob eine Änderung wirksam wurde. Der Wert bleibt bestehen, bis Sie /bye eingeben. Mit /save qwen3-capped speichern Sie die aktuelle Sitzung einschließlich der Parameter als neues Modell. Nichts, was Sie hier mit /set ausführen, erreicht einen anderen Client.

Welche Einstellung gewinnt und warum Ihre Einstellung ignoriert aussieht

Die Reihenfolge ist kurz. Mit der Anfrage gesendete Optionen haben Vorrang vor allem anderen. Eine PARAMETER num_predict-Zeile im Modelfile des Modells dient als Fallback, wenn die Anfrage keinen Wert enthält. Wenn beides fehlt, gilt der integrierte Standardwert von Ollama.

/set parameter ist keine dritte Regel. Die interaktive Sitzung ist ein API-Client. Der dort gesetzte Wert wird deshalb als options der jeweiligen Anfrage gesendet. Genau deshalb überschreibt er das Modelfile für diese Sitzung.

Damit lässt sich auch der folgende Fehler erklären. Sie fügen PARAMETER num_predict 512 hinzu, erstellen das Modell neu, und die Antworten umfassen weiterhin Tausende von Tokens. Ihre Einstellung ist vorhanden, und ollama show --parameters bestätigt das. Sie wird bei jeder Anfrage überschrieben, weil der Client ein eigenes options-Objekt mit einer eigenen Zahl sendet. Diese Zahl wurde häufig vor Monaten in einer Einstellungsmaske eingetragen und danach vergessen. ollama show liest das gespeicherte Modell. Es zeigt nicht, was über HTTP eintrifft.

Prüfen Sie die Serverseite mit einem Befehl. Senden Sie eine Anfrage, die eine lange Antwort erzeugt, setzen Sie die Begrenzung niedrig und lesen Sie zwei Felder aus:

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'

Damit sollten "length" und 32 ausgegeben werden. Installieren Sie zuerst jq mit sudo apt install -y jq, falls es fehlt. Eine Antwort mit "length" und 32 bedeutet, dass der Server die Option berücksichtigt und Ihre Anwendung einen anderen Wert sendet. Für die serverseitige Aufzeichnung einer Anfrage starten Sie den Server mit OLLAMA_DEBUG=1 in der Umgebung neu und überwachen Sie journalctl -u ollama -f, während Ihre Anwendung mit ihm kommuniziert.

Negative Werte und Zahlen, die Sie nicht übernehmen sollten

num_predict akzeptiert auch negative Werte. Dabei handelt es sich um Signalwerte und nicht um Zähler. Ein negativer Wert bedeutet „keine Begrenzung, Generierung fortsetzen“. Ein anderer stand für „verbleibenden Kontext auffüllen“. Im August 2026 gibt die Ollama-Modelfile-Referenz -1 als Standardwert für eine unendliche Generierung an. Frühere Versionen derselben Tabelle führten für das Auffüllen des Kontexts außerdem -2 auf.

Behandeln Sie diese Angaben als versionsabhängig, da sie geändert wurden. In der Referenz war der Standardwert lange Zeit als 128 dokumentiert, bevor der Eintrag Ende 2024 korrigiert wurde. Deshalb wird die alte Zahl in vielen Anleitungen weiterhin genannt. Lesen Sie die Referenz zu den Modelfile-Parametern für die von Ihnen tatsächlich eingesetzte Version. Bestätigen Sie das Verhalten anschließend mit der obigen eval_count-Prüfung. Ein Wert, den Sie auf Ihrem eigenen System überprüft haben, ist verlässlicher als ein Wert aus einer beliebigen Quelle, einschließlich dieses Beitrags.

Warum die Ausgabelänge die Hauptkosten auf einer reinen CPU-VPS verursacht

Die Generierung erfolgt in zwei Phasen mit sehr unterschiedlichen Geschwindigkeiten. Prompt-Tokens werden in Batches ausgewertet, also viele gleichzeitig. Ausgabe-Tokens werden einzeln erzeugt, und für jedes Token ist ein vollständiger Durchlauf über die Modellgewichte erforderlich. Auf einer reinen CPU-VPS wird dieser Durchlauf durch die Speicherbandbreite begrenzt. Deshalb kostet ein generiertes Token deutlich mehr als ein Prompt-Token.

Fordern Sie eine Antwort ohne Streaming an. Dann sind die Zahlen direkt sichtbar:

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

Die Zeitangaben sind in Nanosekunden. Dieser Block stammt aus der Ollama-API-Dokumentation und ist keine Messung eines bestimmten Servers. 26 Prompt-Tokens benötigten etwa 0,1 Sekunden, während 237 Ausgabe-Tokens etwa 4,3 Sekunden benötigten. Ihre eigene Generierungsrate ergibt sich aus eval_count geteilt durch eval_duration, umgerechnet in Sekunden. Einmalig die Tokens-pro-Sekunde-Rate auf Ihrer eigenen Hardware zu messen lohnt sich, bevor Sie andere Einstellungen anpassen. Diese Rate hängt ebenso stark vom Modell wie von der Maschine ab. Wenn lange Antworten die eigentlichen Kosten verursachen, kann ein für schnelles Decoding ausgelegtes Modell wie Nemotron 3.5 Lightning auf einer VPS einen Teil der Zeit einsparen, die eine niedrige Obergrenze ansonsten begrenzt.

Die Rechnung zeigt den Rest. Bei 8 Tokens pro Sekunde hält eine Antwort mit 2.000 Tokens die Maschine mehr als vier Minuten beschäftigt. Das Modell weiß nicht, dass Sie nur einen Absatz wollten. Einige Modelle geraten außerdem in Schleifen und wiederholen eine Phrase, bis sie gestoppt werden. Ohne Obergrenze bleibt ein einzelner Request so lange auf einem CPU-Kern aktiv, bis das Kontextfenster erschöpft ist. num_predict ist die Einstellung, die diese Ausgabe begrenzt. Das ist besonders auf einer kleinen selbst gehosteten Ollama-VPS wichtig, auf der ein einzelner langer Request die gesamte Maschine auslasten kann.

Abgebrochene Ausgaben sind normalerweise eine Begrenzung und kein fehlerhaftes Modell

Die Symptome sehen nach einem Modellfehler aus. Eine Antwort endet mitten im Satz. JSON lässt sich nicht parsen, weil die schließende Klammer fehlt. Der erste Reflex ist, dem Modell oder der Quantisierung die Schuld zu geben. Prüfen Sie zuerst die Antwort.

done_reason bedeutet, dass die Antwort die Frage direkt beantwortet. stop bedeutet, dass das Modell selbstständig fertig wurde, entweder durch Ausgabe seines End-of-Sequence-Tokens oder durch Übereinstimmung mit einer der Zeichenfolgen in Ihrer Option stop. length bedeutet, dass die Generierung abgebrochen wurde, weil kein Platz mehr verfügbar war. Wenn length angezeigt wird, vergleichen Sie eval_count mit Ihrer Obergrenze: Eine exakte Übereinstimmung bedeutet, dass num_predict die Generierung beendet hat. Eine kleinere Zahl bedeutet, dass das Kontextfenster zuerst gefüllt war.

Beim Streaming treffen diese Felder im letzten Chunk ein, der "done": true enthält. Viele Client-Bibliotheken verwerfen diesen Chunk und übergeben Ihrem Code nur den Text. Deshalb wirkt dieselbe Kürzung innerhalb einer Anwendung unerklärlich, unter curl jedoch offensichtlich. Wenn eine Bibliothek dieses Feld ausblendet, senden Sie eine Anfrage mit curl, um festzustellen, was der Server tatsächlich gemeldet hat.

Ein weiterer Punkt erspart Ihnen einen unnötigen Nachmittag. Das Erhöhen von num_predict bewirkt nicht, dass ein Modell mehr schreibt. Es entfernt lediglich eine Obergrenze. Wenn eine Antwort nach 200 Tokens mit done_reason von stop endet, hat das Modell entschieden, dass es fertig ist. Eine höhere Obergrenze ändert daran nichts. Kurze Antworten mit stop sind ein Prompting-Problem. Kurze Antworten mit length sind ein Problem der Obergrenze.

Einen Wert auswählen

• Für einen interaktiven Chat lassen Sie den Wert unbegrenzt und drücken Sie Ctrl+C, um eine außer Kontrolle geratene Antwort zu stoppen. Sie beobachten die Ausgabe ohnehin.
• Für alles, was per Skript ausgeführt wird, setzen Sie einen Wert. Eine unbegrenzte Generierung innerhalb einer Schleife führt dazu, dass ein Batchauftrag, der zehn Minuten dauern sollte, am nächsten Morgen immer noch läuft.
• Für strukturierte Ausgaben setzen Sie die Begrenzung höher als das größte gültige Dokument, das Sie erwarten. Behandeln Sie anschließend done_reason von length als harten Fehler und versuchen Sie es erneut, statt die empfangene Ausgabe zu parsen.
• Bei einem Coding-Agent gehört der Wert in die eigene Konfiguration des Agents, weil der Agent bei jeder Anfrage seine eigenen Optionen sendet. Einen Coding-Agent auf Ollama verweisen erklärt, wo diese Einstellungen gespeichert werden.

Die Begrenzung zählt Tokens, nicht Wörter und nicht Zeichen. Schätzen Sie den Wert daher nicht. Generieren Sie eine repräsentative Antwort ohne Begrenzung, lesen Sie eval_count aus und setzen Sie das Limit mit ausreichendem Abstand darüber. Modellfamilien tokenisieren unterschiedlich. Ein Wert, der für ein Llama-Modell ausreicht, kann dieselbe Antwort von einem Qwen 3-Modell auf demselben VPS abschneiden.

FAQ

Was ist der Unterschied zwischen num_ctx und num_predict in Ollama?

num_ctx bezeichnet die Größe des Kontextfensters. Der Parameter legt fest, wie viel das Modell lesen kann: den Prompt und alles, was bis dahin erzeugt wurde. Das benötigt Speicher, weil der Key/Value-Cache entsprechend wächst. num_predict legt fest, wie viele Tokens das Modell in einer Antwort höchstens schreiben darf. Das benötigt vor allem Zeit und reserviert keinen Speicher im Voraus. Erzeugte Tokens werden auf beide Werte angerechnet. Eine Antwort kann daher durch jeden der beiden Werte vorzeitig beendet werden.

Warum scheint meine Einstellung für num_predict ignoriert zu werden?

Weil ein mit der Anfrage übergebener Wert einen im Modell gespeicherten Wert überschreibt. Tragen Sie PARAMETER num_predict 512 in eine Modelfile ein und verwenden Sie dieses Modell anschließend über ein Chat-Frontend oder einen Coding-Agenten. Der Client sendet dann ein eigenes options-Objekt. Dessen Wert hat Vorrang. ollama show --parameters gibt weiterhin Ihren Wert aus, weil der Befehl das gespeicherte Modell liest und nicht sehen kann, was über HTTP eingeht. Senden Sie mit curl eine Anfrage unter Verwendung von "options": {"num_predict": 32} und prüfen Sie, ob eval_count als 32 zurückkommt. Damit bestätigen Sie, dass sich der Server selbst korrekt verhält, und verlagern die weitere Suche in Ihre Anwendung.

Wie kann ich feststellen, ob meine Ausgabe durch num_predict abgeschnitten wurde?

Senden Sie die Anfrage mit "stream": false und lesen Sie done_reason aus. Der Wert stop bedeutet, dass das Modell selbstständig fertig geworden ist. Der Wert length bedeutet, dass kein weiterer Platz verfügbar war. Vergleichen Sie anschließend eval_count mit Ihrem Grenzwert: Sind die Werte exakt gleich, wurde die Ausgabe durch num_predict beendet. Ist eval_count kleiner, war das Kontextfenster zuerst voll. Beim Streaming kommen beide Felder im letzten Chunk zusammen mit "done": true an. Viele Client-Bibliotheken verwerfen diese Informationen, bevor Ihr Code sie erhält.

Welchen Standardwert hat num_predict?

Lesen Sie den Wert aus Ihrer eigenen Installation aus und verlassen Sie sich nicht auf einen Artikel. Im August 2026 gibt die Ollama-Modelfile-Referenz als Standardwert -1 an. Das bedeutet, dass die Generierung nicht begrenzt ist. Dieser Eintrag wurde Ende 2024 korrigiert, nachdem über Jahre 128 dokumentiert worden war. Negative Werte sind Platzhalter und keine Zählerwerte. Ältere Versionen derselben Tabelle führten außerdem -2 zum Auffüllen des verbleibenden Kontexts auf. Prüfen Sie die Referenz zu Modelfile-Parametern für Ihre Version. Bestätigen Sie den Wert anschließend mit ollama show --parameters und einer curl-Anfrage.

Führt ein höherer Wert für num_predict zu längeren Antworten?

Nein. Dadurch wird lediglich eine Obergrenze entfernt. Endet eine Antwort mit done_reason von stop, hat das Modell entschieden, dass sie vollständig ist. Eine höhere Obergrenze ändert daran nichts. In diesem Fall ist die Länge eine Frage der Prompt-Formulierung: Fordern Sie eine bestimmte Struktur, eine Anzahl von Abschnitten oder einen festgelegten Detaillierungsgrad an. Erhöhen Sie num_predict nur, wenn done_reason als length zurückkommt.