Reasoning-Modell-Hardware: warum Thinking Tokens das GPU-Sizing für gpt-oss, Qwen und DeepSeek verändern

Reasoning-Modell-Hardware: was Thinking Tokens verändern

Ein Reasoning-Modell schreibt vor seiner Antwort verborgene Thinking Tokens, von einigen hundert bis zu Zehntausenden je Anfrage, und die GPUs erzeugen und speichern jedes davon. Die Gewichte behalten ihre Größe, der Speicher für eine Kopie des Modells bleibt also gleich. Es wachsen die Zahl der Ausgabe-Token je Anfrage, der KV-Cache, den jedes Gespräch während des Reasonings hält, und die Zeit, die jede Anfrage in Bearbeitung bleibt. Bei gleicher Belegschaft sind mehr Anfragen gleichzeitig in Bearbeitung, und jede hält einen längeren Cache.

Im Rechenbeispiel unten brauchen 500 Mitarbeiter mit gpt-oss-120b bei deklarierten 32K Kontext nach unserer Schätzung zwei RTX PRO 6000 oder eine H200 NVL für Chat-Antworten mit 500 Token. Schreibt jede Anfrage 8.000 Token, brauchen sie 16 RTX PRO 6000 oder sechs H200 NVL, wenn jede Anfrage die vollen 32K reserviert, und fünf oder zwei, wenn sie nur die 10.000 Token hält, die sie nutzt. Die Reasoning-Stufe ist daher eine Eingangsgröße des Sizings, festgelegt je Anwendungsfall, wie die Kontextlänge.

NVIDIA beschrieb den Trend in seiner Ankündigung von Dynamo vom 18. März 2025: Wenn Modelle Reasoning-Fähigkeiten hinzugewinnen und in agentischen Workflows laufen, „erzeugen sie während der Inferenz eine weit größere Zahl von Token“.

Reasoning-Steuerung und angegebene Längen je Modell

Jede Modellfamilie dokumentiert ihre eigene Steuerung. gpt-oss erhält eine Reasoning-Stufe im System-Prompt, und OpenAIs harmony-Leitfaden vom 5. August 2025 hält fest: „Standardmäßig führt das Modell ein Reasoning der Stufe medium aus.“ Qwen3.8 denkt standardmäßig, akzeptiert für reasoning_effort die Werte xhigh, medium oder low und schaltet das Thinking ab, wenn enable_thinking auf false steht.

OpenAIs Model Card zu gpt-oss (arXiv 2508.10925) und harmony-Leitfaden, Qwens Card zu Qwen3.8-27B, DeepSeeks Cards zu V4-Flash-0731 und R1-0528 auf Hugging Face, alle abgerufen am 10. Oktober 2026. Die AIME-Werte stammen aus Wettbewerbsmathematik, nicht aus Büroaufgaben.

Die Werte der Tabelle sind Ausgabegrenzen und Mittelwerte aus Wettbewerbsmathematik; die Längen Ihrer eigenen Anwendungsfälle werden in einem Piloten gemessen, wie unten beschrieben. Die Model Card von gpt-oss hält fest: „Eine höhere Reasoning-Stufe führt dazu, dass die durchschnittliche CoT-Länge des Modells steigt“, und längeres Reasoning bringe „höhere Genauigkeit bei einem relativ starken Anstieg von Latenz und Kosten der endgültigen Antwort“. DeepSeeks Card zu R1-0528 berichtet, dass das Update den Durchschnitt von 12.000 auf 23.000 Token je AIME-Frage erhöht hat, und die Evaluationen erlaubten bis zu 64K Token Generierung. Qwens Card ergänzt einen Hinweis für Agenten: „Bei agentischen Aufgaben über mehrere Runden verkürzt ein geringerer Reasoning-Aufwand die gesamte Bearbeitungszeit einer Aufgabe nicht immer“, weil eine schwache Analyse zu Wiederholungen führt.

Decode-Last und Zeit in Bearbeitung je Anfrage

Prefill liest den Prompt einmal und ist rechengebunden, während Decode ein Token nach dem anderen schreibt und, in NVIDIAs Worten, „speichergebunden ist“. Thinking Tokens sind Decode-Token. Die Decode-Last eines Dienstes ist seine Ankunftsrate mal die Ausgabe-Token je Anfrage, und nach dem Gesetz von Little ist die Zahl der Anfragen in Bearbeitung die Ankunftsrate mal die Zeit, die jede Anfrage braucht.

Wir übernehmen die Beispielwerte unseres Artikels zum privaten ChatGPT-Server nach Unternehmensgröße für 500 Mitarbeiter: 200 Nutzer in der Spitzenstunde, je 6 Anfragen pro Stunde und ein Spitzenfaktor von 2. Das ergibt in der Spitze eine Anfrage alle 1,5 Sekunden. Für die Zeit in Bearbeitung setzen wir 18 Token pro Sekunde je Stream an, den Median des Server-Szenarios für gpt-oss-120b in MLPerf Inference v6.0 auf einem Server mit acht RTX PRO 6000, wie unsere Benchmarks der RTX PRO 6000 berichten. Eine Antwort mit 500 Token dauert dann etwa 28 Sekunden, nahe an den 30 Sekunden des Artikels zur Unternehmensgröße.

Unsere Schätzungen, keine Messungen, für gpt-oss-120b mit 16-Bit-KV-Cache: Beispielwerte aus unserem Artikel zur Unternehmensgröße, einschließlich seiner 30 Sekunden je Chat-Anfrage; Reasoning-Zeilen mit 18 Token pro Sekunde je Stream aus MLPerf Inference v6.0 (Ergebnis 6.0-0047); Karten nach der Methode des Artikels zur Unternehmensgröße mit 19 Gesprächen je RTX PRO 6000 und 55 je H200 NVL bei vollen 32K, eine Kopie je Karte.

Die Ausgabelänge geht zweimal ein. Bei 18 Token pro Sekunde bleibt eine Anfrage mit 8.000 Token etwa 444 Sekunden in Bearbeitung, gegenüber den 30 Sekunden einer Chat-Antwort, deshalb sind in der Spitze etwa 15-mal so viele Anfragen in Bearbeitung, und jede hält einen längeren Cache.

Die Kartenzahlen der Tabelle folgen der Methode des Artikels zur Unternehmensgröße und reservieren die vollen deklarierten 32.768 Token für jede Anfrage in Bearbeitung, als ob alle ihren Kontext im selben Moment füllten. Zählt man nur die Token, die jede Anfrage an ihrem Ende hält, 2.000 Token Prompt plus 8.000 Token Ausgabe bei 36 KiB je Token, belegen die 296 Anfragen der letzten Zeile etwa 103 GiB Cache, die fünf RTX PRO 6000 oder zwei H200 NVL fassen. Der Abstand zwischen 5 und 16 Karten ist der Kontext, den jede Anfrage reserviert, aber nicht nutzt: 10.000 gehaltene Token gegenüber 32.768 reservierten. Der niedrigere Wert gilt, solange Prompts und Verlauf nahe 2.000 Token bleiben. Fügen Nutzer lange Dokumente ein oder führen sie lange Chats, nähern sich die Anfragen dem deklarierten Kontext, und die Zahl bewegt sich in Richtung 16. Reicht der Cache nicht aus, verdrängt vLLM Anfragen und berechnet sie später neu, wie sein Tuning-Leitfaden beschreibt; messen Sie daher die Prompt-Längen in einem Piloten, bevor Sie einen Punkt zwischen beiden Werten wählen.

Speicher ist nicht die einzige Grenze. Bei 5.333 Token pro Sekunde in der Spitze braucht das Profil mit 8.000 Token vom Durchsatz her mindestens drei RTX PRO 6000, da das System mit acht Karten in MLPerf im selben Szenario 1.782 Token pro Sekunde je Karte lieferte, nach unserer Division des Systemergebnisses. Diese Karten liefen voll ausgelastet, 18 Token pro Sekunde sind also ein Wert unter Volllast; mit weniger Streams je Karte endet jede Anfrage früher, und die Tabelle liegt eher zu hoch. Muss der Dienst den Ausfall eines Servers überstehen, gilt zusätzlich die Zwei-Server-Regel des Artikels zur Unternehmensgröße.

Für einen Piloten fasst ein DGX Spark (128 GB) gpt-oss-120b vom Speicher her mit etwa 30 Gesprächen bei 32K, wobei wir wie unser Überblicksbeitrag 102 GB seines Speichers ansetzen. Seine Speicherbandbreite von 273 GB/s begrenzt ihn, bevor der Speicher es tut. Die llama.cpp-Ergebnisse in unserem Artikel zur gemeinsamen Nutzung eines DGX Spark im Team ergeben etwa 12 Token pro Sekunde je Anfrage bei 16 gleichzeitigen Anfragen, eine Reasoning-Anfrage mit 8.000 Token liefe also etwa 11 Minuten.

Wir bauen Inferenz-Server mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern. Schicken Sie uns das Modell, die Reasoning-Stufe je Anwendungsfall und Ihre Spitzenzahl an Anfragen über das Formular unten, und wir antworten mit Konfiguration und Angebot.

KV-Cache je Gespräch beim Reasoning

Der Cache je Token ist durch das Attention-Design des Modells festgelegt, und Reasoning vervielfacht nur die Token. Bei gpt-oss-120b kostet jedes Token 36 KiB 16-Bit-Cache in den Layern mit voller Attention, wie unser Leitfaden zur Hardware für gpt-oss-120b aus seiner config.json herleitet; 20.000 Reasoning-Token fügen einem Gespräch also etwa 0,7 GiB hinzu. Qwen3.8-27B erreicht mit 64 KiB je Token etwa 16 GiB bei den empfohlenen 262.144 Token Reasoning-Ausgabe, was zugleich seine native Kontextlänge ist. Eine RTX PRO 6000 behält neben den FP8-Gewichten des Modells 54,3 GiB für den Cache, wie unser Leitfaden zur Qwen-Hardware zeigt, Platz für drei solche Gespräche.

Auch der Chatverlauf trägt zum Cache bei. OpenAIs harmony-Leitfaden weist an, „alle früheren CoT-Inhalte beim nachfolgenden Sampling zu verwerfen“, sobald eine Antwort im Kanal „final“ geendet hat, mit Tool- und Function-Calls als Ausnahme. Ein Chat mit gpt-oss wächst daher nur um Fragen und Antworten. Qwens Card hält fest: „Standardmäßig behält Qwen3.8 die Thinking-Blöcke aller früheren Nachrichten“, jede Runde trägt also das Reasoning früherer Runden mit, sofern preserve_thinking nicht auf false steht. Für einen Assistenten mit mehreren Runden auf Qwen3.8 ändert diese Einstellung den Kontext, den Sie deklarieren.

DeepSeek-R1-Hardware und große Reasoning-Modelle

DeepSeek-R1-0528 ist mit 685B Parametern angegeben, und seine config.json nennt die Architektur von DeepSeek-V3 (DeepseekV3ForCausalLM), 61 Layer, FP8-Gewichte in Blöcken von 128 × 128 und 163.840 Token Kontext. Nach unserer Summe der Parameterzahlen je Datentyp auf seiner Hugging-Face-Seite belegen die Gewichte etwa 689 GB, nahe am FP8-Checkpoint von DeepSeek-V3.2 mit 690 GB, den unser Leitfaden zur DeepSeek-Hardware auf acht H200 NVL legt. Nach unserer Lesart braucht R1-0528 von den Gewichten her dieselben acht Karten.

Seine Multi-Head Latent Attention speichert je Layer und Token 512 + 64 Werte, nach unserer Rechnung 68,6 KiB in 16 Bit, ohne den Indexer der Sparse Attention von V3.2. Eine durchschnittliche AIME-Antwort mit 23.000 Token hält dann etwa 1,5 GiB Cache, und die 64K Token aus DeepSeeks Evaluationen etwa 4,3 GiB. Unter Tensor-Parallelismus wird der latente Cache auf jede Karte kopiert; mit den etwa 43 GiB je Karte, die unser DeepSeek-Leitfaden auf acht H200 NVL für V3.2 ermittelt, passen nach unserer Schätzung etwa 28 solche Antworten gleichzeitig. Die Card zu R1-0528 beschreibt außerdem ein destilliertes DeepSeek-R1-0528-Qwen3-8B mit der Architektur von Qwen3-8B, etwa 16 GB BF16-Gewichte für seine 8,2B Parameter, das von den Gewichten her auf eine L4 oder RTX PRO 4000 mit 24 GB passt. Die config.json von Qwen3-8B ergibt 144 KiB 16-Bit-Cache je Token, etwa 3,2 GiB für eine Antwort mit 23.000 Token, deshalb hat eine Karte mit 24 GB neben den Gewichten höchstens Platz für zwei solche Antworten.

DeepSeek-V4-Flash erlaubt weit längeres Reasoning mit einem viel kleineren Cache je Token. Bei den empfohlenen 384K Token Ausgabe schätzt unser DeepSeek-Leitfaden etwa 1,5 GiB FP8-Cache je Gespräch auf jeder Karte.

Reasoning-Modelle in vLLM bereitstellen

vLLM trennt das Reasoning von der Antwort, wenn der Server mit --reasoning-parser startet; seine Dokumentation, eine Developer Preview vom 1. Oktober 2026, führt deepseek_r1 für die Serie DeepSeek R1 und qwen3 für die Qwen3-Serie. Die Antwort enthält dann neben dem Inhalt ein Feld reasoning, das in früheren Versionen reasoning_content hieß.

Zwei Steuerungen wirken je Anfrage. Bei Modellen, die enable_thinking nutzen, setzt ein reasoning_effort von low, medium oder high es auf true und none auf false, sofern die Anfrage enable_thinking nicht selbst setzt. Der Sampling-Parameter thinking_token_budget setzt eine Grenze je Anfrage, und sobald sie erreicht ist, „zwingt vLLM das Modell, reasoning_end_str zu erzeugen“, die Endmarke, die mit --reasoning-config gesetzt oder aus dem Reasoning-Parser übernommen wird. Ohne Budget gilt laut Dokumentation „über normale Generierungsgrenzen wie max_tokens hinaus keine ausdrückliche Reasoning-Grenze“.

Setzen Sie --max-model-len auf den Prompt, den Verlauf und das längste Reasoning, das Sie zulassen, nicht auf das Maximum des Modells. Ein Budget, das das Reasoning abkürzt, tauscht Antwortqualität gegen Last; testen Sie es also auf Ihrem Evaluationssatz.

Reasoning-Last im Piloten messen

Model Cards nennen Benchmark-Mittelwerte, deshalb misst ein Pilot die Ausgabelänge Ihrer eigenen Anwendungsfälle.

1. Protokollieren Sie jede Anfrage am Gateway mit Start- und Endzeit sowie der Zahl ihrer Reasoning- und Antwort-Token.
2. Lassen Sie jeden Anwendungsfall mit der geplanten Reasoning-Stufe laufen und einmal mit der nächstniedrigeren Stufe.
3. Nehmen Sie die Ankunftsrate der stärksten Stunde sowie Median und 95. Perzentil der Ausgabe-Token je Anfrage.
4. Berechnen Sie Anfragen in Bearbeitung und Decode-Last wie in der Tabelle oben, und testen Sie die infrage kommende GPU mit diesen Längen unter Last.

Unsere Leistung Private AI/ML startet mit einem Pilotprojekt auf einem Prozess mit klaren Metriken. Schreiben Sie uns, welchen Prozess der Pilot abdecken soll und welche Reasoning-Stufe er voraussichtlich braucht.

Was wir liefern

Wir liefern die RTX PRO 6000 als Workstation, Max-Q und Server Edition, die H200 NVL mit Zweifach- und Vierfach-NVLink-Brücken, die L40S, die L4 und die DGX Spark Founders Edition, als Karten aus unserem Sortiment professioneller GPUs oder in nach Auftrag gebauten KI-Servern mit 2 bis 8 GPUs je Knoten. Für ein Reasoning-Modell legen wir den Server nach Modell, Reasoning-Stufe je Anwendungsfall, deklariertem Kontext und Spitzenzahl der Anfragen in Bearbeitung aus. Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen, und Konfiguration und Angebot folgen innerhalb eines Werktages, unter einem EU-Vertrag und auf einer Rechnung, mit Herstellergarantie. Die Bereitstellung des Modells mit vLLM, RAG und MLOps ist unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ