Qwen3.8-Flash-Next-Uncensored：在 llama.cpp 和 Apple Silicon 上運行 Abliterated MoE

在下載任何東西之前：Qwen3.8-Flash-Next-Uncensored不是Qwen3.8-27B-Uncensored。它們共享同一個系列名稱和 abliferation 技術，但其實是不同權重版本的不同模型；本站先前每一篇「Qw​en uncensored」文章講的都是 27B。這裡的主角是 OrcaRouter 於 2026 年 8 月 26 日發布到 Hugging Face 的一對模型——orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF與orcarouter/Qwen3.8-Flash-Next-Uncensored-MLX——也就是Qwen3.8-Flash-Next的 abliferation 版本。Qwen3.8-Flash-Next 是 Alibaba 的 176B 儲存 / 6B 啟用路由式混合專家（MoE）模型，預覽 Qwen4 架構。我們以「GGUF + 原生 MLX，最高 262K 上下文」宣布這批發布，目標是安全研究人員、紅隊和藍隊。這份 runbook 是根據我們自己的 model cards 撰寫：在路由式 MoE 內部去除拒絕機制究竟做了什麼、262K 上下文的宣稱實際上要耗費多少記憶體、如何伺服這兩種檔案系列，以及研究路線位於何處。如果你是想找 abliferation 入門或 27B 量化數學，本系列先前文章已經涵蓋那些主題。

首先，大門。

兩個儲存庫都在 Hugging Face 上設有門檻（gated: auto）。在您登入並在每個儲存庫上接受儲存庫條款之前，無法下載任何檔案——GGUF 和 MLX 儲存庫各自有自己的門檻。這與未設門檻的 GGUF 系列相比，最實際的差異在於：單純的「只要 hf download」一行指令在抓取任何位元組之前就會因驗證錯誤而失敗。流程是：

• 登入 Hugging Face（或註冊）並安裝 huggingface_hub，然後執行一次 hf auth login，以便您的令牌儲存在磁碟上。

• 在瀏覽器中開啟 orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF，接受條款，然後對 orcarouter/Qwen3.8-Flash-Next-Uncensored-MLX 重複相同操作。

• 從那時起，使用您的已認證 token 執行 hf download，就跟處理任何其他儲存庫一樣。您所下載的每個量化版本，以及 MLX 權重，都是 Apache-2.0 之下的研究產物——與基礎模型相同的授權——而這道門檻正是協議的一部分：閱讀條款是使用模型的第一步。

abliteration 對路由 MoE 的作用

這項技術是我們在此部落格其他文章中已介紹過的 Arditi 式權重編輯；有趣的是它對這個特定架構的作用。在密集的 27B 模型上，它涉及 131 個殘差矩陣。在 Qwen3.8-Flash-Next-Uncensored 上，MLX 模型卡記錄了對 149 個殘差寫入張量套用 abliteration，而構成這個模型之所以如此的元件——MoE 路由器、51B n-gram 嵌入表、視覺塔——則明確從未被觸及。

「從未觸及」這個說法對路由模型來說就是全部真相。每個 token 會啟動 512 個專家中的 10 個；沒有任何單一專家負責拒絕行為。拒絕行為存在於組成最終輸出的殘差流中，而這正是正交化所移除的方向。因此路由器持續路由相同的專家，n-gram 表持續產生相同的嵌入，而改變的是輸出投射層運行後模型所說的內容。GGUF 模型卡上公布的評測結果將這種變化的形態描述為：有害提示拒絕率從基礎模型的 64–100% 下降到這個版本的約 0–3.3%，良性過度拒絕接近 0%，而在 MMLU-Pro / GSM8K / CMMLU 類型的評測中，能力與基礎模型差距在 ±2 個百分點以內。這些是模型卡自己的數字，是自我報告而非獨立複現的結果。

MTP head：存在於 MLX 中，在 GGUF 中已移除

Qwen3.8-Flash-Next 內建了一個約 4B 的 multi-token-prediction（多令牌預測，MTP）推測式解碼頭，而兩種建置版本對它的處理方式並不一致。GGUF 儲存庫將其排除在外——模型卡明確說明這些檔案不包含 MTP 推測式草稿頭——原因是 llama.cpp 的 qwen4exp 支援尚未實作 MTP，因此把這個解碼頭放進檔案裡只會是多餘的累贅。MLX 建置版本則保留了它，所以在 Apple Silicon 上你依然能獲得推測式解碼的加速。實際影響（已由實際運行基礎模型的從業者證實）是：目前 llama.cpp 的 GGUF 路線在沒有推測式解碼的情況下運行，而在同一等級的硬體上，啟用 MTP 的 SGLang 配置能讓解碼速度提升一倍以上。若未來 llama.cpp 為 qwen4exp 加入 MTP 支援，GGUF 這條路線就能免費獲得速度提升——但請不要為了期待「本週就能實現」而購買硬體。

262K 上下文宣稱，以及 KV 快取的代價

原生上下文長度為 262,144 個 token（可透過 YaRN 擴展至 100 萬），而真正會造成限制的是記憶體。好消息是，該架構讓 KV 快取保持在很小的規模：在 48 層中，36 層使用 Gated DeltaNet 線性注意力，可將歷史資訊壓縮為固定大小的循環狀態，只有 12 個全注意力層帶有傳統的 KV 快取，其大小會隨序列長度增長。

兩個由社群測量的數據點，皆基於基礎模型，可直接套用。一個 4× RTX 3090 GGUF 部署回報，在僅增加每張卡約 0.78 GB 的 KV 快取下，將上下文從 65K 提升到 131K；而單一台 DGX Spark 則以 Q4 等級的檔案跑滿 262K 上下文，同時透過將 n-gram 表固定於 CPU 並從 NVMe 進行 mmap，讓模型常駐於其 128 GB 記憶體中的約 76.9 GB。GGUF 模型卡自身的預算公式為：總量 = 檔案大小 + KV 快取 + 約 0.9 GB 的 mmproj。這對量化選擇的結論是：在 262K 下，KV 快取是實際的支出項目，但權重才是主導項目，因此 27B GGUF 指南中「VRAM 優先」的相同邏輯依然適用——這裡的差異在於檔案大小本身，範圍從約 52 GB 的 IQ2_XXS 到約 125 GB 的 Q5_K_M。

GGUF 系列：13 種量化、分割檔案、mmproj，以及一個 llama.cpp 建置。

GGUF 儲存庫提供 13 種量化等級：IQ2_XXS、IQ2_M、IQ3_XXS、IQ3_M、IQ4_XS、Q2_K、Q3_K_S、Q3_K_M、Q3_K_L、Q4_K_S、Q4_K_M、Q5_K_S、Q5_K_M，其中 IQ 量化是基於英文、中文與程式碼校正文字的重要性矩陣建構而成。每個量化檔都是多部分組成，並以 llama-gguf-split 分割，因此請下載某個量化等級的完整集合，並將載入器指向 ...-00001-of-000NN.gguf 這個部分。此處沒有 Q6_K、Q8_0 或 F16 等級，原因在於結構性而非經濟因素：n-gram（PLE）嵌入表在 6-bit 及以上時，單一張量過大，無法符合 Hugging Face 每個檔案 50 GB 的上限，而且單一 GGUF 張量無法跨檔案分割——因此最高只能到 Q5_K_M。

你不應跳過的另一個檔案是 mmproj-...-F16.gguf，大小約 0.9 GB：這是一個視覺語言模型，而 llama.cpp 在任何影像輸入時都需要這個投影器。Qwen3.8-Flash-Next 是多模態的，這個建置版本也是如此——abliteration 不會觸及視覺塔。

llama.cpp 的支援尚未進入主線。架構 ID 是 qwen4exp，標準建置會失敗並顯示「unknown architecture 'qwen4_exp'」；你需要使用 PR #27742（分支 qwen4exp/qwen3.8-flash-next）的建置，並以 llama-cli、llama-mtmd-cli、llama-server 與 llama-gguf-split 為編譯目標。接下來，服務型態就是常見的 llama.cpp server，搭配 Qw​en 專用旗標，並使用分片檔案中的量化名稱：

llama-server -m Qwen3.8-Flash-Next-Uncensored-Q4_K_M-00001-of-00003.gguf --jinja --mmproj mmproj-Qwen3.8-Flash-Next-Uncensored-F16.gguf -c 8192 --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0

將 -c 設定為你能容納的任何上下文長度；此卡片的範例從 8192 開始。推理預設為開啟，並在 reasoning_content 中回傳，工具呼叫則可透過與 OpenAI 相容的端點運作。上述取樣數值為模型卡片的建議；使用基礎模型的從業者在非思考指令模式中採用 temp 0.7 / top-p 0.80 / top-k 20，並加上 1.5 的存在懲罰，同時以 --chat-template-kwargs {"reasoning_effort":"medium"} 調整推理深度。

Apple Silicon 上的 MLX 版本

MLX 儲存庫是 Apple Silicon 的原生路徑：相同權重、相同的拒答移除機制，以及 Metal 原生執行環境。預設提供 4-bit 建置（約 163 GB）、已公布的 6-bit 建置（約 192 GB）和 8-bit 層級（約 221 GB）。由於融合式 3D 專家（fused-3D experts）與 n-gram 表是以高於標稱位元數的精度保存，實際有效精度遠高於均勻 4-bit——清單上「4-bit」標籤約為每個權重 7.85 個有效位元。這就是儲存庫體積看似龐大的原因：n-gram 表並未像社群量化版那樣被壓縮到極致。

硬體是根本的限制條件。MLX 僅能在 Apple Silicon（Metal）上執行，而且你需要統一記憶體來容納權重——模型卡上的說明是「一台具備足夠統一記憶體以容納 163 GB 權重的 Mac（例如 M 系列 Ultra）」。請將 4-bit 等級視為 192 GB 級別的機器，6-bit 版本則視為 256 GB 級別。模型卡的標籤記錄了完整的功能集——qwen4_exp、MoE、MTP、函式呼叫、視覺語言——並透過 mlx-vlm 驅動影像輸入。此處包含了 MTP 推測解碼頭，這是 MLX 版本相較於 GGUF 系列的隱藏優勢。

視覺路徑，適用於使用它的人

由於這是一個視覺語言模型，多模態路徑是操作手冊的一部分，而非額外功能。在 llama.cpp 上，影像輸入需要 mmproj 投影器，以及包含 llama-mtmd-cli / llama-server 的建置版本。在 MLX 上，你應使用 mlx-vlm 驅動，而非僅支援文字的 mlx-lm 驅動程式。對紅隊而言，視覺路徑正是有趣評估工作的所在：多模態護欄、以影像承載的提示注入、對自家系統截圖進行的 OCR，以及針對整個管線的對抗性影像。由於 abliteration 涵蓋整個模型且保留視覺塔完好無損，一張在文字頭中會觸發拒絕回應的影像，最終只會落在一個沒有拒絕行為可觸發的模型上。GGUF 卡說明此建置版本已驗證視覺與多輪工具呼叫功能；但並未發布獨立的視覺評估套件。

這是做什麼用的，以及界線在哪裡

此建置存在的目的只有一類工作：評估移除拒答機制（refusal）的模型能做到什麼，以服務於理解與防禦系統。對紅隊而言，這意味著用一個不會禮貌婉拒的模型來測試你自己的防護措施——提示注入的抵抗力、資料外洩情境、工具使用的濫用，以及「基礎模型會拒絕」與「模型實際上做不到」之間的落差。這個落差正是 abliterated 建置的全部研究價值：它讓你看見拒答層原本隱藏了什麼，也就是「靠政策達到的安全」與「靠能力達到的安全」之間的差異。對藍隊而言，同一組權重就是對手合理的基準線：如果敵意行為者能下載並執行這個模型，你的防禦就必須能抵擋一個會回答而非閃避的模型。以此為基礎所作的評估，是客製化且從未對齊的模型所能做到之事的下限——請這樣看待它們，而不是把它們當作上限。

需明確區分移除拒絕機制會改變什麼、不會改變什麼。它改變的是輸出行為——模型不再拒絕回答——但能力並未改變。沒有新增知識、沒有新增技能、沒有新增算力；訓練相同，模型實際能產出的內容限制也相同。去抑制（abliterated）模型並不能設計出它原本無法設計的惡意軟體；它只是直接回答而非迴避閃爍，而且輸出也不會因為更放任就變得更真實。卡片上±2分的能力區間與拒絕數字的崩跌，是同一事實的兩個面向。

閘門式儲存庫協議的界線劃分於此，而它並非制式條款。合法用途：評估你自己的系統、對模型進行公開漏洞研究、建立偵測與防禦性評估、研究拒答機制。不合法用途：將此部署為面向使用者的助理、針對你不擁有或未獲授權測試的系統生成可運作的惡意軟體或漏洞利用程式、詐欺、武器材料。Apache-2.0 授權條款與適用法律是底線；而閘門是位於其上、明確的研究用途協議。如果你的使用情境是「向使用者推出聊天機器人」，那这不是你的模型——而這是刻意為之，並非疏忽。

如何取得提供的基線

這些權重刻意僅限本地使用：紅隊的探測載荷絕不應經過第三方 API，而自架設正是重點。當你想要經過審查、以服務方式提供的基準來對照時——阿里巴巴的 Qwen3.8-Flash：每百萬輸入 token 0.16 美元、每百萬輸出 token 0.47 美元——OrcaRouter 會以供應商的列表價格、零加價並自動故障轉移來路由，因此評估測試架構只需一個金鑰、無需第二份合約，就能在託管基準與你本地的無審查版本之間切換。開放的 Qwen3.8-Flash-Next 權重目前還不在我們的目錄中；一旦我們路由的某個執行環境提供這些權重，它們就會進入相同的單一金鑰、列表價格設置。

從這裡開始

先判斷哪一條路線符合你的硬體，然後閱讀相關的關卡。在配備 128 GB 以上統一記憶體的 Mac 上，MLX 版本把 MTP 與視覺功能整合在同一處——接受 MLX 儲存庫的條款、下載 4-bit 或 6-bit 權重，然後用 mlx-vlm 驅動它們。在 NVIDIA、AMD 或 CPU 機器上，則從 PR #27742 建置 llama.cpp、接受 GGUF 儲存庫的條款、下載一個裝得下的量化版本，而且別忘了 mmproj 檔案。無論哪種情況，拒絕數字與能力範圍都是儲存庫自己的資料，公佈於模型卡上，且截至本文撰寫時尚未被獨立重現——要誠實地解讀它們，就該把它們視為供應商對自身改動的衡量，而非獨立審計。前述的關卡、授權條款與安全界線，是同一份文字從三個角度切入：這是一件研究工具，而它正是在這個條件下釋出的。

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

請勿與 27B 系列混淆：Qwen3.8-27B-Uncensored是從不同基礎模型進行 abliterated 處理的另一個模型，擁有自己的集合與專屬 runbooks。相同的技術，不同的權重。

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