對寫 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 的真正起點。

對「在 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