Ollama on KnightLi的博客

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 編程流程，這個方案值得試試。只是要記住：先從小任務開始，每次改動都要驗證，把本地模型當助手，而不是自動工程師。

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

解決 Ollama 使用 CPU 而不使用 GPU 運算的問題

Fri, 24 Apr 2026 18:30:00 +0800

本地跑大模型時，最讓人困惑的一類問題就是：機器明明有顯卡，Ollama 卻還是主要吃 CPU，速度也慢得離譜。

先說結論，這類問題通常不是單一原因。最常見的幾類分別是：

Ollama 根本沒有識別到可用 GPU
驅動、ROCm 或 CUDA 環境沒裝對
Ollama 服務啟動時沒有繼承正確的環境變數
模型太大，實際已經退回到 CPU 或 CPU/GPU 混合載入
AMD 平台存在額外相容性問題，例如 ROCm 版本、gfx 代號或裝置可見性設定不對

下面按最省時間的順序排查。

1. 先確認是不是真的沒用到 GPU

最直接的方法是看：

`1`	`ollama ps`

重點看 PROCESSOR 這一欄。

100% GPU：表示模型完整跑在顯卡上
100% CPU：表示完全沒用上顯卡
48%/52% CPU/GPU 這類結果：表示模型部分進了顯存，部分落到系統記憶體

如果你看到的是 100% CPU，後面就該重點查環境和服務設定。
如果看到的是混合載入，那不一定代表顯卡沒生效，更可能只是顯存不夠。

2. 先排除最常見的誤區：模型塞不進顯存

很多人以為只要裝了 GPU，Ollama 就一定會全顯卡推理。其實不是。

如果模型太大、上下文太長，或者機器上已經有其他模型佔著顯存，Ollama 很可能會退回到：

部分 GPU + 部分 CPU
直接 100% CPU

這時候可以先做兩個最簡單的驗證：

換一個更小的模型測試
例如先用 4B、7B 這類小模型，而不是一上來就跑更大的參數量。
卸載其他已載入的模型後再試
先看 ollama ps，確認沒有別的模型佔著顯存。

如果小模型能上 GPU、大模型不行，問題通常就不在驅動，而在顯存容量。

3. 檢查顯卡驅動和底層環境是否可用

如果連小模型都只能跑 CPU，下一步就該看底層環境。

NVIDIA 方向

先確認驅動正常、系統能看到顯卡。常見檢查方式包括：

`1`	`nvidia-smi`

如果這裡都報錯，Ollama 幾乎不可能正常使用 GPU。

AMD / ROCm 方向

如果你是 AMD GPU，尤其是 ROCm 環境，重點先看：

1
2

rocminfo
rocm-smi

如果這些工具都不能正常列出裝置，說明問題還在 Ollama 之前，先不要繼續折騰應用層。

對 AMD 來說，最常見的問題不是「有沒有裝驅動」，而是：

ROCm 版本和系統版本不匹配
當前 GPU 架構支援不完整
裝置雖然存在，但執行環境沒有正確暴露給 Ollama

4. 重啟 Ollama 服務，不要只重開終端

這是非常高頻的坑。

很多人裝完驅動、改完環境變數、補完 ROCm 之後，只是重新開一個終端，然後直接繼續 ollama run。但如果 Ollama 是以背景服務方式執行，它很可能還在用舊環境。

所以更穩的做法是：

完整重啟 Ollama 服務
必要時直接重啟系統

如果你是在 Linux 上以服務方式執行，通常要確認服務進程已經重新拉起，而不是沿用之前的舊進程。

5. 檢查服務環境變數有沒有真的傳進去

這一步在 AMD ROCm 環境尤其重要。

有些機器在終端裡手動執行命令沒問題，但 Ollama 服務還是只跑 CPU，原因就是服務進程沒有拿到你在 shell 裡設定的變數。

常見需要關注的變數包括：

1
2

ROCR_VISIBLE_DEVICES
HSA_OVERRIDE_GFX_VERSION

其中：

ROCR_VISIBLE_DEVICES 用來限制或指定 ROCm 能看到哪些 GPU
HSA_OVERRIDE_GFX_VERSION 常見於某些 AMD 平台的相容性處理

如果你只是在當前終端裡臨時 export 了變數，但 Ollama 是 systemd、桌面背景服務或其他守護進程啟動的，這些變數未必會生效。

也就是說，終端裡「看起來已經設定好了」，不代表 Ollama 真的拿到了。

6. AMD 平台重點看 ROCm 相容性

從公開頁面資訊來看，這個問題對應的影片主題本身就落在 AMD Max+ 395、strix halo、AMD ROCm 這條線上。
這類環境裡，Ollama 不走 GPU，往往比 NVIDIA 平台更依賴版本匹配。

可以優先排查下面幾項：

ROCm 版本是否適合當前系統和顯卡
當前 GPU 是否屬於 ROCm 支援較好的架構範圍
是否需要補 HSA_OVERRIDE_GFX_VERSION
是否是舊版 Ollama 或舊版底層推理庫導致相容性問題

如果你已經確認 rocminfo 正常、GPU 也能被系統識別，但 Ollama 仍然只跑 CPU，那大概率就要回到版本組合上重新檢查，而不是繼續盲目調模型參數。

7. Docker、WSL 或遠端環境要額外檢查裝置映射

如果你不是直接在裸機跑，而是在下面這些環境裡執行：

Docker
WSL
遠端容器
虛擬化環境

那還要多看一層：GPU 裝置有沒有真的暴露進去。

典型現象是：

宿主機能看到 GPU
容器裡的 Ollama 卻只能跑 CPU

這時要先確認不是 Ollama 本身的問題，而是容器或子系統根本沒拿到 GPU 存取權限。

8. 最後再看日誌，而不是一開始就亂猜

如果前面都查過了，最有效的做法不是繼續反覆重裝，而是直接看 Ollama 的啟動日誌和執行日誌。

重點看兩類資訊：

有沒有識別到 GPU
有沒有出現驅動、庫載入、裝置初始化失敗之類的報錯

只要日誌裡明確出現類似「找不到相容 GPU」或「ROCm/CUDA 初始化失敗」，排查方向就會立刻清楚很多。

排查順序

如果你只想記最短路徑，可以按這個順序來：

ollama ps 看現在到底是 GPU、CPU 還是混合載入
換一個更小的模型，排除顯存不夠
用 nvidia-smi、rocminfo、rocm-smi 先確認底層環境正常
完整重啟 Ollama 服務
檢查服務環境變數，尤其是 AMD 的 ROCR_VISIBLE_DEVICES、HSA_OVERRIDE_GFX_VERSION
如果是 Docker / WSL，再檢查裝置映射
最後看日誌定位具體報錯

結語

Ollama 使用 CPU 而不使用 GPU，本質上通常是三類問題之一：

GPU 根本沒有被識別
GPU 能被識別，但執行環境沒有傳到 Ollama
GPU 在工作，但模型太大，最後還是回落到 CPU 或混合記憶體

先把這三類分開，排查就會快很多。
如果你是 AMD 平台，尤其要把注意力放在 ROCm 版本、裝置可見性和相容性變數上，而不是只看 Ollama 命令本身。

原影片：https://www.bilibili.com/video/BV1cHoYBqE8k/

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

Windows 用 WSL + Ollama 本地部署 Hermes Agent，並接入 Telegram

Sat, 18 Apr 2026 00:48:22 +0800

如果你想在 Windows 上盡量低門檻地跑 Hermes Agent，一個比較順手的路徑是：

宿主系統繼續用 Windows
在 WSL 裡跑 Ubuntu
用 Ollama 提供本地模型
讓 Hermes Agent 直接連接本地 Ollama 介面

這樣做的好處是環境相對乾淨，命令大多按 Linux 方式執行，同時又不需要單獨準備一台 Linux 機器。

整體流程

這套部署可以拆成 4 步：

啟用 WSL 並安裝 Ubuntu
在 Ubuntu 裡補齊 Python、Node.js、Git 等執行環境
安裝 Ollama 並拉取本地模型
安裝 Hermes Agent，再接入 Telegram

如果你只想先把 Hermes Agent 跑起來，其實做到第 3 步就已經很接近完成了。

1. 安裝 WSL 和 Ubuntu

在管理員權限的 PowerShell 裡執行：

`1`	`wsl --install`

安裝完成後重新啟動電腦，然後繼續安裝 Ubuntu：

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

之後打開 WSL 裡的 Ubuntu，後續命令基本都在這裡執行。

2. 更新 Ubuntu，並安裝基礎環境

先更新系統：

1
2

sudo apt update
sudo apt upgrade -y

然後安裝 Python、解壓工具、Node.js 和 Git。

安裝 Python

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

安裝 zstd

`1`	`sudo apt install -y zstd`

安裝 Node.js

1
2

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

安裝 Git

1
2

sudo apt update
sudo apt install -y git

安裝完成後可以順手檢查一下：

1
2
3

node -v
npm -v
git --version

3. 安裝 Ollama，並拉取 Gemma 4

安裝 Ollama：

`1`	`curl -fsSL https://ollama.com/install.sh \| sh`

如果你打算給 Hermes Agent 配一個本地模型，可以直接從 Gemma 4 開始。

例如：

`1`	`ollama run gemma4:e4b`

如果機器資源更弱，也可以試：

`1`	`ollama run gemma4:e2b`

更大的版本還有：

1
2

ollama run gemma4:26b
ollama run gemma4:31b

對大多數 Windows + WSL 的普通機器來說，gemma4:e4b 通常是更實際的起點。

4. 安裝並配置 Hermes Agent

安裝命令：

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

安裝完成後，給它指定 Ollama 的本地介面：

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

模型名填你本地實際在用的那個，例如：

`1`	`gemma4:e4b`

如果安裝腳本要求刷新 shell，可以執行：

`1`	`source ~/.bashrc`

Hermes Agent 常用命令

平時最常用的是下面幾個：

啟動

hermes

重新進入配置

`1`	`hermes setup`

配置聊天平台閘道

`1`	`hermes setup gateway`

更新

`1`	`hermes update`

接入 Telegram 的基礎步驟

如果你要讓 Hermes Agent 透過 Telegram 收發訊息，核心還是先跑一遍：

`1`	`hermes setup gateway`

然後準備 Telegram 端需要的兩個東西：

用 BotFather 建立機器人
用 @userinfobot 取得你的 User ID

拿到這些基礎資訊後，再按 Hermes Agent 的閘道配置繼續填入即可。

這套方案適合什麼人

這套方式比較適合下面幾類使用者：

平時主力系統就是 Windows
不想單獨折騰完整 Linux 主機
想先把本地 Agent 跑通，再慢慢擴展聊天平台接入
希望優先用本地模型，不依賴雲端 API

如果你只是想本地體驗一個 Agent，而不是一開始就做複雜生產部署，這條路線已經足夠實用。

需要注意的幾個點

WSL 本質上還是一層相容環境，極端場景下穩定性未必和原生 Linux 完全一樣
大模型能不能跑得順，最終還是取決於你的記憶體、顯存和 CPU / GPU 條件
gemma4:e4b 雖然是比較現實的起點，但具體體驗還是要看機器配置
Hermes Agent 的聊天平台接入屬於「能力擴展」，先把本地模型鏈路跑通，再加 Telegram，會更穩

結論

如果你想在 Windows 上盡量簡單地本地部署 Hermes Agent，比較順的順序就是：

WSL -> Ubuntu -> Ollama -> Gemma 4 -> Hermes Agent -> Telegram

先把本地模型跑通，再做閘道接入，成功率會高很多。對大多數使用者來說，這比一上來就堆很多元件更容易排錯，也更適合後續繼續擴展。

原文參考

本文根據下列頁面內容整理並改寫：

X超哥博客：太简单了！Hermes Agent 本地部署（无需API）接入 Telegram + 微信

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 鏈路不夠穩定。

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

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：適合高要求任務，效果更接近雲端大模型，但對硬體要求明顯更高。

如何判斷 Ollama 模型是否已載入到 GPU

Mon, 06 Apr 2026 10:15:18 +0800

想確認 Ollama 模型是否真的跑在 GPU 上，最直接的方法就是查看目前已載入模型的處理器占用資訊。

使用指令

`1`	`ollama ps`

範例輸出

1
2

NAME        ID            SIZE    PROCESSOR   UNTIL
llama3:70b  bcfb190ca3a7  42 GB   100% GPU    4 minutes from now

如何解讀 `PROCESSOR` 欄位

100% GPU：模型完全載入在 GPU 顯存中。
100% CPU：模型完全載入在系統記憶體中（未使用 GPU 推理）。
48%/52% CPU/GPU：模型部分在系統記憶體、部分在 GPU 顯存中，屬於混合載入。

實用建議

如果你預期使用 GPU，但看到 100% CPU，先檢查顯卡驅動、CUDA/ROCm 環境與 Ollama 執行參數。
模型參數量較大、顯存不足時，通常會出現 CPU/GPU 混合載入。
排查效能問題時，先執行 ollama ps 再看速度數據，能更快定位瓶頸。

總結

ollama ps 是判斷模型是否真正使用 GPU 的第一步。重點看 PROCESSOR 欄位，就能快速確認目前載入位置，並據此決定後續優化方向。

Ollama 模型預設儲存位置與遷移方法（避免 C 槽爆滿）

Mon, 06 Apr 2026 09:38:00 +0800

本機執行大模型時，最容易先爆掉的通常是系統碟。Ollama 預設會把模型下載到使用者目錄或系統目錄，如果不先規劃路徑，C 槽很快就會被占滿。

Ollama 常見預設模型目錄

Windows：C:\Users\<使用者名稱>\.ollama\models
macOS：~/.ollama/models
Linux：/usr/share/ollama/.ollama/models（不同安裝方式可能略有差異）

Windows：把模型目錄遷移到非系統碟

建議將模型目錄遷移到例如 D:\OllamaModels。核心做法是設定系統環境變數 OLLAMA_MODELS。

1. 建立目標目錄

例如先建立：D:\OllamaModels

2. 設定系統環境變數

變數名稱：OLLAMA_MODELS
變數值：D:\OllamaModels

可在「系統內容 -> 進階 -> 環境變數」中新增，也可使用命令列設定（系統管理員 PowerShell）：

`1`	`[System.Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "D:\OllamaModels", "Machine")`

3. 重啟 Ollama（或重啟系統）

環境變數生效後，重新啟動 Ollama 服務或應用程式。若不確定是否已生效，直接重啟電腦最穩妥。

4. 驗證新目錄是否生效

拉取任意模型後，檢查 D:\OllamaModels 下是否出現新檔案。

5. 清理舊目錄（確認無誤後）

確認模型已在新目錄正常工作，再刪除舊目錄內容，回收 C 槽空間。

常見問題

設定後仍寫入 C 槽怎麼辦

先確認環境變數是「系統變數」，而不是「目前工作階段臨時變數」。
確認 Ollama 行程已重啟。
檢查變數名稱是否正確：必須是 OLLAMA_MODELS。

是否需要遷移舊模型檔案

如果你不想重複下載，可在停止 Ollama 後手動複製舊模型到新目錄，再啟動 Ollama 驗證。

在 Linux 上徹底移除 Ollama（含殘留清理）

Mon, 06 Apr 2026 09:16:29 +0800

如果你需要在 Linux 上徹底移除 Ollama，可以依照下列順序執行。本文會清理服務、執行檔、模型目錄，以及 ollama 使用者與群組。

移除前提醒

以下指令會刪除本機 Ollama 模型檔案（通常位於 /usr/share/ollama），請先確認是否需要備份。
指令預設使用 sudo，請確認目前帳號具備管理員權限。

1. 停止並移除 systemd 服務

sudo systemctl stop ollama
sudo systemctl disable ollama
sudo rm -f /etc/systemd/system/ollama.service
sudo systemctl daemon-reload

2. 刪除 Ollama 執行檔

OLLAMA_BIN="$(command -v ollama)"
if [ -n "$OLLAMA_BIN" ]; then
  sudo rm -f "$OLLAMA_BIN"
fi

3. 刪除 Ollama 相關函式庫目錄（若存在）

如果你的安裝方式在 lib 目錄寫入了 Ollama 檔案，可用下列方式清理：

1
2
3

for d in /usr/local/lib/ollama /usr/lib/ollama /lib/ollama; do
  [ -d "$d" ] && sudo rm -rf "$d"
done

4. 刪除模型與資料目錄

`1`	`sudo rm -rf /usr/share/ollama`

5. 刪除系統使用者與群組（若存在）

1
2

id -u ollama >/dev/null 2>&1 && sudo userdel ollama
getent group ollama >/dev/null 2>&1 && sudo groupdel ollama

6. 驗證是否已完成移除

1
2

command -v ollama || echo "ollama binary not found"
systemctl status ollama || true

若以上檢查都不再找到 ollama，即代表已移除完成。

大型模型量化詳解：FP16、Q8、Q5、Q4 到 Q2 怎麼選？

Sun, 05 Apr 2026 22:09:11 +0800

量化的核心目標很簡單：用少量精度損失，換取更小體積、更低顯存占用與更快推理速度。
對本地部署使用者來說，選對量化版本，通常比盲目追求大參數更重要。

什麼是量化

量化是指把模型參數從高精度格式（如 FP16）壓縮為更低位寬格式（如 Q8、Q4）。

可以把它理解為：

原始模型：像高精度照片，清晰但檔案大。
量化模型：像壓縮照片，細節略有損失但更輕更快。

常見量化版本對比

量化版本	精度/位寬	體積	品質損失	推薦場景
FP16	16 位浮點	最大	幾乎無損	研究、評測、追求極致品質
Q8_0	8 位整數	較大	幾乎無損	高配電腦，兼顧品質與效能
Q5_K_M	5 位混合	中等	輕微損失	日常主力，平衡方案
Q4_K_M	4 位混合	較小	可接受損失	通用預設，性價比高
Q3_K_M	3 位混合	很小	明顯損失	低配設備，先求能跑
Q2_K	2 位混合	最小	較大損失	極限資源場景，臨時可用

量化命名規則

以 gemma-4:4b-q4_k_m 為例：

gemma-4:4b：模型名稱與參數規模。
q4：4 位量化。
k：K-quants（改進的量化方法）。
m：medium（中等級別，常見還有 s/small、l/large）。

如何按顯存快速選型

內存/顯存	推薦量化
4 GB	Q3_K_M / Q2_K
8 GB	Q4_K_M
16 GB	Q5_K_M / Q8_0
32 GB+	FP16 / Q8_0

建議先從能穩定跑起來的版本開始，再逐步提高精度，而不是一開始就追求最大模型。

實戰建議

預設從 Q4_K_M 開始，先驗證真實任務效果。
如果答案品質不夠，再升到 Q5_K_M 或 Q8_0。
如果主要瓶頸是顯存或速度，再降到 Q3_K_M。
每次切換量化版本，都用同一批測試問題做對比。

結論

品質優先：FP16 或 Q8_0。
平衡優先：Q5_K_M。
通用預設：Q4_K_M。
低配兜底：Q3_K_M 或 Q2_K。

選型的本質不是「越大越好」，而是「在你的硬體條件下，達到最穩定可用的效果」。

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 的最佳選擇通常不是參數最大，而是與硬體條件與任務目標匹配度最高的版本。

Ollama on KnightLi的博客

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

這套方案解決什麼問題

基本準備

CC Switch 關鍵配置

Claude Code 強在哪裡

Ollama 在這裡扮演什麼角色

體驗邊界在哪裡

多模態相容性還不穩定

適合誰嘗試

使用建議

小結

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

先看顯存邊界

推薦一：Qwen3 8B

推薦二：Llama 3.1 8B Instruct

推薦三：Gemma 3 12B

推薦四：DeepSeek R1 Distill Qwen 8B

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

量化怎麼選

用什麼工具運行

上下文不要開太大

不同用途怎麼選

3060 本地 LLM 的合理預期

小結

參考連結

解決 Ollama 使用 CPU 而不使用 GPU 運算的問題

1. 先確認是不是真的沒用到 GPU

2. 先排除最常見的誤區：模型塞不進顯存

3. 檢查顯卡驅動和底層環境是否可用

NVIDIA 方向

AMD / ROCm 方向

4. 重啟 Ollama 服務，不要只重開終端

5. 檢查服務環境變數有沒有真的傳進去

6. AMD 平台重點看 ROCm 相容性

7. Docker、WSL 或遠端環境要額外檢查裝置映射

8. 最後再看日誌，而不是一開始就亂猜

排查順序

結語

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

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

多 GPU 不是簡單疊算力

不需要 SLI 或 NVLink

如何限制 Ollama 使用哪些 NVIDIA GPU

AMD 和 Vulkan 的選擇變數

Docker 裡怎麼暴露多張 GPU

OLLAMA_SCHED_SPREAD 是什麼

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

常見誤區

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

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

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

誤區 4：必須有 NVLink / SLI

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

選卡建議

小結

參考連結

Windows 用 WSL + Ollama 本地部署 Hermes Agent，並接入 Telegram

整體流程

1. 安裝 WSL 和 Ubuntu

2. 更新 Ubuntu，並安裝基礎環境

安裝 Python

安裝 zstd

安裝 Node.js

安裝 Git

3. 安裝 Ollama，並拉取 Gemma 4

4. 安裝並配置 Hermes Agent

Hermes Agent 常用命令

啟動

重新進入配置

配置聊天平台閘道

更新

接入 Telegram 的基礎步驟

這套方案適合什麼人

需要注意的幾個點

結論

原文參考

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

設定監聽埠

開啟防火牆

`OLLAMA_SCHED_SPREAD` 是什麼

如何解讀 `PROCESSOR` 欄位