Qwen3.8-Flash-Next unter Verwendung von RTX 3090-Grafikkarten mit Tensor-Offloading über llama.cpp
Warum ein 88 GB großes, sparsames Modell mit 180 Milliarden Parametern auf Consumer-GPUs passt und wie Flags wie -ot, -ncmoe sowie mmap von llama.cpp es auf VRAM, RAM und NVMe aufteilen.
Qwen3.8-Flash-Next ist ein offenes Modell mit etwa 180 Milliarden Parametern, dessen quantisierte Dateien insgesamt 88 GB umfassen. Dennoch berichten einige Nutzer davon, es auf einer einzigen RTX 3090 mit 24 GB VRAM laufen zu lassen. Auf dem Papier liegt das um einen Größenordnung unterschied. Es funktioniert aufgrund der Architektur des Modells – nicht wegen einer cleveren Quantisierung oder einer außergewöhnlich leistungsstarken GPU: Große Teile des Modells müssen überhaupt nicht auf der Grafikkarte gespeichert werden. Dieser Artikel erläutert die vier Gestaltungsentscheidungen, die das möglich machen, und zeigt anschließend vollständige llama.cpp-Konfigurationen für Systeme mit drei GPUs sowie einem einzelnen GPU, einschließlich der Funktion jeder wichtigen Flagge und der realistischen Durchsatzwerte, die man erwarten kann.
Warum Flash-Next lohnenswert ist, lokal zu betreiben
Alibaba hat Flash-Next im August veröffentlicht. Zum Zeitpunkt der Erstellung dieses Textes liegen die veröffentlichten Ergebnisse vor und zeigen, dass es Qwen3.8-27B, DeepSeek V4 Flash (0731) sowie auf mehreren agilen Benchmarks Opus 4.6 übertrifft – und zwar bei der Aktivierung von nur 6 Milliarden Parametern pro Token. Die Rangfolgen auf den Benchmarks ändern sich schnell, daher sollten Sie die aktuellen Bewertungen prüfen, bevor Sie diese Vergleiche als endgültig betrachten. Entscheidender ist vielmehr die Struktur des Modells, denn sie bestimmt, welche Hardware es unterstützen kann.
Vier architektonische Ansätze, die die Rechenlast von der GPU nehmen
Flash-Next kombiniert vier Konzepte. Jedes davon verlagert einen teuren Rechenschritt von teurer auf günstigere Hardware oder entfernt ihn ganz.
Ultra-sparse Mixture of Experts
Das Modell hat 48 Schichten, und jede Schicht enthält 512 Experten-Unternetzwerke. Jeder einzelne Token durchläuft nur 11 davon: 10 werden von einem Router ausgewählt, der den Token prüft und die am besten geeigneten Spezialisten auswählt, plus 1 gemeinsamer Experte, den jeder Token ohne Routing verwendet. Mit anderen Worten: Etwa 2 % der Experten erledigen die Arbeit für einen gegebenen Token.
Eine nützliche Analogie ist ein Krankenhaus mit 512 im Bereitschaftsdienst stehenden Spezialisten und einem Hausarzt, der stets im Raum ist. Jeder Patient erhält zehn Beratungen, die zu seinen Symptomen passen, wobei die anderen 501 Spezialisten nicht beteiligt sind. Die entscheidende Erkenntnis für lokale Inferenz ist, dass „im Bereitschaftsdienst“ lediglich „erreichbar“ bedeutet. Ein Spezialist muss nicht unbedingt auf einer GPU sitzen, um verfügbar zu sein.
Der gemeinsame Experte existiert, weil rein routenbasierte Designs dazu neigen, das allgemeine Wissen zu verlieren, das jedes Token benötigt. Durch die Unterbringung dieses Wissens in einem stets aktiven Generalisten können sich die routenbasierten Experten intensiver spezialisieren. Die meisten aktuellen MoE-Designs beinhalten einen solchen Generalisten, und seine Parameter gehören zur Gesamtanzahl der 6 Milliarden Aktivitäten.
Gated DeltaNet plus Qwen Sparse Attention
Ein Standard-Transformer speichert eine Schlüssel/Wert-Einträge für jedes verarbeitete Token. Dieser KV-Cache wächst linear mit dem Kontextumfang und wird bei langen Texten enorm groß. Flash-Next umgeht dieses Problem größtenteils. Drei von vier Schichten verwenden Gated DeltaNet, das die Historie in einen kleinen, festen Zustand komprimiert. Die verbleibende Schicht in jeder Gruppe nutzt Qwen Sparse Attention, das aus einem festen Pool von 512 Blöcken, 2.048 Tokenn liest – unabhängig davon, ob der Kontext 32.000 oder eine Million Token enthält.
Die praktischen Auswirkungen sind bemerkenswert: Bei einem Kontextumfang von 178 K benötigt der KV-Cache in den unten aufgeführten Konfigurationen etwa 6 GB, während ein vergleichbares dichtes Modell rund zehnmal so viel benötigen würde. Deshalb kann eine Karte mit 24 GB überhaupt ein langes Gespräch speichern.
Eine gesteuerte, mehrspurige Residualstrom-Struktur
Klassische Transformer leiten alles über einen einzigen Residualstrom von der ersten bis zur letzten Schicht, wodurch frühe Merkmale in tiefen Netzwerken im Laufe des Weges oft verfälscht werden. Flash-Next erweitert diesen Pfad auf vier parallele Spuren, wobei gelernte Türen steuern, was in jede Spur eintritt und welche wieder verlassen. Während des Trainings spezialisierte sich eine dieser Spuren als Langstreckenkanal, der frühe Informationen tief in das Netzwerk transportiert. Es handelt sich um eine kleine architektonische Änderung, die ohne nennenswerte Kosten zusätzliche Fähigkeiten bietet.
Eine n-gramm-basierte Embedding-Tabelle
Der vierte Bestandteil ist eine Tabelle mit 51 Milliarden Parametern, mehr als der Rest des Modells zusammen, die keine Matrixmultiplikationen durchführt. Es handelt sich dabei um eine Abfragestruktur, und sie ist der Hauptgrund dafür, dass eine einzelne Gaming-GPU ausreicht.
Die n-gramm-Tabelle: Wissen, das keine GPU benötigt
In einem normalen Sprachmodell wird jeder Token auf eine ID abgebildet, und das Modell sucht diese ID in einer Embedding-Tabelle nach – eine Zeile pro Token. Eine Zeile mit nur einem Token enthält sehr wenig Information über den Kontext. Bei einem Satz wie „Dostojewski schrieb die Brüder“ sagt das Embedding für „die“ nichts über die Karamasow-Brüder aus; das Modell muss die Fortsetzung mit seinen aufwändigen Schichten erschließen und dies jedes Mal tun, wenn dieses Muster auftaucht.
Flash-Next fügt eine zweite Tabelle hinzu, deren Zeilen durch kurze Phrasen statt durch einzelne Token identifiziert werden. Konzeptuell sehen die Einträge wie der untenstehende Entwurf aus: eine gehashte Phrase auf der linken Seite und die Art von Hinweis, den ihr gelernter Vektor auf der rechten Seite kodiert.
Drawer "born on october" → hint: 1985, Honolulu, singer
Drawer "dostoevsky brothers" → hint: Karamazov, novel, 1880
Drawer "def main(" → hint: python entry point
Beim Lesen hasht das Modell die neuesten Token, holt die entsprechende Zeile ab und erhält somit im Grunde kostenlos einen vorberechneten Hinweis. Niemand hat diese Zeilen von Hand verfasst. Während des Trainings wurde jede Zeile jeweils leicht in die Richtung angepasst, in der eine bestimmte Fortsetzung nach einer Phrase kam; dadurch approximiert jede Zeile nach Trillionen von Token das, was in der Regel als Nächstes kommt. Die Tabelle enthält etwa 20 Millionen Bigramm- und Trigrammeinträge, und ihre Ausgabe wird bereits früh in Schicht 2 eingespeist. Im Grunde handelt es sich dabei um das Merken häufiger Ausdrucksweisen – und ein großer Teil des echten Textes besteht aus solchen häufigen Ausdrucksweisen.
Der Unterschied zwischen den beiden Arten von Wissen im Modell ist es, der eine Aufteilung des Hardwares ermöglicht. Der folgende Vergleich fasst dies zusammen.
| | Neural network | N-gram table |
|------------------|-------------------------|-------------------------|
| Work per token | Matrix math (expensive) | Drawer lookup (no math) |
| Needs the GPU? | Yes, every millisecond | No — CPU can fetch it |
| Lives in | VRAM | RAM. Even SSD. |
Die entscheidende Eigenschaft ist, dass die zu ladenden Zeilen nur vom Eingabetext abhängen und nicht von einem versteckten Zustand innerhalb des Netzwerks. Sobald ein Prompt tokenisiert wird, weiß die CPU genau, welche Zeilen benötigt werden, sodass sie diese vorladen kann, während die GPU noch mit früheren Schichten beschäftigt ist.
Dadurch kann das Modell entsprechend den Stärken jeder Speicherebene in der Speicherhierarchie verteilt werden:
- VRAM (schnell, teuer): die etwa 6 Milliarden Parameter, die tatsächlich für jeden Token berechnet werden.
- System-RAM (mäßig, günstig): inaktive Expertenwerte sowie die 29 GB große n-gramm-Tabelle.
- NVMe-Speicher (langsam, günstigst): Überlaufdaten, die nur dann geladen werden, wenn sie benötigt werden.
Die GPU ist nicht mehr der Ort, an dem das gesamte Modell gespeichert wird, sondern dient nun als Ort für die aktive Berechnung.
Eine dreifache GPU-Konfiguration für den täglichen Gebrauch
Betrachten wir einen Server, der aus drei RTX 3090-Karten (insgesamt 72 GB VRAM), 48 GB DDR4-Systemram und einer PCIe Gen3 NVMe-Festplatte besteht, auf der die Gewichte gespeichert sind. Nichts daran gehört zur Klasse von Workstations – es handelt sich um die Art von Maschine, die viele Entwickler aus älteren Gaming-Karten zusammenbauen.
Die hier verwendete Modelldatei ist die UD-IQ4_XS-Version aus dem GGUF-Repository von unsloth für dieses Modell auf Hugging Face; sie umfasst etwa 88 GB, die sich auf drei Teile verteilen: rund 59 GB an Hauptgewichten sowie 29 GB für die n-gramm-Tabelle. Die Unterstützung für diese Architektur ist noch neu, daher sollten Sie die neueste Version von llama.cpp herunterladen und neu kompilieren, bevor Sie es ausprobieren.
Der untenstehende Befehl startet llama-server auf drei der GPUs des Rechners. Die meisten Flags sind üblich (Host, Port, Sampling-Parameter, Batch-Größen, Kontextlänge), daher sollten Sie besonders auf die Offload-Flags, die Split-Flags sowie den Lademodus achten, die gleich weiter unten erläutert werden.
CUDA_VISIBLE_DEVICES=0,2,3 CUDA_SCALE_LAUNCH_QUEUES=4x llama-server \
-m /mnt/data_2t/ai_models_all/llm_hf_models/unsloth/Qwen3.8-Flash-Next-GGUF/Qwen3.8-Flash-Next-UD-IQ4_XS-00001-of-00003.gguf \
--alias Qwen3.8-Flash-Next \
--jinja \
--metrics \
--host 0.0.0.0 \
-ngl 99 \
--batch-size 4096 \
--ubatch-size 512 \
--flash-attn on \
--temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 --repeat-penalty 1.0 \
--split-mode layer \
--tensor-split 0.9,0.95,1.0 \
--fit off \
--main-gpu 0 \
--ctx-size 178000 \
--parallel 1 \
--image-min-tokens 1024 \
--reasoning-format none \
--timeout 1200 \
--ctx-checkpoints 8 \
--port 8082 \
--load-mode mmap \
--cache-type-k q8_0 --cache-type-v q8_0 \
-ot '^per_layer_token_embd\.weight$=CPU' \
--reasoning-effort low \
-t 14
Fixierung der n-gramm-Tabelle in der System-RAM
Die -ot '^per_layer_token_embd\.weight$=CPU' -Übernahme weist llama.cpp an, dass jeder Tensor, dessen Name mit der regulären Ausdrucksregel übereinstimmt, im CPU-Speicher statt in der VRAM gespeichert werden soll. Die n-gramm-Tabelle wird unter dem Tensornamen per_layer_token_embd.weight gespeichert, wodurch diese einzige Zeile alle 29 GB davon vor den GPUs schützt. Wenn ein Token eine Zeile benötigt, holt der CPU diese ab und gibt das Ergebnis weiter – genau wie bei der oben beschriebenen Vorausladestrategie. Die Anker ^ und $ sind wichtig: Sie stellen sicher, dass das Muster nur auf diesen Tensor angewendet wird und nicht versehentlich andere Gewichte beeinflusst.
Erlauben des OS, die Speicherplatzverwaltung mit mmap zu übernehmen
--load-mode mmap erstellt eine Speicherkartei des Modellfiles anstelle dessen, es vorab in den RAM zu lesen. Das Betriebssystem behält anschließend die häufig genutzten Seiten im verfügbaren Pagenkacheln und lässt die selten genutzten Seiten auf der SSD. Bei 48 GB RAM und einer 29 GB großen Tabelle ist das der richtige Kompromiss: Der Kernel entscheidet, was im Arbeitsspeicher bleiben soll. Auf einem Rechner mit viel Speicher, beispielsweise 128 GB, macht es mehr Sinn auf none umzustellen, da das gesamte File nur einmal gelesen wird und danach keine Pagenfehler auftreten.
Trennung der Schichten auf mehrere Karten
--split-mode layer in Kombination mit --tensor-split 0.9,0.95,1.0 teilt das 59GB große Backbone in aufeinanderfolgende Gruppen von Schichten auf, wobei jede GPU eine Gruppe erhält; die Proportionen sind leicht ungleichmäßig, damit die erste Karte genügend Kapazität für ihre zusätzlichen Aufgaben als --main-gpu hat. -ngl 99 verteilt alle 48 Schichten auf die GPUs, was etwa 20GB pro Karte entspricht. Der KV-Cache, der über --cache-type-k und --cache-type-v auf q8_0 quantisiert wird, befindet sich neben den Gewichten und umfasst 178K Token bei etwa 6GB.
Messbarer Durchsatz auf drei Karten
In dieser Konfiguration sind die angegebenen Werte unten aufgeführt.
Decode: 30-50 tokens/second
Prefill: 400-700 tokens/second
Context: 178,000 tokens
Das ist schneller als die Lesegeschwindigkeit eines Modells aus der frontier-ähnlichen Klasse auf genutzten Consumer-Karten in einem Mid-Tower-Gehäuse.
Konfiguration mit einer einzigen GPU und ihre Grenzen
Eine 3090 reicht aus, wenn eine Bedingung erfüllt ist: mindestens 64 GB System-RAM. Die n-gramm-Tabelle sowie die ausgelagerten Experten benötigen einen Speicherort, und der Systemspeicher ist in der Regel die günstigste Aufrüstung für eine lokale KI-Maschine.
Der Befehl verwendet dieselbe GGUF-Datei. Die auffälligen Unterschiede sind die neue -ncmoe-Flagge, eine einzige sichtbare GPU, --load-mode none anstelle von mmap sowie weniger CPU-Threads.
CUDA_VISIBLE_DEVICES=0 llama-server \
-m /mnt/data_2t_3/ai_models_all/unsloth/Qwen3.8-Flash-Next-GGUF/Qwen3.8-Flash-Next-UD-IQ4_XS-00001-of-00003.gguf \
--alias Qwen3.8-Flash-Next \
--jinja \
--metrics \
--host 0.0.0.0 \
-ngl 99 \
-ncmoe 38 \
--batch-size 4096 \
--ubatch-size 1024 \
--flash-attn on \
--temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 --repeat-penalty 1.0 \
--ctx-size 178000 \
--parallel 1 \
--image-min-tokens 1024 \
--reasoning-format none \
--timeout 1200 \
--ctx-checkpoints 8 \
--port 8083 \
--load-mode none \
-ot '^per_layer_token_embd\.weight$=CPU' \
--reasoning-effort low \
-t 8
Was -ncmoe 38 bewirkt
-ncmoe 38 speichert die Experten-Gewichte der ersten 38 Schichten im CPU-RAM, während die letzten 10 Schichten ihre Experten in VRAM speichern. Dadurch landen etwa 43 GB an Experten-Gewichten im Systemspeicher. Die Aufmerksamkeits- und gemeinsamen Komponenten jeder Schicht laufen weiterhin auf der GPU aufgrund von -ngl 99.
Durch die Spärlichkeit ist das Speichern großer Mengen in RAM weiterhin machbar. Jedes Token aktiviert 10 der 512 Experten pro Schicht, wodurch insgesamt nur etwa 1,3 GB an Gewichten der Experten berührt werden. Die in RAM gespeicherten Experten werden dort auf dem CPU berechnet, ohne dass sie auf die GPU kopiert werden müssen, während die in VRAM gespeicherten Experten direkt auf der Karte ausgeführt werden. Der CPU ist deutlich langsamer als eine 3090, wodurch es tatsächlich zu Nachteilen kommt, doch diese hängen von den etwa 2 % der Gewichte ab, die jedes Token berührt, und nicht von dem gesamten gespeicherten Inhalt.
Weil hier so viel in RAM untergebracht werden kann, liest --load-mode none beim Start die Datei vollständig ein anstelle davon, auf Seitenfehler zurückzugreifen – was ein weiterer Grund dafür ist, warum eine Mindestgröße von 64 GB wichtig ist.
Anpassung für andere Karten
Derselbe Befehl funktioniert auch bei einer RTX 4090 oder 5090; nur -ncmoe muss an die verfügbare VRAM angepasst werden. Die empfohlenen Ausgangswerte sind unten aufgeführt.
| GPU | VRAM | Suggested -ncmoe | Experts in RAM |
|------------|------|------------------|----------------|
| RTX 3090 | 24GB | 38 | ~43GB |
| RTX 4090 | 24GB | 38 | ~43GB |
| RTX 5090 | 32GB | 28-30 | ~32GB |
Jeder Schritt, bei dem Sie -ncmoe verringern, bringt die Experten eines Layers – etwa 1,1 GB – wieder auf die GPU zurück. Nach dem Laden des Modells sollten Sie nvidia-smi überprüfen und darauf achten, dass etwa 500 MB VRAM frei bleiben; wenn die Grafikkarte vollständig ausgelastet ist, treten bei wachsendem Kontext Speicherfehler auf.
Realistische Erwartungen setzen
Auf einer einzelnen 3090 erfolgt die Dekodierung mit **15 bis 20 Tokens pro Sekunde**. Das ist nutzbar, aber nur knapp: schnell genug, um mitzulesen, langsam genug, sodass lange Generierungen träge wirken, da ein Teil der Berechnungen tatsächlich auf der CPU im System-RAM stattfindet. Als Konzeptbeispiel oder um einen bereits vorhandenen Rechner optimal zu nutzen, ist es bemerkenswert, ein 180B-Modell in Lesegeschwindigkeit auf einer Gaming-Karte laufen zu lassen.
Für einen Assistenten, den man den ganzen Tag über für Programmierung und alltägliche Aufgaben nutzen möchte, sind drei oder vier 3090-Karten erforderlich, um ein angenehmes Erlebnis zu gewährleisten. Der Unterschied zwischen etwa 18 und 40 Tokens pro Sekunde markiert die Grenze zwischen einer Demo und einem täglichen Werkzeug. Wenn man stattdessen kleinere lokale Qwen-Modelle für agierende Programmierung ausprobiert, zeigt die Anleitung zu der Erstellung eines lokalen Spiels mit Qwen3.8-27B eine leichtere Konfiguration.
Mehrtoken-Vorhersage: Die nächste Geschwindigkeitssteigerung, auf die man achten sollte
Flash-Next verfügt über einen trainierten multi-token prediction (MTP) Head, ein kleines zusätzliches Modul, das gleichzeitig mehrere zukünftige Token vorschlägt, damit das Hauptmodell sie parallel überprüfen kann. Es handelt sich dabei um eine spekulative Dekodierung mit einem für genau dieses Modell end-to-end trainierten Entwurfskomponenten. Auf vLLM wurde berichtet, dass es bei echten Anfragen eine Geschwindigkeitssteigerung von etwa 2,5 Mal bei der Dekodierung bringt.
Zum Zeitpunkt der Erstellung unterstützt llama.cpp die Flash-Next-Architektur selbst, doch sein Entwurf für den MTP-Pfad umfasst diesen Modelltyp noch nicht. Es gibt Unterstützung für verwandte Modelle, sodass die Änderungen vermutlich gering ausfallen werden. Überprüfen Sie jedoch vorab die aktuellen Release-Notes von llama.cpp, bevor Sie davon ausgehen, dass die Unterstützung bereits verfügbar ist. Sobald sie implementiert ist, könnte die Leistung der dreifach-GPU-Konfiguration mit 30 bis 50 Tokens pro Sekunde allein durch ein Software-Update auf etwa 60 bis 100 Tokens pro Sekunde auf derselben Hardware ansteigen. Betrachten Sie dies zunächst als Schätzung, bis Sie konkrete Messwerte haben.
Hauptpunkte
- Flash-Next eignet sich aufgrund seines Designs – und nicht durch reine Rechenkraft – für Consumer-Hardware: eine ultradünne MoE-Struktur, ein fester Aufmerksamkeitszustand sowie eine ausschließlich zur Abfrage dienende n-gramm-Tabelle verringern alle zusammen den Speicherbedarf in der VRAM.
-ot in Kombination mit einer präzisen Regex dient dazu, es dort zu platzieren.-ncmoe ist die wichtigste Einstellung für Ein-GPU-Setups: Senken Sie diesen Wert, bis der VRAM fast voll ist und ein kleiner Sicherheitspuffer bleibt.mmap, wenn der RAM begrenzt ist und Sie möchten, dass das Betriebssystem die Speicherung verwalten lässt; wählen Sie none, wenn genügend RAM vorhanden ist und Sie eine vorhersehbare Latenz nach dem Laden wünschen.