Qwen3.8-27B GGUF：為您的 GPU 選擇哪種量化版本？

下載 unsloth/Qwen3.8-27B-GGUF 套件，並把檔案對應到你實際擁有的顯示卡。這就是完整答案：24GB 顯示卡（RTX 4090 或 3090）應選用 Q4_K_M（17.1GB）；16GB 顯示卡應選用 IQ4_XS（15.7GB）（若想要更多上下文餘裕，可選 13.8GB 的 Q3_K_M）；12GB 顯示卡則受限於 2-bit 檔案，UD-IQ2_XXS（9.0GB），而這是必須清楚意識到的取捨。Qwen3.8 27B——阿里巴巴的稠密型 270 億參數模型，Apache 2.0 權重於 2026 年 8 月 13–14 日釋出——在本地運行的成本異常低廉，因為其混合注意力機制只快取 64 層當中的 16 層，所以在 24GB 顯示卡上，4-bit 量化可輕鬆承載 32K–64K tokens 的上下文。而 GGUF 是唯一零邊際成本的路徑：不需要 API 金鑰、沒有逐 token 計費、資料也不會離開你的機器。

{{1}}關於來源：架構、上下文視窗與授權均屬官方資料，取自 Hugging Face 上的 Qwen3.8 27B 模型卡，於 2026 年 8 月 15 日核實。{{/1}} {{2}}GGUF 檔案大小來自 unsloth 與 ggml-org 的 GGUF 儲存庫，日期同上。{{/2}} {{3}}每張 GPU 的 VRAM 建議用量為 unsloth 的官方建議。{{/3}} {{4}}KV 快取位元組估算與每秒 token 數為釋出後最初幾天的社群實測數據，並非廠商規格。{{/4}} {{5}}下方列出的每項基準測試皆為 Ali​baba 自行發布且未經重現的結果。{{/5}}

檔案選擇器，每個 quant 一行

• UD-IQ2_XXS — 9.0GB — 唯一適合 12GB 顯示卡的舒適選擇；預期會有明顯的品質損失。

• UD-Q2_K_XL — 10.7GB — 12GB 顯示卡，幾乎沒有剩餘的上下文空間。

• Q3_K_M — 13.8GB — 適合想要上下文餘裕的16GB顯示卡。

• IQ4_XS — 15.7GB — 16GB 顯示卡：能完整放入的最大量化版本。

• Q4_K_M — 17.1GB — 24GB 顯示卡的甜蜜點，也是本文推薦的檔案。

• Q5_K_M — 19.8GB — 24GB，犧牲上下文空間以換取小幅度的品質提升。

• Q6_K — 22.9GB — 若精打細算可塞進24GB；接近無損。

• Q8_0：29.0GB 至 32GB，可雙卡拆分或使用 CPU 卸載。

• BF16 — 54.7GB — 適用於伺服器顯示卡與高記憶體 CPU 配置；參考精度。

有兩個包、兩種 Q4_K_M 大小：unsloth 的是 17.1GB；ggml-org 的是 19.0GB。unsloth 包對其 UD-* 檔案使用 Dynamic V3.0（預覽版）量化，也是大多數本機應用程式預設使用的版本；ggml-org 包則隨附標準 K-quants，以及用於推測解碼的獨立 multi-token-prediction 表頭。任一種 Q4_K_M 都可以用——差異只在幾百 MB 和 MTP 檔案。

為何這個27B能裝在比多數卡片更小的卡片上

Qwen3.8 27B有64層，但只有16層使用完整注意力。其餘48層使用Gated DeltaNet線性注意力，它保持固定大小的循環狀態，而不是不斷增長的鍵值快取。模型卡本身的區塊布局為每1×(Gated Attention → FFN)搭配3×(Gated DeltaNet → FFN)——即3:1的混合比例。實際效果是：KV快取大約只有傳統27B密集模型在相同上下文長度下所需量的四分之一。本週的社群測量顯示，快取在8K上下文時約0.5GB，32K時約2.0GB，而在完整的262K原生視窗下則為16.4GB。這顛覆了常見的建議——你大部分的VRAM預算都花在權重上，而不是上下文，而且一張24GB的顯示卡就能輕鬆跑Q4_K_M，支援64K–96K上下文。你可以使用llama.cpp的--cache-type-k旗標進一步縮小快取，它會對快取本身進行量化。

三個第一天就會絆倒你的陷阱

• 舊版 llama.cpp 會拒絕載入該檔案。GGUF 註冊了新的 qwen35 架構，因此你需要最新版本——發布週之前的任何版本都會以架構錯誤拒絕載入。請先更新 llama.cpp，再進行下載。

• 模板陷阱。官方的 Jinja 聊天模板會將每一輪助理回覆都包進 think 區塊中，即使推理軌跡是空的也一樣，這會在多輪對話中產生巢狀區塊與被截斷的歷史紀錄——看起來就像模型忘了你說過的話。請使用 --jinja 執行 llama.cpp，並優先選擇附帶修正版 chat_template.jinja 的套件。

• 視覺功能需要單獨的檔案。 文字開箱即用；圖片和影片則會靜默地不起任何作用，除非你另外載入 mmproj 投影器（約 0.9GB）。它未列在 unsloth 的 GGUF repo 頁面上——請從基礎儲存庫或 ggml-org 包中取得。若你打算將文件或螢幕截圖餵入模型，請在伺服器指令後加上 --mmproj。

執行它：命令

llama.cpp，一旦你有了目前的建置版本：

llama-server -m Qwen3.8-27B-Q4_K_M.gguf --ctx-size 32768 --n-gpu-layers 99 --jinja --cache-type-k q8_0

並添加 --mmproj Qwen3.8-27B-mmproj-bf16.gguf，如果你需要視覺功能。

Ollama，如果你要加入程式庫：先執行 ollama pull qwen3.8:27b，然後執行 ollama run qwen3.8:27b。LM Studio 和 Unsloth Desktop 會自動套用聊天模板並自動處理 RAM 卸載——對初次執行來說，這是最不費事的路徑。

本地 vs API：誠實的經濟學

The GGUF是免費途徑：零邊際成本、無速率限制、資料不會離開你的機器。但以絕對成本而言，它並非便宜途徑——你需要提供24GB GPU（二手RTX 3090或全新RTX 4090，外加電費），而在12GB顯示卡上跑2-bit檔案則是一種大打折扣的體驗。

「API 路由之所以存在，{{1}}是因為權重採用 Apache 2.0 授權{{/1}}，{{2}}所以提供服務的邊際成本接近於零，任何人都能自行架設{{/2}}。Qwen3.8 27B 現已在 OrcaRouter 上線，{{3}}每百萬輸入 token 收費 $0.33、每百萬輸出 token 收費 $2.40{{/3}}——{{4}}供應商列表價格直接轉傳，不加任何加成{{/4}}——而且由於權重是開放的，還有一個{{5}}受速率限制、每個請求收費 $0 的免費方案{{/5}}，{{6}}當你超過其上限時{{/6}}會回傳 HTTP 429。以每月 1,000 萬 token、其中 70% 為輸入的代表性用量為例，付費方案約需 $9.51。如果你已經有 GPU，本機部署在成本上勝出；如果沒有，就業餘專案而言，租用 token 比買一張顯示卡更划算。」

當此建議有誤時

Q4_K_M 在 24GB 上是預設值，而非通用答案。在以下情況請選擇其他方案：

• 您在伺服器或工作站上需要最高品質 — Q8_0 29GB 或 BF16 54.7GB，搭配 CPU 與 RAM 卸載，而非 4-bit 檔案。

• 您使用的是 Blackwell RTX 50 系列顯示卡 — NVFP4 變體在相同的 24GB VRAM 中速度約快 1.5 倍，並使用 FP8 KV 快取以支援更長的上下文。在 5090 上，NVFP4 勝過此型號上的任何 GGUF。

• 你需要完整的 262K 上下文——在權重之外，還需預留約 16GB 的快取；這會讓 24GB 的顯示卡降至 Q3_K_M，或迫使 KV 量化。

• 你依賴推測性解碼 — 請選擇 ggml-org 套件，它保留了多 Token 預測頭；有些量化版本會將其移除，以節省約 0.5GB。

• 你只有12GB — 誠實的回答：以 2-bit 部署的 27B 模型，表現明顯比正常部署的同一模型差。在投入本地 2-bit 設置之前，先試試免費的 API 方案；如果效果夠好，GGUF 可以等到硬體升級後再考慮。

底線

Qwen3.8 27B 是少數能在 24GB 顯示卡上無妥協運行的 27B 模型：17.1GB 的 Q4_K_M 下載檔、最新的 llama.cpp 版本，以及便宜到長上下文幾乎不花費任何代價的 KV 快取。如果你擁有該硬體，就下載那個檔案；請記得視覺功能需要單獨的 mmproj，並預期多輪對話第一次看起來像失憶時，那是模板陷阱。如果你沒有該硬體，同一個模型提供 $0.33/$2.40 的 API，並有免費的限速額度，所以沒有理由去跑一個你不滿意的 2-bit 檔案。GGUF 是免費途徑，但它已不再是唯一的途徑。