GGUF on KnightLi的博客

Qwen3.6-35B-A3B 越獄版本地部署：無審查 GGUF、llama.cpp 與安全邊界

Sun, 24 May 2026 23:52:16 +0800

零度博客最近介紹了一款熱度很高的本地模型：Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive。原文把它稱為「越獄版」「無審查」開源模型，並給出了 GGUF 量化包、llama.cpp 啟動方式和 Agent 對接思路。

這類模型值得關注，但更適合冷靜理解：它的重點不只是「限制少」，而是把幾個本地 AI 關鍵能力放到了一起：

MoE 架構下的 35B 級模型。
GGUF 量化後可在消費級顯卡上運行。
透過 llama.cpp 提供 OpenAI API 相容介面。
搭配 mmproj 支援多模態視覺輸入。
可以接入 Hermes、OpenClaw 等本地 Agent 工具。

如果你關心本地模型，這篇更值得看的不是「越獄」噱頭，而是它代表的趨勢：本地模型正在從「能聊天」走向「能接入工具、能看圖、能做 Agent 後端」。

這個模型是什麼

原文提到的模型全名是：

`1`	`Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive`

從名字可以拆出幾個關鍵資訊：

Qwen3.6：基於 Qwen 系列模型。
35B：總參數規模約 35B。
A3B：每次推理啟用參數約 3B，屬於 MoE 思路。
Uncensored / Aggressive：經過更少安全限制或更激進風格調整的版本。
GGUF：面向 llama.cpp 等本地推理工具的量化格式。

這裡要特別注意：Uncensored 並不等於「更可靠」。它通常意味著模型更少拒答，也更可能產生不受約束、未經事實核驗或有風險的內容。對技術研究來說可以實驗，但不適合直接接入公開服務、生產系統或無人值守任務。

為什麼 35B 模型還能在本地跑

很多人看到 35B 會以為必須用伺服器或高階多卡機器。原文強調的關鍵點是：這個模型採用 MoE 架構。

MoE 可以簡單理解為：模型總參數很大，但每次推理不會啟用全部參數，而是只啟用其中一部分專家。原文稱它每次實際運行大約啟用 3B 參數，因此在一定量化下，速度和顯存壓力會比傳統 dense 35B 模型低很多。

再疊加 GGUF 量化後，它就有機會在消費級顯卡上運行。原文提到最小量化版本約 11GB，6G/8G 顯存也能嘗試，但更建議至少 8G 顯存。

更現實的理解是：

6G 顯存：可以嘗試低比特量化，但上下文和速度都要降低預期。
8G 顯存：更適合入門測試，建議選更小量化。
16G 顯存：體驗會明顯寬鬆，適合更長上下文和更多 GPU offload。
24G 顯存：更適合 Q4_K_M、Q4_K_P 這類品質更好的量化版本。

本地模型能不能「好用」，不能只看能不能啟動，還要看上下文長度、生成速度、顯存餘量、KV cache、是否啟用多模態、並發需求和實際任務類型。

llama.cpp 部署思路

原文推薦使用 llama.cpp，原因是它支援 Windows、Linux、macOS，也支援 NVIDIA CUDA、AMD、Intel、Vulkan 和純 CPU 等多種後端。

一個典型啟動方式類似：

llama-server.exe ^
  -m "模型路徑.gguf" ^
  --mmproj "mmproj.gguf" ^
  -ngl 999 ^
  -c 131072 ^
  -n 8192 ^
  --host 127.0.0.1 ^
  --port 8080 ^
  --jinja

幾個參數值得單獨理解：

-m：主模型 GGUF 檔案路徑。
--mmproj：多模態投影檔案，啟用視覺能力時需要。
-ngl：盡量把層 offload 到 GPU，具體效果取決於顯存和後端。
-c：上下文長度，越大越吃記憶體和顯存。
-n：單次生成 token 上限。
--host 127.0.0.1：只監聽本機，安全性比暴露公網高。
--port 8080：本地 API 服務端口。
--jinja：新版 Qwen 模型常需要正確聊天模板，否則可能出現格式錯亂、重複或中文異常。

這裡最容易踩坑的是上下文長度。-c 131072 看起來很誘人，但長上下文會顯著增加 KV cache 占用。低顯存機器不建議盲目拉滿，應該先用較小上下文跑通，再逐步增加。

多模態能力怎麼用

原文提到這個版本支援多模態視覺識圖，可以分析圖片、截圖、OCR、複雜 UI 和程式碼截圖。

在 llama.cpp 裡，多模態通常需要主模型和 mmproj 檔案配套。沒有正確載入 --mmproj 時，前端裡的圖片上傳能力可能不可用，或者模型無法正確理解圖像。

多模態本地模型的實用場景包括：

分析截圖裡的 UI。
OCR 識別圖片文字。
閱讀程式碼截圖或報錯截圖。
給本地 Agent 提供視覺輸入。
在不上傳雲端的情況下處理隱私圖片。

但它也有邊界：視覺理解不等於嚴格 OCR，不適合作為唯一事實來源。涉及帳單、合約、證件、醫療圖像等高風險內容時，仍然需要人工複核。

OpenAI API 相容介面

llama.cpp 的 llama-server 可以提供類似 OpenAI API 的本地介面。原文給出的本地 base URL 是：

`1`	`http://127.0.0.1:8080/v1`

這意味著很多支援自訂 OpenAI-compatible provider 的工具，可以把請求轉到本地模型上。API key 通常可以隨便填一個占位值，具體取決於客戶端是否強制校驗。

這類能力的意義很大：

不需要雲端 API key。
不產生按 token 計費。
資料可以留在本機。
可以接入本地 Agent、程式碼助手或聊天前端。
可以作為 OpenAI API 的本地替代後端做實驗。

但不要把本地介面直接暴露到公網。即使模型在本地，API 一旦開放到區域網路或公網，也可能被別人濫用，導致機器資源被打滿，甚至讓模型輸出你不希望生成的內容。

對接 Hermes 和 OpenClaw 的意義

原文提到，將這個本地模型接入 Hermes 或 OpenClaw，才能真正體現它的價值。

這句話的意思是：模型本身只是推理核心，Agent 工具才負責把它接到真實任務裡。比如：

寫程式碼。
調用工具。
讀取檔案。
分析圖片。
聯網搜尋。
執行多步驟任務。
維護長上下文工作流。

本地模型如果只用來聊天，價值有限；如果能穩定作為 Agent 後端，才更接近「本地 AI 工作站」。

不過，無審查模型接入 Agent 時要更謹慎。Agent 能操作檔案、運行命令、訪問網頁、調用工具時，模型的輸出會轉化為真實動作。模型越少限制，越需要外層權限控制、人工確認和審計日誌。

無審查模型的風險邊界

這類模型最大賣點通常是「少拒答」。但少拒答也意味著更大的風險。

需要注意幾件事：

它可能更容易輸出違法、危險或誤導性內容。
它可能不會主動提醒安全邊界。
它可能在高風險問題上給出過度自信的建議。
它可能被提示詞誘導執行不合適的任務。
它不適合直接面向公眾開放。

更穩妥的做法是：

只在本機或受控區域網路內測試。
不把它接入高權限工具。
不讓它自動執行刪除、支付、發文、批量提交等不可逆操作。
給 Agent 工具設定檔案、命令、網路和瀏覽器權限邊界。
對高風險輸出保持人工複核。

換句話說，越是「自由」的模型，越需要外層系統約束。

適合誰嘗試

這類模型適合以下使用者：

想研究本地大模型部署的人。
有 8G 以上顯存，願意折騰 GGUF 和 llama.cpp 的使用者。
想把本地模型接入 OpenAI-compatible 客戶端的人。
關注本地多模態、截圖分析和 Agent 後端的人。
想離線處理部分隱私資料的開發者。

不太適合以下場景：

完全不想調參數的新手。
需要穩定生產 SLA 的服務。
對安全合規要求高的團隊。
需要嚴格事實可靠性的業務流程。
想把模型直接公開給外部使用者的人。

簡單結論

Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive 這類模型的出現，說明本地 AI 的能力邊界正在快速往前推：消費級顯卡可以跑更大模型，GGUF 量化讓部署門檻下降，llama.cpp 讓本地模型具備 OpenAI API 相容介面，多模態和 Agent 工具又把它從聊天推進到任務執行。

但不要把它只理解成「越獄模型」。更有價值的角度是：本地 AI 正在成為可組合的基礎設施。模型、推理引擎、API 服務、前端、Agent 工具、權限控制，會一起決定最終體驗。

如果你要嘗試，建議先從低風險本地測試開始：選合適量化，降低上下文長度，確認 --jinja 和 --mmproj 配置正確，再接入客戶端。等穩定後，再考慮接入 Agent 工作流。

參考資料：

零度博客原文：https://www.freedidi.com/24284.html
llama.cpp GitHub：https://github.com/ggml-org/llama.cpp

RTX 3070 8GB 本地運行 Qwen3.6-35B：llama.cpp 部署要點與最佳化參數

Fri, 22 May 2026 22:44:16 +0800

8GB 顯存能不能跑 35B 級別模型，關鍵不只看模型總參數量，還要看模型結構、量化格式和推理框架的調度方式。

這次案例的核心思路是：使用 Qwen3.6-35B-A3B 這類 MoE 模型的 GGUF 量化版本，再透過 llama.cpp 的 CUDA 加速、CPU Offload、MoE 參數調度和 KV Cache 量化，把顯存壓力分攤到 GPU 與記憶體之間。這樣一來，RTX 3070 8GB 這類老顯卡也有機會跑起 35B 級別的本地多模態模型。

需要先說明一點：這不是「8GB 顯存完整裝下 35B 模型」。更準確的理解是，顯卡負責更適合 GPU 的計算部分，部分專家層和快取壓力由系統記憶體承擔。實際體驗會受到記憶體容量、CPU 效能、模型量化格式、上下文長度和參數設定影響。

測試環境

這類配置對記憶體比較敏感。參考環境如下：

CPU：Intel Core i7-12700 級別
GPU：NVIDIA RTX 3070 8GB
記憶體：64GB
系統：Windows 11
推理框架：llama.cpp CUDA 版本
模型格式：GGUF

如果只有 16GB 或 32GB 記憶體，也不是完全不能嘗試，但 35B MoE 模型在載入和長上下文推理時更容易觸發記憶體壓力。想要穩定使用，64GB 記憶體會更穩。

為什麼 8GB 顯存也有機會跑 35B

Qwen3.6-35B-A3B 的關鍵點在於 MoE 架構。它的總參數規模是 35B，但每次推理並不是所有參數都同時啟用，而是只啟用其中一部分專家參數。

這會帶來兩個結果：

總模型檔案仍然很大，需要足夠磁碟和記憶體承載。
單次推理的活躍計算量低於完整 35B Dense 模型。

llama.cpp 的 CPU Offload 和 MoE 相關參數可以進一步降低顯存門檻。GPU 主要承擔注意力和部分高收益計算，CPU 與記憶體承擔一部分專家層權重。代價是速度、回應延遲和穩定性會更依賴整機配置，而不是只看顯卡型號。

準備 llama.cpp

Windows 使用者可以直接下載 llama.cpp 的預編譯 CUDA 版本。需要注意三點：

顯卡驅動要足夠新，CUDA 執行環境要和下載的 llama.cpp 套件匹配。
下載後建議放在一個不含中文和特殊字元的路徑下，方便批次腳本呼叫。
模型檔案統一放到 models 目錄，避免命令裡寫太長路徑。

如果是 AMD、Intel 顯卡或純 CPU 環境，也可以選擇 Vulkan、HIP、SYCL 或 CPU 版本，但參數和效能表現會不同。本文重點仍然是 NVIDIA 顯卡上的 CUDA 路線。

下載模型和多模態投影檔案

本次使用的模型是：

Qwen3.6-35B-A3B-UD-Q4_K_M.gguf

量化格式選擇 Q4_K_M，主要是為了在精度、體積和速度之間取得平衡。顯存較小的機器不建議一開始就嘗試更高精度版本，否則載入失敗或系統頻繁換頁的機率會明顯上升。

如果要使用圖片理解能力，還需要同時準備多模態投影檔案，例如：

mmproj-BF16.gguf

這個檔案非常重要。只下載主模型通常只能完成文字推理；如果缺少 mmproj，網頁 UI 裡可能看不到正常的圖片上傳能力，或者上傳後無法完成視覺理解。

建議目錄結構保持簡單：

llama.cpp/
├─ llama-server.exe
└─ models/
   ├─ Qwen3.6-35B-A3B-UD-Q4_K_M.gguf
   └─ mmproj-BF16.gguf

RTX 3070 8GB 啟動參數

下面是一份面向 RTX 3070 8GB 的啟動腳本範例。路徑需要改成你自己的 llama.cpp 所在目錄。

@echo off
chcp 65001 >nul
cd /d D:\AI\llama.cpp

llama-server.exe ^
  -m "models\Qwen3.6-35B-A3B-UD-Q4_K_M.gguf" ^
  --mmproj "models\mmproj-BF16.gguf" ^
  -ngl 99 ^
  --n-cpu-moe 999 ^
  --flash-attn on ^
  --jinja ^
  -c 32768 ^
  -t 12 ^
  -b 512 ^
  -ub 128 ^
  --cache-type-k q4_0 ^
  --cache-type-v q4_0 ^
  --mlock ^
  --host 127.0.0.1 ^
  --port 8080

pause

啟動後在瀏覽器訪問：

`1`	`http://127.0.0.1:8080`

如果頁面可以打開，並且模型能正常回覆，就說明服務已經啟動成功。首次載入模型可能會比較慢，期間不要急著重複運行多個實例，否則更容易把記憶體占滿。

關鍵參數怎麼理解

-ngl 99 表示盡量把可放到 GPU 的層放到顯卡上。實際能放多少，取決於模型結構、量化格式和顯存占用。

--n-cpu-moe 999 用來讓 MoE 專家層更多走 CPU 側，降低顯存壓力。它是這類小顯存運行大 MoE 模型的關鍵參數之一。

--flash-attn on 開啟 Flash Attention，有助於降低注意力計算的開銷。是否可用取決於目前 llama.cpp 版本和顯卡支援情況。

-c 32768 設定上下文長度。長上下文會顯著增加 KV Cache 壓力，如果啟動失敗或推理很慢，可以先降到 8192 或 16384。

--cache-type-k q4_0 和 --cache-type-v q4_0 用於量化 KV Cache，能節省記憶體和顯存，但可能對輸出品質和速度有輕微影響。

-b 512 與 -ub 128 控制批次處理相關參數。小顯存環境下，不要一開始就把批次參數設得太激進。

常見問題

如果啟動時提示顯存不足，可以先降低上下文長度，例如把 -c 32768 改成 -c 8192，再嘗試減小 -b 和 -ub。

如果圖片上傳按鈕不可用，優先檢查 --mmproj 路徑是否正確，以及使用的 mmproj 是否和模型匹配。

如果模型載入後回應很慢，通常不是顯卡完全沒工作，而是大量權重或專家層由 CPU 與記憶體承擔。可以觀察工作管理員裡的 GPU、CPU、記憶體和磁碟占用，判斷瓶頸在哪裡。

如果輸出格式異常，確認是否啟用了 --jinja，並檢查目前模型是否需要對應聊天模板。

如果服務啟動後瀏覽器打不開，檢查 --host 和 --port 設定，確認 8080 端口沒有被其他程式占用。

適合誰嘗試

這套方案適合手上已有 RTX 3070、RTX 4060 Laptop、RTX 3060 8GB 這類 8GB 顯存設備，但又想嘗試更大 MoE 模型的使用者。

它不適合追求極致速度的人。小顯存運行 35B MoE 本質上是在用記憶體和 CPU 換顯存門檻，能跑起來是一回事，是否足夠流暢是另一回事。

如果目標是日常高頻聊天，7B、8B、14B 模型可能更舒服。如果目標是體驗更大 MoE 模型、多模態能力和本地部署邊界，那麼 RTX 3070 8GB 加 64GB 記憶體仍然有嘗試價值。

小結

RTX 3070 8GB 能運行 Qwen3.6-35B-A3B 的關鍵，不是顯存突然變大，而是 MoE 架構、GGUF 量化、llama.cpp CPU Offload 和 KV Cache 最佳化共同降低了門檻。

這類方案最值得關注的地方，是它讓舊顯卡仍然能參與本地大模型實驗。只要接受速度和穩定性上的取捨，8GB 顯存機器也可以成為本地 AI 模型測試平台，而不只是運行小模型的入門設備。

參考資料：

原文連結：https://www.freedidi.com/24267.html

llama.cpp b9196 更新：Windows 預編譯版支援 CUDA 13.1、Vulkan、HIP 和 SYCL

Mon, 18 May 2026 23:20:00 +0800

llama.cpp 最近的 Windows 版本對本地大模型使用者更友好了。以前在 Windows 上跑 GGUF 模型，很多人卡在環境問題上：CUDA 版本不匹配、DLL 缺失、驅動不相容、CMake 編譯失敗、環境變數錯誤，或者 Vulkan / HIP / SYCL 設定太麻煩。

現在官方 Release 已經提供多種 Windows 預編譯包。很多場景下，使用者不再需要從源碼編譯，下載對應版本、解壓、放入模型文件後，就可以直接啟動本地推理服務。

llama.cpp 適合做什麼

llama.cpp 是目前最常用的本地 GGUF 模型推理框架之一。它的特點是輕量、跨平台，既能跑 CPU，也能利用 GPU，並且圍繞 GGUF 生態累積了大量模型資源。

常見模型路線包括：

Qwen
Llama
DeepSeek
Gemma
Mistral
Mixtral
Hermes

隨著 GGUF 量化模型越來越普及，很多開源模型都會提供適合本地部署的 GGUF 版本。對普通使用者來說，llama.cpp 的價值主要在於：不用搭一整套複雜推理框架，也能在本機跑一個可用的聊天服務。

Windows 預編譯版本怎麼選

目前 Windows 使用者可以根據硬體選擇不同構建版本：

Windows x64 CPU
Windows x64 CUDA 12.4
Windows x64 CUDA 13.1
Windows x64 Vulkan
Windows x64 HIP Radeon
Windows x64 SYCL
Windows ARM64 CPU

如果是 NVIDIA 顯卡，通常優先考慮 CUDA 版本。RTX 3060、4060、4070、4080、4090 這類顯卡都更適合走 CUDA 路線。

如果是 AMD 顯卡，可以嘗試 HIP 或 Vulkan。實際體驗裡，Vulkan 的相容性有時比 HIP 更省心，尤其適合不想折騰完整 ROCm 環境的使用者。

如果是 Intel 核顯或 Arc 獨顯，可以嘗試 SYCL 或 Vulkan。性能通常不如 NVIDIA CUDA 路線，但跑一些中小型 GGUF 模型已經足夠測試。

CPU 版本適合沒有獨顯、只是想驗證模型或跑小參數模型的使用者。速度不會太快，但部署最簡單。

啟動普通 GGUF 模型

假設你已經下載好 llama.cpp Windows 預編譯包，並把模型放到 models 目錄。進入 llama.cpp 解壓目錄後，可以用類似命令啟動：

`1`	`llama-server.exe -m models\your-model.gguf -ngl 999`

這裡的 -m 指向 GGUF 模型文件，-ngl 999 表示盡量把模型層載入到 GPU。實際能載入多少，取決於顯存容量、模型大小和量化格式。

啟動成功後，在瀏覽器打開：

`1`	`http://127.0.0.1:8080`

就可以進入本地網頁聊天介面。

如果顯存不足，可以換更小的模型，或者換更低量化版本，例如 Q4、Q5 這類 GGUF 文件。不要只看模型參數量，也要看量化格式和上下文長度設定。

啟動多模態視覺模型

多模態視覺模型通常不只需要一個主模型文件，還需要一個 mmproj 視覺投影文件。啟動時要同時指定主模型和 mmproj：

`1`	`llama-server.exe -m "models\main-model.gguf" --mmproj "models\mmproj-model.gguf" -ngl 999`

常見用途包括：

OCR 識別
截圖理解
網頁截圖分析
圖片問答
簡單視覺內容判斷

例如 Qwen2-VL / Qwen2.5-VL 這類視覺模型，在中文截圖理解、OCR 和圖文問答上比較實用。使用時要注意主模型和 mmproj 文件是否匹配，版本不匹配很容易導致載入失敗或效果異常。

用 bat 腳本管理多個模型

如果本地同時放了多個模型，可以寫一個簡單的 .bat 腳本做選單切換。下面是一個示例，路徑和模型名需要改成你自己的：

@echo off
chcp 65001 >nul
cd /d C:\path\to\llama-b9196-bin-win-cuda-13.1-x64

echo 请选择模型：
echo 1. Gemma
echo 2. Qwen VL 多模态
echo 3. DeepSeek

set /p choice=输入数字：

if "%choice%"=="1" llama-server.exe -m "models\gemma.gguf" -ngl 999
if "%choice%"=="2" llama-server.exe -m "models\qwen-vl.gguf" --mmproj "models\mmproj.gguf" -ngl 999
if "%choice%"=="3" llama-server.exe -m "models\deepseek.gguf" -ngl 999

pause

保存時建議使用 UTF-8 編碼，再把文件後綴改成 .bat。這樣雙擊腳本後，就可以透過數字選擇不同模型。

模型選擇要看三件事

第一，看硬體。顯存越大，能跑的模型越大；顯存不足時，不要硬上大模型，可以先從 7B、8B 或更低量化版本開始。

第二，看用途。如果只是日常問答、總結、改寫，小模型和中等量化通常夠用。如果要做程式碼、長文件分析或多模態理解，就需要更強模型和更多顯存。

第三，看授權和安全邊界。網上有很多社群改版模型，能力、限制和授權都不一樣。下載前要確認來源、授權、適用場景和風險，不建議把生產任務直接交給來源不明的模型。

常見問題

如果啟動時報 DLL 缺失，先確認下載的包和顯卡路線是否匹配。例如 NVIDIA 使用者不要誤下載 HIP 版本，AMD 使用者也不要下載 CUDA 版本。

如果模型載入很慢，可能是模型太大、硬碟速度慢，或者顯存不足導致部分層回落到 CPU。

如果網頁打不開，先看命令列是否已經成功啟動服務，再確認端口是不是 8080。如果端口被佔用，可以查閱 llama-server 參數換端口。

如果多模態模型效果不對，優先檢查 mmproj 文件是否和主模型配套，而不是只換提示詞。

小結

這次 Windows 預編譯包的價值在於降低了本地 AI 的入門門檻。以前很多使用者卡在編譯和依賴環境，現在可以更快進入「下載模型、啟動服務、測試效果」的階段。

對 Windows 使用者來說，選擇路線可以簡單理解為：

NVIDIA：優先 CUDA。
AMD：優先嘗試 Vulkan，再看 HIP。
Intel：嘗試 SYCL 或 Vulkan。
沒有獨顯：用 CPU 版本跑小模型。

真正使用前，仍然要確認模型來源、授權、顯存需求和實際效果。本地 AI 的好處是可控、離線、低延遲，但它不等於沒有成本：模型管理、硬體資源和輸出品質都需要自己負責。

參考來源：https://www.freedidi.com/24211.html

適合 RTX 3060 顯卡運行的本地 LLM 模型推薦

Fri, 08 May 2026 09:25:24 +0800

RTX 3060 最常見的是 12GB 顯存版本。它不是頂級 AI 顯卡，但用來跑本地 LLM 很合適，尤其適合 7B、8B、9B、12B 級別模型。

如果只想快速選型，可以先記住一句話：

RTX 3060 12GB 優先選 8B 左右模型的 Q4_K_M 或 Q5_K_M 量化；想要更穩就選 Q4，想要更好品質再試 Q5。

不要一上來就追 32B、70B。它們即使用低位元量化和 CPU offload 能跑，速度和體驗通常也不適合日常使用。

先看顯存邊界

RTX 3060 12GB 跑本地 LLM，真正限制是顯存。

模型規模	推薦量化	3060 12GB 體驗
3B / 4B	Q4、Q5、Q8	很輕鬆，速度快
7B / 8B / 9B	Q4_K_M、Q5_K_M	最推薦，品質和速度平衡好
12B / 14B	Q4_K_M	可以嘗試，注意上下文不要太大
30B 以上	Q2 / Q3 或部分 offload	能折騰，但不推薦日常使用
70B 以上	極低量化或大量 CPU/RAM 參與	更像實驗，不適合普通使用

本地 LLM 不只是模型檔案大小占顯存。上下文長度、KV cache、批處理大小、推理框架和顯卡驅動都會占資源。

所以 12GB 顯存不等於可以直接載入 12GB 模型檔案。更穩的做法是給系統和上下文留餘量。

推薦一：Qwen3 8B

如果你主要用中文，Qwen3 8B 是 RTX 3060 上很值得優先嘗試的模型。

適合場景：

中文問答。
摘要和改寫。
日常知識助手。
簡單程式碼解釋。
本地 RAG。
輕量 Agent 流程。

建議選擇：

1
2
3

Qwen3 8B GGUF
Q4_K_M：優先推薦
Q5_K_M：品質更好，但顯存壓力更高

Qwen 系列對中文更友好，日常寫作、資料整理和中文指令理解通常比較順。如果你不知道第一款本地中文模型選什麼，可以先從它開始。

推薦二：Llama 3.1 8B Instruct

Llama 3.1 8B Instruct 是一個很穩的通用模型，英文能力和工具生態都比較成熟。

適合場景：

英文問答。
輕量程式碼輔助。
通用聊天。
文件摘要。
提示詞測試。
對比不同推理工具。

建議選擇：

1
2
3

Llama 3.1 8B Instruct GGUF
Q4_K_M：速度和顯存更穩
Q5_K_M：回答品質更好

如果你主要處理英文資料，或者想要一個生態成熟、教學多、相容性好的模型，Llama 3.1 8B 仍然是很好的基準選擇。

推薦三：Gemma 3 12B

Gemma 3 12B 更接近 3060 12GB 的上限選擇。

它比 8B 模型更吃顯存，但在 Q4 量化下仍然有機會在 3060 12GB 上跑起來。適合想在單卡上嘗試更大一點模型的人。

適合場景：

更高品質的通用問答。
英文內容處理。
較複雜的總結和分析。
對 8B 模型不滿意時的升級嘗試。

建議選擇：

1
2
3

Gemma 3 12B GGUF
Q4_K_M 或官方 QAT Q4
上下文不要開太大

如果運行時爆顯存，可以先降低上下文長度，或者換回 8B 模型。對 3060 來說，12B 是「能試」，不是「無腦推薦」。

推薦四：DeepSeek R1 Distill Qwen 8B

如果你想在本地體驗推理風格模型，可以試 DeepSeek R1 Distill Qwen 8B 一類 8B 蒸餾模型。

適合場景：

簡單推理題。
分步驟分析。
學習推理模型輸出風格。
本地低成本實驗。

建議選擇：

1
2

DeepSeek R1 Distill Qwen 8B GGUF
Q4_K_M

需要注意，這類模型有時會輸出更長的推理過程，速度和上下文占用可能比普通指令模型更明顯。日常聊天不一定比 Qwen3 8B 更舒服，但用來做推理實驗很合適。

推薦五：Phi / MiniCPM / 小尺寸模型

如果你的 3060 不是 12GB 版本，而是 8GB 版本，或者電腦記憶體也比較小，可以優先考慮 3B、4B 級別模型。

適合場景：

快速問答。
簡單摘要。
嵌入到本地小工具。
低延遲聊天。
老電腦測試。

這類模型品質不一定能和 8B、12B 相比，但勝在輕、快、部署簡單。

量化怎麼選

本地模型常見格式是 GGUF，常見量化包括 Q4、Q5、Q6、Q8。

量化	特點	適合誰
Q4_K_M	體積小，速度好，品質夠用	3060 首選
Q5_K_M	品質更好，占用更高	8B 模型可以試
Q6 / Q8	更接近原始品質，占用更大	小模型或顯存寬裕時
Q2 / Q3	很省顯存，但品質下降明顯	大模型折騰用

對 RTX 3060 12GB 來說，最實用的是：

1
2
3

8B 模型：Q4_K_M 或 Q5_K_M
12B 模型：優先 Q4_K_M
更大模型：不建議作為日常主力

用什麼工具運行

新手可以從 Ollama 開始，優點是安裝和運行簡單。

常見命令形式：

1
2

ollama run qwen3:8b
ollama run llama3.1:8b

如果想更細地控制 GGUF 檔案、GPU layers、上下文長度，可以用 llama.cpp 或基於 llama.cpp 的圖形工具。

常見選擇：

Ollama：最省心，適合新手。
LM Studio：圖形介面友好，適合手動下載和切換模型。
llama.cpp：控制最細，適合折騰效能。
text-generation-webui：功能多，適合測試不同後端。

如果只是本地聊天和簡單問答，Ollama 或 LM Studio 就夠了。

上下文不要開太大

很多模型宣傳支援很長上下文，但 RTX 3060 運行時不要盲目開到最大。

上下文越長，KV cache 占用越高，顯存壓力也越大。即使模型能載入，長上下文也可能導致速度下降。

建議：

1
2
3

普通聊天：4K 到 8K
文件摘要：8K 到 16K
長文件 RAG：優先切片，不要硬塞全文

3060 更適合「中等上下文 + 好模型 + 好檢索」，不適合把幾十萬 token 一次性塞進去。

不同用途怎麼選

如果你主要寫中文：

1
2

優先：Qwen3 8B Q4_K_M
備選：DeepSeek R1 Distill Qwen 8B

如果你主要寫英文：

1
2

優先：Llama 3.1 8B Instruct Q4_K_M
備選：Gemma 3 12B Q4_K_M

如果你想跑得快：

1
2
3

3B / 4B 模型
8B Q4_K_M
上下文控制在 4K 到 8K

如果你想品質更好：

1
2
3

8B Q5_K_M
12B Q4_K_M
接受速度變慢

如果你想寫程式碼：

1
2

8B 程式碼模型可以輔助解釋和小改動
複雜工程任務仍建議用雲端強模型

本地 3060 模型適合做程式碼解釋、函式補全、小腳本生成和離線輔助；大型專案重構、複雜 bug、跨檔案 Agent 任務，不要期待它達到 Claude Sonnet 或 GPT-5 級別。

3060 本地 LLM 的合理預期

RTX 3060 12GB 的定位很清楚：它適合把本地 LLM 從「玩具」變成「日常可用工具」，但不是讓你在家裡復刻頂級雲端模型。

它的優勢是：

成本低。
顯存比 8GB 卡寬裕。
8B 模型體驗不錯。
可以離線使用。
適合隱私敏感資料的本地處理。

它的限制是：

大模型很難流暢。
長上下文會吃顯存。
推理速度不如高階卡。
本地小模型複雜推理能力有限。
多模態和 Agent 工作流會更吃資源。

所以最穩的路線是：用 8B 模型做日常本地助手，用 12B 模型做品質嘗試，複雜任務交給雲端模型。

小結

RTX 3060 12GB 最推薦的本地 LLM 選擇是：

中文通用：Qwen3 8B Q4_K_M
英文通用：Llama 3.1 8B Instruct Q4_K_M
更高品質嘗試：Gemma 3 12B Q4_K_M
推理實驗：DeepSeek R1 Distill Qwen 8B Q4_K_M
低顯存快速體驗：3B / 4B 小模型

量化優先選 Q4_K_M，8B 模型可以嘗試 Q5_K_M。工具優先從 Ollama 或 LM Studio 開始。

不要把 3060 當成大模型伺服器。把它當成本地知識助手、隱私文件處理器、輕量程式碼助手和模型實驗卡，會更符合它的實際能力。

參考連結

Qwen3 8B GGUF：https://huggingface.co/Qwen/Qwen3-8B-GGUF
Llama 3.1 8B GGUF：https://huggingface.co/macandchiz/Llama-3.1-8B-Instruct-GGUF
Gemma 3 12B GGUF：https://huggingface.co/unsloth/gemma-3-12b-it-GGUF
llama.cpp：https://github.com/ggml-org/llama.cpp
Ollama：https://ollama.com

本地部署 Qwen3.6：27B 與 35B-A3B 各量化版本需要多少顯存

Fri, 01 May 2026 12:02:00 +0800

Qwen3.6 目前最適合本地部署討論的開放權重版本，主要是兩類：

Qwen3.6-27B：27B 稠密模型。
Qwen3.6-35B-A3B：35B total / 3B active 的 MoE 模型。

還有一些線上產品名或 API 模型名，例如 Qwen3.6-Plus、Qwen3.6-Max。這類模型如果沒有公開完整權重和穩定量化檔案，就不適合列入本地顯存表。本文只整理可以圍繞 Hugging Face 權重與 GGUF 量化檔案部署的版本。

和 /05/10 的 Gemma 4 表一樣，這裡也要先區分兩個概念：

GGUF 檔案體積：模型權重檔案本身有多大。
實際顯存占用：模型權重、KV cache、上下文長度、執行後端、多模態模組、批次大小共同決定。

Qwen3.6 的預設上下文很長，官方模型卡裡寫到原生支援 262,144 tokens，並可擴展到 1,010,000 tokens。所以表格裡的「最低顯存」只適合短上下文或中等上下文。如果你真的要跑 128K、256K 或更長上下文，必須額外給 KV cache 留大量空間。

先看結論

顯存	比較合適的選擇	不建議硬上
8GB	27B / 35B-A3B 的 2-bit 極限嘗試，品質風險較高	Q4 以上
12GB	27B Q2/Q3，35B-A3B Q2/Q3 短上下文	27B Q4 長上下文
16GB	27B Q3/Q4，35B-A3B Q3/IQ4_XS	35B-A3B Q4 長上下文
24GB	27B Q4/Q5/Q6，35B-A3B Q4	35B-A3B Q8、BF16
32GB	27B Q8，35B-A3B Q5/Q6	BF16
48GB	35B-A3B Q8，27B 長上下文更從容	35B-A3B BF16
80GB+	27B / 35B-A3B BF16	沒有必要為普通本地聊天追 BF16

如果你是 24GB 顯卡，重點看：

Qwen3.6-27B Q4_K_M
Qwen3.6-27B Q5_K_M
Qwen3.6-35B-A3B UD-Q4_K_M

如果你只有 16GB 顯存，優先從低位寬版本開始，不要一上來就開超長上下文。

官方權重體積

以下是官方 Hugging Face 倉庫中 model.safetensors.index.json 統計到的 BF16 權重體積。它可以作為原始權重規模參考。

模型	架構	官方 BF16 權重體積	官方上下文
`Qwen3.6-27B`	27B dense	55.56GB	262K 原生，可擴展到 1,010K
`Qwen3.6-35B-A3B`	35B total / 3B active MoE	71.90GB	262K 原生，可擴展到 1,010K

35B-A3B 雖然每次只啟用約 3B 參數，但它仍然需要載入完整 MoE 權重。所以它不能按 3B 小模型來估算顯存。

Qwen3.6-27B 顯存表

Qwen3.6-27B 是稠密模型，優點是能力穩定，缺點是推理成本更接近傳統 27B 模型。從本地部署角度看，它比 35B-A3B 更吃計算，但顯存需求更容易預估。

量化版本	GGUF 檔案體積	最低顯存	更穩妥顯存	適合場景
`UD-IQ2_XXS`	9.39GB	12GB	16GB	極限低顯存嘗試
`UD-IQ2_M`	10.85GB	12GB	16GB	低顯存可用性優先
`UD-Q2_K_XL`	11.85GB	14GB	18GB	低位寬折中
`UD-IQ3_XXS`	11.99GB	14GB	18GB	省顯存的 3-bit
`Q3_K_S`	12.36GB	16GB	20GB	3-bit 入門
`Q3_K_M`	13.59GB	16GB	20GB	3-bit 常用折中
`IQ4_XS`	15.44GB	20GB	24GB	接近 Q4 的省顯存選擇
`IQ4_NL`	16.07GB	20GB	24GB	品質和體積折中
`Q4_K_M`	16.82GB	20GB	24GB	27B 常用推薦
`Q5_K_M`	19.51GB	24GB	32GB	更穩的高品質量化
`Q6_K`	22.52GB	28GB	32GB	品質優先
`Q8_0`	28.60GB	32GB	40GB	接近原始精度
`BF16`	53.80GB	64GB	80GB	研究、評測、精度對比

如果只是普通本地編碼和聊天，Q4_K_M 是最容易推薦的起點。 24GB 顯卡可以比較舒服地跑 Q4_K_M，但如果要長上下文，最好降低量化位寬或減少上下文長度。

Qwen3.6-35B-A3B 顯存表

Qwen3.6-35B-A3B 是 MoE 模型，35B total，但每次啟用約 3B 參數。它的優勢是速度和能力之間的平衡很好，尤其適合本地 Agent、工具呼叫、程式碼協作。

但要注意：MoE 的 3B active 主要影響計算量，不代表顯存只需要 3B 模型級別。完整執行仍要載入專家權重。

量化版本	GGUF 檔案體積	最低顯存	更穩妥顯存	適合場景
`UD-IQ2_XXS`	10.76GB	12GB	16GB	極限低顯存嘗試
`UD-IQ2_M`	11.52GB	14GB	16GB	低顯存可用性優先
`UD-Q2_K_XL`	12.29GB	14GB	18GB	低位寬折中
`UD-IQ3_XXS`	13.21GB	16GB	20GB	省顯存的 3-bit
`UD-Q3_K_S`	15.36GB	18GB	24GB	3-bit 入門
`UD-Q3_K_M`	16.60GB	20GB	24GB	3-bit 常用折中
`UD-IQ4_XS`	17.73GB	20GB	24GB	品質和體積折中
`UD-IQ4_NL`	18.04GB	20GB	24GB	接近 Q4 的推薦選擇
`UD-Q4_K_M`	22.13GB	24GB	32GB	35B-A3B 常用推薦
`UD-Q5_K_M`	26.46GB	32GB	40GB	更穩的高品質量化
`UD-Q6_K`	29.31GB	32GB	48GB	品質優先
`Q8_0`	36.90GB	48GB	64GB	接近原始精度
`BF16`	69.37GB	80GB	96GB	研究、評測、精度對比

24GB 顯存可以把 UD-Q4_K_M 作為重點選擇，但上下文不要開得太誇張。如果想給 128K 以上上下文留空間，UD-IQ4_XS、UD-IQ4_NL 或 3-bit 版本會更現實。

27B 和 35B-A3B 怎麼選

需求	更推薦
穩定稠密模型表現	`Qwen3.6-27B`
更快響應、Agent 和工具呼叫	`Qwen3.6-35B-A3B`
24GB 顯存日常本地用	`35B-A3B UD-Q4_K_M` 或 `27B Q4_K_M`
16GB 顯存嘗試	兩者都選 2-bit/3-bit，不建議長上下文
長上下文優先	降低量化位寬，留更多 KV cache 空間
品質優先且有 32GB+ 顯存	`27B Q5/Q6` 或 `35B-A3B Q5/Q6`

如果你主要寫程式碼、跑 Agent、做工具呼叫，35B-A3B 更值得先試。如果你更在意稠密模型的穩定性和一致性，27B 更直觀。

為什麼長上下文會吃掉大量顯存

Qwen3.6 的模型卡建議在複雜任務中保持較長上下文，甚至提到 128K 以上上下文對思考能力有幫助。但對本地部署來說，長上下文意味著更大的 KV cache。

影響實際顯存的因素包括：

KV cache：上下文越長，占用越高。
是否啟用視覺輸入：Qwen3.6 是帶視覺編碼器的模型，多模態場景會增加額外開銷。
是否使用 --language-model-only：在 vLLM 等執行時裡，跳過視覺部分可以釋放一部分記憶體給 KV cache。
批次大小和並發：並發越高，顯存需求越高。
KV cache 量化：q8_0、q4_0 等設定可以省顯存，但可能影響細節。
執行時差異：llama.cpp、vLLM、SGLang、KTransformers、LM Studio 的占用不完全一樣。

所以不要只看 GGUF 檔案大小。如果檔案已經接近顯存上限，模型即使能載入，也可能在生成長文字或長上下文時 OOM。

怎麼選

如果你只是想本地體驗 Qwen3.6：

12GB 顯存：嘗試 27B UD-IQ2_M 或 35B-A3B UD-IQ2_M，上下文要短。
16GB 顯存：嘗試 27B Q3_K_M 或 35B-A3B UD-IQ3_XXS。
24GB 顯存：優先看 27B Q4_K_M、35B-A3B UD-IQ4_NL、35B-A3B UD-Q4_K_M。
32GB 顯存：可以考慮 27B Q5/Q6 或 35B-A3B Q5/Q6。
48GB 以上：可以嘗試 Q8_0，或者給長上下文留更多空間。

一般使用者不需要追 BF16。 Qwen3.6 的本地部署重點不是「檔案越大越好」，而是在顯存、上下文長度、速度和輸出品質之間找到平衡。

參考來源

本地部署 Gemma 4：E2B、E4B、26B、31B 各量化版本需要多少顯存

Fri, 01 May 2026 11:42:34 +0800

Gemma 4 現在主要有四個本地部署尺寸：E2B、E4B、26B A4B 和 31B。其中 E2B、E4B 面向輕量和邊緣裝置，26B A4B 是 MoE 架構，31B 是更大的稠密模型。

本地執行時，最容易混淆的是兩個數字：

GGUF 檔案體積：模型權重檔案本身有多大。
實際顯存占用：模型權重、KV cache、執行時開銷、上下文長度、是否載入多模態投影檔共同決定。

下面的表格按 GGUF 檔案體積估算顯存需求。預設假設是 llama.cpp、LM Studio、Ollama 這類本地推理場景，主要跑文字，使用中短上下文。如果要開長上下文、視覺/音訊輸入、並發請求，顯存要繼續往上留餘量。

先看結論

顯存	比較合適的選擇	不建議硬上
4GB	E2B 的低位元量化	E4B 以上
6GB	E2B Q4/Q5，E4B 低位元量化	26B、31B
8GB	E2B Q8，E4B Q4/Q5	26B Q4、31B Q4
12GB	E4B Q8，26B/31B 的 2-bit/3-bit 低品質嘗試	26B Q4 長上下文、31B Q4
16GB	26B 低位元量化，31B 低位元量化	31B Q4 長上下文、26B Q5 以上
24GB	26B Q4/Q5，31B Q4	31B Q8、BF16
32GB	26B Q6/Q8，31B Q5/Q6	BF16
48GB	31B Q8 更從容，26B Q8 長上下文	31B BF16
80GB+	26B/31B BF16	普通消費卡單卡部署

如果只是想本地可用，優先從 E4B Q4_K_M 或 E2B Q4_K_M 開始。如果有 24GB 顯存，26B A4B Q4_K_M 和 31B Q4_K_M 才開始進入比較舒服的範圍。

Gemma 4 E2B 顯存表

E2B 是最輕量的版本，適合筆電、迷你主機、行動端和低顯存測試。它的優勢是容易跑，缺點是複雜推理、程式碼和長任務穩定性有限。

量化版本	GGUF 檔案體積	最低顯存	更穩妥顯存	適合場景
`UD-IQ2_M`	2.29GB	4GB	6GB	極限低顯存測試
`UD-Q2_K_XL`	2.40GB	4GB	6GB	低顯存可用性優先
`Q3_K_M`	2.54GB	4GB	6GB	輕量聊天、摘要
`IQ4_XS`	2.98GB	6GB	8GB	品質和體積折中
`Q4_K_M`	3.11GB	6GB	8GB	E2B 常用推薦
`Q5_K_M`	3.36GB	6GB	8GB	比 Q4 更穩一點
`Q6_K`	4.50GB	8GB	10GB	小模型高品質量化
`Q8_0`	5.05GB	8GB	10GB	接近原始精度的輕量部署
`BF16`	9.31GB	12GB	16GB	除錯、對比、研究

E2B 的 Q4_K_M 已經夠日常體驗。如果只有 4GB 顯存，可以嘗試 2-bit 或 3-bit，但輸出品質會更容易波動。

Gemma 4 E4B 顯存表

E4B 是更實用的輕量版本。它比 E2B 更適合日常寫作、資料總結、輕量程式碼輔助和本地助手。

量化版本	GGUF 檔案體積	最低顯存	更穩妥顯存	適合場景
`UD-IQ2_M`	3.53GB	6GB	8GB	低顯存嘗試
`UD-Q2_K_XL`	3.74GB	6GB	8GB	低顯存可用性優先
`Q3_K_M`	4.06GB	6GB	10GB	輕量本地助手
`IQ4_XS`	4.72GB	8GB	12GB	品質和速度折中
`Q4_K_M`	4.98GB	8GB	12GB	E4B 常用推薦
`Q5_K_M`	5.48GB	8GB	12GB	更穩的日常使用
`Q6_K`	7.07GB	10GB	16GB	品質優先
`Q8_0`	8.19GB	12GB	16GB	接近原始精度
`BF16`	15.05GB	20GB	24GB	研究、評測、精度對比

如果你的顯卡是 8GB，E4B Q4_K_M 是很現實的起點。如果是 12GB 或 16GB，E4B Q8_0 也可以考慮。

Gemma 4 26B A4B 顯存表

26B A4B 是 MoE 版本，參數規模更大，但每次推理只啟用其中一部分專家。它適合更複雜的問答、程式碼、工具呼叫和 Agent 工作流。

量化版本	GGUF 檔案體積	最低顯存	更穩妥顯存	適合場景
`UD-IQ2_M`	9.97GB	14GB	16GB	16GB 顯卡極限嘗試
`UD-Q2_K_XL`	10.55GB	14GB	16GB	低顯存跑 26B
`UD-Q3_K_M`	12.53GB	16GB	20GB	品質略好，仍偏省顯存
`UD-IQ4_XS`	13.42GB	16GB	24GB	品質和體積折中
`UD-Q4_K_M`	16.87GB	20GB	24GB	26B 常用推薦
`UD-Q5_K_M`	21.15GB	24GB	32GB	更穩的高品質量化
`UD-Q6_K`	23.17GB	28GB	32GB	品質優先
`Q8_0`	26.86GB	32GB	40GB	接近原始精度
`BF16`	50.51GB	64GB	80GB	單卡消費級不現實

24GB 顯存是 26B A4B 比較舒服的分界線。 16GB 顯卡可以嘗試低位元版本，但上下文長度、並發和多模態都要收斂。

Gemma 4 31B 顯存表

31B 是更大的稠密模型。它的優點是綜合能力更強，缺點是顯存壓力比 26B A4B 更直接。

量化版本	GGUF 檔案體積	最低顯存	更穩妥顯存	適合場景
`UD-IQ2_XXS`	8.53GB	12GB	16GB	極限低顯存嘗試，品質犧牲明顯
`UD-IQ2_M`	10.75GB	14GB	18GB	低顯存嘗試
`UD-Q2_K_XL`	11.77GB	16GB	20GB	16GB 顯卡可嘗試
`Q3_K_S`	13.21GB	16GB	24GB	更省顯存的 3-bit
`Q3_K_M`	14.74GB	20GB	24GB	3-bit 常用折中
`IQ4_XS`	16.37GB	20GB	24GB	接近 Q4 的折中
`Q4_K_M`	18.32GB	24GB	32GB	31B 常用推薦
`Q5_K_M`	21.66GB	28GB	32GB	更穩的高品質量化
`Q6_K`	25.20GB	32GB	40GB	品質優先
`Q8_0`	32.64GB	40GB	48GB	接近原始精度
`BF16`	61.41GB	80GB	96GB	伺服器或大顯存工作站

31B 的低位元版本可以在 16GB 顯卡上做實驗，但如果想日常使用，最好從 24GB 顯存起步。 Q4_K_M 是比較平衡的選擇，Q5_K_M 往上更適合 32GB 以上顯存。

為什麼實際占用會比檔案體積更高

GGUF 檔案體積只是權重大小。真正執行時還會增加這些開銷：

KV cache：上下文越長，占用越高。
批次大小和並發：一次處理更多 token 或多使用者並發，會增加顯存。
多模態組件：圖片、音訊、影片輸入通常還要載入 mmproj 或額外處理模組。
執行時後端：CUDA、Metal、ROCm、CPU/GPU 分層載入的占用不同。
KV cache 量化：開啟 q8_0、q4_0 等 KV cache 量化可以省顯存，但可能影響細節。

所以表格裡的「最低顯存」只能理解為「能啟動並短上下文執行」的門檻。如果你要 32K、64K、128K 甚至 256K 上下文，顯存需求會明顯增加。

怎麼選

如果只是想在本地體驗 Gemma 4：

4GB 到 6GB 顯存：選 E2B Q3_K_M 或 E2B Q4_K_M。
8GB 顯存：優先選 E4B Q4_K_M，也可以跑 E2B Q8_0。
12GB 顯存：選 E4B Q8_0，或者嘗試 26B/31B 的低位元版本。
16GB 顯存：可以嘗試 26B A4B UD-Q3_K_M 或 31B Q3_K_S，但不要期待長上下文很舒服。
24GB 顯存：26B A4B UD-Q4_K_M 和 31B Q4_K_M 是重點選擇。
32GB 以上：可以考慮 Q5_K_M、Q6_K，或者更長上下文。

一般使用者不需要追 BF16。本地部署的重點不是檔案越大越好，而是在顯存、速度、上下文和輸出品質之間找到平衡。

參考來源

llama-quantize 怎麼用：GGUF 模型量化入門

Sun, 12 Apr 2026 09:42:36 +0800

llama-quantize 是 llama.cpp 裡的量化工具，用來把高精度的 GGUF 模型轉成更小的量化版本。

它最常見的用途，是把像 F32、BF16 或 FP16 這樣的高精度模型，轉成 Q4_K_M、Q5_K_M、Q8_0 等更適合本機執行的格式。量化後模型體積會明顯縮小，推理通常也會更快，但精度會有一定損失。

基本用法

一個典型流程通常是先準備原始模型，再轉成 GGUF，最後執行量化。

# install Python dependencies
python3 -m pip install -r requirements.txt

# convert the model to ggml FP16 format
python3 convert_hf_to_gguf.py ./models/mymodel/

# quantize the model to 4-bits (using Q4_K_M method)
./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M

量化完成後，就可以直接用 llama-cli 載入新的 GGUF 檔案：

1
2

# start inference on a gguf model
./llama-cli -m ./models/mymodel/ggml-model-Q4_K_M.gguf -cnv -p "You are a helpful assistant"

常見參數

--allow-requantize：允許對已經量化過的模型再次量化，但通常不建議，品質可能下降得更明顯
--leave-output-tensor：保留輸出層不量化，體積會更大，但有時能換來更好的品質
--pure：關閉混合量化，讓更多張量使用同一量化類型
--imatrix：使用重要性矩陣優化量化效果，通常值得優先考慮
--keep-split：保留輸入模型的分片結構，而不是合併成單一檔案

如果只是想先跑起來，最實用的起點通常還是：

`1`	`./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M`

量化怎麼選

可以先把不同量化等級理解成「體積、速度和品質之間的交換」：

Q8_0：體積較大，但品質通常更穩
Q6_K / Q5_K_M：常見的平衡型選擇
Q4_K_M：很常見的預設檔，體積和效果通常比較均衡
Q3 / Q2：適合資源非常緊張的場景，但品質下降會更明顯

從示例資料來看，量化等級越低，模型通常越小；而在實際推理裡，更高精度也不一定總是更快，所以選型重點通常不是「越大越好」，而是「在你的硬體上夠穩、夠省、效果也能接受」。

實用建議

優先從 Q4_K_M 或 Q5_K_M 開始試
如果更看重品質，再往 Q6_K 或 Q8_0 提升
如果機器資源比較緊，再嘗試 Q3 或 Q2
最好始終用同一批測試問題比較不同量化版本

一句話總結：llama-quantize 的核心價值，不是單純把模型變小，而是讓 GGUF 模型在本地設備上更容易跑起來。

llama.cpp 如何從 Hugging Face 取得 GGUF 模型

Sun, 12 Apr 2026 09:31:38 +0800

llama.cpp 可以直接搭配 Hugging Face 上的 GGUF 模型使用，不一定要先手動把檔案下載到本機。

如果模型倉庫本身已經提供 GGUF 檔案，可以直接在命令列中使用 -hf 參數，例如：

`1`	`llama-cli -hf ggml-org/gemma-3-1b-it-GGUF`

預設情況下，這個參數會從 Hugging Face 下載模型。
如果你使用的是其他相容 Hugging Face API 的模型託管服務，也可以透過環境變數 MODEL_ENDPOINT 切換下載端點。

需要注意的是，llama.cpp 只能直接使用 GGUF 格式。
如果拿到的是其他格式的模型檔案，就需要先用倉庫中的 convert_*.py 腳本轉換成 GGUF。

Hugging Face 也提供了一些和 llama.cpp 相關的線上工具，常見用途包括：

把模型轉換為 GGUF
對模型做量化，縮小體積
轉換 LoRA 適配器
在線編輯 GGUF 中繼資料
直接託管 llama.cpp 推理服務

如果只想記住一個最實用的結論：優先找已經提供 GGUF 的模型倉庫，然後直接用 llama-cli -hf <user>/<model>，通常是最省事的做法。

Hugging Face 選擇 Llama 的 GGUF 模型時，量化怎麼選：從 Q8 到 Q2 的實用建議

Sat, 11 Apr 2026 20:07:29 +0800

在 Hugging Face 選擇 Llama 的 GGUF 模型時，可以先把量化等級理解成「解析度」。解析度越低，所需 VRAM/RAM 越少，但品質也會逐步下降。

先理解 32、16 與 Q 系列

32：可視為原始未壓縮版本，品質最高，但硬體需求非常高。
16：仍接近原始品質，體積約為 32 的一半，實用性更高。
Q8：從這裡開始是量化版本，常見寫法為 Q8_0 或 Q8。
Q6、Q5、Q4、Q3、Q2：數字越小，資源占用越低，品質損失也越明顯。

`K_M` / `K_S` 是什麼

K_M 與 K_S 代表混合量化策略：

大部分權重使用目前量化等級
部分關鍵區塊保留較高精度

所以同等級下，Qx_K_M 或 Qx_K_S 通常會比純 Qx 稍好。

實用選型建議

硬體足夠：優先 Q8。
記憶體或顯存吃緊：逐步下調到 Q6 / Q5 / Q4。
建議下限：盡量不要低於 Q4，可優先 Q4_K_M。
Q3 以下：可見品質下降會更明顯。

品質梯度（高到低）

32
16

– 在這一點之上，品質是一樣的，但是硬體要求太瘋狂了 –

Q8
Q6_K_M
Q6_K_S
Q6
Q5_K_M
Q5_K_S
Q5

– 這是典型的甜蜜點 –

Q4_K_M
Q4_K_S
Q4

– 在這一點之下，品質下降變得可見 –

Q3_K_M
Q3_K_S
Q3
Q2_K_M
Q2_K_S
Q2

如果只記一個結論：大多數情況先從 Q8 或 Q6_K_M 開始，不夠再降到 Q5 或 Q4_K_M，通常更穩妥。

從 Hugging Face 下載 GGUF 模型並匯入 Ollama

Thu, 09 Apr 2026 11:00:07 +0800

如果某個模型在 Ollama 官方庫裡沒有現成版本，或你想使用 Hugging Face 上的特定 GGUF 檔案，就可以先手動下載，再匯入到 Ollama。

第 1 步：從 Hugging Face 下載 GGUF 檔案

先到 Hugging Face 找到目標模型對應的 GGUF 檔案。通常你會看到多個量化版本，例如：

Q4_K_M
Q5_K_M
Q8_0

要選哪個版本，取決於你的 VRAM、RAM，以及你對速度與品質的取捨。下載後請把 .gguf 檔案放在固定目錄，後續才能在 Modelfile 中直接引用。

第 2 步：撰寫 Modelfile

在模型檔案所在目錄建立一個 Modelfile。最基本的寫法如下：

`1`	`FROM ./model.gguf`

如果檔名不同，請改成實際檔名，例如：

`1`	`FROM ./gemma-3-12b-it-q4_k_m.gguf`

如果你只是先讓模型跑起來，通常這一行 FROM 就夠了。

第 3 步：匯入到 Ollama

接著執行：

`1`	`ollama create myModelName -f Modelfile`

myModelName 是你想在 Ollama 內使用的本地模型名稱
-f Modelfile 表示用這個設定檔建立模型

建立成功後，這個 GGUF 檔案就會成為可直接呼叫的本地模型。

第 4 步：執行模型

建立完成後直接執行：

`1`	`ollama run myModelName`

之後它的使用方式就和用 ollama pull 拉下來的模型差不多。

如何查看現有模型的 Modelfile

如果你不確定 Modelfile 要怎麼寫，可以直接查看現有模型的設定：

`1`	`ollama show --modelfile llama3.2`

這個命令會輸出 llama3.2 的 Modelfile，很適合作為參考：

FROM 該怎麼寫
模板與 system prompt 如何組織
參數如何宣告

什麼時候適合用這條路線

以下情境很適合用 Hugging Face 手動匯入流程：

Ollama 官方庫裡還沒有你要的模型
你想使用特定的量化版本
你已經手動下載好 GGUF 檔案
你希望更細緻地控制模型封裝方式

如果 Ollama 官方庫已經有現成版本，直接 pull 通常更省事；但當你需要特定量化或自訂封裝時，GGUF + Modelfile 會更有彈性。

常見注意事項

FROM 後面的路徑必須和實際 .gguf 檔案位置一致。
如果檔名包含空格或特殊字元，建議先改成較簡單的名稱。
不同 GGUF 量化版本對記憶體與速度影響很大，匯入成功不代表執行一定順暢。
若模型是聊天模型，後續通常仍需依其格式調整 prompt 模板，效果才會更穩定。

結論

從 Hugging Face 下載 GGUF 檔案再匯入 Ollama 並不複雜。準備好模型檔案、寫一個最小可用的 Modelfile，再執行 ollama create，就能把第三方 GGUF 模型接入 Ollama 工作流。

GGUF on KnightLi的博客

Qwen3.6-35B-A3B 越獄版本地部署：無審查 GGUF、llama.cpp 與安全邊界

這個模型是什麼

為什麼 35B 模型還能在本地跑

推薦量化怎麼理解

llama.cpp 部署思路

多模態能力怎麼用

OpenAI API 相容介面

對接 Hermes 和 OpenClaw 的意義

無審查模型的風險邊界

適合誰嘗試

簡單結論

RTX 3070 8GB 本地運行 Qwen3.6-35B：llama.cpp 部署要點與最佳化參數

測試環境

為什麼 8GB 顯存也有機會跑 35B

準備 llama.cpp

下載模型和多模態投影檔案

RTX 3070 8GB 啟動參數

關鍵參數怎麼理解

常見問題

適合誰嘗試

小結

llama.cpp b9196 更新：Windows 預編譯版支援 CUDA 13.1、Vulkan、HIP 和 SYCL

llama.cpp 適合做什麼

Windows 預編譯版本怎麼選

啟動普通 GGUF 模型

啟動多模態視覺模型

用 bat 腳本管理多個模型

模型選擇要看三件事

常見問題

小結

適合 RTX 3060 顯卡運行的本地 LLM 模型推薦

先看顯存邊界

推薦一：Qwen3 8B

推薦二：Llama 3.1 8B Instruct

推薦三：Gemma 3 12B

推薦四：DeepSeek R1 Distill Qwen 8B

推薦五：Phi / MiniCPM / 小尺寸模型

量化怎麼選

用什麼工具運行

上下文不要開太大

不同用途怎麼選

3060 本地 LLM 的合理預期

小結

參考連結

本地部署 Qwen3.6：27B 與 35B-A3B 各量化版本需要多少顯存

先看結論

官方權重體積

Qwen3.6-27B 顯存表

Qwen3.6-35B-A3B 顯存表

27B 和 35B-A3B 怎麼選

為什麼長上下文會吃掉大量顯存

怎麼選

參考來源

本地部署 Gemma 4：E2B、E4B、26B、31B 各量化版本需要多少顯存

先看結論

Gemma 4 E2B 顯存表

Gemma 4 E4B 顯存表

Gemma 4 26B A4B 顯存表

Gemma 4 31B 顯存表

為什麼實際占用會比檔案體積更高

怎麼選

參考來源

llama-quantize 怎麼用：GGUF 模型量化入門

基本用法

常見參數

量化怎麼選

實用建議

llama.cpp 如何從 Hugging Face 取得 GGUF 模型

Hugging Face 選擇 Llama 的 GGUF 模型時，量化怎麼選：從 Q8 到 Q2 的實用建議

先理解 32、16 與 Q 系列

K_M / K_S 是什麼

實用選型建議

品質梯度（高到低）

從 Hugging Face 下載 GGUF 模型並匯入 Ollama

第 1 步：從 Hugging Face 下載 GGUF 檔案

第 2 步：撰寫 Modelfile

第 3 步：匯入到 Ollama

第 4 步：執行模型

如何查看現有模型的 Modelfile

`K_M` / `K_S` 是什麼