本地大模型 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

Claude Code + Ollama 本地部署教學：用 CC Switch 打造免費 AI 編程助手

Fri, 15 May 2026 23:27:50 +0800

最近 Claude Code 這類 AI 編程助手很受關注。它的吸引力不只是能聊天寫程式碼，而是可以讀取專案、修改檔案、執行命令、安裝依賴，甚至根據錯誤反覆修正，接近一個可操作的 Agent。

問題在於成本。專案一大，上下文變長，多輪 Agent 操作很容易消耗大量 API 額度。對於只是想試用、改小工具、寫腳本、處理本地私有專案的使用者來說，大家自然會想到：能不能保留 Claude Code 的操作體驗，但把模型換成本地執行？

這套方案的關鍵工具是 CC Switch。它可以讓 Claude Code 透過 OpenAI 相容 API 連接本地 Ollama 服務，從而把請求轉發到本地模型，而不是直接走官方 Claude API。

這套方案解決什麼問題

可以把整個流程理解為：

1
2
3

Claude Code 桌面端
+ CC Switch API 轉發層
+ Ollama 本地模型

Claude Code 仍然負責編程工作流和專案操作，CC Switch 負責模型供應商配置與 API 相容，Ollama 則負責在本機執行模型。

這並不代表本地模型會突然變成 Claude。它真正有價值的地方，是讓 Claude Code 的 Agent 工作流可以用在低成本、離線、私有化的本地場景。

基本準備

開始之前，需要先準備幾個元件：

安裝 Git。
安裝 Ollama。
拉取一個適合編程的本地模型。
安裝 CC Switch。
本機可以使用 Claude Code。

模型方面，可以先從偏程式碼能力的模型開始，例如 Qwen Coder、DeepSeek Coder，或其他具備較好工具呼叫和程式碼生成能力的模型。模型越大，效果可能越好，但記憶體與 GPU 壓力也會同步上升。

如果電腦記憶體有限，建議先用較小模型跑通流程，再逐步嘗試更大的模型。

CC Switch 關鍵配置

Ollama 啟動後，預設本地 API 位址通常是：

`1`	`http://127.0.0.1:11434/v1`

在 CC Switch 中選擇 OpenAI 相容的供應商類型，常見選項是：

`1`	`OpenAI Chat Completions`

然後把 base URL 指向 Ollama 的本地位址。

API key 欄位對本地 Ollama 來說通常不需要真實金鑰，但很多工具仍會要求環境變數或佔位值。可以使用：

`1`	`ANTHROPIC_API_KEY`

或其他本地配置可接受的佔位變數。

有一個配置項需要特別注意：

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

它表示把 Claude Code 預期的模型角色映射到本地供應商。實際使用時，需要把 haiku、sonnet、opus 對應到 Ollama 或 CC Switch 中可用的模型名稱。映射錯了，Claude Code 可能無法呼叫模型，或者一直回落到非預期配置。

Claude Code 強在哪裡

Claude Code 最有價值的地方不是單次補全，而是整套編程工作流：

讀取並理解專案結構；
根據任務定位相關檔案；
直接修改程式碼；
執行命令與測試；
觀察錯誤後繼續迭代；
在一個會話中完成多步任務。

這也是很多人想把 Claude Code 保留下來的原因。普通聊天介面可以生成程式碼片段，但不會自然地在倉庫裡操作。Claude Code 更像是一個能執行任務的開發助手。

Ollama 在這裡扮演什麼角色

Ollama 負責本地模型的執行與管理。它處理模型下載、載入和本地推理。

它的優點很明確：請求留在本機，反覆使用不會產生 API 帳單，在網路受限時也能使用。對私有程式碼來說，這也比把每一輪上下文都送到雲端模型更容易接受。

代價同樣明確。本地模型高度依賴硬體和模型品質。較小模型能處理簡單修改、解釋、腳本生成，但遇到大型跨檔案重構或細節很多的架構判斷時，能力會明顯下降。

體驗邊界在哪裡

這套方案不適合被理解成對 Claude 雲端強模型的完整替代。

你可能遇到這些問題：

長上下文理解能力較弱；
複雜任務中的工具呼叫不穩定；
純 CPU 機器推理速度較慢；
更容易幻覺出不存在的檔案路徑或 API；
多輪規劃可靠性不足；
大型專案重構成功率較低。

所以更合理的期待是：把它當成免費本地開發助手，而不是頂級雲端模型的完美替身。

多模態相容性還不穩定

有些使用者希望 Claude Code 處理截圖、UI 圖片、流程圖或其他多模態輸入。這一部分取決於本地模型和轉發層的支援情況。

如果選用的 Ollama 模型不支援視覺，或者 CC Switch 沒有正確轉換請求格式，多模態功能就可能失效。即使用了視覺模型，行為也可能和 Claude 官方 API 不完全一致。

因此目前更建議把這套方案用在文字與程式碼工作流上，多模態能力暫時按實驗功能看待。

適合誰嘗試

這套方案適合：

想低成本體驗 Claude Code 工作流的開發者；
經常寫腳本、小工具、自動化流程的使用者；
希望程式碼盡量留在本機的團隊；
想學習 AI 編程助手但不想持續消耗 API 的新手；
正在測試不同本地程式碼模型的人。

如果你高度依賴長上下文、大型 monorepo、嚴格程式碼審查品質，或複雜全專案重構，它可能還不夠穩。

使用建議

建議先從小任務開始。

例如：

解釋單個檔案；
重構一個小函式；
生成一段 shell 腳本；
修復一個簡單錯誤；
增加一個小功能；
為局部模組補單元測試。

每次修改後，最好自己跑測試，或至少檢查 diff。本地模型可以提高效率，但不應該盲目接受所有修改。

如果模型經常丟失上下文，就縮小任務範圍。不要讓它「重構整個專案」，而是改成「重構這個函式」或「為這個檔案增加校驗」。

小結

Claude Code + CC Switch + Ollama 是一個很有意思的組合。它把 Claude Code 的 Agent 式開發體驗保留下來，同時把模型推理搬到本地。

它最大的優勢是成本低、資料更私有、工作流順手；限制也很明顯，模型品質、硬體性能、長上下文和工具呼叫穩定性都會影響最終體驗。

如果你已經在用 Ollama，又想要一套更接近實戰的本地 AI 編程流程，這個方案值得試試。只是要記住：先從小任務開始，每次改動都要驗證，把本地模型當助手，而不是自動工程師。

本地執行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的嘗試

Mon, 11 May 2026 08:51:37 +0800

Antirez 開源了一個新專案：ds4。它不是通用 LLM 框架，而是一個面向 DeepSeek V4 Flash 的本地推理引擎，重點放在 Apple Silicon 和 Metal 後端上。

專案地址：https://github.com/antirez/ds4

ds4 是什麼

ds4 的目標很明確：在 Mac 上本地執行 DeepSeek V4 Flash。

它目前提供三種使用方式：

互動式 CLI。
HTTP server。
一個實驗性的 Agent 模式。

從定位看，它更像是一個針對特定模型深度最佳化的推理專案，而不是要取代 llama.cpp、Ollama 或 vLLM 這類通用工具。

為什麼值得關注

這類專案值得看，主要有三個原因。

第一，作者是 Redis 作者 Antirez。他長期關注底層系統、效能和簡單工具，專案風格通常比較直接。

第二，DeepSeek V4 Flash 屬於面向高效推理的模型方向。如果本地執行體驗足夠好，對 Mac 使用者來說會很有吸引力。

第三，ds4 直接面向 Apple Metal。相比「先支援所有平台，再慢慢最佳化」的路線，它更像是先把一個明確場景做深。

適合誰用

ds4 更適合這幾類使用者：

使用 Apple Silicon Mac。
想在本地執行 DeepSeek V4 Flash。
關注 Metal 推理效能。
願意嘗試 alpha 階段專案。
想研究輕量推理引擎和模型執行細節。

如果你的目標是穩定部署、跨平台執行、OpenAI API 相容生態，現階段它未必是首選。它更適合作為實驗工具和技術觀察對象。

使用方式

專案 README 給出的基本流程是先建置，再執行。

1
2
3

git clone https://github.com/antirez/ds4.git
cd ds4
make

互動式執行：

./ds4

啟動 HTTP server：

`1`	`./ds4 --server`

Agent 模式：

`1`	`./ds4 --agent`

具體參數和模型檔案準備方式，建議以倉庫 README 為準，因為專案仍在快速變化。

目前的風險

ds4 還處在早期階段，使用前要有預期：

功能可能不完整。
參數、模型格式和命令列行為可能變化。
相容性主要圍繞 Apple Silicon 和 Metal。
Agent 模式更偏實驗，不適合直接用於生產流程。
遇到問題時，需要自己閱讀 README、issue 或原始碼排查。

也就是說，它現在更像「值得動手試的開源實驗」，還不是面向普通使用者的一鍵工具。

和通用推理工具的區別

通用推理工具通常追求模型格式、平台、後端和 API 的廣泛相容。ds4 的方向更窄：圍繞 DeepSeek V4 Flash 和 Metal 做本地執行。

這種選擇有利有弊。

好處是實作可以更集中，效能和體驗更容易圍繞單一目標最佳化。代價是適用範圍有限，不適合拿來執行各種不同模型，也不適合取代完整的部署平台。

如果你已經在用 llama.cpp 或 Ollama，ds4 可以作為補充測試工具，而不是馬上替換現有工作流。

小結

ds4 的看點不在「又一個本地大模型工具」，而在於它把範圍收得很窄：DeepSeek V4 Flash、Apple Silicon、Metal、本地推理。

如果你手上有合適的 Mac，並且願意折騰早期專案，可以關注它後續的效能表現、模型支援方式和 server/agent 能力演進。對於生產環境，建議繼續觀望，等介面和使用方式穩定後再評估。

參考

GitHub 專案：https://github.com/antirez/ds4

llama.cpp 多 GPU 性能實測思路：2x V100 16GB 會比單卡 32GB 快嗎？

Sat, 09 May 2026 15:05:41 +0800

大概結論：llama.cpp 多 GPU offload 不是「多一張卡就白撿一倍性能」。如果模型本來能完整放進一張 32GB 顯卡，2x V100 16GB 通常不如單張 32GB 顯卡省心，甚至可能更慢；如果模型單張 16GB 放不下，雙卡的主要價值是「能把模型放進 GPU」，這時收益會很明顯。

先分清 split mode

llama.cpp 的多 GPU 主要圍繞 --split-mode 和 --tensor-split 使用。實際討論性能時，先要區分幾種模式：

layer：按層切分到不同 GPU，兼容性較好，也是多數人優先嘗試的方式。
tensor：把張量計算拆到多張 GPU 上，更接近並行計算，但更依賴 GPU 之間的互聯頻寬和後端支援。
row：舊的行切分方式，在不少場景裡仍能看到，但新部署通常不建議優先從它開始。

簡單說，layer 更像「把不同樓層放在不同卡上」，單 token 生成時不一定能讓兩張卡同時滿負載；tensor 更像「同一層兩張卡一起算」，理論上更能並行，但跨卡通訊會成為關鍵瓶頸。

單卡 32GB 能放下時：雙 16GB 不一定更快

如果模型和 KV cache 能完整放進一張 32GB 顯卡，那麼單卡通常更穩，也常常更快。對 1x V100 32GB 和 2x V100 16GB 這類同代硬體來說，後者未必能贏。

比較保守的預期是：2x V100 16GB 可能比單張 V100 32GB 慢 10% 到 40%，尤其是單人聊天、Continue Agent、程式碼問答這類一次主要生成一個回答的場景。

原因不複雜：多 GPU 不是簡單合併顯存。按層切分時，推理會在不同 GPU 之間流轉，單 token 生成階段經常是部分 GPU 等另一部分 GPU；按張量切分時，兩張卡可以一起算，但中間結果需要跨卡同步，互聯頻寬和延遲會直接影響吞吐。

所以如果你的選擇是：

1x V100 32GB
2x V100 16GB

並且目標模型單張 32GB 已經能完整放下，那麼單張 32GB 往往是更舒服的選擇。

單卡 16GB 放不下時：雙卡價值很大

另一種情況完全不同：模型單張 16GB 放不下，但兩張 16GB 合起來可以放下。

這時雙卡的價值就很直接：

單張 16GB：可能需要大量 CPU offload，速度明顯變慢。
2x 16GB：權重盡量留在 GPU 上，速度可能比 CPU/GPU 混跑快很多。

這種場景下，2x V100 16GB 不一定比單張 32GB 快，但它可能比「單張 16GB 加大量系統記憶體 offload」快幾倍。也就是說，雙卡的第一價值不是加速，而是避免模型被迫落到更慢的系統記憶體裡。

V100 PCIe 和 V100 SXM2 差別很大

多 GPU 推理最容易被忽略的是互聯。

如果是 V100 SXM2，並且機器裡有 NVLink，跨卡通訊頻寬高很多。NVIDIA 的 V100 資料裡，NVLink 互聯最高可到 300GB/s。這種環境下，tensor 或更高 batch 的場景才更有機會接近甚至超過單卡表現。

如果是 V100 PCIe，情況就保守得多。V100 PCIe 的互聯主要走 PCIe Gen3，資料裡標的 interconnect bandwidth 是 32GB/s。這個頻寬和 NVLink 不是一個量級，所以雙卡經常出現「顯存夠了，但速度沒有翻倍」的情況。

因此判斷 2x V100 16GB 值不值得，不能只看顯存相加是 32GB，還要看它們是 PCIe 版還是 SXM2/NVLink 版。

怎麼選更實際

如果模型能放進單張 32GB 顯卡，優先選單卡。它的延遲、穩定性和調參成本通常更好。

如果模型單張 16GB 放不下，而兩張 16GB 能放下，雙卡值得用。此時重點是讓權重盡量留在 GPU，而不是期待性能線性翻倍。

如果是 V100 PCIe 雙卡，優先嘗試 --split-mode layer，把目標放在「能穩定跑」和「少走 CPU」上。

如果是 V100 SXM2/NVLink，才更值得測試 tensor 相關模式，尤其是 prefill、大 batch 或併發請求場景。

什麼時候買 2x16GB，什麼時候買 1x32GB

如果你只服務一個人，主要做聊天、程式碼補全、Continue Agent、長上下文問答，並且目標模型能放進 32GB，那麼 1x32GB 通常更值得。它少了跨卡調度，延遲更穩定，排查問題也簡單。

如果你已經有一張 16GB 卡，想用較低成本擴到能跑 30B、32B 或更高量化模型，2x16GB 就有意義。它不一定讓 token/s 翻倍，但可以把原本必須 CPU offload 的權重留在 GPU 上。

如果你準備重新採購，優先級可以這樣排：

單模型、單使用者、重視回應延遲：優先 1x32GB。
模型單卡放不下、預算有限：可以考慮 2x16GB。
有 NVLink 或 SXM2 機器：2x16GB 的可玩性明顯高於普通 PCIe 雙卡。
未來想跑更長上下文：不要只看權重大小，還要預留 KV cache 顯存。

layer split 和 tensor split 怎麼用

實用建議是：先用 layer，再測 tensor。

layer 適合作為預設起點。它按層分配模型，兼容性較好，對 PCIe 雙卡更友好。缺點是生成階段可能更像流水線，某些時刻只有一張卡在忙，另一張卡在等。

tensor 更適合互聯頻寬好的機器，例如 V100 SXM2/NVLink。它把同一層的部分計算拆到多張卡上，理論上更有並行空間，但跨卡同步更頻繁。如果是 PCIe 雙卡，tensor 可能會被通訊開銷吃掉收益。

實際測試時可以從這幾組開始：

1
2
3

llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,0

第三條不是為了長期使用，而是給單卡結果做一個參照。這樣才能看出雙卡到底是更快，還是只是把顯存壓力分攤出去了。

prefill 和 decode 為什麼表現不同

本地大模型性能通常要分成兩個階段看：

prefill：處理輸入 prompt，典型指標是 pp512 這類 prompt processing 吞吐。
decode：逐 token 生成回答，典型指標是 tg128 這類 token generation 吞吐。

prefill 更像大批量矩陣計算，batch 較大時更容易把 GPU 餵飽，也更可能從多 GPU 並行裡受益。decode 是一個 token 接一個 token 生成，batch 小、同步頻繁，跨卡通訊和調度延遲更容易暴露出來。

所以你可能會看到一種結果：雙卡的 pp512 更好，但 tg128 沒明顯提升，甚至更慢。對聊天和 Agent 來說，使用者體感更接近 tg128；對長文件導入、批量預填充、併發服務來說，pp512 也很重要。

KV cache 會不會成為第二個顯存瓶頸

會。很多人只算模型權重，忘了 KV cache。

模型權重決定「能不能載入模型」，KV cache 決定「能不能開足上下文」。上下文越長、併發越高、batch 越大，KV cache 佔用越明顯。你可能遇到這種情況：模型本體能放進 32GB，但一開 32K 或 64K 上下文，顯存又不夠了。

判斷時至少要留出幾塊顯存餘量：

KV cache
CUDA graph 或後端執行時開銷
prompt batch 和 ubatch
系統桌面、驅動和其它程序佔用

如果你用的是 2x16GB，顯存不是一個完全等價的 32GB 大池子。某些緩衝區、KV cache 或中間張量仍然會受單卡剩餘顯存影響。測試長上下文時，最好直接用目標 --ctx-size 和目標併發數測，而不是只看模型能不能啟動。

用 llama-bench 做自己的雙卡測試

llama-bench 比直接聊天更適合做硬體對比，因為它會把 prompt processing 和 token generation 拆成可比較的指標。官方 README 的預設示例就是：

`1`	`llama-bench -m model.gguf`

對雙 V100，可以至少測這幾組：

# 單卡基線
CUDA_VISIBLE_DEVICES=0 llama-bench -m model.gguf -ngl 99

# 雙卡 layer split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1

# 雙卡 tensor split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1

重點看兩列：

pp512：prompt processing，長輸入和批量預填充更相關。
tg128：token generation，單人聊天和 Agent 體感更相關。

測試時盡量固定模型、量化格式、上下文、batch、驅動版本和 llama.cpp 版本。每組多跑幾次，取中位數，比只看一次結果可靠。最後再用真實工作流跑一遍，例如 Continue Agent、OpenAI-compatible server 或你自己的 RAG 請求，因為 benchmark 好看不代表互動體驗一定更好。

一句話結論

2x V100 16GB 的優勢主要是顯存容量，而不是必然的生成速度。模型單卡能放下時，單張 32GB 往往更快、更穩；模型單卡放不下時，雙 16GB 的價值就很大，因為它能避免大量 CPU offload。至於能不能更快，關鍵看 split mode、batch、模型大小，以及兩張 V100 之間到底是 PCIe 還是 NVLink。

參考資料：

RTX 5090 / 5080 AI 推理效能實測：本地大模型、4K 影片生成和即時 3D 怎麼選

Fri, 08 May 2026 10:07:19 +0800

RTX 50 系列真正讓本地 AI 使用者興奮的，不只是遊戲幀率，而是 Blackwell 架構、GDDR7 顯存和第五代 Tensor Core 帶來的推理潛力。對跑本地大模型、圖像生成、影片增強和即時 3D 工作流的人來說，顯卡已經不只是渲染設備，而是桌面級 AI 工作站的核心。

但 RTX 5090 和 RTX 5080 的差距不能只看型號。它們都屬於 Blackwell，都支援 DLSS 4、第五代 Tensor Core 和 FP4，但在本地 AI 推理裡，真正決定體驗的往往是顯存容量、顯存頻寬、軟體支援和具體模型適配。

簡單結論是：RTX 5090 更像單卡本地 AI 的旗艦選擇，適合大模型、長上下文、圖像生成和影片 AI；RTX 5080 更適合預算有限、模型規模較小、以 16GB 顯存可覆蓋的工作流。兩者都比上一代有進步，但不是所有 AI 應用都會立刻吃滿 Blackwell 的新能力。

先看硬體差距

RTX 5090 的關鍵規格是 32GB GDDR7、512-bit 顯存位寬、21760 個 CUDA Core 和 3352 AI TOPS。公開測試中，Puget Systems 也強調它的顯存頻寬達到約 1.79TB/s，相比 RTX 4090 的 24GB 和約 1.01TB/s 頻寬，對 AI 工作負載很有意義。

RTX 5080 的規格則更克制：16GB GDDR7、256-bit 顯存位寬、10752 個 CUDA Core 和 1801 AI TOPS。它的頻寬約 960GB/s，比 RTX 4080 系列提升明顯，但顯存容量仍停在 16GB。

這意味著兩張卡的定位非常清楚：

RTX 5090 的優勢是 32GB 顯存和高頻寬，適合更大的模型、更長上下文和更重的多模態任務。
RTX 5080 的優勢是價格和功耗相對可控，適合中小模型、圖像生成、輕量影片處理和開發調試。
如果任務已經被顯存卡住，RTX 5080 的計算能力再強也很難彌補 16GB 的限制。
如果任務主要受軟體最佳化限制，RTX 5090 也未必總能比 RTX 4090 拉開理論規格對應的差距。

本地 AI 推理經常是「顯存先決定能不能跑，頻寬再決定跑得快不快」。這也是 RTX 5090 對本地大模型使用者吸引力更強的原因。

本地大模型：32GB 顯存更關鍵

跑 LLM 時，顯存主要被三類東西占用：模型權重、KV cache 和執行時開銷。模型越大、上下文越長、並發越高，顯存壓力越明顯。

RTX 5080 的 16GB 顯存可以覆蓋不少 7B、8B、14B 級別模型，也能透過 4-bit 量化執行一部分更大的模型。但當使用者想跑 30B 級別模型、提高上下文長度，或者同時開 WebUI、RAG、語音和工具調用時，16GB 很容易變成瓶頸。

RTX 5090 的 32GB 顯存給了本地推理更多空間。它更適合：

執行 30B 左右的量化大模型。
在 7B、14B 模型上保留更長上下文。
做本地程式碼助手、知識庫問答和 Agent 調試。
同時載入嵌入模型、重排模型或多模態元件。
在單機環境裡減少頻繁換模型和降低上下文的麻煩。

不過，32GB 也不是萬能。70B 級別模型即使用 4-bit 量化，也常常需要更謹慎地控制上下文、執行參數和顯存碎片。想要高並發服務，多卡或伺服器 GPU 仍然更合適。

如果只是個人使用，RTX 5090 的體驗優勢主要體現在「少折騰」：可選模型更多，長上下文更寬鬆，圖形介面和周邊工具也更容易同時執行。

FP4 是潛力，不是所有應用的即插即用加速

Blackwell 的重要變化之一是第五代 Tensor Core 支援 FP4。NVIDIA 在 TensorRT 相關資料中提到，FP4 可以降低模型的顯存占用和資料搬運壓力，並用於 FLUX 等生成式模型的本地推理最佳化。

這對圖像生成和未來的大模型推理很重要。低精度不只意味著更少顯存，也意味著更低頻寬壓力。對於 RTX 5090 這種高頻寬顯卡，FP4 如果被框架和模型充分支援，理論上會進一步放大優勢。

但現實是，FP4 的收益取決於軟體鏈路：

模型是否有合適的 FP4 量化版本。
推理框架是否支援對應算子。
TensorRT、ComfyUI、PyTorch、ONNX 或外掛是否完成適配。
精度損失是否能被具體任務接受。
使用者是否願意為了效能調整工作流。

所以現在評價 RTX 50 系列 AI 效能，不能只看 FP4 峰值。更穩妥的判斷是：Blackwell 給了 FP4 硬體基礎，但實際體驗要看應用更新速度。早期使用者會先吃到部分收益，主流使用者需要等待生態成熟。

圖像生成和 4K 影片：頻寬與顯存一起決定體驗

Stable Diffusion、FLUX、影片超分、插幀、去噪、去背和生成式影片都對顯存敏感。解析度越高，顯存占用越大；節點越多，執行時開銷越高；同時啟用 ControlNet、LoRA、高清修復和批量生成時，顯存壓力會繼續上升。

RTX 5080 在 16GB 顯存內可以完成很多圖像生成任務。對 1024px 級別圖像、輕量 LoRA、常規 ComfyUI 工作流來說，它已經足夠快。問題出現在更大的畫布、更複雜節點、更高 batch，或者影片生成這類長序列任務裡。

RTX 5090 的優勢在 4K 影片相關工作流裡更明顯：

32GB 顯存更適合高解析度幀、長序列和複雜節點圖。
1.79TB/s 級別頻寬有利於減少資料搬運瓶頸。
三個第九代 NVENC 編碼器對影片匯出、轉碼和創作流程更友好。
FP4 和 TensorRT 適配成熟後，圖像生成模型可能獲得更明顯收益。

不過，公開影片 AI 實測也提醒了一點：應用最佳化還沒完全跟上硬體。Puget Systems 在 DaVinci Resolve AI 和 Topaz Video AI 測試中發現，RTX 5090 並不是每個項目都能大幅領先 RTX 4090，RTX 5080 也沒有總是拉開 RTX 4080 系列。這說明影片 AI 不是單純堆規格，外掛、驅動和模型實作同樣重要。

換句話說，如果你的工作流已經明確支援 Blackwell、TensorRT 或 FP4，RTX 50 系列更值得期待；如果主要依賴還沒最佳化的商業軟體，升級收益要看具體版本。

即時 3D 和 AI 建模：RTX 5090 更適合重場景

即時 3D 建模、神經渲染、3D 資產生成和視口 AI 加速通常會同時消耗 CUDA、RT Core、Tensor Core 和顯存。它和純 LLM 不同，不只是 token 生成速度，還包括場景複雜度、材質、幾何、光追、AI 降噪和視口幀率。

RTX 5080 可以勝任很多 4K 遊戲、即時預覽和中等規模創作項目。對獨立創作者來說，它是比較現實的高效能選擇。

RTX 5090 更適合下面幾類場景：

複雜 3D 場景即時預覽。
高解析度材質和大規模資產。
AI 降噪、超分和生成式輔助建模同時開啟。
D5 Render、Blender、Unreal Engine 等工具中的重負載工作。
需要邊建模邊執行本地 AI 助手或圖像參考生成。

NVIDIA 宣稱 RTX 50 系列在創作應用中可提升生成式 AI、影片編輯和 3D 渲染效率，但實際項目裡仍要看軟體是否調用了新硬體路徑。對生產環境來說，最可靠的辦法仍然是用自己的項目檔測試，而不是只看宣傳圖表。

該怎麼選

如果你的目標是本地大模型，優先看顯存。16GB 的 RTX 5080 可以跑很多輕量模型，但更像「高效能入門本地 AI 卡」；32GB 的 RTX 5090 才更接近「單卡本地大模型工作站」。

如果你的目標是圖像生成，RTX 5080 已經能覆蓋很多日常工作流；如果你經常做高解析度、多節點、批量生成、FLUX 或影片生成，RTX 5090 的顯存餘量更重要。

如果你的目標是 4K 影片 AI，RTX 5090 更穩，但要確認具體軟體版本。Topaz、DaVinci Resolve、ComfyUI、TensorRT 外掛和驅動版本都可能影響結果。

如果你的目標是即時 3D 建模，RTX 5080 可以滿足很多創作需求；RTX 5090 更適合重場景、多應用並行和長時間生產。

如果你已經有 RTX 4090，升級要謹慎。RTX 5090 的顯存和頻寬更強，但部分現有 AI 軟體還未完全釋放 Blackwell 優勢。除非你明確需要 32GB 顯存、更高頻寬或新編碼器，否則可以等軟體生態再成熟一些。

如果你還在使用 RTX 30 系列或更老顯卡，RTX 50 系列的升級感會明顯很多。尤其是從 8GB、10GB、12GB 顯存升級到 16GB 或 32GB，本地 AI 的可用範圍會直接擴大。

小結

RTX 5090 和 RTX 5080 都把消費級顯卡推向了更強的本地 AI 時代，但它們適合的人並不一樣。

RTX 5090 的價值在於 32GB GDDR7、超高顯存頻寬和更完整的創作硬體配置。它適合想在單機上跑更大模型、更複雜圖像生成、更重影片 AI 和即時 3D 工作流的人。

RTX 5080 的價值在於用相對低的成本進入 Blackwell 平台。它適合 16GB 顯存能覆蓋的中小模型、日常圖像生成、開發測試和高效能創作。

真正的選購原則很簡單：先看你的模型和項目能不能放進顯存，再看軟體是否已經最佳化 Blackwell，最後才看理論 AI TOPS。對本地 AI 來說，能穩定跑完，比峰值數字更重要。

參考資料

DeepSeek V4 本地私有化部署方案：國產晶片與消費級顯卡叢集怎麼選

Fri, 08 May 2026 09:39:35 +0800

DeepSeek V4 發布後，很多企業開始關注一個問題：能不能不走外部 API，把模型部署在自己的機房、私有雲或專有叢集裡？

這個需求很現實。金融、醫療、政企、製造、法律和研發團隊往往不能把內部文檔、程式碼、合約、工單、客戶資料直接發到公有雲模型。對這些場景來說，DeepSeek V4 的吸引力不只是模型能力，而是它給了企業一個更接近「可控大模型基礎設施」的選擇。

不過，DeepSeek V4 本地部署不是下載模型、找幾張顯卡就能跑起來。尤其是 Pro 這類超大 MoE 模型，總參數規模、啟用參數、上下文長度、KV cache、並發量和推理框架都會直接決定硬體成本。企業真正要做的不是盲目追求滿血版本，而是先確認業務需要哪種部署形態。

先明確部署目標

企業做本地私有化部署，常見目標有三類：

資料不出域：內部文檔、程式碼、客戶資料、日誌和知識庫不離開企業環境。
穩定可控：模型服務、權限、稽核、日誌和升級節奏由企業自己掌握。
降低長期成本：高頻調用時，本地推理可能比長期購買外部 API 更可控。

如果只是少量員工偶爾問答，本地部署不一定划算。真正適合私有化的是高頻、穩定、資料敏感、流程明確的場景，例如：

內部知識庫問答。
程式碼審查和研發助手。
客服工單總結。
合約、病歷、報告等文檔分析。
資料庫查詢助手。
Agent 工作流自動化。

這些場景的共同點是：資料敏感、調用穩定、可透過權限和日誌納入企業治理。

不要一上來就追求滿血 Pro

DeepSeek V4 常見版本包括 Pro 和 Flash。公開資料中，Pro 面向更強推理和複雜 Agent 任務，Flash 更強調成本和回應速度。企業選型時，不應預設所有業務都上 Pro。

可以按任務複雜度分層：

簡單問答、摘要、分類、標籤生成：優先考慮 Flash 或更小模型。
內部知識庫檢索增強：Flash 足夠覆蓋大量場景，重點反而是 RAG、權限和檢索品質。
程式碼 Agent、複雜推理、長上下文分析：再評估 Pro。
高價值低頻任務：可以使用 Pro，但不一定需要高並發。
普通辦公助手：沒有必要長期占用最貴的推理資源。

MoE 模型的優勢在於每次推理只啟用部分參數，但它並不等於硬體壓力很小。權重儲存、專家並行、網路通訊、上下文快取和並發調度仍然很重。尤其是 1M token 級別長上下文，真正吃掉資源的往往不是單次回答，而是長上下文、多使用者並發和持續會話。

國產晶片路線：適合企業級私有雲

如果企業已經有國產算力池，或者有信創、合規、供應鏈要求，可以優先評估昇騰、寒武紀等國產晶片路線。

這條路線的優勢是：

更符合國產化和供應鏈可控要求。
適合進入企業機房、專有雲和政企專案。
便於統一做權限、稽核、資源隔離和維運。
對長期穩定服務更友好。

但國產晶片路線也要看三個現實問題。

第一，框架適配。模型能不能跑，不只取決於晶片算力，還取決於推理框架、算子、通訊庫、量化格式、MoE 專家並行和長上下文最佳化是否成熟。

第二，工程經驗。企業需要的不只是「啟動成功」，而是穩定服務：多租戶、限流、監控、失敗恢復、灰度升級、日誌稽核、權限隔離都要補齊。

第三，生態差異。同一套模型在 NVIDIA、昇騰、寒武紀等平台上的效能、精度、量化支援和部署工具不會完全一致。上線前必須做實際壓測，而不是只看標稱算力。

因此，國產晶片更適合預算明確、合規要求高、願意投入平台工程的企業。它不是最省事的路線，但可能是最符合長期治理要求的路線。

消費級顯卡叢集：適合試點和中小團隊

如果目標是先驗證業務價值，消費級顯卡叢集更容易起步。RTX 4090、RTX 5090、RTX 3090、RTX 3060 12GB 這類顯卡在社群工具、量化模型和本地推理框架上資料更多，試錯成本更低。

消費級顯卡路線適合：

研發團隊做內部試點。
中小企業做知識庫問答。
低並發程式碼助手。
離線文檔處理。
對 SLA 要求不高的內部工具。

但它也有明顯限制：

顯存小，難以直接承載完整大模型。
多卡通訊能力弱，跨機器通訊更麻煩。
消費級硬體長期滿載穩定性不如伺服器方案。
機箱、電源、散熱、驅動和維運會變成隱性成本。
不適合一開始就承諾企業級高可用。

更現實的做法是：消費級顯卡先跑 Flash、蒸餾版、量化版或小模型，把業務流程跑通；等調用量、效果和資料治理都驗證後，再決定是否遷移到伺服器 GPU 或國產算力平台。

可能的部署架構

一個比較穩的企業私有化架構可以分成六層：

模型層：DeepSeek V4 Pro、V4 Flash，或根據任務選擇更小的蒸餾模型。
推理層：SGLang、vLLM、llama.cpp、廠商 NPU 推理棧或企業自研服務。
閘道層：統一鑑權、限流、稽核、模型路由和調用日誌。
知識層：向量庫、全文檢索、文檔解析、權限過濾和 RAG。
應用層：客服、程式碼助手、文檔分析、報表問答、Agent 工作流。
維運層：監控、告警、成本統計、灰度發布、回滾和安全稽核。

這裡最容易被低估的是閘道層和知識層。很多專案失敗，不是模型完全不能用，而是權限、檢索、日誌、上下文管理、提示詞模板和業務流程沒有做好。

企業內部部署大模型時，應該把模型當作基礎能力，而不是一個孤立聊天頁面。真正產生價值的是模型進入流程後，能不能穩定處理企業自己的資料和任務。

硬體選型思路

硬體不要只看「能不能跑」，還要看「能不能穩定服務」。

可以按階段選：

驗證階段

目標是證明業務是否值得做。

使用 1-4 張消費級顯卡。
優先跑 Flash、小模型、蒸餾模型或量化模型。
並發要求低，重點看任務完成率。
不承諾高可用。

這個階段不要過早採購大規模硬體。先確認員工是否真的用、業務是否真的省時間、回答是否能進入流程。

試點階段

目標是讓一個部門或一個業務線穩定使用。

使用 4-16 張 GPU 或一組國產 NPU 節點。
加入統一閘道、日誌和權限控制。
做 RAG、文檔解析、模型路由和快取。
開始統計 token、並發、延遲和失敗率。

這個階段要開始關注維運。模型效果只是其中一部分，穩定性、成本和資料治理同樣重要。

生產階段

目標是進入企業級服務。

使用伺服器 GPU、國產算力叢集或私有雲資源池。
建立多副本、限流、故障轉移和容量規劃。
按任務路由模型：簡單任務走輕量模型，複雜任務走 Pro。
接入企業身份系統、稽核系統和安全策略。

生產階段不建議所有請求都打到最強模型。合理的模型路由通常比堆硬體更省錢。

推理框架怎麼選

DeepSeek V4 這類模型對推理框架要求較高，尤其涉及 MoE、長上下文、稀疏注意力、量化和多卡並行時，框架成熟度會直接影響速度和穩定性。

常見選擇可以這樣理解：

SGLang：適合關注高效能推理、Agent、多輪工具調用和複雜服務編排的團隊。
vLLM：生態成熟，適合通用 LLM 服務，但具體支援要看版本和模型適配進度。
llama.cpp：更適合小模型、量化模型和邊緣部署，不適合直接承載滿血超大 MoE。
國產 NPU 推理棧：適合信創和國產算力環境，但要重點驗證算子、量化和長上下文支援。

框架選擇不要只看 benchmark。企業更應該測試自己的真實輸入：內部文檔長度、並發數、平均輸出長度、RAG 命中率、Agent 工具調用次數、失敗重試次數。

資料安全要做在模型外面

私有化部署不等於自動安全。模型跑在本地，只是解決了「資料是否離開企業」的一部分問題。

還需要補齊：

帳號和權限：不同部門只能存取自己的知識庫。
日誌稽核：誰問了什麼、調用了哪個模型、存取了哪些文檔。
資料脫敏：客戶資訊、身分證號、手機號、合約金額等敏感欄位要處理。
提示詞安全：避免使用者透過提示詞繞過權限或洩露系統提示。
輸出審查：重要場景要有人審或規則審。
資料生命週期：上傳文檔、向量索引、快取和會話記錄要能刪除。

企業做本地大模型，不能只找演算法團隊。安全、法務、維運、業務負責人都要參與，否則上線後風險會被集中暴露。

成本不要只算顯卡

本地部署的成本通常被低估。除了顯卡或 NPU，還要算：

伺服器、機櫃、電源、散熱和網路。
儲存和備份。
推理框架適配和工程開發。
維運監控和故障處理。
模型升級、回滾和相容性測試。
安全稽核和權限系統。
業務側提示詞、RAG 和工作流建設。

如果調用量很低，外部 API 可能更便宜。如果調用量高、資料敏感、流程穩定，本地部署才更容易攤薄成本。

比較合理的策略是混合部署：

高敏感資料走本地模型。
低敏感通用任務可以走外部 API。
簡單任務走小模型。
複雜任務走 DeepSeek V4 Pro。
高頻任務優先最佳化快取、檢索和模型路由。

小結

DeepSeek V4 讓企業本地私有化部署有了更強的想像空間，但它不是一個簡單的「本地版 ChatGPT」。真正的難點在工程：硬體、框架、模型路由、權限、RAG、稽核、監控和成本控制都要一起考慮。

國產晶片路線更適合合規要求高、長期建設私有雲的企業；消費級顯卡叢集更適合試點和中小團隊快速驗證。Pro 適合複雜推理和 Agent，Flash 或小模型更適合大量普通任務。

如果只記住一句話：DeepSeek V4 私有化部署不要從硬體採購開始，而要從業務場景、資料邊界和調用規模開始。先把場景跑通，再決定要不要上大模型、上多大模型、上哪種算力。

參考資料

適合 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

Hermes + Qwen3.6：本地 Agent 的一套低成本部署方案

Mon, 04 May 2026 06:40:30 +0800

這篇記錄整理一套本地 Agent 部署方案：用 llama.cpp 在 WSL2 中運行 Qwen3.6 GGUF 模型，再把 Hermes Agent 接到本地 OpenAI-compatible API。這樣可以在自己的電腦上獲得一個可長期在線的本地 AI 助手，不再按在線服務的 Token 額度計費。

這套方案適合想體驗本地 AI Agent、又希望保留資料隱私和長期可控性的使用者。它可以用於日常問答、寫作、程式碼輔助、資料整理和簡單自動化任務。需要注意的是，模型規模越大，對顯存要求越高；原文示例使用的是 Qwen3.6-27B，顯存 24GB 更穩。如果顯存較小，應選擇更小尺寸或更低量化的模型。

方案結構

整體鏈路很簡單：

Windows 上安裝 WSL2 和 Ubuntu 24.04。
在 WSL2 中安裝 CUDA Toolkit、編譯 llama.cpp。
下載 Qwen3.6 GGUF 模型。
用 llama-server 啟動本地模型服務。
安裝 Hermes Agent，並把它配置到 http://localhost:8080/v1。
可選：寫啟動腳本，讓 WSL2 打開時自動啟動模型服務。

Hermes 負責 Agent 能力，Qwen3.6 負責本地大模型能力。兩者組合後，可以把電腦變成一個本地私有 AI 助理。

安裝 WSL2 和 Ubuntu

在 Windows PowerShell 管理員視窗中執行：

1
2

wsl --install
wsl --set-default-version 2

重啟後安裝 Ubuntu 24.04：

`1`	`wsl --install -d Ubuntu-24.04`

安裝完成後，Ubuntu 會提示設定使用者名稱和密碼。進入 Ubuntu 後，先檢查 NVIDIA GPU 是否能在 WSL2 中正常識別：

`1`	`nvidia-smi`

如果無法識別 GPU，通常需要先更新 Windows 端的 NVIDIA 顯示卡驅動。WSL2 會繼承 Windows 驅動，但 CUDA Toolkit 仍需要在 WSL2 內單獨安裝。

安裝 Python 和基礎工具

`1`	`sudo apt update && sudo apt install -y python3-pip python3-venv`

後續還需要編譯工具、Git 和 CMake：

`1`	`sudo apt install -y cmake build-essential git`

編譯 llama.cpp

先拉取源碼：

1
2

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

如果 WSL2 中已經有可用 CUDA 環境，可以直接編譯：

1
2

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

CMAKE_CUDA_ARCHITECTURES=89 適合 Ada 架構顯示卡，例如 RTX 40 系列。其他顯示卡應按實際架構調整。

如果編譯時報 CUDA Toolkit 缺失，先在 WSL2 中安裝 CUDA Toolkit：

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

安裝完成後配置環境變數：

export PATH=/usr/local/cuda-12.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH
echo 'export PATH=/usr/local/cuda-12.8/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc

然後重新編譯：

cd ~/llama.cpp
rm -rf build
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

下載 Qwen3.6 GGUF 模型

原文示例使用 unsloth/Qwen3.6-27B-GGUF 中的 Qwen3.6-27B-UD-Q4_K_XL.gguf：

1
2
3

hf download unsloth/Qwen3.6-27B-GGUF \
Qwen3.6-27B-UD-Q4_K_XL.gguf \
--local-dir ~/models/

這個文件約 17GB。如果 Hugging Face 下載慢，可以換 ModelScope 等國內鏡像。顯存不足時不要硬上 27B，可以換更小模型或更低量化版本。

啟動本地模型服務

根據自己的模型文件名啟動 llama-server：

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080

啟動成功後，在 Windows 瀏覽器訪問：

`1`	`http://localhost:8080`

如果要讓 Hermes Agent 或其他 OpenAI-compatible 客戶端調用，API 地址通常是：

`1`	`http://localhost:8080/v1`

Thinking 模式取捨

Qwen3.6 預設可能啟用 Thinking 模式。它適合複雜推理、複雜程式碼問題、多步驟分析，但速度會慢一些。

如果想關閉 Thinking 模式，可以停止服務後增加 --chat-template-kwargs 參數：

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--chat-template-kwargs '{"enable_thinking":false}' \
--port 8080

關閉 Thinking 後，簡單問答、寫作、程式碼補全和解釋程式碼會更快；但複雜演算法設計、疑難 Debug 和架構分析仍建議開啟 Thinking。

安裝 Hermes Agent

保持 llama-server 運行，再新開一個 WSL2 終端安裝 Hermes Agent：

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

安裝腳本會處理 Python、Node.js、ripgrep、ffmpeg 等依賴。配置模型端點時選擇自訂 endpoint：

1
2
3

URL: http://localhost:8080/v1
API Key: 12345678
Model: 自動識別

API Key 對本地 llama-server 來說可以隨便填一個佔位值。配置完成後，可以繼續接 Telegram、微信、QQ、Discord 等聊天工具，讓 Hermes Agent 透過這些入口調用本地模型並執行任務。

自動啟動模型服務

可以寫一個啟動腳本，讓 WSL2 終端打開時自動啟動模型服務。

創建腳本：

cat > ~/start-llm.sh << 'EOF'
#!/bin/bash
echo "Starting Qwen3.6-27B llama-server..."
~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 65536 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080 \
--host 0.0.0.0 &
echo "llama-server started, PID: $!"
echo "API: http://localhost:8080/v1"
echo "Chat UI: http://localhost:8080"
EOF
chmod +x ~/start-llm.sh

寫入 .bashrc：

echo '# Auto-start llama-server' >> ~/.bashrc
echo 'if ! pgrep -f "llama-server" > /dev/null 2>&1; then' >> ~/.bashrc
echo '    ~/start-llm.sh' >> ~/.bashrc
echo 'fi' >> ~/.bashrc

這樣每次打開 WSL2 終端時，如果 llama-server 沒有運行，就會自動啟動；如果已經在運行，就會跳過，避免重複啟動。

注意事項

27B 模型對顯存要求較高，24GB 顯存體驗更穩；顯存較小時應換小模型。
--ctx-size 65536 會顯著增加顯存和記憶體壓力，不穩定時先降到 32768 或更低。
WSL2 中 CUDA Toolkit 和 Windows 顯示卡驅動都要正常，缺一邊都可能導致 CUDA 編譯或運行失敗。
Hermes Agent 接本地服務時，本質上是調用 OpenAI-compatible API，關鍵是 http://localhost:8080/v1 能正常回應。
如果要從手機或其他設備訪問，需要額外處理 Windows 防火牆、區域網地址和安全隔離，不要把本地模型服務直接暴露到公網。

NVIDIA 發布 Nemotron 3 Nano Omni：面向智慧體的開放全模態推理模型

Fri, 01 May 2026 12:07:15 +0800

NVIDIA 發布了 Nemotron 3 Nano Omni，這是一款面向智慧體工作流的開放式全模態推理模型。它的重點不是只做文字問答，而是把語言、視覺、音訊放進同一個推理框架裡，讓模型能夠處理更接近真實工作流的輸入。

從定位看，Nemotron 3 Nano Omni 更像是給 AI Agent 準備的底層模型。它可以理解螢幕、文件、圖片、語音和影片中的資訊，並把這些資訊轉成可執行的推理結果。這類能力適合電腦操作、文件智慧、影片理解、語音互動、客服、教育和企業流程自動化。

模型規格

Nemotron 3 Nano Omni 採用 MoE 架構。 NVIDIA 給出的核心規格是：

項目	資訊
模型名稱	`Nemotron 3 Nano Omni`
架構	MoE
參數規模	30B total / 3B active
模態	文字、圖像、音訊、影片
上下文長度	256K token
授權	Apache 2.0
主要部署方向	AI Agent、多模態推理、企業智慧體

這裡最值得注意的是 30B-A3B。它代表模型總參數規模約 30B，但每次推理只啟用約 3B 參數。這能在能力和推理成本之間做一個折衷：模型保留較大的專家容量，同時執行時只使用其中一部分。

不過，MoE 的 active params 不等於顯存只按 3B 模型估算。完整部署仍然要考慮專家權重、KV cache、視覺/音訊編碼模組、上下文長度和推理框架開銷。

它解決的不是單一模態問題

傳統大語言模型主要處理文字。多模態模型進一步支援圖片理解。而 Nemotron 3 Nano Omni 的目標更寬：它強調全模態輸入，也就是把文字、圖像、音訊和影片統一納入推理。

這對 Agent 很關鍵。真正的智慧體任務往往不是「給一段文字，生成一段文字」，而是：

看螢幕上的按鈕、表格和視窗；
讀 PDF、截圖、圖表和網頁；
聽語音說明或會議錄音；
理解影片中的動作、場景和時序；
把這些資訊綜合成下一步操作。

如果模型只能處理單一模態，Agent 就需要額外拼接多個專用模型。全模態模型的價值在於減少這種拼接成本，讓同一個模型直接處理更複雜的環境輸入。

面向電腦操作和文件智慧

NVIDIA 特別提到，Nemotron 3 Nano Omni 可用於電腦操作相關任務。這類任務通常要求模型理解使用者介面：

螢幕上有哪些控制項；
目前視窗處於什麼狀態；
哪個按鈕或選單是下一步目標；
表格、彈窗、輸入框中的內容意味著什麼。

這也是現在 AI Agent 落地時很難繞開的能力。如果智慧體要幫人操作辦公軟體、瀏覽器、企業後台或開發工具，它必須能看懂介面，而不是只讀 API 文件。

文件智慧也是類似邏輯。企業資料經常混合文字、表格、圖像、掃描頁和圖表。全模態模型可以把這些內容放在同一個上下文裡理解，適合做合約審閱、報表分析、票據處理、知識庫問答和流程自動化。

音訊和影片讓 Agent 更接近真實場景

音訊和影片輸入會讓 Agent 的應用範圍明顯擴大。

音訊場景包括：

會議錄音總結；
客服通話分析；
語音指令理解；
教育和培訓內容整理。

影片場景包括：

教學影片理解；
安防和工業巡檢；
螢幕錄製分析；
操作流程複盤；
多步驟任務中的時序判斷。

這些任務如果只靠文字轉寫，會丟掉很多視覺和時序資訊。全模態模型可以直接把聲音、畫面和文字線索結合起來，給 Agent 更完整的環境感知。

部署與生態

NVIDIA 將 Nemotron 3 Nano Omni 放進開放生態裡，模型採用 Apache 2.0 授權。這對開發者和企業很重要，因為它降低了試驗、整合和二次開發的授權門檻。

從 NVIDIA 的介紹看，這個模型也和其推理生態綁定緊密。對企業使用者來說，真正部署時通常會關注這些問題：

是否能在 NVIDIA GPU 上高效推理；
是否支援長上下文和多模態輸入；
是否能接入現有 Agent 框架；
是否能處理企業內部文件、音影片和介面截圖；
是否可以在私有環境裡部署。

NVIDIA 強調該模型在吞吐方面有明顯優勢，並稱其最高可達到同類開放全模態推理模型的 9 倍。這個數字的實際價值，還要結合具體硬體、上下文長度、輸入模態和推理框架來看。但方向很明確：NVIDIA 想把開放多模態模型和自己的推理基礎設施一起推向企業 Agent 場景。

適合哪些場景

Nemotron 3 Nano Omni 更適合下面這些任務：

需要同時理解文字、圖片、音訊和影片的 Agent；
企業內部文件智慧和知識庫問答；
基於螢幕截圖或網頁介面的電腦操作；
會議、客服、教學內容的多模態分析；
影片理解、流程複盤和時序判斷；
對開放授權和私有化部署有要求的團隊。

它不一定適合所有普通使用者。如果只是本地聊天、程式碼補全或簡單問答，單模態語言模型可能更輕、更快、更省資源。 Nemotron 3 Nano Omni 的價值主要體現在複雜輸入和多模態 Agent 工作流裡。

這對 AI Agent 意味著什麼

AI Agent 要真正進入工作場景，不能只會寫文字。它需要看得懂介面，聽得懂語音，讀得懂文件，理解影片裡的變化，還要把這些資訊轉成下一步行動。

Nemotron 3 Nano Omni 的意義就在這裡。它不是單純把模型參數做大，而是把 Agent 需要面對的多種輸入統一到一個推理模型裡。這會讓開發者更容易構建面向真實任務的智慧體，而不是只圍繞聊天視窗做應用。

從這個角度看，NVIDIA 發布這款模型的重點不只是「又一個多模態模型」，而是繼續把開放模型、GPU 推理、企業 Agent 和私有部署連接起來。未來真正值得關注的是，它在具體 Agent 框架、企業工作流和本地部署中的實際表現。

參考來源：

NVIDIA 技術部落格：NVIDIA Nemotron 3 Nano Omni

本地部署 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 的本地部署重點不是「檔案越大越好」，而是在顯存、上下文長度、速度和輸出品質之間找到平衡。

參考來源

本地部署 DeepSeek V4：Pro、Flash 與 Base 版本顯存占用估算表

Fri, 01 May 2026 11:55:25 +0800

DeepSeek V4 和 Gemma 4 的本地部署不是一個量級。 Gemma 4 的 26B、31B 還能討論 24GB、32GB 顯卡怎麼選量化版；DeepSeek V4 則是超大 MoE 模型，真正完整本地部署時，顯存需求會直接進入多卡工作站或伺服器級別。

官方發布的 DeepSeek V4 Preview 主要包含兩個推理版本：

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

Hugging Face 官方 collection 裡還包含兩個 Base 版本：

DeepSeek-V4-Pro-Base
DeepSeek-V4-Flash-Base

這篇只討論完整載入模型權重時的大致顯存門檻。 MoE 的 active params 主要影響每個 token 的計算量，不等於只需要載入這部分參數。如果沒有專家按需載入、CPU/NVMe offload、分散式推理或專門執行時最佳化，顯存仍然要按完整權重來估。

先看結論

顯存規模	能比較現實地嘗試什麼	不建議期待什麼
24GB	不能完整跑 DeepSeek V4；只能跑小型蒸餾模型或 API	V4-Flash / V4-Pro 完整本地載入
48GB	仍不適合完整載入；可做小模型或遠端 API 用戶端	V4-Flash Q4 穩定執行
80GB	理論上可嘗試 V4-Flash Q2/Q3 或強 offload	V4-Pro
128GB	V4-Flash Q4 比較現實；Q5/Q6 仍緊	V4-Pro Q4
192GB	V4-Flash FP8/Q6 更從容；Pro Q2 勉強進入討論	V4-Pro Q4
256GB	V4-Flash FP8 比較穩；Pro Q2/Q3 可實驗	V4-Pro Q5 以上
512GB	V4-Pro Q4 開始進入可討論範圍	V4-Pro FP8
1TB+	V4-Pro FP8、Pro-Base 低位寬更現實	單機低成本部署
2TB+	Pro-Base FP8 級別	普通工作站部署

如果你的目標是個人電腦本地執行，DeepSeek V4 並不是合適對象。更現實的路線是：

用 DeepSeek 官方 API 或相容服務；
等社群穩定的 GGUF/EXL2/MLX 量化和推理支援；
使用更小的 DeepSeek 蒸餾模型；
或者把本地模型換成 Qwen、Gemma、Llama 等 7B 到 70B 級別模型。

官方權重體積

以下是 Hugging Face 官方倉庫的 model.safetensors.index.json 中統計到的權重總量。它反映的是目前公開權重檔案大小，不等於長上下文執行時的完整顯存占用。

模型	參數規模	官方權重體積	說明
`DeepSeek-V4-Flash`	284B total / 13B active	159.61GB	推理版，體積相對最小
`DeepSeek-V4-Pro`	1.6T total / 49B active	864.70GB	推理版，能力更強，體積巨大
`DeepSeek-V4-Flash-Base`	284B total	294.67GB	Base 版，更接近全量 FP8 權重體積
`DeepSeek-V4-Pro-Base`	1.6T total	1606.03GB	Base 版，約 1.6TB 級別

可以看到，即使是最小的 V4-Flash，官方權重也已經接近 160GB。這就是為什麼它不能按「13B active params」理解成 13B 小模型。

DeepSeek V4 Flash 顯存估算

V4-Flash 是 DeepSeek V4 裡最適合本地嘗試的一檔。但「最適合」只是相對 Pro 而言，它仍然不是消費級單卡模型。

下面按官方 159.61GB 權重體積做折算。其中 Q4/Q3/Q2 是按位寬估算，不代表目前已經有穩定可用的官方 GGUF 版本。

版本/量化	估算權重體積	最低顯存	更穩妥顯存	適合場景
`FP8 / 官方權重`	159.61GB	192GB	256GB	多卡伺服器、推理服務
`Q6`	120GB	160GB	192GB	品質優先的量化嘗試
`Q5`	100GB	128GB	160GB	品質和體積折中
`Q4`	80GB	96GB	128GB	Flash 本地化較現實的起點
`Q3`	60GB	80GB	96GB	大顯存單卡或多卡實驗
`Q2`	40GB	48GB	64GB	極限低位寬實驗，品質風險明顯

如果未來社群出現成熟的 V4-Flash Q4，它大機率也不是 24GB 顯卡的模型。更現實的硬體起點是 96GB 到 128GB 級別的總顯存，或者依賴 CPU 記憶體/offload 換速度。

DeepSeek V4 Pro 顯存估算

V4-Pro 是旗艦推理版，官方權重體積約 864.70GB。即使做 4-bit 量化，完整權重也仍然是數百 GB 級別。

版本/量化	估算權重體積	最低顯存	更穩妥顯存	適合場景
`FP8 / 官方權重`	864.70GB	1TB	1.2TB+	多機多卡推理服務
`Q6`	648GB	768GB	1TB	高品質量化服務
`Q5`	540GB	640GB	768GB	高品質與成本折中
`Q4`	432GB	512GB	640GB	Pro 本地化較現實的最低品質線
`Q3`	324GB	384GB	512GB	低位寬實驗
`Q2`	216GB	256GB	320GB	極限實驗，品質和穩定性風險高

對個人使用者來說，V4-Pro 更適合透過 API 使用。如果目標是完整本地部署，至少要把它當成多卡伺服器模型，而不是 4090、5090、RTX PRO 單卡模型。

DeepSeek V4 Flash-Base 顯存估算

Base 版通常用於研究、微調或繼續訓練，不是普通聊天部署的首選。 V4-Flash-Base 官方權重體積約 294.67GB。

版本/量化	估算權重體積	最低顯存	更穩妥顯存	適合場景
`FP8 / 官方權重`	294.67GB	384GB	512GB	研究、訓練前處理、評測
`Q6`	221GB	256GB	320GB	高品質量化研究
`Q5`	184GB	224GB	256GB	品質和體積折中
`Q4`	147GB	192GB	224GB	Base 版低成本實驗
`Q3`	111GB	128GB	160GB	低位寬實驗
`Q2`	74GB	96GB	128GB	極限實驗

如果只是要使用 DeepSeek V4 能力，不建議從 Base 版開始。 Base 版的部署和調優成本更高，普通應用更適合推理版或 API。

DeepSeek V4 Pro-Base 顯存估算

V4-Pro-Base 是最重的一檔，官方權重體積約 1606.03GB。這已經是 1.6TB 級別的模型檔案。

版本/量化	估算權重體積	最低顯存	更穩妥顯存	適合場景
`FP8 / 官方權重`	1606.03GB	2TB	2.4TB+	大規模研究叢集
`Q6`	1205GB	1.5TB	2TB	高品質量化研究
`Q5`	1004GB	1.2TB	1.5TB	研究與評測
`Q4`	803GB	1TB	1.2TB	低位寬研究
`Q3`	602GB	768GB	1TB	極限低位寬研究
`Q2`	402GB	512GB	640GB	極限實驗

這類模型不適合被放進「家用顯卡能不能跑」的框架裡討論。哪怕是 Q4，也已經超過絕大多數單機工作站的舒適範圍。

為什麼不能只看 active params

DeepSeek V4 是 MoE 模型。 MoE 的特點是每個 token 只啟用一部分專家，因此計算量會明顯低於總參數量。但這不等於顯存只需要放 active params。

完整本地推理通常還要考慮：

所有專家權重是否需要常駐 GPU；
是否支援按需專家載入；
CPU 記憶體與 GPU 顯存之間的資料搬運成本；
NVMe offload 的延遲；
KV cache 在長上下文下的增長；
1M context 場景下的額外執行時開銷；
多機多卡通訊成本。

所以，49B active 的 V4-Pro 不能當成 49B 模型來部署。 13B active 的 V4-Flash 也不能當成 13B 小模型來部署。

怎麼選

如果你只是普通個人使用者：

不建議完整本地部署 DeepSeek V4。
需要 DeepSeek V4 能力時，優先用官方 API。
需要本地私有化時，優先看是否有成熟推理服務商或內部多卡伺服器。
只有 24GB 到 48GB 顯存時，轉向 7B、14B、32B、70B 級別量化模型更實際。

如果你有 128GB 到 256GB 總顯存：

可以關注 V4-Flash Q4/Q5 是否有穩定社群實作。
不建議把 V4-Pro 當成主力本地模型。

如果你有 512GB 以上總顯存：

V4-Pro Q4 才開始進入工程驗證範圍。
仍然要關注推理框架、專家調度、KV cache、吞吐和並發。

DeepSeek V4 的本地部署重點不是「下載哪個量化檔案」，而是「有沒有足夠的系統級推理能力」。它更接近一個伺服器模型，而不是普通桌面模型。

參考來源

本地部署 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。本地部署的重點不是檔案越大越好，而是在顯存、速度、上下文和輸出品質之間找到平衡。

參考來源

8G 顯存跑 llama.cpp 怎麼調：32K 更穩，64K 要開 KV Cache 量化

Thu, 23 Apr 2026 12:13:04 +0800

8G 顯存到底還能不能把本地大模型跑順，尤其是在長上下文場景下還能不能保住速度，這是很多人在折騰 llama.cpp 時都會遇到的問題。

核心結論可以先記住三條：

對 8G 顯存來說，32K 上下文通常是更穩的平衡點
如果一定要跑 64K，KV Cache 量化基本是必選項
在全顯卡運行場景裡，盲目拉高 CPU 執行緒數，反而可能讓速度明顯下降

一、先解釋清楚：32K、64K 和 KV Cache 是什麼

很多人第一次看這類調優文章，最容易卡住的就是這三個詞。

32K 和 64K 說的是上下文長度，也就是模型一次最多能處理多少 token。這裡的 K 就是千，32K 大約是 32000 token，64K 大約是 64000 token。上下文越長，模型一次能看到的歷史內容越多，適合長文件問答、長對話和多輪分析。

KV Cache 則是模型為了加速連續生成而保留的一份中間結果快取。你可以把它理解成：模型已經讀過、算過的一部分內容，不會每次都從頭重算，而是把關鍵結果先存起來，後面繼續接著用。這裡的 K 和 V，來自 Transformer 裡的 Key 和 Value。

為什麼這三個詞總是一起出現？因為：

32K、64K 決定你想讓模型一次記住多長內容
KV Cache 決定為了維持這段記憶，要額外占多少顯存
上下文越長，KV Cache 通常越大，顯存壓力也越高

所以很多長上下文變慢的問題，本質上並不是模型「不會算」，而是快取太大，把顯存擠到了臨界點。

二、為什麼 32K 和 64K 的速度會差這麼多

這裡用《三體》大約 3 萬字的文本做壓力測試，對比 32K 和 64K 兩種上下文設定。結果很誇張：在文件長度接近的情況下，64K 模式的速度顯著下降，總耗時也明顯拉長。

問題不在模型突然變笨，而在顯存邊界被撞到了。

當 32K 模式下，模型權重加快取還能基本塞進 8G 顯存裡，資料大多走顯卡顯存帶寬，速度還能維持在比較可用的區間。但一旦切到 64K，快取體積繼續上漲，總占用逼近甚至超過顯存上限，系統就會把部分資料擠到記憶體裡。

這時候真正掉下去的，不是算力，而是帶寬。

也就是說，很多人看到的是「上下文翻倍後速度暴跌」，本質上其實是資料路徑從顯存掉到了共享記憶體或系統記憶體，推理鏈路不再跑在高速通道上。

三、64K 還能不能跑，關鍵在 KV Cache 量化

第二個很關鍵的結論，是 KV Cache 量化對 8G 顯存使用者特別重要。

如果不改變模型本身，只針對快取做量化，長上下文下最直接的收益就是把快取占用壓縮下來，讓原本已經溢出的那部分重新回到顯存裡。這樣一來，64K 模式雖然依然比 32K 更吃資源，但至少不會直接跌進最慢的區間。

換句話說：

32K 更像是 8G 顯存的預設推薦區間
64K 不是完全不能跑
但如果不上快取量化，效能很容易從「能用」直接掉到「很難用」

如果你的目標是盡量穩定地跑長上下文，那優先順序通常應該是：

先確認顯存是否已經逼近上限
再決定是否開啟 KV Cache 量化
最後才去繼續嘗試更激進的吞吐量參數

四、GPU 占用不高，不代表顯卡沒幹活

這是一個很容易打破直覺的點。

很多人看到工作管理員裡 GPU 使用率只有二三十，就會懷疑：

是不是參數沒設對
是不是模型沒真正跑到顯卡上
是不是顯卡根本沒吃滿

但這組測試給出的判斷是，llama.cpp 這類推理很多時候首先卡的不是核心算力，而是顯存讀寫速度。

也就是說，顯卡核心可能很快就把一批計算做完了，但後面還得等下一批權重和快取資料搬過來。於是你看到的現象就會變成：

核心占用不算高
但整體速度還是上不去

這不是顯卡在偷懶，而是資料通路太窄。

所以看本地大模型速度時，不能只盯著 GPU Usage。顯存容量、顯存帶寬、快取是否溢出，往往更影響最終體驗。

五、調大吞吐量參數，確實可能再快一截

這裡還做了一個思路很清晰的測試：既然顯卡核心並沒有完全忙滿，那能不能透過調大吞吐量相關參數，讓顯卡一次處理更多資料，把並行能力進一步壓出來。

測試結果表明，這種做法確實有機會把速度再往上拉一段。

但這裡也有一個前提：顯存還得扛得住。

因為吞吐量相關參數調大之後，往往會帶來額外顯存占用。如果你本來就在 64K、高快取、顯存見底的狀態下繼續往上推，就很容易出現兩種情況：

直接崩潰
沒崩，但被迫進入更慢的共享記憶體模式

所以更穩妥的順序通常不是「先把參數拉滿」，而是：

先守住顯存邊界
再考慮吞吐量優化
每調一步都重新看速度和穩定性

六、CPU 執行緒不是越多越好

這也是整篇內容裡最值得記住的坑點之一。

很多人做本地推理調優時，容易下意識覺得執行緒越多越快，既然機器有那麼多執行緒，不用滿就像浪費。但實測給出的結果恰恰相反：在模型已經主要跑在顯卡上的情況下，強行把 CPU 執行緒拉高，效能反而會明顯變差。

原因不複雜。

在全顯卡運行時，CPU 更像是調度者和預處理協作者，而不是主力計算單元。這時候如果開太多執行緒，CPU 端的執行緒競爭、調度切換和上下文切換開銷都會變重，最終把本來應該更流暢的資料流打亂。

結果就是：

CPU 更忙了
但整體速度變慢了

所以在這種場景下，預設設定或者較低執行緒數，往往比一味拉滿更靠譜。

七、對 8G 顯存使用者更實用的一套思路

如果把上面的結論壓成一套更容易執行的思路，大概可以整理成這樣：

1. 先把 32K 當成預設目標

如果你用的是 8G 顯存顯卡，先別急著追 64K。32K 往往是速度、穩定性和顯存占用之間更現實的平衡點。

2. 想上 64K，先處理快取問題

不要先想「還能不能再榨一點速度」，而是先確認 KV Cache 有沒有量化、顯存是不是已經壓線。

3. 不要用 GPU 占用率判斷一切

低占用不一定代表設定錯了，也可能只是顯存帶寬在拖後腿。

4. 吞吐量優化可以做，但別越過顯存邊界

這類參數確實能帶來收益，但前提是顯存還有餘量。

5. CPU 執行緒先保守，再逐步測試

如果模型已經基本跑在顯卡上，CPU 執行緒並不是越高越好。先用預設值或低執行緒值測試，再看是否值得繼續調整。

結語

這組內容最有價值的地方，不只是給出幾個測試數字，而是把一個經常被忽略的事實講清楚了：

本地大模型調優，很多時候拼的不是「有沒有把所有參數開到最大」，而是你有沒有搞清楚瓶頸到底在算力、顯存容量、顯存帶寬，還是在 CPU 調度。

對 8G 顯存使用者來說，真正更穩的思路通常不是硬衝最長上下文，而是先守住顯存邊界，再決定要不要繼續往上加。

如果只記一句話，那就是：

32K 往往是 8G 顯存更穩的工作區間；64K 不是不能跑，但前提是你已經把 KV Cache 和顯存占用管住了。

16G 顯卡也能跑 35B 模型：LM Studio 下 MoE 模型的顯存壓縮思路

Wed, 22 Apr 2026 21:47:34 +0800

很多人對 16G 顯存的印象是：本地部署大模型時，大概也就跑到 12B 到 14B，量化之後再往上就會變得很吃力。這個判斷不算離譜，但也不是 16G 顯卡真正的上限。

如果模型選型和參數設定都合適，16G 顯卡其實不一定只能停留在「小參數量模型」這一檔。圍繞這件事，一套比較有代表性的思路是：在 LM Studio 裡利用 MoE 模型和合理的卸載策略，把 35B 級模型跑到比較可用的速度。

01 為什麼 16G 顯卡不一定只能跑 12B 到 14B

這裡的核心觀點很直接：顯存大小固然重要，但模型架構同樣重要。

如果你拿一個標準稠密模型硬塞進 16G 顯卡，確實很快就會遇到瓶頸。因為這類模型在推理時通常要參與全部參數計算，顯存壓力和帶寬壓力都會直接上來。

但 MoE 模型不一樣。它的總參數量可以很大，可是在單次推理時，只會啟動其中一部分專家參數。以 35B 級模型為例，雖然總參數規模不小，但單次推理實際參與計算的參數量要小得多，所以它對顯存的實際要求沒有想像中那麼誇張。

也正因為這樣，16G 顯卡在面對這類模型時，並不是完全沒有操作空間。

02 實測重點：35B MoE 模型可以跑得很快

一個重點案例，是 Qwen 3.5 35B A3B 一類的 MoE 模型量化版本。在 16G 顯卡配合 LM Studio 做參數調整後，Q6 量化大約能跑到 30 多 tokens/s，此前 Q4 量化甚至能測到更高的速度。

這個結果之所以有參考價值，不只是因為「能跑」，而是因為速度已經進入了「明顯可用」的區間。

作為對比，同類大參數量但不是 MoE 的模型，在 16G 顯卡上如果直接硬跑，往往會出現爆顯存、速度明顯掉下來的情況。換句話說，決定結果的不是單純看參數總量，而是看模型在推理時到底怎麼用這些參數。

03 在 LM Studio 裡，重點不只一個參數

想在 16G 顯卡上把這類模型跑順，關鍵不是碰運氣，而是調對兩個參數：

GPU Offload
強制把部分專家層載入到 CPU 記憶體的參數

第一項比較好理解，GPU Offload 基本就是能拉多高就拉多高，讓模型盡量優先使用顯卡計算。

第二項才是這裡的重點。它的作用不是傳統意義上那種「顯存爆了之後再借系統記憶體」，而是主動把一部分專家層放到 CPU 記憶體裡，提前降低顯存占用。因為 MoE 模型本來就不是每次都要把所有專家都啟動，所以把一部分專家放到記憶體裡，對整體推理速度的影響沒有很多人想像中那麼誇張。

比較穩妥的做法，是先在一個區間裡嘗試，再根據自己的機器慢慢調：

可以先把相關參數設到 20 到 35 之間
然後結合顯存占用和記憶體壓力，逐步微調

本質上，這套方法就是用系統記憶體去換顯存空間。

04 128K 上下文下也能跑，縮小上下文還能繼續壓顯存

還有一個比較有意思的點：測試時把上下文長度拉到了 128K，在這種偏激進的設定下，35B 級 MoE 模型依然能跑出比較高的速度。

這說明一個問題，16G 顯卡的瓶頸沒有想像中那麼死板。尤其在 LM Studio 這種本地推理工具裡，很多時候不是「能不能運行」的二選一，而是：

你願不願意拿更多記憶體換顯存
你願不願意縮短上下文長度
你願不願意接受不同量化版本之間的能力差異

如果把上下文從 128K 進一步縮到 64K 或 32K，顯存壓力還可以繼續下降。也就是說，某些 35B 級 MoE 模型甚至可能在更小顯存的顯卡上勉強跑起來，只是速度和記憶體壓力要重新權衡。

05 這種方法的代價：對系統記憶體和虛擬記憶體要求更高

這類方案並不是白送性能。

需要注意的是，當顯存壓力被進一步壓縮時，系統記憶體占用會明顯上升，虛擬記憶體的壓力也會變大。換句話說，你省下來的不是成本，只是把壓力從顯卡挪到了記憶體和磁碟交換空間上。

所以如果你也想照著試，最好先確認幾件事：

你的系統記憶體是否足夠
虛擬記憶體是否留得夠大
機器背景是否還有很多佔資源的軟體在運行

如果這些條件跟不上，最後看到的可能不是「35B 也能飛快跑」，而是整台機器都被拖慢。

06 量化版本也不是越激進越好

這裡還有一個實際取捨：雖然更低位數的量化通常能進一步節省顯存，但不一定就是最合適的方案。

實際經驗是，有些模型在 Q4 下速度確實更高，但對原始能力的影響也更明顯；相對來說，Q6 在速度和能力保留之間更平衡。所以最終不一定要無腦追求最小體積，而是要看你更在意什麼：

如果你主要追求速度和塞進顯存
或者你更在意模型原有能力的保留

這兩種取向，對應的量化選擇可能並不一樣。

07 哪些模型思路值得試

從這個思路來看，最值得嘗試的並不是「盲目追大參數量」，而是優先找適合這種玩法的模型：

MoE 架構模型
在 LM Studio 裡支援較好、量化版本較全的模型
對長上下文或指令跟隨有明確優勢的模型

除了主講的 35B MoE 模型，這類方案也適合延伸到一些其他方向，比如偏長上下文記憶、指令遵循表現更好的實驗性模型，以及一些速度表現不錯的輕量量化版本。

這類推薦背後的邏輯其實很一致：先找架構上適合「記憶體換顯存」的模型，再談參數調優，而不是先看參數量再決定能不能跑。

08 簡單總結

如果你手裡正好是一張 16G 顯卡，覺得本地大模型最多只能玩 12B 到 14B，這種想法可以稍微更新一下。

更準確的說法應該是：

16G 顯卡跑大模型並不是完全沒戲
稠密模型和 MoE 模型要分開看
LM Studio 裡的 GPU Offload 和專家層轉移到 CPU 記憶體的參數，能明顯改變顯存占用情況
你實際上是在用更高的記憶體壓力，換更大的模型規模和更高的可用速度

這套思路不一定適合所有機器，但它至少說明了一點：本地部署大模型時，顯存上限不是唯一限制，模型架構和推理配置同樣重要。

Ollama 多顯卡使用筆記：顯存疊加、GPU 選擇和常見誤區

Sun, 19 Apr 2026 00:18:00 +0800

折騰 Ollama 本地推理時，經常會遇到類似問題：我現在有一張顯卡，主機板還有空 PCIe 槽，再加幾張 GPU 對 Ollama 有幫助嗎？多顯卡是否必須同型號？顯存能不能疊加？會不會像訓練框架那樣多卡並行加速？

這篇整理一下 Ollama 多顯卡的實際行為。重點先說結論：

Ollama 支援多 GPU。
多 GPU 最大價值通常是讓更大的模型放進總顯存，而不是線性提升 token/s。
預設策略下，如果模型能完整放進某一張 GPU，Ollama 傾向於放在單卡上。
如果模型無法完整放進單張 GPU，Ollama 會把模型分布到可用 GPU 上。
不同型號 GPU 可以被 Ollama 看到並使用，但效能和分配效果不一定理想。
不需要 SLI / NVLink 才能用多卡。
想限制 Ollama 使用哪些 GPU，需要用 CUDA_VISIBLE_DEVICES、ROCR_VISIBLE_DEVICES 或 GGML_VK_VISIBLE_DEVICES。

官方行為：先單卡，放不下再多卡

Ollama FAQ 裡對多 GPU 載入邏輯說得比較直接：載入新模型時，Ollama 會估算模型所需 VRAM，並和目前可用顯存比較。如果模型能完整放進某一張 GPU，它會載入到那張 GPU 上；如果單張 GPU 放不下，才會分布到所有可用 GPU 上。

這個策略的原因是效能。單卡載入通常能減少推理時跨 PCIe 匯流排的資料傳輸，因此往往更快。

所以不要把 Ollama 的多 GPU 理解成「有幾張卡就自動幾倍加速」。更準確的理解是：

小模型能進單卡：通常單卡跑。
大模型單卡放不下：跨多卡分層載入。
顯存仍不夠：一部分會落到系統記憶體，速度會明顯下降。

可以用下面命令確認模型到底載入到了哪裡：

`1`	`ollama ps`

輸出裡的 PROCESSOR 會顯示類似：

1
2
3

100% GPU
48%/52% CPU/GPU
100% CPU

如果看到 48%/52% CPU/GPU，說明已經有一部分在系統記憶體裡了。此時多加 GPU 或換更大顯存的卡，通常比繼續依賴 CPU/RAM 更有意義。

多 GPU 不是簡單疊算力

本地大模型推理和遊戲裡的 SLI 不是一回事。Ollama 多卡時，更常見的是把模型的不同層或張量放到不同裝置上。這樣可以用多張卡的顯存裝下更大的模型，但推理過程中仍然可能需要裝置之間傳遞資料。

因此，多 GPU 帶來的收益通常分兩種：

顯存收益：更容易裝下大模型，或者避免落到 CPU/RAM。
效能收益：只有在原本單卡裝不下或嚴重混 CPU 時，提升才會很明顯。

如果一個 8B 或 14B 模型本來就能完整放進單張 3090，強行拆到兩張卡不一定更快，甚至可能因為跨卡傳輸變慢。Ollama 官方預設「能單卡就單卡」的策略，就是為了避免這類不必要的跨 PCIe 開銷。

不需要 SLI 或 NVLink

Ollama 多 GPU 不依賴 SLI。多張普通 PCIe GPU 只要驅動和 Ollama 能識別，就可以被調度。

NVLink 或更高 PCIe 頻寬可能對某些跨卡場景有幫助，但它不是 Ollama 多 GPU 的前提條件。很多二手 GPU 伺服器或工作站，靠普通 PCIe 多卡也能跑。

真正要注意的是 PCIe 頻寬。x1、x4、x8、x16 的差異會影響模型載入到顯存的速度；如果頻繁切換大模型，PCIe 鏈路會更容易成為瓶頸。模型載入完成後，生成階段受 PCIe 的影響通常會小一些，但跨卡分層仍然可能帶來額外開銷。

比較穩的建議是：

能用 x16 / x8 就不要用礦卡 x1 轉接。
大模型頻繁切換時，PCIe 頻寬更重要。
如果模型長期常駐顯存，PCIe 頻寬瓶頸會相對不明顯。
多卡機器要重點看主機板 PCIe 拓撲和 CPU 直連通道。

如何限制 Ollama 使用哪些 NVIDIA GPU

NVIDIA 多卡環境下，用 CUDA_VISIBLE_DEVICES 控制 Ollama 能看到哪些卡。

臨時執行：

`1`	`CUDA_VISIBLE_DEVICES=0,1 ollama serve`

只讓 Ollama 用第二張卡：

`1`	`CUDA_VISIBLE_DEVICES=1 ollama serve`

強制不用 NVIDIA GPU，可以給一個無效 ID：

`1`	`CUDA_VISIBLE_DEVICES=-1 ollama serve`

官方文件提醒，數字 ID 的順序可能變化，更可靠的是用 GPU UUID。先查看 UUID：

`1`	`nvidia-smi -L`

輸出類似：

1
2

GPU 0: NVIDIA GeForce RTX 3090 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
GPU 1: NVIDIA GeForce RTX 3070 (UUID: GPU-yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy)

然後指定 UUID：

`1`	`CUDA_VISIBLE_DEVICES=GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ollama serve`

如果 Ollama 是 Linux systemd 服務安裝的，需要寫到服務環境變數裡：

`1`	`sudo systemctl edit ollama.service`

加入：

1
2

[Service]
Environment="CUDA_VISIBLE_DEVICES=0,1"

然後重載並重啟：

1
2

sudo systemctl daemon-reload
sudo systemctl restart ollama

AMD 和 Vulkan 的選擇變數

AMD ROCm 環境下，用 ROCR_VISIBLE_DEVICES 控制可見 GPU：

`1`	`ROCR_VISIBLE_DEVICES=0,1 ollama serve`

如果要強制不用 ROCm GPU，也可以用無效 ID：

`1`	`ROCR_VISIBLE_DEVICES=-1 ollama serve`

Ollama 官方 GPU 文件還提到，如果用實驗性的 Vulkan 支援，可以透過 GGML_VK_VISIBLE_DEVICES 選擇 Vulkan GPU：

`1`	`OLLAMA_VULKAN=1 GGML_VK_VISIBLE_DEVICES=0 ollama serve`

如果 Vulkan 裝置有問題，可以停用：

`1`	`GGML_VK_VISIBLE_DEVICES=-1 ollama serve`

AMD 多卡比 NVIDIA 更容易遇到驅動、ROCm 版本、GFX 版本支援的問題。官方文件中也提到 Linux 下 ROCm 驅動版本、HSA_OVERRIDE_GFX_VERSION 等相容性處理。多張不同代 AMD 卡混用時，先確認每張卡是否單獨可用，再考慮多卡。

Docker 裡怎麼暴露多張 GPU

如果用 Docker 跑 Ollama，NVIDIA 環境通常需要先安裝 nvidia-container-toolkit，然後用 --gpus 暴露裝置。

暴露全部 GPU：

docker run -d \
  --gpus=all \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

只暴露指定 GPU：

docker run -d \
  --gpus '"device=0,1"' \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

也可以結合環境變數：

docker run -d \
  --gpus=all \
  -e CUDA_VISIBLE_DEVICES=0,1 \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

如果容器裡 nvidia-smi 看不到卡，Ollama 也不可能用到 GPU。先排查 Docker GPU passthrough，再排查 Ollama。

`OLLAMA_SCHED_SPREAD` 是什麼

在一些多 GPU 配置討論裡，會看到 OLLAMA_SCHED_SPREAD=1 或 OLLAMA_SCHED_SPREAD=true。它和 Ollama 的調度策略有關，常被用於希望模型或請求更分散地利用多張 GPU 的場景。

可以這樣設定：

`1`	`OLLAMA_SCHED_SPREAD=1 ollama serve`

或者 systemd：

1
2

[Service]
Environment="OLLAMA_SCHED_SPREAD=true"

不過它不是萬能開關。開啟後並不等於 token/s 線性增長，也可能因為多個模型同時載入、顯存估算、上下文長度和 KV cache 增長導致 OOM。官方 FAQ 的核心策略仍然是：如果單 GPU 能完整容納模型，單 GPU 通常更高效；單 GPU 放不下時才跨多 GPU。

所以建議把 OLLAMA_SCHED_SPREAD 當成進階調度實驗項，而不是多卡必開項。先理解預設行為，再根據實際 ollama ps、日誌和 nvidia-smi 觀察結果調整。

怎麼觀察多卡是否真的用上

常用觀察命令：

`1`	`ollama ps`

`1`	`watch -n 0.5 nvidia-smi`

查看 Ollama 服務日誌：

`1`	`journalctl -u ollama -f`

如果使用 Docker：

`1`	`docker logs -f ollama`

你需要關注：

Ollama 是否發現相容 GPU。
模型是否顯示 100% GPU 或 CPU/GPU 混合。
每張卡顯存是否有占用。
載入模型時是否多卡顯存同時增長。
生成時 token/s 是否比 CPU/RAM 混跑明顯改善。
是否頻繁 OOM 或卸載模型。

如果只看 GPU 利用率，很容易誤判。LLM 推理時 GPU 利用率不一定長期滿載，尤其是多卡、低 batch、小上下文、慢 CPU 或慢 PCIe 環境下。

常見誤區

誤區 1：兩張 12GB 顯卡等於一張 24GB 顯卡

不完全等價。多卡可以讓模型跨裝置放置，但跨卡存取有額外開銷。它能解決「放不下」的問題，不一定等價於單張大顯存卡的速度和穩定性。

誤區 2：不同型號顯卡不能混用

不一定。只要驅動、計算能力和執行庫都支援，Ollama 可以看到多張 GPU。但混用時，速度通常受較慢卡、較小顯存和 PCIe 拓撲影響。最穩的多卡配置仍然是同型號、同顯存、同代驅動支援良好的卡。

誤區 3：多卡一定比單卡快

不一定。如果模型能完整放進單張快卡，單卡可能更快。多卡主要適合大模型、長上下文、單卡顯存不夠的情況。

誤區 4：必須有 NVLink / SLI

不需要。普通 PCIe 多卡也能被 Ollama 使用。NVLink 不是前提。

誤區 5：加 GPU 後不用重啟服務

不一定。Linux systemd 服務、Windows 背景應用、Docker 容器都可能需要重啟，才能重新識別裝置和環境變數。

選卡建議

如果目標是 Ollama 本地推理，優先級大致是：

單卡顯存越大越省心。
同型號多卡比混合多卡更容易排錯。
PCIe 通道越完整，載入大模型越舒服。
老卡要先確認 CUDA compute capability 或 ROCm 支援。
多卡電源、散熱和機箱風道要提前算清楚。

對於預算有限的二手平台：

雙 3090 仍然是很常見的大顯存方案。
P40 / M40 這類老 Tesla 顯存大，但功耗、散熱、驅動和效能都要權衡。
4070 / 4070 Ti 這類新卡能效好，但單卡顯存容量限制更明顯。
多張 8GB 老卡能折騰，但不建議為了大模型長期使用。

小結

Ollama 多顯卡支援可以理解成「顯存擴展優先，效能加速其次」。如果模型能完整放進一張 GPU，預設單卡通常更快；如果單卡放不下，多卡可以把模型分布到多張 GPU 上，避免大量落到 CPU/RAM，從而讓大模型變得可用。

實際配置時，先用 ollama ps 看模型載入位置，再用 nvidia-smi 或 ROCm 工具觀察顯存占用。需要限制 GPU 時，NVIDIA 用 CUDA_VISIBLE_DEVICES，AMD ROCm 用 ROCR_VISIBLE_DEVICES，Vulkan 用 GGML_VK_VISIBLE_DEVICES。如果在 Docker 中執行，先確保容器層面能看到 GPU。

多卡不是魔法。它能幫你裝下更大的模型，但不保證線性加速。真正穩定好用的路線，仍然是盡量選大顯存單卡或同型號多卡，並把驅動、PCIe、電源、散熱和模型量化一起考慮。

參考連結

Ollama FAQ：How does Ollama load models on multiple GPUs?：https://github.com/ollama/ollama/blob/main/docs/faq.mdx
Ollama GPU 文件：Hardware support / GPU Selection：https://github.com/ollama/ollama/blob/main/docs/gpu.mdx
Ollama Docker Hub：https://hub.docker.com/r/ollama/ollama
NVIDIA Container Toolkit：https://github.com/NVIDIA/nvidia-container-toolkit

Gemma 4 E4B 越獄版和官方普通版有什麼差別

Sat, 18 Apr 2026 10:20:00 +0800

如果你看到 HauhauCS/Gemma-4-E4B-Uncensored-HauhauCS-Aggressive 這種模型，最關鍵的一點是：它不是 Google 新發的另一套 Gemma 4，而是建立在官方 google/gemma-4-E4B-it 之上的非官方衍生版本，重點是把模型行為調到「更少拒答」。

所以它和普通版真正拉開的，通常不是底層架構，而是對齊策略與輸出風格。

這個衍生版模型卡自己怎麼說

Hugging Face 模型卡裡，這個 HauhauCS 版本明確寫了幾件事：

它基於 google/gemma-4-E4B-it
它聲稱「沒有改資料集或能力」
它聲稱變化只是「去掉拒答」
Aggressive 版本被描述為「完全解鎖，不會拒絕提示詞」

這些是作者自己的說法，不是第三方獨立測評。但從定位來看已經很清楚：這就是一個以「減少安全拒答」為目標的非官方衍生版。

官方版 vs 所謂「越獄版」

維度	官方 `google/gemma-4-E4B-it`	`Gemma-4-E4B-Uncensored-HauhauCS-Aggressive`
來源	Google 官方發布	Hugging Face 第三方衍生版
基礎模型	Gemma 4 E4B 指令微調版	同一模型家族，且模型卡明確寫明基於 `google/gemma-4-E4B-it`
核心目標	通用助理能力 + 負責任使用框架	盡量減少拒答，讓模型繼續輸出
安全取向	與 Gemma 家族的安全文件、禁止用途政策一致	明確削弱拒答與護欄行為
回答風格	更可能拒絕、轉向或保守回答敏感請求	更可能直接繼續回答原本會被擋下的問題
風險水位	預設風險較低，但仍不代表絕對安全	預設風險更高，更容易輸出不安全或不合規內容
用於產品/團隊	更容易通過評審與落地	更難用於公開產品、企業環境或合規場景
額外防護需求	仍需要應用層防護	更依賴你自己做額外審核、過濾與限制

核心差異是「對齊方式」變了，不是「能力等級」突然提高

很多人會把 uncensored 理解成「更強」，這通常不是精準的判斷。

對這種衍生版來說，最先變的是：

拒答頻率
對敏感請求的服從程度
最終答案裡還剩多少安全過濾

而不會因為名稱裡寫了 Uncensored，就自動代表下面這些一起升級：

模型架構突然更強
上下文視窗突然更大
多模態能力突然更完整
推理上限顯著更高

更準確的理解是：它通常只是同一模型家族裡，行為調校不同的一版，而不是更高階的新模型。

為什麼官方普通版會更保守

Google 的 Gemma 官方資料一直把這個系列放在「負責任 AI 開發」的框架裡。Gemma 模型卡會明確談到誤用、有害內容、隱私與偏見等風險；Gemma Prohibited Use Policy 也明確禁止把 Gemma 或其衍生模型用於：

危險、違法或惡意活動
生成有害、誤導、欺騙性內容
覆蓋或繞過安全過濾

所以官方版不是「剛好比較保守」，而是從文件、授權與部署定位上，本來就那樣設計。

什麼情況下普通版更適合

如果你更在意下面這些，優先用官方 google/gemma-4-E4B-it：

產品部署
團隊協作
企業或對外場景
較低的政策與法律風險
更容易解釋與審查的輸出行為

對大多數正常應用來說，這通常才是預設選項。

什麼情況下有人會去試越獄版

選這類 uncensored 衍生版的人，常見目的通常是：

本地私人實驗
測試官方版是否「太早拒答」
角色扮演或更開放的創作場景
比較不同對齊版本的行為差異

但對應的代價也很明確：模型提供方少做的那部分安全約束，需要你自己補回來。

結論

所謂 Gemma 4 E4B「越獄版」和官方普通版，最本質的差異其實是：

官方版追求的是「有護欄的可用能力」
越獄版追求的是「更少拒答的可輸出性」

它不自動等於更強，更多只是更放開。

如果你的目標是穩定、可解釋、適合部署，先用官方版更合理。
如果你的目標是本地實驗，而且你清楚知道安全、合規與輸出風險都要自己承擔，那這類 uncensored 衍生版可以當成「行為差異版本」來測試，但不應該直接理解成普通版的全面升級替代品。

參考來源

Hugging Face: HauhauCS/Gemma-4-E4B-Uncensored-HauhauCS-Aggressive
Hugging Face: google/gemma-4-E4B-it
Google AI for Developers: Gemma Prohibited Use Policy
Google AI for Developers: Gemma model card

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>，通常是最省事的做法。

Gemma-4-31B-it 裡的 it 是什麼意思

Sat, 11 Apr 2026 20:45:34 +0800

在 gemma-4-31B-it 這個名稱裡，it 是 Instruction Tuned 的縮寫，也就是「指令微調」版本。

對大多數人來說，可以直接理解成：這個模型更適合聊天、問答、寫程式和執行明確任務。

`it` 是什麼

模型通常會有兩類常見版本：

Base / Pre-trained：基礎模型，更接近原始文字預測器。
it：經過指令微調，更擅長理解「請幫我做什麼」這類輸入。

如果你輸入「請翻譯這段話」或「幫我寫一段 Python 程式碼」，it 版本通常會更穩定，也更符合對話式使用方式。

`31B` 是什麼

31B 表示這個模型大約有 310 億參數。

一般來說：

參數量越大，模型能力和知識覆蓋通常越強
同時對顯存或記憶體的要求也會更高

所以 31B 屬於比較大的模型，運行門檻也會更高。

`Gemma-4` 又表示什麼

Gemma-4 表示模型系列與代際：

Gemma：Google 的開源模型系列
4：該系列的第 4 代版本

怎麼選

如果你的目標是聊天、問答、翻譯、寫程式，通常優先選擇帶 -it 的版本。

如果你做的是更底層的研究、微調或自訂訓練任務，才更可能去看基礎版。

一句話總結

gemma-4-31B-it 可以直接理解成：Gemma 4 系列、310 億參數、適合對話與指令任務的版本。

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，通常更穩妥。

Windows 區域網存取 Ollama API 設定指南

Sat, 11 Apr 2026 16:43:52 +0800

如果你希望區域網內其他裝置存取本機 Ollama API，可以依照下面步驟設定。

設定監聽埠

先把 Ollama 監聽位址改為所有網卡：

OLLAMA_HOST=0.0.0.0:11434

開啟防火牆

開啟防火牆進階設定後，新增一條輸入規則並放行目標連接埠（例如 8080）：

按下 Win + S，搜尋並開啟「Windows Defender 防火牆」。
點擊「進階設定」。
選擇「輸入規則」 -> 「新增規則…」。
規則類型選「連接埠」，點擊「下一步」。
選擇協定（通常是 TCP），在「特定本機連接埠」輸入要開放的連接埠（例如 8080），點擊「下一步」。
選擇「允許連線」，點擊「下一步」。
在「設定檔」中勾選「網域」「私人」「公用」，點擊「下一步」。
為規則命名（例如 OpenPort8080），點擊「完成」。

執行 Ollama

Ollama run 模型

透過 API 存取模型

curl http://192.168.x.xxx:11434/api/generate -d '{
  "model": "gemma4",
  "prompt": "这个是什么模型?"
}'

Gemma 4 本地調用指南：從一鍵啟動到開發整合

Fri, 10 Apr 2026 22:54:17 +0800

如果你想在本地調用 Gemma 4，可以依需求從以下四種主流方案中選擇。

1) 最快上手：Ollama（推薦）

這是門檻最低的方式，適合快速測試、日常對話與本地 API 調用。

`1`	`ollama run gemma4`

特點：

支援 Win/Mac/Linux
自動處理硬體加速
提供相容 OpenAI 風格的本地 API

2) 圖形介面：LM Studio / Unsloth Studio

如果你偏好桌面 GUI（像 ChatGPT）：

LM Studio：可直接搜尋與下載 Hugging Face 上的 Gemma 4 量化模型（如 4-bit、8-bit），並查看資源占用。
Unsloth Studio：除推理外，也支援低顯存微調；對 6GB-8GB 顯存更友善。

3) 低配與深度控制：llama.cpp

適合舊機、純 CPU 場景，或希望細調推理參數的使用者。

你可以使用 .gguf 模型檔配合量化版本，在更低硬體門檻下運行 Gemma 4。

4) 開發者整合：Transformers / vLLM

如果你要把 Gemma 4 接進自己的應用：

Transformers：適合 Python 專案直接載入模型
vLLM：適合高效能 GPU 與高吞吐推理服務

快速選型

需求	推薦工具	硬體門檻
我只想先跑起來	Ollama	低（自動適配）
我想用圖形介面	LM Studio	中
顯存很吃緊（6GB-8GB）	Unsloth / llama.cpp	低
我要做本地 AI 應用開發	Ollama / Transformers / vLLM	中到高
我要做微調訓練	Unsloth Studio	中到高

模型尺寸建議

Gemma 4 有多種尺寸（如 E2B、E4B、31B）。

一般筆電建議先用量化後的 E2B / E4B
顯存充足後再嘗試更大版本

Ollama 雲模型是什麼，怎麼用

Thu, 09 Apr 2026 18:42:32 +0800

如果你平時用 Ollama 跑本地模型，應該很容易理解雲模型。

區別只有一個核心點：
本地模型是在你的電腦上推理，雲模型是在 Ollama 的雲端推理，再把結果回傳給你。

雲模型是什麼

Ollama 雲模型保留了 Ollama 的呼叫方式，但把計算位置從本地換到了雲端。

這樣做的好處是：

本地硬體壓力更小
更容易使用本地機器跑不動的大模型
仍然可以沿用熟悉的 Ollama 工作流

和本地模型的區別

對比項	本地模型	雲模型
運行位置	本機	雲端
硬體要求	高	低
延遲	更低	受網路影響
隱私性	更強	請求會發送到雲端

如果你更在意隱私、低延遲和離線使用，本地模型更適合。
如果你本地硬體不夠，但又想體驗更大的模型，雲模型更方便。

怎麼識別雲模型

目前 Ollama 的雲模型一般會帶 -cloud 後綴，例如：

`1`	`gpt-oss:120b-cloud`

可用模型列表可能會變化，實際以 Ollama 官方頁面為準。

怎麼用

先登入：

`1`	`ollama signin`

登入完成後，直接運行雲模型：

`1`	`ollama run gpt-oss:120b-cloud`

如果你是在程式裡呼叫，也可以配置 API Key：

`1`	`export OLLAMA_API_KEY=your_api_key`

Python 示例：

import os
from ollama import Client

client = Client(
    host="https://ollama.com",
    headers={"Authorization": "Bearer " + os.environ["OLLAMA_API_KEY"]},
)

messages = [
    {"role": "user", "content": "為什麼天空是藍色的？"}
]

for part in client.chat("gpt-oss:120b-cloud", messages=messages, stream=True):
    print(part["message"]["content"], end="", flush=True)

小結

Ollama 雲模型可以理解成一句話：

命令基本沒變，只是模型不在你本地跑了。

如果你的電腦帶不動大模型，但你又想繼續用 Ollama 的方式呼叫模型，雲模型就是一個很直接的方案。

從 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 工作流。

Ollama 下載模型 pull 速度很慢的排查與解決辦法

Thu, 09 Apr 2026 10:42:39 +0800

ollama pull model_name:tag 在有些地區下載速度會很慢，而且過程並不穩定。

如果你遇到的是大模型下載到一半反覆中斷、報錯 TLS handshake timeout 或 unexpected EOF，那麼問題很可能不只是 registry.ollama.ai 本身，而是後續跳轉到的實際下載鏈路。

這篇文章記錄一次簡單直接的排查思路：先拿到模型檔案的真實下載地址，再確認最終流量落到哪裡，最後只針對關鍵網域做網路優化。

取得模型檔案的下載地址

可以借助下面這個專案，把 Ollama 模型對應的 manifest 與 blob 下載地址直接提取出來：

https://github.com/Gholamrezadar/ollama-direct-downloader

以 gemma4:latest 為例，可以提取出類似下面這些連結。

Manifest 位址

`1`	`https://registry.ollama.ai/v2/library/gemma4/manifests/latest`

Blob 位址

https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:56380ca2ab89f1f68c283f4d50863c0bcab52ae3f1b9a88e4ab5617b176f71a3

如果你只是想快速驗證，也可以直接用 curl 下載 manifest 與 blob：

curl -L "https://registry.ollama.ai/v2/library/gemma4/manifests/latest" -o "latest"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11" -o "sha256-f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a" -o "sha256-4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2" -o "sha256-7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2"

跳轉後的真實下載地址

嘗試用 wget 下載其中一個 blob，會發現請求並不是一直停留在 registry.ollama.ai，而是會繼續跳轉到一個 Cloudflare R2 物件儲存地址：

`1`	`wget https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a`

從日誌裡可以看到幾個關鍵資訊：

registry.ollama.ai 回傳了 307 Temporary Redirect
最終下載地址落在 *.r2.cloudflarestorage.com
真正承載大檔案傳輸的，實際上是後面的物件儲存網域

這一步很重要，因為它說明如果你的代理或分流規則只覆蓋了 registry.ollama.ai，但沒有處理 *.r2.cloudflarestorage.com，那下載仍然可能很慢，甚至反覆中斷。

下面是一次實際抓到的跳轉日誌：

wget https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
--2026-04-09 09:22:04--  https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
Resolving registry.ollama.ai (registry.ollama.ai)... 104.21.75.227, 172.67.182.229, 2606:4700:3034::ac43:b6e5, ...
Connecting to registry.ollama.ai (registry.ollama.ai)|104.21.75.227|:443... connected.
HTTP request sent, awaiting response... 307 Temporary Redirect
Location: https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?... [following]
--2026-04-09 09:22:05--  https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?...
Resolving dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com (dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com)... 172.64.66.1, 2606:4700:2ff9::1
Connecting to dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com|172.64.66.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9608338848 (8.9G) [application/octet-stream]

調整網路設定

確認真實下載鏈路之後，排查方向就會清晰很多。

如果你正在使用代理、分流或自訂 DNS，建議優先檢查下面幾件事：

registry.ollama.ai 與 *.r2.cloudflarestorage.com 是否走了同一條穩定線路
代理規則是否只覆蓋了前者，而漏掉了後者
目前出口是否適合持續下載數 GB 到數十 GB 的大檔案

這類問題的關鍵並不是「能不能打開官網」，而是「跳轉後的物件儲存鏈路是否穩定、是否能長時間持續傳輸」。很多時候，真正需要優化的是 Cloudflare R2 這一層，而不是前面的 registry 網域。

調整前後的對比

下面是一次實際下載 gemma4:31b-it-q8_0 時的表現。

調整前，下載速度較慢，而且會在中途報錯：

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  38% ▕██████████████████████                                    ▏  12 GB/ 33 GB  1.2 MB/s   4h40m
Error: max retries exceeded: unexpected EOF

調整後，再次下載同一個模型時，速度和穩定性都有明顯改善：

1
2
3

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  46% ▕████████████████████████████████████████████████████████████████▏ 15 GB/ 33 GB  8.5 MB/s  35m23s

這並不代表所有網路環境都能得到同樣結果，但至少說明了一點：瓶頸很可能不在 Ollama 用戶端本身，而在實際的大檔案下載鏈路。

一個更實用的排查順序

如果你也遇到類似問題，可以按這個順序來：

先執行一次 ollama pull 或 ollama run，確認問題是否穩定重現。
再用 wget 或 curl -L 測一個 blob 位址，確認是否跳轉到 *.r2.cloudflarestorage.com。
最後只針對真實下載網域調整代理或分流，再重新測試速度和穩定性。

這樣做的好處是，每一步都在驗證一個明確假設，不需要盲目試錯。

結論

ollama pull 下載慢，很多時候並不是因為 registry.ollama.ai 無法存取，而是因為真正承載大檔案下載的 Cloudflare R2 鏈路不夠穩定。

所以更有效的做法不是反覆重試，而是先把真實下載鏈路找出來，再針對實際流量落點做優化。

樹莓派 5 跑 Gemma 4 實測：可行，但回應較慢

Wed, 08 Apr 2026 18:42:00 +0800

我做了一次偏極限的嘗試：在 Raspberry Pi 5（8GB RAM） 上運行 Gemma 4。目標不是大模型版本，而是最小體量的 E2B。

結論先說：能跑、能用，但更適合低互動頻率場景，不適合高即時要求的對話體驗。

測試環境

設備：Raspberry Pi 5（4 核 CPU，8GB RAM）
系統：Ubuntu Server（無圖形介面）
存取方式：SSH
模型運行方式：LM Studio CLI（僅命令列模式）
模型：Gemma 4 E2B（約 4.5GB）

第 1 步：安裝並啟動 LM Studio CLI

我在樹莓派上安裝了 LM Studio 的 CLI 版本，然後啟動服務並查看可用命令。

由於是純命令列環境，這種僅命令列部署方式非常適合樹莓派。

第 2 步：把模型儲存切到 SSD

為了避免頻繁讀寫 SD 卡，我把模型下載目錄改到了外接 SSD。

樹莓派 5 接 SSD 的體驗明顯比早期機型更實用，長期運行本地模型建議優先使用 SSD。

第 3 步：下載並載入 Gemma 4 E2B

下載完成後，模型可以正常載入進記憶體。

按官方資訊，Gemma 4 系列具備：

面向 Agent 場景的工具呼叫能力（function calling）
多模態能力（含影像/影片；小模型也具備語音相關能力）
128K 上下文視窗
Apache 2.0 授權（可商用）

從樹莓派的硬體條件看，E2B 這一檔更適合先試起來。

第 4 步：啟動 API 並開放區域網路存取

模型載入後，我先在本機連接埠啟動 API（4000），並透過 HTTP 請求確認模型清單可返回。

問題在於：預設只監聽本機，區域網路其他設備無法直接存取。

因為啟動參數裡不能直接設定 host，我用了 socat 做連接埠轉發，把樹莓派外部連接埠請求橋接到 LM Studio 內部連接埠，實現區域網路存取。

結果是可行的：我在同一區域網路的 MacBook 上能成功請求並拿到模型清單。

第 5 步：接入編輯器（Zed）

LM Studio 的本地服務相容 OpenAI API 形態，因此多數支援自訂 base_url 的工具都可以直接接入。

我在 Zed 裡新增了一個 LLM provider，指向樹莓派上的 Gemma 4 實例，隨後在編輯器內聊天測試通過。

實際可用性判斷

這套方案適合：

本地自動化腳本
低併發、低即時性要求的輔助任務
個人學習與邊緣設備實驗

不太適合：

高頻互動聊天
對回應延遲敏感的開發協作場景

結論

在 Raspberry Pi 5 上運行 Gemma 4（E2B）是可行的，而且實際效果比預期更好。

如果你的目標是「能離線跑、能接工具、能完成輕中量任務」，這條路線值得嘗試；如果目標是流暢即時互動，仍建議上更強硬體。

OpenClaw 對接本地 Gemma 4：完整配置指南

Wed, 08 Apr 2026 18:18:00 +0800

這篇文章示範如何把 OpenClaw 對接到本地 Gemma 4 模型（透過 Ollama 提供介面）。

如果你還沒完成本地部署，可先參考：

如何在筆記型電腦上運行 Gemma 4：5 分鐘本地部署指南

第 1 步：啟動 Ollama API 服務

先啟動 Ollama 服務：

`1`	`ollama serve`

你可以用下面的命令快速測試 API 是否正常：

curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:12b",
  "prompt": "你好"
}'

如果能返回模型輸出，代表本地 API 已可用。

第 2 步：配置 OpenClaw 接入 Ollama

OpenClaw 配置檔路徑通常為：

`1`	`~/.openclaw/config.yaml`

編輯 config.yaml，在 models 中新增一個本地模型條目：

models:
  # 你已有的模型配置...

  gemma4-local:
    provider: ollama
    base_url: http://localhost:11434
    model: gemma4:12b
    timeout: 120s

第 3 步：設定預設模型（可選）

如果你希望預設走 Gemma 4，可新增：

`1`	`default_model: gemma4-local`

第 4 步：重啟並驗證 OpenClaw

重啟 OpenClaw：

`1`	`openclaw restart`

查看模型列表：

`1`	`openclaw models list`

發起一次對話測試：

`1`	`openclaw chat --model gemma4-local "你好"`

如果對話回傳正常，代表 OpenClaw 已成功接入本地 Gemma 4。

常見排查

connection refused：先確認 ollama serve 是否在運行。
找不到模型：檢查模型名是否與 ollama list 一致（例如 gemma4:12b）。
回應超時：可適度提高 timeout，並優先測試較小模型。

如何在筆記型電腦上運行 Gemma 4：5 分鐘本地部署指南

Wed, 08 Apr 2026 18:06:00 +0800

如果你想在筆記型電腦上本地運行 Gemma 4，Ollama 是目前最省事的方式之一。即使不折騰複雜環境，通常 5 分鐘左右也能跑起來。

第 1 步：安裝 Ollama

打開 https://ollama.com，下載對應系統的安裝包。
按系統完成安裝：

macOS：拖到 Applications。
Windows：執行 .exe 安裝程式。
Linux：使用官網提供的安裝腳本。

安裝完成後，Ollama 會以背景服務形式運行。除初次安裝外，日常可以只用簡單命令。

第 2 步：下載 Gemma 4 模型

打開終端機，執行：

`1`	`ollama pull gemma4:4b`

如果你的機器性能更強，可以改成 12b 或 27b。下載完成後，模型會保存在本地。

查看已下載模型：

`1`	`ollama list`

第 3 步：啟動模型

`1`	`ollama run gemma4:4b`

這會在終端機打開互動式對話。輸入問題後按 Enter 即可；結束會話可輸入：

/bye

如果你更偏好網頁聊天介面，可以搭配 Open WebUI 使用。它可以把 Ollama 包裝成瀏覽器端 UI，通常透過 Docker 幾分鐘即可完成配置。

筆記型電腦效能優化建議

Apple Silicon（M2/M3/M4）：預設走 Metal，加速效果通常很好，12B 也有不錯體驗。
NVIDIA 顯示卡：檢測到相容 GPU 時會自動使用 CUDA，建議提前更新驅動。
僅 CPU 推理：可以運行，但大模型會明顯變慢；多數 CPU-only 場景建議優先 4B。
釋放記憶體：載入大模型前盡量關閉占記憶體應用。經驗上每 10 億參數大約需要 0.5GB 到 1GB 記憶體。

模型怎麼選

Gemma 4 1B：適合輕量問答、基礎摘要、快速查詢；複雜推理能力有限。
Gemma 4 4B：適合多數日常任務（寫作輔助、程式輔助、資料整理），速度與品質平衡較好。
Gemma 4 12B：適合更長上下文與更複雜任務，在程式與推理場景更穩。
Gemma 4 27B：適合高要求任務，效果更接近雲端大模型，但對硬體要求明顯更高。

Android 上安裝並運行 Gemma 4：完整上手指南

Wed, 08 Apr 2026 17:55:53 +0800

如果你想在手機上離線體驗 Gemma 4，這篇文章會帶你從安裝到實用功能一步步跑通。

第 1 步：取得應用

Google AI Edge Gallery 目前不在 Google Play 上架，需要透過 APK 側載安裝。

在 Android 裝置上依序進入：

設定 -> 應用程式 -> 特殊應用程式存取權 -> 安裝未知應用程式

然後：

找到你使用的瀏覽器（例如 Chrome 或 Firefox），開啟「允許來自此來源」。
在手機瀏覽器打開 Google AI Edge Gallery 的 GitHub Releases 頁面。

位址：https://github.com/google-ai-edge/gallery/releases

下載最新的 .apk 安裝包。
下載完成後，在通知欄或檔案管理器中點開安裝包，按提示完成安裝。

網路正常時，這一步通常約 2 分鐘可完成。

第 2 步：首次開啟並授權

首次開啟 AI Edge Gallery 時，應用會請求儲存權限，用於保存模型檔案。建議直接允許，否則應用無法下載或載入模型。

首頁一般會看到這些入口：

Ask Image：影像理解任務（描述圖片、回答圖片相關問題）
AI Chat：一般文字對話
Summarize：貼上文字並產生摘要
Smart Reply：產生回覆建議

大多數使用者最常用的是 AI Chat。

第 3 步：下載 Gemma 4 模型

進入 AI Chat。
按提示點擊 Get Models。
在模型清單中選擇 Gemma 4 版本（會顯示對應體積）。
按裝置性能選擇模型；如果手機是 8GB RAM，可先從 Gemma 4 4B 開始。
點擊 Download，背景開始下載。

注意：模型越大，下載時間越長。你也可以下載多個模型，後續按需切換，已下載模型會保存在本機，不必重複下載。

第 4 步：開始對話

模型下載完成後：

點擊模型名稱進行載入（首次載入通常需要 10 到 30 秒，取決於模型大小和裝置性能）。
在聊天框輸入問題並送出。
模型會在本地產生回覆，資料不會上傳到雲端。

一般第一條回覆會稍慢，這是模型預熱的正常現象；同一會話後續回覆通常更快。

第 5 步：體驗視覺能力（Gemma 4 多模態）

如果你下載的是 Gemma 4 多模態版本：

返回主選單，進入 Ask Image。
選擇一張圖片，或直接拍照。
輸入你想問的問題（例如「這張圖裡有什麼？」或「圖裡有哪些文字需要注意？」）。
等待模型在本地分析並回傳結果。

這項功能可以離線使用，圖片內容也不會傳送到外部伺服器。

Google Gemma 4 模型對比：2B/4B/26B/31B 怎麼選？

Sun, 05 Apr 2026 08:30:00 +0800

Gemma 4 主打 多模態 與 本地離線運行，並提供從輕量端到高性能端的完整模型梯度。對大多數本地部署使用者來說，關鍵不是選最大，而是選最符合硬體與任務需求的版本。

Gemma 4 各模型對比

下表用於快速選型參考；具體性能與資源占用請以實際部署環境測試為準。

模型	參數規模	定位	主要優勢	主要限制	推薦場景
Gemma 4 2B	20 億	超輕量	延遲低、資源占用小、部署門檻最低	複雜推理與長鏈路任務能力有限	行動端、IoT、輕量問答、簡單自動化
Gemma 4 4B	40 億	輕量增強	比 2B 更穩定的理解與生成能力，仍易於本地部署	高強度編碼與複雜 Agent 任務上限有限	本地助手、基礎文件處理、多語言日常任務
Gemma 4 26B	260 億	高性能（專家混合）	推理與工具調用能力明顯提升，適合生產工作流	顯存需求顯著上升，硬體門檻更高	編程助手、複雜工作流、企業內部 Agent
Gemma 4 31B	310 億	高性能（稠密）	綜合能力最強，複雜任務穩定性更好	資源成本最高，部署與調優成本更大	高要求推理、複雜程式任務、重度自動化

怎麼選：按硬體和任務倒推

如果你主要關心「能不能跑、跑得順不順」，可以按下面選：

8GB 顯存：優先 2B/4B。
12GB 顯存：優先 4B 或更高模型的量化版本。
24GB 顯存：可重點考慮 26B，並依任務評估 31B 量化版。
更高顯存或多卡：可嘗試 31B 的高精度配置。

建議先保證穩定性與推理速度，再逐步提升模型規模。

四類典型使用場景

1) 本地通用助手

優先模型：4B
原因：成本與效果平衡佳，適合長期常駐運行。

2) 程式與自動化

優先模型：26B
原因：在多步驟任務、工具調用、腳本生成上更穩。

3) 高難度推理與複雜 Agent

優先模型：31B
原因：在複雜上下文下穩定性更高、容錯更好。

4) 邊緣設備與輕量離線

優先模型：2B
原因：最容易在資源受限設備落地。

部署建議（Ollama 方向）

更實用的做法是小步快跑：

先用 4B 建立可運行基線（速度、記憶體、效果）。
把真實任務做成固定測試集（例如 20 條常見問題 + 10 個自動化任務）。
再升級到 26B/31B 對比準確率、時延與顯存成本。
只在收益明顯時升級大模型。

這樣可以避免一開始就追求大參數，導致卡頓、吞吐低與維護複雜度上升。

結論

Gemma 4 的真正價值，不是單純參數更大，而是提供了從輕量到高性能的一整套可落地梯度：

想低成本快速上線：從 2B/4B 開始。
想讓本地 AI 真正接入生產流程：優先 26B。
想衝擊複雜推理與重度自動化：再上 31B。

Gemma 4 的最佳選擇通常不是參數最大，而是與硬體條件與任務目標匹配度最高的版本。

本地大模型 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 腳本管理多個模型

模型選擇要看三件事

常見問題

小結

Claude Code + Ollama 本地部署教學：用 CC Switch 打造免費 AI 編程助手

這套方案解決什麼問題

基本準備

CC Switch 關鍵配置

Claude Code 強在哪裡

Ollama 在這裡扮演什麼角色

體驗邊界在哪裡

多模態相容性還不穩定

適合誰嘗試

使用建議

小結

本地執行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的嘗試

ds4 是什麼

為什麼值得關注

適合誰用

使用方式

目前的風險

和通用推理工具的區別

小結

參考

llama.cpp 多 GPU 性能實測思路：2x V100 16GB 會比單卡 32GB 快嗎？

先分清 split mode

單卡 32GB 能放下時：雙 16GB 不一定更快

單卡 16GB 放不下時：雙卡價值很大

V100 PCIe 和 V100 SXM2 差別很大

怎麼選更實際

什麼時候買 2x16GB，什麼時候買 1x32GB

layer split 和 tensor split 怎麼用

prefill 和 decode 為什麼表現不同

KV cache 會不會成為第二個顯存瓶頸

用 llama-bench 做自己的雙卡測試

一句話結論

RTX 5090 / 5080 AI 推理效能實測：本地大模型、4K 影片生成和即時 3D 怎麼選

先看硬體差距

本地大模型：32GB 顯存更關鍵

FP4 是潛力，不是所有應用的即插即用加速

圖像生成和 4K 影片：頻寬與顯存一起決定體驗

即時 3D 和 AI 建模：RTX 5090 更適合重場景

該怎麼選

小結

參考資料

DeepSeek V4 本地私有化部署方案：國產晶片與消費級顯卡叢集怎麼選

先明確部署目標

不要一上來就追求滿血 Pro

國產晶片路線：適合企業級私有雲

消費級顯卡叢集：適合試點和中小團隊

可能的部署架構

硬體選型思路

驗證階段