Qwen3.8-Flash-Next-Uncensored-NVFP4：Blackwell 服務操作手冊

Qwen3.8-Flash-Next-Uncensored-NVFP4只在一種 GPU 系列上運行：Blackwell。NVFP4 在硬體 FP4 張量核心上執行，而 Hopper（H100/H200）以及任何更舊的 GPU 根本沒有這些核心。如果你用的是 Hopper，到此為止——Qwen3.8-Flash-Next-Uncensored-FP8版本才是你需要的。以下所有內容均假設你使用 Blackwell（B100、B200、GB200 或 RTX 50 系列顯示卡）、支援 qwen4_exp 的較新 vLLM 構建版本，以及 transformers ≥ 5.16。

這是 Qwen 的 abliterated（已移除拒絕回答）建置的 NVFP4 量化：Qwen/Qwen3.8-Flash-Next，從 BF16 的 330 GB 縮減至磁碟上的 178 GB。OrcaRouter 於 2026 年 8 月 27 日將其發布到 Hugging Face，名為 orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4。該儲存庫設有存取限制：你必須登入 Hugging Face 並接受儲存庫的條款，否則 hf download 與 vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 都會在傳輸任何位元組之前因驗證錯誤而失敗。此頁面是一份部署（serving）運行手冊，而非發布報導——該建置僅推出兩天，人們實際會遇到的問題是硬體、旗標（flags），以及該選擇哪個建置。

在數字開始之前：Qwen3.8-Flash-Next-Uncensored並非Qwen3.8-27B-Uncensored。它們是兩個不同的模型，共享同一個系列名稱與相同的 abliteration 技術——不同的基礎權重、不同的架構、不同的 Hugging Face 集合。Flash-Next 是從Qw​en/Qwen3.8-Flash-Next，即 Qwen4 架構（qwen4_exp）的路由混合專家（routed mixture-of-experts）預覽版：512 個專家，其中十個 routed 專家加上一個共享且恆定啟動（active）的專家，混合注意力（Gated DeltaNet 線性層與全注意力層並行）、Hyper-Connections、PLE n-gram 嵌入、原生視覺與視訊塔，以及 MTP 推測解碼頭。27B 則是從Qw​en/Qwen3.8-27B，一個完全不同的密集基礎模型。27B 頁面上的服務數據不會轉移到此模型；在 27B 頁面真正有用之處——abliteration 入門、通用的量化選擇計算——則於下方連結，並標明哪些可沿用、哪些不可沿用。

這個構築是什麼，一點一滴的精確剖析

Qwen3.8-Flash-Next 是一個路由式混合專家（MoE）模型：{{1}}每個 token 會啟動 512 個專家中的 10 個，外加一個共享專家，而{{2}}儘管儲存模型的規模遠大於此，每個 token 僅有數十億參數處於活躍狀態{{/2}}。{{/1}}NVFP4 版本是對該架構進行混合精度壓縮張量（compressed-tensors）量化的產物，{{3}}而這種拆分正是關鍵所在{{/3}}：

• MoE 專家權重 — NVFP4（4 位元、NVIDIA FP4 E2M1、group-16 搭配 FP8 區塊縮放）。

• Attention（self_attn.{q,k,v,o}）、linear_attn 投影、共享專家，以及 lm_head — FP8（8位元）

• PLE n-gram 嵌入、token 與 vision 嵌入、Hyper-Connections、QSA 索引器、Gated-DeltaNet conv/dt、所有正規化層，以及整個視覺塔——皆為 BF16，保持全精度。

轉換的三個特性比精度劃分本身更重要。首先，它是僅權重量化：激活值在執行時動態量化，沒有靜態校準，而權重直接從 BF16 檢查點導出（該卡稱此推導過程為無資料依賴）。其次，abliteration 編輯已烘焙進權重中，因此拒絕移除能在量化後保存下來——4 位元轉換只是精度變更，而非安全干預。第三，KV 快取不量化；執行時維持 BF16。最後這點很容易被忽略，而在模型原生 262,144 個 token 的上下文長度下，它非常重要，因為 KV 快取與權重一樣，都是實際的記憶體開銷項目。

磁碟佔用空間主要由一個張量主導。該卡將 PLE n-gram 嵌入描述為一個依設計以 BF16 保存的約 660 億參數張量；它是最大的分片，也是建置為 178 GB 而非更精簡數字的原因。有一個需要指出而非掩蓋的差異：FP8 兄弟卡將同一表格稱為 510 億參數的 PLE n-gram，而這張卡的 W4A4 註記則稱其約為 100 GB。兩張卡對同一表格給出了不同數字，因此請將每個數字視為各自卡片自己的數字——在規劃部署規模時，假設該表格在 BF16 下體積龐大，並據此進行規劃。

硬體前置條件，詳細說明

這是頁面上最短但最重要的部分。NVFP4 是 Blackwell 格式：其快速路徑是在第五代張量核心上執行的原生 FP4 GEMM，而沒有該硬體，此格式便無從運行。顯示卡自身的需求說明寫得很明確——必須採用 Blackwell GPU（B100 / B200 / GB200 / RTX 50 系列），因為 NVFP4 使用硬體 FP4 張量核心，因此它無法在 Hopper（H100/H200）或更舊的架構上運行，這些架構缺乏 FP4 運算能力。

重新導向，集中在一處：

• 在 Hopper（H100/H200）上，請改為使用 Qwen3.8-Flash-Next-Uncensored-FP8。它使用相同的權重但為 8-bit 精度，可運行於 Hopper 和 Blackwell，而本篇部落格的 FP8 操作手冊正是針對此建置版本。

• 在消費級 NVIDIA GPU 或 CPU 機器上，配備 13 種 llama.cpp 量化格式的 GGUF 版本是本地端方案。

• 在 Apple Silicon 上 — MLX 版本（4/6/8 位元等級）是原生的 Metal 路徑。

運行時要求如同矽晶片本身一樣具有約束力。qwen4_exp 是全新建構，因此早於它的標準 vLLM 建置會拒絕載入 checkpoint。您需要支援 qwen4_exp 的最新 vLLM，加上 compressed-tensors NVFP4 讀取器（格式是從 config.json 偵測，而非手動選擇），以及 transformers ≥ 5.16。多模態輸入額外需要運行時的 Qw​en 視覺堆疊；僅文字服務則不需要。

這張卡片的 serve 命令，逐個旗標

模型卡自身的調用是一個很好的起點，值得理解每個旗標的用途，而不是盲目地複製貼上：

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 — 權重在磁碟上約 178 GB，因此該卡會將它們分散到四個 GPU 上。這就是此建置所針對的組態；請勿將其視為建議。

• --trust-remote-code — 自訂架構所需。qwen4_exp 的建模程式碼尚未收錄在標準 transformers 登錄檔中，因此 vLLM 會從儲存庫載入架構程式碼。你等於是在信任那段程式碼，這對一個全新架構來說是正常但實際的決定。

• --enable-expert-parallel——將專家分散到張量並行（tensor-parallel）的各個 rank，而非複製一份；這正是讓 512 個專家的 MoE 在 TP4 下可行的關鍵。對應的 FP8 卡片說明了該版本更精確的理由：若無此參數，MoE 的中間層寬度除以 TP 後，將無法被 FP8 的 block size 整除。請將其視為必要參數，而非選用參數。

• --enable-auto-tool-choice and --tool-call-parser qwen3_coder — 它們共同啟用函式呼叫。auto 旗標讓模型自行決定是否呼叫工具，而 qwen3_coder 解析器則解碼其工具呼叫格式，與 Qwen3.8-27B 和 Qwen3.8-Flash-Next 所用的解析器家族相同。

一旦啟動，位於 /v1/chat/completions 的 OpenAI 相容端點透過執行階段的 Qwen4 堆疊提供完整功能集：如上所述的工具呼叫、透過 chat_template_kwargs.enable_thinking 進行的推理，以及透過 image_url 內容部分實現的視覺功能。您不需要為多模態另設伺服器；這是同一個端點。

卡片上的一則結構性說明：此建置沒有完全靜態的 W4A4 變體，而且短期內也不會有便宜的方案。靜態 W4A4 轉換需要一次激活校準的正向傳遞，而該傳遞必須在單一 GPU 上容納約 100 GB 的 n-gram 嵌入。這正是 PLE 表格在檔案清單中佔主導地位的原因，也是此建置維持僅權重（weight-only）搭配動態激活的原因。

社群實地報告 — 實際提供這項服務的樣貌

這個確切的 repo 並未公布任何吞吐量或延遲數據，本頁面也不會憑空捏造。現有的只是一群從業人員在部署基礎版 Qwen3.8-Flash-Next NVFP4 建置時累積的實地報告——相同的架構、相同的 NVFP4/FP8/BF16 精度分配，只是少了 abliteration 編輯——而部署行為會直接沿用。這些是社群發現，並非廠商指引，且回報者都是在採用相同量化方案的 Blackwell 硬體上運作。

• MTP 推測解碼是最大的單一效能槓桿。該模型配備了一個多 token 預測的草稿頭。在一張 RTX PRO 6000（96 GB、SM120）上，MTP 模組以 NVFP4 量化方式載入，約佔 0.51 GB 的 VRAM——報告量測到的接受長度為 2.3–3.9（上限 4），接受率為 0.86–0.96。同一份報告量測到單串流解碼中位數為 180–226 tok/s（編碼 216.9、代理工具呼叫工作負載 225.8、推理 136.6），對比基準約為 105 tok/s，並在 8.4 秒內回答了一個 216,685 token 的提示詞。請將這些數字視為單一使用者的硬體配置，而非規格數據。

• 將 PLE n-gram 嵌入卸載到主機 RAM。由於這個表格非常龐大，而且很少成為吞吐量的瓶頸，單張 Blackwell 顯示卡的社群做法會將其固定於主機端（RTX PRO 6000 報告中約有 50 GiB 的可用主機 RAM），並以 mmap 從 NVMe 映射，用一點延遲換取模型得以載入。除非你的 VRAM 預算非常充裕，否則預期也需要這樣做。

• 明確固定上下文窗口。啟用 BF16 KV 快取和 MTP 時，自動調整大小的 KV 池會膨脹到超出顯示卡容量，並在長預填時觸發 OOM；將 max-model-len / max-total-tokens 固定為 262144 後才恢復了餘裕。在 262K 上下文下，KV 快取是需要編列預算的項目，而非預設值。

• FlashInfer autotune 的 bug 會默默破壞輸出。在實務上，這是最重要的故障模式：autotune 只根據延遲（latency）選擇 fused-MoE 的 kernel 策略，從不檢查數值正確性，因此在某些 shape 下，decode 會崩潰成重複的 token。RTX PRO 6000 的報告重現了此問題：開啟 autotune 時，36 次生成中有 36 次損壞；關閉時則為 0 次。變通做法是停用 FlashInfer autotune（在 vLLM 中，使用 --no-enable-flashinfer-autotune；在 SGLang 中，使用 --disable-flashinfer-autotune）。如果你的服務輸出突然退化，請先檢查此項，再動其他任何設定。

• DGX Spark（GB10、SM121）需要自己的補丁。社群版中的 NVFP4 權重（約 126 GiB）無法裝入單台 128 GB 的 Spark，因此 SGLang 的配方（recipes）會透過 RoCE 跨兩個節點以張量並行（tensor-parallel）2 的方式執行；而 QSA 的稀疏解碼解析器（sparse-decode resolver）會把快速的 FlashInfer kernel 擋在 is_sm100_supported() 檢查之後，該檢查在 SM121 上會失敗，於是便退回至一條在預熱階段就會當掉的路徑——修復方式是一份小補丁，再加上 PLE 卸載（offload）。預期解碼速度約為 47–50 tok/s，搭配 MTP4 與 CUDA graphs 時峰值接近 70 tok/s；在承諾基準測試（benchmark）結果之前，請先確認你的 kernel 確實能在 SM121 上執行。

透過 Qwen4 技術棧實現推理、工具呼叫與視覺能力

社群對 Qwen3.8 世代的共識沿用至此模型，但附帶慣常的但書：這屬於實際操作經驗，而非供應商指導。

• reasoning_effort 是最關鍵的調節旋鈕。聊天模板預設為 xhigh，這會讓模型在每次請求時都進行長時間思考。Agent-loop 操作者預設設定為 medium，並在對延遲敏感的呼叫中降至 low；當你不需要推理時，enable_thinking false 可完全停用推理。在單張 Blackwell 卡上，如果例行呼叫也維持 xhigh，就會讓快速模型產生緩慢的答案。

• 將採樣器與思考模式配對使用。從業者普遍在思考模式開啟時使用溫度 1.0 / top-p 0.95，關閉時則使用溫度 0.7 / top-p 0.80，並搭配約 1.5 的存在懲罰。混用這兩組設定會導致輸出品質下降。

• 工具呼叫在經過 abliteration 和 4 位元量化後仍然有效。 函式呼叫路徑完好無損，這正是 qwen3_coder 解析器和自動工具選擇旗標所連接的部分。對紅隊來說，這是把雙面刃，因為這表示在未對齊的模型上，代理型濫用可完全運作——詳見下文。

• 視覺能力得以保留，這擴大了攻擊面。視覺塔從未受abliteration影響，且保持BF16格式，因此圖像輸入可透過image_url內容部分運作。評估無審查系列的實務者將多模態路徑視為首要評估目標：載於圖像中的提示注入會落在一個沒有拒絕行為可阻擋的模型上。

您應該提供哪個組建？

Flash-Next 系列共有五種建構版本 — BF16、GGUF、MLX、FP8，以及這個 NVFP4 — 而誠實的選擇邏輯取決於硬體與取捨，並非排名高低。

• NVFP4（此版本，磁碟上約 178 GB） — Blackwell 之選。FP4 張量核心、4 位元專家，是收錄中最新版本，也是其 vLLM 伺服器版本中最小的一個，而本頁介紹的正是此版本。

• FP8（磁碟上約 186 GB）——Hopper 的首選，在 Blackwell 上同樣適用。相同的權重以 8-bit 儲存，這是經過更廣泛驗證的 vLLM 路徑，也是專家並行需求更明確的路徑。

• GGUF（13 種量化，IQ2_XXS 約 52 GB 至 Q5_K_M 約 125 GB）——這是 llama.cpp 在消費級 NVIDIA、AMD 或 CPU 機器上的首選。無需 Blackwell，也無需 vLLM。

• MLX（4/6/8 位元等級，約 163–221 GB） — Apple Silicon 的首選，原生 Metal，內含 MTP 接頭。

在你選擇之前，有兩點坦誠的說明。首先，NVFP4 與 FP8 版本在磁碟上的差距僅約 8 GB，因為兩者都將大型 n-gram 表保留在 BF16 格式中——4 位元的節省集中在專家權重上，而非整體佔用空間。在 Blackwell 上，NVFP4 真正的優勢在於這些專家上的 FP4 張量核心速度，而非檔案大幅縮小。其次，該卡片將 NVFP4 描述為一種確定性的權重衍生方式，繼承了 abliteration 評估結果，但來自 4 位元專家會帶來少量額外的品質取捨，而它並未量化此取捨。這是未被量化的——應將其視為較小專家所帶來的真實但未明說的成本，而非可忽略不計。

評估，正確解讀

「該模型卡報告了在以 vLLM 提供服務的 BF16 版本上、對照官方 Qw​en/Qwen3.8-Flash-Next 所測得的 abliteration 數據：有害提示的拒答率從 64–100% 崩跌至約 0–3.3%，良性提示的過度拒答維持在接近零，能力則與基礎版本相差在 ±2 個百分點以內。關於這些數字，有三件事須正確理解。它們是在 BF16 版本上測得的結果，此 4 位元版本是透過論證推論而繼承，而非在其上實測所得。它們是廠商自己的數據，由一個基於規則的開場語句分類器所產生；該系列的卡片將其描述為指示性（indicative）而非發表等級——這是對其自身修改所做的內部測量，並非獨立稽核。此外，這些數據對上述 NVFP4 的品質取捨毫無著墨，而該卡也未對此加以量化。」

安全邊界 — 僅供研究

這張卡片的免責聲明直言不諱，也是本頁面中最不能讀起來像套版文字的部分。此模型的安全對齊已被大幅移除：拒絕方向已從殘差流中正交化剔除，模型會順從原始 Qwen3.8-Flash-Next 會拒絕的有害、不道德或非法請求。此模型僅為合法研究而發布——可解釋性、AI 安全與拒絕機制研究、紅隊測試及穩健性評估——作者對濫用行為不承擔任何責任。您需對其生成內容承擔全部責任，並在使用者接觸任何內容之前，自行加入安全與審核機制。Apache 2.0 是基本底限；研究用途的限制門檻位於其上。

「未審查模型」的論述有兩點錯誤，而這張卡片讓它們無法被忽視。第一，{{1}}針對此模型成功的越獄探測並非通過安全評估——這是其宣稱的行為。{{/1}}去對齊模型是刻意無法通過那些探測的；{{2}}用單一「你能越獄它嗎」測試來衡量，只是在衡量編輯是否生效，而非護欄是否強固。{{/2}}第二，{{3}}被保留的視覺塔與完整的工具呼叫路徑，將實際攻擊面擴展到文字之外：{{/3}}{{4}}影像輸入的提示注入與代理工具濫用都完全可用，{{/4}}這正是紅隊框架將其視為能力探測、而非聊天機器人候選的原因。如果你的使用情境是推出面向使用者的助理，這不是你的模型，而這是刻意為之。

OrcaRouter 的定位

一個僅兩天歷史、受限、僅限自託管的建置，正是路由而非固定線路的典型案例。當你親自執行這個 NVFP4 建置時，你可以建立一條指向它的路由，並在該建置於負載下表現異常時故障轉移至託管模型——只需一個介面，切換供應商時無需重新接線。具體針對評估工作而言，設有審查的託管基準正是你想要的比較對象，而且它只需一鍵之遙：目錄中提供 Ali​baba 的 Qwen3.8-Flash，每百萬輸入 token 收費 $0.15，每百萬輸出 token 收費 $0.47，按供應商列表價格轉發且加價 0%，因此紅隊測試框架可以在託管的審查基準與你本地的未審查建置之間移動，無需第二份合約，而任何供應商價格變動也會在當天反映到你的端點上。

誰應該下載這個——誰不應該

如果你使用 Blackwell，想在 Flash-Next 系列中取得最小的伺服器佔用空間，並具備 FP4 張量核心速度，而且你正在做這條產品線存在所要服務的研究工作，請下載 orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4。如果你使用 Hopper，或者你想要更廣泛驗證的路徑，請下載 Qwen3.8-Flash-Next-Uncensored-FP8。如果你使用消費級 GPU 或 CPU 主機，請下載 GGUF 版本；如果你使用 Apple Silicon，請下載 MLX 版本；如果目標是面向使用者的部署，則什麼都不用下載。在您接受任一版本之前，請先閱讀 gate 與免責聲明——它們是模型的條款，而不是形式。

所有五種 Flash-Next 構建——BF16、GGUF、MLX、FP8 和 NVFP4——都收錄在Qwen3.8-Flash-Next-Uncensored collection（Hugging Face 上）。

一個不同的模型，不是這個模型的另一個建置版本：Qwen3.8-27B-Uncensored是從不同的基礎模型進行去對齊（abliterated）處理，並擁有自己獨立的集合與操作手冊。

這些權重依設計僅限本機使用。若要取得可對照衡量 abliterated 建置版本的託管基準，Qwen3.8-Flash 會以供應商列表價格、0% 加價在 OrcaRouter 上提供——即原始模型，安全對齊完好無缺。