Qwen-Hardware-Anforderungen: Qwen3.8-27B und Flash-Next auf DGX Spark, RTX PRO 6000 und H200 NVL

Qwen-Hardware-Anforderungen für 1, 20 und 100 Nutzer

Die Hardware-Anforderungen von Qwen hängen von der Modellgröße und vom Checkpoint-Format ab. Qwen3.8-27B, das dichte Modell der aktuellen Qwen-Generation, läuft in Qwens FP8-Version mit 30,9 GB auf einem DGX Spark, einer RTX PRO 6000 oder einer H200 NVL, und eine Karte, ob RTX PRO 6000 oder H200 NVL, bedient 20 Gespräche mit 32.768 Token. Qwen3.8-Flash-Next, ein Mixture-of-Experts-Modell mit einem FP8-Checkpoint von 172,78 GiB, braucht zwei H200 NVL oder vier RTX PRO 6000 für einen Nutzer und acht für 20. Für 100 gleichzeitige Gespräche mit 32K schätzen wir für Qwen3.8-27B vier RTX PRO 6000 oder zwei H200 NVL und für Flash-Next vier H200 NVL.

Das sind Schätzungen für die Planung, keine Messungen, mit Modellangaben von Qwens Hugging-Face-Seiten und aus den offiziellen vLLM-Rezepten, abgerufen am 9. Oktober 2026. Unser Überblick über LLM-Hardware-Anforderungen je Modell vergleicht Qwen3.8 mit anderen Modellfamilien.

Qwen3.8-Modelle, Checkpoints und Kontext im Oktober 2026

Qwens Organisation auf Hugging Face führt drei Sprachmodelle von Qwen3.8, jedes in BF16 und in Qwens eigener FP8-Version, veröffentlicht im August 2026.

Model Cards, Dateilisten und config.json-Dateien auf Hugging Face (Qwen) sowie das vLLM-Rezept für Qwen3.8-Flash-Next (aktualisiert am 30. September 2026) für die Checkpoint-Größen von Flash-Next, abgerufen am 9. Oktober 2026.

Die FP8-Versionen des 27B- und des Flash-Next-Modells skalieren die Gewichte in Blöcken von 128 × 128 und behalten die Token-Embeddings und den Ausgabe-Layer in 16 Bit, wie ihre config.json-Dateien angeben. Auf Hugging Face fanden wir keinen Qwen3.8-Checkpoint von NVIDIA und keine NVFP4-Version von Qwen. Das 27B-Rezept von vLLM führt NVFP4-Checkpoints von Drittanbietern aus und hält im englischen Original fest, hier übersetzt, dass das Modell „in jeder Präzision auf eine Blackwell-GPU passt: NVFP4 in 24,6 GiB“.

Die 27B-Card hält fest, hier aus dem Englischen übersetzt, dass „Qwen3.8-Modelle standardmäßig im Thinking-Modus arbeiten“, und eine Anfrage schaltet ihn mit enable_thinking auf false ab, wie bei Flash-Next. Das 2.4T-Modell setzt laut seiner Card den Thinking-Modus für alle Interaktionen voraus.

KV-Cache je Gespräch im hybriden Layout von Qwen3.8

Wir dimensionieren jede Konfiguration nach einer Regel: Die Gewichte plus ein KV-Cache je Gespräch müssen in 90 Prozent des vom Treiber gemeldeten Speichers passen, abzüglich 3 GiB je Karte; das lässt 83,04 GiB auf einer RTX PRO 6000 und 123,36 GiB auf einer H200 NVL. Für einen DGX Spark (128 GB), die Version, die wir liefern, setzen wir 102 GB an. Unser Leitfaden dazu, wie viel VRAM ein LLM braucht, erklärt die Regel.

In Qwen3.8 nutzen drei von vier Layern Gated DeltaNet, eine Linear Attention, die je Gespräch einen festen Zustand statt eines Caches je Token hält. Die config.json von Qwen3.8-27B nennt 16 Layer mit voller Attention mit vier KV-Heads der Dimension 256, das ergibt 64 KiB je Token in 16 Bit. Seine 48 DeltaNet-Layer halten je 48 Value-Heads mit 128 × 128 Werten in float32, dem mamba_ssm_dtype, den die Datei setzt, also 144 MiB je Gespräch, unabhängig von dessen Länge. Flash-Next hat 12 Layer mit Sparse Attention mit zwei KV-Heads der Dimension 256, 12 KiB je Token in FP8. Sein Indexer fügt je Layer einen Key mit 128 Werten Breite hinzu, den wir mit bis zu 1,5 KiB je Token ansetzen, und seine 36 DeltaNet-Layer halten 108 MiB.

Unsere Rechnung aus den config.json-Dateien von Qwen3.8-27B und Qwen3.8-Flash-Next-FP8, für ein Gespräch und das ganze Modell, einschließlich des Zustands der Linear Attention. Für mehrere Karten nehmen wir an, dass vLLM die KV- und DeltaNet-Heads auf die GPUs aufteilt und jede GPU mindestens einen KV-Head behält, sodass die zwei KV-Heads von Flash-Next auf vier oder acht Karten je Karte mehr kosten als einen gleichmäßigen Anteil; ein vLLM-Dokument, das dies festhält, haben wir nicht gefunden.

Ein Gespräch mit 1M Token bräuchte bei Qwen3.8-27B etwa 61 GiB Cache in 16 Bit. Die Cards empfehlen für Reasoning-Inhalte ein Ausgabelimit von 262.144 Token, und preserve_thinking, standardmäßig aktiv, behält die Thinking-Blöcke früherer Runden im Gespräch. Der Kontext, den Sie vLLM angeben, entscheidet darüber, wie viele Gespräche in voller Länge Platz haben.

GPUs für Qwen3.8 bei 1, 20 und 100 Nutzern

Unsere Schätzungen, keine Messungen, der Kartenzahl für 1, 20 und 100 gleichzeitige Gespräche mit je 32.768 Token, in Konfigurationen mit 1, 2, 4 oder 8 Karten; Cache in 16 Bit für Qwen3.8-27B und in FP8 für Flash-Next, wie es das Flash-Next-Rezept von vLLM setzt. Beim DGX Spark zeigt die Tabelle nur, ob der Speicher reicht, für die Version mit 128 GB. PLE-Offload hält die N-Gram-Tabelle im Host-Speicher, was das vLLM-Rezept nur auf der H100 validiert.

Qwen3.8-27B in FP8 lässt auf einer RTX PRO 6000 54,3 GiB für den Cache, Platz für 25 Gespräche mit 32K, und auf einer H200 NVL 94,6 GiB, Platz für 44. Mit Tensor-Parallelismus auf vier RTX PRO 6000 verteilt, fasst es etwa 141 Gespräche, und zwei H200 NVL fassen etwa 101. Ein FP8-Cache, den die meisten CUDA-Befehle im 27B-Rezept von vLLM setzen, halbiert die Kosten je Gespräch: 47 passen auf eine RTX PRO 6000, zwei Karten bedienen also 100 Nutzer.

Da die 27B-Gewichte auf eine Karte passen, können vier RTX PRO 6000 auch je eine Kopie ausführen, mit 25 Gesprächen je Kopie und ohne Datenverkehr über PCIe; diese Abwägung behandelt unser Artikel zur Aufteilung eines Modells über PCIe oder NVLink.

Wir bauen Inferenz-Server mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern. Schicken Sie uns die Qwen-Variante, Ihre Kontextlänge und die Spitzenzahl gleichzeitiger Gespräche über das Formular unten, und wir antworten mit Konfiguration und Angebot.

Qwen3.8-27B auf einer Karte oder einem DGX Spark

Auch der BF16-Checkpoint passt auf eine Karte, lässt auf einer RTX PRO 6000 aber 31,3 GiB, genug für 14 Gespräche mit 32K; für ein Team ist deshalb Qwens FP8-Version die praktische Wahl. Das 27B-Rezept von vLLM, aktualisiert am 8. Oktober 2026, gibt die FP8-Gewichte auf zwei GPUs mit 14,28 GiB je GPU an, im Einklang mit unserer Rechnung.

Ein DGX Spark mit 128 GB fasst beide Checkpoints, den FP8-Checkpoint mit Platz für etwa 30 Gespräche mit 32K. Auf einem Spark begrenzt die Geschwindigkeit ein Team früher als der Speicher. Seine Speicherbandbreite beträgt 273 GB/s, gegenüber 1.597 GB/s bei der RTX PRO 6000 Server Edition und 4,8 TB/s bei der H200 NVL. Ein dichtes Modell liest für jedes Token alle seine Gewichte, deshalb passt ein Spark zu einem Entwickler oder einem kleinen Pilotprojekt.

Prüfen Sie bei der RTX PRO 6000 vor dem Kauf die Engine. Das 27B-Rezept meldet vLLM-Läufe auf zwei Consumer-Blackwell-Karten derselben Chipfamilie sm120 und hält für sie fest, hier aus dem Englischen übersetzt: „Der blockskalierte FP8-Checkpoint braucht keinen Workaround.“ Die Support-Matrix von TensorRT-LLM (Version 1.3.0rc29) führt für diese Chipfamilie nur FP8 mit Skalierung je Tensor, nicht die Block-Skalierungen von 128 × 128 der FP8-Version von Qwen.

Qwen3.8-Flash-Next: die N-Gram-Tabelle bestimmt die Kartenzahl

Die N-Gram-Embedding-Tabelle von Flash-Next mit 51B, in FP8 etwa 47,5 GiB, erhöht seine Kartenzahl. Das vLLM-Rezept hält unter einfachem vierfachem Tensor-Parallelismus fest, hier übersetzt, dass „die 80 GB je GPU der H100 nicht genug Reserve für die 51B große N-Gram/PLE-Embedding-Tabelle bieten“. Wir lesen das als eine Kopie der Tabelle auf jeder GPU, zuzüglich des Anteils jeder GPU am Rest.

Nach dieser Lesart tragen zwei H200 NVL je 110,1 GiB und behalten 13,2 GiB für den Cache, genug für etwa 46 Gespräche mit 32K. Vier RTX PRO 6000 tragen je 78,8 GiB und behalten 4,2 GiB, etwa 16 Gespräche. Acht RTX PRO 6000 behalten 19,9 GiB je Karte, etwa 80 Gespräche, was 20 Nutzer bedient, aber nicht 100. Vier H200 NVL behalten 44,5 GiB je Karte, Platz für etwa 170.

Das Rezept bietet auch eine Alternative. Mit VLLM_PLE_CPU_OFFLOAD=1 wandert die Tabelle in den Host-Speicher, für den es, hier übersetzt, „mindestens 51 GB plus Reserve für die Laufzeit“ verlangt. Vier RTX PRO 6000 behalten dann 51,7 GiB je Karte und zwei H200 NVL 60,7 GiB, nach unserer Schätzung beides genug für 100 Gespräche. Das Rezept validiert die Auslagerung nur auf vier H100, testen Sie sie also zuerst auf Ihrer Plattform.

Auf acht GPUs nutzt das Rezept Tensor-Parallelismus mit Experten-Parallelismus (TEP8), weil, hier übersetzt, „einfaches TP8 mit seinen 128 breiten Quantisierungsblöcken nicht kompatibel ist“. Sein Befehl für acht H200 nutzt TEP8, und sein Test mit KV-Offloading lief mit vierfachem Tensor-Parallelismus auf vier H200. Zweifacher Tensor-Parallelismus ist nur auf GB300 validiert, und der Text des Rezepts enthält keinen Befehl für die RTX PRO 6000, deshalb sind unsere Aufteilungen für zwei H200 NVL und für RTX PRO 6000 Schätzungen. Auf RTX PRO 6000 laufen All-Reduce und Expertenverkehr über PCIe, während sich zwei oder vier H200 NVL eine NVLink-Brücke teilen können.

Wir bauen Server mit vier oder acht RTX PRO 6000 oder H200 NVL und prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Beschreiben Sie Ihren Rack-Standort, seine Stromversorgung und den geplanten Host-Speicher im Formular unten.

vLLM-Einstellungen für Qwen3.8 aus den offiziellen Rezepten

Das Flash-Next-Rezept von vLLM, aktualisiert am 30. September 2026, stellt den FP8-Checkpoint auf acht H200 mit --tensor-parallel-size 8, --enable-expert-parallel, --moe-backend triton und --gpu-memory-utilization 0.85 bereit. Den Speicher verändern --kv-cache-dtype fp8 und --attention-config.indexer_kv_dtype fp8, die beide Caches in FP8 speichern. Es ergänzt --enable-prefix-caching und Multi-Token Prediction mit drei spekulativen Token; der MTP-Layer hält einen kleinen eigenen Cache.

Beide Rezepte nutzen --reasoning-parser qwen3, und ihre Befehle mit Tool Calling ergänzen --tool-call-parser qwen3_coder. Ohne --max-model-len übernimmt vLLM die nativen 262.144 Token, und bei Mamba-Cache-Fehlern beim Start rät das Flash-Next-Rezept, --max-num-seqs 256 beizubehalten.

Der Kontext von 1M Token braucht eine YaRN-Einstellung. Die 27B-Card warnt, hier übersetzt, dass „alle namhaften Open-Source-Frameworks statisches YaRN implementieren“, was die Qualität bei kürzeren Texten beeinträchtigen kann, und rät, es nur zu aktivieren, wenn lange Kontexte gebraucht werden.

Qwen3.8-2.4T-A95B und frühere Qwen3-Modelle

Qwen3.8-2.4T-A95B ist in FP8 ein Repository mit 2,5 TB, mehr als die 1.128 GB von acht H200 NVL; allein nach den Gewichten braucht es also mindestens drei Server mit je acht Karten, einen Multi-Node-Cluster jenseits der hier dimensionierten Konfigurationen.

Frühere Qwen-Modelle folgen derselben Rechnung. Unser Leitfaden dazu, wie viele H200 NVL große Modelle brauchen, setzt Qwen3-235B-A22B-2507 allein nach den Gewichten mit zwei H200 NVL in FP8 (236 GB) und vier in BF16 (470 GB) an, und Qwen3.5-397B in FP8 (406 GB) mit vier. Die NVFP4-Version von Qwen3-235B mit 134 GB passt auf zwei RTX PRO 6000, die FP4 nativ ausführen, während die H200 NVL sie nur Weight-only ausführt. Für die Qwen3-Coder-Modelle nennt unser Leitfaden zum privaten Coding-Assistenten die Kartenzahl.

Lizenzbedingungen der Qwen3.8-Modelle

Qwen3.8-27B ist unter Apache 2.0 veröffentlicht, wie seine Model Card angibt. Qwen3.8-Flash-Next steht unter der Qwen Community License 1.0, deren Klausel 2 sinngemäß bestimmt: Betreibt der Lizenznehmer oder eines seiner verbundenen Unternehmen ein Geschäft als „Model as a Service“ oder „AI Work Assistant“, muss der Lizenznehmer eine separate Lizenz von Qwen einholen, bevor er die Software oder ihre abgeleiteten Werke für einen kommerziellen Zweck nutzt. Die Klausel nimmt eine interne Nutzung aus, die weder die Software noch ihre Ausgaben oder ihre Modellfähigkeiten einem Dritten zugänglich macht.

Das 2.4T-Modell hat eine eigene Qwen3.8-Max License mit Klauseln gleicher Struktur, deren Klausel 2 jedoch nur oberhalb einer Umsatzschwelle gilt. Beide Lizenzen definieren Model as a Service sinngemäß als Zugang eines Dritten zu Inferenz oder Fine-Tuning eines Sprachmodells, der es dem Dritten erlaubt, eine nennenswerte Kontrolle über Eingaben, Parameter oder Trainingsdaten auszuüben. Keiner der beiden Texte enthält, Stand 9. Oktober 2026, eine territoriale Beschränkung. Ob eine Klausel Ihr Unternehmen betrifft, ist eine rechtliche Bewertung für Ihre Rechtsabteilung.

Was wir liefern

Wir liefern die DGX Spark Founders Edition, die RTX PRO 6000 als Workstation, Max-Q und Server Edition sowie die H200 NVL mit ihren Zweifach- und Vierfach-NVLink-Brücken, als Karten oder in nach Auftrag gebauten KI-Servern. Sie kommen unter einem EU-Vertrag und auf einer Rechnung, mit Herstellergarantie, und unser Sortiment professioneller GPUs führt jede Karte. Mit der Qwen-Variante, der Kontextlänge und der Zahl gleichzeitiger Nutzer erhalten Sie von uns innerhalb eines Werktages eine Konfiguration und ein Angebot. Der Betrieb des Modells mit RAG und MLOps darauf ist unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ