對寫 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 才是真本地」這類迷思。

讀完本模組後，你應該能在自己的 Mac 上裝好一個本地 LLM 工作流，並知道它的能力邊界、什麼時候該切回雲端。

章節列表

推論伺服器選型總表

模組零已建立的三層架構視角告訴你 Ollama、LM Studio、llama.cpp 都屬於伺服器層。本模組要回答的是這三者的具體差異：

讀完本表後的決策建議是：先裝 Ollama，跑穩後再評估其他。LM Studio 可以同時裝來探索模型，但日常主力建議 Ollama；llama.cpp 暫時不需要直接接觸（Ollama 內部已經用 llama.cpp）。

為什麼這個順序

本模組章節順序的設計脈絡：

1. 先 1.0 Ollama：學習曲線最低、生態最成熟、Gemma 4 MTP 一鍵支援。多數讀者裝完這個就能開始用。
2. 再 1.1 LM Studio：給「想要可視化探索」的讀者另一條路；也可以跟 Ollama 並存。
3. 接 1.2 llama.cpp：澄清網路上「llama.cpp 才是真本地」的迷思，給進階讀者完整背景。
4. 再 1.3 VS Code + Continue.dev：把伺服器接到日常工作環境，這才是寫 code 的真正起點。
5. 然後 1.4 模型選型：伺服器跑起來後該裝哪個模型，給優先順序。
6. 再 1.5 期望管理：用一週後該怎麼判斷「值不值得繼續用」「什麼時候切雲端」。
7. 最後 1.6 延伸方向：日常路徑穩了再玩 Web UI、coding agent、產圖。

每一章可以單獨讀，但若你是第一次接觸本地 LLM，照順序讀最不容易迷路。

一個小時的最短路徑

如果你沒時間讀完整本模組、只想用一小時搞定本地 LLM 寫 code 的最基本工作流，下面是最短路徑：

 1# 1. 裝 Ollama（5 分鐘）
 2brew install ollama
 3ollama serve &
 4
 5# 2. 拉模型（首次下載約 20 ~ 30 分鐘，看網速）
 6ollama run gemma4:31b-coding-mtp-bf16
 7
 8# 3. 在 VS Code 裝 Continue 擴充套件（2 分鐘）
 9# 4. 設定 ~/.continue/config.json（5 分鐘）
10# 5. 試用 Cmd+L（對話）、Cmd+I（行內編輯）（剩下時間）

需要 32GB+ Mac 才能流暢跑這個 model；16GB / 24GB 請改用 1.4 模型選型 的對照表選對應大小的模型。完整步驟在 1.0 Ollama 跟 1.3 VS Code + Continue.dev。

跑穩之後該做什麼

裝完不是終點。本地 LLM 跟雲端的差別在於「需要持續調教」。跑穩後建議的後續工作：

1. 用一週實測：把日常工作流真實餵進去、記錄通過率與痛點、用真實任務當判讀依據而非示範任務。
2. 建立切換習慣：明確哪些任務交給本地、哪些切雲端。詳見 1.5 期望管理。
3. 觀察記憶體與發熱：開 Activity Monitor 看記憶體 swap 狀態、機殼溫度是否過高。
4. 追新模型：本地模型發布速度很快、每 2 ~ 3 個月會有新候選、值得追蹤。
5. 判斷是否升級硬體：用一個月後若限制都來自記憶體、再評估升級 Mac；先確認痛點再投資硬體。

不在本模組內的主題

本模組不討論：

1. 訓練、fine-tuning、LoRA 微調 — 跟「跑現成模型」是不同的工程問題。
2. 部署到雲端 GPU、Linux server — 本指南範圍只在 Apple Silicon Mac。
3. Cursor、Windsurf、Cline 等其他 IDE 整合 — Continue.dev 是與本地 LLM 整合最成熟的選擇，其他工具的整合度視版本而定。
4. 詳細的 benchmark 跑分方法 — 本指南只引用官方數據，自己跑分屬於另一個工程主題。

需要這些主題時請另尋專門資源；硬塞進來只會讓「Mac 本地寫 code」這條最短路徑被淹沒。

讀完本章後、你應該能在 Windows 上：選對 LM Studio 的 GPU backend、在 GUI 內設定卸載層數與 KV cache 量化、啟動 OpenAI 相容 server、接到 VS Code Continue.dev。

本章目標

1. 在 Windows 上安裝 LM Studio、選對 GPU backend。
2. 知道 GUI 設定面板的哪幾個欄位對應 llama.cpp 的核心旗標。
3. 啟動 LM Studio 的本地 server、提供 OpenAI 相容 API。
4. 判斷你的工作流適不適合用 LM Studio 當主力。
5. 處理常見的 Windows + GPU 整合議題（driver 版本、CUDA toolkit）。

安裝

LM Studio 是 Electron 桌面 app、個人使用免費、Windows / Linux / macOS 三平台都支援。從 lmstudio.ai 官網 下載對應系統的安裝檔即可。

Windows 版的安裝步驟：

1. 下載 .exe 安裝程式、執行安裝（不需 admin 權限的情況下會裝在使用者目錄）。
2. 首次啟動時、LM Studio 會偵測 GPU 並提示選擇 backend。

事實查核註：LM Studio 是商業軟體、UI 跟功能會隨版本變化。本章描述以 2026 年 5 月的穩定版為基準、實際 UI 元素位置以當前版本為準。

GPU backend 選擇

LM Studio 在 Windows 上的 GPU compute backend 選項依 GPU 廠商不同：

backend 的切換位置：LM Studio 的設定面板（齒輪圖示）→ Hardware / Runtime 區段、會列出當前可用的 backend 與下載連結。部分 backend 在首次使用時需要下載對應的 runtime（如 CUDA runtime）。

選錯 backend 的常見徵兆：

1. 模型載入時間異常長：可能 fallback 到 CPU、確認 GPU backend 是否正確啟用。
2. 生字速度遠低於同硬體的社群回報：backend 不對、或 driver 版本不對、或 VRAM 不足而啟用了 CPU offload。
3. 載入時錯誤訊息提到 CUDA 版本不符：driver 跟 LM Studio 內建的 CUDA runtime 不對齊、需更新 driver 或選擇對應的 LM Studio build。

事實查核註：各 backend 的可用性跟下載方式依 LM Studio 版本變動、以當前版本的 Hardware / Runtime 設定面板顯示為準。

GUI 設定對應到 llama.cpp 旗標

LM Studio 在背後使用 llama.cpp、GUI 內的設定欄位通常對應到 llama.cpp 的某個旗標。對熟悉 5.3 llama.cpp 在 PC 上 旗標的讀者、這個對應表能加速 GUI 內的設定：

具體欄位名稱跟位置依 LM Studio 版本變化、以實際 UI 為準。新加入 llama.cpp 的旗標通常會在後續 LM Studio 版本被加進 GUI。

啟動 LM Studio Server

LM Studio 內建 OpenAI 相容 server、預設 port 1234。啟用步驟：

1. 載入想用的模型（GUI 左側 Chat / Local Server 切換）。
2. 切到「Local Server」分頁。
3. 設定上面對應的旗標（GPU Offload、Context、KV Quant、MoE Offload 等）。
4. 點「Start Server」、看 log 確認模型載入成功、port 顯示為 1234（或自訂）。

啟動成功後、可以用任何 OpenAI 相容 client 連接：

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

接到 VS Code Continue.dev：

 1{
 2  "models": [
 3    {
 4      "title": "LM Studio",
 5      "provider": "openai",
 6      "model": "loaded-model-name",
 7      "apiBase": "http://localhost:1234/v1",
 8      "apiKey": "not-needed"
 9    }
10  ]
11}

model 欄位填 LM Studio 載入的模型名稱、要跟 GUI 顯示一致。

模型瀏覽器與下載

LM Studio 的內建模型瀏覽器直接連到 Hugging Face、可以搜尋 GGUF 格式的模型並一鍵下載。對「想試新模型但不想自己抓 GGUF」的使用者較友善。

下載時的選擇：

1. 量化等級：LM Studio 會列出可用的量化版本（Q4_K_M、Q5_K_M、Q8_0 等）、可依 VRAM 預算選擇。
2. 模型大小估計：LM Studio 通常會顯示「在你當前硬體上能不能跑」的提示；提示為估計、實際載入仍以 llama.cpp 啟動結果為準。
3. 下載位置：LM Studio 預設下載到使用者目錄；可在設定面板改路徑（適合把模型放到大容量 SSD）。

事實查核註：LM Studio 對「能否在當前硬體跑」的判讀是基於 VRAM + RAM 容量的估算、不考慮 MoE 卸載、KV cache 量化等進階設定；提示僅供參考、實際以實測為準。

跟 Ollama / llama.cpp 並存

LM Studio、Ollama、llama-server 可以同時跑、用不同 port：

實務上同時跑多個的場景是調參階段比較不同 backend 或設定；常態使用通常一個就夠。

切換主力的判讀：

Windows + GPU 整合常見議題

Windows 上跑本地 LLM 的常見議題：

1. NVIDIA driver 版本：driver 太舊可能不支援 LM Studio 內建的 CUDA runtime；過新 driver 偶爾出現相容性問題。建議用 NVIDIA Studio Driver（相對 Game Ready Driver 更穩）、或 NVIDIA 官方建議的當前長期支援版本。
2. WSL2 vs 原生 Windows：LM Studio 在原生 Windows 跟 WSL2 都能跑；WSL2 可以更接近 Linux 環境（適合熟悉 Linux 工具的使用者）、但 GPU 透傳的配置略多。
3. windows defender / 防毒軟體掃描：模型檔案常為 10+ GB、安全軟體的即時掃描可能拖慢載入速度；建議把模型目錄加入排除清單。
4. 電源計劃：Windows 的「省電」電源計劃可能讓 CPU 在閒置時降頻、影響 prefill 速度；建議使用「高效能」或自訂「卓越效能」計劃。
5. VRAM 被其他應用佔用：Chrome、Discord、遊戲都可能佔用 VRAM；觀察「工作管理員 → 效能 → GPU」確認 VRAM 餘量。

事實查核註：上面的議題以 Windows 10 / 11 為背景、具體現象跟解法依 Windows 版本、driver 版本變化。引用前以自己版本的官方文件為準。

給多數讀者的建議

LM Studio 在 Windows + 獨立 GPU 場景的核心價值是「降低 MoE 卸載與 KV cache 量化的學習成本」。對下面類型的使用者特別合適：

1. 剛接觸本地 LLM、不熟悉 CLI 旗標。
2. 主力工作是探索新模型、不是調穩定 production-like 設定。
3. 想視覺化看「卸載層數 vs VRAM 用量」的關係、再決定要不要轉到 CLI。

對下面類型的使用者、Ollama 或直接 llama-server 通常更適合：

1. 熟悉 CLI、想最完整地控制旗標。
2. 主力是穩定日常寫 code、模型不常換。
3. 想用 llama-bench 做精確校準。
4. 部署到團隊或多人共用的 server 環境（GUI app 不適合 headless 部署）。

下一章

下一章：5.5 PC 場景的模型選型優先順序、用前面四章建好的工程選項回答「具體裝哪個模型」。