Bereitstellung von Qwen3.8-Flash-Next-Uncensored-FP8: ein vLLM-Runbook für den Block-FP8-Build

Qwen3.8-Flash-Next-Uncensored-FP8 — der Block-FP8-Build des abliterierten Flash-Next — ist das Artefakt, das Sie tatsächlich herunterladen, wenn Sie dieses Modell auf Rechenzentrums-Hardware bereitstellen, und es ist das letzte in der Sammlung, das ein eigenes Runbook erhält. Es befindet sich unter orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 auf Hugging Face: die Verweigerungsrichtung wurde aus Qwens Qwen3.8-Flash-Next entfernt und dann offline auf das exakte FP8-Schema des offiziellen Qwen3.8-Flash-Next-FP8 neu quantisiert, sodass vLLM es auf dem identischen Kernel-Pfad bereitstellt. Es ist der Build, nach dem jeder greifen wird, der dieses Modell auf GPUs der Hopper-Klasse und neueren ausführt, und der Serving-Pfad hat ein Flag, das leicht falsch zu setzen ist und, wenn es falsch gesetzt ist, schwer zu diagnostizieren ist.

Zunächst die Abgrenzung, denn Leser verwischen sie immer wieder, und sie verändert alles Weitere. Qwen3.8-Flash-Next-Uncensored und Qwen3.8-27B-Uncensored sind zwei verschiedene Modelle, nicht zwei Builds ein und desselben Modells. Unterschiedliche Basisgewichte – Qwen3.8-Flash-Next gegenüber Qwen3.8-27B – unterschiedliche Architekturen, unterschiedliche Weight-Drops, unterschiedliche Hugging-Face-Sammlungen. Sie teilen eine Abliterationstechnik und einen Familiennamen; das ist alles. Keine der Zahlen einer 27B-Seite überträgt sich auf dieses Modell, und wenn du über eine 27B-Suche hierhergekommen bist, ist das eigene lokale Runbook der 27B eine separate Seite mit einem separaten Satz von Entscheidungen.

Diese Seite ist ausschließlich die Serving-Seite für Flash-Next FP8 und nichts anderes. Das GGUF/MLX-Runbook behandelt die Abliteration-Erklärung für dieses Modell und die beiden Consumer-Hardware-Build-Linien; die Technik hinter der gesamten Familie wird im Abliteration-Primer und im breiteren Erklärartikel zu unzensierten LLMs erklärt; und Qwen3.8-27B-Uncensored-FP8, das Geschwistermodell, auf das Sie vielleicht verwiesen wurden, hat ein eigenes FP8-Runbook. Hier bleibt es bei einer Frage: wie man den Block-FP8-Build bedient, was schiefgeht, wenn man es falsch macht, und was die eigenen Zahlen der Modellkarte Ihnen sagen und was nicht.

Bevor Sie beginnen: das Gate und die Laufzeit

Zwei Dinge schränken dieses Repo ein, und beide erzeugen Fehler, die wie etwas anderes aussehen.

Der erste Punkt ist der Zugriff. Das Repository ist zugangsbeschränkt: Sie müssen bei Hugging Face angemeldet sein und die Nutzungsbedingungen des Repos akzeptiert haben, bevor ein Download funktioniert. Die Modellseite selbst ist ohne Konto lesbar – der vollständige Kartenprosatext ist öffentlich –, aber die Gewichte sind es nicht. Deutlich gesagt: Ohne eine angemeldete Sitzung, die die Bedingungen akzeptiert hat, schlagen sowohl `hf download` als auch `vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8` mit einem Authentifizierungsfehler fehl, nicht mit einem freundlichen „Sie müssen auf Zustimmen klicken“. Machen Sie zuerst den einmaligen Klick-Durchgang, dann laden Sie die ~186 GB mit der hf-CLI herunter oder lassen Sie vLLM das Repo beim ersten Start auflösen.

Das Zweite ist die Runtime. Der Checkpoint wird unter der qwen4_exp-Architektur (Qwen4ExpForConditionalGeneration) registriert, die weder mit Standard-vLLM noch mit Standard-Transformers geladen werden kann. Du benötigst das Day-0-vLLM-Image und Transformers 5.16+. Dies ist der mit Abstand häufigste „Es lädt nicht“-Fehler in den Community-Runbooks dieser Woche – kein beschädigter Download, sondern eine Runtime, die vor der Architektur existierte. Das Image ist nicht optional; es ist der Weg.

Hardware, damit Sie planen können, bevor Sie etwas herausziehen: Der Aufruf der Karte zielt auf einen 8-GPU-Knoten ab, und die Anleitung des offiziellen vLLM-Rezepts für den FP8-Checkpoint gilt hier, da die Builds Tensor-für-Tensor übereinstimmen — in der Größenordnung von 265 GB GPU-VRAM für eine Bereitstellung auf einem vollständigen Knoten, wobei TP2 als Minimum auf GB300-Klasse behandelt wird und TEP4/TEP8 als die validierten Full-Tray-Konfigurationen.

Warum der FP8-Build existiert – und warum „identischer Kernel-Pfad“ der springende Punkt ist.

{{1}}Die abliterierten BF16-Gewichte sind die maßgebliche Quelle; dieses Repo ist das offline neu quantisierte Modell, das bewusst das offizielle Qwen3.8-Flash-Next-FP8-Rezept reproduziert.{{/1}} {{2}}Der Quantisierer verändert nur die 512 gerouteten Experten-Projektionen{{/2}} – {{3}}experts.{e}.down/gate/up_proj{{/3}} – {{4}}und löst sie dabei aus dem 3D-Layout des BF16-Builds heraus, wobei jede als float8_e4m3fn-Gewichte plus BF16-weight_scale_inv-Skalen in 128×128-Blöcken gespeichert wird.{{/4}} {{5}}Die Aktivierungen sind pro Token dynamisches FP8; es gibt keinen Kalibrierungsdatensatz.{{/5}} {{6}}Alles andere bleibt BF16: Attention und linear_attn, der gemeinsame Experte, der MoE-Router (mlp.gate), die Hyper-Connection-Mischer, Embeddings, lm_head, der MTP-Head für spekulatives Dekodieren und der gesamte Vision-Tower.{{/6}}

Die Aussage „identischer Kernel-Pfad“ ist mehr als nur Marketing, und sie verdient einen Satz. Der Build wurde gegen den offiziellen FP8-Checkpoint verifiziert: Die Blockskalen stimmen exakt überein (scale_relerr = 0) und die FP8-Codes entsprechen einer Rundung unterhalb des ULP. Deshalb führt vLLM es mit denselben block-skalierten FP8-Kernels und demselben MTP-Speculative-Decoding aus wie die offizielle Version — die Tensoren sind effektiv dieselben Tensoren, abzüglich der Ablehnungsrichtung.

Konkret ergibt das ~186 GB über 131 Shards (152.089 Tensoren, davon 75.264 FP8), 262.144 Token nativen Kontexts, den Vision- und Video-Turm Byte für Byte erhalten (333 visual.*-Tensoren) sowie den intakten MTP-Head. Die Gewichte wurden zuerst abliteriert – eine einzelne Refusal-Richtung, die auf Schicht 24 geschätzt und in float32 aus 149 residuenschreibenden Tensoren orthogonalisiert wurde, nach Arditi et al. (2024) – und die Residual-Writer des MTP-Heads wurden konsistent angepasst, sodass spekulatives Dekodieren weiterhin funktioniert. Dieses letzte Detail ist nicht offensichtlich, und es ist der Unterschied zwischen einem Head, der das Dekodieren beschleunigt, und einem, der es stillschweigend verschlechtert.

Das eine Flag, das über Erfolg oder Misserfolg des Ladevorgangs entscheidet.

Stellen Sie diesen Build ohne --enable-expert-parallel bereit, und Sie erhalten einen Fehler, der wie ein Formfehler aussieht, nicht wie ein Konfigurationsfehler. Dies ist der am häufigsten gemeldete Serving-Fehler für diesen Checkpoint, und er ist vollständig deterministisch.

Hier ist die Rechnung. Die fusionierte Gate+Up-Projektion der gerouteten Experten hat eine Zwischengröße von 640. Block-FP8 quantisiert in 128 breiten Blöcken. Bei einfachem Tensor-Parallelismus wird diese 640 auf die Ränge aufgeteilt — 640 ÷ TP — und für die üblichen TP-Grade (2, 4, 8) ist der Pro-Rang-Anteil nicht durch 128 teilbar: TP8 ergibt 80, TP4 ergibt 160, TP2 ergibt 320. vLLM weigert sich dann, die Gewichte zu laden, mit einem Fehler, der wie eine Formunverträglichkeit klingt: Die Ausgabegröße des Gewichts von gate und up = 80 ist nicht durch den Gewichtsquantisierungs-Block block_n = 128 teilbar.

Expert-Parallelismus behebt das Problem, indem die Expert-Gewichte über Expert-Parallel-Ränge statt über Tensor-Parallel-Ränge verteilt werden, wodurch die FP8-Blockgrenzen erhalten bleiben. Deshalb ist das Flag für diesen Build zwingend erforderlich: Mit --enable-expert-parallel wird TP8 zu einem funktionierenden TEP8. (Für den BF16-Build ist es unbedenklich, da dort keine FP8-Blöcke erhalten werden müssen.) Das offizielle vLLM-Rezept stellt klar, dass reines TP8 mit den 128 breiten Quantisierungsblöcken des Checkpoints inkompatibel ist, und ein vLLM-Issue, das zwei Tage nach der Veröffentlichung der Gewichte eingereicht wurde, dokumentiert denselben Fehler auf einem 8×L40s-Knoten bei TP2, TP4 und TP8. Wenn ein Ladevorgang mit einem formähnlichen Fehler abbricht, prüfen Sie das Flag, bevor Sie den Download prüfen.

Der genaue Befehl

Hier ist der Docker-Aufruf der Karte, getreu wiedergegeben:

docker run -d --name flashnext --gpus all --ipc host -p 8000:8000 -v /path/to/Qwen3.8-Flash-Next-Uncensored-FP8:/model vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 --model /model --served-model-name Qwen3.8-Flash-Next-Uncensored --tensor-parallel-size 8 --trust-remote-code --max-model-len 262144 --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder

Arbeiten Sie die nicht offensichtlichen Flags durch:

• vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 — das Day-0-Image von qwen4_exp. Dies ist kein generisches vLLM; es ist das architekturspezifische Image, und Standard-Images, die vor qwen4_exp veröffentlicht wurden, können den Checkpoint überhaupt nicht laden.

• --trust-remote-code — lädt den im Repo enthaltenen qwen4_exp-Modellcode. Ohne diese Option weigert sich der Loader grundsätzlich.

• --max-model-len 262144 — entspricht dem nativen Kontextfenster. Hier sollte es explizit angegeben werden, statt es einem Standardwert zu überlassen.

• --enable-expert-parallel — erforderlich für den FP8-Build, aus den im obigen Abschnitt genannten Gründen. Die Karte weist darauf hin, dass es für BF16 harmlos ist.

• --enable-auto-tool-choice --tool-call-parser qwen3_coder — aktiviert Tool- und Funktionsaufrufe im Qwen3-Coder-XML-Format. Lässt man sie weg, kann das Modell weiterhin chatten, aber die agentische Werkzeugnutzung ist deaktiviert.

• --tensor-parallel-size 8 — der Aufruf der Karte setzt einen 8-GPU-Knoten voraus (8× Hopper-Klasse). Mit --enable-expert-parallel ist das eine TEP8-Bereitstellung.

Sobald der Container läuft, ist der Endpunkt OpenAI-kompatibel unter :8000/v1. Setzen Sie --served-model-name auf das, was Ihre Clients erwarten; die Karte verwendet Qwen3.8-Flash-Next-Uncensored.

Alternativen, alle in der Modellkarte oder von Praktikern diese Woche bestätigt: vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 direkt, sobald Ihre HF-Sitzung authentifiziert ist; SGLang über das lmsysorg/sglang:qwen38flashnext-Image mit --tp 8 --ep 8 — gleiche Expert-Parallel-Anforderung, gleicher Grund; und Transformers mit pipeline("image-text-to-text", ...) auf Transformers 5.16+, wenn Sie Skripte gegen das Modell schreiben möchten, anstatt es zu bedienen.

Was wirklich funktioniert, wenn man es serviert

Die Muster in diesem Abschnitt sind Community-Erkenntnisse aus Praktiker-Runbooks und Forenthreads dieser Woche, keine Herstelleranleitung. Wo mehr als ein Setup dasselbe Verhalten berichtet, ist es wert, als real behandelt zu werden:

• Spekulative Dekodierung mit MTP funktioniert. Fügen Sie --speculative-config '{"method":"mtp","num_speculative_tokens":3}' hinzu und vLLM verwendet den beibehaltenen MTP-Head. Mehrere Runbooks führen MTP als Grund dafür an, dass die Dekodierung dieses Modells trotz seiner Größe nutzbar bleibt.

• OOM beim Laden? Lagern Sie die n-Gramm-Tabelle aus. Die 51B-Parameter-PLE-n-Gramm-Einbettung ist die Speicherüberraschung in dieser Architektur. VLLM_PLE_CPU_OFFLOAD=1 verschiebt sie in den Host-RAM — geben Sie ihr dort mindestens ~51 GB. Das offizielle Rezept und die Community-Runbooks für Multi-Node-Setups verwenden beide dieses Flag.

• Vision ist real, nicht rudimentär.Der Vision- und Video-Turm wird Byte für Byte beibehalten, sodass es ein vollwertiges Vision-Language-Modell bleibt. Übergib in einer Chat-Completion einen image_url-Inhaltsteil, und derselbe Endpunkt liefert Bildverständnis; Community-OCR-Tests bei diesem Build melden saubere Ergebnisse.

• Reasoning ist standardmäßig aktiviert – und das verändert das Sicherheitsbild. Die Chat-Template aktiviert das Denken, sofern Sie nichts anderes angeben. Schalten Sie es pro Anfrage mit chat_template_kwargs={"enable_thinking": true|false} um, und fügen Sie einen Reasoning-Parser hinzu, wenn Sie den Denktext getrennt von der Antwort haben möchten. Aufgrund dieser Standardeinstellung bedienen Sie fast immer das Modell mit aktiviertem Denken, es sei denn, Sie schalten es explizit aus.

• 262K nativ, 1M mit Rope-Override. Der native Kontext umfasst 262.144 Tokens. Um auf 1M zu kommen, braucht es einen expliziten YaRN-Rope-Scaling-Override plus eine Umgebungsvariable, die das max-model-len-Limit von vLLM anhebt – und du solltest zuerst die Qualität bei kürzeren Kontexten per Regressionstest prüfen, denn eine blinde 4×-Erweiterung ist genau der Punkt, an dem die Qualität bei langen Kontexten normalerweise abnimmt.

Was die Zahlen der Karte sagen — und was sie nicht sagen

Dies sind die eigenen Messungen des Anbieters an seiner eigenen Version, veröffentlicht in der Modellkarte und gemessen an genau diesen Gewichten, die mit vLLM gegen die offizielle Basis unter identischen Skripten und Einstellungen ausgeliefert wurden. Geben Sie sie als das wieder, was sie sind: indikativ und keine unabhängige Prüfung.

Die Kernaussage ist der Zusammenbruch der Verweigerung bei deaktiviertem Denken. In der Suite für schädliche Prompts der Karte (n von 50 bis 150 pro Benchmark) liegt die Basis-Verweigerung bei 64–100% und bei diesem Build bei 0–2.7%: AdvBench 100%→2.0%, JailbreakBench 94%→0.0%, StrongREJECT 99.3%→1.3%, HarmBench 100%→1.3%, MaliciousInstruct 98%→0.0%, SimpleSafetyTests 64%→2.0%, ForbiddenQuestions 75.3%→2.7%, und ein eigener chinesisch/englischer Test 63.6%→0.0%.

Jetzt die ehrliche Hälfte. Die Verweigerungsrate des Basismodells selbst bricht ein, wenn Denken aktiviert ist — AdvBench fällt von 100 % beim Basismodell auf 7,0 % mit aktiviertem Reasoning —, sodass der Vergleich mit aktiviertem Denken weit weniger dramatisch ausfällt: Dieser Build liegt bei 0,0 % in derselben Suite, aber er reduziert eine kleine Zahl, die das Basismodell bereits reduziert hatte. Zitiert man nur die Zahlen ohne Denken, präsentiert man die schmeichelhafte Hälfte der Geschichte, und genau diese Hälfte ist es, auf die sich eine Sicherheitsbewertung nicht stützen darf.

Überverweigerung bei harmlosen Prompts (XSTest-safe, n=250) sinkt von 9,6 % im Basismodell auf 1,2 % bei diesem Build mit deaktiviertem Denken – eine echte Verbesserung, denn ein Modell, das harmlose Prompts verweigert, ist der leisere Fehlermodus. Der Fähigkeitserhalt bei MMLU / MMLU-Pro / GSM8K / CMMLU zeigt Deltas von −2,0, −1,2, −1,3 bzw. −0,6 Punkten, konsistent mit der Behauptung, dass die Orthogonalisierung einer Richtung nahezu keine allgemeinen Fähigkeiten kostet. Tool-Calling, Vision/OCR und Reasoning werden für diesen Build alle als funktionierend gemeldet.

Zwei Einschränkungen gelten für all das oben Genannte. Die Verweigerungsmetrik stammt von einem regelbasierten Klassifikator für Eröffnungsphrasen, den die Karte selbst als indikativ bezeichnet, nicht als LLM-Judge oder publikationsreife Zahl – ein menschliches Gremium oder ein Judge-Modell wird diese exakten Zahlen nicht reproduzieren. Und die Spalte mit den Einschränkungen ist wichtig: Bei der Suite ohne Denken beginnen etwa die Hälfte bis drei Viertel der Ausgaben dieses Builds immer noch mit einem kurzen Haftungsausschluss, bevor sie nachkommen. Das Modell verweigert selten; es weicht aus. „Uncensored“ bedeutet hier, dass es antwortet, nicht dass es ohne Vorrede antwortet.

Der Sicherheitsabschnitt ist keine Formalität.

Lies das, bevor du die Gewichte ziehst, nicht danach.

Bei diesem Modell wurde die Sicherheitsausrichtung weitgehend entfernt, und der Mechanismus ist spezifisch: Eine einzelne Verweigerungsrichtung wurde im Residualstrom geschätzt und aus jeder Matrix, die in den Residualstrom schreibt — 149 an der Zahl — herausorthogonalisiert, berechnet in float32. Die Konsequenz wird offen angekündigt, sie ist kein Nebeneffekt. Das Datenblatt sagt unmissverständlich, dass das Modell schädlichen, unethischen, anstößigen oder illegalen Anfragen nachkommen wird, die das Basismodell Qwen3.8-Flash-Next ablehnen würde, und dass es keine nennenswerten eingebauten Schutzmechanismen hat. Es wird ausschließlich für legitime Forschung veröffentlicht — Interpretierbarkeit, KI-Sicherheit und Untersuchung von Verweigerungsmechanismen, Red-Teaming, Robustheitsbewertung und kontrollierte Experimente — und der Nutzer übernimmt die volle Verantwortung und Haftung für das, was es erzeugt. Apache 2.0 regelt, was Sie mit den Gewichten tun dürfen.

Zwei Dinge gilt es, genau richtig zu machen, denn dieser Build macht es leicht, sie falsch zu machen.

Zunächst einmal ist ein Jailbreak-Test, der bei diesem Modell „erfolgreich“ ist, keine bestandene Sicherheitsprüfung. Es ist das beworbene Verhalten. Wenn Ihre Bewertung behauptet: „Die Sicherheit dieses Modells wurde umgangen“, dann haben Sie das Design gemessen, keine Schwachstelle. Was tatsächlich ein Befund wäre, ist eine Verweigerung, die die Abliteration übersteht, oder eine Leistungsregression – und die Zahlen auf der Karte deuten darauf hin, dass beides selten ist.

Zweitens ist die erhaltene Angriffsfläche größer als nur Text. Der Vision-Turm ist byte-for-byte intakt und Tool-Aufrufe funktionieren, daher sind sowohl Bildeingaben als auch agentische Nutzung aktiv. Ein Red-Team-Plan, der nur Text-Prompts testet, übersieht die Modalitäten, die dieses Modell tatsächlich exponiert. Und die oben genannten Verweigerungszahlen sind ein regelbasierter Klassifikator der eigenen Änderung des Anbieters – sie sind kein unabhängiges Audit von irgendetwas, einschließlich Sicherheit.

Stellen Sie dies weder Endbenutzern bereit noch setzen Sie es in der Produktion ein, ohne eigene Ebenen für Sicherheit, Moderation und Missbrauchsprävention hinzuzufügen. Die Bedingungen des Repos sagen es klar und deutlich, und es ist keine Floskel: Die Ausgaben spiegeln nicht die Ansichten der Uploader oder von Qw​en / Ali​baba wider.

So erhalten Sie eine zensierte Basislinie für den Vergleich

Wenn sich Ihre Arbeit mit der Erforschung von Verweigerungsmechanismen oder mit Red Teaming befasst, wollen Sie mit ziemlicher Sicherheit das zensierte Gegenstück dieses Modells Seite an Seite haben — dieselbe Architektur ohne die Modifikation —, um das Delta zu messen. Dieser unzensierte Build ist bewusst rein lokal ausgelegt: Das Repository ist zugriffsbeschränkt und verfügt über kein gehostetes Inferenz-Deployment, was Absicht ist, damit sensible Nutzlasten niemals eine Drittanbieter-API durchlaufen.

Für die gehostete Baseline leitet OrcaRouter die Qw​en-Linie zum Listenpreis des Anbieters mit null Aufschlag weiter — Qwen3.8-Flash zu 0,15 $ pro Million Eingabe-Tokens und 0,47 $ pro Million Ausgabe-Tokens, unverändert durchgereicht, mit automatischem Failover und einem Schlüssel für 200+ Modelle. Eine Preisänderung des Anbieters erscheint am selben Tag. Wenn Sie abwägen, ob Sie diesen Build überhaupt ausführen sollen oder wie viel Ihres Stacks er tragen kann, ist das der kostengünstige Weg, die zensierte Version dagegenzuhalten, ohne einen zweiten Vertrag oder eine zweite Codebasis.

Hier beginnen

Entscheidungsübersicht. Sie benötigen: ein Hugging-Face-Konto mit akzeptierten Repository-Bedingungen; einen Knoten der Hopper-Klasse oder neuer – der Befehl der Karte zielt auf 8 GPUs ab und benötigt gemäß den Angaben des offiziellen Rezepts für den passenden FP8-Checkpoint in der Größenordnung von 265 GB GPU-VRAM; das Day-0-vLLM-Image und Transformers 5.16+; sowie etwa 186 GB Speicherplatz für die Gewichte.

Reihenfolge der Ausführung: Akzeptiere die Repo-Bedingungen → lade die Gewichte herunter → ziehe das Day-0-Image → starte den Server mit --enable-expert-parallel → verifiziere mit einer Anfrage an :8000/v1/chat/completions → beginne dann mit deinen Evals. Wenn ein Laden mit einem shape-artigen Fehler fehlschlägt, prüfe das Flag, bevor du den Download überprüfst.

Und behalten Sie den Rahmen. Dies ist ein Forschungsinstrument, das unter dieser Bedingung freigegeben wurde. Seine Zahlen sind die eigenen indikativen Messungen des Anbieters an seiner eigenen Bearbeitung. Sein Sicherheitsverhalten ist der Kern der Übung, kein Fehler, den es zu umgehen gilt. Servieren Sie es, messen Sie es und setzen Sie Ihre eigene Moderation zwischen es und alles Menschliche.

der Qwen3.8-Flash-Next-Uncensored-Sammlung auf Hugging Face.

Ein anderes Modell, nicht ein weiterer Build davon: Qwen3.8-27B-Uncensored ist von einer anderen Basis abliteriert und hat seine eigene Sammlung und seine eigenen Runbooks.

Diese Gewichte sind bewusst nur lokal verfügbar. Für eine gehostete Baseline, gegen die der abliterierte Build gemessen werden kann, wird Qwen3.8-Flash auf OrcaRouter zum Listenpreis des Anbieters mit 0 % Aufschlag bereitgestellt — das unveränderte Modell mit intakter Sicherheitsausrichtung.