Ollama num_predict begrenzen: Ausgabe-Länge festlegen

Was num_predict in Ollama bewirkt

num_predict ist die Ollama-Option, die begrenzt, wie viele Tokens ein Modell in einer Antwort generieren darf. Gezählt werden nur Ausgabe-Tokens. Der Prompt wird daher nicht auf dieses Limit angerechnet. Wenn das Modell das Limit erreicht, wird die Generierung an dieser Stelle beendet, gelegentlich mitten in einem Wort. Die Antwort enthält dann done_reason mit dem Wert length.

Das ist die gesamte Funktion. Die Schwierigkeit besteht darin, dass Ollama drei separate Stellen zum Festlegen des Werts bietet. Die Einstellung, die am nächsten an der Anfrage liegt, hat Vorrang. Fast jeder Bericht, dass „num_predict nichts bewirkt“, ist darauf zurückzuführen, dass eine Ebene unbemerkt eine andere überschreibt.

num_predict ist nicht num_ctx

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

num_ctx gibt an, wie viel das Modell lesen kann. Es bezeichnet die Größe des Kontextfensters. Dieses enthält den Prompt und alle bisher erzeugten Inhalte. Ein höherer Wert 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 gibt an, wie viel das Modell schreiben wird. Es handelt sich um eine Abbruchregel, nicht um eine Speicherzuweisung. Ein höherer Wert benötigt mehr Zeit, aber keinen zusätzlichen RAM. Im Voraus wird dafür nichts reserviert.

Beide treffen an einer Stelle zusammen. Erzeugte Tokens werden während der Generierung im Kontextfenster abgelegt. 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. Sie wird weiter unten behandelt.

Einmalig mit einem Modelfile festlegen

Ein 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 gesetzten 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. Fehlt num_predict in dieser Ausgabe, enthält das Modell keine fest eingebaute Begrenzung und es gilt der Standardwert von Ollama. ollama show --modelfile qwen3-capped gibt die vollständige Definition aus. Damit lassen sich die Parameter, mit denen ein vorhandenes Modell bereits ausgeliefert wird, am schnellsten kopieren. Das Erstellen eines begrenzten Modells auf diese Weise benötigt nahezu keinen zusätzlichen Speicherplatz. Der neue Eintrag verwendet die bereits vom Basismodell heruntergeladenen Weight-Blobs erneut, anstatt sie zu kopieren. Daher sollten Sie wissen, wo Ollama diese Blobs speichert, bevor die Root-Disk eines VPS voll läuft.

Das ist die richtige Ebene für einen Wert, den jeder Aufrufer übernehmen soll. Es ist die falsche Ebene, wenn Sie erwarten, dass der Wert endgültig gilt, denn das tut er nicht.

Legen Sie ihn pro Anfrage im options-Objekt fest

Jeder Generation-Endpunkt übernimmt 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. Der Wert gilt nur für diesen einen Aufruf und für nichts anderes. Diese Ebene verwenden Ihre Tools: ein Chat-Frontend, ein Script, 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

In 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 sendet. Damit lässt sich am schnellsten prüfen, ob eine Änderung übernommen wurde. Der Wert bleibt bestehen, bis Sie /bye eingeben. Mit /save qwen3-capped schreibt die Sitzung den aktuellen Sitzungszustand einschließlich der Parameter als neues Modell. Nichts, was Sie hier mit /set eingeben, erreicht einen anderen Client.

Welche Einstellung gilt und warum Ihre scheinbar ignoriert wird

Die Reihenfolge ist kurz. Mit der Anfrage übergebene Optionen haben Vorrang vor allen 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 dieser Anfrage gesendet. Genau deshalb überschreibt er das Modelfile für die 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 laufen weiterhin über 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. Häufig stammt diese Zahl aus einer Einstellung, die Sie vor Monaten in einer Einstellungsoberfläche eingegeben und danach vergessen haben. ollama show liest das gespeicherte Modell. Es zeigt nicht, was über HTTP eingeht.

Prüfen Sie die Serverseite mit einem einzigen Befehl. Senden Sie eine Anfrage, die eine lange Antwort erzeugt, setzen Sie das Limit 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 eigene Protokollierung des Servers starten Sie ihn 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 kopieren sollten

num_predict akzeptiert auch negative Werte. Diese dienen als Sentinel-Werte und nicht als Zähler. Ein negativer Wert bedeutet „keine Begrenzung, weiter generieren“. Ein anderer Wert bedeutete „den verbleibenden Kontext auffüllen“. Im August 2026 gibt die Ollama-Modelfile-Referenz -1 als Standardwert für die unbegrenzte Generierung an. Frühere Versionen derselben Tabelle führten außerdem -2 zum Auffüllen des Kontexts auf.

Betrachten 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. Daher wiederholen viele Anleitungen weiterhin die alte Zahl. Lesen Sie die Referenz zu den Modelfile-Parametern für die von Ihnen tatsächlich verwendete Version. Bestätigen Sie anschließend das Verhalten mit der oben beschriebenen Prüfung eval_count. 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 CPU-only-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 CPU-only-VPS wird dieser Durchlauf durch die Speicherbandbreite begrenzt. Daher kostet ein generiertes Token deutlich mehr als ein Prompt-Token. Da bei diesem Durchlauf jedes Gewicht gelesen werden muss, bestimmt die von jedem Gewicht belegte Byte-Anzahl die Obergrenze für Ihre Tokenrate. Deshalb dekodiert ein q4-Build schneller als dasselbe Modell mit q8 oder fp16.

Fordern Sie eine Antwort ohne Streaming an, stehen die Zahlen direkt zur Verfügung:

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

Die Zeitangaben sind in Nanosekunden. In diesem Block, der ein Beispiel aus der Ollama-API-Dokumentation und keine Messung eines bestimmten Servers ist, benötigten 26 Prompt-Tokens 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 und in Sekunden umgerechnet. Die Messung der Tokens pro Sekunde auf Ihrer eigenen Hardware lohnt sich, bevor Sie andere Einstellungen optimieren. Diese Rate hängt ebenso stark vom Modell wie von der Hardware ab. Wenn lange Antworten die eigentlichen Kosten verursachen, verkürzt ein für schnelles Dekodieren entwickeltes Modell wie Nemotron 3.5 Lightning auf einer VPS die Zeit, die eine niedrige Obergrenze sonst einsparen soll.

Die Rechnung erledigt 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. Ein Reasoning-Modell verwendet einen Teil dieses Budgets zum Nachdenken, bevor es das von Ihnen angeforderte erste Wort schreibt. Auch dieses Denken wird wie alles andere Token für Token generiert. Daher ist der von Ihnen angeforderte Reasoning-Aufwand ein weiterer Stellhebel für dieselben Kosten. Einige Modelle laufen außerdem in Schleifen und wiederholen eine Phrase, bis sie gestoppt werden. Ohne Obergrenze bleibt ein einzelner Request aktiv und belegt einen CPU-Kern, bis das Kontextfenster ausgeschö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 langer Request die gesamte Maschine auslastet.

Abgeschnittene Ausgaben sind normalerweise die Obergrenze, kein defektes Modell

Die Symptome wirken wie ein Modellfehler. Eine Antwort bricht mitten im Satz ab. JSON lässt sich nicht parsen, weil die schließende geschweifte Klammer fehlt. Der erste Impuls ist, das Modell oder die Quantisierung dafür verantwortlich zu machen. 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 weil eine der Zeichenfolgen in Ihrer Option stop gefunden wurde. length bedeutet, dass die Generierung abgebrochen wurde, weil kein Platz mehr verfügbar war. Wenn Sie length sehen, 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 vollständig belegt war.

Beim Streaming treffen diese Felder im letzten Chunk ein, der "done": true enthält. Viele Clientbibliotheken verwerfen diesen Chunk und übergeben Ihrem Code nur den Text. Deshalb wirkt dieselbe Kürzung innerhalb einer Anwendung unerklärlich, während sie unter curl offensichtlich ist. Wenn eine Bibliothek diese Information ausblendet, senden Sie eine Anfrage mit curl, um festzustellen, was der Server tatsächlich zurückgegeben hat.

Ein weiterer Punkt erspart Ihnen einen unnötig langen Debugging-Nachmittag. Das Erhöhen von num_predict führt nicht dazu, 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 mit der Obergrenze.

Wahl eines Werts

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

Das Limit zählt Tokens, nicht Wörter und nicht Zeichen. Schätzen Sie den Wert daher nicht. Generieren Sie eine repräsentative Antwort ohne Limit, lesen Sie eval_count ab 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. Damit wird festgelegt, wie viel das Modell lesen kann: den Prompt und alles, was bis dahin erzeugt wurde. Das benötigt Arbeitsspeicher, 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 Rechenzeit, aber keinen zusätzlichen reservierten Speicher. 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-Agent. Der Client sendet dann sein eigenes options-Objekt, dessen Wert maßgeblich ist. ollama show --parameters gibt weiterhin Ihren Wert aus, weil es das gespeicherte Modell ausliest und nicht sehen kann, was über HTTP eingeht. Senden Sie eine Anfrage mit curl 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 können die Ursache in Ihrer Anwendung suchen.

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 der verfügbare Platz nicht ausgereicht hat. Vergleichen Sie anschließend eval_count mit Ihrem Limit: Stimmen die Werte exakt überein, hat num_predict die Ausgabe beendet. Ist eval_count kleiner, war das Kontextfenster zuerst voll. Beim Streaming kommen beide Felder im letzten Chunk mit "done": true an. Viele Client-Bibliotheken verwerfen diesen Chunk, bevor Ihr Code ihn sieht.

Was ist der Standardwert von num_predict?

Lesen Sie den Wert aus Ihrer eigenen Installation aus und nicht aus einem Artikel. Im August 2026 nennt die Ollama-Referenz für Modelfile als Standardwert -1. Das bedeutet, dass die Generierung nicht begrenzt ist. Dieser Eintrag wurde Ende 2024 korrigiert, nachdem dort jahrelang 128 dokumentiert worden war. Negative Werte sind Platzhalter und keine Zähler. Ältere Versionen derselben Tabelle nannten außerdem -2, um den verbleibenden Kontext zu füllen. Prüfen Sie die Referenz für Modelfile-Parameter für Ihre Version und 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 dazu, dass das Modell längere Antworten schreibt?

Nein. Dadurch wird nur eine Obergrenze entfernt. Wenn eine Antwort mit done_reason von stop endet, hat das Modell entschieden, dass sie vollständig ist. Ein höheres Limit ändert daran nichts. Die Länge ist in diesem Fall eine Frage des Promptings: Fordern Sie eine bestimmte Struktur, eine Anzahl von Abschnitten oder einen vorgegebenen Detailgrad an. Erhöhen Sie num_predict nur, wenn done_reason als length zurückkommt.