一張 Qwen3.8-27B-Uncensored 基準測試報告的標題卡片,顯示拒絕率儀表從標記為 Base 的面板上的紅色 99% 急劇下降至標記為 Uncensored 的面板上的綠色 0%,右側面板上有被劃掉的盾牌圖示,其下方有一條水平線,寫著能力在正負 1.3 個百分點以內。
Guides & Insights

Qwen3.8-27B 無審查基準測試:拒答率崩潰,能力保持

作者

Rowan Sterling

發佈日期

最新模型 · 20查看全部模型
基準測試:Artificial Analysis · 每日更新
返回全部文章

的基準測試故事Qwen3.8 27B Uncensored (Aggressive)——即Qwen3.8 27B的 abliterated 版本,於 2026 年 8 月 15 日以 FP8 檢查點形式發布,並於 8 月 16 日發布 GGUF 版本——重點不在於它變得更強,而在於它不再拒絕回答。模型卡片顯示,有害提示的拒絕率從基礎模型的 64–99% 降至 abliterated 版本的 0–6%(關閉思考時),開啟思考時則為 1.7% 或以下;同時,所有能力基準測試的結果都落在基礎模型 ±1.3 分以內,WikiText-2 困惑度為 6.96。如果你來這裡是為了 qwen uncensored 基準測試,那些就是頭條數字:它不是更聰明的模型,而是一個不拒絕回答的模型。

這個區別很重要,因為大多數在「未審查基準」中排名居前的內容,不是一份單薄的效能分數清單,就是宣稱模型「更好」的炒作文章。而這兩者都不是 abliteration(消融法)在做的事。本文將帶領讀者檢視實際測量到的數據——拒絕崩塌、過度拒絕、能力保留與困惑度——以及產生這些數據的方法,還有在動手碰觸權重之前,你應該先閱讀的安全邊界。

未經審查的基準測試總覽實際上衡量的究竟是什麼

一般的模型評測只報告一個軸線:能力——MMLU、GSM8K、程式設計、推理。abliterated 模型的有趣之處在於另一個軸線,而「uncensored」標籤的全部意義就是安全軸線移動了。因此,對Qwen3.8-27B-Uncensored-FP8而言,有用的問題不是「它更聰明嗎?」而是「移除拒絕機制付出了什麼代價,以及移除得有多徹底?」

三組數字必須放在一起看。有害提示基準上的拒絕率——模型多常拒絕;基線越高,移除就越明顯。良性提示上的過度拒絕——模型多常錯誤拒絕無害請求;對所有人來說,越低越好。以及能力保留——該編輯是否讓模型退化。只輸出能力分數的基準摘要,是在回答錯誤的問題。

方法:abliteration 是一種權重編輯,而非微調。

abliteration 與社群「越獄」套件的差異在於變更所在的位置。提示層級的越獄包覆輸入;abliteration 則編輯權重。此處的方法是 Arditi 等人(2024)的論文《Refusal in Language Models Is Mediated by a Single Direction》。其核心發現是,許多模型的拒絕行為是由殘差流中的單一方向所驅動——只要估算出該方向並將其移除,模型便無需重新訓練就會停止拒絕。

具體來說,這張模型卡描述了從巨量激活遮蔽(massive-activation-masked)的平均差異中估計一個拒絕方向:在第 38 層(round(0.6 × 64)),以有害(harmful)減去無害(harmless)的最後一個 token 殘差,其中有害集合使用 AdvBench,無害集合使用 Alpaca。這個編輯是一個正交化,W′ = W − r(rᵀW),以 float32 計算,並套用於 131 個殘差寫入矩陣——注意力輸出投影、線性注意力輸出投影、MLP 下投影,以及一個嵌入行空間。沒有執行任何訓練步驟;視覺塔保持原樣未動;MTP 推測解碼頭也被一致地消融。這就是能力得以留存的原因:移除一個方向遠比微調模型使其服從要溫和得多。

拒絕崩潰:數字

在 vLLM 服務的 FP8 版本上測量,並發佈於 Hugging Face 模型卡(2026-08-15),有害提示基準測試的拒絕率從基礎版的 64–99% 降至未審查版(關閉思考)的 0–6%:

• AdvBench — 99.0% → 0.0%

• JailbreakBench (有害) — 94.0% → 0.0%

StrongREJECT — 97.3% → 2.0%

• HarmBench(標準)— 98.7% → 2.7%

• MaliciousInstruct — 99.0% → 0.0%

• SimpleSafetyTests — 64.0% → 6.0%

• 禁止問題 — 73.3% → 4.7%

在啟用思考功能的情況下,拒絕率基本上趨近於零——在AdvBench上為1.7%,在其餘大多數測試上為0.0%。模型卡上附了一項誠實的但書:30–50%的回答仍會在前言加上一段簡短免責聲明。這是訓練產生的痕跡,並非拒絕——模型確實回答了,只是開場有所保留。這讀起來像是摩擦,而非安全機制。

A two-column scoreboard comparing harmful-prompt refusal rates for the base Qwen3.8 27B versus the abliterated Qwen3.8-27B-Uncensored build across seven benchmarks, the base column reading 99.0, 94.0, 97.3, 98.7, 99.0, 64.0 and 73.3 percent and the uncensored column reading 0.0, 0.0, 2.0, 2.7, 0.0, 6.0 and 4.7 percent, with a footer noting the data is from the Hugging Face model card, measured on the vLLM-served FP8 build, 2026-08-15.

過度拒答同樣是問題。

較少被公開的數字位於安全軸的另一端。在 XSTest-safe —— 250 個良性的提示詞,這些對齊的模型有時會錯誤拒絕 —— 基礎模型過度拒絕的比例為 5.6%。未經審查的版本過度拒絕的比例為 0.4%。移除拒絕方向不僅阻止模型拒絕有害請求,也阻止它拒絕那些先前因過度概括而被標記為無害的請求。對於任何建構評估或紅隊工具的人來說,若無拒絕基線正是重點,這是工具上的實際改進,而不是需要為之道歉的副作用。

能力得以保留,而非提升。

这就是“无审查 = 更强”的说法失效的地方。模型卡展示了经消融处理的 FP8 构建版本与官方基础 FP8 在相同脚本和设置下的对比结果:

• MMLU (0-shot) — 84.3% → 84.7%

• GSM8K (CoT) — 90.0% → 88.7%

• MMLU-Pro (CoT) — 77.6% → 76.8%

• CMMLU(0-shot,中文)— 81.4% → 80.8%

Every score lands within ±1.3 points of the base, and WikiText-2 raw perplexity comes in at 6.96 — the card's evidence that language modeling itself did not degrade. The honest reading: abliteration is close to capability-neutral on this architecture. You are not getting a better model; you are getting the same model without the refusal behavior.

A scoreboard for the Qwen3.8-27B-Uncensored capability retention results: MMLU 84.3 to 84.7, GSM8K 90.0 to 88.7, MMLU-Pro 77.6 to 76.8, CMMLU 81.4 to 80.8, every score within plus or minus 1.3 points of the base, with a highlight panel showing WikiText-2 perplexity 6.96 and over-refusal on XSTest-safe falling from 5.6 percent to 0.4 percent, and a footer noting the source is the Hugging Face model card, measured on the vLLM-served FP8 build.

同樣的警示也適用於更廣泛的生態系統:社群建置版本上宣稱的「無損無審查」值得以懷疑的眼光看待。在 Hugging Face 上一個 4B 開放權重版本的第三方比較中發現,宣稱無損的技術實際上讓 TruthfulQA 掉了約 7 個百分點、Lambada 掉了約 4 個百分點,而其 HarmBench 攻擊成功率達 100%;另外兩種方法則分別為 99.2% 和 95.5%。此外,在另一個版本上進行的激進測試雖然達到了零拒絕,卻產生了語無倫次的文字沙拉,因此最終發布的版本退回到較溫和的逐層參數。Abliteration 的結果因方法而異——這些數字特指 FP8 版本的模型卡資料。

卡片未聲稱的內容

在引用這些數字之前,請先閱讀方法論。該模型卡將其拒絕測量標記為「僅供參考,並非 LLM 評審/可發表等級的數字」:拒絕是透過基於規則的開場語句分類器來判斷,並設有一個獨立的「警示」類別,用來收納那些雖已遵從但前置了免責聲明的回答。這些基準測試僅限於純文字,針對 vLLM 伺服化的 FP8 建置版本執行,且僅使用語言模型;能力測試套件則採用標準評測腳本。正確的理解框架是:這是供應商自行測量的數據,可依據已發布的模型卡重現——並非獨立的第三方評測,也不涉及對 GGUF 建置版本的宣稱;該 GGUF 版本是為 llama.cpp 發布的量化版本,應另行評估。

安全邊界

這是無法迴避的部分。一個經過去拒斥化(abliterated)處理的模型,其拒絕機制已被大幅移除。具體而言:它會順從基礎Qwen3.8 27B原本會拒絕的有害、不道德或非法請求,且沒有實質的內建防護措施。合法的用途僅限於研究——可解釋性(研究拒絕方向是如何被編碼的)、AI安全與拒絕機制研究、紅隊測試(以試圖繞過防護的輸入來探測模型),以及穩健性評估。它基於 Apache 2.0 授權釋出(繼承自基礎模型),嚴格作為研究產物。您需對您的使用方式及其所產生的所有內容承擔全部責任與法律責任。請勿在未設置您自己的安全、內容審核與濫用防護層的情況下將其部署給終端使用者或投入生產環境——而對於任何生產或消費端用途,標準的 Qwen3.8 27B 才是您真正想要的模型。

當查閱未經審查的基準是錯誤之舉

如果你的問題是「哪個模型在數學或編碼方面最強?」,那你讀錯數字了——未審查版本並非能力升級。如果你的應用程式需要拒絕有害請求,這個模型正是你最不想要的。如果你要出貨產品,請不要在「消除拒絕」的檢查點上建置。如果你真正追求的是越獄,那完全是另一回事——提示詞層級的套件不屬於本文討論的權重層級干預,也不是這篇文章的主題。本文的基準數據只為一個狹窄而合法的問題存在:移除拒絕機制對 Qwen3.8 27B 的影響,經實測量。

如何訪問它

兩個建置版本都已上架 Hugging Face,採用 Apache 2.0 授權:orcarouter/Qwen3.8-27B-Uncensored-FP8(block-FP8 E4M3,權重約 30.9 GB,以標準 vLLM FP8 核心路徑提供服務,完整保留 262K 上下文、工具、思考與 MTP 功能)和orcarouter/Qwen3.8-27B-Uncensored-GGUF(F16 加上 12 種量化層級供 llama.cpp 使用,其中 Q4_K_M 為 16.8 GB,是 24 GB GPU 的建議預設值)。模型卡位於 OrcaRouter 上,載明定價與基準測試詳細資料——該非審查版本在列表上名為 obsidian/Qwen3.8-27B,輸入每百萬 token 0.40 美元,輸出每百萬 token 4.21 美元,支援 262K 上下文,且僅對安全研究人員、紅隊與 AI 安全研究人員開放存取。

The OrcaRouter model page for obsidian Qwen3.8-27B, showing the uncensored build's 0.40 USD per million input and 4.21 USD per million output pricing, a 262K token context window, a released August 15 2026 label, and the researcher-access gating note.

底線

Qwen 無審查基準測試回答的是一個狹隘的問題,而答案很明確:透過 abliteration 對 Qwen3.8 27B 進行去拒答處理,能力僅在 ±1.3 分內波動,同時對有害提示的拒答率從 64–99% 崩跌至 0–6%,過度拒答率從 5.6% 降至 0.4%,困惑度維持在 6.96。請將這些數字理解為「不會拒答」,切勿解讀為「更強大」。就可解釋性、安全性和紅隊研究而言,這正是模型卡所描述的用途。但對於任何面向使用者的情境,此模型從根本上就是錯誤的選擇。

僅供合法研究使用,權重以 Apache 2.0 授權發布於 Hugging Face — orcarouter/Qwen3.8-27B-Uncensored-FP8(適用於 llama.cpp 的 GGUF 版本位於 orcarouter/Qwen3.8-27B-Uncensored-GGUF)。

© 2026 OrcaRouter

推理服務商

經營推理平台?讓您的模型上架 OrcaRouter。

providers@orcarouter.ai

加入我們的社區

Discordsupport@orcarouter.aiXGitHubYouTube