Qwen3.8-Flash-Next-Uncensored-NVFP4: Ein Serving-Runbook für Blackwell

Qwen3.8-Flash-Next-Uncensored-NVFP4 läuft auf genau einer GPU-Familie: Blackwell. NVFP4 wird auf Hardware-FP4-Tensor-Kernen ausgeführt, und Hopper (H100/H200) sowie alles Ältere haben diese schlichtweg nicht. Wenn Sie auf Hopper sind, hören Sie hier auf — der Qwen3.8-Flash-Next-Uncensored-FP8 Build ist genau der richtige. Alles Folgende setzt Blackwell (B100, B200, GB200 oder eine RTX-50-Serie-Karte), einen aktuellen vLLM-Build mit qwen4_exp-Unterstützung und transformers ≥ 5.16 voraus.

Das ist die NVFP4-Quantisierung des abliterierten (Refusal-entfernten) Builds von Qw​ens Qw​en/Qwen3.8-Flash-Next, reduziert von 330 GB in BF16 auf 178 GB auf der Platte. OrcaRouter hat es am 27. August 2026 als orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 auf Hugging Face veröffentlicht. Das Repo ist gated: du musst bei Hugging Face eingeloggt sein und die Bedingungen des Repos akzeptiert haben, oder hf download und vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 schlagen beide mit einem Authentifizierungsfehler fehl, bevor auch nur ein Byte übertragen wird. Diese Seite ist ein Serving-Runbook, keine Launch-Berichterstattung — der Build ist zwei Tage alt, und die Fragen, auf die die Leute tatsächlich stoßen, sind Hardware, Flags und welchen Build man wählen sollte.

Und bevor die Zahlen beginnen: Qwen3.8-Flash-Next-Uncensored ist nicht Qwen3.8-27B-Uncensored. Sie sind zwei verschiedene Modelle, die sich einen Familiennamen und eine Abliterationstechnik teilen — unterschiedliche Basisgewichte, unterschiedliche Architekturen, unterschiedliche Sammlungen auf Hugging Face. Flash-Next ist abliteriert von Qw​en/Qwen3.8-Flash-Next, einer gerouteten Mixture-of-Experts-Vorschau der Qwen4-Architektur (qwen4_exp): 512 Experten mit zehn gerouteten plus einem gemeinsamen aktiven Experten, Hybrid Attention (Gated-DeltaNet-Linearschichten neben Full-Attention-Schichten), Hyper-Connections, eine PLE-n-Gramm-Einbettung, einen nativen Vision- und Video-Turm und einen MTP-Kopf zum spekulativen Dekodieren. Die 27B ist abliteriert von Qw​en/Qwen3.8-27B, einer völlig anderen dichten Basis. Nichts von den Serving-Zahlen einer 27B-Seite überträgt sich auf dieses Modell; wo eine 27B-Seite wirklich nützlich ist — die Abliterations-Einführung, die allgemeine Quant-Auswahl-Mathematik — ist sie unten verlinkt mit dem, was übernommen wird und was nicht.

Was dieser Build ist, Präzision um Präzision

Qwen3.8-Flash-Next ist ein geroutetes MoE-Modell: Jeder Token aktiviert 10 von 512 Experten plus einen gemeinsamen Experten, und pro Token sind nur wenige Milliarden Parameter aktiv, obwohl das gespeicherte Modell weitaus größer ist. Der NVFP4-Build ist eine Mixed-Precision-Quantisierung mit komprimierten Tensoren dieses Stacks, und die Aufteilung ist die ganze Geschichte:

• MoE-Expertengewichte — NVFP4 (4-Bit, NVIDIA FP4 E2M1, group-16 mit FP8-Block-Skalen).

• Attention (self_attn.{q,k,v,o}), die linear_attn-Projektionen, der gemeinsame Experte und lm_head — FP8 (8-Bit).

PLE-n-Gramm-Einbettung, Token- und Vision-Einbettungen, Hyper-Connections, der QSA-Indexierer, Gated-DeltaNet conv/dt, alle Normalisierungen und der gesamte Vision-Turm — BF16, in voller Präzision belassen.

Drei Eigenschaften der Konvertierung sind wichtiger als die Präzisionsaufteilung selbst. Erstens ist sie rein gewichtsbasiert: Aktivierungen werden zur Laufzeit dynamisch quantisiert, es gibt keine statische Kalibrierung, und die Gewichte werden direkt aus dem BF16-Checkpoint abgeleitet (die Karte bezeichnet die Ableitung als datenfrei). Zweitens ist die Abliteration-Änderung in den Gewichten fest eingebacken, sodass die Entfernung der Verweigerung die Quantisierung übersteht – eine 4-Bit-Konvertierung ist eine Präzisionsänderung, kein Sicherheitseingriff. Drittens wird der KV-Cache nicht quantisiert; er bleibt zur Laufzeit im BF16-Format. Dieser letzte Punkt ist leicht zu übersehen und wird bei einem nativen Kontext von 262.144 Token des Modells wichtig, wo der KV-Cache neben den Gewichten einen echten Speicherposten darstellt.

Die On-Disk-Größe wird von einem einzigen Tensor dominiert. {{1}}Die Karte beschreibt das PLE-n-Gramm-Embedding als {{2}}einen einzelnen ~66B-Parameter-Tensor, der designbedingt in BF16 gehalten wird{{/2}}; {{3}}er ist das größte Shard und der Grund, warum der Build 178 GB statt einer schlankeren Zahl beträgt{{/3}}.{{/1}} Eine Diskrepanz, die man hervorheben und nicht beschönigen sollte: {{4}}die FP8-Schwesterkarte bezeichnet dieselbe Tabelle als das PLE-n-Gramm mit 51B Parametern{{/4}}, und {{5}}die W4A4-Anmerkung dieser Karte gibt sie mit ~100 GB an{{/5}}. {{6}}Die beiden Karten nennen unterschiedliche Zahlen für dieselbe Tabelle{{/6}}, also {{7}}behandle jede Angabe als die ihrer jeweiligen Karte{{/7}} — und {{8}}geh bei der Dimensionierung einer Bereitstellung davon aus, dass die Tabelle in BF16 groß ist, und plane entsprechend{{/8}}.

Die Hardware-Voraussetzung, ausformuliert

Dies ist der kürzeste und wichtigste Abschnitt der Seite. NVFP4 ist ein Blackwell-Format: Der schnelle Pfad ist ein natives FP4-GEMM auf den Tensor-Cores der fünften Generation, und ohne diese Hardware kann das Format auf nichts laufen. Die eigene Anforderungszeile der Karte ist explizit — eine Blackwell-GPU (B100 / B200 / GB200 / RTX-50-Serie), da NVFP4 die hardwarebasierten FP4-Tensor-Cores nutzt und nicht auf Hopper (H100/H200) oder älteren Architekturen läuft, denen die FP4-Rechenfähigkeit fehlt.

Die Weiterleitungen, an einem Ort:

• Auf Hopper (H100/H200) — stattdessen Qwen3.8-Flash-Next-Uncensored-FP8 ausliefern. Es sind dieselben Gewichte in 8-Bit, es läuft auf Hopper und Blackwell, und es ist der Build, den das FP8-Runbook dieses Blogs abdeckt.

• Auf einer Consumer-NVIDIA-GPU oder einem CPU-Rechner ist der GGUF-Build mit seinen 13 llama.cpp-Quants der lokale Weg.

• Auf Apple Silicon — der MLX-Build in 4/6/8-Bit-Stufen ist der native Metal-Pfad.

Die Laufzeitanforderung ist ebenso bindend wie das Silizium. qwen4_exp ist eine brandneue Architektur, daher verweigern Standard-vLLM-Builds, die vor dieser Architektur veröffentlicht wurden, das Laden des Checkpoints. Sie benötigen ein aktuelles vLLM mit qwen4_exp-Unterstützung sowie den compressed-tensors NVFP4-Reader (das Format wird aus config.json erkannt, nicht manuell ausgewählt) und transformers ≥ 5.16. Multimodale Eingaben erfordern außerdem den Qw​en-Vision-Stack der Laufzeit; reine Textbereitstellung funktioniert ohne diesen.

Der serve-Befehl der Karte, Flag für Flag

{{1}}Der eigene Aufruf der Modellkarte ist ein guter Ausgangspunkt{{/1}}, und es lohnt sich zu verstehen, wofür jedes Flag gedacht ist, anstatt es blind zu kopieren:

vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 --tensor-parallel-size 4 --trust-remote-code --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder

• --tensor-parallel-size 4 — die Gewichte belegen etwa 178 GB auf der Festplatte, daher verteilt die Karte sie auf vier GPUs. Dies ist die Form, für die der Build ausgelegt ist; betrachten Sie es nicht als Vorschlag.

• --trust-remote-code — erforderlich für eine benutzerdefinierte Architektur. Der Modellcode von qwen4_exp ist noch nicht im Standard-Transformers-Registry enthalten, daher lädt vLLM den Architekturcode aus dem Repo. Du vertraust diesem Code, was eine normale, aber echte Entscheidung für eine brandneue Architektur ist.

• --enable-expert-parallel — verteilt die Experten über die Tensor-Parallel-Ränge, anstatt sie zu replizieren; genau das macht eine MoE mit 512 Experten bei TP4 handhabbar. Die FP8-Schwesterkarte gibt den präziseren Grund für diesen Build an: ohne sie ist die Zwischenbreite der MoE geteilt durch TP nicht durch die FP8-Blockgröße teilbar. Behandeln Sie es als erforderlich, nicht optional.

• --enable-auto-tool-choice und --tool-call-parser qwen3_coder — zusammen aktivieren sie das Aufrufen von Funktionen. Das Auto-Flag ermöglicht dem Modell zu entscheiden, ob es ein Tool aufrufen soll, und der qwen3_coder-Parser dekodiert dessen Tool-Call-Format, dieselbe Parser-Familie, die Qwen3.8-27B und Qwen3.8-Flash-Next verwenden.

Sobald er läuft, bietet der OpenAI-kompatible Endpunkt unter /v1/chat/completions den vollständigen Funktionsumfang über den Qwen4-Stack der Laufzeit: Tool-Aufrufe wie oben, Reasoning über chat_template_kwargs.enable_thinking und Vision über image_url-Inhaltsteile. Für multimodale Eingaben benötigen Sie keinen separaten Server; es ist derselbe Endpunkt.

Eine strukturelle Anmerkung von der Karte: Es gibt keine vollständig statische W4A4-Variante dieses Builds, und eine solche wird es nicht billig geben. Eine statische W4A4-Konvertierung erfordert einen Vorwärtsdurchlauf zur Aktivierungskalibrierung, und dieser Durchlauf muss die ~100 GB große n-Gramm-Einbettung auf einer einzigen GPU halten. Das ist derselbe Grund, aus dem die PLE-Tabelle die Dateiliste dominiert, und es ist der Grund, warum dieser Build weight-only mit dynamischen Aktivierungen bleibt.

Community-Feldberichte – wie es tatsächlich aussieht, das zu servieren.

Für dieses exakte Repository werden keine Durchsatz- oder Latenzzahlen veröffentlicht, und diese Seite wird sie auch nicht erfinden. Was es gibt, ist eine wachsende Sammlung von Feldberichten von Praktikern, die die Basis-Qwen3.8-Flash-Next-NVFP4-Builds betreiben – dieselbe Architektur, dieselbe NVFP4/FP8/BF16-Präzisionsaufteilung, ohne die Abliteration-Änderung – und das Serving-Verhalten überträgt sich direkt. Das sind Community-Erkenntnisse, keine Herstellerangaben, und die Personen, die sie gemeldet haben, waren auf Blackwell-Hardware mit demselben Quantisierungsschema.

• MTP-spekulative Dekodierung ist der mit Abstand größte Leistungshebel. Das Modell wird mit einem Multi-Token-Prädiktions-Draft-Head ausgeliefert, und auf einer RTX PRO 6000 (96 GB, SM120) belegt das auf NVFP4 quantisierte MTP-Modul etwa 0,51 GB VRAM — der Bericht maß eine Akzeptanzlänge von 2,3–3,9 bei einem Maximum von 4 und eine Akzeptanzrate von 0,86–0,96. Derselbe Bericht maß eine mediane Single-Stream-Dekodierung von 180–226 tok/s (216,9 bei Codierung, 225,8 bei einer Agent-Tool-Call-Workload, 136,6 bei Reasoning) gegenüber einer Basislinie von etwa 105 tok/s und beantwortete einen Prompt mit 216.685 Tokens in 8,4 Sekunden. Behandeln Sie die Zahlen als die Werte eines einzelnen Systems, nicht als Spezifikation.

• Lagern Sie das PLE-n-gram-Embedding in den Host-RAM aus.Da die Tabelle riesig ist und selten den Durchsatz-Engpass darstellt, binden Community-Rezepte auf einzelnen Blackwell-Karten sie an den Host (~50 GiB freies Host-RAM im RTX-PRO-6000-Bericht) und mappen sie von der NVMe, wobei sie ein wenig Latenz in Kauf nehmen, um das Modell überhaupt unterzubringen. Rechnen Sie damit, so etwas zu tun, es sei denn, Sie haben ein sehr großes VRAM-Budget.

• Legen Sie das Kontextfenster explizit fest. Mit aktivem BF16-KV-Cache und MTP blähte sich ein automatisch dimensionierter KV-Pool über das hinaus auf, was die Karte halten konnte, und führte bei langem Prefill zu einem OOM; das Festlegen von max-model-len / max-total-tokens auf 262144 schaffte wieder Spielraum. Bei 262K Kontext ist der KV-Cache ein Posten, den man einplant, kein Standard.

• Ein FlashInfer-Autotune-Fehler beschädigt die Ausgabe stillschweigend. Der wichtigste Fehlermodus in der Praxis: Autotune wählt die Taktiken für den Fused-MoE-Kernel nur nach Latenz aus und prüft nie die Numerik, sodass bei bestimmten Formen das Decoding zu einem wiederholten Token kollabiert. Der Bericht der RTX PRO 6000 reproduzierte es mit 36 von 36 korrupten Generationen bei aktiviertem Autotune und 0 von 36 bei deaktiviertem – der Workaround besteht darin, das FlashInfer-Autotune zu deaktivieren (in vLLM: --no-enable-flashinfer-autotune; in SGLang: --disable-flashinfer-autotune). Wenn Ihre bereitgestellte Ausgabe plötzlich degeneriert, überprüfen Sie dies, bevor Sie etwas anderes anfassen.

• DGX Spark (GB10, SM121) benötigt eigene Patches. Die NVFP4-Gewichte (~126 GiB im Community-Build) passen nicht in einen einzelnen 128-GB-Spark, daher laufen die SGLang-Rezepte mit Tensor-Parallelismus 2 über zwei Knoten über RoCE, und der QSA-Sparse-Decode-Resolver macht den schnellen FlashInfer-Kernel von einer is_sm100_supported()-Prüfung abhängig, die auf SM121 fehlschlägt, und fällt dann auf einen Pfad zurück, der im Warmup abstürzt — der Fix ist ein kleiner Patch plus PLE-Offload. Erwarte ~47–50 tok/s Decode, mit Spitzenwerten nahe 70 bei MTP4 und CUDA-Graphen, und überprüfe, dass dein Kernel tatsächlich auf SM121 läuft, bevor du einen Benchmark versprichst.

Reasoning, Tool-Aufruf und Vision über den Qwen4-Stack

Der Community-Konsens zur Qwen3.8-Generation gilt auch für dieses Modell, mit dem üblichen Vorbehalt, dass es sich um Feldpraxis und nicht um Herstellervorgaben handelt.

• reasoning_effort ist der entscheidende Regler.Die Chat-Vorlage verwendet standardmäßig xhigh, wodurch das Modell bei jeder Anfrage ausführlich nachdenkt. Agent-Loop-Betreiber setzen standardmäßig medium und reduzieren auf low für latenzempfindliche Aufrufe; enable_thinking false deaktiviert das Denken vollständig, wenn Sie es nicht benötigen. Auf einer einzelnen Blackwell-Karte führt das Belassen von xhigh für Routineaufrufe dazu, dass ein schnelles Modell langsame Antworten erzeugt.

• Sampler mit Denkmodus kombinieren. Praktiker einigen sich auf Temperatur 1.0 / top-p 0.95, wenn der Denkmodus aktiviert ist, und auf Temperatur 0.7 / top-p 0.80 mit einer Presence-Strafe von etwa 1.5, wenn er deaktiviert ist. Die Vermischung der beiden Parametersätze verschlechtert die Ausgabequalität.

• Tool-Calling übersteht sowohl die Abliteration als auch die 4-Bit-Konvertierung. Der Funktionsaufruf-Pfad ist intakt – genau diesen verdrahten der qwen3_coder-Parser und die Auto-Tool-Choice-Flags. Für ein Red Team ist das eine zweischneidige Tatsache, denn es bedeutet, dass agentischer Missbrauch auf einem nicht ausgerichteten Modell voll funktionsfähig ist — weiter unten behandelt.

• Vision bleibt erhalten, und das vergrößert die Angriffsfläche. Der Vision-Tower wurde von der Abliteration nie berührt und bleibt in BF16, sodass Bildeingaben über image_url-Inhaltsteile funktionieren. Praktiker, die die unzensierte Modellreihe evaluieren, behandeln den multimodalen Pfad als erstklassiges Evaluierungsziel: Eine in einem Bild transportierte Prompt-Injection trifft auf ein Modell, das kein Verweigerungsverhalten aufweist.

Welchen Build solltest du bereitstellen?

Die Flash-Next-Sammlung umfasst fünf Builds — BF16, GGUF, MLX, FP8 und dieses NVFP4-Modell — und die ehrliche Auswahllogik dreht sich um Hardware und Abwägungen, nicht um eine Rangliste.

• NVFP4 (dieser Build, ~178 GB auf der Festplatte) — die Blackwell-Wahl. FP4-Tensor-Kerne, 4-Bit-Experten, der neueste Build in der Sammlung und der kleinste seiner vLLM-Server-Builds – und der, um den es auf dieser Seite geht.

• FP8 (~186 GB auf dem Datenträger) — die Wahl für Hopper und gleichermaßen geeignet für Blackwell. Dieselben Gewichte bei 8-Bit, also der breiter verifizierte vLLM-Pfad und derjenige mit der klareren Expert-Parallel-Anforderung.

• GGUF (13 Quants, IQ2_XXS ~52 GB bis Q5_K_M ~125 GB) — die llama.cpp-Empfehlung für Consumer-NVIDIA-, AMD- oder CPU-Rechner. Kein Blackwell nötig, kein vLLM nötig.

• MLX (4/6/8-Bit-Stufen, etwa 163–221 GB) — die Apple-Silicon-Empfehlung, nativ Metal, MTP-Kopf enthalten.

Zwei ehrliche Anmerkungen, bevor du dich entscheidest. Erstens: Die NVFP4- und FP8-Builds unterscheiden sich auf der Platte nur um etwa acht GB, da beide die große N-Gramm-Tabelle in BF16 behalten – die 4-Bit-Ersparnis konzentriert sich auf die Expert-Gewichte, nicht auf den gesamten Speicherbedarf. Der eigentliche Vorteil von NVFP4 auf Blackwell ist die FP4-Tensor-Core-Geschwindigkeit bei diesen Experten, nicht eine deutlich kleinere Datei. Zweitens: Die Karte beschreibt NVFP4 als eine deterministische Gewichtsableitung, die die Abliteration-Auswertung erbt, mit einem kleinen zusätzlichen Qualitätskompromiss durch die 4-Bit-Experten, und sie beziffert diesen Kompromiss nicht. Er ist nicht quantifiziert – behandle ihn als echte, aber nicht näher spezifizierte Kosten der kleineren Experten, nicht als vernachlässigbar.

Die Auswertung, richtig gelesen

Die Karte berichtet über Abliteration, gemessen am BF16-Build, der mit vLLM gegen das offizielle Qw​en/Qwen3.8-Flash-Next bereitgestellt wird: Die Verweigerungsrate bei schädlichen Aufforderungen fällt von 64–100 % auf ungefähr 0–3,3 %, die übermäßige Verweigerung bei harmlosen Aufforderungen bleibt nahe Null, und die Leistungsfähigkeit bleibt innerhalb von ±2 Punkten des Basismodells. Drei Dinge muss man bei diesen Zahlen richtig verstehen. Es handelt sich um Messungen am BF16-Build, die per Argumentation auf diesen 4-Bit-Build übertragen werden, nicht um Messungen an diesem Build. Es sind die eigenen Zahlen des Anbieters, erzeugt mit einem regelbasierten Klassifikator für Eröffnungsphrasen, den die Karten der Sammlung als indikativ und nicht als publikationsreif beschreiben – eine interne Messung des eigenen Edits, kein unabhängiges Audit. Und sie sagen nichts über den oben erwähnten NVFP4-Qualitätskompromiss aus, den die Karte nicht quantifiziert.

Die Sicherheitsgrenze — nur für Forschungszwecke

Der Haftungsausschluss der Model-Card ist unverblümt, und er ist der Teil dieser Seite, der nicht wie ein Textbaustein klingen darf. Das Safety-Alignment dieses Modells wurde weitgehend entfernt: Die Verweigerungsrichtung wurde aus dem Residualstrom herausorthogonalisiert, und das Modell wird schädlichen, unethischen oder illegalen Anfragen nachkommen, die das ursprüngliche Qwen3.8-Flash-Next ablehnen würde. Es wird ausschließlich für legitime Forschung veröffentlicht — Interpretierbarkeit, KI-Sicherheit und Erforschung von Verweigerungsmechanismen, Red-Teaming und Robustheitsbewertung — und die Autoren übernehmen keine Haftung für Missbrauch. Sie übernehmen die volle Verantwortung für das, was es generiert, und Sie fügen Ihre eigenen Sicherheits- und Moderationsschichten hinzu, bevor irgendetwas einen Nutzer erreicht. Apache 2.0 ist die Untergrenze; das Forschungszweck-Gate sitzt darüber.

Zwei Dinge, die der Diskurs über unzensierte Modelle falsch sieht, und diese Karte macht sie unübersehbar. Erstens: Ein Jailbreak-Versuch, der gegen dieses Modell erfolgreich ist, ist keine bestandene Sicherheitsprüfung – er ist das beworbene Verhalten. Ein abliteriertes Modell scheitert bei diesen Tests absichtlich; es mit einem einzigen „Kannst du es jailbreaken?“-Test zu messen, misst, dass der Eingriff gewirkt hat, nicht, dass eine Leitplanke stark ist. Zweitens erweitern der erhaltene Vision-Tower und der intakte Tool-Calling-Pfad die tatsächliche Angriffsfläche über Text hinaus: Prompt-Injection über Bildeingaben und Tool-Missbrauch durch Agenten sind beide voll funktionsfähig – genau deshalb behandelt das Red-Team-Framing dies als Fähigkeitstest und nicht als Chatbot-Kandidaten. Wenn Ihr Anwendungsfall darin besteht, einen Assistenten für Endnutzer auszuliefern, ist dies nicht Ihr Modell – und das ist Absicht.

Wo OrcaRouter passt

Ein zwei Tage altes, zugangsbeschränktes, nur selbst gehostetes Build ist der Lehrbuchfall für Routing anstatt fest verdrahteter Verbindungen. Wenn Sie dieses NVFP4-Build selbst ausführen, können Sie eine Route einrichten, die darauf zeigt und bei Fehlverhalten unter Last auf ein gehostetes Modell umschaltet – eine Schnittstelle, kein Umverdrahten zwischen Anbietern beim Wechsel. Speziell für Evaluierungsarbeiten ist die zensierte, bereitgestellte Baseline der gewünschte Vergleichsmaßstab, und sie ist nur einen Klick entfernt: Der Katalog führt Ali​babas Qwen3.8-Flash zu 0,15 $ pro Million Eingabe-Token und 0,47 $ pro Million Ausgabe-Token, zum Listenpreis des Anbieters durchgereicht mit 0 % Aufschlag, sodass eine Red-Team-Umgebung zwischen der gehosteten zensierten Basis und Ihrem lokalen unzensierten Build wechseln kann, ohne einen zweiten Vertrag, und jede Preisänderung des Anbieters landet noch am selben Tag auf Ihrem Endpoint.

Wer sollte dies herunterladen — und wer nicht

Laden Sie orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 herunter, wenn Sie auf Blackwell arbeiten, den kleinsten Server-Fußabdruck in der Flash-Next-Sammlung mit FP4-Tensor-Core-Geschwindigkeit wünschen und die Forschungsarbeit leisten, für die diese Reihe existiert. Laden Sie Qwen3.8-Flash-Next-Uncensored-FP8 herunter, wenn Sie auf Hopper arbeiten oder den breiter verifizierten Weg bevorzugen. Laden Sie den GGUF-Build herunter, wenn Sie eine Consumer-GPU oder eine CPU-Box nutzen, den MLX-Build, wenn Sie Apple Silicon verwenden, und gar nichts, wenn das Ziel eine Bereitstellung für Endbenutzer ist. Lesen Sie das Gate und den Haftungsausschluss, bevor Sie eines davon akzeptieren – sie sind die Bedingungen des Modells, keine Formalität.

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.