Qwen3.8 27B 量化基準測試：4 位元等同 BF16，1 位元失效

簡要重點

Qwen3.8 27B 量化至 4‑位元（Q4_K_M，17 GB）的表現幾乎與完整 BF16 模型相同，可輕鬆安裝於 24 GB GPU 上。低於 4 位元的量化會導致效能下降，其中 1 位元（UD‑IQ1_S，6.2 GB）在 GPQA Diamond 上的表現跌至隨機猜測水平，且在程式碼任務上完全失敗。

4‑位元量化表現穩定

結論： 4 位元 Q4_K_M 量化（17 GB）在 GPQA Diamond、IFBench 和 Terminal‑Bench 2.1 上與 BF16 表現一致，是消費級 GPU 的最佳選擇。

完整的 BF16 模型需要約 55 GB VRAM，超出大多數桌面顯示卡的容量。
Q4_K_M 可在 RTX 4090（24 GB）上運行，並保留約 64 k tokens 的 KV‑cache 空間。
在 GPQA Diamond 上，BF16、8 位元、4 位元，甚至 2 位元的分數在統計上無法區分（Wilson 95 % 信賴區間重疊）。僅 2 位元的 UD‑Q2_K_XL 顯示出輕微下降。
IFBench 顯示 BF16 與 2 位元模型之間無可測量差異，儘管上下文窗口限制在約 4 k tokens。
Terminal‑Bench 2.1（89 個代理式程式碼任務，3 小時逾時，xhigh 計算努力，98 k 上下文）記錄 BF16 與 Q4_K_M 的成功率完全相同。2 位元模型略為下降，但仍與中階商業代理（例如 Opus 4.7、Gemini 3.1 Pro）相當。

「17 GB 的 Q4_K_M 在流行的代理式程式碼基準 Terminal‑Bench 2.1 上與完整模型表現一致。它可安裝於 RTX 4090 之類的 24 GB 顯示卡上，仍保留約 64k tokens 的上下文空間。」 – Quesma blog

為何 4 位元有效

量化方法 Q4_K_M（Unsloth v2）比傳統 4 位元方案更能保留權重分佈。
作者使用固定的 F16 KV‑cache（每 32 k tokens 約 2.3 GB），因此記憶體節省僅來自權重壓縮。
更高的推理努力（xhigh）可彌補量化所引入的微小機率偏移，如評論者所指出。

2‑位元量化可用但較弱

結論： 2 位元 UD‑Q2_K_XL（10.7 GB）在大多數基準上仍可運作，但會帶來輕微的效能損失。

與 4 位元相比，GPQA Diamond 分數略有下降。
IFBench 仍顯示無顯著下降，顯示許多指令遵循任務對 2 位元雜訊具有容忍度。
在 Terminal‑Bench 2.1 上，成功率下降數個百分點，但仍處於舊型商業代理的範圍內。
位元使用量增加：對於成功解決的任務，2 位元模型撰寫的位元數比 BF16 多出約 25 %，但推理回合數大致保持不變。

1‑位元量化徹底崩潰

結論： 1 位元 UD‑IQ1_S（6.2 GB）表現嚴重失敗，在 GPQA Diamond 上的分數接近隨機猜測，且在程式碼基準上表現不佳。

分數低於隨機猜測基線，尤其在高推理努力（xhigh）下，長時間生成導致答案為空。
作者的測量結果與 Unsloth 所聲稱的「72 % top‑1 准確率」相矛盾——那缺失的 28 % 對任務成功至關重要。
社群報告（例如 r/LocalLLaMA）也描述相同失敗模式，稱此模型為「腦損傷量化」。

「雖然 2 位元量化在一定程度上可行，但即使是最佳的 1 位元模型對這些基準也毫無用處。」 – Quesma blog

技術洞察

在預訓練的密集模型上進行 1 位元量化本質上不穩定；若未在巨量資料上進行量化感知訓練（QAT），權重表示會崩潰。
一位評論者指出：「在現有預訓練模型上進行量化，幾乎總會在 1 位元時崩潰。」（HN 評論）

基準測試方法

結論： 作者在測試量化前重現了官方 BF16 分數，確保了可靠的基準。

使用的基準：GPQA Diamond（研究生級科學問答）、IFBench（指令遵循）、Terminal‑Bench 2.1（代理式程式碼）。
推理努力等級：low、medium、xhigh（預設）。較高努力通常提升分數，但也增加位元消耗。
硬體：NVIDIA L40S（48 GB）、H100（80 GB）、H200（141 GB）。使用了模式 GPU 租用，總成本約 3 千美元。
模型載入使用 llama.cpp（2026 年 8 月 16 日建置版本），無論權重量化如何，均使用 F16 KV‑cache。
所示信賴區間為 Wilson 95 % 區間；HN 上的評論指出其為保守估計，與跑次間變異無直接關聯。

社群觀點

結論： 評論者大多確認研究結果，補充推理努力的細節，並提出關於 KV‑cache 量化與 GPU 記憶體限制的疑問。

推理努力至關重要： 一位評論者指出，更長的思考時間可彌補量化雜訊，儘管會消耗更多位元。
GPU 記憶體上限： 使用者指出，即使 4 位元模型在長上下文下仍超過 16 GB 顯示卡容量；3 位元或混合精度方案可填補此缺口。
KV‑cache 量化： 有人請求結合模型量化、KV‑cache 量化與上下文大小的基準測試，突顯此領域尚未被探索。
硬體實用性： 多位評論指出，許多消費者擁有 8–12 GB GPU，即使 4 位元也可能太大，無法支援有用的上下文長度。

成本考量

結論： 在雲端 GPU 上執行全規模基準測試成本高昂；4 位元量化雖降低記憶體與運算成本，但與大型 MoE 模型的 API 定價相比，節省幅度有限。

使用了 Modal GPU 租用；總支出約 3 000 美元。
參考：DeepSeek V4 Flash 0731（284 B MoE）在 OpenRouter 上每百萬輸出位元約 0.10 美元，遠低於本地運行密集型 27 B 模型的成本。
4 位元的記憶體節省（約 38 GB 對 55 GB）可讓模型在單一 RTX 4090 上運行，避免多 GPU 設定。

實用建議

結論： 對於大多數本地工作負載，建議使用 4 位元 Q4_K_M 量化；2 位元適用於資源有限的環境；完全避免 1 位元量化。

選擇能適配您 GPU 的最高量化等級，同時保留所需 KV‑cache 大小以支援您的上下文窗口。
若發現微小準確率下降，將推理努力設為 xhigh；預期位元使用量會增加。
監控 KV‑cache 記憶體——即使使用 4 位元模型，32 k 位元的快取仍消耗約 2.3 GB；更長的上下文可能需要更大 GPU。
若需在 16 GB 顯示卡上支援 >64 k 位元，可考慮混合精度或 3 位元方案（本基準未涵蓋）。
除非在巨量資料上進行量化感知訓練，否則完全避免 1 位元量化，這對大多數使用者目前不切實際。

結語

Qwen3.8 27B 的量化在4 位元以下仍具實用性，在多種任務上提供與 BF16 相當的品質，且可安裝於消費級 GPU 上。效能曲線呈非線性：從 BF16 到 4 位元變化極小，2 位元略有下降，1 位元則徹底崩潰。採用量化——特別是精心設計的 Q4_K_M 版本——可讓大型語言模型在本地部署時不犧牲能力。