Qwen3.8-27B wird auf einer RTX 3090 mit einem gepatchten vLLM und DFlash2 ausgeführt.
Wie ein gepinnter vLLM 0,28,0-Branch mit neu quantisierten Embeddings und DFlash2-Spekulationen ein 27-Billionen-Modell auf einer Karte mit 24 GB ausführt – und wo ein langer Kontext die Leistung verlangsamt.
Ein 27-Milliarden-Parameter-Modell auf einer einzelnen Consumer-GPU bedeutet in der Regel eine schwierige Abwägung zwischen Kontextlänge, Parallelität und Geschwindigkeit. Eine von der Community entwickelte Variante von vLLM, die für Qwen3.8-27B optimiert ist, verändert diese Situation auf einer 24 GB RTX 3090: Bei einer Agenten-basierten Arbeitslast erreicht sie etwa 177 Tokens pro Sekunde bei der Dekodierung – und zwar auf einer gewöhnlichen (nicht Ti-)Karte, die auf 300 W Leistung begrenzt ist. Dieser Leitfaden zeigt eine native, containerfreie Installation, erläutert, welche Optimierungen zu dieser Geschwindigkeit führen, und macht genau deutlich, ab wann der Ansatz nicht mehr lohnenswert ist, damit Sie entscheiden können, ob er zu Ihrer Arbeitslast passt.
Die beiden unten beschriebenen Einsatzprofile tauschen Kontextlänge gegen Parallelität und Geschwindigkeit aus. Die Werte stammen von einer Agenten-Workload auf einem einzigen Rechner, daher sollten sie als Orientierungshilfe und nicht als Garantie angesehen werden.
| Config | Context | Parallel requests | My measured decode speed |
|------------|-----------|-------------------|--------------------------|
| CTX=fast | 65,536 | 8 | ~177 tok/s |
| CTX=long | 131,072 | 4 | ~122 tok/s |
Weil der Server eine mit OpenAI kompatible API bereitstellt, besteht die Integration in ein Agenten-System wie DeepSeek Harness darin, den Client auf eine Basis-URL im Format http://<host>:18020/v1 zu richten und einen Zugriffsschlüssel bereitzustellen. Die Unteragenten können anschließend parallel Anfragen an ein lokales Modell senden, das mit Geschwindigkeiten antwortet, die zuvor Hardware in Rechenzentren erfordert hätten.
Was das qwen38-27b-rtx3090-Projekt tatsächlich ist
Das Projekt befindet sich im Repository syv-ai/qwen38-27b-rtx3090. Es handelt sich weder um ein neues Modell noch um einen neuen Inferenzmotor. Es ist eine Fork, die auf vLLM 0.28.0 basiert und mit einer Reihe von Patches, Requantisierungs-Skripten sowie Startprofilen kombiniert wurde – deren einziger Zweck darin besteht, dieses spezielle hybride Modell auf eine Karte mit 24 GB Speicher zu bringen und es schnell laufen zu lassen.
Eine Docker-Image wird bereitgestellt, und docker compose --profile single up -d ist die vollständige Installation, falls Sie mit Containern zufrieden sind. Das Repository unterstützt außerdem das Ausführen derselben Schritte manuell in einer Python-Virtualisierungsumgebung, was hier gewählt wurde. Dadurch bleiben die Logs sichtbar, es entsteht kein weiteres großes Image auf der Festplatte, und es ist einfacher zu erkennen, welche Änderungen bei jedem Schritt erfolgen.
Warum eine einzelne tok/s-Zahl wenig aussagt
Die Durchsatzleistung dieser Technologiebasis hängt stark von der Aufgabe ab. Das Erstellen von Code ist schnell, die Erstellung freier Prosa langsamer, und das Wiederholen von Texten, die bereits im Prompt enthalten sind, ist deutlich schneller (der unten stehende Abschnitt zur Suche und Erstellung erklärt den Grund). Die Projektdokumentation betont denselben Punkt: Eine Durchsatzzahl für diese Technologiebasis sagt nichts aus, es sei denn, man weiß auch, welcher Prompt sie erzeugt hat. Die Zahl von 177 Tok/s wurde mit Agentenlasten gemessen; Ihre eigenen Ergebnisse hängen weitaus stärker davon ab, wie Ihre Prompts aussehen, als vom Zufall.
Nativer Installationsweg ohne Docker
Vor dem Start sollten Sie sicherstellen, dass der Rechner über Folgendes verfügt:
- Linux oder WSL2 mit einer RTX 3090 in beliebiger Variante (wichtig sind die 24 GB VRAM)
- Einen aktuellen NVIDIA-Treiber, damit
nvidia-smiohne Fehler läuft - Python 3.12 oder neuer, einschließlich der dazugehörigen Entwicklungshäder
Ein praktischer Shortcut für die systembezogenen Voraussetzungen ist es, einen Programmier-Assistenten mit Shell-Zugriff (Claude Code, Codex, OpenCode oder ähnliche Tools) zur Installation einzusetzen. Weisen Sie ihn auf das Repository hin und bitten Sie ihn, den Stack auf Ihrer 3090 zum Laufen zu bringen. Wenn etwas fehlschlägt, liest der Assistent den Fehler und behebt ihn direkt – sei es durch die Installation von python3.12-dev oder libssl über apt, das Aktualisieren des Treibers oder den Wechsel der CUDA-Toolkits. Dadurch wird das Suchen nach fehlenden Paketen, das sonst einen Nachmittag mit Forensuchen erfordern würde, zu einem Routinevorgang. Überprüfen Sie, was der Assistent ausführt, genauso wie bei jedem Tool mit Shell-Zugriff.
Schritt 1: Das Repository klonen
Beginnen Sie damit, das Repository herunterzuladen und sich darin zu bewegen.
git clone https://github.com/syv-ai/qwen38-27b-rtx3090
cd qwen38-27b-rtx3090
Schritt 2: Erstellen Sie eine virtuelle Umgebung und installieren Sie die festgelegte vLLM-Version
Der Fork zielt speziell auf vLLM 0.28.0 ab, denn in dieser Version wurde die spekulative Dekodierung von DFlash2 in den ursprünglichen vLLM-Code integriert (als PR #52816 eingefügt). Die untenstehenden Befehle erstellen eine neue virtuelle Umgebung und installieren genau diese Version zusammen mit FlashInfer, den Download-Tools von Hugging Face, ninja für die Kernel-Kompilierung sowie pandas.
python3.12 -m venv venv
venv/bin/pip install -U pip
venv/bin/pip install vllm==0.28.0 huggingface_hub hf_transfer ninja \
flashinfer-python flashinfer-cubin==0.6.13 pandas
Zwei Punkte hier können leicht falsch verstanden werden:
- Lassen Sie nicht zu, dass pip
flashinfer-pythonauf eine andere Version verschiebt. Der Launcher setztFLASHINFER_DISABLE_VERSION_CHECK=1, und die Patches wurden ausschließlich für dieses festgelegte Versionspaar getestet.
curand.h. Wenn Ihre CUDA-Installation die curand-Header fehlt, scheitert die Kompilierung beim ersten Start, und der Server wechselt leise auf eine langsamere Alternative. Die Ausgabe bleibt korrekt, die Durchsatzrate sinkt um etwa 5%, und nichts in den Protokollen gibt dies an. Unter Ubuntu mit CUDA 13 behebt das Installieren von libcurand-dev-13-0 über apt das Problem.Der zweite Punkt ist ein gutes Beispiel für einen Fehler, den keine Gesundheitsprüfung erkennen kann. Wenn Ihre Werte um ein paar Prozent zu niedrig aussehen, überprüfen Sie zunächst diese Header.
Schritt 3: Herunterladen des Basis-Checkpoints
Der Ausgangspunkt ist der dbirks/Qwen3.8-27B-W4A16-AutoRound-Checkpoint, etwa 19,5 GB groß. Die Aktivierung des hochleistungsstarken Xet-Transfermodus beschleunigt das Herunterladen erheblich.
HF_XET_HIGH_PERFORMANCE=1 venv/bin/hf download \
dbirks/Qwen3.8-27B-W4A16-AutoRound \
--local-dir models/Qwen3.8-27B-W4A16-AutoRound
Schritt 4: Vorbereitung des Modells
Die Skripte in prepare/ ändern den Checkpoint. Sie quantisieren die Eingangs- und Ausgabematrixen erneut – öffentliche, quantisierte Checkpoints lassen diese nämlich in voller Präzision – bauen den MTP-Draft-Head um ein besser geeignetes Vokabular herum neu auf und laden anschließend die schnelle Variante sowie den 1,2 GB großen DFlash2-Draft herunter. Alles läuft auf der CPU ab und jedes Skript ist innerhalb weniger Minuten fertig.
M=models/Qwen3.8-27B-W4A16-AutoRound
venv/bin/python prepare/quant_lm_head.py $M
venv/bin/python prepare/quant_embed.py $M
venv/bin/python prepare/quant_mtp.py $M
venv/bin/python prepare/build_draft_vocab.py $M --ids prepare/draft_vocab_ids.json
venv/bin/python prepare/fetch_fast_variant.py
venv/bin/python prepare/fetch_dflash2.py
Schritt 5: Patch-Stack anwenden
Der Verzeichnis patches/ enthält etwa fünfzehn .patch-Dateien, die Themen wie die Verkabelung der Embedding-Quantisierung, Split-KV-Aufmerksamkeit für die Entwurfsüberprüfung, Korrekturen an den Marlin int8-Kernen, DFlash2-Lookup-Verarbeitung und weitere abdecken. Die Reihenfolge dieser Patches ist in patches/series definiert. Die untenstehende Schleife entfernt Kommentare sowie leere Zeilen aus dieser Datei und wendet jeden Patch auf das vLLM-Paket innerhalb des venv an. Dabei wird dflash2-backport.patch übersprungen, da dieser nur für vLLM-Versionen vor 0.28.0 vorhanden ist, in denen DFlash2 noch nicht nativ integriert war.
sed -e 's/#.*//' -e 's/^[[:space:]]*//;s/[[:space:]]*$//' -e '/^$/d' patches/series |
while IFS= read -r name; do
[ "$name" = "dflash2-backport.patch" ] && continue
patch -p1 -d venv/lib/python3.12/site-packages/vllm < "patches/$name"
done
Ein Patch, der nicht angewendet werden kann, weist fast immer auf eine Versionskonflikts hin. Führen Sie venv/bin/pip show vllm aus und überprüfen Sie, ob tatsächlich 0.28.0 angezeigt wird.
Schritt 6: Installation überprüfen
Bevor Sie irgendetwas starten, erstellen Sie einen API-Schlüssel und führen Sie das Überprüfungsskript im Offline-Modus aus. Es prüft, ob alle Patches erfolgreich angewendet wurden und das Modell die erwartete Struktur aufweist.
openssl rand -hex 24 > api_key.txt
bash verify.sh --no-server # checks all patches applied + model shape correct
Ein sauberes Ergebnis bedeutet, dass Ihre Installation bytegenau mit der von den Wartern als Referenz genutzten Konfiguration übereinstimmt. Bei selbst gehosteter Inferenz, bei der eine subtile Versionsverschiebung ständig zu Verwirrung führt, ist diese Reproduzierbarkeit außergewöhnlich wertvoll.
Schritt 7: Server starten
Sämtliche Konfigurationen erfolgen über Umgebungsvariablen. Der Standardbefehl aktiviert DFlash2-Spekulation sowie Präfix-Caching auf der ausgewählten GPU; die Anmerkung zeigt, wie man auf das Profil für lange Kontexte oder auf ein 245k-Profil wechselt, nachdem kvarn/install.sh ausgeführt wurde.
CUDA_VISIBLE_DEVICES=0 SPEC=dflash2 PREFIX_CACHE=1 bash single-user/start_qwen.sh
# add CTX=long for ~131k context (4 slots), or CTX=huge after kvarn/install.sh for 245k
Setzen Sie CUDA_VISIBLE_DEVICES immer explizit. Andernfalls neigt vLLM dazu, die GPU mit dem meisten freien Speicher auszuwählen, was auf einem Mehr-GPU-System nicht unbedingt die gewünschte Karte sein kann. Der Träger-Schlüssel wird aus api_key.txt oder VLLM_API_KEY gelesen; setzen Sie ihn ein, bevor Sie den Port für etwas anderes als localhost freigeben, denn ohne Schlüssel akzeptiert der Server unauthentifizierte Anfragen. Die übrigen Einstellungen stammen aus .env. Ein paar Minuten nach dem Start haben Sie einen mit OpenAI kompatiblen Endpunkt, der ein 27B-Modell von einer einzigen Karte bereitstellt – eine Karte, die weniger kostet als ein gebrauchtes Fahrrad.
Woher die Geschwindigkeit kommt
Das Ausführen von stock vLLM mit kommerziell erhältlichen, quantisierten Checkpoints verschwendet Leistung an mehreren weniger offensichtlichen Stellen. Die Optimierungsdokumentation des Projekts (docs/optimizations.md im Repository) beschreibt neun Änderungen. Vier davon tragen zum größten Teil zum Leistungszuwachs bei.
Die Quantisierung der Embeddings, die alle überspringen
Qwen3.8-27B verwendet untied Embeddings, was bedeutet, dass es separate Eingangs- und Ausgabentabellen gibt, die jeweils etwa 2,5 GB groß sind. Öffentliche „quantisierte“ Checkpoints behalten beide in bf16 bei, hauptsächlich weil ihre Quantisierung umständlich ist. Die Vorbereitungsskripte konvertieren beide in int8, wodurch 2,6 GB VRAM eingespart werden können, ohne dass eine messbare Qualitätsminderung auftritt. Auf einer Karte mit 24 GB reicht das in etwa aus, um den Kontext eines weiteren Benutzers zu speichern.
Ausnutzung der hybriden Architektur
Nur 16 der 64 Schichten des Modells sind herkömmliche Attention-Schichten, deren Speicher mit dem Kontext wächst. Die verbleibenden 48 sind Gated DeltaNet-Schichten, ein linear-Attention-Design, dessen Zustand pro Konversation eine feste Größe hat – unabhängig davon, ob die Konversation 100 oder 100.000 Token lang ist. Stock vLLM speicherte diesen Zustand im fp32-Format, was etwa 150 MB pro Anfrage bedeutete, und konnte trotz einer konfigurierten Obergrenze von 64 nicht mehr als 37 gleichzeitige Anfragen verarbeiten. Die Fork speichert ihn im fp16-Format, die Perplexität bleibt bis auf drei Nachkommastellen unverändert, und alle konfigurierten Slots werden nutzbar.
DFlash2: Sieben Token in einem Durchlauf erstellen
Diese Änderung ist insbesondere für die Latenz bei einzelnen Anfragen von Bedeutung. Die spekulative Dekodierung kombiniert ein kleines Entwurfsmodell mit dem großen Zielmodell. Das Entwurfsmodell schlägt mehrere zukünftige Token vor, und das Zielmodell überprüft sie alle in einem einzigen Vorwärtslauf, behält das korrekte Präfix bei und regeneriert ab dem ersten Fehler. Die Überprüfung ist auf einer an Speicher gebundenen GPU viel günstiger als die Generierung, da die Gewichte nur einmal für mehrere Token gelesen werden, sodass jeder Schritt mehr als ein Token liefern kann.
Qwens integrierter MTP-Modul verknüpft vier Schätzungen nacheinander. Der Fork ersetzt dieses Modul durch DFlash2, einen fünfschichtigen Entwurfsmechanismus, der in einem einzigen, nicht-autoregressiven Durchlauf einen gesamten Block von sieben Token vorhersagt, wobei versteckte Zustände aus fünf verschiedenen Tiefen des Zielmodells verwendet werden. Der Entwurfsmechanismus selbst wurde von GPTQ auf 1,19 GB von ursprünglich 3,85 GB quantisiert, sodass er die gleiche Grafikkarte nutzen kann, ohne stark um den Speicherbandbreitenbedarf zu konkurrieren. Das Ergebnis sind etwa drei Token pro Schritt anstelle von einem. Da die standardmäßige spekulative Dekodierung Entwurfs-Token entweder annimmt oder ablehnt, damit die endgültige Ausgabeverteilung ausschließlich dem Zielmodell entspricht, ist die Geschwindigkeitssteigerung verlustfrei; die Genauigkeit von GSM8K bleibt in allen vom Repository gemeldeten Konfigurationen bei 96 bis 96,5 %.
Ein Entwurfsvokabular, das aus den eigenen Ausgaben des Modells erstellt wird
Der Ersteller kann nur solche Token vorschlagen, die im reduzierten Ausgabewortschatz vorhanden sind; alles Außerhalb davon wird per Definition abgelehnt. Der ursprüngliche Wortschatz wurde aus Webtexten abgeleitet und umfasste 92 % der Token, die das Modell tatsächlich erzeugt. Die Wartungsteams sammelten 5,4 Millionen Token aus den eigenen Ausgaben des Modells und erstellten auf dieser Grundlage einen neuen Wortschatz, wodurch eine Abdeckung von 97,5 % erreicht wurde. Allein diese Änderung führte zu einer Steigerung der Leistung um etwa 10 %, ohne dass neue Hardware oder Änderungen am Modell erforderlich waren.
Auskunftssuche für Texte, die das Modell zitiert
Eine weitere Technik erklärt die extremsten Werte. Wenn die Ausgabe Material wiederholt, das bereits im Prompt enthalten ist – wie beispielsweise Quellcode, der bearbeitet wird, oder ein eingefügtes Dokument – umgeht die Fork den Ersteller und schlägt direkt aus dem Kontext Token vor. Die Wiedergabe eines 25k-Token-Dokuments erreicht auf der Referenzhardware 381 Tok/s. Code-Agenten verbringen einen großen Teil ihrer Zeit damit, Code wiederzugeben, der kurz zuvor im Prompt erschienen ist – der ideale Fall für diese Technik – und das ist einer der Gründe, warum die Messwerte bei der Nutzung solcher Agenten so hoch ausfallen.
Warum das Verdoppeln des Kontexts nicht zu einem VRAM-Mangel führt
Der Einzelpользоватler-Launcher verwendet standardmäßig einen Kontext von 65k. Durch den Wechsel auf CTX=long verdoppelt sich dieser Wert auf etwa 131k, und man könnte annehmen, dass es bei einer Karte mit 24 GB Speicher zu einem Speichermangel kommen würde. Tatsächlich startet der Server jedoch normal und läuft nur etwas langsamer. Mehrere Designentscheidungen erklären dieses Verhalten.
- Die Gewichte haben eine feste Speichernutzung. Bei der W4A16-Quantisierung nimmt der Modellkörper unabhängig von der Länge des Kontexts etwa 15 GB ein.
- Der KV-Pool wird einmal in Bytes reserviert. Bevor Verkehr bedient wird, reserviert der Fork einen festen Speicherbedarf – hier etwa 5,2 GiB – und vLLM protokolliert das Ergebnis, beispielsweise „GPU KV-Cache-Größe: 136.429 Tokens.“ Da der Pool beim Start zugewiesen wird, passt er entweder sofort hinein oder der Server weigert sich zu starten. Es gibt keine pro Anfrage erfolgende Zuweisung, die mitten in einer Agentenaufgabe fehlschlagen könnte.
CTX=long sie im int8-Format speichert, wodurch die Kosten pro Token etwa halbiert werden. Damit können mit denselben 5,2 GiB nun 136.429 Token statt 68.605 gespeichert werden, wodurch die maximale Kontextlänge auf 131.000 steigt. Die durch den Lehrer erzwungene Perplexität bei derselben Passage unterscheidet sich zwischen den beiden Profilen nur um 0,2 %.Warum die Obergrenze 131.072 und nicht 136.429 beträgt
Nicht der gesamte Puffer kann in den Cache für die Verarbeitung einer Anfrage gehen. Jede laufende Anfrage benötigt außerdem ihren fest definierten DeltaNet-Zustand, und DFlash2 fügt daraufhin pro Anfrage acht zusätzliche Spekulationszustände hinzu. Da im langen Profil nur vier Plätze verfügbar sind, setzt der Launcher die maximale Anzahl an Kontexten auf 131.072 – das sind etwa 4 % unter der Kapazität des Puffers – wodurch der Rest für diese Zustandsseiten sowie für die Blockausrichtung reserviert bleibt. Genau dieser Puffer ermöglicht das Versprechen, keinen Out-of-Memory-Fehler zu erleben: Beim Start wird der anspruchsvollste Fall überprüft, nämlich eine einzige Anfrage mit maximaler Länge, während alle verbleibenden Plätze ebenfalls in Gebrauch sind.
Was Sie stattdessen opfern
Ein längerer Kontext wird durch höhere Geschwindigkeit, nicht durch mehr Abstürze, erkauft. Tokens werden im int8-Format gespeichert, und jeder laufende Anfrage wird nun ein Pool an Zustandsseiten zugewiesen, der sich auf weniger Plätze verteilt. Die Anzahl der parallelen Slots sinkt von 8 auf 4, und die Dekodiergeschwindigkeit geht von etwa 177 auf etwa 122 Tok/s zurück. Die Karte leistet mehr mit denselben Bytes und berechnet dafür die Gebühr anhand der Durchsatzrate statt anhand der Anzahl der Ausnahmen.
Wo sie nachlässt: tiefer Kontext für einzelne Anfragen
Der Stack funktioniert am besten bei kurzen und mittellangen Kontexten, was auch das meiste, was die Agenten senden, ausmacht. Eine einzelne Anfrage mit etwa 100.000 Tokens verhält sich anders. Bei einem Gerät mit 3090 wurde eine einzelne Anfrage bei kurzen Prompts auf etwa 107 Tok/S decodiert, bei rund 10.000 Tokens auf etwa 78 Tok/S und bei rund 43.000 Tokens auf 38 Tok/S; nahe 100.000 Tokens sank die Geschwindigkeit auf etwa 31 Tok/S. Der Grund dafür ist die Akzeptanzrate des Modells, die mit der Kontexttiefe abnimmt. Auch das Repository weist denselben Effekt auf – die Akzeptanzrate liegt unabhängig vom Cache-Typ bei etwa 0,29 – wodurch klar wird, dass es sich um eine Eigenschaft des Modells und der Kontexttiefe handelt und nicht um einen ungelösten Fehler.
Zum Vergleich erreicht eine auf llama.cpp basierende Variante derselben Kartenklasse bei 150k Context eine konstante Geschwindigkeit von 65 bis 80 Tok/s. Sie verfügt weder über einen Drafter, dessen Schätzungen mit der Zeit schlechter werden, noch über einen Verifizierungsblock, der die Auszahlungen stoppt; daher ist sie weder besonders schnell noch besonders langsam. Die untenstehende Tabelle zeigt beide Optionen nebeneinander – beachten Sie, dass der Kurz-Context-Bereich von vLLM eine Werte für einzelne Anfragen mit Messwerten für mehrere Slots kombiniert.
| Context depth | vLLM fork (DFlash2) | llama.cpp ATX fork |
|-----------------|---------------------|--------------------|
| short (<4k) | 107–177 tok/s | 65–80 tok/s |
| ~10k | ~78 tok/s | 65–80 tok/s |
| ~43k | ~38 tok/s | 65–80 tok/s |
| ~100k | ~31 tok/s | 65–80 tok/s |
Die praktische Empfehlung folgt direkt daraus. Wenn Ihre Arbeit hauptsächlich durch das langsame Lesen eines sehr langen Dokuments geprägt ist, ist llama.cpp die zuverlässigere Wahl; informieren Sie sich in unserem Leitfaden zu der Bereitstellung eines Qwen3.8 MoE-Modells auf RTX 3090s mit llama.cpp Tensor Offloading über die Vor- und Nachteile. Wenn Ihre Arbeit aus vielen mittellangen Programmiergesprächen besteht, liegt die vLLM-Variante deutlich vorn.
Warum dies für Agent-Harnesses geeignet ist
Harnesses wie Pi, Hermes oder DeepSeek Harness führen keine einzelne Konversation durch. Mit Subagenten erzeugen sie gleichzeitig viele parallele Verarbeitungsschritte – in der Regel fünf bis zwölf –, wobei jeder Schritt eine mittlere Länge hat und die meisten denselben Systemprompt sowie denselben Codebase-Kontext wiederverwenden. Genau für diese Belastung wurde diese Variante optimiert:
- Die Gesamtleistung skaliert mit der Konkurrenzfähigkeit. Vier gleichzeitige Verarbeitungsschritte erbrachten auf einer einzigen 3090-Karte insgesamt mehr als 300 Tok/s. Die Referenzbenchmarks des Repositoriums zeigen 279 bis 335 Tok/s bei vier gleichzeitigen Anfragen sowie bis zu etwa 400 Tok/s insgesamt bei acht Anfragen unter Verwendung von MTP.
PREFIX_CACHE=1 wurden 64 Anfragen, die einen 5,8k-Token-systemischen Prompt teilen, in 17 Sekunden abgewickelt anstelle von 222 Sekunden im Benchmark des Repositoriums, wobei die mittlere Latenz von 95 s auf 8 s sank. Nach der ersten Anfrage zahlen Subagenten fast nichts für gemeinsame Anweisungen. Im Rahmen dieses hybriden Modells speichert der Cache außerdem den wiederkehrenden DeltaNet-Zustand, nicht nur die Attention-KV-Daten – weshalb eine weitere Verarbeitung eines 24k-Token-dicken Dokuments etwa 1 Sekunde statt 23 Sekunden dauert.Es gibt eine Obergrenze. Ab etwa vier residenten Langkontext-Streams wird man durch die Aufteilung des Pools eingeschränkt, nicht durch die Rechenleistung. In der Dokumentation heißt es ausdrücklich, dass acht gleichzeitige Langkontext-Anfragen deutlich schlechter abschneiden als vier, wobei dies als „kein Kompromiss, sondern ein Verlust“ beschrieben wird. Die beste Leistung der Karte erzielt man, wenn man etwa vier parallele Prozesse bei mittlerer Tiefe verwendet. Ein Beispiel dafür, was eine lokale Qwen3.8-27B-Einrichtung in der Praxis erreichen kann, finden Sie unter der Anleitung zur Erstellung einer lokalen Spielkopie mit Qwen3.8-27B und Pi.
Haupterkenntnisse
- Die Geschwindigkeit stammt vom Software-Design: requantisierte Embeddings, fp16 DeltaNet-Zustände, ein sieben-Token-DFlash2-Generator sowie ein Wortschatz, der auf die tatsächlichen Ausgaben des Modells abgestimmt ist. Die GPU bleibt unverändert.
verify.sh aus, bevor Sie einem Benchmark vertrauen.Für weitere Details enthält das Verzeichnis docs/reproductions des Repositoriums Anleitungen, wie man den nicht-Docker-Pfad Schritt für Schritt auf einer 3090 nachbilden kann.