對寫 code 場景來說，LM Studio 不一定是日常主力（Ollama 通常更穩、生態更成熟），但它在「探索新模型」「視覺化看推論參數」「拿來教其他人本地 LLM」這幾個情境上明顯佔優勢。本章說明它的安裝、模型瀏覽器、server 模式啟用，以及跟 Ollama 並存的配置。

本章目標

讀完本章後，你應該能：

1. 安裝 LM Studio 並下載第一個模型。
2. 在 GUI 跟模型對話、調整參數。
3. 啟用 LM Studio 的 OpenAI 相容 server 模式。
4. 判斷你的工作流適不適合用 LM Studio 當主力。
5. 讓 LM Studio 與 Ollama 並存。

安裝

LM Studio 是商業軟體（個人使用免費），不在 Homebrew core repo 裡。直接從官網下載：

1. 開 lmstudio.ai
2. 下載 macOS（Apple Silicon）版本
3. 把 LM Studio.app 拖到 Applications
4. 第一次開啟會被 macOS 安全提示擋，到「系統設定 > 隱私權與安全性」放行

裝完開啟 app，會看到三個主要分頁：

• Discover：搜尋 Hugging Face model hub、下載模型
• My Models：管理已下載模型
• Chat / Developer：跟模型對話、啟用 server

下載第一個模型

Discover 分頁把 Hugging Face 模型搜尋、量化等級挑選、記憶體適配判讀集中在同一個面板。在 Discover 分頁搜尋模型名（例如 gemma-4）、會列出 Hugging Face 上的對應 repo：

選一個合適量化等級點下載。Q4_K_M 在多數場景是甜蜜點；32GB Mac 跑 31B Q5_K_M 也順暢。下載中可以繼續操作其他功能。

陷阱：

1. Repo 來源要看。Hugging Face 上同一個模型有多個社群重新封裝的 repo。google/gemma-4-... 是官方 repo；bartowski/... 等是社群常見的高品質 quant 提供者。挑下載量高、最近更新的 repo 較安全。完整的供應鏈信任判讀（量化版本污染、權重完整性、registry 信任）見 6.0 模型供應鏈與信任邊界。
2. 不是所有檔案都要下載。一個 repo 可能有 5 ~ 10 個量化檔案，下載你選的那個就好。LM Studio UI 有時讓人誤以為要全選。
3. 下載完成後檢查路徑：預設下載到 ~/.cache/lm-studio/models/、跟 Ollama 的 ~/.ollama/models/ 分開。兩邊 model storage 各自獨立、想在兩個伺服器都用同一個模型要分別下載。

Chat 分頁與推論參數調整

下載完到 Chat 分頁、左上角 model selector 選剛下載的模型。LM Studio 會把模型載入記憶體（30 ~ 60 秒）、然後就能對話。

右側面板提供推論參數調整：

對寫 code 場景的關鍵調整是 Temperature 降到 0.2 ~ 0.4，可以讓回答更穩定、減少幻覺。預設 0.7 是給創意寫作的設定。

Speculative decoding 設定面板

LM Studio 內建 speculative decoding 的 UI 設定。在 model 載入頁面下方有 Draft Model 設定區：

1. 選 target model（主力，例如 Gemma 4 31B）
2. 選 draft model（小模型，例如 Gemma 4 E4B）
3. 啟用 speculative decoding

Speculative decoding 真的加速需要 target 與 drafter 用同一個 tokenizer。Gemma 4 31B 配 Gemma 4 E4B 可以工作；Gemma 4 配 Llama 因 tokenizer 不同無法配對。LM Studio UI 會自動過濾相容的 draft 候選。

跟 Ollama 比，LM Studio 的優勢是「能看到並調整每個推論細節」。劣勢是「Gemma 4 的官方 MTP drafter 整合不是一鍵」，要自己挑 draft model。多數使用者用 Ollama 的 gemma4:31b-coding-mtp-bf16 一行解決就好；想自己組合 target + drafter 的進階使用者選 LM Studio。

啟用 Server 模式

Server 模式是 LM Studio 暴露 OpenAI 相容 API 的開關、預設關閉以避免 GUI 使用者誤開網路 port。讓 VS Code 等介面層接 LM Studio、要開 Local Server 模式：

1. 切到 Developer 分頁（左側 icon 像 </>）
2. 在頂部 model selector 選要 serve 的模型
3. 點 Start Server

預設聽 localhost:1234，提供 OpenAI 相容 API。

驗證：

1curl http://localhost:1234/v1/chat/completions \
2  -H "Content-Type: application/json" \
3  -d '{
4    "model": "gemma-4-31b-it",
5    "messages": [{"role": "user", "content": "Hello"}],
6    "stream": false
7  }'

回應的 JSON 應該包含 choices[0].message.content。

陷阱：

1. Server 跟 GUI 同生命週期。關閉 LM Studio 視窗或登出 macOS 會停止 server、IDE 連不上。修法：日常常駐改用 Ollama 的 launchd service 模式、LM Studio 只在桌面 session 啟動探索。
2. CORS 預設關。要從瀏覽器（如 Open WebUI 跑在不同 port）連，要去 Server 設定打開 CORS。
3. Model name 不是 tag。LM Studio 在 API 用的 model name 是檔名（如 gemma-4-31b-it），跟 Ollama 的 tag 格式不同。

與 Ollama 並存

LM Studio（port 1234）跟 Ollama（port 11434）port 不同，可以同時跑。在 Continue.dev 的 config.json 可以同時列：

 1{
 2  "models": [
 3    {
 4      "title": "Ollama: Gemma 4 31B MTP",
 5      "provider": "ollama",
 6      "model": "gemma4:31b-coding-mtp-bf16",
 7      "apiBase": "http://localhost:11434"
 8    },
 9    {
10      "title": "LM Studio: Qwen3-Coder 30B",
11      "provider": "openai",
12      "model": "qwen3-coder-30b",
13      "apiBase": "http://localhost:1234/v1",
14      "apiKey": "not-needed"
15    }
16  ]
17}

UI 上可以下拉切換 model。這個設計讓你「Ollama 跑主力、LM Studio 跑實驗模型」，兩條工作流不互相干擾。

LM Studio 適合誰

簡單的建議：LM Studio 適合當「副廚」、Ollama 適合當「主廚」。日常工作流用 Ollama 跑主力模型、需要探索新東西時開 LM Studio。

何時改回 Ollama 或 llama.cpp

LM Studio 的 GUI 定位在以下情境會變成阻礙、建議改用其他伺服器：

LM Studio 的最佳定位是「需要 GUI、桌面 session 內探索、有人在電腦前操作」的場景；任何「沒人看著 / 後台跑 / 跨機器 daemon」的需求、Ollama 通常更穩。

跟 Anthropic Claude API 的對比

如果你習慣 Claude 的工具用法（Anthropic Console、Claude Code）、LM Studio 的 GUI 體驗比較像 Anthropic Console：可以調 system prompt、看 token 計數、儲存對話。兩者都用 OpenAI 相容 API 形狀（Anthropic 自有 messages API 是另一條路徑、LM Studio 不接 Anthropic 格式）。差別是：

LM Studio 對寫 code 場景不是 Anthropic Console 的替代品，但作為「本地版 console」的體驗很完整。

下一章

下一章：1.2 llama.cpp 底層引擎，澄清網路上「llama.cpp 才是真本地」這類迷思。

對寫 code 場景的多數讀者來說、Ollama 已涵蓋 llama.cpp 的直接使用情境。Ollama 已經把它包好、使用者看到的是 model tag 跟 CLI；llama.cpp 自己的編譯、量化、參數設定都被抽象掉。本章的目的是澄清網路上「llama.cpp 才是真本地、Ollama 是壓榨版」這類迷思、並給少數需要直接用 llama.cpp 的場景一條路。

本章目標

讀完本章後，你應該能：

1. 理解 llama.cpp 在三層架構中的位置。
2. 知道 Ollama 與 llama.cpp 的關係（包含 / 上游）。
3. 判斷自己什麼情境下需要直接用 llama.cpp、什麼情境不用。
4. 看懂 GGUF 格式與量化標籤（Q4_K_M、Q5_K_S 等）。
5. 對「llama.cpp 整合 Gemma 4 MTP」這類消息建立判讀反射。

llama.cpp 在哪一層

llama.cpp 同時跨三層架構的兩層：

1. 推論引擎（library、可被其他程式呼叫的程式碼集合）：核心 C++ library、把 GGUF 權重載入、跑 forward pass（神經網路把輸入算到最後一層產出 token 的單次計算）。Ollama、LM Studio、許多其他工具的 backend 就是這個 library。
2. CLI 工具與 server（llama-cli、llama-server）：附帶的命令列工具與 HTTP server、可以直接拿來用、但需要自己編譯與配置。

當你看到「我用 Ollama 跑 Gemma 4」，實際發生的事是：

1你的指令
2  ↓
3Ollama CLI / server（包裝層、模型管理）
4  ↓
5llama.cpp library（推論核心）
6  ↓
7Metal API（Apple Silicon GPU）
8  ↓
9Apple Silicon 硬體

所以「Ollama vs llama.cpp」不是兩個競爭品，是「上層包裝」跟「底層引擎」的關係。

Ollama 跟 llama.cpp 的關係

Ollama 是 llama.cpp 的下游 wrapper、但 fork 跟 upstream 不是即時同步的關係。Ollama 在自己的 repo 裡放一份 vendored（複製進來、跟隨 Ollama 自家發版節奏管理）的 llama.cpp source、加上他們自己的 patches（補丁修改）；新功能進入 Ollama 的順序通常是：

1. llama.cpp 上游加新功能或修 bug
2. Ollama 把該 commit cherry-pick（從另一個 branch 單獨挑出一個 commit 套用）進來
3. Ollama 發新版

但反過來也成立：Ollama 有時搶先在 fork 裡加上游還沒接受的功能，例如 Gemma 4 MTP 在 2026/5/7 的 Ollama v0.23.1 一鍵支援，當時 llama.cpp 上游的 Gemma 4 MTP 整合還是 feature request。

這個關係的啟示：

1. 「llama.cpp vs Ollama 誰先進」視功能而定：具體功能要實際對照 release notes、「上游 / 下游」直覺只是初步參考、未必符合實際版本狀態。
2. 判讀支援度看 release notes：主版本號只是命名、實際功能列表要看具體版本的 changelog。
3. 直接用 llama.cpp 跟靠近上游是兩件事：Ollama 的 patches 有時是「上游還沒接受、但已經實用的功能」。

什麼情境真的需要直接用 llama.cpp

絕大多數寫 code 場景，Ollama 完全夠用。直接用 llama.cpp 的合理情境只有少數：

寫 code 場景的讀者通常不命中以上任何一條。

安裝（如果你真要試）

從原始碼編譯：

1git clone https://github.com/ggerganov/llama.cpp.git
2cd llama.cpp
3make

或用 Homebrew（社群維護，版本可能稍舊）：

1brew install llama.cpp

裝完後常用命令：

1# CLI 對話
2llama-cli -m /path/to/model.gguf -p "Hello"
3
4# HTTP server
5llama-server -m /path/to/model.gguf --port 8080 --host 127.0.0.1

llama-server 啟動後在 localhost:8080 提供 OpenAI 相容 API：

1curl http://localhost:8080/v1/chat/completions \
2  -H "Content-Type: application/json" \
3  -d '{
4    "model": "any-name",
5    "messages": [{"role": "user", "content": "Hi"}],
6    "stream": false
7  }'

model 欄位 llama-server 忽略，因為它一次只 serve 一個模型（不像 Ollama 可以動態切換）。

--host 127.0.0.1 是 loopback 預設、只接受本機連線。改 0.0.0.0 會把伺服器暴露到整個 LAN、跟 Ollama 改 OLLAMA_HOST 同類別的決定；完整的綁定模式跟誤開放後果見 6.1 推論伺服器的綁定與暴露範圍。

GGUF 格式與量化標籤

量化標籤是看 GGUF 檔名選模型的唯一線索、影響「記憶體 / 品質 / 速度」三軸的取捨。GGUF（GGML Unified Format）是 llama.cpp 定義的模型權重格式、把模型權重、tokenizer、metadata 打包成單一檔案。Ollama 內部存的就是 GGUF。

常見量化標籤：

_K_M、_K_S 的 K 指 K-quants（更先進的量化方法）、M / S 指 mixed-medium / mixed-small（不同層用不同量化）。實務上選 Q4_K_M 或 Q5_K_M 是寫 code 場景的甜蜜點；極端記憶體緊張才往 Q3 走、但通常會發現換較小模型的 Q5 比強塞大模型的 Q3 好。

為何 coding 任務對 Q3 以下特別敏感：寫 code 的回應要在 token 層保持高精度（變數名拼字、API 呼叫格式、括號配對都不容錯）、低 bit 量化會放大 token 分布失真、體感是 hallucination 上升、編造的 API 變多、長 context 累積誤差更明顯。一般對話容忍幾個錯字、code 一個錯字就跑不過。所以同 24GB Mac 上 Q5 14B 通常比 Q3 31B 適合寫 code、雖然參數量名義上少了一半。

Gemma 4 MTP 在 llama.cpp 的狀態（2026/5）

2026 年 5 月時：

• speculative decoding 框架：llama.cpp 已有 --draft-model 參數，整體 speculative decoding 功能 beta 階段。
• Gemma 4 官方 drafter 整合：feature request 開著（GitHub issue 上有討論），但尚未合進主分支。
• Ollama 對應狀態：v0.23.1 已一鍵支援 gemma4:31b-coding-mtp-bf16。

這是少見的「Ollama 領先 llama.cpp 上游」情境，原因是 Ollama 團隊接到 Google 的合作後直接做 patch、不等上游 review 流程。

實務啟示：

1. 想用 Gemma 4 MTP，直接用 Ollama 是最快路徑。
2. 想在 llama.cpp 直接跑 Gemma 4 MTP，要自己編譯帶上 Ollama 的 patches，或等上游合進來。
3. 看到「llama.cpp 已整合 Gemma 4 MTP」的網路文章，先去 llama.cpp 的 PR 列表 確認時間點。

llama.cpp 對 Apple Silicon 的優化

llama.cpp 對 Apple Silicon 有針對性優化：

1. Metal backend：在 macOS 上自動啟用 Metal（Apple 的 GPU 加速 API）、把 GPU 算力吃滿。
2. NEON / AMX：CPU 上用 ARM 向量指令集（NEON 是基本 SIMD、AMX 是 Apple 的矩陣加速器）加速 dequantization（把量化權重還原為計算精度的過程）。
3. Unified Memory aware：不像 NVIDIA GPU 要透過 PCIe（連接 GPU 與系統其他元件的高速匯流排）把資料搬進 VRAM、Apple Silicon 直接共用記憶體、省下這趟搬移。

這些優化都「免費」，不用使用者特別設定。但跟 MLX 比，llama.cpp 用的是 Metal 而不是 MLX framework；兩者效能各有勝負，差距通常 10 ~ 30%，不是「天差地遠」。

陷阱是看到「MLX 比 llama.cpp 快 N 倍」這類說法時，要追問：

1. 哪個模型？
2. 哪個量化？
3. 哪台 Mac？
4. llama.cpp 哪個版本？
5. 量測腳本是什麼？

多數網路 benchmark 沒有完整變數控制，差距常被誇大。對寫 code 場景的使用者，這個差距不值得糾結。

直接用 llama.cpp 跟 Ollama 並存

如果你真的想試 llama.cpp，可以跟 Ollama 並存（port 不同）：

Continue.dev 可以同時連兩個：

 1{
 2  "models": [
 3    {
 4      "title": "Ollama default",
 5      "provider": "ollama",
 6      "model": "gemma4:31b-coding-mtp-bf16",
 7      "apiBase": "http://localhost:11434"
 8    },
 9    {
10      "title": "llama.cpp experimental",
11      "provider": "openai",
12      "model": "any",
13      "apiBase": "http://localhost:8080/v1",
14      "apiKey": "not-needed"
15    }
16  ]
17}

給多數讀者的建議

直接用 llama.cpp 的學習成本比 Ollama 高、換來的好處對寫 code 場景的使用者通常不命中需求。在「自己量化模型 / 跑特殊冷門模型 / 需要 llama.cpp 最新 commit」三個條件都不命中時、Ollama 是低成本的預設選擇。

把 llama.cpp 當成「Ollama 背後的引擎、值得知道存在、但不必直接面對」。這個定位足夠應付網路上 95% 的相關討論。

何時不適用本章 / 該往哪去

本章的「以 Ollama 為主、llama.cpp 作為底層理解」這個敘事在以下情境會失準、需要另外的路徑：

下一章

下一章：1.3 VS Code + Continue.dev 整合，把伺服器接到日常編輯器，這才是寫 code 的真正起點。

Continue.dev 是 2026 年 5 月時與本地 LLM 整合最成熟的 VS Code 擴充套件。對應到雲端世界、它的定位類似 Cursor、差別是 Continue.dev 預設綁本地、可以同時連雲端；Cursor 預設綁雲端、本地是次要 surface、設定深度較高。

本章假設你已經裝好 Ollama 並至少跑過一次 ollama run。沒裝過請先回 1.0 Ollama。

本章目標

讀完本章後，你應該能：

1. 安裝 Continue.dev 擴充套件。
2. 在 ~/.continue/config.json 設定本地 Ollama 模型。
3. 用 Cmd+L 開對話、Cmd+I 做行內編輯。
4. 同時設定本地與雲端模型，按任務切換。
5. 排除 Continue 連不上 Ollama 的常見問題。

安裝擴充套件

Continue 擴充套件是 VS Code 內接到本地 LLM 的介面層入口、裝完才有 chat panel 與 inline edit 快捷鍵。在 VS Code 內按 Cmd+Shift+X 開啟 extensions panel、搜尋 Continue。第一個結果作者是 Continue Dev, Inc.（藍色 verified 標記）、點 Install。

裝完後左側 sidebar 多一個 Continue icon（一個小方塊）。第一次點開會跳出 onboarding、可以略過。

擴充套件本身是 open source、Continue Dev 帳號（公司提供的雲端服務 tier、跟 VS Code 的 Microsoft 帳號是兩件事）可選。「本地 LLM」場景使用 open source 部分就足夠、不必登入。

找到 config.json

Continue 的設定檔在 ~/.continue/config.json（macOS 是 /Users/<你的帳號>/.continue/config.json）。第一次開 Continue 後檔案會自動產生。

開檔案：

1code ~/.continue/config.json

或在 VS Code Continue panel 點右上角齒輪 icon，會直接開 config.json。

預設內容包含一些雲端範例 model（OpenAI、Anthropic、Mistral），我們要加自己的本地 model。

設定本地 Ollama 模型

把 models 陣列改成這樣：

 1{
 2  "models": [
 3    {
 4      "title": "Local: Gemma 4 31B MTP",
 5      "provider": "ollama",
 6      "model": "gemma4:31b-coding-mtp-bf16",
 7      "apiBase": "http://localhost:11434"
 8    }
 9  ],
10  "tabAutocompleteModel": {
11    "title": "Local autocomplete",
12    "provider": "ollama",
13    "model": "gemma4:e4b",
14    "apiBase": "http://localhost:11434"
15  },
16  "embeddingsProvider": {
17    "provider": "ollama",
18    "model": "nomic-embed-text",
19    "apiBase": "http://localhost:11434"
20  }
21}

每個欄位的意義：

Embedding model 的角色跟 chat / autocomplete model 不同：chat model 負責「跟你對話」、embedding model 負責「把文字壓成向量、用來做語意相似比對」、是 @codebase 功能的後端引擎。一般 chat model 沒法當 embedding model、要分開設定。

provider: ollama 是 Continue 內建的 Ollama 整合、比 provider: openai 多支援 model auto-pull 等功能。apiBase 不需要加 /v1、Continue 內部會處理。

存檔後 Continue 會自動 reload。

用 Cmd+L 開對話

Cmd+L 是把當前 buffer 餵進 chat 的快捷路徑、context 由選取範圍決定。回到 VS Code、按 Cmd+L（macOS）開啟 Continue chat panel。預設快捷鍵：

按 Cmd+L 後 panel 開啟，下方輸入區可以打 prompt。如果先選了一段 code，那段 code 會自動加進 context，你可以直接問「解釋這段 code」「改成 async」「加 type annotation」。

第一次提問時 Ollama 會載入 model（30 ~ 60 秒）、看到 Continue panel 有 spinner 是預期的。之後同一個 model 會留在記憶體（ollama keep_alive）、對話速度會快得多。

用 Cmd+I 做 inline edit

把游標放在你要修改的 code 上（或選取一段），按 Cmd+I 開 inline prompt。打字描述要做什麼，例如：

1加 type annotation

或：

1把這個 callback 改成 async/await

Enter 後 Continue 會把選取的 code + 你的指令送給本地模型，回傳的 diff 直接 inline 顯示。按 Cmd+; 接受、Cmd+' 拒絕。

陷阱是「選取範圍太大」。本地模型的 context window 雖然多半 8K 以上、但塞太多 code 會讓 TTFT 暴增。把選取範圍縮在一個 function 或一個 block 內、體感最好。

同時設定本地與雲端模型（按任務切換）

寫 code 場景的常見配置是「本地當預設、雲端當大難題備援」。修改 config.json：

 1{
 2  "models": [
 3    {
 4      "title": "Local: Gemma 4 31B MTP",
 5      "provider": "ollama",
 6      "model": "gemma4:31b-coding-mtp-bf16",
 7      "apiBase": "http://localhost:11434"
 8    },
 9    {
10      "title": "Cloud: Claude Sonnet 4.6",
11      "provider": "anthropic",
12      "model": "claude-sonnet-4-6",
13      "apiKey": "sk-ant-xxx"
14    },
15    {
16      "title": "Cloud: GPT-5",
17      "provider": "openai",
18      "model": "gpt-5",
19      "apiKey": "sk-xxx"
20    }
21  ]
22}

Continue chat panel 下方有 model selector，可以下拉切換。建議的切換時機：

詳細的判斷邏輯見 1.5 期望管理。安全 / 資料邊界面向：同個 IDE 同時接本地跟雲端 provider、prompt routing 設錯就會把該走本地的 NDA / 客戶 code 送到雲端、見 6.4 跨雲端 / 本地的資料邊界；codebase / 外部文件 / 剪貼簿成為 prompt injection 攻擊面的判讀見 6.3 IDE 場景的 prompt injection。

Codebase 索引與 @ 命令

@ 命令是把外部 context（整個專案 / 終端機輸出 / docs）注入到 chat prompt 的擴充機制、讓 LLM 在回應時能參考超出選取範圍的資料。Continue 支援把整個 codebase 索引成向量資料庫、讓你用 @codebase 參考整個專案。要啟用：

1. ~/.continue/config.json 設定 embeddingsProvider（前面已給範例）。
2. 開新 chat 後在 prompt 內打 @codebase，Continue 會自動把相關片段加進 context。
3. 第一次索引要 5 ~ 30 分鐘（看 repo 大小），之後增量更新。

@codebase 對中型專案（< 1000 檔案）效果不錯、本地模型有機會找到合適片段；對大型專案（10000+ 檔案）效果受限於 embedding model 品質。大型專案的退路：拆 workspace 縮小索引範圍、改用 @file 明確指定相關檔案、或換較強的 embedding model（例如雲端 OpenAI text-embedding-3-large）。

其他 @ 命令：

處理 Continue 連不上 Ollama

常見錯誤訊息與處理：

排錯時先用 curl 驗證 Ollama 本身正常：

1curl http://localhost:11434/api/tags

如果這個都回不出來、問題在 Ollama；如果這個正常但 Continue 連不上、問題在 Continue 設定。

排錯時的機制判讀：

• Failed to fetch：通常是 Ollama 沒跑、或 listen address 配置不一致（Continue config 跟 OLLAMA_HOST 對不上）。
• address already in use：另一個 Ollama instance 佔了 port、或 LM Studio 啟動時也搶 11434。先用 lsof -i :11434 找佔用方。
• 長時間 spinner：第一次載入大模型（30 ~ 60 秒）正常；如果每次新 chat 都這樣、可能 keep_alive 太短、模型每次被 unload。
• 對話內容亂碼 / 一直重複：小模型 capacity 不足以維持長 context 連貫性、或 repeat_penalty 預設值對該模型不合適。先換較大模型驗證是不是 model 本身的問題、再回頭調 temperature / repeat_penalty。
• Tab autocomplete 沒觸發：autocomplete 模型沒 pull 成功、或 model 名稱拼錯。ollama list 確認 model 真的在。

何時 Continue.dev 不適合

Continue.dev 是 VS Code 環境內最成熟的本地 LLM 介面層、但在以下情境會撞到設計邊界、需要找替代路徑：

Continue 的甜蜜點是「VS Code 內、單檔到中型專案、人在駕駛位的 chat + inline edit」。離這個甜蜜點越遠、收益越低、改用 Cline / aider / Cursor 等工具更直接。

Continue.dev 跟 Cursor 的取捨

如果你正考慮 Continue.dev vs Cursor，下表是寫 code 場景的取捨：

對「本地 LLM 為主」的使用者，Continue.dev 是更直接的選擇。Cursor 是「雲端 LLM 為主、偶爾本地」的選擇。

下一章

下一章：1.4 寫 code 場景的模型選型優先順序，回答「Ollama 跑起來該裝哪個 model」。

本章用「優先順序」而不是「對比表羅列」呈現，因為實際使用上 95% 的讀者只需要從前兩三個選一個；後面的選擇是給特定情境用的補充。先給結論再給推導，讀者可以快速看到結論、有空再回頭看為什麼。

本章目標

讀完本章後，你應該能：

1. 對自己的 Mac 規格，立刻知道該裝哪個模型。
2. 理解每個模型的能力強項與適用情境。
3. 看到新模型發表時，知道怎麼放進這個優先順序。
4. 看到「最強本地模型」這類排名時、用具體任務脈絡判讀。

優先順序總覽

對 32GB+ Mac 的讀者、建議的選型順序：

1. Gemma 4 31B MTP（首選）— 速度最快、coding 任務 MTP 加速 2 ~ 3 倍
2. Qwen3-Coder 30B（次選）— coding 專科、SWE-bench 表現最強的本地模型
3. Qwen3 14B（通用備案）— 較小較快、記憶體吃緊或要跑 long context 時切回來
4. gpt-oss 20B（OpenAI 開源）— 風格較像 GPT、想嘗試 OpenAI 風味時用

對 24GB Mac、跳過 31B、從 14B 起步。對 16GB Mac、可用模型限於 7B 或 Gemma 4 E4B、能力明顯下降、建議混用雲端。

1. Gemma 4 31B MTP：日常主力首選

Gemma 4 31B MTP 在「速度 × 能力 × 工具支援」三軸取得寫 code 場景的最佳平衡、是首選的原因。Gemma 4 31B 在 SWE-bench、HumanEval（OpenAI 提供的 164 題 Python 函式補完 benchmark）等 coding benchmark 上接近 Qwen3-Coder 30B、但因為 Google 釋出官方 MTP drafter、Ollama v0.23.1 一鍵整合、實際使用體感速度比 Qwen3-Coder 30B 快 2 ~ 3 倍（同硬體、同任務）。

Ollama tag：gemma4:31b-coding-mtp-bf16

記憶體需求：~18GB（含 drafter），32GB Mac 順暢、24GB Mac 吃緊。

能力範圍：

• 簡單 function 補完、改寫、加 type：強
• 寫 unit test、寫 docstring：強
• 解釋程式碼、提建議：中強
• 跨檔案重構：中等（仍輸雲端旗艦）
• 跟你討論架構設計：中等（會給合理方向但深度有限）
• 多步驟 agent 規劃：弱（雲端旗艦領先明顯）

為什麼選它而不是 Qwen3-Coder 30B：MTP 加速在寫 code 場景太明顯。Qwen3-Coder 在 benchmark 上略強，但實際工作流的「等模型回應」時間差會抵消那點 benchmark 差距。除非你的任務剛好命中 Qwen3-Coder 強過 Gemma 4 的部分（後面會說），Gemma 4 是更穩的預設。

2. Qwen3-Coder 30B：coding 專科

Qwen3-Coder 30B 是「benchmark 最強、速度次之」的本地 coding 模型、做為 benchmark 敏感工作流的次選。Qwen3-Coder 在 SWE-bench Verified（OpenAI 篩過的高品質子集、500 題）上達 77.2 分（2026 年 4 月 Alibaba 釋出時的公開數據）、是本地模型中 coding 表現最強的。對「複雜程式碼任務、不在乎速度差一倍」的使用者、這是更好的選擇。

Ollama tag：qwen3-coder:30b

記憶體需求：~18 ~ 20GB，32GB Mac 順暢。

Qwen3-Coder 30B 強項（JSON 結構穩定 / SQL Rust Go / 200+ 行 code / 演算法題）：

• 需要嚴格遵循 prompt 結構（例如要求輸出 JSON）— Qwen3-Coder 較穩定
• 需要寫 SQL、Rust、Go 等較少見語言 — 訓練資料較多
• 需要產出較長 code（200+ 行）— 比較不容易在中段失控
• 需要解 leetcode 風格演算法題（注重題目模式 + 標準解）— benchmark 強項

為什麼不是首選：MTP 加速目前限於 Gemma 4 官方 drafter、Qwen3-Coder 還沒有對應的官方 drafter（2026 年 5 月）。生字速度明顯慢於 Gemma 4 31B MTP、體感等候時間長。

3. Qwen3 14B：通用備案

Qwen3 14B 是 32GB Mac 想留記憶體餘裕（多 model 並存、長 KV cache、其他重 app）時的合理「降一級」選擇。能力較弱但記憶體佔用減半。

Ollama tag：qwen3:14b

記憶體需求：~10GB，24GB Mac 順暢、32GB Mac 留更多空間給 IDE 與系統。

能力範圍：

• 簡單 function 補完、加 type：尚可
• 解釋程式碼：尚可
• 寫 unit test：有時會錯
• 跨檔案重構：明顯弱於 31B 等級
• 複雜推理：明顯弱

主要使用情境：

1. 24GB Mac 的預設選擇。
2. 32GB Mac 但想留記憶體給其他重 app（如同時跑 Docker、跑大型測試）。
3. Tab autocomplete 的小模型（搭配主對話 31B 模型）。
4. 長 context 場景（KV cache 佔用較少）。

4. gpt-oss 20B：OpenAI 開源版

gpt-oss 20B 是 OpenAI 在 2025 年釋出的開源模型、風格較接近 GPT 系列、定位是「習慣 GPT 語感的使用者」的補充選項。如果你已經很習慣 GPT 的回答方式、這個模型的「語感」會比 Gemma 或 Qwen 親切。

Ollama tag：gpt-oss:20b

記憶體需求：~12GB，24GB Mac 起點可跑。

能力範圍：

• coding 表現中等，輸 Gemma 4 31B、Qwen3-Coder 30B。
• 一般對話、解釋、寫作風格較 polished。
• Tool use 支援較好（OpenAI 自家生態的優勢）。

主要使用情境：

1. 你已習慣 GPT 風格、不想換語感。
2. 寫 code + 一般對話混用（一般對話 gpt-oss 較自然）。
3. 24GB Mac 的進階選擇（比 Qwen3 14B 大、能力強，比 Gemma 4 31B 小、塞得進）。

16GB Mac 的選擇

16GB Mac 是現實上的最小可用配置。能跑的選擇：

實話：16GB Mac 跑這些模型只能做「簡單補完、解釋短段程式碼」、比較複雜的任務還是要切雲端。如果你想以本地 LLM 為主力寫 code、16GB 不在本指南推薦範圍；建議混用雲端、或評估升級到 24GB+ Mac。

48GB+ Mac 的選擇

48GB 以上記憶體可以跑更大模型，但邊際效益要考慮。可用選擇：

48GB Mac 的主要收益不是「跑得到更大模型」，而是「同時跑兩個 model」或「長 context 不卡」。例如同時跑 31B 主對話 + 4B autocomplete + 留空間給 IDE。

判斷新模型是否值得換的步驟

本地模型發布速度很快、每 2 ~ 3 個月會有新候選。判斷要不要換的步驟：

1. 看 SWE-bench Verified 分數：新模型在 SWE-bench Verified 上比現用模型高 5 分以上、值得試。
2. 看模型大小與記憶體預算：新模型大小落在 Mac 預算內、再進入下一步評估。
3. 看 speculative decoding 支援：有 drafter 的新模型在體感速度上常勝過稍強但沒加速的模型。
4. 用自己的 5 ~ 10 個日常任務當私人 benchmark：公開 benchmark 是參考、自己跑一遍才能拿到能用在自己場景的數字。
5. 看 Ollama / LM Studio 的 release notes：新模型要被伺服器支援、Ollama registry 已收錄的模型用起來最直接。

合理的更換節奏是一年 2 ~ 3 次主力模型。每換一次要重新適應它的語感、prompt 風格、體感速度、切換成本不算低；穩定下來再換、收益比追新發布每個都試大。

量化等級的選擇

對所有模型，量化等級的選擇大致一致：

量化等級的延伸判讀：

• Q8 / bf16 的回退條件：模型載入時 swap 到 SSD（生字速度掉一個量級）就要往下降一級。
• Q5_K_M 的回退條件：載入後 KV cache 跟 IDE 一起擠到記憶體上限、改 Q4_K_M。
• Q4_K_M 的回退條件：跑 coding 任務通過率明顯下降（基準 vs Q5 / Q8 下降 10% 以上）就換較小模型的 Q5、不再下降到 Q3。
• Q3 的觸發訊號：hallucination 上升、編造 API、長 context 累積誤差。寫 code 場景的具體判讀：Q3 31B 在 coding 任務上常輸給 Q5 14B、選 model size 時先看任務通過率、再用量化調記憶體、不是反過來。

適合寫 code 以外場景的模型

以下五類模型各自有專屬定位、跟「寫 code 主力」是不同的工作流；放在寫 code 主力位置會踩到能力錯位。每類各自有不同的判讀條件、用同一個欄位塞會遺失各自的失敗模式。

Llama 3.x base 等 base model

Base model 是純粹做下一個 token 預測訓練、沒做 instruction-tuning 的原始模型。直接拿來對話會跟著 prompt 隨機接龍、不會「回答你的問題」。適合下游 fine-tuning 跟研究；寫 code 場景改選同 family 的 instruction-tuned 版本（例如 llama3.3:70b-instruct 而不是 llama3.3:70b）。

純對話模型（Vicuna、ChatGLM 早期等）

純對話模型是 2023 年早期對話研究的成果、訓練資料偏自然對話、coding 表現遠輸後來的專科模型。早期教學示範或對話技術 baseline 仍會用到；現階段 coding 任務直接選 Qwen3-Coder 或 Gemma 4、不在這條路線上糾結。

多模態模型（Llava、Gemma 4 多模態版等）

多模態模型訓練資料含圖片 + 文字、能做圖片理解、UI 描述、OCR、圖文對應、適合「給 LLM 看截圖」這類工作流。寫 code 場景如果不需要看圖、改選同等級的純文字模型較省記憶體（多模態的 vision tower 佔額外 GB 級記憶體、純文字 coding 用不到）。

中文特化模型

中文特化模型在純中文寫作、客服場景表現好、但 coding 仍以英文 prompt + 英文 code comment 為主流。寫 code 用通用模型 + 英文 prompt 通常表現較穩、中文特化模型反而在英文程式碼相關任務上劣勢。除非工作流真的有大量中文 docstring / 註解需求、否則用通用模型。

「最新最強」測試模型

社群每週都有新模型釋出、號稱「跑分爆表」。日常主力建議等社群驗證 1 ~ 2 個月再採用、避免出「benchmark 強但 prompt 適應性差」「prompt 模板未進入主流工具預設」的事故。嘗鮮跟跑分是另一條工作流、用 LM Studio 探索性測試後再決定是否切主力。

模型不只 chat、還有 embedding

Continue.dev 的 codebase 索引功能要用 embedding model，這跟 chat model 是兩種不同的模型。常用 embedding：

1ollama pull nomic-embed-text

nomic-embed-text 約 274MB，記憶體佔用低，是 Continue.dev codebase 索引的好搭檔。其他選項：

Embedding 模型的選擇對 codebase 搜尋品質有影響，但邊際效益遠小於 chat model。先用預設 nomic-embed-text，有需求再換。

何時不適用本章優先順序

本章選型假設「Apple Silicon Mac + 寫 code 為主 + 個人使用」。以下情境的選型邏輯不同、需要另外的判讀路徑：

給讀者的最快決策路徑

決策表把記憶體預算跟用途摺成一張快查、依情境定位、不需要重讀整章：

決策表的兩個閱讀方式：先按「你的情境」找對應 model、再注意「觸發回退條件」決定何時切換到下一行。回退條件常被忽略、導致讀者在條件變化時還抱著原本的選擇。

下一章

下一章：1.5 期望管理，把本地 LLM 放在「免費的初階 pair programmer」這個正確位置，避免錯誤期待造成的挫折。

本章把期待校準到現實。讀完後你會清楚知道：哪些任務交本地、哪些交雲端、本地 LLM 一週後該怎麼判斷去留、什麼時候硬體升級才有意義。

本章目標

讀完本章後，你應該能：

1. 區分本地擅長領域、雲端擅長領域、模糊地帶三類任務。
2. 建立「本地 vs 雲端」的切換反射、減少每次糾結。
3. 用一週實測決定本地 LLM 是否留在工作流。
4. 識別本地 LLM 對你個人是「日常主力」「偶爾備援」還是「整體無用」。

本地擅長領域：明確強項

本地 LLM 在這些任務上的表現「足夠好、足夠快、值得每天用」：

本地擅長的共通結構：模式單純度高 + context 短 + 結果可驗證。遇到新任務時用這三條判讀：模式有沒有大量訓練資料覆蓋（補 type / 寫 docstring 屬高、設計新架構屬低）、需要的 context 是不是單檔內（單檔內屬短、跨檔屬長）、回應對不對自己看得出來（測試跑得過 / 註解讀得通 = 可驗證、深度 debug 的結論對錯難以即時驗證 = 不可驗證）。三條都打勾、本地通常勝任；任一缺項、考慮切雲端。

這份清單覆蓋了一般工程師每天 60 ~ 80% 的 LLM 使用情境。對主要靠雲端 API 訂閱（Claude Code、ChatGPT Plus、API tokens）的使用者、把這些餵給本地能讓雲端費用 / 配額用在真正困難的任務上。

雲端擅長領域：本地較弱、改用雲端更划算

下列任務在雲端旗艦上的表現明顯領先本地、預設交給雲端可以省下「先試本地、發現品質不夠、再切雲端」的時間成本：

雲端擅長的共通結構：context window 大 + reasoning depth 深 + 訓練資料密度高。雲端旗艦的 context 動輒 200K+ tokens、reasoning effort 模式能跑深推理 chain、訓練資料量級遠超開源模型。新任務若涉及「跨多檔閱讀 + 多步驟規劃 + 領域知識深度」、預設交雲端比較划算。

這份清單覆蓋了「LLM 真正取代人類思考的部分」、雲端旗艦的能力斷崖式領先。

模糊地帶：先試本地、視結果切換

下列任務本地能否做好視具體 case 而定。預設策略是「先試本地、看到觸發訊號再切雲端」：

觸發訊號的設計目標是「不依賴主觀判斷」、用具體跡象避免「總覺得本地不夠好就一律切雲端」的偏誤。建立自己的觸發訊號清單後、切換變成反射動作、不再每次糾結。模糊地帶切到雲端是正常工作流、是「先用便宜的工具、不夠再升級」的合理做法、跟本地「失敗」是兩件事。

切換的具體流程

Continue.dev 的 chat panel 下方（輸入框上方的下拉選單）有 model selector、可以直接切。建議的反射動作：

1. 預設用本地：開啟 Continue panel 時、先選本地 model。
2. 碰到雲端擅長任務直接切：上面雲端擅長表格的任務、第一次提問就選雲端。
3. 模糊地帶試一次本地：本地的回答堪用就用、看到觸發訊號就切雲端重提。
4. 記錄本地 hit rate：用一週、記錄哪些任務本地通過。第二週開始就有自己的判斷依據。

把本地當工具、把切換當常態。本地的價值在於「該用時隨手可用」、不是「裝了就要硬用」。

用一週實測：去留決策

裝完本地 LLM 後、建議用一週實測決定是否留下來。實測時做四件事：

1. 每次用 LLM 都先試本地、讓本地有機會證明自己。
2. 記錄 hit rate：簡單試算表、欄位放任務描述、本地通過、雲端通過。
3. 記錄體感速度：本地的等待感是「順暢」「可接受」「心煩」哪一級。
4. 記錄記憶體與發熱：Mac 是否變慢、風扇是否狂轉影響其他工作。

一週後做決策（hit rate 閾值是經驗值、可依任務分佈微調）：

這個實測比看 benchmark 重要得多、因為你的工作流跟 benchmark 設定的任務分佈未必一致。

本地 LLM 的角色定位

把本地 LLM 定位成「免費的初階 pair programmer」、期待會自然對齊現實：

1. 初階 pair programmer 是有用的：能寫測試、能解釋程式碼、能補 type、能改 callback。這些事一個 junior 同事每天做得很好。
2. 初階 pair programmer 有適用範圍：設計新架構、跨檔案重構、評估技術選型適合交給 senior（雲端旗艦）、跟交給 junior 同事的判斷一致。
3. 初階 pair programmer 隨時在線、不用付薪水：這是本地 LLM 比 junior 同事還好的地方。
4. 初階 pair programmer 跟 senior 互補：本地處理量、雲端處理難度、兩者組合讓 senior 把時間花在真正困難的部分。

陷阱是把本地當「便宜的 senior」。它的能力等級是 junior；明確這個定位後、你會自然把日常雜事丟給本地、把難題留給雲端。

跟雲端旗艦的協作姿勢

「混用」是有結構的協作姿勢、不是隨機切換。下表是寫 code 場景的典型分工：

這個結構讓「雲端旗艦的高品質」用在最值錢的地方（規劃 + 審稿）、「本地的免費 + 速度」用在批量產出。雲端 API 費用會大幅下降、思考品質仍然維持高水準。

硬體升級的判斷時機

裝完本地、用一週後、可能會想「升級 Mac 是否值得」。判斷依據（記憶體預算的完整推導見 0.5 Apple Silicon 記憶體預算）：

1. 記憶體預算：跑 14B 模型體感卡 → 升 24GB；跑 31B 卡 → 升 32GB；跑 70B 卡 → 升 64GB。
2. 生字速度：用最強量化與較小模型仍 < 10 tok/s 表示要換更輕的模型、不是升級硬體。
3. Hit rate 太低：問題在本地模型能力上限、不在硬體、升級沒幫助。
4. 長 context 場景：升級到 48GB+ 才能順暢處理 16K+ context。

陷阱是把「想換新 Mac」混在「正當理由」裡。先用一個月再決定；多數情況下省下的 API 費用攤平不了升級成本。

識別「本地對你個人沒用」的訊號

下列訊號表示本地 LLM 在你工作流上幫助有限、可以乾脆卸載：

1. 一週後雲端 API 費用沒降、因為切換習慣始終沒養成。
2. 本地回答太慢、實際使用頻率低、Ollama 卻在背景吃記憶體。
3. Mac 規格本來就吃緊、跑本地讓其他工作變慢。
4. 你的工作主要是規劃、設計、複雜推理、本地擅長領域跟你的主場交集小。

卸載屬於合理結論、不算失敗。本地 LLM 適合特定工作流；你的工作流跟它的擅長領域交集小、改用雲端是更划算的選擇。

完整卸載 Ollama 跟 Continue.dev 的指令：

1brew services stop ollama
2brew uninstall ollama
3rm -rf ~/.ollama
4
5# 卸載 Continue.dev 擴充套件
6# 在 VS Code Extensions panel 找到 Continue 點 Uninstall
7rm -rf ~/.continue

卸載後可以雲端 API 全用 Claude Code、Cursor 或其他雲端 IDE plugin、體驗一樣完整。

何時不適用本章建議

本章假設你的工作流可以「混用本地 + 雲端」。以下情境的混用前提不成立、本章建議要調整：

下一章

下一章：1.6 延伸方向、講日常路徑跑穩後可以玩的延伸（Open WebUI、aider、產圖）。

關鍵原則：先把寫 code 跑穩、再考慮延伸。同時推進三條延伸通常會讓每條都停在半生不熟階段、累積成果有限。本章建議的順序是先 Web UI、再 coding agent、最後產圖；如果你只想嘗試一個、依自己最常用的場景挑。

本章目標

讀完本章後，你應該能：

1. 列出三條延伸方向的代表工具與基本定位。
2. 知道每個方向跟寫 code 主路徑的關係。
3. 判斷自己現階段該不該往延伸方向走。
4. 對「產圖」這條歧路建立正確認知（不是換 model 就好）。

延伸方向一：ChatGPT 風格 Web UI（Open WebUI）

定位：在瀏覽器跑一個類 ChatGPT 介面，連到本地 LLM 或雲端 LLM。屬於三層架構的介面層，跟 Continue.dev 同層、解決不同情境（瀏覽器 vs IDE）。

典型使用情境：

1. 不在寫 code 但想跟 LLM 對話（解釋技術概念、寫文章草稿）。
2. 跟同事 / 家人分享 LLM 使用，他們不會用 VS Code。
3. 從手機 / iPad 連回家裡 Mac 跑的 Ollama。
4. 多輪深度對話、希望有歷史紀錄保存。

主流選擇：Open WebUI

Open WebUI 是 open source 的 ChatGPT-clone，連 Ollama 與 OpenAI 相容 API。安裝最快路徑是 Docker：

1docker run -d --name open-webui -p 3000:8080 \
2  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
3  -v open-webui:/app/backend/data \
4  --restart always \
5  ghcr.io/open-webui/open-webui:main

host.docker.internal 是 Docker Desktop 提供的 DNS 名稱、container 內透過它連到宿主機（macOS 本身）跑的 Ollama；Linux Docker 沒這個別名、要改用 --add-host=host.docker.internal:host-gateway 或直接填宿主 IP。啟動後開 http://localhost:3000、註冊本地帳號（資料只存本機 SQLite）、就有完整 ChatGPT 介面：

• 對話歷史保存（本地 SQLite）
• 多 model 切換、可同時對比兩個 model 回答
• 系統 prompt 自訂、prompt template 管理
• 上傳檔案分析（PDF、txt 等）
• 圖片支援（如果本地 model 是多模態）

陷阱：

1. 沒裝 Docker 的話要先學 Docker，是不小的前置學習。
2. Open WebUI 預設不需要驗證，跑在 0.0.0.0 會暴露在 LAN 上。要從外網用記得加 reverse proxy + auth。
3. 對話紀錄存在 Docker volume，刪 container 要小心保留 volume，否則歷史會消失。

何時做這個延伸：日常 Continue.dev + Ollama 跑穩、用了至少一週、確認本地 LLM 對你有用，再加 Open WebUI 擴展使用情境。

延伸方向二：Coding Agent（aider、Cline 等）

定位：比 Continue.dev 更主動的 LLM 寫 code 工具。Continue.dev 是「你提問、LLM 答」的對話模式；coding agent 是「你給目標、LLM 自己分多步驟改 code、跑測試、修錯誤」的代理模式。詳細的 agent loop 結構、失敗模式、人類審查協作見 4.4 Agent 架構原理。

主流選擇：

選擇三個工具的延伸判讀：

• aider：當主要工作流是「在 terminal + git 內完成」、想讓 LLM 把 diff 直接 commit 進 history、aider 的 CLI-first + git-aware 設計最對位。失敗模式：跨多檔修改超過 5 個檔時、aider 的 prompt 規劃容易斷裂；改回 Continue.dev 手動逐檔修可能更穩。
• Cline：當你已在 VS Code 內工作、想要 agent 能跑 shell command（執行測試、跑 build 看錯誤）並 loop 修錯時、Cline 比 aider 更貼近「IDE 內 agent」。失敗模式：本地模型在「規劃 → 執行 shell → 解讀錯誤 → 改 code」這個 loop 上接受度不穩、常需要人工接管。
• Cursor Agent：當你已是 Cursor 訂閱戶、agent 預設綁雲端旗艦（成功率最高、但 prompt / code 會送到 Cursor 雲端）。NDA / 合規場景不適用、本地 LLM 接入也是次要 surface。

為什麼是 advanced：coding agent 需要本地模型能「跟著規劃跑多步驟、用 tools、不偏離目標」。這部分是本地 LLM 的弱項（見 1.5 期望管理）；現階段本地模型跑 coding agent 的成功率明顯低於雲端旗艦。

用 aider 跑本地 LLM 的最小範例：

1# 裝 aider
2pip install aider-chat
3
4# 在 git repo 內啟動，用本地 Ollama
5aider --model ollama/gemma4:31b-coding-mtp-bf16 \
6  --ollama-base-url http://localhost:11434

aider 會把當前 repo 的相關檔案打進 prompt、把 LLM 生成的 diff apply 到本機、自動 commit。簡單任務（單檔重構、加 test）成功率還行；複雜任務（跨檔案、需要規劃）失敗率高。

陷阱：

1. 本地 LLM 跑 aider 比跑 Continue.dev 慢得多、因為每輪 agent loop 都要重新處理長 context。
2. coding agent 對 long context 敏感、本地 TTFT 痛點被放大。Agent loop 每輪都會 mutate prompt（前一輪結果加入下一輪的 context）、KV cache 命中率低、每輪都要重新做完整 prefill。
3. 失敗時 agent 可能 commit 不可用的 code、要記得 git diff 審過再 push。

何時做這個延伸：本地模型在 Continue.dev 對話模式下表現穩定、且你想看看「multi-step 自動化」能幫到什麼程度。對多數讀者、這條延伸在 2026 年 5 月時是「值得試一週、但不一定留下」。

何時該停：以下訊號出現時、agent 路線在你的工作流暫時不成立、回到 Continue.dev 對話模式：

• 連續 5 個 multi-step 任務都需要人工接管 / 中途介入修錯
• TTFT 持續 > 30 秒、agent loop 的「等待 → 接管」節奏比手寫快不了多少
• agent commit 進 git history 的 diff 通過率 < 50%、審查與 revert 的成本超過自己寫
• 簡單任務（單檔重構、加 test）本地 agent 也常失敗、表示模型 capacity 對 agent 規劃不足

延伸方向三：產圖（Stable Diffusion、Flux 等）

產圖是另一個專業領域、工具鏈跟概念體系另起一套、跟 LLM 寫 code 沒有共用的伺服器層或 model layer。產圖用的是 Diffusion 架構、跟寫 code 用的 Transformer 架構是兩個獨立的神經網路類型。

四個維度上產圖跟寫 code 的工作流互不相通：

1. 工具鏈各自獨立：Ollama 服務 Transformer LLM、Draw Things / ComfyUI 服務 Diffusion 模型、兩條路線的伺服器與生態互不通用。
2. prompt 風格不同：寫 code 是 instruction 形式、產圖是 descriptive prompt + negative prompt + sampler 參數。
3. 學習成本各自獨立：產圖有自己的 LoRA、ControlNet、IP-Adapter、refiner 等概念體系、學起來等於進入新領域。
4. 硬體最適規格不同：寫 code 看記憶體預算（跑大模型）、產圖看 GPU 算力與 VRAM 頻寬。

本章只給入口資訊、不展開教學。

主流工具：

主流模型：

Apple Silicon Mac 跑產圖的現實：

1. 24GB+ Mac 可以順暢跑 SDXL / Flux。記憶體需求其實比 LLM 低（一張圖 ~ 8GB），但對 GPU 算力敏感。
2. M4 Max 跑 Flux 生 1024x1024 圖約 15 ~ 30 秒一張，可接受。
3. Draw Things 在 Mac App Store 可下載，是最簡單的入門路徑。

本指南的立場：先把寫 code 跑穩、再考慮產圖。產圖屬於獨立的學習主題、另外找專門教材會學得更有效率。

給讀者的延伸順序

如果你想嘗試延伸方向，建議的順序：

1. 先用一個月本地 LLM 寫 code。確認 Ollama + Continue.dev 對你有用、習慣了切換。
2. 第一個延伸：Open WebUI。加裝最低成本（只多裝 Docker），擴展使用情境到非 VS Code 場景。
3. 第二個延伸：aider 或 Cline。試 coding agent，評估本地模型能 handle 多複雜的多步驟任務。
4. 第三個延伸：產圖。完全獨立的學習投入，跟前面工具鏈無關。

依序進階。先讓基底穩、再疊加延伸、學習曲線最平滑。

不在本章範圍內的延伸

下列延伸方向值得知道存在，但不在本指南內展開：

需要這些方向時請另尋專門資源；硬塞進來會稀釋本指南「Mac 本地寫 code」這條最短路徑。

下一步

實作範例（含 ComfyUI / Whisper / Piper TTS / RAG / MCP）見 Hands-on 章節。

讀到這裡、本指南的核心內容就完了。下一步是回到 模組零 或 模組一 任一章節做深度閱讀、或實際打開終端機跑第一個 ollama run、把概念變成肌肉記憶。

具體錯誤訊息對照表（「address already in use 要這樣修」「model not found 要那樣修」）不在本章——這些隨工具版本變、查 release notes 跟 GitHub issue 更快。本章寫的是「換工具之後仍成立」的排錯思維。

本章目標

讀完本章後、你應該能：

1. 看到症狀時、先定位是介面 / 伺服器 / 模型哪一層的問題。
2. 知道在每一層該看什麼 log。
3. 用「最小可重現」策略快速縮減問題範圍。
4. 識別「跨層級的誤判」常見模式、把 server 層問題正確歸位、避開瞎調 model 的繞路。

故障定位的核心原則：先確認哪一層壞

模組零 三層架構 的視角延伸到排錯：故障可能落在介面層（Continue.dev / Cursor 等 IDE 整合）、伺服器層（Ollama / LM Studio / llama.cpp）、或模型層（權重檔本身的能力 / 量化選擇）。在不知道哪一層壞之前、任何修法都是亂槍打鳥——重啟 Continue.dev 解不了模型量化太激進的問題、重 pull 模型解不了 IDE 設定錯的問題。

先定位再修補的 ROI 高於直接修補、因為沒有定位的修法常常掃過正確答案還不知道是哪個動作生效。定位用的工具不複雜：

• 直接 curl 伺服器 API：繞過介面層、直接驗證伺服器是否回應正常。
• ollama ps / 等價指令：看伺服器層 model 狀態、確認 model 真的載入。
• 換 model 試試：同樣 prompt、不同 model 表現一致就是介面 / 伺服器層、不一致就是 model 層。
• 換 prompt 試試：簡單 prompt OK、複雜 prompt 崩、可能是 context 長度或 model 容量問題。

這四個動作能 cover 90% 的定位需求。學會這個反射、排錯時間大幅縮短。

症狀到層級的對應反射

不同症狀對應到不同最有可能的故障層、建立對應反射能省下大量試錯時間。下表是寫 code 場景常見症狀的對應：

對應的具體驗證指令範例：

• 回答亂碼 / 重複：ollama list 確認當前 model tag、改跑 ollama run <較高量化版本>（例如 Q4 → Q5）；同 prompt 換 model 確認是不是 model 本身能力問題、不是伺服器。
• TTFT 異常變長：ollama ps 看 model 是否被 unload 又重載（keep_alive 太短）；檢查 prompt 字數是否暴增（10K+ tokens 進入 prefill 痛點區）。
• Ollama 自己 crash：launchd service 模式看 /opt/homebrew/var/log/ollama.log、前景模式看啟動 terminal 的 stderr。

這張表的核心訊號：

• 「沒回應」「connection 系」→ 通常 server 層。
• 「內容怪」「答非所問」「重複」→ 通常 model 層。
• 「設定怪」「快捷鍵不對」→ 通常介面層。
• 「整機卡」→ 系統資源、不一定哪層的「bug」、可能是規格不夠。

把這個 mapping 內化、看症狀立刻有第一手猜測、不用每次從零思考。

Log 在三層的角色差異

每一層的 log 看的東西不同、用法不同：

介面層 log

• 位置：IDE plugin 的 console（VS Code Developer Tools、JetBrains 的 plugin log）。
• 看什麼：請求是否發出、發到哪個 endpoint、回應 status code、parse error。
• 常見訊號：請求根本沒發 → 介面層配置錯；請求發了但伺服器拒 → 伺服器層；請求成功但 parse 失敗 → 介面層或伺服器層回應格式不對。

伺服器層 log

• 位置：Ollama 在 ~/.ollama/logs/server.log 或類似位置、LM Studio 在 console 輸出、llama.cpp 在啟動 terminal。
• 看什麼：模型載入過程、推論進度、error trace、記憶體狀態。
• 常見訊號：載入 model 卡住 / 失敗 → model file 損壞或記憶體不足；推論時 OOM → 量化太激進或 context 太長；連線錯誤 → port 配置或 host binding。

模型層的觀察訊號

模型層通常沒有獨立的 log——權重檔本身不會 log、行為要透過伺服器層觀察。判讀模型問題的訊號通常是：

• 「載入成功、推論時崩」→ 量化等級或記憶體配對問題。
• 「載入成功、推論結果差」→ 模型能力或量化品質問題。
• 「不同 prompt 表現不一致」→ 可能是 model 對特定 pattern 弱、不是 bug。

模型層問題多半不是「壞了」、是「能力上限」——換更大模型或調量化是主要解法、不是「修 bug」。

log level 預設夠用、針對性提升

實務上 default log level 提供的訊息已涵蓋多數排錯需要；全部開 verbose 反而把 noise 蓋過 signal、要找的關鍵錯誤被淹沒。有問題時針對該層提升 log level（其他層保持 default）、定位完再降回來。

最小可重現的縮減策略

症狀複雜時、把問題縮到最小、再逐步加回來。這個方法在所有軟體 debug 都通用、套用到 LLM 場景的具體流程：

1. 直接 curl 伺服器、用最簡 prompt 復現：

   • 繞過介面層、確認伺服器本身行為。
   • prompt 用 "Hello" 這種最短的、排除 prompt 複雜度因素。
   • 如果這步就崩 → 伺服器 / 模型層問題、可以排除介面層。

2. 換不同 model 試：

   • 同樣 prompt、換 gemma4:e4b 或 llama3.2:1b。
   • 不同 model 都正常 → 原 model 問題。
   • 不同 model 也崩 → 伺服器層問題。

3. 換不同伺服器試：

   • Ollama 接不上、用 LM Studio 同模型試。
   • 兩個都崩 → 模型或系統層問題。
   • 一個好一個壞 → 該伺服器特有問題。

4. 改變一個變數一次：

   • 每次只改一個變數（設定 / model / IDE 重啟三選一）、確保行為變化能對應到具體動作。
   • 每次只改一項、觀察行為變化。

5. 記錄每一步：

   • 排錯 30 分鐘還沒解時、開始會忘記試過什麼。
   • 簡單 notebook 記錄「改了什麼、行為怎麼變」、避免轉圈。

這個方法看起來慢、實際上比「亂試一通」快很多。亂試的代價是「以為改了 A 沒效、其實改 A 跟改 B 互相抵銷、不知道」。最小可重現是 disciplined approach、值得花時間建立習慣。

跨層級的常見誤判

排錯時常踩的陷阱是「把某層的問題誤判成另一層」、修錯方向白費力氣。常見誤判模式：

把伺服器問題誤當模型問題

例：Ollama 因為 port 被佔啟動失敗、IDE 看到 connection refused、誤以為「model 載不起來、需要換 model」。實際上換 model 也救不了、要看 server log 才知道是 port 問題。

判讀：connection 系問題 → server 層、不是 model 層。

把模型問題誤當伺服器問題

例：用 Q3 量化跑 7B 模型、輸出全是亂碼、誤以為「Ollama bug」、開 issue 報。實際上是量化太激進、模型本身輸出崩、換 Q4 就好。

判讀：「server 看起來正常、輸出怪」→ 通常 model 層、改量化或換 model。

把介面問題誤當伺服器問題

例：Continue.dev 的 config.json 寫錯 apiBase、IDE 顯示 connection error、誤以為「Ollama 掛了」。實際上 Ollama 正常、curl 過得去、IDE 配置錯。

判讀：curl 過得去、IDE 過不去 → 介面層配置問題。

把系統資源問題誤當軟體 bug

例：32GB Mac 跑 31B + 同時開大量 app、Mac 整體變慢、誤以為「Ollama 越來越慢」。實際上是記憶體 swap、Ollama 沒問題。

判讀：Activity Monitor 看 Memory Pressure 變紅 / swap 大量、是系統資源、不是軟體 bug。

把 prompt 問題誤當模型問題

例：給 model 超長 context（30K token）、TTFT 30 秒、誤以為「model 變慢了」。實際上是 prefill 階段需要時間、跟 model 沒變慢無關。

判讀：短 prompt 正常、長 prompt 慢 → prefill 問題、可預期、不是 bug。

每種誤判的根因都是「症狀對應到錯的層級」。內化「症狀 → 層級」對應反射、能避開多數誤判。

排錯工具箱

四個基本工具能 cover 90% 的排錯場景：

curl

• 角色：直接打伺服器 API、繞過介面層。
• 用法：curl http://localhost:11434/api/version 看伺服器是否回應、curl http://localhost:11434/v1/chat/completions 帶最簡 prompt 試完整流程（11434 是 Ollama 預設 port、見 1.0 Ollama）。
• 價值：排除介面層、確認伺服器層行為。

ollama ps / 等價指令

• 角色：看伺服器層當前 model 狀態。
• 用法：ollama ps 列出載入記憶體的 model、看 size、idle timer。
• 價值：確認「我以為載入了」跟「真的載入了」是否一致；看記憶體佔用是否合理。

Activity Monitor / system monitor

• 角色：看系統資源狀態。
• 用法：Memory Pressure 是否變紅、CPU / GPU 使用率、swap 量、過熱降頻。
• 價值：區分「軟體 bug」跟「規格不夠」。多數本地 LLM 慢的問題是規格、不是 bug。

IDE 開發者工具

• 角色：看介面層請求 / 回應。
• 用法：VS Code 的 Help → Toggle Developer Tools、看 Network tab、看 Console。
• 價值：確認介面層真的把請求發出去、看 server 回什麼。

這四個工具學會用、寫 code 場景 90% 的排錯都能處理。剩 10% 的 deep issue（如 driver 問題、模型權重檔損壞、framework 內部 bug）需要更專業的工具、但這 10% 對寫 code 使用者來說、通常該求助社群或回報 maintainer、不是自己 debug。

排錯流程的決策樹

把上面的內容整合成一個流程：

 1症狀出現
 2  ↓
 3curl 伺服器（伺服器層活著嗎）
 4  ├─ curl 失敗 → 看 server log（伺服器層問題）
 5  │   ├─ port 衝突 → 改 port 或 kill 舊 instance
 6  │   ├─ model 載入失敗 → 看 file / 記憶體
 7  │   └─ crash → bug report、看版本是否最新
 8  └─ curl 成功 → 介面層或 model 層問題
 9      ↓
10      換最簡 prompt 試（model 在簡單 prompt 上正常嗎）
11      ├─ 簡單 prompt 也崩 → model 層問題
12      │   ├─ 換 model 試 → 不同 model 都崩 → 系統或伺服器
13      │   └─ 同 model 換量化等級 → 量化太激進
14      └─ 簡單 prompt OK、複雜 prompt 崩
15          ↓
16          看 prompt 長度跟 context 限制
17          ├─ context 超出 → 縮短 prompt 或換 long-context model
18          └─ context 在範圍內 → model 能力上限、考慮換大 model
19              ↓
20              （如果伺服器、prompt、model 都檢查過還是壞）
21              介面層配置問題
22              ├─ 看 IDE plugin developer console
23              ├─ 比對 config.json 跟最簡 working example
24              └─ reset 設定後重試

這棵樹不是「按順序跑完」、是「定位後對應到具體分支」。學會用症狀直接 jump 到對應分支、不必每次從根跑起。

何時不適用本章方法論

本章「三層架構定位」假設「單機、單 user、單一伺服器實例、人在駕駛位」的個人開發場景。以下情境的方法論需要擴充：

本章方法論的甜蜜點是「個人 Mac、一個 IDE、一個 Ollama instance」的場景。離開這個甜蜜點、要把「三層」擴充成更多層（user / network / cluster）、或改用 production-grade 觀察工具。

何時過時 / 何時不過時

不會過時的部分：

• 三層架構視角排錯（介面 / 伺服器 / 模型）。
• 「先定位、再修補」的反射。
• 最小可重現的縮減策略。
• 五類跨層級誤判模式的識別。
• 四個基本工具的概念（curl / process status / system monitor / dev tools）。

會變的部分：

• 具體錯誤訊息文字（隨 Ollama / LM Studio / Continue.dev 版本變）。
• log 檔位置（隨工具更新可能調整）。
• 特定指令名稱（如 ollama ps 將來可能改名）。
• 特定工具的開發者面板路徑。

換工具或工具升級之後、本章的方法仍適用、只需要重新對應到「新工具的對應指令在哪」。看到新錯誤訊息時、回到三層架構定位、用最小可重現縮減——這比 google 錯誤訊息字面快得多、也比「重啟一次再試」可靠得多。

下一章

下一章：模組二 LLM 的數學基礎、或回到 模組一首頁 看其他章節。

對「在 VS Code 接本地 LLM 寫 code」這條最短路徑、Ollama 多半是唯一需要的伺服器層。本章先給 5 分鐘可跑通的最短路徑、再展開日常使用所需的模型管理跟 API 細節、最後才進階主題（背景常駐、MTP 加速、安全暴露、版本升級）。已經把 Ollama 跑起來的讀者可以直接跳到日常使用或排錯。

本章目標

讀完本章後、你應該能：

1. 裝好 Ollama 並驗證它正在跑。
2. 用 CLI 拉一個模型並開始對話。
3. 用 curl 驗證 OpenAI 相容 API 在 11434 正常回應。
4. 看懂 model tag 命名規則、選對 Gemma 4 MTP 版本。
5. 排查 port 撞、記憶體不足、模型載入慢、cache 過大等情境。

最短路徑：5 分鐘把 Ollama 跑起來

最短路徑的設計目標是「裝、跑、驗證三步、其他細節留到日常使用段」。三個指令用到的 macOS 工具分別是 Homebrew 套件管理器（brew install）跟 shell 前景 process（ollama serve 預設前景跑、Ctrl+C 結束）。

1# 1. 安裝
2brew install ollama
3
4# 2. 啟動 server（前景跑、Ctrl+C 結束）
5ollama serve
6
7# 3. 在另一個 terminal 拉一個小模型驗證
8ollama run gemma3:1b

第三步首次執行會下載權重（約 815 MB、頻寬足夠的話 1 ~ 3 分鐘）、下載完自動進入 REPL：

1>>> 寫一個 Python function 計算 fibonacci
2def fibonacci(n):
3    if n <= 1:
4        return n
5    return fibonacci(n - 1) + fibonacci(n - 2)
6>>> /bye

驗證 server 正常聽 11434：

1curl http://localhost:11434/api/version
2# 回 {"version":"0.23.x"}

驗證 OpenAI 相容 API 可以做 chat completion：

1curl http://localhost:11434/v1/chat/completions \
2  -H "Content-Type: application/json" \
3  -d '{
4    "model": "gemma3:1b",
5    "messages": [{"role": "user", "content": "Hello"}],
6    "stream": false
7  }'

回應 JSON 包含 choices[0].message.content、最短路徑就完成。實際寫 code 用的模型大小通常是 14B / 31B 級、選型詳見 1.4 模型選型優先順序；完整安裝紀錄含 launchd service 設定見 Hands-on：Ollama 安裝。

日常使用：模型管理與 API 形狀

模型管理指令

Ollama 用四個指令覆蓋日常模型管理。每個指令承擔一個語意責任：

模型權重存在 ~/.ollama/models/、單一大模型（30B+）可能佔 18 ~ 30 GB、累積超過 100 GB 很常見。清理路徑統一用 ollama rm、Ollama 會同步更新 registry metadata、後續 ollama list 與 ollama pull 才能正確判斷既存模型狀態。

Model tag 命名規則

Model tag 是 Ollama 的模型定位符、形式為 family:size-variant-quantization。同一個 model family 可能有十幾個 tag、對應不同參數量、訓練變體跟量化等級。

選 tag 時的兩個判讀重點：variant（instruct / coding 等用途特化、影響回應風格）、quantization（量化等級、影響記憶體佔用與品質、見 1.2 llama.cpp 的量化標籤對照）。完整 tag 清單在 ollama.com/library。寫 code 場景的推薦選擇詳見 1.4 模型選型。

兩套 API：選哪一套

Ollama 在 11434 同時提供兩套 API、用途互補：

寫 code 場景多半用 /v1/…、因為 IDE plugin 預設講這套形狀。詳細協定背景見 0.3 OpenAI 相容 API。

驗證 streaming 回應：

1curl http://localhost:11434/v1/chat/completions \
2  -H "Content-Type: application/json" \
3  -d '{
4    "model": "gemma3:1b",
5    "messages": [{"role": "user", "content": "Count 1 to 5"}],
6    "stream": true
7  }'

Streaming 回應是一連串 data: {...} 行、每行一個 token chunk。Ollama 原生 /api/generate 還支援 num_predict、temperature、stop 等細項、IDE plugin 內部會自行轉換、終端使用者通常用不到。

進階主題（按需閱讀）

進階段的特色是「沒有它最短路徑仍能跑、但搞懂後體驗大幅提升」。最短路徑只想跑通的讀者可以先跳到排錯、需要時再回來。

背景常駐：launchd service

ollama serve 預設在前景跑、terminal 關掉就停。日常使用建議讓 Ollama 開機自動啟動、用 macOS 的 launchd service 機制：

1brew services start ollama

這個指令做兩件事、決定 Ollama 之後的行為：

1. 寫一個 launchd plist 到 ~/Library/LaunchAgents/homebrew.mxcl.ollama.plist
2. 立刻啟動 ollama serve、之後重開機自動拉起

launchd 是 macOS 原生的服務管理機制、把 process 註冊成 daemon / agent、由系統負責生命週期。brew services 是 Homebrew 對 launchd 的封裝、把 plist 模板跟啟動指令簡化成一行。Log 統一寫到 /opt/homebrew/var/log/ollama.log（Apple Silicon Mac）、出問題第一步先看這個檔。

對應的服務管理指令：

1brew services stop ollama      # 停掉、保留 plist
2brew services restart ollama   # 升級後重啟

完整 plist 內容與 log 範例見 Hands-on：Ollama 安裝。

Gemma 4 MTP 一鍵加速

Multi-Token Prediction（MTP） 是 speculative decoding 的具體實作、用一個小 drafter 預測多個 token、再由 target model 驗證、coding 任務有 2 ~ 3 倍加速。Ollama v0.23.1（2026/5/7 釋出）內建 Gemma 4 的 MTP 一鍵支援、啟用方式只需要 pull 對應 model tag：

1ollama run gemma4:31b-coding-mtp-bf16

這個 tag 內含 target model（31B）跟 drafter（Google 釋出的官方小模型）、Ollama 自動把兩個 model 載入記憶體、推論時並行驗證。記憶體佔用約 18 GB（drafter 約 1 GB、其餘為 target）、適合 32GB+ Mac。詳細原理見 0.4 MLX / MTP / oMLX。

判讀 MTP tag 時的三個重點：

1. Tag 裡的 bf16 描述的是 drafter 精度。Target model 內部已套用量化、實際佔用約 18 GB、跟「整個 31B 用 bf16 跑、要 60+ GB」是兩件事。
2. 加速幅度跟任務 pattern 預測度成正比。Coding（pattern 強）2 ~ 3 倍、純創意寫作或隨機字串生成大約 1.5 倍。
3. 品質由 target model 保證。Drafter 猜錯時 target 會拒絕該預測、最終輸出跟「直接由 target 生成」一致、drafter 只影響速度。

模型常駐：keep_alive

ollama run 第一次跑某個 model 時、需要 30 ~ 60 秒把權重從 SSD 載入記憶體；後續對話則用 cached 權重、快得多。Ollama 預設把載入的 model 留在記憶體 5 分鐘（keep_alive 預設值）、長時間不用會被 unload 釋放記憶體。

長時間穩定使用的場景可以延長 keep_alive：

1OLLAMA_KEEP_ALIVE=-1 ollama serve     # 永久保留
2OLLAMA_KEEP_ALIVE=2h ollama serve     # 保留 2 小時

-1 設定會持續佔用記憶體、適合「整天頻繁用」的工作流；偶爾用一次的場景保持預設、讓系統自動釋放更省記憶體。

對外暴露與信任邊界

預設 Ollama 只聽 127.0.0.1、外部裝置連不上。讓 LAN 內其他機器（例如桌機跑 server、筆電當 client）能用、把 listen address 改成 0.0.0.0：

1OLLAMA_HOST=0.0.0.0:11434 ollama serve

這個設定把 Ollama 暴露在整個區網、任何同網路裝置都能呼叫 API。信任邊界的三種典型情境：

• 家用 / 信任的辦公網路：風險低、可以直接開
• 公共 Wi-Fi、共用網路：透過 SSH tunnel 把 11434 隧道到遠端、或加防火牆規則限制 source IP
• 暴露到 Internet：需要 reverse proxy 加 auth、Ollama 本身沒有內建身分認證

完整資料流判讀見 0.7 隱私 / 資安資料流、綁定模式（loopback / LAN / reverse proxy + auth）跟誤開放後的具體後果見 6.1 推論伺服器的綁定與暴露範圍。

版本管理

Ollama 釋出節奏快、每兩三週可能加新功能或修嚴重 bug。升級流程：

1brew upgrade ollama
2brew services restart ollama   # 若用 launchd service 跑

升級前先看 release notes、確認三件事：

1. 是否引入 breaking API change（IDE plugin 可能要對應更新）
2. 是否棄用舊 model tag（拉新 tag 取代）
3. 是否帶來想要的新功能（例如新模型支援、加速優化）

排錯快速判讀

排錯段的設計是「先給操作原則、再列觸發條件」、讓讀者快速定位現象屬於哪一類。

Port 11434 已被佔用

操作原則：先檢查是不是舊 Ollama 還在跑、再決定 kill 或換 port。lsof / pkill 的角色是找出佔用方並送終止訊號。

1lsof -i :11434          # 看誰佔 11434
2pkill -f "ollama serve" # 確認是舊 Ollama 才 kill
3ollama serve &          # 重啟、& 是把 process 丟背景

需要兩個 Ollama 並存的場景、改 port 啟動：

1OLLAMA_HOST=127.0.0.1:11435 ollama serve

IDE plugin 的 apiBase 也要對應改成 11435。

記憶體不足、模型崩潰

操作原則：先用 ollama ps 看實際載入了什麼、再對照 0.5 記憶體預算 決定降級。

1ollama ps
2# NAME           ID      SIZE     PROCESSOR    UNTIL
3# gemma4:31b...  abc123  18 GB    100% GPU     5 minutes from now

模型大小超過 Mac 記憶體預算時的可選路徑：

• 換較小 model（例如 31B → 14B）
• 換較激進量化（例如 Q5_K_M → Q4_K_M）
• 縮短 context window（在 IDE plugin 端設定）

模型載入很慢

操作原則：第一次載入慢屬於正常、後續呼叫如果還是慢、檢查 keep_alive 設定。

第一次載入 18 GB 權重需要 30 ~ 60 秒、屬於 SSD → RAM 的真實 I/O 時間。如果發現「每次第一個請求都慢」、表示 keep_alive 太短、模型每次被 unload 又重新載入。延長 keep_alive 解決：

1OLLAMA_KEEP_ALIVE=1h ollama serve

代價是模型常駐記憶體、其他應用可用記憶體變少。

Model cache 過大佔滿 SSD

操作原則：清理用 ollama rm <tag>、Ollama 才會同步更新 registry metadata。

1ollama list             # 看哪些 model 佔空間
2ollama rm <tag>         # 刪除單一 model

手動 rm -rf ~/.ollama/models/ 會留下 registry metadata 不一致、後續 ollama list 出錯、ollama pull 也可能誤判已存在。需要完全重置的場景、用：

1brew services stop ollama
2rm -rf ~/.ollama
3brew services start ollama

這會清掉所有 model 跟設定、重新從零開始。

跟其他伺服器並存

Ollama 設計上可以跟 LM Studio、llama.cpp 同時在一台 Mac 跑、預設 port 不同：

並存的好處是「主力穩定跑 Ollama、實驗模型用 LM Studio」、Continue.dev 等介面層可以同時設多個 model、UI 上下拉切換。並存設定範例見 1.1 LM Studio。

下一章

下一章可選擇：

• 想對比 GUI 派的選擇：1.1 LM Studio
• 想了解底層 / Ollama 跟 llama.cpp 的關係：1.2 llama.cpp
• 直接進入 VS Code 整合：1.3 VS Code + Continue.dev