Qwen3.8-27B auf einer RTX 3090: 262K Kontext bei 65–80 Tokens pro Sekunde

Ein dichtes Modell mit 27 Milliarden Parametern, das volle Kontextfenster von 262K, eine einzige in die Jahre gekommene Consumer-GPU und eine Generierungsgeschwindigkeit, die sich anfühlt wie ein Gespräch mit einem Menschen. Bis vor Kurzem klang dieser Satz nach Marketing. Mit Qwen3.8-27B und einem spezialisierten llama.cpp-Build ist das jetzt ein reproduzierbares Setup auf einer einzelnen RTX 3090.

Etwas Hintergrund, warum das zählt. Qwen3.8-27B ist ein starkes Modell für den Alltag, klar besser als die vorherige Generation Qwen3.6. Es in guter Qualität zu betreiben, war bisher aber teuer. Die nahezu verlustfreie Q8-Version braucht rund 28 GB VRAM, also passt sie auf keine einzelne Consumer-Karte. Viele Heim-Setups haben zwei RTX 3090 kombiniert, nur um ein solches Modell bereitzustellen. Das Rezept unten bringt eine deutlich schlankere Konfiguration auf einer gewöhnlichen 24-GB-Karte von 2020 zum Laufen.

Zuerst die Zahlen

Gemessen auf getrennten Maschinen, jeweils ein Modell und eine GPU:

| GPU            | Decode Speed    | Prompt Prefill   |
|----------------|-----------------|------------------|
| RTX 3090       | 65–80 tok/s     | 1,000–1,300 t/s  |
| RTX 3090 Ti    | 70–100 tok/s    | 1,200–1,700 t/s  |
| RTX 5090       | 150–180 tok/s   | 3,000–4,000 t/s  |

Schauen Sie sich die oberste Zeile noch einmal an: 65 bis 80 Tokens pro Sekunde auf einer einzigen RTX 3090. Das ist schneller, als die meisten Menschen lesen, und weit über den etwa 30 tok/s, ab denen sich ein Chat natürlich anfühlt. Und das auf einer Karte, die NVIDIA 2020 ausgeliefert hat, mit einem dichten 27B-Modell bei vollem Kontext. Die 3090 Ti schafft etwa 100, die 5090 liegt zwischen 150 und 180, was vor ein paar Jahren als Rechenzentrumsdurchsatz gegolten hätte.

Das ist weit mehr, als frühere lokale Setups geliefert haben. Was hat sich also geändert?

Drei Schritte zum Nachbauen

Schritt 1: den spezialisierten llama.cpp-Fork bauen

Ein llama.cpp-Fork namens llamAmpere zielt auf Ampere-GPUs und neuere und optimiert sie aggressiv:

git clone -b main https://github.com/JakeATX/llamAmpere.git
cd llamAmpere
cmake -S . -B build-sm86 -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ON -DGGML_CUDA_FA=ON \
      -DCMAKE_CUDA_ARCHITECTURES=86 -DGGML_NATIVE=ON
cmake --build build-sm86 -j8 --target llama-server

Die 86 ist dabei der CUDA-Architekturcode für Karten der RTX-30-Serie. Bei einer neueren Generation ersetzen Sie ihn: Ada (40er-Serie) nutzt 89, Blackwell (50er-Serie) 120. Der Fork selbst läuft auf allen, nur dieses Compiler-Flag unterscheidet sich.

Schritt 2: das speziell quantisierte Modell holen

Die Geschwindigkeit hängt an einer eigens dafür gebauten Quantisierung namens ATX-4-XS. Sie ist auf Hugging Face als jakeatx/Qwen3.8-27B-ATX-IQ4_XS-M-GGUF veröffentlicht und wiegt 14,5 GB. Herunterladen lässt sie sich auf zwei Wegen. Mit der Hugging Face CLI:

huggingface-cli download jakeatx/Qwen3.8-27B-ATX-IQ4_XS-M-GGUF \
    --local-dir ~/models/qwen38-27b-atx

Oder mit einfachem wget in einen Ordner Ihrer Wahl:

mkdir -p ~/models/qwen38-27b-atx
wget -O ~/models/qwen38-27b-atx/Qwen3.8-ATX-4-XS.gguf \
  "https://huggingface.co/jakeatx/Qwen3.8-27B-ATX-IQ4_XS-M-GGUF/resolve/main/Qwen3.8-ATX-4-XS.gguf"

Passen Sie die Pfade an, wenn Ihre Modelle woanders liegen, etwa auf einem eigenen Speicherlaufwerk.

Schritt 3: den Server starten

Starten Sie mit diesem Befehl, angepasst an Ihre eigenen Verzeichnisse:

CUDA_VISIBLE_DEVICES=0 GGML_Q8_TURBO3_MMA_FUSED=1 \
/home/andrewzhu/storage_1t_1/github_repos/llamAmpere/build-sm86/bin/llama-server \
    -m /mnt/data_2t_3/ai_models_all/Qwen3.8-27B-ATX-IQ4_XS-M-GGUF/Qwen3.8-ATX-4-XS.gguf \
    --alias Qwen3.8-27B-GGUF \
    -c 262144 -b 4096 -ub 1024 -t 8 -tb 8 -ngl 99 -fa on -ctk q8_0 -ctv turbo3 \
    --parallel 1 --jinja --fit off \
    --cache-prompt --cache-ram 8192 --ctx-checkpoints 24 --checkpoint-min-step 10240 \
    --spec-type draft-mtp --spec-draft-n-max 3 --spec-draft-p-min 0 \
    --spec-draft-type-k q8_0 --spec-draft-type-v q8_0 \
    --host 0.0.0.0 --port 8082 \
    --spec-draft-vocab-map docs/mtp-vocab/atx_65536.txt

Zwei Details kosten Geschwindigkeit, wenn man sie weglässt. Das eine ist die Umgebungsvariable GGML_Q8_TURBO3_MMA_FUSED=1, die laut den Notizen des Forks 13 % bringt und die Zeile ist, die alle vergessen. Das andere ist die Vocab-Map-Datei am Ende. Der Pfad docs/mtp-vocab/atx_65536.txt liegt im Repository des Forks, das Sie bereits geklont haben.

Warum es funktioniert

Hier stapeln sich vier eigenständige Ideen. Keine davon ist Magie, zusammen zeigen sie sorgfältige Ingenieursarbeit.

1. Ein Build, neu geschrieben für eine Chipfamilie

Das Standard-llama.cpp schreibt seine CUDA-Kernel so, dass sie auf vielen GPU-Generationen korrekt laufen. Dieser Fork geht den umgekehrten Weg: Er schreibt die Hot Paths für eine einzige Architektur neu und optimiert sie, bis nichts mehr herauszuholen ist.

Zwei Beispiele. Qwen3.8-27B ist kein reiner Transformer: 48 seiner Schichten halten statt Attention einen rekurrenten Gated-DeltaNet-Zustand. Der Fork hat diese Kernel so umgebaut, dass jeder GPU-Warp vier Zustandsspalten statt einer übernimmt, wodurch die Hardware-Pipeline besser ausgelastet ist. Das brachte etwa 5 bis 6 % bei Prefill und Decode.

Die übrigen 16 Schichten machen echte Attention. Ihre Keys werden komprimiert gespeichert, und der bisherige Dekompressionspfad nutzte nur etwa 10 % der Speicherbandbreite, als würde man durch einen dünnen Strohhalm trinken. Die Neufassung lädt Daten per asynchroner Kopie vor und korrigiert das Lesemuster, wodurch das Dekodieren bei langem Kontext bis zu 11 % schneller wird.

Unspektakulärere Korrekturen waren genauso wichtig. Zwei Fixes bei der Speicherzuweisung haben 2,8 GB VRAM freigemacht: Ein Puffer wurde doppelt angelegt, und der spekulative Drafter reservierte eigene Rechenpuffer, obwohl er die des Hauptmodells hätte mitnutzen können. Genau diese 2,8 GB entscheiden, ob 262K Kontext auf die Karte passen.

2. Eine Quantisierung, die Bits klug verteilt

Ein Quantisierungsschema legt fest, wie viele Bits jedes Gewicht bekommt. Ein naives Schema gibt jedem Tensor dasselbe Budget, etwa 4 Bit. Tensoren leiden aber unterschiedlich stark unter Rundung.

Das ATX-4-XS-Rezept entstand aus Messungen, welche Tensorrollen bei Kompression tatsächlich Schaden nehmen, etwa Attention-Projektionen und Output-Heads. Es nutzt IQ4_XS als Basisformat und hebt ausgewählte Rollen auf Q5_0, Q6_K oder Q8_0 an. Heraus kommt eine 14,5-GB-Datei, kleiner als ein Standard-Q4_K_M-Build desselben Modells, die bei jedem Durchlauf weniger Bytes aus dem Speicher zieht und für die Alltagsarbeit nah an voller Qualität bleibt.

Kleiner heißt schneller, weil die Erzeugung Token für Token an der Speicherbandbreite hängt: Für jedes Token müssen die Gewichte einmal aus dem GPU-Speicher gelesen werden. Weniger Bytes pro Token ergeben mehr Tokens pro Sekunde. Damit das nicht auf Kosten der Qualität geht, war sorgfältiges Messen nötig, welche Bits man behält.

3. Turbo3: kompaktes Kurzzeitgedächtnis

Beim Generieren hält ein Modell einen KV-Cache, also eine Aufzeichnung von allem, was es gelesen und geschrieben hat, damit jedes neue Token zurückblicken kann. Bei 262K Tokens ist dieser Cache riesig. In Standardformaten würde er den Großteil des VRAM verschlingen, bevor überhaupt die Gewichte geladen sind.

Dieser Stack, übernommen aus der TurboQuant+-Arbeit, speichert Attention-Keys in q8_0 (nahezu verlustfrei) und Values rotiert und auf etwa 3 Bit komprimiert. Daher der Name Turbo3. Die Asymmetrie ist Absicht: Keys funktionieren wie Adressen, Fehler darin legen alles falsch ab, während Values Inhalte sind, die eine Kurzschrift vertragen.

Ein fairer Vorbehalt: Das ist nicht durchgehend Q8-Treue. Für Coding, Schreiben und agentenartige Alltagsarbeit zeigt sich keine Qualitätsgrenze, aber wenn Ihr Workload bitgenaue Reproduktion bei Temperatur 0 verlangt, bleiben Sie bei Q8 auf zwei Karten.

4. MTP und die Vocab-Map: günstiges Vorausraten

Den größten Gewinn bringt spekulatives Dekodieren mit MTP (Multi-Token Prediction). Das Modell hat einen eigenen kleinen Draft-Head, der kommende Tokens vorschlägt, während das große Modell diese Vorschläge parallel prüft. In diesem Fork ist die Tiefe 3: Drei Tokens werden geraten, alle drei in einem Durchlauf geprüft, und alle richtigen Treffer bleiben erhalten.

Geändert hat sich die Prüfung. Das ältere llama.cpp akzeptierte ein Draft-Token nur, wenn es exakt der Top-Wahl des Zielmodells entsprach, was streng und verschwenderisch ist. Dieser Stack nutzt stattdessen echtes Rejection Sampling. Jeder Entwurf wird mit Wahrscheinlichkeit min(1, p/q) angenommen, wobei p die Wahrscheinlichkeit des Hauptmodells für das Token ist und q die des Drafters. Einfach gesagt: faire Würfel mit einer beweisbar identischen Endverteilung wie bei normaler Generierung, also schnellere Ausgabe bei gleicher Qualität.

Bleibt die Map-Datei. Warum braucht der Startbefehl überhaupt eine Vokabular-Map?

Qwen3.8-27B hat ein Vokabular von fast 248.000 Tokens. Jeder Draft-Schritt multipliziert den Hidden State mit einer riesigen Projektionsmatrix über alle davon, etwa 1.152 × 248.320, also rund 286 Millionen Multiply-Accumulates pro entworfenem Token. Echter Text berührt den Großteil dieses Vokabulars aber kaum. Gemessen an realer Ausgabe deckt eine Shortlist der häufigsten 65.536 Tokens 99,59 % der Vorschläge des Drafters ab.

Also stutzt die Map nur die Projektion des Drafters, das Hauptmodell wählt weiterhin aus dem gesamten Vokabular:

Full vocab draft head:    1,152 × 248,320 ≈ 286M MACs per draft token
Shortlisted (65K):        1,152 ×  65,536 ≈  75M MACs per draft token

Das sind rund 75 % weniger Arbeit in der teuersten Matrix des Drafters. Weil pro erzeugtem Token mehrfach entworfen wird, war das der größte einzelne Speedup im Release v0.2, der Sprung von etwa 65 auf etwa 75 tok/s. Ohne die Map wird jeder Rateversuch voll bezahlt.

Legt man alle vier Ebenen zusammen, neu geschriebene Kernel, klügere Bitverteilung, komprimierte Kurzschrift im Speicher und günstiges Vorausschauen, dann schlägt eine GPU von 2020 das, was Spezialhardware 2023 geboten hat. Die RTX 3090 ist nicht besser geworden. Die Community ist einfach sehr gut darin geworden, sie auszuquetschen.

Das größere Bild

Überlegen Sie, was passiert ist. Ein einzelner Ingenieur hat mit Hilfe von Frontier-Modellen in wenigen Tagen eine Consumer-GPU von 2020 dazu gebracht, ein führendes offenes Modell etwa dreimal so schnell wie der offizielle Stack auszuliefern, und dann Kernel, Quantisierung und Rezept kostenlos veröffentlicht.

So sieht lokale KI 2026 aus. Jeden Monat passt etwas, das im letzten Quartal zwei Karten brauchte, auf eine. Das verändert auch die Debatte darüber, wer KI kontrolliert. Hardware, die schon in den Wohnungen der Leute steht, kann moderne Modelle offline betreiben, ohne API-Key, ohne Abrechnung pro Token und ohne fremde Erlaubnis. Regeln, die Inferenzkosten in die Höhe treiben oder einschränken, wer Rechenleistung kaufen darf, würden genau diese Art unabhängiger Arbeit am härtesten treffen.

Was immer Sie von diesen politischen Debatten halten, die praktische Lehre ist einfach. Die Gewichte liegen auf Ihrer eigenen Platte, und die Effizienzarbeit der Open-Source-Community, geliefert als Kernel und Commits statt als Ankündigungen, senkt weiter den Preis dafür, ein eigenes Modell zu betreiben. Der Code liegt im llamAmpere-Repository, das Modell ist jakeatx/Qwen3.8-27B-ATX-IQ4_XS-M-GGUF.