Reasoning-Aufwand bei lokalen LLMs richtig messen

Welche Auswirkungen hat der Reasoning-Aufwand bei einem lokalen LLM?

Der Reasoning-Aufwand ist eine Einstellung, die festlegt, wie lange ein Modell vor seiner Antwort nachdenkt. Er verändert nur die Länge des Reasoning-Abschnitts. Die Gewichte auf dem Datenträger sind bei jeder Stufe identisch, ebenso die Quantisierung. Die Antwort entsteht aus demselben Forward Pass. Verändert wird nur die Anzahl der Tokens, die das Modell zunächst für seinen eigenen Scratchpad verwendet.

Diese Unterscheidung ist wichtig, weil es darauf ankommt, wo diese Tokens anfallen. Bei einer gehosteten API erscheinen Reasoning-Tokens auf der Rechnung. Auf einem VPS, den Sie selbst betreiben, werden sie durch Generierungszeit auf Ihrer eigenen CPU oder GPU und durch belegten Platz im Context Window bezahlt. Ein Modell, das mit dem höchsten Reasoning-Aufwand ausgeführt wird, kann den Großteil seiner Ausgabe für das Reasoning verwenden, bevor das erste Wort der Antwort erscheint. Auf selbst gehosteter Hardware kann das den Unterschied zwischen einer Antwort nach zwei Sekunden und einer Antwort nach zwei Minuten ausmachen.

Wo die Stufe festgelegt wird: im Chat-Template, nicht in den Gewichten

Ein Thinking-Modell ist darauf trainiert, vor seiner endgültigen Antwort ein Reasoning-Segment auszugeben, das normalerweise in <think>- und </think>-Tags eingeschlossen ist. Die Effort-Stufe ist eine Anweisung, die das Chat-Template des Modells in den Prompt schreibt. Dieses Template ist eine mit dem Modell ausgelieferte Jinja-Datei. Es liest eine Variable wie reasoning_effort und erzeugt für jeden Wert eine andere Zeile auf Systemebene. Das Modell wurde darauf trainiert, sein Scratchpad als Reaktion auf diese Zeile zu verkürzen oder zu verlängern.

Daraus folgen zwei Punkte. Die Namen der Stufen gehören zum Modell und nicht zu Ihrer Laufzeitumgebung. Daher kann ein Name aus der Model Card bei einem anderen Modell bedeutungslos sein. Wenn ein Bestandteil der Kette das Chat-Template des Modells durch ein generisches Template ersetzt, wird die Variable nicht gerendert. Die Einstellung bleibt dann unbemerkt wirkungslos.

Stand 2026-08-20 dokumentiert die Model Card des Modells Qwen3.8-27B drei Effort-Stufen: low, medium und xhigh. xhigh ist die Standardeinstellung. high gibt es nicht. Das Thinking selbst wird mit enable_thinking aktiviert und ist standardmäßig eingeschaltet. Die Model Card dokumentiert außerdem preserve_thinking, das ebenfalls standardmäßig eingeschaltet ist und Reasoning aus früheren Nachrichten im Gesprächsverlauf beibehält. gpt-oss verwendet stattdessen low, medium und high. Viele andere Modellfamilien akzeptieren nur einen booleschen Wert. Lesen Sie die Model Card der exakten Version, die Sie heruntergeladen haben, da diese Namen kein Standard sind. Ein 27B-Modell auf einem VPS starten ist der erste Schritt. Auf dieser Seite geht es darum, was Sie einstellen müssen, sobald das Modell antwortet.

Warum hoher Rechenaufwand auf einem VPS mehr kostet

Ausgabetokens. Reasoning-Tokens sind erzeugte Tokens. Sie durchlaufen dieselbe Decodierungsschleife wie die Antworttokens und werden von Ihrer Hardware mit derselben Tokenrate verarbeitet. Angenommen, eine Aufgabe erzeugt 200 Antworttokens und 4.000 Reasoning-Tokens. Dann wurden 4.200 Tokens erzeugt, obwohl der Leser nur 200 davon gesehen hat. Ihre Decodierungsrate wird durch die Speicherbandbreite und durch die gewählte Quantisierung bestimmt. Als einzige Stellschraube bleibt daher die Anzahl der Tokens.

Wanduhrzeit. Ein Benutzer wartet auf den ersten Token der Antwort, weil alles davor einen leeren Bildschirm oder einen eingeklappten Ladeindikator bedeutet. Reasoning wird zuerst ausgegeben. Die Wartezeit entspricht daher ungefähr der Anzahl der Reasoning-Tokens geteilt durch die Decodierungsrate, zuzüglich der Prompt-Verarbeitung. Eine Verdopplung der Reasoning-Länge verdoppelt diese Wartezeit.

Kontext. Reasoning-Tokens belegen das Kontextfenster wie alle anderen Tokens. Wenn preserve_thinking aktiviert ist, befindet sich der Zwischenspeicher aus dem ersten Turn beim fünften Turn weiterhin im Prompt. Dadurch wird die Prompt-Verarbeitung mit jedem Turn langsamer, während sich das Fenster von beiden Seiten füllt. Wenn Sie num_ctx erhöhen, um den Inhalt aufzunehmen, benötigt der KV-Cache zusätzlichen Speicher. Auf einem VPS ohne GPU ist das System-RAM, das möglicherweise nicht verfügbar ist.

Wann Sie die Stufe erhöhen und wann Sie sie niedrig lassen

Erhöhen Sie sie bei Aufgaben, bei denen ein falscher Zwischenschritt das Ergebnis verfälscht: mehrstufige Arithmetik und Einheitenumrechnung, die Planung einer Änderung über mehrere Dateien hinweg, Code, der kompilieren muss, sowie Aufgaben mit Bedingungen, bei denen eine Antwort mehrere Vorgaben gleichzeitig erfüllen muss. In diesen Fällen leistet der Scratchpad tatsächlich wichtige Arbeit. Ein längerer Scratchpad ist eine kostengünstige Möglichkeit, einen Fehler abzufangen, auf den sich das Modell sonst festlegen würde.

Lassen Sie sie niedrig, wenn die Antwort bereits in der Eingabe enthalten ist und nur übertragen werden muss. Extraktion, Klassifizierung, Tagging, Übersetzung, Umschreiben, Zusammenfassen und Formatieren fallen in diese Kategorie. Der Abschnitt zum Schlussfolgern wiederholt die Aufgabe größtenteils. Dadurch kann das Modell seine zunächst richtige Einschätzung wieder verwerfen.

Lassen Sie sie auch bei interaktiven Aufgaben niedrig. In einem Chatfeld oder Editor sind Sie Teil des Ablaufs. Eine schnelle Antwort, die Sie korrigieren können, ist daher besser als eine langsame Antwort, auf die Sie warten müssen. Das ist der eigentliche Zielkonflikt hinter einen Coding-Agent auf ein lokales Modell anzusetzen: Ein Agent führt viele kleine Aufrufe aus, und die Kosten für das Schlussfolgern fallen bei jedem einzelnen an.

So legen Sie das Level in llama.cpp fest

llama.cpp schreibt die Variable direkt in das Template. Damit befindet sie sich zur Laufzeit an der Stelle, an der Sie sicher feststellen können, dass das Level angekommen ist. Verweisen Sie mit -m auf die bereits vorhandene GGUF-Datei.

llama-server -m ./qwen3.8-27b-Q4_K_M.gguf \
  --jinja \
  --reasoning-effort medium \
  --reasoning-format deepseek \
  -c 32768 \
  --host 127.0.0.1 --port 8080

--jinja verwendet das Chat-Template des Modells und ist in aktuellen Builds standardmäßig aktiviert. --reasoning-effort akzeptiert default, minimal, low, medium, high, xhigh oder max. default bedeutet, dass der Standardwert des Templates unverändert bleibt. Diese Liste enthält die von llama.cpp unterstützten Bezeichnungen, nicht die des Modells. Verwenden Sie daher nur einen Namen, den die Model Card aufführt. Ein Level, das im Template nicht definiert ist, kann bei der Verarbeitung der Anfrage einen Template-Fehler verursachen. --reasoning-format deepseek verschiebt die Überlegungen aus message.content nach message.reasoning_content. Dadurch lässt sich die Aufteilung im nächsten Abschnitt messen.

Um das Denken vollständig zu deaktivieren, statt es nur zu verkürzen, setzen Sie die Template-Variable selbst:

llama-server -m ./qwen3.8-27b-Q4_K_M.gguf --jinja \
  --chat-template-kwargs '{"enable_thinking": false}'

--reasoning-budget ist ein anderer Mechanismus. Damit wird der Abschnitt mit den Überlegungen auf eine bestimmte Token-Anzahl begrenzt. 0 beendet ihn sofort, während -1 keine Begrenzung festlegt. Dabei wird das Modell nicht aufgefordert, einen kürzeren Abschnitt zu planen. Beide Flags gelten für den gesamten Server. llama-server akzeptiert reasoning_effort nicht als Feld pro Anfrage. Wenn Sie gleichzeitig zwei Effort-Level bereitstellen möchten, benötigen Sie daher zwei Prozesse auf zwei Ports.

vLLM stellt dieselbe Variable pro Anfrage im OpenAI-kompatiblen Request-Body bereit:

{"model": "Qwen/Qwen3.8-27B",
 "messages": [{"role": "user", "content": "Summarise this changelog in two lines."}],
 "chat_template_kwargs": {"reasoning_effort": "medium"}}

So legen Sie die Stufe in Ollama fest

Ollama verfügt über ein eigenes Feld, think, für /api/chat und /api/generate. Es akzeptiert true, false oder einen der Werte low, medium, high und max. max fordert dabei die höchste vom Modell angebotene Stufe an. Bei Modellen, die diese Funktion unterstützen, ist das Denken standardmäßig aktiviert.

ollama run qwen3.8:27b --think=low "Draft a one line commit message for a README typo fix"

{"model": "qwen3.8:27b",
 "messages": [{"role": "user", "content": "Which HTTP status code means the request body was too large?"}],
 "think": "low",
 "stream": false}

Die Begründung wird in message.thinking und die Antwort in message.content zurückgegeben. Beide sind bereits getrennt. In einer interaktiven ollama run-Sitzung können Sie die Funktion mit /set think und /set nothink ein- und ausschalten, ohne die Sitzung neu zu starten.

Beachten Sie nun die Abweichung. Das Vokabular von Ollama umfasst low, medium, high und max. Das Template von Qwen3.8 definiert low, medium und xhigh. Eine Zuordnung zwischen diesen Werten ist daher erforderlich. Ein Ollama-Modell enthält ein in seinem Tag verpacktes Template und nicht die Jinja-Datei aus dem ursprünglichen Repository. Ob Ihre festgelegte Stufe das Modell erreicht, hängt daher von diesem verpackten Template ab. Gehen Sie nicht davon aus, dass die Einstellung wirksam war. Die Messung dauert etwa eine Minute.

So messen Sie, ob die Stufe tatsächlich übernommen wurde

Senden Sie denselben Prompt mit mehreren Stufen und setzen Sie temperature auf 0. Vergleichen Sie anschließend die Tokenanzahl. Hier erstellt jq den Anforderungstext, sodass Sie Anführungszeichen nicht manuell maskieren müssen.

for level in low medium max; do
  body=$(jq -n --arg lvl "$level" '{
    model: "qwen3.8:27b",
    messages: [{role: "user", content: "A pump fills a 4500 litre tank in 25 minutes. A second pump is 40 percent slower. How long do both together take? Answer in minutes."}],
    think: $lvl,
    stream: false,
    options: {temperature: 0, num_ctx: 8192}
  }')
  echo "== $level"
  curl -s http://localhost:11434/api/chat -d "$body" | jq '{
    thinking_chars: (.message.thinking // "" | length),
    answer_chars: (.message.content | length),
    eval_count: .eval_count,
    seconds: (.total_duration / 1e9),
    tok_per_sec: (.eval_count / (.eval_duration / 1e9))
  }'
done

eval_count umfasst jedes generierte Token einschließlich des Reasonings. Die Differenz zwischen zwei Stufen besteht daher fast vollständig aus Reasoning. thinking_chars liefert die Aufteilung direkt. Zwei Bedingungen sollten erfüllt sein: Die Zahlen ändern sich zwischen den Stufen, und die Antwort bleibt auch bei der niedrigeren Stufe korrekt. Wenn eval_count bei allen drei Durchläufen innerhalb des Messrauschens liegt, wird die Stufe ignoriert. Die Lösung ist dann eine Laufzeitumgebung, die diese Stufe übergibt, nicht ein anderer Name für die Stufe.

Die Gesamtzeit zeigt nur die Hälfte des Bildes. Messen Sie daher die Zeit bis zum ersten Antwort-Token, indem Sie die Ausgabe streamen und beim ersten nicht leeren content-Chunk stoppen. Dafür benötigen Sie jq und bc.

start=$(date +%s.%N)
curl -sN http://localhost:11434/api/chat -d '{
  "model": "qwen3.8:27b",
  "messages": [{"role": "user", "content": "Explain what a reverse proxy does, in three sentences."}],
  "think": "low",
  "stream": true
}' |
while IFS= read -r line; do
  if [ -n "$(printf '%s' "$line" | jq -r '.message.content // ""')" ]; then
    echo "first answer token after $(echo "$(date +%s.%N) - $start" | bc)s"
    break
  fi
done

Führen Sie den Test mit low und anschließend erneut mit max aus. Die Differenz ist die zusätzliche Wartezeit. Bei llama.cpp werden dieselben Zahlen innerhalb der Antwort ausgegeben. Eine Berechnung in der Shell ist nicht erforderlich:

curl -s http://localhost:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model": "local", "temperature": 0,
       "messages": [{"role": "user", "content": "A pump fills a 4500 litre tank in 25 minutes. A second pump is 40 percent slower. How long do both together take?"}]}' | jq '{
  reasoning_chars: (.choices[0].message.reasoning_content // "" | length),
  answer_chars: (.choices[0].message.content | length),
  predicted_n: .timings.predicted_n,
  tok_per_sec: .timings.predicted_per_second
}'

Führen Sie diesen Test auf Ihrem eigenen System aus. Ein veröffentlichter Vergleich des Aufwands wurde auf Hardware gemessen, die nicht Ihrer entspricht. Ihre Decodierungsrate ist der Faktor, der eine Tokenanzahl in Sekunden umrechnet. Token pro Sekunde auf Ihrem eigenen Server messen liefert diesen Faktor: Die Anzahl der Reasoning-Tokens geteilt durch Ihre Decodierungsrate ergibt die zusätzliche Wartezeit.

Was schiefgeht

Die Antwort wird abgeschnitten oder content ist leer, während thinking gefüllt ist. Das Generierungslimit wurde durch das Reasoning aufgebraucht. Ollamas num_predict begrenzt die gesamte Generierung einschließlich des Reasonings. Da das Reasoning zuerst erfolgt, kann ein Limit von 512 Tokens bei hoher Ausführlichkeit die Antwort beenden, bevor sie beginnt. Ollama meldet bei dieser Antwort "done_reason": "length". Erhöhen Sie das Limit oder reduzieren Sie die Ausführlichkeit. Wie num_predict Tokens zählt beschreibt dieses Zusammenspiel ausführlich.

Die Stufe bewirkt nichts. Die Tokenanzahl ist auf jeder Stufe identisch. Entweder übergibt die Laufzeit die Variable nicht, oder das Template liest sie nicht aus. Prüfen Sie das Template, das Ihre Laufzeit tatsächlich verwendet, und nicht das Template aus dem ursprünglichen Repository. llama.cpp schreibt die Variable mit --jinja und --chat-template-kwargs manuell ein und eignet sich daher als Kontrolle: Wenn die Stufe dort funktioniert, aber sonst nirgendwo, ist das Modell in Ordnung und die andere Laufzeit verwirft den Wert.

Ein Stufenname wird abgelehnt. Ein Template-Fehler zum Zeitpunkt der Anfrage oder ein Fehler bei der ersten Nachricht auf einem ansonsten funktionierenden Server bedeutet normalerweise, dass Sie eine Stufe übergeben haben, die das Template nicht definiert. Ein Beispiel ist high bei einem Modell, dessen Model Card nur low, medium und xhigh aufführt.

Multi-Turn-Chats werden bei jeder Runde langsamer. Altes Reasoning wird im Verlauf beibehalten. Setzen Sie preserve_thinking auf false, wenn das Modell dies unterstützt, oder entfernen Sie das Feld thinking aus den Nachrichten, die Sie zurücksenden. Andernfalls wächst die Prompt-Verarbeitung bei jeder Runde, während die Antworten gleich lang bleiben.

Die Qualität sinkt bei niedriger Ausführlichkeit für eine Aufgabe, die Sie für einfach hielten. Manche Extraktion ist keine reine Extraktion. Wenn die Eingabe eine Einheitenumrechnung oder die schrittweise Anwendung einer Regel erfordert, handelt es sich um eine Reasoning-Aufgabe mit kurzer Ausgabe. Erhöhen Sie die Stufe nur für diesen Aufruf und nicht für den gesamten Server.

Zwei Ebenen gleichzeitig ausführen

llama.cpp legt die Ebene beim Start fest. Ein System, das sowohl einen Editor als auch einen nächtlichen Batchauftrag bedient, benötigt daher zwei Prozesse auf zwei Ports, jeweils mit einer eigenen --reasoning-effort. Zwei Prozesse bedeuten außerdem zwei Kopien der Gewichte im Arbeitsspeicher, sofern Sie die Aufträge nicht zeitlich trennen. Auf einem VPS ist daher meist folgende Kombination kostengünstiger: ein Server mit geringem Aufwand für alles, worauf eine Person wartet, und ein geplante Ausführung mit höherem Aufwand für Aufgaben, die niemand überwacht. Was geschieht, wenn mehrere Benutzer ein lokales Modell gemeinsam verwenden gilt auch hier: Reasoning-Tokens sind Decodierungsarbeit. Wenn Sie den Aufwand erhöhen, sinkt Ihre effektive Parallelität daher ungefähr um denselben Faktor, um den die Tokenanzahl steigt.

FAQ

Welche Stufe für den Denkaufwand sollte ich standardmäßig verwenden?

Beginnen Sie mit der niedrigsten vom Modell angebotenen Stufe und erhöhen Sie sie nur für Aufgaben, bei denen Sie bereits Fehler beobachtet haben. Mehrere Thinking-Modelle werden mit einem hohen Standardwert ausgeliefert, und Qwen3.8-27B verwendet seit August 2026 standardmäßig xhigh, seine höchste Stufe. Dieser Standardwert ist darauf ausgelegt, in Benchmark-Tabellen gut auszusehen. Eine Benchmark-Tabelle berücksichtigt jedoch keine Zeitkosten. Auf Ihrer eigenen Hardware bezahlen Sie mit Sekunden. Verwenden Sie die höhere Stufe daher pro Aufgabe gezielt, statt sie als Einstellung für jede Anfrage zu übernehmen.

Werden Reasoning-Tokens auf das Kontextfenster angerechnet?

Ja. Sie sind normale Tokens in der Ausgabe und belegen zusammen mit allen anderen Inhalten Platz im Kontextfenster. Ob sie im nächsten Turn erhalten bleiben, hängt von der Laufzeitumgebung und vom Modell ab. Die Model Card von Qwen3.8 dokumentiert preserve_thinking, das standardmäßig aktiviert ist. Dadurch bleibt vorheriges Reasoning im Verlauf erhalten, sodass eine lange Unterhaltung jedes erzeugte Scratchpad mitführt. Setzen Sie den Wert auf false oder entfernen Sie das Feld thinking aus den Nachrichten, die Sie erneut übergeben. Dann wächst der Aufwand für die Prompt-Verarbeitung nicht weiter.

Warum ändert die Einstellung für die Denkstufe nichts an meinen Token-Zählungen?

Die Einstellung erreicht das Chat-Template nicht. Die Stufe ist eine Template-Variable. Sie funktioniert daher nur, wenn die Laufzeitumgebung sie übergibt und das bereitgestellte Template sie ausliest. Einige Laufzeitumgebungen liefern zusammen mit einem Modell ein eigenes Template aus, statt die Jinja-Datei aus dem ursprünglichen Repository zu verwenden. Die Variable wird dann verworfen, ohne dass irgendwo eine Fehlermeldung ausgegeben wird. Belegen Sie dies, indem Sie denselben Prompt mit der niedrigsten und der höchsten Stufe senden, dabei temperature auf 0 setzen und eval_count vergleichen. Stimmen die Zählungen innerhalb der Messabweichung überein, wird die Stufe ignoriert.

Macht ein geringerer Denkaufwand das Modell ungenauer?

Das hängt von der Aufgabe ab. Messen Sie dies, statt es anzunehmen. Wenn die Antwort bereits in der Eingabe enthalten ist, etwa bei Extraktion oder Überarbeitung, ändert ein kürzeres Scratchpad in der Regel nichts. Wenn ein Zwischenschritt korrekt sein muss, bevor der nächste Schritt ausgeführt werden kann, sinkt die Genauigkeit bei einem kürzeren Scratchpad. Das gilt beispielsweise für mehrstufige Arithmetik oder Code, der kompilieren muss. Erstellen Sie aus Ihrer tatsächlichen Arbeitslast einen Satz aus zwanzig Prompts. Führen Sie diese mit zwei Stufen und temperature auf 0 aus und zählen Sie die falschen Antworten. Diese Zahl ist spezifisch für Ihre Arbeitslast. Keine veröffentlichte Tabelle kann sie für Sie ermitteln.