服務 Qwen3.8-Flash-Next-Uncensored-FP8：block-FP8 版本的 vLLM 操作手冊

Qwen3.8-Flash-Next-Uncensored-FP8 —— 即已消除拒絕方向（abliterated）的 Flash-Next 之 block-FP8 建置 —— 是你在資料中心硬體上提供此模型服務時實際下載的工件，也是這個系列中最後一個擁有專屬操作手冊的版本。它位於orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8的 Hugging Face 頁面：已從 Qw​en 的 Qwen3.8-Flash-Next 中移除拒絕方向，再於離線重新量化為官方 Qwen3.8-Flash-Next-FP8 的完全一致 FP8 格式，使 vLLM 以相同的 kernel 路徑提供服務。這是任何在 Hopper 級及更新 GPU 上執行此模型的人會採用的建置，而服務路徑上有一個旗標很容易設錯，且一旦設錯就很難診斷。

首先，界線問題，因為讀者不斷混淆它，而這會影響下面所有內容。Qwen3.8-Flash-Next-Uncensored 和 Qwen3.8-27B-Uncensored 是兩個不同的模型，不是同一個模型的兩個構建版本。基礎權重不同——Qwen3.8-Flash-Next 對比 Qwen3.8-27B——架構不同，權重刪減不同，Hugging Face 集合也不同。它們共享一種 abliteration 技術和同一個系列名稱；僅此而已。27B 頁面上的任何數字都不適用於這個模型，如果你從 27B 的搜尋結果來到這裡，27B 自己的本地操作手冊是另一個頁面，包含另一組決策。

{{1}}這個頁面是 Flash-Next FP8 的服務頁面，僅此而已。{{/1}}{{2}}GGUF/MLX 操作手冊涵蓋了此模型的 abliteration 說明，以及兩條消費級硬體建置路線；{{/2}}{{3}}整個家族的技術原理則在 abliteration 入門指南和更廣泛的 uncensored-LLM 解說中說明；{{/3}}{{4}}而你可能被引導前往的姊妹模型 Qwen3.8-27B-Uncensored-FP8，則有自己專屬的 FP8 操作手冊。{{/4}}{{5}}在這裡，我們只聚焦於一個問題：如何服務 block-FP8 建置、做錯了會發生什麼問題，以及該卡自身的數據能告訴你什麼、不能告訴你什麼。{{/5}}

開始之前：閘道與執行環境

有兩道關卡阻擋了這個 repo，而兩者造成的失敗，看起來都像是其他原因所導致。

首先是存取權限。這個儲存庫設有門禁：你必須登入 Hugging Face 並接受該儲存庫的條款，任何下載才能運作。模型頁面本身在沒有帳號的情況下也可閱讀——完整的模型卡說明文字是公開的——但權重檔案並非如此。簡而言之，如果沒有已登入並接受條款的工作階段，`hf download` 和 `vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8` 都會因驗證錯誤而失敗，而不是出現友善的「你需要點擊 Agree」提示。請先完成一次性的點擊同意流程，然後用 hf CLI 拉取約 186 GB 的內容，或讓 vLLM 在首次執行時解析該儲存庫。

第二個是執行環境。該檢查點註冊在 qwen4_exp 架構（Qwen4ExpForConditionalGeneration）之下，而原版 vLLM 和原版 Transformers 無法載入。你需要 day-0 的 vLLM 映像檔和 transformers 5.16 以上版本。這是本週社群手冊中最常見的「無法載入」失敗原因——不是下載損壞，而是執行環境早於該架構。該映像檔不是可選的；它就是必經之路。

硬體方面，讓你在實際拉取任何東西之前先做好規劃：這張卡的調用目標是 8-GPU 節點，而官方 vLLM 配方針對 FP8 checkpoint 的指引在此同樣適用，因為兩者的建置在張量層級上一一對應——完整節點部署約需 265 GB 的 GPU VRAM，其中 TP2 被視為 GB300 等級的最低配置，而 TEP4/TEP8 則為經過驗證的全托盤配置。

為何 FP8 建置存在——以及為何「相同的核心路徑」才是重點所在

被abliterated的BF16權重是事實來源；這個repo是將該模型離線重新量化，刻意重現官方Qwen3.8-Flash-Next-FP8的配方。量化器只觸及512個路由專家投影——experts.{e}.down/gate/up_proj——將它們從BF16建構的3D佈局中解開融合，並以float8_e4m3fn權重加上BF16 weight_scale_inv縮放因子，以128×128區塊儲存。激活值為每token動態FP8；沒有校準集。其他一切保持BF16：attention與linear_attn、共享專家、MoE路由器（mlp.gate）、Hyper-Connection混合器、嵌入層、lm_head、MTP推測解碼頭，以及整個視覺塔。

「相同內核路徑」這個說法不只是行銷話術，值得用一句話來闡述。該建置已與官方 FP8 檢查點進行驗證：區塊縮放因子完全重現（scale_relerr = 0），且 FP8 編碼符合至次 ULP 捨入精度。這就是為什麼 vLLM 使用與官方版本相同的區塊縮放 FP8 內核和相同的 MTP 推測解碼來執行它——這些張量實際上就是相同的張量，只是少了拒絕方向。

具體而言，這讓你在 131 個分片中獲得約 186 GB 的權重（共 152,089 個張量，其中 75,264 個為 FP8）、262,144 個 token 的原生上下文，視覺 + 影片塔逐位元組保留（333 個 visual.* 張量），MTP 頭也原封不動。這些權重首先經過了 abliteration 處理——依照 Arditi et al. (2024)，在第 24 層估計出單一的拒絕方向，並以 float32 將其從 149 個殘差寫入張量中正交化去除——同時 MTP 頭的殘差寫入器也經過一致性的修改，因此推測解碼仍能正常運作。最後這個細節並不明顯，但它正是「加速解碼的頭」與「默默拖累解碼的頭」之間的差別。

決定載入成敗的那一個旗標

若在不加 --enable-expert-parallel 的情況下伺服此建置，你會得到一個看起來像形狀錯誤的失敗，而不是配置錯誤。這是此檢查點最常被回報的伺服失敗，而且完全是確定性的。

以下是計算過程。路由專家的融合 gate+up 投影，其中間大小為 640。Block-FP8 以 128 寬的區塊進行量化。在純張量並行下，640 會被拆分到各 rank——640 ÷ TP——而對於常見的 TP 度（2、4、8），每個 rank 的切片無法被 128 整除：TP8 得到 80，TP4 得到 160，TP2 得到 320。vLLM 接著會拒絕載入這些權重，並出現看似形狀不符的錯誤：gate 和 up 的權重 output_size = 80 無法被權重量化 block_n = 128 整除。

專家平行（expert parallelism）透過將專家權重切分到專家平行 rank（而非張量平行 rank）來解決此問題，如此便能保留 FP8 區塊邊界。這就是為什麼此旗標對此建置是強制性的：加上 --enable-expert-parallel 後，TP8 就變成可用的 TEP8。（這對 BF16 建置沒有影響，因為那裡沒有需要保留的 FP8 區塊。）官方 vLLM 配方明確指出，單純的 TP8 與 checkpoint 的 128 寬量化區塊不相容；而在權重發布兩天後提交的一則 vLLM issue，也記載了在 8×L40s 節點上於 TP2、TP4 和 TP8 遇到的完全相同失敗。如果載入時因看似形狀相關的錯誤而失敗，請先檢查旗標，再檢查下載。

確切的指令

以下是卡片的 Docker 調用，忠實重現：

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

仔細檢查那些不明顯的標記。

• vllm/vllm-openai:qwen38-flash-next-x86_64-cu130—— 這是 qwen4_exp 的 day-0 映像。它不是通用的 vLLM，而是架構特定映像。早於 qwen4_exp 的標準映像完全無法載入該檢查點。

• --trust-remote-code — 載入隨儲存庫附帶的 qwen4_exp 建模程式碼。若無此參數，載入器基於原則會拒絕載入。

• --max-model-len 262144 — 對應原生上下文視窗。這裡應明確設定，而非留給預設值。

• --enable-expert-parallel — 對於 FP8 構建是必需的，原因如上節所述。此卡註明它對 BF16 無害。

• --enable-auto-tool-choice --tool-call-parser qwen3_coder — 採用 Qwen3-Coder XML 格式啟用工具與函式呼叫功能。若關閉這些選項，模型仍可進行對話，但代理式工具使用將停用。

• --tensor-parallel-size 8 — 該卡片的調用假設使用一個 8-GPU 節點（8× Hopper 級）。啟用 --enable-expert-parallel 時，即為 TEP8 部署。

容器啟動後，端點在 :8000/v1 提供 OpenAI 相容的介面。請將 --served-model-name 設定為您的客戶端所期望的名稱；此卡片使用 Qwen3.8-Flash-Next-Uncensored。

替代方案，全部列於卡片中，或本週經從業者證實：{{2}}vllm serve {{3}}orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8{{/3}}{{/2}} 一旦你的 HF 工作階段完成驗證，即可直接使用；SGLang 則可透過 {{4}}lmsysorg/sglang:qwen38flashnext{{/4}} 映像檔，搭配 {{5}}--tp 8 --ep 8{{/5}} 執行 — 兩者同樣需要專家平行，原因相同；而若你想以腳本操作模型，而非將其作為服務部署，則可在 {{7}}transformers 5.16+{{/7}} 上使用 Transformers 的 {{6}}pipeline("image-text-to-text", ...){{/6}}。

當你端上桌時，什麼才真正管用

本節中的模式是社群本週從從業人員的操作手冊和論壇討論串中彙整的發現，並非廠商指引。當多個配置回報相同行為時，值得將其視為真實情況：

• MTP 推測解碼可正常運作。 新增 --speculative-config '{"method":"mtp","num_speculative_tokens":3}'，vLLM 便會使用保留的 MTP 頭。多份 runbook 回報，MTP 是此模型解碼在規模龐大的情況下仍能維持可用的原因。

• 載入時 OOM？將 n-gram 表卸載。 此架構中出人意料的記憶體大戶是 51B 參數的 PLE n-gram embedding。VLLM_PLE_CPU_OFFLOAD=1 會將它移到主機 RAM——請在那裡至少準備約 51 GB 的空間。官方配方和社群多節點運行手冊都會採用這個旗標。

• 視覺是真實的，並非殘留。 vision + video tower 以逐位元組方式保留，因此這仍是完整的視覺語言模型。在聊天完成（chat completion）中傳入 image_url 內容部分，同一個端點即可提供影像理解；社群針對此建置版本的 OCR 探測回報皆乾淨通過。

• 推理預設為開啟——這改變了安全態勢。聊天模板會啟用思考，除非你另行指定。可使用 chat_template_kwargs={"enable_thinking": true|false} 依請求切換，並加入推理解析器，若你想讓思考文字與答案分開。由於此預設，除非你明確將其關閉，否則你幾乎總是在服務「思考開啟」的模型。

• 原生 262K，透過 rope 覆寫可達 1M。原生上下文為 262,144 個 token。要推向 1M 需要明確的 YaRN rope-scaling 覆寫，外加一個能放寬 vLLM 之 max-model-len 上限的環境變數——而且你應該先對較短上下文的品質做回歸測試，因為盲目的 4 倍擴展正是長上下文品質通常會劣化的地方。

卡片的數字說明了什麼——以及它們沒有說明的

這些是供應商自行在其修改版本上進行的測量，公布於模型卡中，並在相同腳本與設定下，使用 vLLM 部署這些確切權重，針對官方基礎版本進行量測的結果。請如實呈現：這些數據僅具參考性質，並非獨立稽核。

重點在於關閉思考時的拒答崩潰。在該卡片的惡意提示測試集（每個基準測試 n 從 50 到 150）中，基礎拒答率介於 64–100%，而此版本為 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%，以及自訂的中英文探針 63.6%→0.0%。

現在說說誠實的那一半。基礎模型本身的拒絕率在啟用思考時會大幅下降——AdvBench 從基礎模型的 100% 下降到開啟推理時的 7.0%——因此啟用思考的比較就沒那麼戲劇化了：這個版本在相同測試套件中維持 0.0%，但它只是從基礎模型已降低的數字上再削去一小部分。如果只引用未啟用思考的數據，你呈現的就是故事中較好看的那一半，而這正是安全評估絕對不能依賴的那一半。

良性提示（XSTest-safe，n=250）上的過度拒絕率，從基礎版的9.6%降至此版本（關閉思考功能時）的1.2%——這是實質改進，因為會拒絕良性提示的模型，是較不顯眼的失敗模式。在MMLU / MMLU-Pro / GSM8K / CMMLU上的能力保持分別為−2.0、−1.2、−1.3與−0.6個百分點的差異，與「將單一方向正交化幾乎不損失一般能力」的說法一致。工具呼叫、視覺/OCR與推理在此版本均回報為正常運作。

以上所述有兩點注意事項。拒絕率指標來自一個基於規則的開場語句分類器，而模型卡本身也稱其僅具參考性，並非 LLM 評審或可發表等級的數字——人工評審小組或評審模型都無法重現這些精確數據。此外，「注意事項」欄也很關鍵：在關閉思考（thinking-off）模式的測試集中，此版本大約有一半到四分之三的輸出仍會先以簡短免責聲明開場，然後才遵從要求。模型很少拒絕；它只是閃爍其詞。這裡的「Uncensored」意思是它會回答，而非指它的回答沒有開場白。

安全部分並非形式。

拉起重量前先讀這個，別等到之後。

此模型的安全對齊已被大幅移除，且其機制十分具體：在殘差流中估計出單一拒絕方向，並將其從每個殘差寫入矩陣中正交化去除——共149個——以float32計算。此後果是明示的，而非附帶產生的。模型卡直言不諱地指出，該模型會遵從基礎Qwen3.8-Flash-Next原本會拒絕的有害、不道德、冒犯性或非法請求，且沒有任何實質的內建防護機制。此模型僅為合法的研究目的而發布——包括可解釋性、AI安全與拒絕機制研究、紅隊測試、穩健性評估與受控實驗——使用者須對其生成內容承擔全部責任與法律責任。Apache 2.0授權條款規範您對權重的使用方式。

有兩件事必須完全做對，因為這個版本很容易讓它們出錯。

首先，針對該模型的越獄探測若「成功」，並不代表通過安全評估，而是其預期的行為。如果你的評估宣稱「該模型的安全防護已被繞過」，你測量到的是設計本身，而非漏洞。真正算得上發現的，是那些在 abliteration 之後依然存在的拒絕行為，或是能力退化——而模型卡上的數據顯示，這兩種情況都很罕見。

其次，保留的攻擊面比文字更廣。視覺塔逐位元組完整保留，工具呼叫也能運作，因此影像輸入和代理式使用都仍然有效。只探測文字提示的紅隊計畫，會漏掉此模型實際暴露的模態。而上述的拒答數字，是基於規則的分類器，套用在供應商自己的修改上——它們不是對任何事物的獨立稽核，安全也不例外。

請勿在未添加自己的安全、審核和濫用防護層的情況下，將此部署給最終使用者或投入生產環境。該儲存庫的條款已明確說明，且這並非例行公事：輸出內容並不反映上傳者或Qw​en / Ali​baba的觀點。

如何取得用於比較的設限基準

如果你的工作是拒絕機制研究或紅隊測試，你幾乎肯定會想要這個模型的受審查對應版本並排對照——相同的架構但未經編輯——以衡量兩者之間的差異。這個未審查的建置版本在設計上僅限本地使用：儲存庫設有存取限制，且沒有託管的推論部署，這是刻意為之，以便敏感的有效載荷永遠不會經由第三方 API 傳輸。

就託管基準而言，OrcaRouter 以供應商列表價格轉送 Qwen 產品線，零加價——Qwen3.8-Flash 每百萬輸入 token 收費 $0.15，每百萬輸出 token 收費 $0.47，完全原價轉嫁，並具備自動故障轉移，且單一金鑰即可存取 200 多種模型。供應商價格異動當天即會反映。若你正在斟酌是否要執行這個建置，或它究竟能承載你技術棧的多少比重，這就是一個便宜的方式，讓你在不必簽第二份合約、也不必維護第二套程式碼的前提下，將審查版拿來與之對照比較。

從這裡開始

決策摘要。你需要：一個已接受該儲存庫條款的 Hugging Face 帳號；一個 Hopper 級或更新的節點——該模型卡的指令以 8 個 GPU 為目標，且根據官方配方對應 FP8 檢查點的指引，GPU VRAM 約需 265 GB；day-0 的 vLLM 映像檔和 transformers 5.16+；以及約 186 GB 的磁碟空間存放權重。

執行順序：接受 repo 條款 → 下載權重 → 拉取 day-0 映像 → 使用 --enable-expert-parallel 提供服務 → 以對 :8000/v1/chat/completions 的請求進行驗證 → 然後開始你的評估。如果載入失敗並出現看似形狀的錯誤，請先檢查旗標，再檢查下載。

並保持框架。這是一個研究工具，以此為條件發布。其數字是供應商對自身版本所做的指示性測量。其安全行為正是本次實驗的重點，而非需要繞過的缺陷。部署它、測量它，並在它與任何人類事物之間，加入你自己的審核把關。

所有五種 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 上提供——即原始模型，安全對齊完好無缺。