本地跑 Claude Code 實戰｜Ollama + Gemma 4 + RTX 3070 使用心得與踩坑筆記
kyle

Claude Code 用著用著開始燒錢，雲端 API 每天的 token 用量加起來不便宜，偶爾也會遇到不想把程式碼送上雲端的情境，於是我們開始想：能不能把 Claude Code 接到本地的 Ollama，用免費的開源模型來跑？剛好家裡的桌機是 Ryzen 5600X 配 RTX 3070 8GB VRAM 一張，理論上 Gemma 4 系列的小模型是跑得起來的。這篇文章就來分享實戰心得——從安裝、第一次使用、中間踩到的坑，到最後發現本地小模型真正擅長的甜蜜點在哪裡。

為什麼想本地跑 Claude Code

Claude Code 是 Anthropic 官方推出的終端機 AI 程式助手，預設透過雲端 API 呼叫 Claude 模型，效果非常好。如果還不熟悉 Claude Code 是什麼，可以先看 Claude Code 入門使用教學｜終端機 AI 程式助手指南 。

但雲端 API 用久了會遇到幾個問題：

  • 費用：Sonnet / Opus 的 token 單價不便宜，每天寫程式累積下來月帳單很可觀。
  • 隱私：公司專案、客戶資料、實驗中的點子，都會上傳到第三方伺服器。
  • 網路依賴：飛機上、咖啡廳網路不穩、或是連線中斷時就完全沒辦法用。
  • 練習心態：純粹想看看消費級顯卡到底能不能扛住一個 agent 工作流。

剛好 Google 在 2026 年 4 月發佈了 Gemma 4 系列開源模型，其中專為邊緣裝置設計的 E2B 和 E4B 變體只需要幾 GB 的 VRAM，看起來很適合在自己的顯卡上跑。Gemma 4 的詳細介紹可以參考 Google Gemma 4｜多模態開源模型大更新 。

環境準備

硬體規格

這次測試的機器規格如下：

  • 作業系統：Windows 11 Pro
  • CPU：AMD Ryzen 5 5600X（6 核 12 緒）
  • GPU：NVIDIA RTX 3070 8GB VRAM
  • RAM：32GB DDR4-3200（8GB × 4）
  • 儲存：1TB M.2 SSD

RTX 3070 的 8GB VRAM 是這次測試的最大限制。Gemma 4 E4B 量化後大約佔 5-6GB，再加上 Claude Code 需要的 KV cache，VRAM 會吃得很滿，後面會看到這個限制怎麼影響可用的 context length。

安裝 Ollama 與 Gemma 4

Ollama 的安裝在 Ollama 入門教學｜本地大語言模型新手指南 已經寫過了，這邊就不重複。Windows 版直接從官網下載 installer 即可。

裝好之後，在 PowerShell 用 ollama pull 把 Gemma 4 的 E4B 變體抓下來：

# 抓 Gemma 4 E4B（約 5-6 GB）
ollama pull gemma4:e4b

# 確認模型清單
ollama list

有一個小細節要注意：Windows 版 Ollama 必須先把圖形化介面（GUI）開啟，PowerShell 的 ollama 指令才能跑。實際運算的引擎是包在 GUI 裡面的，純命令列無法獨立運作。GUI 開起來後可以縮到系統匣，不會影響使用。

安裝 Claude Code 並接到 Ollama

Claude Code 本身要先用官方方式安裝起來，安裝流程可以參考 Claude Code 入門使用教學 。裝好後，在 PowerShell 輸入下面這個指令，就可以用 Ollama 的 Gemma 4 取代雲端 Claude 模型來啟動 Claude Code：

# 用本地 Gemma 4 跑 Claude Code
ollama launch claude --model gemma4

這個指令會自動把 Claude Code 的 API endpoint 指到本機的 Ollama 服務，然後用指定的模型作為後端。第一次跑的時候模型要載入到 VRAM，會等幾秒鐘，之後就會進到熟悉的 Claude Code 對話介面。

第一次使用心得

/init 成功建立 CLAUDE.md

進到 Claude Code 之後，第一件事是測試最基本的 /init 指令——它會掃描專案結構並產生一個 CLAUDE.md，是 Claude Code 認識專案的起點。我們開了一個 React 專案測試，結果很意外：Gemma 4 E4B 居然能順利跑完整個 /init 流程，產生的 CLAUDE.md 雖然細節不如 Sonnet 精準，但結構和重點都抓得到。第一個任務算是過關。

Context length 至少要 32K

Ollama 預設的 context length 是 4K，但這對 Claude Code 來說完全不夠用——Claude Code 的系統提示加上工具定義就會吃掉好幾千 tokens，再加上對話歷史，4K 馬上就爆了。實測下來，Claude Code 至少要 32K 才能勉強運作。我們把它開到 64K，這時候 RTX 3070 的 8GB VRAM 已經接近極限了。

調整方式：開啟 Ollama GUI，點開 Settings 頁面就能設定 context length。設定好之後重新啟動模型才會生效。

中文輸入但只回英文

用 Gemma 4 E4B 跑 Claude Code 時遇到一個有趣現象：輸入繁體中文它聽得懂，但回應永遠是英文。即使在 prompt 裡明確要求「請用繁體中文回覆」也沒用，最多回幾句中文後又切回英文。這應該是 Gemma 4 系列在訓練時，繁體中文資料量比較少導致的偏好，跟 Llama 早期版本的狀況很像。對只想看程式碼輸出的開發者來說影響不大，但如果習慣用中文跟 AI 討論需求，會覺得不太順手。但之後我再調整看看或許可以改善。

踩坑筆記

/statusline 怎麼寫都不能跑

/statusline 是 Claude Code 用來自訂終端機底部狀態列的指令，可以顯示專案名稱、git 分支、目前模型等資訊。我們請 Gemma 4 幫忙寫一個，它一開始給了一個 bash 版本——但這是 Windows，bash 版根本跑不起來。請它改成 PowerShell 版，結果改出來的 PowerShell 腳本還是有問題，跑不出預期的結果。試了幾輪都搞不定，最後放棄這個功能。這代表 Gemma 4 E4B 對「寫一個能在特定環境下實際執行的腳本」這種任務還是有侷限，雖然語法能寫出來，但邊角案例和環境差異處理得不夠細。不曉得是不是因為 PowerShell 的程式比較少，Gemma 4 缺少學習樣本或是降低參數與精度後被捨棄了呢？

settings.json 被整個覆蓋

這是這次測試最痛的一次踩坑。請 Gemma 4 E4B 幫忙修改 ~/.claude/settings.json 加上一個環境變數，結果它直接把整個檔案重寫，把原本累積很久的設定全部蓋掉——包含 hooks、權限、自訂 alias 等等。

雲端的 Claude Sonnet / Opus 在做這種編輯時，會先讀檔、找到要修改的位置、做最小化的編輯。但 Gemma 4 E4B 在這個 agent 工作流上行為比較粗糙，會直接「我覺得這個檔案應該長這樣」然後寫一個全新的。如果要用本地小模型跑 Claude Code，務必先把 ~/.claude/settings.json 備份起來，或是先用 git 把整個 ~/.claude 目錄納入版本控制，免得辛苦累積的設定一夕歸零。

PowerShell 環境變數小撇步

Windows 用戶用 Claude Code 推薦在 ~/.claude/settings.json 加上這個設定，可以讓 Claude Code 更穩定地呼叫 PowerShell：

{
  "env": {
    "CLAUDE_CODE_USE_POWERSHELL_TOOL": "1"
  }
}

這個環境變數會讓 Claude Code 在執行 shell 指令時優先使用 PowerShell 而不是 cmd，避開很多 Windows 路徑、編碼相關的怪問題。不論本地模型或雲端模型都建議加上。

本地小模型可以拿來做什麼

講完踩坑，誠實的結論是：用 RTX 3070 + Gemma 4 E4B 跑完整的 Claude Code agent 工作流是「跑得起來但不順手」。生成速度大概 30 t/s，反應延遲偏高，加上偶爾會把檔案搞壞，並不適合拿來當主力的開發 AI 助手。

但這不代表本地小模型沒價值。我們發現 Gemma 4 E4B 對於「輸入短、任務明確、輸出短」的工作非常擅長。下面是 6 個跑得又快又好的實測例子，這些任務 Gemma 4 E4B 大多在 1 秒內就完成：

  1. 情感分類：客服訊息、商品評論的正負面標記
  2. 結構化抽取：從 email、發票、履歷抽出 JSON 格式的欄位
  3. 關鍵字 / 標籤生成：部落格 SEO、文件索引、自動分類
  4. Shell / SQL 指令生成：寫 CLI 小工具、自動化腳本
  5. 短文翻譯：i18n 字串、UI 文案的批次翻譯
  6. Git commit 訊息、PR 標題自動生成

舉兩個讓我們有點驚艷的實測：

Commit 訊息生成——餵給 Gemma 4 E4B 一段功能描述「added a retry mechanism with exponential backoff to the API client to handle transient network failures」，請它寫一句 conventional commit。它在 0.76 秒內回應：

feat(api): add retry mechanism with exponential backoff for network failures

格式正確、scope 也標對了，跟雲端模型寫出來的沒有差別。

結構化資料抽取——餵它一封文字 email，請它抽出寄件者、日期、主旨、需要的動作，並輸出為 JSON。它在 2.3 秒內產生：

{
  "sender": "[email protected]",
  "date": "2026-04-10",
  "subject": "Project deadline reminder",
  "action_required": "Please submit your reports by Friday."
}

JSON 格式乾淨、欄位齊全，可以直接餵給後續的程式處理。

換句話說，本地小模型的甜蜜點不是當「萬能 AI 助手」，而是當「自動化工作流裡的單點工具」。把它當成一個免費、離線、可程式呼叫的文字處理引擎，接到 cron job、Git hook、Slack bot、自訂 CLI 工具裡，這才是 RTX 3070 等級的硬體真正能發揮的地方。

想知道更多？

這篇主要分享的是「使用心得」與「本地模型適合什麼場景」的高層次結論。如果開發者們對下面這些問題感興趣：

  • RTX 3070 跑 Gemma 4 的 TPS 到底多少？Context length 拉高會變慢嗎？
  • Gemma 4 的 E2B 和 E4B 哪個比較強？參數小的反而比較快嗎？
  • 為什麼 E2B 在 Ollama 上跑起來反而比 E4B 慢 10 倍？
  • thinking、temperature、top_k、top_p 這些參數到底在控制什麼？

這些問題我們都跑了完整的 benchmark，並追到 Ollama renderer 的層級找答案，整理在下一篇 Gemma 4 E2B vs E4B 完整實測｜Thinking 模式的祕密與本地小模型最佳實踐 ，有興趣的可以接著看。

總結

用 Ollama + Gemma 4 + Claude Code 在 RTX 3070 上跑了一輪之後，我們的結論是：

  • 當主力 AI 開發助手：不推薦。速度、品質、agent 行為都跟雲端模型差一截，會被 settings.json 被覆蓋這類意外傷害。
  • 學習與好玩：很值得試一次。能親手把開源模型接到一個真實的 agent 工具，對理解 AI 工作流很有幫助。
  • 當自動化工作流的後端：非常推薦。免費、離線、可程式呼叫，適合 commit 訊息、結構化抽取、分類這類「明確任務」。

如果你只有一張消費級顯卡又想試試本地 AI，建議的順序是：先把 Ollama 玩熟、了解 Gemma 4 的能力邊界、再決定要不要把它接到 Claude Code。直接跳到最後一步可能會失望，但繞一圈走完之後，會對「本地模型適合什麼、不適合什麼」有非常清楚的判斷。

Post Views: 40
Tags:

發佈留言