Select Page
Qwen3.8-27B 本地部署教學:16GB 顯卡怎麼選,llama.cpp 接 Hermes Agent

Qwen3.8-27B 本地部署教學:16GB 顯卡怎麼選,llama.cpp 接 Hermes Agent

Qwen3.8-27B 把文字、圖片、影片、程式設計與 Agent 工作流放進同一個稠密模型,對想把 AI 留在本機的人來說,這是一個能力和硬體成本相對平衡的新選擇。

16GB 顯卡不要直接選 Q4_K_M,因為 15.9 GiB 只是主模型檔案,還沒有算約 0.86 GiB 的視覺投影模型、KV Cache 與執行環境。比較實際的選擇是 Q3_K_M 或 UD-Q3_K_XL,再從 8K 上下文開始測試。8GB 顯卡雖然可以用極低位元量化搭配系統記憶體卸載,但不等於 27B 多模態模型能完整放進 8GB 顯示記憶體。

Qwen3.8-27B 是什麼

Qwen3.8-27B 官方模型採用 Apache 2.0 授權,是一個 27B 參數的稠密視覺語言模型,它不是只會聊天的純文字模型,而是原生理解圖片與影片,也把程式設計、專業工作、研究和長時間 Agent 任務列為主要能力。

  • 27B 稠密模型,64 層,Hidden Dimension 為 5120
  • 原生支援圖片與影片理解
  • 原生上下文長度 262,144 tokens,可透過 YaRN 延伸到 1,000,000 tokens
  • 支援思考與非思考模式,也能用 reasoning_effort 調整推理深度
  • 訓練時加入多步 MTP,執行環境支援時可用於推測解碼

如果你正在比較本地模型,建議先看站內的Qwen 3.6 的 27B、35B、MXFP8 與 NVFP4 比較,Qwen3.8-27B 延續 27B 稠密模型的定位,但多模態、Agent 執行和思考控制都更完整。

MTP 和 noMTP 差在哪裡

MTP 是 Multi-Token Prediction,一般自迴歸模型每次產生一個 token,MTP 會另外預測後續多個候選 token,再由主模型驗證,推理框架支援推測解碼時,可以減少逐 token 等待的成本,提升生成速度。

Qwen3.8-27B 的官方架構包含 MTP,Unsloth 的 Qwen3.8 指南也提供 MTP 量化版本,noMTP 通常是社群為了相容性或降低額外負擔而移除 MTP 預測頭的版本,你的 llama.cpp 太舊、載入失敗,或記憶體非常緊時,可以把 noMTP 當作相容性選項。新版推理環境能正常使用 MTP 時,則優先保留。

16GB 顯卡該下載哪一個 GGUF

可用記憶體建議量化主模型大小實際建議
8GBUD-IQ2_XXS約 8.4 GiB仍需系統記憶體卸載,不建議當作完整多模態體驗
12GBUD-IQ2_M 或 Q3_K_S約 9.6 到 11.7 GiB使用短上下文,接受較明顯的量化損失
16GBQ3_K_M 或 UD-Q3_K_XL約 12.9 或 12.5 GiB最實際的平衡,先用 8K 上下文
24GBQ4_K_M 或 Q5_K_M約 15.9 或 18.5 GiB能保留較好的品質,也有空間給視覺與 KV Cache
32GBQ6_K 或 Q8_0約 21.3 或 27.1 GiB適合重視品質與較長上下文的使用者
檔案大小依 Unsloth Hugging Face 儲存庫計算,實際記憶體還要加上視覺投影模型、KV Cache 與執行環境
Qwen3.8-27B 常見 GGUF 主模型檔案大小比較圖
主模型從 8.4 GiB 的 2-bit 到 27.1 GiB 的 Q8_0,數字不包含額外執行記憶體

Q4_K_M 的檔案約 15.9 GiB,看起來很接近 16GB,但視覺功能還需要 mmproj-F16.gguf,檔案約 0.86 GiB,再加上 KV Cache 後,16GB 顯卡通常沒有足夠餘裕。若只跑文字、上下文很短,而且願意部分卸載到系統記憶體,IQ4_XS 可能可以啟動,但這不是我會給一般使用者的預設建議。

量化位元越低,檔案越小,但指令遵循、長文本穩定性、程式正確率和視覺判斷都可能下降。16GB 使用者如果重視穩定性,有時候選較小參數模型的 4-bit 或 8-bit,會比硬塞 27B 的 2-bit 更實用。

用 llama.cpp 在本機啟動

個人電腦要跑 GGUF,llama.cpp 仍然是很直接的底座。Windows 使用者可以從 llama.cpp Releases 下載對應版本,NVIDIA 顯卡選 CUDA,AMD 顯卡可用 Vulkan,沒有獨立顯卡則選 CPU 版本,框架定位和差異可以延伸閱讀vLLM、SGLang、llama.cpp、MLX 與 Ollama 比較

一 下載主模型與視覺投影模型

pip install -U "huggingface_hub[cli]"

hf download unsloth/Qwen3.8-27B-GGUF \
  Qwen3.8-27B-Q3_K_M.gguf \
  mmproj-F16.gguf \
  --local-dir Qwen3.8-27B-GGUF

24GB 顯卡可以把 Q3_K_M 換成 Q4_K_M。只處理文字時可以先不載入 mmproj,等基本對話穩定後再加入視覺功能。

二 啟動 OpenAI 相容端點

llama-server \
  --model Qwen3.8-27B-GGUF/Qwen3.8-27B-Q3_K_M.gguf \
  --mmproj Qwen3.8-27B-GGUF/mmproj-F16.gguf \
  --host 127.0.0.1 \
  --port 8080 \
  --ctx-size 8192 \
  --n-gpu-layers 99 \
  --jinja \
  --chat-template-kwargs '{"reasoning_effort":"medium"}'

Windows 請把執行檔改成 llama-server.exe。若出現記憶體不足,先把上下文從 8192 降到 4096,再考慮換更小的量化。不要一開始就把 262K 全開,長上下文的 KV Cache 會快速增加記憶體需求。

三 測試 API

curl http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"Qwen3.8-27B","messages":[{"role":"user","content":"請用繁體中文列出三個本地部署注意事項"}]}'

能收到 JSON 回應,就代表本地端點已經可以交給其他工具使用,想把開發環境完全留在本機,也可以參考Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本環境

接到 Hermes Agent

llama-server 啟動後,可以在 Hermes Agent 的模型提供方加入本地自訂端點,Base URL 填入 http://127.0.0.1:8080/v1,如果介面要求 API Key,可以填一個只供本機識別的非空字串,模型清單出現 Qwen3.8-27B 後,就能把它用在網站製作、檔案處理、程式生成與瀏覽器檢查等 Agent 任務。

本地模型接 Agent 的價值在於資料不用先送到外部 API,也能降低大量反覆呼叫的成本。不過模型一旦拿到終端機、瀏覽器和檔案權限,風險也會跟著放大。Hermes 的代理層與 LINE 整合可以延伸閱讀Hermes Proxy 與 Hermes Agent 支援 LINE

程式、視覺與 Agent 能力怎麼看

一個單檔 HTML 飛行遊戲可以同時產生畫面、操作、儀表與聲音,代表 27B 模型已經能完成有一定複雜度的前端原型,圖片計數測試也能辨識出 25 根筷子,並區分 6 根彩色與 19 根銀色,接到 Agent 後,還能建立帶搜尋、排序與模型卡片的網站,再開啟瀏覽器檢查介面。

這些結果適合當作能力檢查,不適合直接當成通用 benchmark,單一提示、單一圖片與單一硬體都可能讓結果偏高或偏低。真正要採用前,應該用自己的程式庫、文件、圖片和 Agent 權限做一組固定測試,記錄成功率、速度與記憶體峰值。

無審查版本不是官方安全模式

所謂無審查或 Uncensored 版本通常是社群修改、微調或去除拒答傾向的衍生模型,不是 Qwen 官方提供的安全開關,它比較少拒絕,不代表答案更正確,也不代表可以放心交給有系統權限的 Agent。

  • 先在沒有正式帳密與重要檔案的環境測試
  • 工具採用允許清單,不要直接給完整終端機與管理員權限
  • 寫檔、執行命令、付款與對外發布都要保留人工確認
  • 本地 API 預設只綁定 127.0.0.1,不要直接暴露到網際網路
  • 保存工具呼叫紀錄,發生異常時能回溯

如果用途只是寫作或私人角色扮演,可以把衍生模型放在沒有工具權限的聊天環境。需要操作檔案、瀏覽器或伺服器時,優先使用官方模型並限制權限,通常會更穩妥。

我的選擇建議

16GB 顯卡從 Q3_K_M、8K 上下文和官方版本開始。24GB 顯卡可選 Q4_K_M,並保留足夠空間給 mmproj 與 KV Cache。50 系列 Blackwell 顯卡如果要做正式服務,可以研究 NVFP4 與 vLLM。一般個人使用者則先用 GGUF 和 llama.cpp,把模型穩定跑起來,再決定是否需要 Hermes Agent、長上下文或 MTP。

Qwen3.8-27B 的重點不是單純追求更大模型,而是把多模態、程式能力和 Agent 執行放進個人可負擔的硬體範圍。選對量化、控制上下文、限制工具權限,才是本地部署真正能長期使用的關鍵。

FAQ

MTP 一定比較快嗎

只有推理框架正確支援推測解碼時才會發揮效果。框架版本、硬體與批次大小都會影響實際速度,不能只看檔名判斷。

可以用 Ollama 或 LM Studio 嗎

可以,只要版本已支援 Qwen3.8 架構與對應 GGUF。想控制 MTP、mmproj、KV Cache 與細部參數時,llama.cpp 通常更透明。

本地模型接 Hermes Agent 安全嗎

模型資料可以留在本機,但工具權限仍然需要管理。使用 127.0.0.1、工具允許清單、人工確認與執行紀錄,可以大幅降低風險。

參考資料

NVFP4 與 MTP 是什麼?Qwen3.6 本地推理加速重點整理

NVFP4 與 MTP 是什麼?Qwen3.6 本地推理加速重點整理

NVFP4 和 MTP 最近被放在一起討論,原因很簡單:本地大模型推理開始從「能不能放進顯存」進入「怎麼把記憶體搬運成本壓到最低」的階段,Unsloth 釋出的 Qwen3.6 NVFP4 quants 主打 27B 模型可在 24GB VRAM 上運行,35B-A3B 在 B200 上可達 17,561 tok/s,並宣稱相對 NVIDIA NVFP4 quant 有 2.5 倍速度提升。

這些數字很吸引人,但不能直接翻譯成「買 RTX 5090 就一定變快」。真正該看的,是 NVFP4 和 INT4 的格式差異、MTP 如何降低推理瓶頸,以及消費級 Blackwell 現階段為什麼可能吃不到企業級 B200 的完整紅利。

先講結論

  • NVFP4 是 4 位元浮點量化,不是傳統 4 位元整數量化
  • INT4 的刻度固定,NVFP4 的浮點表示更適合保留權重動態範圍
  • MTP 是多 Token 預測,重點是減少每個 token 都重新搬一次權重的浪費
  • 17,561 tok/s 是特定企業級硬體條件下的吞吐量,不是一般 RTX 50 的保證值
  • 企業部署時,驅動、CUDA、vLLM、llama.cpp、環境變數和自動更新都可能比模型本身更容易出事

如果你之前看過我整理的 Qwen 3.6、MXFP8、NVFP4 比較,這篇可以當成補充版,前一篇偏選型,這篇偏底層原因和部署風險。

NVFP4 和傳統 INT4 差在哪

INT4 是 4 位元整數量化。你可以把它想成一把固定刻度的尺,每一格距離都一樣。問題是神經網路權重分布通常不是均勻的,很多重要數值會擠在接近零的位置,也會偶爾出現比較大的極端值。固定刻度很省空間,但容易犧牲細微權重差異。

NVFP4 則是 4 位元浮點量化,它仍然只用 4 位元,但用浮點格式表達數值,能用有限 bit 描述更大的動態範圍,小數值區域可以保留比較細的變化,大數值區域則用比較寬的範圍表示,這就是為什麼 NVFP4 在某些模型上可以比傳統 INT4 更接近原始權重的行為。

NVFP4 與傳統 INT4 的差異表格
項目NVFP4傳統 INT4
數值格式4 位元浮點4 位元整數
刻度特性動態範圍固定刻度
細節保留較能保留小數值細微權重較易流失
硬體依賴需要 FP4 支援與 kernel 最佳化生態成熟
實務風險新硬體仍看驅動成熟度穩定但精度較受限

這裡要補一個很重要的判斷:NVFP4 不是自動贏 INT4。若硬體、驅動、kernel、推理框架都沒有最佳化,NVFP4 可能反而更慢。格式更先進,不代表你手上的卡和軟體棧已經準備好了。

MTP 為什麼會讓速度暴衝

MTP 是 Multi-Token Prediction,也就是多 Token 預測。傳統自回歸語言模型通常一次產生一個 token。每產生一個 token,都要讀取大量模型權重,再做一次運算。對大模型來說,很多時間不是花在純計算,而是花在權重從顯存搬到運算核心的路上。

MTP 的核心思路,是在一次權重讀取裡嘗試預測多個後續 token。它不是讓模型魔法般跳過推理,而是把原本每一步都要重複付出的記憶體傳輸成本攤薄。當瓶頸主要在顯存頻寬和權重搬運時,這種方式就能明顯提高吞吐量。

Reddit 原始討論裡也有人問 MTP 是否已加入,Unsloth 相關回覆指出 MTP 已經在裡面,並且有說法提到 MTP tensors 已直接內建到 quants 中。這表示使用者不只是拿到一個 NVFP4 量化權重,而是拿到帶有 MTP 加速路徑的版本。

2.5 倍速度提升要怎麼看

這次最容易被誤讀的是「2.5 倍」。Reddit 討論中有人問這個速度提升是不是相對 Q4,Unsloth 回覆脈絡指出,這個比較是相對 NVIDIA 的 NVFP4 quant,而不是拿所有 Q4 或 INT4 實作一起比較。這一點很重要,因為不同量化格式、不同框架、不同 GPU、不同 batch 和 context 設定,都會影響 token/s。

另外,35B-A3B 達到 17,561 tok/s 的數字是在 B200 這類企業級硬體條件下出現。這可以說明 NVFP4 和 MTP 的上限很高,但不代表一般 RTX 50 系列能直接複製。企業採購或本地部署,最怕把資料中心卡的極限數字誤當成桌機卡的常態表現。

為什麼 RTX 50 可能反而沒有變快

同樣叫 Blackwell,不代表所有 Blackwell 都一樣。B200 屬於資料中心路線,軟體路徑和底層 kernel 通常優先被最佳化。RTX 50 消費級卡雖然也有新架構能力,但 SM120 的軟體支援成熟度可能還沒跟上。

Reddit 討論中有人提到,消費級 Blackwell 的 NVFP4 利用率仍可能不理想,也有人實測 NVIDIA NVFP4 Qwen3.6 27B 對比原本 INT4 時,token 生成速度不但沒有提升,還有下降的案例。這些不是說 NVFP4 沒用,而是說「硬體支援」和「軟體真的最佳化」中間有一段距離。

如果你正在看 RTX 5090、5080 或 5060 Ti 類配置,不要只看 NVFP4 四個字。你要確認推理框架是否真的支援你的 GPU、驅動和 CUDA 是否符合要求、實際模型是否有對應 kernel,還要看你的工作負載是 prompt processing 重,還是 token generation 重。

企業部署最容易踩到的不是模型,而是環境

這類極限加速模型最怕直接上正式環境。逐字稿和社群討論都提到一個共通風險:推理框架和底層格式更新太快,vLLM、CUDA、驅動、模型權重、環境變數任何一層沒對上,都可能變慢甚至崩潰。

我會把部署流程拆成四步。第一步先在單機沙盒測模型能不能正常跑。第二步測固定 prompt、長上下文、工具調用和 agent loop。第三步鎖定版本,關掉正式環境自動更新。第四步再進入內部 PoC。這和我之前整理的 本地大模型推理框架選型 是同一個邏輯,速度只是其中一個指標,穩定性才決定能不能上線。

  • 正式環境不要開自動更新
  • 先鎖定 CUDA、driver、vLLM 或 llama.cpp 版本
  • 不要把 B200 benchmark 直接套到 RTX 50 採購決策
  • 工具調用和 agent 流程要單獨壓測
  • 用 24GB VRAM 跑 27B 可以測,但不代表企業就一定該選最大模型

為什麼 9B 和 GGUF 反而更實用

當大家看到 27B 可塞進 24GB VRAM,甚至 35B-A3B 跑出極限吞吐量,很容易以為模型越大越好。但真正落地時,很多企業只需要工單分類、客服輔助、內部文件查詢、簡單自動化。這些任務未必需要 27B 或 35B。

9B 模型的價值在於部署門檻更低,可以放進 12GB 或 16GB 顯卡,還能保留更多 VRAM 給上下文和工具調用。GGUF 則讓 llama.cpp 這類本地推理路線更容易接上 CPU 或低階硬體。這也是為什麼社群一邊討論 17,561 tok/s,一邊仍然敲碗 9B 和 GGUF 版本。

對中小企業來說,我會優先問三個問題。你的資料是否需要完全本地化,你的任務是否真的需要大模型,你是否有能力維護最新 GPU kernel 和推理框架。如果答案不明確,小模型加穩定部署,通常比追逐極限跑分更務實。

我的判斷

NVFP4 和 MTP 很重要,因為它們代表本地 AI 推理正在處理真正的瓶頸:顯存容量、權重搬運、吞吐量和模型品質之間的平衡。NVFP4 解決的是低 bit 量化下如何保留更多數值動態範圍,MTP 解決的是一次只吐一個 token 帶來的記憶體傳輸浪費。

但我不會把它解讀成「RTX 玩家立刻起飛」。比較健康的看法是:資料中心硬體已經看到 NVFP4 和 MTP 的上限,消費級硬體還在等軟體棧補齊。現在要採購或部署,應該把 PoC、版本鎖定、框架支援和真實任務測試放在跑分前面。

真正值得期待的是,這些技術成熟後,27B 不再只能放在機房裡,9B 和 GGUF 也能讓更小的團隊取得足夠好用的本地 AI。極限跑分很好看,但真正改變企業日常的,通常是穩定、便宜、好維護的那一條路。

延伸資源

FAQ

NVFP4 是什麼?

NVFP4 是 NVIDIA 4 位元浮點量化格式。它和 INT4 一樣節省記憶體,但用浮點方式表達數值,較適合保留神經網路權重中的動態範圍。

NVFP4 和 INT4 最大差異是什麼?

INT4 是固定刻度的整數量化,NVFP4 是 4 位元浮點量化。前者生態成熟,後者更依賴硬體 FP4 支援和軟體 kernel 最佳化。

MTP 是什麼?

MTP 是 Multi-Token Prediction,多 Token 預測。它讓模型在一次權重讀取中嘗試預測多個後續 token,降低記憶體傳輸瓶頸,提高吞吐量。