理解這個機制不只是為了知識本身。後續所有加速技巧（speculative decoding、MTP、KV cache、量化）都是在攻擊這兩個瓶頸的不同部分；不懂瓶頸在哪，看到「2x 加速」「3x 加速」這種廣告詞就無從判讀。

本章目標

讀完本章後，你應該能回答：

1. 為什麼 LLM 採用「一個 token 接一個 token」的生成方式、而非整段一次生出？
2. 為什麼 Apple Silicon 的「統一記憶體」對 LLM 推論是優勢？
3. 為什麼模型量化能加速、而非只是省記憶體？
4. 為什麼長 prompt 的首字延遲特別有感？

自回歸架構：一次只能吐一個 token

自回歸的核心概念是「下一個 token 的生成需要前面所有 token 的結果」。模型每生成一個 token，都要把目前已有的 token 序列（你的 prompt + 它已經生成的部分）重新丟進神經網路算一次，得到下一個 token 的機率分佈，挑一個輸出，然後重複。

舉個具體例子。當你輸入 寫一個 Python function 計算費氏數列，模型生成回答的過程大致是：

1. 把 prompt 丟進模型，產出第一個 token，例如 def。
2. 把 prompt + def 丟進模型，產出 fib。
3. 把 prompt + def fib 丟進模型，產出 (。
4. 一直重複到模型決定產出結束 token。

每一步都要跑一次完整的神經網路 forward pass（神經網路把輸入資料從第一層算到最後一層、產出輸出的單次計算）。這就是為什麼回答長度直接影響等待時間、跟雲端旗艦模型一樣；差別只是雲端每個 forward pass 跑得更快。

陷阱是把自回歸跟 streaming 混淆。Streaming 只是把已產出的 token 即時顯示在畫面上，看起來「邊想邊說」；模型內部該跑幾次 forward pass 就是幾次，streaming 不會加速生成本身。

記憶體頻寬：Apple Silicon 真正的瓶頸

LLM 推論的瓶頸幾乎一定落在記憶體頻寬、而不是算力。原因是每生成一個 token 都要把整個模型的權重從記憶體讀到處理器一次；模型有多大、每秒能讀多少 GB、就決定了每秒能吐幾個 token。每生一個 token 都要把整份權重讀過一次、所以「每秒能讀完幾份權重」就是「每秒能吐幾個 token」。

模型大小的換算規則很簡單：bf16 每個權重佔 2 bytes、Q4 量化後每個權重約 0.5 byte。所以：

• Gemma 4 31B 的 bf16 權重約 62GB（31B × 2 bytes）、Q4 量化後約 18GB。
• M4 Max 的記憶體頻寬約 546 GB/s、M2 Pro 約 200 GB/s。
• 理論上限 = 頻寬 / 模型大小。M4 Max 跑 Q4 量化 31B 模型、理論上限約 546 / 18 ≈ 30 tok/s。

實際數字會比理論上限低 30 ~ 50%（attention 機制的 KV cache 也要讀寫、有些運算需要中間結果），所以 M4 Max 跑 Q4 31B 大約落在 20 ~ 25 tok/s。這個推導讓你看到任何「在 Mac 上跑 70B 模型很快」的說法時，可以直接用頻寬算一下合不合理。

Apple Silicon 的**統一記憶體**（Unified Memory Architecture, UMA）讓 CPU、GPU、Neural Engine 共用同一塊記憶體、省下跨 PCIe 搬資料的成本。傳統 PC + NVIDIA GPU 的記憶體分成系統記憶體跟 VRAM；模型權重要放進 VRAM 才能用 GPU 跑、跨 PCIe 搬資料的速度成本很高。Mac 的 64GB 統一記憶體可以幾乎全部給模型用（扣掉系統保留部分）、同等價位的 PC 通常只有 12GB ~ 24GB VRAM。

這就是為什麼 Mac 在「跑得動多大的模型」上佔優勢，但在「跑多快」上輸給 H100。H100 的 HBM 頻寬約 3,300 GB/s，是 M4 Max 的 6 倍。能跑得動 vs 跑得快，是兩件事。

量化：用精度換頻寬

量化的核心是把模型權重從 16-bit float 壓成 4-bit、5-bit、8-bit integer。權重數量不變，但每個權重佔的 bytes 變少；模型總大小變小，每秒能讀過的權重變多，生字速度直接變快。

常見量化等級：

接近真實的選擇：

• 32GB Mac 跑 31B 模型：選 Q4_K，記憶體佔用 ~ 18GB，留 14GB 給系統與 IDE。
• 24GB Mac 跑 14B 模型：選 Q5_K 或 Q4_K，看任務品質要求。
• 16GB Mac 跑 7B 模型：選 Q4_K，是現實上界。

陷阱是把量化等級拉到極限以塞下更大模型。Coding 任務上 Q3 的 31B 模型常輸給 Q5 的 14B 模型；模型「夠大」跟「夠好」是兩件事、選 model size 時先看任務通過率、再用量化等級調記憶體。後續 模型選型章節 會展開這個取捨。

KV cache 與長 prompt 痛點

KV cache（key-value cache）把 attention 機制每個 token 產生的中間結果暫存、後續 token 生成時直接讀 cache 跳過重算、讓「已經算過的 prompt」省下重複跑 forward pass。

但 KV cache 有兩個性質會放大長 prompt 的痛點：

1. 首次處理 prompt 時要完整算過一次、這個階段稱為 prefill。10K token 的 prompt 在本地可能需要 30 ~ 90 秒才 prefill 完、這 30 ~ 90 秒就是 TTFT 的主要來源。
2. KV cache 本身佔記憶體：長 context 跑下來、KV cache 可能比模型權重還大、會擠壓可用記憶體。

這就是為什麼 coding agent 場景（塞整個 repo 進 prompt）在本地特別痛：每次都要重新 prefill，每次都等 30 ~ 90 秒。oMLX 這類特化伺服器就是針對這個痛點，用 paged SSD KV cache 把已 prefill 過的 context 存到 SSD，下次同樣的 prompt 前綴可以直接讀 cache，把 TTFT 從 30 ~ 90 秒降到 1 ~ 3 秒。詳見 0.4 MLX / MTP / oMLX。

Speculative decoding 與 MTP

既然瓶頸是「每生一個 token 都要讀一次完整模型權重」、那能否一次生多個 token？speculative decoding（推測解碼）就是這個想法的具體實作。

機制大致是：

1. 用一個小模型（drafter、例如 1B 參數）快速猜未來 N 個 token。
2. 把這 N 個 token 一次餵給大模型（target、例如 31B 參數）、讓大模型並行驗證每個位置的機率分佈。
3. 大模型保留認同的前綴、從第一個拒絕點之後重新生成。

這個機制能加速的關鍵是「大模型的驗證可以並行」。一次 forward pass 驗證 N 個 token 的時間，跟驗證 1 個 token 的時間差不多（因為瓶頸是讀權重，不是算力）。如果接受率高，等於一次 forward pass 產出多個 token。

寫 code 場景特別適合 speculative decoding、因為 code 有大量可預測 pattern（縮排、括號、常見變數名、import 語句）、小模型猜對的接受率高。Google 為 Gemma 4 釋出官方 drafter、官方數據在 coding 任務有 2 ~ 3 倍加速；接受率低的任務（純創意寫作、隨機字串生成）加速幅度可能降到 1.5 倍左右、加速倍數跟任務 pattern 強相關。

Multi-Token Prediction（MTP）是這個概念的具體實作、本質是 speculative decoding 的工程化版本。下一章 0.4 MLX / MTP / oMLX 會把 MTP 跟其他容易混淆的術語放在一起對照。

何時這套推導失準

「頻寬決定生字速度」是 dense 模型 + 單請求情境下的乾淨推導。實務上有三類情境會讓這個公式失準、解讀效能數字時要對應調整：

1. MoE 模型（Mixture of Experts）：每個 token 只啟用部分專家層、實際讀的權重遠小於總權重。例如 Mixtral 8x7B 名義 46B 參數、但每個 token 只啟用約 12B、速度上限要用「啟用權重」算、不是總權重。判讀 MoE 模型在 PC 獨立 GPU 上的部署細節見 MoE CPU 卸載。
2. 多請求 batching：資料中心級推論伺服器把多請求 batch 一起跑、權重讀一次處理 N 個 token、攤平頻寬成本。本章開頭舉的「H100 跑 200 tok/s」是 batch=1 的單 user 數字、production 場景 batch=32 時單 user 看到的速度更接近 50 tok/s、但 total throughput 翻 N 倍。詳見 batching 卡片。
3. Speculative decoding 接受率變動：MTP / drafter 的加速幅度跟任務 pattern 強相關、coding 任務的 2 ~ 3 倍無法直接 carryover 到創意寫作、看 benchmark 數字時要追問「跑的是哪類任務」。

判讀效能數字時的反射動作：先問「dense 還是 MoE」「batch 多少」「任務 pattern 強弱」、再決定能不能套頻寬公式。

下一章

下一章：0.2 三層架構，把任何本地 LLM 工具放回正確的層級。

對應到你已經熟悉的雲端世界：ChatGPT 網頁是介面層，OpenAI 的後端服務是伺服器層，GPT-5 模型是模型層。Cursor 是另一個介面層，連到的也是同一批雲端伺服器。介面跟伺服器各自獨立演化，這就是為什麼換介面不用換模型、換模型不用換介面。

本地 LLM 把這三層全部搬到你的 Mac 上，但分層關係不變。看懂這點，後面所有工具關係就清楚。

本章目標

讀完本章後，你應該能：

1. 看到任一個本地 LLM 工具，立刻判斷它屬於哪一層。
2. 理解為什麼可以「介面換、伺服器留」或「伺服器換、介面留」。
3. 看懂 localhost:11434 這類本地 API endpoint 的意義。
4. 對應雲端世界的工具，建立熟悉感橋接。

三層的責任邊界

這張表是後續判讀新工具的基底。任何工具都可以放到這三層的某一格；少數工具同時跨多層（例如 LM Studio 內建介面跟伺服器），但它的功能仍可拆成三層去理解。

介面層：你實際在用的東西

介面層的責任是「人類能舒服地把任務送進去、把結果拿出來」。它本身不跑模型，只是把使用者輸入打包成 API 請求、把 API 回應顯示出來。

接近真實的例子：

• Continue.dev：VS Code 擴充套件，把 Cmd+L 開啟側邊對話框、Cmd+I 觸發 inline 編輯。背後送的是 OpenAI 相容 API 請求，target 可以是本地 Ollama 也可以是雲端 OpenAI。
• aider：CLI 工具，把 git 倉庫狀態跟 prompt 一起打包送進 LLM，再把回應的 diff apply 到本機檔案。背後也是送 API 請求。
• Open WebUI：類 ChatGPT 風格的網頁介面，跑在本機 Docker 裡，連到本地或遠端的 LLM API。
• CLI 直接呼叫：ollama run gemma4:31b 在終端機開一個對話 session，本身也是一個介面層。

介面層的選擇影響日常使用體驗，但完全不影響推論速度或品質。換介面不用換模型，這就是分層的好處。

伺服器層：載入權重與跑推論

伺服器層負責把模型權重從磁碟載入記憶體、接收 HTTP API 請求、處理 prompt、跑推論、把生成的 token 流回客戶端。

接近真實的例子：

• Ollama：最主流的本地推論伺服器、預設聽 localhost:11434、提供 OpenAI 相容 API 與自己的原生 API。內建 model registry、ollama pull gemma4:31b 會自動下載權重檔。
• LM Studio：GUI 工具、內建模型瀏覽器與本地伺服器。可以在 UI 上開啟 server、預設聽 localhost:1234。適合喜歡可視化操作、不熟悉終端機的使用者。
• llama.cpp server：底層推論引擎附帶的 HTTP server、需要手動編譯與配置。Ollama 內部其實是用 llama.cpp 當推論引擎。
• oMLX：建在 MLX 之上的特化伺服器、主打 paged SSD KV cache、針對 coding agent 長 context 場景的首字延遲優化。詳見 0.4 MLX / MTP / oMLX。

伺服器層的選擇影響：

1. 速度：不同伺服器對量化、KV cache、speculative decoding 的支援度不同。
2. 能跑哪些模型：每個伺服器支援的模型格式不同（GGUF、MLX、Safetensors 等）。
3. API 形狀：多數本地伺服器同時提供「OpenAI 相容」跟「自家原生」兩套 API。詳見 0.3 OpenAI 相容 API。

陷阱是把伺服器跟模型混為一談。「Ollama 跑得快不快」這句話離開模型與機器脈絡就難以判讀、要追問「Ollama 跑哪個模型、在哪台 Mac 上、tok/s 多少」才有意義。伺服器是執行引擎、模型是被執行的對象。

模型層：權重檔本身

模型層就是神經網路的權重檔。本身只是一堆數字，沒有伺服器就無法執行；但同一個模型可以被不同伺服器載入，前提是格式相容。

接近真實的例子：

• Gemma 4 31B：Google 釋出的開源模型，31 billion 參數。權重檔可以是 gemma-4-31b-it-Q4_K_M.gguf（GGUF 格式、Q4 量化）或 mlx-community/gemma-4-31b-it-4bit（MLX 格式）。
• Qwen3-Coder 30B：Alibaba 釋出的 coding 專用模型、SWE-bench 等 coding benchmark 上表現強。
• Llama 3.x 系列：Meta 釋出的開源模型，是早期本地 LLM 生態的主力。
• gpt-oss 20B：OpenAI 釋出的開源版本，2025 年發布。

模型層的關鍵屬性：

1. 參數規模（B = billion）：7B、14B、31B、70B 等。規模越大能力越強，但記憶體佔用、推論速度成本也越高。
2. 量化等級：bf16、Q8、Q5_K、Q4_K 等。同模型不同量化，記憶體與品質的取捨不同。
3. 格式：GGUF（llama.cpp 與 Ollama 主流）、MLX（Apple 框架）、Safetensors（Hugging Face 通用）等。不同伺服器支援的格式不同。
4. 訓練目的：base model、instruction-tuned、coding-tuned 等。寫 code 場景下 instruction-tuned + coding 版本通常勝過 base model；base model 適合下游微調研究、直接拿來對話的場景較少。

模型選擇影響能力與速度。同樣 32GB Mac 跑 Gemma 4 31B 跟 Qwen3-Coder 30B，兩個模型擅長的任務不同，速度也不同。詳見 模型選型章節。

拼裝組合：三層的搭配範例

理解三層後，本地 LLM 的所有「組合」都變得簡單。下表是幾個常見組合：

表格中的規格欄位（量化等級、gemma4:31b-coding-mtp-bf16 這類 model tag、Q3 等）含義見 0.5 記憶體預算 與 Ollama model tag 命名規則。

注意三件事：

1. 介面跟伺服器之間用 HTTP API 通訊，所以介面層可以同時連多個伺服器，或一個伺服器服務多個介面層。
2. 同一個介面（如 Continue.dev）可以同時設定本地 Ollama 跟雲端 OpenAI，根據任務切換。
3. LM Studio 自己同時是介面 + 伺服器，所以表上有兩列；但它的伺服器部分也可以對外 expose，讓其他介面（如 Continue.dev）連進來。

雲端對應關係：建立熟悉感橋接

下表把本地三層對應到雲端世界，幫助建立直覺：

這個對應的關鍵啟示是：Cursor 跟 Continue.dev 都是介面層、差別在於 Cursor 預設綁雲端、Continue.dev 預設綁本地、但兩者的責任邊界一樣。換句話說、要在 VS Code 裡接本地 LLM、不需要尋找專屬「本地版的 Cursor」、找一個能設定 OpenAI 相容 endpoint 的介面層就好。

分層失效徵兆：什麼時候三層心智模型會失準

三層架構是教學用的乾淨模型、實務上有幾類工具會跨層或讓邊界模糊、判讀時要對應調整：

1. 同層耦合（介面 + 伺服器綁死）：LM Studio 的 GUI 跟內建 server 同屬一個 app、關掉 LM Studio 視窗 server 就停。這類工具用起來方便、但失去「介面換、伺服器留」的彈性、想常駐 server 時建議改用 Ollama 的 launchd service 模式。
2. 伺服器內嵌引擎（責任邊界模糊）：Ollama 內部用 llama.cpp 當推論引擎、但對使用者展現的是 Ollama API 跟 model tag。看到「Ollama 不支援某個 llama.cpp 新功能」時、要回到 Ollama 的 release notes 看版本 cherry-pick 狀態、不是看 llama.cpp 上游。
3. All-in-one 工具淡化分層：Open WebUI 把介面、user 管理、RAG pipeline 都包進一個 Docker container、看起來像「裝完就能用」、但底層仍要連到一個伺服器層（Ollama / OpenAI）。判讀此類工具時、先問「它的 server 是內建還是外接」、就能放回正確的分層。
4. 「Cursor 是本地工具嗎」常見誤判：Cursor 是介面層、它連的是雲端伺服器層、跑的是雲端模型 — 不是本地工具。對應到本地的是 Continue.dev + Ollama + 本地模型的組合。

判讀新工具的反射動作：先把它拆成三層（這工具負責介面 / 伺服器 / 模型 的哪一段？）、再問「它做了多少跨層耦合、影響什麼彈性」。

下一章

下一章：0.3 OpenAI 相容 API，解釋為什麼三層之間能自由組合，背後是同一套 API 形狀。

這個相容性決定了你的選擇空間。理解它的意義後，看到任何工具寫「支援 OpenAI 相容 API」時，你會知道這句話真正承諾的是什麼、不承諾的是什麼。

本章目標

讀完本章後，你應該能：

1. 看懂 apiBase: http://localhost:11434/v1 這類設定背後在做什麼。
2. 判斷一個介面層工具是否支援本地 LLM。
3. 知道「OpenAI 相容」承諾的範圍與邊界。
4. 用 curl 直接打本地 LLM 的 API 驗證它在跑。

API 形狀的核心：chat completions

OpenAI 在 2023 年定義的 chat completions API 核心是這個請求格式：

 1curl http://api.openai.com/v1/chat/completions \
 2  -H "Authorization: Bearer $OPENAI_API_KEY" \
 3  -H "Content-Type: application/json" \
 4  -d '{
 5    "model": "gpt-5",
 6    "messages": [
 7      {"role": "system", "content": "You are a helpful assistant."},
 8      {"role": "user", "content": "寫一個 Python function 計算費氏數列"}
 9    ],
10    "stream": true
11  }'

回應是一連串 server-sent events（SSE、伺服器把回應切成小封包陸續推給 client、而不是等整段算完才一次回）、每個 event 包含一個 token chunk。

本地推論伺服器實作同樣的 endpoint 形狀，只是 host 換成 localhost、API key 不檢查或檢查 dummy 值：

 1curl http://localhost:11434/v1/chat/completions \
 2  -H "Content-Type: application/json" \
 3  -d '{
 4    "model": "gemma4:31b-coding-mtp-bf16",
 5    "messages": [
 6      {"role": "system", "content": "You are a helpful assistant."},
 7      {"role": "user", "content": "寫一個 Python function 計算費氏數列"}
 8    ],
 9    "stream": true
10  }'

差別只有三點：

1. host：從 api.openai.com 換成 localhost:11434。
2. model：從 gpt-5 換成 gemma4:31b-coding-mtp-bf16。
3. Authorization：本地通常不檢查 API key，或接受任意值。

請求與回應的 JSON schema 完全一樣。這就是「OpenAI 相容」的字面意義。

為什麼這個相容性這麼重要

如果沒有 OpenAI 相容 API，每個介面層工具要支援新的伺服器就得寫專屬整合：Continue.dev 要為 Ollama 寫一份、為 LM Studio 寫一份、為 llama.cpp 寫一份、為雲端 OpenAI 寫一份、為 Anthropic 寫一份。每多一個工具就 N×M 的整合成本。

OpenAI 相容把這個成本拆成「介面層支援標準 API 一次 + 伺服器層實作標準 API 一次」、整合工作從 N×M 降到 N+M。後果是新伺服器（如 2024 年才出現的 oMLX）只要實作這份 API、馬上能被既有的所有介面層用上。

這也是為什麼幾乎所有 IDE plugin、CLI 工具、Web UI 都選擇 OpenAI 相容做 first-class citizen。Anthropic 自己的 API 形狀（messages、不同 streaming 格式）反而成為次要選項，介面層工具通常要為 Anthropic 寫額外的 adapter。

接本地 LLM 的最小設定

實際使用上，把任一個介面層工具切到本地 LLM 通常只要改三個欄位：

三個欄位的延伸判讀：API base 改成 localhost:11434 表示請求送到本機 11434 port、不走網路；API key 本地通常不檢查、但介面層工具可能仍要求填一個值才能初始化；Model name 要去伺服器看當前已下載的 model tag、Ollama 用 ollama list 查、LM Studio 在 Discover 分頁查。

接近真實的例子是 Continue.dev 的 config.json：

 1{
 2  "models": [
 3    {
 4      "title": "Gemma 4 31B (local)",
 5      "provider": "ollama",
 6      "model": "gemma4:31b-coding-mtp-bf16",
 7      "apiBase": "http://localhost:11434"
 8    }
 9  ]
10}

Continue.dev 內部會把 provider: ollama 翻成 OpenAI 相容請求送到 apiBase。如果你想用通用 OpenAI provider：

 1{
 2  "models": [
 3    {
 4      "title": "Local LLM (via OpenAI-compatible)",
 5      "provider": "openai",
 6      "model": "gemma4:31b-coding-mtp-bf16",
 7      "apiBase": "http://localhost:11434/v1",
 8      "apiKey": "not-needed"
 9    }
10  ]
11}

兩種寫法都會工作。provider: ollama 多一些 Ollama 特有功能（如 model auto-pull），provider: openai 比較通用、可以接任何 OpenAI 相容伺服器。

「OpenAI 相容」承諾什麼、不承諾什麼

相容承諾的是 API 形狀 —— request schema、response schema、streaming 格式、錯誤碼大致一致。不承諾的是：

1. 模型能力：本地 Gemma 4 31B 跟雲端 GPT-5 都能用同一套 API 呼叫，但回答品質天差地遠。
2. 效能特性：本地的 TTFT、生字速度跟雲端完全不同，介面層感覺不到差別不代表速度一樣。
3. 進階參數：OpenAI 自己的新功能（function calling 進階模式、structured output 強制 JSON 輸出、reasoning effort 控制推理深度等）不一定被本地伺服器完整支援。寫 code 場景常見問題是設定了 tools 參數但本地模型不會主動呼叫。模組四會展開這些進階特性、見 4.3 Tool use 原理。
4. 模型清單：呼叫 GET /v1/models 回的清單、本地是你已下載的模型、雲端是 OpenAI 提供的模型；介面層要把兩邊清單視為各自獨立的資料。

接近真實的意外事件：

• 設定 response_format: { type: "json_object" } 強制 JSON 輸出，本地某些舊模型不認，會直接回普通文字。
• 設定 tool_choice: "required" 強制使用工具，本地許多模型不支援，行為退化成普通對話。
• 設定 seed 想拿確定性輸出，本地伺服器多半實作了，但雲端 OpenAI 並不保證每個 model 都尊重。

陷阱是把「相容」當成「等價」。在依賴進階參數的場景下、寫程式時值得先假設本地伺服器可能不支援最新功能、預先準備降級處理（例如先試 tool_choice: "required"、伺服器忽略時 fallback 到 prompt-based 工具呼叫）。

用 curl 驗證本地 LLM 在跑

啟動 Ollama 並 pull 一個模型後，最快確認它在跑的方式是直接 curl：

1curl http://localhost:11434/v1/chat/completions \
2  -H "Content-Type: application/json" \
3  -d '{
4    "model": "gemma4:e4b",
5    "messages": [{"role": "user", "content": "Say hi in three languages."}],
6    "stream": false
7  }'

如果回的是 JSON 包含 choices[0].message.content，伺服器層正常。介面層連不上的時候，先用這個 curl 確認問題是介面層、伺服器層，還是模型本身。

需要驗證 streaming：

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

正常應該看到一連串 data: {...} 行，每行是一個 token chunk。

多伺服器並存：同時跑 Ollama 與 LM Studio

OpenAI 相容讓你可以同時在同一台 Mac 上跑多個伺服器，只要 port 不撞。常見配置：

Port 衝突的徵兆是啟動伺服器時報 address already in use。用 lsof -i :<port> 找佔用方、確認是舊版伺服器就 pkill -f 終止、或改用其他 port 啟動。詳細的 port 與 listen address 判讀見 Port 與 Localhost 卡片。

Continue.dev 的 config.json 可以同時列多個 model、每個 model 指向不同伺服器、UI 上下拉切換。這個能力讓「主力模型穩定跑、實驗模型隔離測試」變得直接。

不是 OpenAI 相容的本地工具

少數本地工具不走 OpenAI 相容，要特別注意：

1. MLX 原生 Python API：Apple 的 MLX framework 本身是 Python library、不是 HTTP server。需要自己 wrap 或用 mlx_lm.server（次要產品、功能不全）。完整的 MLX / MTP / oMLX 區別見 0.4 章節。
2. 早期 llama.cpp：在 OpenAI 相容前就存在，原生 API 形狀不同；新版加上 /v1/chat/completions 後跟主流相容。
3. 某些研究專案：直接 wrap PyTorch / Transformers，沒有 HTTP 層，要當 library 用。

遇到這類工具時、值得先評估「該不該為它寫 adapter」。判讀訊號：模型唯一性（這個工具是否提供其他伺服器拿不到的模型？）vs 整合成本（寫 adapter 與長期維護的時間投入）。模型唯一性高時值得投資、模型可在主流伺服器找到替代時、選 OpenAI 相容的主流伺服器（Ollama、LM Studio）能省下大量整合成本。

下一章

下一章：0.4 MLX / MTP / oMLX，澄清三個常被混為一談的術語，避開網路上最常見的本地 LLM 認知陷阱。

把這三個分清楚後，看到「MLX 加速 50%」「MTP 整合到 llama.cpp」「oMLX 用上 MTP」這類句子就能精準判讀。本章的責任是把每個術語放回正確的位置，再說明它們如何疊加。

本章目標

讀完本章後，你應該能：

1. 用一句話分別說清楚 MLX、MTP、oMLX 是什麼。
2. 看懂「MLX backend」「啟用 MTP」「用 oMLX 跑」這些句子。
3. 判斷三者組合的可行性與效果。
4. 避開把它們當成競爭關係的常見誤解。

MLX：Apple 的數值運算 framework

MLX 是 Apple 為 Apple Silicon 設計的數值運算 framework、類似 PyTorch 或 JAX 在 Mac 上的對應物（全名 Machine Learning eXchange、2023 年釋出）。它的責任是：

1. 在 CPU、GPU、Neural Engine 之間自動排程運算。
2. 利用統一記憶體（UMA）避免在記憶體層級之間搬資料。
3. 提供 lazy evaluation（延遲計算、把運算累積成圖再一次優化執行）與 graph optimization（自動合併多個運算、減少記憶體 round-trip）、讓相同的 Python 程式碼在 M1 ~ M4 上都能用上各代硬體優勢。
4. 提供 mlx.core、mlx.nn 等 Python API、可以寫訓練 / 推論程式。

MLX 的角色就是「跑神經網路用的底層數值庫」、把 server / 模型 / 加速技巧三個責任都留給上層工具去做。可以類比：

MLX 的角色定位是「basic infrastructure」。要拿 MLX 跑 LLM，你需要：MLX framework + 一份用 MLX 寫的模型實作（如 mlx-lm package）+ 模型權重（MLX format）+ 一個介面（CLI 或 server wrapper）。所有上層工具都站在 MLX 這塊地基上。

接近真實的例子：

1pip install mlx-lm
2mlx_lm.generate --model mlx-community/Llama-3.2-3B-Instruct-4bit --prompt "hi"

這段命令會載入 MLX 格式的模型權重、用 MLX framework 在 Apple Silicon 上跑推論。但這只是 library 等級的呼叫、不是常駐伺服器；要做成 server 還需要再 wrap 一層（例如 mlx_lm.server 或 oMLX）。

常見 MLX 誤用

1. 以為裝 MLX 就有 server：MLX 只是 library、要 expose HTTP API 需要再 wrap 一層（mlx_lm.server、oMLX、或自己用 FastAPI 包）。
2. 以為 MLX 跟 Metal 互斥：MLX 跑在 GPU 上會自動用 Metal、兩者是上下層關係、不是擇一。Metal 是 Apple 的 GPU 加速 API、MLX 是利用 Metal 的高階 framework。
3. 以為 Ollama 用 MLX backend：Ollama 內部用 llama.cpp 配 Metal、跟 MLX 沒關係。看到「Ollama 用 MLX 加速」要追問來源、多半是混淆。

MTP：一種加速技巧

Multi-Token Prediction（MTP）的核心是「一次預測多個 token 的加速技巧」，本質上是 speculative decoding 的工程化實作。它的責任是：

1. 用一個小模型（drafter）快速猜未來 N 個 token。
2. 把這 N 個 token 一次餵給大模型（target），讓大模型並行驗證。
3. 大模型保留它認同的 token 前綴，從第一個拒絕點繼續。

MTP 是跑模型時的演算法層、跟伺服器與模型實作互相正交：任何推論伺服器都可以選擇實作或不實作 MTP、模型可以選擇有沒有官方 drafter、兩件事分離。

Google 為 Gemma 4 釋出官方 drafter 後，MTP 變成 Gemma 4 生態的標準配備。官方數據宣稱 coding 任務 2 ~ 3 倍加速；寫 code 的加速尤其明顯，因為 code 有大量可預測 pattern（縮排、括號、常見變數名），drafter 接受率高。

陷阱有三個：

1. MTP ≠ Gemma 4 限定。任何模型理論上都能用 speculative decoding；只是 Gemma 4 有官方 drafter、現成可用。其他模型要嘛社群自己訓 drafter，要嘛沒有。
2. MTP 不一定加速所有任務。對沒有預測 pattern 的任務（如生成隨機 ID、加密文字），接受率低，反而會拖慢。寫 code 是甜蜜點。
3. 加速倍數受實作品質影響。網路上「MTP 加速 40%」這類來源不明數字常見；Google 官方數據是 2 ~ 3 倍，視任務而定。引用時要追到官方來源。

實作層面、要用 MTP 需要：

• 一個支援 speculative decoding 的伺服器（2026 年 5 月時 Ollama v0.23+ 已支援、LM Studio 跟 oMLX 也支援、llama.cpp 上游 speculative decoding 框架仍 beta）。
• 一個有 drafter 的模型、或自己組合 target + drafter pair。

Ollama 在 2026/5/7 釋出的 v0.23.1 加入 Gemma 4 MTP 一鍵支援：

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

這個 model tag 內含 drafter，伺服器自動啟用 speculative decoding。

oMLX：建在 MLX 上的特化伺服器

oMLX（“optimized MLX server” 的縮寫，2024 年由社群釋出）的核心是「建在 MLX 之上、針對 coding agent 長 context 場景優化的推論伺服器」。它的責任是：

1. 用 MLX 當推論 backend，吃 Apple Silicon 統一記憶體優勢。
2. 提供 OpenAI 相容 HTTP API。
3. paged SSD KV cache：把已 prefill 過的 prompt context 存到 SSD，下次同前綴 prompt 可以直接讀 cache。
4. 支援 speculative decoding 與量化。

oMLX 跟 Ollama 並列同一層（都是推論伺服器），但定位不同：

oMLX 解的是 0.1 為什麼 LLM 生字慢 提到的痛點：當你用 aider 或 Cline 這類 coding agent（用 LLM 自動操作 git / 檔案的 CLI 工具、模組四會展開）、把整個 repo 塞進 prompt 時、本地 LLM 每次都要重新 prefill 10K+ tokens、等 30 ~ 90 秒。oMLX 的 SSD cache 把同前綴 prompt 的 prefill 結果保存下來、下次只 prefill「新增的部分」、TTFT 從幾十秒降到幾秒。

陷阱是把 oMLX 當成「比 Ollama 強的替代品」。它解的是非常特定的痛點；短 prompt code completion 或一般對話場景下、Ollama 的 TTFT 痛點不浮現、oMLX 的 SSD cache 賣點換不到體感、卻要先承擔較高的安裝與維護成本。長 context coding agent 才是 oMLX 的甜蜜點。

三者疊加：實際堆疊長什麼樣

三者不是競爭關係，是堆疊關係。下表是幾種常見組合：

兩個主流堆疊的延伸判讀：

• Ollama + Gemma 4 MTP：成立條件是 Ollama 版本 ≥ v0.23.1（內建 MTP 一鍵支援）、target / drafter 同 family（都是 Gemma 4）。換成 Llama 或 Qwen 系列就要找對應的 drafter 配對、或退回沒 MTP 的版本；2026 年 5 月時 Qwen3-Coder 還沒有官方 drafter。
• oMLX + Gemma 4 MTP：成立條件是有長 context coding agent 工作流（10K+ tokens）、且 Mac 記憶體足夠同時載入 target + drafter（32GB+）。短 context 或一般對話場景、oMLX 的 SSD cache 帶不來體感優勢、改用 Ollama 配同樣 model tag 更省事。

注意三件事：

1. Ollama 預設用 llama.cpp 當 backend，跟 MLX 沒關係。看到「Ollama 用 MLX 加速」這種句子要追問來源，多半是混淆。
2. oMLX 是少數真正把 MLX 用在 server 層的工具；它的賣點不是「MLX」本身，是 SSD KV cache。
3. MTP 是技巧層，可以疊在 Ollama 或 oMLX 上面，跟伺服器選擇正交。

用三層定位判讀新資訊

三層定位的用法是「把每則資訊放回 framework / server / 技巧層、再追問該層的證據」。社群文章在描述這三者時常會混用層級、用這個流程可以快速還原它真正在說什麼。下面是幾個常見句子、加上三層定位重新解析的版本：

「llama.cpp 已整合 Gemma 4 MTP」：要追問版本與時間點。2026 年 5 月時 llama.cpp 上游的 speculative decoding 框架仍 beta、Gemma 4 官方 drafter 整合是 feature request；Ollama 反而在 v0.23.1（2026/5/7）一鍵支援、是少見的「Ollama 領先底層 llama.cpp」情境。Ollama 維護自己的 fork、有時搶先加 patch。

「MTP 加速 40%」：要追問任務與基準。Google 官方數據是 coding 任務 2 ~ 3 倍、其他任務 1.5 ~ 2 倍。「40%」這類數字若沒附上任務、硬體、比較基準、判讀價值有限。回到 Google Gemma 4 技術報告比對原始三變數。

「Ollama 用 MLX 比 llama.cpp 快」：混淆了 framework 層與 server 層。Ollama 內部用 llama.cpp（library 層）當推論引擎、配 Metal backend 接 Apple Silicon GPU。它跟 MLX 是平行的選擇、不是包含關係。想用 MLX 當 backend 要選 oMLX 或自己 wrap mlx-lm。

「oMLX 是 Ollama 的 MLX 版本」：兩者沒有 fork 關係。oMLX 的主要創新是 paged SSD KV cache、解的是長 context window coding agent 的 TTFT 痛點。「換 backend 到 MLX」是另一回事、不是 oMLX 的賣點。

「裝 MLX 就能跑 LLM」：MLX 只是 framework。實際要跑 LLM 還需要模型實作（mlx-lm）+ 模型權重（MLX format）+ 介面（CLI 或 server wrapper）。對寫 code 場景的多數使用者、直接用 Ollama 反而更直接、不用接觸 MLX 細節。

詳細的判讀框架見 0.6 判讀本地 LLM 資訊的五個框架；其中框架一（追溯版本與時間點）、框架二（量化宣稱三變數）、框架三（工具放回三層架構）對本章三個術語的混淆特別有用。

給讀者的選擇順序

寫 code 場景的優先順序：

1. 先裝 Ollama、跑 Gemma 4 31B MTP 或 Qwen3-Coder 30B。MTP 加速包含在 Ollama v0.23.1 內、開箱即用。
2. 用一週後若發現 TTFT 在塞長 context 時體感痛、再評估 oMLX。
3. MLX 本身對寫 code 使用者是抽象層下面的事、多數場景由 Ollama 把 MLX 細節包起來；直接接觸 MLX 的時機是想自己 wrap library 或調試底層 framework。

順序設計的核心是「先解決日常路徑、再針對痛點做特化」。先鑽 MLX 細節或安裝 oMLX、會在還沒驗證痛點存在時就承擔額外的學習與維護成本。

下一章

下一章：0.5 Apple Silicon 記憶體預算、把心智模型對到自己 Mac 的真實規格。

Apple Silicon Mac 跑本地 LLM 的核心限制是記憶體大小、而非 CPU 或 GPU 算力。記憶體決定能載入多大的模型；模型載得進、推論才有得跑（生字速度則由 memory bandwidth 決定、見 0.1）。本章把「24GB 能跑 70B」這類含糊說法、換成可操作的記憶體預算判讀。

讀完本章後，你可以對自己這台 Mac 直接回答：能跑哪些模型、要用什麼量化、要留多少給系統、風扇會不會狂轉、什麼時候該升級。

本章目標

讀完本章後，你應該能：

1. 看 Mac 規格立刻知道能跑哪一級的模型。
2. 理解量化等級跟模型大小的乘積為何決定可行性。
3. 為「給系統留多少記憶體」這件事設一個合理上界。
4. 判斷自己這台 Mac 適不適合跑本地 LLM。

記憶體預算的基本算式

跑本地 LLM 的記憶體預算大致拆成三塊：

1總記憶體 = 系統與其他 app（保留）+ 模型權重 + KV cache + 推論中間結果

各塊的估算原則：

1. 系統與其他 app：至少留 8GB 給 macOS、VS Code、瀏覽器與其他工作流程。重度多工建議留 10 ~ 12GB。
2. 模型權重：用「參數規模 × 每權重 bits / 8」算出 bytes。其中「Q4」代表每個權重佔 4 bits。例如 31B 模型 Q4 量化 = 31 × 4 / 8 = 15.5 GB、加上 metadata 與 overhead 約 16 ~ 18GB。
3. KV cache：跟 context 長度成正比。短 context（< 2K tokens）約 0.5 ~ 1GB、長 context（10K+ tokens）可能超過 5GB。
4. 推論中間結果：通常 1 ~ 2GB。

實際留給模型的可用記憶體 = 總記憶體 − 系統保留（8GB）− KV cache（2 ~ 5GB）− 推論 overhead（2GB）。

Mac 記憶體與可運作模型對照

下表是 2026 年 5 月、Apple Silicon Mac 在 Q4 量化下的可運作模型對照。預設 Q4 是因為它是 31B 等級寫 code 場景的甜蜜點、下節「為什麼 32GB 是寫 code 場景的甜蜜點」會展開原因。所有體感標籤都假設「主要用途是寫 code」、純文字對話的甜蜜點會往較小模型偏。

讀這張表要注意四件事：

1. 體感是 coding 場景。純對話、寫文章、解釋程式的記憶體門檻較低。
2. 量化等級可以調整。32GB 跑 31B Q4 順暢、跑 31B Q5 也行（吃 21GB 左右）；跑 70B Q3 會崩潰，因為 70B Q3 約 26GB，加上 KV cache 跟系統，超過 32GB。
3. fanless 機種要打折。MacBook Air 系列因為散熱被動，跑大型模型 5 分鐘後會降頻，實際生字速度比有風扇的同代機器低 30 ~ 50%。
4. 記憶體不是 SSD。Apple Silicon 的「統一記憶體」是 RAM、不是 SSD swap。雖然 macOS 會 swap、但 swap 後生字速度會慢一個量級以上、實質喪失互動可用性。

MoE 與 dense 模型在記憶體預算上的差異

Mixture of Experts（MoE） 模型跟 dense 模型的記憶體 / 速度判讀方式不同、Gemma 4 26B A4B 這類 MoE 模型在上表「24GB Mac」一格出現時、容易讓人誤以為跟 14B dense 同等的記憶體需求。實際差異：

判讀重點：MoE 的記憶體需求看「總參數」、但速度看「啟用參數」。同記憶體預算下 MoE 通常跑得比 dense 快、但能力強度比較需配合具體 benchmark 判讀、名義參數僅作初步篩選。PC 獨立 GPU 上的 MoE 部署策略（CPU 卸載專家層）見 MoE CPU 卸載卡片。

為什麼 32GB 是寫 code 場景的甜蜜點

32GB Mac 跑 Gemma 4 31B（Q4 + MTP）是 2026 年 5 月寫 code 場景最佳的價格效能比，原因是三個趨勢的交會：

1. 31B 模型剛好能力夠用。Gemma 4 31B / Qwen3-Coder 30B 在 SWE-bench 等 coding benchmark 上的表現大幅超越 14B 模型，接近 GPT-4 mini 等級。14B 等級的模型在跨檔案任務上仍經常失誤。
2. Q4 量化在 31B 上的品質衰減仍可接受。Q4 在 7B 模型上品質衰減明顯，但 31B 模型有「參數冗餘」，Q4 反而是甜蜜點。
3. 32GB 剛好夠 18GB 模型 + 8GB 系統 + 6GB 其他。再小（24GB）跑 31B Q4 會吃緊；再大（48GB）邊際效益降低，除非要跑 70B。

對應的 Mac 機型（2026 年 5 月可購）：

• MacBook Pro 14 / 16 with M4 Pro / Max，32GB 配置。
• Mac mini M4 Pro，32GB 配置（最便宜的進入點）。
• Mac Studio M4 Max，32GB 起跳。

如果你正準備買新 Mac 主要為了跑本地 LLM 寫 code、32GB 在 [預算敏感、單機、Gemma 4 31B 為主] 通常是最划算的起點。16GB 在 [>14B 模型 / 多工] 會被擠到 swap、48GB+ 在純寫 code 場景超過甜蜜點、但對 [長 context coding agent / 70B 模型] 仍有實際價值。

16GB Mac 的可行策略

16GB Mac 是現實上的最小可用配置。能跑的最大實用模型是 Gemma 4 E4B（Google 的 8B 級實驗版本）或 Qwen3 7B。體感上：

1. 同時開 VS Code + Chrome + Slack 跟跑模型會擠到 swap、整台 Mac 變慢；建議跑模型時關掉其他重度 app。
2. 模型品質明顯弱於 31B 等級。簡單 function 補完還行、跨檔案重構交給雲端旗艦更划算。
3. 適合「偶爾用本地、主要還是雲端」的混用策略。

如果你的 Mac 是 16GB，先用 Gemma 4 E4B 試試看，評估自己工作流是否真的需要本地 LLM。多數情況下答案是「雲端 API 月費比換 Mac 便宜」。

KV cache 與長 context 的記憶體陷阱

模型權重佔的記憶體是固定的，但 KV cache 隨 context 長度線性增加。長 context 場景的記憶體陷阱常被忽略。

接近真實的估算（Gemma 4 31B、Q4 量化）：

陷阱是把 context 長度設到模型支援的上限（如 32K、128K）卻沒算 KV cache 成本。32GB Mac 跑 31B 模型，實際可用 context 大約只有 8 ~ 16K tokens；超過就會 swap，速度崩潰。

解法：

1. 短 prompt 場景（compact code completion）：完全沒問題，多數設定都在 2K 以下。
2. 中等 context（4 ~ 16K）：32GB Mac 仍可運作，但要留意 KV cache 吃多少。
3. 長 context（16K+）：考慮 oMLX 的 paged SSD KV cache（把 KV cache 部分頁面換出到 SSD、換取較長 context、代價是 TTFT 與生字速度略增）。詳見 0.4 MLX / MTP / oMLX。

風扇、發熱與降頻

Apple Silicon Mac 跑本地 LLM 會持續滿載 CPU / GPU。實際體感：

對「全天候用本地 LLM」的工作流，桌機型（Mac mini、Studio）比筆電好。筆電上跑長時間推論還要考慮電池與發熱對手部舒適度的影響。

按情境選機型決策表

決策表把前面三個變數（手上預算 / 想跑的 model size / 主要用途）摺成一張快查、依情境定位、不需要重新讀整章。詳細的模型選型考慮見 1.4 模型選型優先順序。

陷阱是把 96GB+ 配置當成「未來證明」。模型架構演進可能讓現在的記憶體預算明年就不重要（例如 1-bit 量化、新的稀疏架構）。買超大記憶體前先確認有具體現有需求支撐；「以後可能跑得到 100B+ 模型」這類期待風險很高。

下一章

下一章：0.6 判讀本地 LLM 資訊的五個框架、把心智模型轉成判讀資訊的反射。

本章把前面五章的概念整理成五個判讀框架。每個框架對應一類常見資訊問題、給讀者一組可重複套用的提問清單。讀完後你會建立一個反射：看到 LLM 相關內容時、自動跑過這些框架、確認資訊夠不夠扎實再吸收。

本章目標

讀完本章後，你應該能：

1. 看到「N 倍加速」「能跑 X 大小模型」這類量化宣稱時、知道要追問哪些變數。
2. 看到「X 工具支援 Y 功能」時、知道怎麼確認時間點與版本。
3. 把工具放回三層架構、辨識「framework vs 伺服器 vs 模型」的混淆。
4. 區分「載得進記憶體」跟「實際好用」是兩件事。
5. 把「隱私」從「位置」改成「資料流」來思考。

框架一：追溯版本與時間點

本地 LLM 工具的功能支援會隨版本變化。同一句「X 工具支援 Y 功能」可能 2025 年成立、2026 年版本改了、或反過來。判讀任一則「支援 / 整合 / 加入」的宣稱、第一步是確認版本與時間點。

這個框架解什麼問題

社群文章常省略版本資訊。「llama.cpp 加入 Gemma 4 MTP」這類句子若沒附上日期或版本號、就有三種可能：上游確實已合入、是某個 fork（從主 repo 分支出去的獨立版本）加的 patch（補丁修改）、或是社群討論的願景。三種狀態下「該怎麼用」的答案完全不同。

怎麼套用

看到「X 工具支援 / 整合 / 加入 Y」時、按順序問：

1. 版本與日期：在哪個版本加入？發布日期是？
2. 支援程度：是 GA（一般可用）、beta、實驗性、還是 fork 上的 patch？
3. 官方確認：是否在 release notes / changelog / 官方文件提到？

確認來源的最快路徑：

實際情境

2026 年 5 月的具體狀態：Ollama v0.23.1（2026/5/7 釋出）一鍵支援 Gemma 4 MTP；llama.cpp 上游的 speculative decoding 框架仍 beta、Gemma 4 官方 drafter 整合是 feature request。同一個功能在兩個工具的狀態差很多、發表時間決定誰領先。

這個案例的啟示是「Ollama 用 llama.cpp 當底層」這件事、跟「新功能必定先在 llama.cpp 出現」是兩件事。Ollama 維護自己的 fork 加 patch、有時搶先支援上游還沒接受的功能。看資訊時要明確區分。

框架二：量化宣稱的三個變數

任何「N 倍加速」「快 X%」「達到 Y 分」的數字、都至少受三個變數影響：任務類型、比較基準、執行硬體。三個變數沒給齊時、跨情境比較會失準、把數字搬到自己場景常常對不上。

這個框架解什麼問題

「MTP 加速 3 倍」這個句子省略了「在 coding 任務上、跟沒開 MTP 比、用 M4 Max 跑」這三個前提。同樣的 MTP 在創意寫作上加速可能只有 1.5 倍、在 M2 Pro 上絕對數字小很多。讀者拿到「3 倍」這個數字、放到自己的場景常常對不上。

怎麼套用

看到量化宣稱時、回到下面三個維度確認：

實際情境

MTP 的官方數據是「coding 任務 2 ~ 3 倍加速、其他任務 1.5 ~ 2 倍」。社群文章可能引用成「40% 加速」、這個數字若沒附上前提、無法判斷代表什麼任務或什麼硬體。回到 Google 官方技術報告比對、能還原原始三變數。

SWE-bench 的「77.2 分」也一樣：是 SWE-bench Verified（OpenAI 篩選過的子集）、還是 SWE-bench Lite 或 Full？變體間分數差很多、混為一談會誤判模型強弱。

自己驗證的最穩做法

公開 benchmark 是參考、不是結論。挑你日常工作流的 5 ~ 10 個真實任務當私人 benchmark、跑本地模型看通過率。這個方法繞過所有變數爭議、給你能用在自己場景的數字。

框架三：工具放回三層架構

LLM 生態的工具屬於介面層、推論伺服器層、模型層。各層之間用標準介面（OpenAI 相容 API、GGUF 等）連接、各自可獨立替換。判讀工具相關資訊時、先確認它屬於哪一層、再評估宣稱。

這個框架解什麼問題

工具名稱常被當成跨層通用詞。「Ollama 很快」「MLX 比 llama.cpp 強」「oMLX 是 Ollama 的 MLX 版」這類句子各自混淆了不同層：Ollama 是推論伺服器、MLX 是 framework、llama.cpp 同時是 library 跟 server、oMLX 是另一個推論伺服器。混淆層級的句子讀起來像在比較、實際上比較的對象不在同一層。

怎麼套用

看到工具被比較或描述時、按下表分類：

實際情境

「Ollama 用 MLX 加速」這個句子若按本框架追問：Ollama 內部用 llama.cpp（library 層）當推論引擎、用 Metal backend 接 Apple Silicon 的 GPU。它跟 MLX 是平行的選擇、不是包含關係。要用 MLX 當 backend 要選 oMLX 或自己用 Python 把 mlx-lm 包成 server。「Ollama 用 MLX」混淆了 framework 層與 server 層。

「oMLX 比 Ollama 強」這類句子也要拆：oMLX 主要創新是 paged SSD KV cache、解的是長 context 場景的 TTFT 痛點。對短 prompt 場景、Ollama 跟 oMLX 速度差不多；對長 context 場景、oMLX 有針對性優勢。直接說「強」會丟失情境。

框架四：載得進 vs 實際好用

「能載入記憶體」跟「實際好用」是兩件事。看到「Mac 跑得起 X 模型」的截圖時、要追問體感速度與資源佔用、而非只看「啟動成功」。

這個框架解什麼問題

把模型載入記憶體（模型權重 + KV cache + 系統保留）只是第一步。實際使用要看：生字速度體感如何、首字延遲多久、整台 Mac 其他工作是否變慢、長時間用會不會降頻。一張截圖只證明「載入成功」、跟「能日常用」是不同層次的問題。

怎麼套用

看到「我在 Mac 上跑 X 模型」的報告時、按下表追問：

實際情境

16GB Mac「跑得起」31B 模型的截圖、實際多半是：模型剛載入時看起來能用、但系統正在 swap、生字速度掉到 1 ~ 2 tok/s、其他 app 全部變慢、整台 Mac 像泡在糖漿裡。這個狀態下「跑起來」的結論成立、「日常使用」的結論不成立。

換更激進量化（Q3）來塞更大模型也踩同樣的陷阱。Q3 70B 在 24GB Mac 上勉強載入、但 coding 任務表現常輸給同硬體的 Q5 14B 模型；衰減的判讀訊號是「同任務通過率比未量化版本低 30% 以上」「hallucination 明顯上升（編造 API、忽略 prompt 約束）」、出現這些訊號就回頭重新評估量化等級。

判讀「我跑得起來」這類報告時、把上表五個指標都問一遍、才能還原真實體感。

框架五：隱私是資料流、不是位置

本地推論伺服器把 prompt 留在自己機器上、是隱私光譜的起點、不是終點。完整評估隱私要追資料流：prompt 從你按下 Enter 開始、經過哪些 process、儲存在哪、最終會不會以任何形式離開機器。

這個框架解什麼問題

「跑在本地、所以絕對私密」這個結論預設「位置」是隱私的唯一變數、但實際隱私風險來自整條資料流。同樣是「本地 LLM」、不同配置的隱私邊界可以差很多。

怎麼套用

把你的 LLM 使用環境畫成資料流圖、列出 prompt 經過的每個節點：

 1你打字
 2  ↓
 3IDE / 介面層工具（Continue.dev、Cursor、Open WebUI）
 4  ↓ 經過 OpenAI 相容 API
 5本地推論伺服器（Ollama 等）
 6  ↓
 7模型權重 + KV cache 在記憶體
 8  ↓
 9回應顯示在 IDE
10  ↓
11（可能）對話紀錄存到 SQLite / 雲端同步 / 第三方 telemetry

每個節點問一次：

實際情境

寫 NDA 客戶 code 時、即使用 Ollama 跑本地 LLM、若同時開著「自動同步 VS Code 設定到雲端」「Open WebUI 對話歷史備份到 iCloud」、prompt 仍可能間接外洩。Cursor 等 IDE 預設可能送 telemetry（含 prompt 片段）給自家服務；用 Cursor 接本地 Ollama 跟用 Continue.dev 接本地 Ollama 的隱私邊界不同。

把 OLLAMA_HOST=0.0.0.0 開出去（讓區網其他機器連）也常被忽略。家用網路風險低、公共 Wi-Fi 在沒設防火牆規則的情況下、本地 LLM 等同暴露給整個網段。預設值是 127.0.0.1、改動前先確認場景。

雲端 LLM 也提供 zero-retention 與「不訓練」選項（企業方案、API 預設等），多數合規場景能滿足。本地的隱私優勢在「物理上資料留在機器」、雲端的隱私保證來自合約與技術控制；兩條路在隱私光譜上各占一段、按實際需求挑。

把五個框架當反射

下表把五個框架壓成一張快速查表、看新資訊時對照：

五個框架彼此互補、不互斥。一則複雜資訊常需要同時跑兩三個框架才能完整評估。例如「16GB Mac 跑 70B Q3 模型很順、達到 GPT-4 等級」這句話、要同時跑框架二（達到 GPT-4 是什麼任務上的測試？）、框架四（生字速度多少？整台 Mac 還能用嗎？）、框架三（70B Q3 跟 GPT-4 不在同一層、有點混）。三個框架都跑過、就能還原原始宣稱的真實價值。

框架的邊界：何時可以省略

五個框架是預設掃描清單、但不是每個情境都要五個一起跑。下表是「該框架不適用」的判讀：

判讀原則：框架不適用於「該維度根本不存在」的情境。寧可多跑一個框架、覆蓋率優先 — 跑了發現不適用比漏掉某維度風險小。

框架是工具、不是教條

跑這些框架的目的是「拿到能用在自己場景的判讀」、不是「找出每篇文章的錯」。多數作者寫東西時省略前提、是為了文章流暢、未必是有意誤導。把框架當成補完前提的工具：看到不完整的句子、自己補上「在什麼任務、什麼硬體、什麼版本」的脈絡、就能還原作者想表達的事。

對自己也用同一套標準。寫筆記、發推文、回答同事問題時、附上版本與硬體脈絡、能讓資訊更耐保存、半年後自己回看也仍能讀懂。

下一步

下一步：模組一 本地 LLM 服務的安裝與應用、把概念落地到實際安裝、整合 VS Code、選模型、做期望管理。

本章寫的是「無論工具怎麼演變、隱私設計都該這樣思考」的原理層。具體合規法規條文（GDPR、HIPAA、各地新法）、特定工具的 telemetry 設定（每家半年一變）不在本章——這些隨時間變、用本章建立的 framework 重新評估就好。本章是 framing；落地操作見 模組六 本地 LLM 的安全與權限、把這些框架拆到推論伺服器綁定、tool use 權限、prompt injection、跨雲端邊界等具體決策。

本章目標

讀完本章後、你應該能：

1. 用資料流圖描述自己的 LLM 工作流、辨識每個 hop 的信任邊界。
2. 區分「物理保證」與「合約保證」兩種隱私模型的取捨。
3. 把零信任原則套用到 LLM 系統設計。
4. 對 NDA / 企業合規場景做出有條理的判讀、不只看「是否本地」。

從「位置 Thinking」到「資料流 Thinking」

「跑在本地、所以隱私」這個直覺假設「位置」是隱私的唯一變數。實際上隱私風險來自整條資料流的每個節點、位置只是其中一個維度。

把問題從「我的 prompt 是否離開機器」改成「我的 prompt 從打字到最終結果、經過哪些 process、儲存在哪、誰能看到」。後者覆蓋面廣得多：

• prompt 在 IDE 內被 cache？
• IDE 有沒有開雲端同步？
• 推論伺服器 log 留多久？
• 對話歷史存到哪？
• 第三方 plugin 有沒有偷 access prompt？
• 結果寫到磁碟後、有沒有被自動備份到 iCloud / Dropbox？

「位置 thinking」對所有這些都看不到——只要推論在本地就覺得安全。「資料流 thinking」把整條 hop 攤開、每個節點單獨評估。

這個 shift 是隱私設計的根本前提。沒做這個 shift、其他設計都建立在錯誤假設上。

信任邊界的定義

LLM 工作流通常跨多層信任邊界（IDE / 推論伺服器 / 雲端同步 / 第三方 plugin / LAN）、隱私設計的第一步是把這些邊界明確畫出來。信任邊界（trust boundary）的概念來自系統安全設計：「誰能看到什麼資料」的明確分隔。穿越邊界的資料需要明確的授權跟稽核；同邊界內的資料假設安全。

本地推論的天然信任邊界是「我的 Mac」——資料在這個邊界內預設安全（除非機器本身被入侵）。但實際 LLM 工作流會穿透這個邊界：

• 雲端同步穿透：VS Code 同步 settings、Notion 備份對話、iCloud 同步文件——資料從 Mac 走到雲、信任邊界被擴展到供應商。
• Telemetry 穿透：IDE plugin、推論伺服器、作業系統都可能送遙測資料、含 prompt 片段 / metadata。
• 第三方 plugin 穿透：裝的 VS Code extension、瀏覽器 plugin 都可能 access 同個 prompt context。
• 網路 expose 穿透：OLLAMA_HOST=0.0.0.0 把本地伺服器暴露到 LAN、信任邊界從「我的 Mac」擴展到「整個區網」。

LLM 工作流通常有多層信任邊界、跟「我在本地跑」的單純直覺不一定一致。設計隱私時、先把所有信任邊界畫出來、再評估每個邊界的「誰能看到、能看到什麼」。

信任邊界的判讀問題：

• 這個 process 屬於哪個邊界內？
• 跨邊界傳資料需要什麼授權？
• 邊界外的 component 如果被入侵、能 access 到什麼？

這幾個問題答得清楚、隱私設計就有 ground truth；答得模糊、設計就建立在假設上。

本地 vs 雲端的合約模型

本地推論跟雲端推論的隱私保證來自不同模型：

物理保證（本地）

本地推論的隱私保證是「物理上資料留在這台機器」、可技術觀察：

• 用 lsof（list open files、看 process 持有的網路 socket）看推論伺服器的網路連線、確認沒對外送資料。
• 用 tcpdump（系統封包擷取工具）監聽流量、確認 prompt 沒外洩。
• 看磁碟 IO、確認對話歷史沒被寫到雲端同步資料夾。

這些工具的能力邊界：lsof / tcpdump 給的是「常態流量觀察」、不是完整安全證明。編譯期注入、kernel-level exfiltration、DNS tunneling 等繞過手法仍可能規避這些觀察視角。國家級威脅模型或高 stakes 合規場景下、要再加程式碼簽章驗證、SELinux / EndpointSecurity policy、出口防火牆等更深的控制；個人 / 中小企業場景下、這三個工具的觀察通常足以建立日常的信心。

物理保證的特性：

• 可單機驗證：不需要信任供應商、能用本地工具觀察流量。
• 能力上限受硬體限制：本地模型受 Mac 算力跟記憶體限制、能力比雲端旗艦低一個量級。
• 不依賴合約承諾：供應商有沒有承諾「不訓練」「zero-retention」都跟本地推論無關——資料本來就沒去那裡。

合約保證（雲端）

雲端推論的隱私保證是「供應商承諾不留資料、不訓練、合規 X 規範」、技術上單機不可驗證、靠合約與 audit 支撐：

• Anthropic、OpenAI 的企業方案明示 zero-retention、不訓練選項（2026 年 5 月當時的 ToS、雲端 ToS 半年一變、實際採用前以最新版為準）。
• SOC 2、ISO 27001、HIPAA BAA 等合規認證提供第三方 audit。
• 供應商的 ToS / privacy policy 是法律承諾、違反可訴訟。

合約保證的特性：

• 不可單機驗證：要信任供應商沒違反承諾、加上第三方 audit 補強。
• 能力沒上限：能用上雲端最強模型（GPT-5、Claude Sonnet 4.6、Opus）、沒有硬體限制。
• 受法律管轄影響：供應商所在管轄區的法律、未來變動會影響保證強度（如政府要求供應商交資料）。

兩種模型的取捨

兩種模型不是「誰比較好」、是「在什麼情境下哪個適合」：

• 隱私要求極高 + 模型能力夠用：本地。物理保證可驗證、不需信任供應商。
• 能力要求極高 + 隱私要求中等：雲端 + 合約保證。Claude / GPT 旗艦的能力本地短期內追不上。
• 合規場景：看具體規範要求。HIPAA、PCI-DSS 等場景雲端 + BAA / DPA 合約 + technical control 是主流方案、不一定要本地。
• NDA + 客戶明示不得送雲：本地是預設、合約保證對「不得送雲」這條沒幫助。

判讀「該選哪邊」不是 binary、是 spectrum：許多場景混用、敏感任務本地、需要能力的任務雲端 + 合約保證。混用模式有一個隱形 leak 風險：同一個 IDE 同時接本地與雲端 backend、prompt routing 設錯就會把該走本地的內容送到雲端。實作時要明確隔離（不同 workspace / 不同帳號 / 不同 plugin set）、用配置強制路由、而非依賴每次手動切換。Continue.dev 多 provider 設定的具體路由判讀見 6.4 跨雲端 / 本地的資料邊界。

零信任原則套用到 LLM 工作流

零信任（zero trust）的核心是「不假設任何 component 是 trusted、每個 hop 都重新驗證」。傳統信任模型假設「邊界內安全」、零信任假設「邊界本身可能被穿透」、每次 access 都驗證。

套用到 LLM 工作流的具體實踐：

不信任預設配置

每個 component 的預設配置往往不是「最隱私」、是「最方便」。OLLAMA_HOST 預設 127.0.0.1 還算安全、但很多工具預設打開 telemetry、預設同步到雲端。在 NDA / 合規場景下、所有 component 的隱私相關設定通常需要逐項 review、預設值會根據場景調整。

每個 hop 都評估

不只是「我用 Ollama 所以隱私」、要評估從打字到結果的每個 hop：IDE telemetry、plugin 行為、推論伺服器 log、對話歷史儲存、檔案系統位置、雲端同步範圍。任何一個 hop 預設設定「外洩」、整條鏈的隱私就破。

最小權限

每個 component 只給它必要的 access：

• 推論伺服器：不需要存 prompt 歷史就關 log。
• IDE plugin：不裝沒驗證的 third-party plugin。
• 雲端同步：個人場景白名單同步是低成本 default、NDA / 合規場景直接排除整個 LLM 相關目錄。

「最小權限」需要主動設計、不會自動發生——預設都是「方便優先」。

認假設、不認直覺

「跑在本地所以安全」是直覺、不是已驗證的事實。零信任要求每個假設都跑一次 audit 確認、用觀察取代感覺。

資料流分析的具體做法

把抽象原則落地、要做資料流分析：把整個工作流畫成 graph、每個 node 是 process、每個 edge 是資料流動、標示資料類型跟流向。

具體步驟：

1. 列出所有節點：使用者、IDE、IDE plugin、推論伺服器、模型、磁碟、雲端服務、第三方 service。
2. 畫出所有 edge：誰送資料給誰、什麼類型的資料、什麼觸發。
3. 標示信任邊界：哪些節點屬同一個邊界、邊界之間的 edge 標出來。
4. 每個跨邊界 edge 評估三個問題：
   • 誰能看到流過這條 edge 的資料？
   • 儲存多久？
   • 會不會再轉送出去？
5. 找出風險集中點：常見集中點是 IDE telemetry、雲端同步、第三方 plugin。

這個分析做完、隱私風險不再是抽象的「會不會洩漏」、是具體的「哪個 edge 在洩漏什麼」。修補策略也跟著具體：關 telemetry、移除特定 plugin、改設定。

實務做這個分析、第一次通常會發現預期外的 edge——例如「我以為對話歷史只在本地、結果發現 IDE 的 sync settings 把它送到雲」、「我以為這個 plugin 只 access code、結果它也送 prompt 給自家 analytics」。

NDA / 企業合規場景的判讀框架

NDA 跟企業合規場景的隱私要求比個人使用嚴格、判讀方式：

NDA 場景

• 核心要求：客戶明示「不得送第三方 AI 服務」、本地是預設選擇。
• 不夠的地方：本地推論只保證模型呼叫不出去、要 audit 整條資料流（IDE telemetry、雲端同步、plugin 行為）。
• 常見的事故：以為 Ollama 跑就安全、但 Cursor / Copilot 同時開著還送 prompt 給自家 service、NDA 已穿透。
• 強化做法：NDA 客戶程式碼專案開獨立 IDE workspace、停雲端同步、移除第三方 plugin、明確隔離。

企業合規場景

不同規範保護的核心點不同、每條規範需對應到該規範要求的 control、避免用單一 mitigation 一網打盡的做法：

判讀流程：列合規要求 → 對應資料流節點 → 找出缺哪個保護 → 補上技術或合約控制。本地推論滿足「資料留在內部」這條、但通常仍需要 audit log、access control、retention policy 等補強；雲端 + BAA / DPA + zero-retention 是另一條合規路徑、看規範允許哪條再做選擇。

個人 + 一般工作場景

• 多數場景隱私風險中等、合理控制就夠。
• 預設關掉明顯外洩管道（telemetry、雲端同步敏感內容）、敏感任務本地、其他雲端、就 cover 90% 場景。
• 過度設計反而生產力大幅下降、得不償失。

判讀框架的核心不是「該不該做隱私」、是「該做到什麼程度」。NDA / 合規場景要做到嚴、個人場景做到合理、過度都是浪費。

常見的隱私邊界穿透

下列五個穿透模式都符合「位置看似安全、資料流卻外洩」的 pattern、即使用本地推論仍會破隱私：

IDE 雲端同步

VS Code、JetBrains 系列預設可能開 settings sync、把對話歷史、recent files、command history 同步到雲。對話歷史尤其敏感——可能含 prompt 跟 LLM 回應全文。

判讀訊號：登入帳號後、跨機器 settings 自動同步——這條 pipe 通常也帶其他資料。

緩解：明確查看 sync 範圍、敏感場景關閉 sync 或開選擇性 sync（只同步配置、不同步歷史）。

第三方 plugin 偷送 prompt

裝 VS Code extension 時、權限模型較寬：理論上 plugin 能 access 整個 workspace、含 prompt 跟 LLM 回應。多數 plugin 安全、但供應鏈攻擊或惡意 plugin 存在。

判讀訊號：plugin 不是 verified publisher、下載量少、permission 列表廣。

緩解：敏感場景只用 verified plugin、定期 audit 已裝 plugin、移除不必要的。完整 tool use / MCP server 信任邊界見 6.2 tool use 與 MCP server 的權限模型、IDE 場景的 prompt injection 攻擊面（codebase / 外部文件 / 剪貼簿）見 6.3。

Open WebUI 對話歷史備份

Open WebUI（常見的本地 Web 對話介面、通常以 Docker 部署）把對話歷史存本機 SQLite、預設安全。但很多人把 ~/.openwebui 放在 Dropbox / iCloud 同步目錄、歷史間接同步到雲。

判讀訊號：home directory 整個被雲端服務同步。

緩解：明確排除 LLM 相關目錄、或把 LLM 資料移到不被同步的位置。

OLLAMA_HOST=0.0.0.0 暴露區網

把 Ollama 從 127.0.0.1 改成 0.0.0.0 是常見配置（讓區網其他機器接）、但等於把本地 LLM 暴露在 LAN 上。風險視 LAN trust level 而定：純自家信任裝置的家用網路風險低、有 IoT / 訪客機 / 公共 Wi-Fi 的 LAN 環境風險顯著上升（IoT 裝置常被植入、預設要放在 untrusted segment、用 VLAN 或 firewall 隔離後再評估能否互通）。

判讀訊號：能從另一台機器 curl <你的 Mac IP>:11434 成功。

緩解：純自家信任裝置的 LAN 接受、混合 trust LAN 用防火牆規則限定 source IP、公共 Wi-Fi 改回 127.0.0.1 或用 SSH tunnel 隧道到遠端機器。完整綁定模式（loopback / LAN / reverse proxy + auth）跟誤開放後的後果見 6.1 推論伺服器的綁定與暴露範圍。

IDE Plugin 同時送雲

Cursor 預設 telemetry 強、Copilot 本來就送 prompt 給 GitHub。即使在這些 IDE 內用 Continue.dev 接本地 Ollama、IDE 本身可能仍送 prompt 給自家 service。

判讀訊號：IDE 是「雲端 AI 為主」的工具、本地 LLM 接入只是附加功能。

緩解：敏感場景用「本地 AI 為主」的 IDE（如 VS Code + Continue.dev）、不用混合的雲端 IDE。跨 provider 切換的具體 routing 設計見 6.4 跨雲端 / 本地的資料邊界。

何時過時 / 何時不過時

不會過時的部分：

• 「資料流 thinking」對「位置 thinking」的優越性。
• 信任邊界的定義跟畫法。
• 物理保證 vs 合約保證的雙模型 framing。
• 零信任原則的四個套用實踐。
• 資料流分析的 5 步驟方法。
• NDA / 合規 / 個人三類場景的判讀框架。

會變的部分：

• 具體合規法規（GDPR、HIPAA、CCPA、各國新法會持續更新）。
• 特定工具的隱私行為（IDE / 雲端服務的 ToS、telemetry policy 會調整）。
• 雲端供應商的合約細節（BAA / DPA / SCC 條款會 evolve）。
• 「常見穿透模式」的具體例子（會隨工具生態變）。

新工具、新法規、新雲端服務出來時、回到本章的方法重新跑一遍資料流分析、信任邊界評估——framework 不變、實例更新。

下一步

下一步：模組一：本地 LLM 服務的安裝與應用（Apple Silicon Mac）或 模組五：Windows / Linux + 獨立 GPU 把心智模型落到實際操作。模組一 / 五跑穩之後、回到 模組六：本地 LLM 的安全與權限 把本章建立的「資料流 thinking」「信任邊界」「物理 vs 合約保證」三組框架落到具體決策（伺服器綁定、tool use 權限、prompt injection、跨雲端 routing）。

這個位移影響的不只是「在某段程式裡呼叫 LLM」、而是整套設計思維：怎麼處理資料、怎麼定義「正確」、怎麼分解任務、怎麼版本控制、怎麼測試、怎麼除錯。本章把這個典範位移寫成跨應用都成立的心智模型、讓你在後續模組（特別是 模組四 LLM 應用層）讀到 RAG、agent、workflow pattern 時、知道自己在跟哪個典範打交道、該套哪一邊的設計直覺。

本章目標

讀完本章後你能：

1. 區分一段程式碼是 deterministic 還是 fuzzy。
2. 列出兩個典範在四個維度（資料、邏輯、分解、實驗成本）的差異。
3. 判斷一個系統的哪段該 deterministic、哪段該 fuzzy。
4. 設計 fuzzy 邊界的 guardrail（schema / validator / HITL）。
5. 看到一個失敗案例、能定位是「典範用錯」還是「實作問題」。

兩個典範的對照

這張表是後續所有判讀的骨架。看到一段程式時、用這幾個維度自問「這段在哪個典範」、設計直覺自然分開。

為什麼這個位移是典範級、不是只是換工具

很多人把 LLM 當「多了一個 API」、結果是把 LLM 塞進 deterministic 設計框架裡、然後因為它「不夠 deterministic」而 frustrated。這個 framing 錯了。LLM 不是 deterministic 工具的下一代、是另一條工具線、需要另一套設計直覺。

幾個容易踩的混淆：

• 把 LLM 行為當 bug 修：模型輸出不穩定、想用更多 if 把它「夾」回固定行為。這條路會走到死巷——當 prompt 越夾越窄、模型反而開始失去原有能力。正確方向是讓邊界本身可以容忍變化（schema validation + retry、distribution metric、HITL）。
• 用 deterministic 的 test 思維測 LLM：寫了一個「input X 應該得到 output Y」的單元測試、期望 byte-exact match。LLM 行為是分佈、即使 temperature=0、prompt brittleness 也讓單次測試結果不穩。Fuzzy 系統的測試是「在 N 次採樣中、output 落在期望範圍內的比例」、或「分佈級別 metric」、不是「精確等於某 string」。
• 用 deterministic 的 code review 審 LLM-generated code：要求 generated code 完全符合 style guide、結果耗在 nitpick 而不是行為正確性。LLM 生成是 fuzzy 過程、review 焦點該是「功能對 + 安全 + 可讀」、style 交給 linter / formatter 後處理。

典範位移的真正意涵：設計時就承認 fuzziness 存在、並圍繞它設計、不是假裝它不存在。

哪段該 Deterministic、哪段該 Fuzzy

一個系統幾乎不會「全 deterministic」或「全 fuzzy」、實務上是混合。判讀「哪段該哪個」的決策框架：

實務上一個 production LLM 應用的常見組合：

• 使用者輸入解析：偏 fuzzy（LLM 解意圖、parse 自由文字）。
• 資料庫查詢 / 更新：偏 deterministic（SQL、API、schema validation）。
• 業務規則檢查（如「能否退款」「能否變更地址」）：偏 deterministic（policy as code）。
• 回應草稿生成：偏 fuzzy（LLM 寫 email、考慮語氣）。
• 發送 / 寫入動作：偏 deterministic（API call、template render）。

這個混合不是隨機、是按上述決策框架推出來的。LLM 強在「理解模糊輸入」跟「生成有風格的輸出」、其餘部分能 deterministic 就 deterministic。

反模式：典範用錯的訊號

• Deterministic 的需求硬用 fuzzy 解：例如用 LLM 算稅金、然後用 retry + LLM judge 校驗。這條路的成本跟錯誤率都遠高於直接寫 deterministic 規則。判讀訊號：能用 30 行 code 寫死的規則、不要 LLM。
• Fuzzy 的需求硬用 deterministic 解：例如用 regex 解析自由文字客服訊息、然後維護一個越來越長的 case list。判讀訊號：規則 list 每週都在加新 case、加完還是漏、就該換 fuzzy。
• 邊界用錯：把 deterministic 的部分塞進 prompt（如「請計算 9.32 × 47 並退款」）、或把 fuzzy 的部分塞進 code（如 if user_intent == "refund"）。前者讓 LLM 出算術錯、後者讓 code 漏 case。判讀訊號：prompt 在做算術 / 字串解析、或 code 在做意圖分類、就該重切。

Fuzzy 邊界的 Guardrail 設計

承認 fuzziness 存在後、設計重點轉成「邊界要怎麼包」。Guardrail 是 deterministic 包 fuzzy 的設計模式、防止 fuzzy 行為溢出到不該影響的地方。

四種常見 guardrail：

Schema validation

LLM 輸出被強制符合某個 schema（JSON schema、Pydantic model、TypeScript type）。不符合就 retry 或 fallback。

適用：LLM 結果要直接餵給下游 deterministic 系統（API、DB、UI）。

實作位置：LLM call 之後、下游 system 之前。

失敗模式：schema 對了但語意錯（structurally valid、semantically wrong）——這層 guardrail 接不住、要加 semantic check。

Output validator

對 LLM 輸出跑語意驗證、不是只看 schema。例：生成的 email 不能包含未經授權的折扣承諾、生成的 code 不能呼叫 deprecated API。

適用：LLM 輸出有「該做 / 不該做」的清單。

實作位置：LLM call 之後、deliver 之前。可以是 deterministic check（regex、AST 分析）、可以是另一個 LLM judge（見 4.21 LLM-as-Judge）。

失敗模式：validator 自己 hallucinate（如果是 LLM judge）、或漏 case（如果是 deterministic check）。混用兩種比較穩。

Action gating

LLM 想做高代價動作前、強制走人類確認或外部驗證。例：寫 production DB 前要 human approval、發 email 前要 dry-run 給內部 review、執行 shell 前要看到 diff。

適用：副作用範圍大、失敗不可逆。對應 4.4 agent 架構 的 step-by-step approval / HITL 協作模型。

實作位置：tool layer、不是 prompt layer。Prompt 「請小心」是不夠的、靠 tool 本身不執行才有保證。

失敗模式：人類疲勞（rubber-stamp approval）、確認流程變橡皮圖章。設計時要讓 high-risk 跟 low-risk 動作走不同 gate、不要全部要人類確認、否則人類會關掉腦袋。

Distribution monitoring

不在 single call 層擋、而是看 LLM 行為的分佈。例：每天客服回應的「拒絕率」「退款承諾率」、跑 alert；新 prompt 上線後追 token 用量、語氣 polarity、user satisfaction 的 baseline 漂移。

適用：行為層面的 silent drift（個別 call 看不出問題、加總起來偏掉）。

實作位置：production observability、trace pipeline（見 4.20 LLM tracing）。

失敗模式：baseline 沒先建、新 prompt 上線後不知道「正常範圍」是什麼、alert 無基準。

四種 guardrail 怎麼選

順序通常是：schema validation 最便宜先上、output validator 看內容風險再加、action gating 看不可逆性決定、distribution monitoring 是長期經營必備。

混用比例：一個成熟的 production LLM 應用通常四種都有、但分擔不同 risk class。輕量 query 只走 schema、會寫資料的走 schema + validator + gating、會影響多人的走全套加 monitoring。

實驗成本的位移

Deterministic 軟體的實驗成本高、改 code 要 PR review、要跑 CI、要考慮回退、所以團隊文化是「想清楚再寫」。Fuzzy 軟體的實驗成本低——改 prompt 一行、跑兩個 case、就能看新行為——所以更接近「快速試、不行就丟」。

這個位移對工程師的工作方式有實質影響：

• Throw-away code 更可接受：原本「寫了就要維護」、現在「先試、不行就重來」。
• Prompt 是 source、但生命週期不一樣：跟 code 一樣 version control（見 4.10 衍生產物管理）、但 iteration 速度比 code 快一個量級。
• Eval 比 unit test 重要：unit test 鎖行為、但 fuzzy 行為本來就會變、eval 看「行為分佈是否在期望範圍」才是有用的測試。
• 失敗的歸因分層：壞掉時要問「是 prompt 問題、model 問題、context 問題、tool 問題、還是 deterministic glue 的 bug」——deterministic 軟體的歸因比較單一、fuzzy 軟體要分這幾層查。

這個位移是雙面刃。便宜實驗讓 iteration 快、但也讓 prompt / config / 行為快速分裂、production 跑著的東西跟 git 上看到的東西可能不一致。Mitigation 是 prompt template 上 version control、prompt diff 進 CI、production behavior 進 distribution monitoring。

跟 Agent / Workflow 設計的關係

Agent 跟 multi-call workflow 是「fuzzy 軟體」最複雜的型態。4.4 agent 架構 列出 agent 的三大失敗模式（context drift / goal drift / tool misread）、本質上都是 fuzzy 行為在多步累積後溢出 guardrail。

這個 framing 對 agent 設計的啟示：

• Loop 的每一步都是一個 fuzzy 邊界：每步都要決定 schema / validator / gating / monitoring 的組合。
• 越多步累積、越需要 deterministic checkpoint：「跑 10 步 fuzzy 推理、最後一步寫 DB」是高風險、要在中間插 deterministic verification。
• Termination 是 deterministic 邊界：靠模型自己說「完成了」是純 fuzzy、容易失控（見 4.4 termination 條件）。混用 step cap、cost cap、external validation 是 deterministic guardrail 包 fuzzy loop 的標準做法。

何時過時 / 何時不過時

不會過時的部分：

• 兩個典範的四維對照（資料、邏輯、行為一致性、實驗成本）。
• 「哪段該 deterministic / 哪段該 fuzzy」的決策框架。
• 四種 guardrail 的分類跟組合原則。
• Fuzzy 邊界要包 deterministic、不是反過來的設計直覺。

會變的部分：

• 具體 schema 工具（Pydantic、Zod、各家 framework 的 typed output API）。
• 具體 LLM-as-judge 平台跟方法（見 4.21）。
• 各家 framework 的 guardrail SDK（隨工具世代換）。
• Fuzzy / deterministic 的邊界位置會隨模型能力移動——模型越強、能 fuzzy 處理的範圍越大、但「該包 guardrail」的原則不變。

下一章

下一章：模組一 本地 LLM 服務 進入工具層、或跳到 模組四 LLM 應用層 看這個典範怎麼落到 RAG / agent / workflow 設計。Agent 設計怎麼把 fuzzy / deterministic 邊界體現在 loop 結構上見 4.4 agent 架構、人類介入點的設計選擇見 4.5 人機協作拓樸、跨多 call workflow 的 fuzzy 邊界設計見 4.7 workflow 編排模式。

本指南預設讀者已經會用過雲端 LLM（ChatGPT、Claude）、熟悉終端機操作、想以工程視角理解 LLM。寫 code 場景是主要使用例、但模組二 / 三 / 四 / 六多數章節跨場景通用：想懂 reasoning model / RAG / embedding model 內部、即使不裝本地 LLM 也能讀。硬體前提分兩條路線：Apple Silicon Mac（M1 ~ M4、統一記憶體）走模組一；Windows / Linux + 獨立 GPU（NVIDIA / AMD、獨立 VRAM + 系統 RAM）走模組五。文章不販賣 LLM 焦慮、也不誇大本地能取代雲端的程度；它的責任是給每條讀者旅程的最短可行路徑、並標出每個階段的取捨。

模組零（心智模型）是所有讀者旅程的共同前置。模組一跟模組五是「裝本地 LLM」的兩條硬體路線、依平台選一條；想懂底層走模組二跟模組三（跟硬體無關、含 reasoning model / speculative decoding 等推論細節）；想看 LLM 作為系統元件走模組四（12 章涵蓋 RAG、tool use、agent、應用層協議、workflow、production resource、long context、embedding model、benchmarking、vision、靜態 deployment）；本地工作流跑穩想看安全議題走模組六（個人 dev 視角的供應鏈、伺服器綁定、tool use 權限、prompt injection、跨雲端邊界、production routing）。

教材邊界

學習路線

本指南分成七個模組加一組前置卡片（111 張）。讀者依目的選讀、不需要從頭到尾全讀：

• 想用 Apple Silicon Mac 裝本地 LLM 寫 code：讀模組零 + 模組一（最短路徑）
• 想用 Windows / Linux + 獨立 GPU 裝：讀模組零 + 模組五
• 想懂 LLM 內部原理：模組二（數學） + 模組三（理論、含 reasoning models / speculative decoding）— 跟硬體無關
• 想做 LLM 應用開發（含 RAG / agent / VLM / 靜態 deployment）：模組四（12 章、跨工具世代不變的原理）— 跟硬體無關
• 想懂本地工作流的安全議題：模組一 / 五跑穩後接模組六（個人 dev 視角）
• 想選 RAG 的 storage 方案（pickle / vector DB / hosted SaaS）：直接看 4.22 RAG storage 工程
• 想在靜態網站加 RAG / 智能搜尋：直接看 4.16 靜態 / serverless RAG deployment
• 想在本機 fine-tune 模型：模組三 3.4 訓練流程原理 → 本機 QLoRA hands-on
• 想跟最新進展接軌：讀完模組後進推薦的公開課程跟 paper（模組二 2.4 + 模組三 3.10）

前置知識卡片

用原子化卡片整理 token、自回歸、KV cache、量化、speculative decoding、MTP、MLX、推論伺服器、OpenAI 相容 API、memory bandwidth、統一記憶體、TTFT、prefill、context window、Transformer、Diffusion 等核心概念。章節文章專注情境推導、術語背景交由卡片維持一致。

模組零：基礎知識與心智模型

整理本地 vs 雲端 LLM 的差異、自回歸架構與記憶體頻寬瓶頸、介面 / 伺服器 / 模型三層心智模型、OpenAI 相容 API 為何重要、MLX / MTP / oMLX 三個容易搞混的術語、Apple Silicon Mac 記憶體與模型大小的對應關係、判讀本地 LLM 資訊的五個框架。

模組一：本地 LLM 服務的安裝與應用

整理 Ollama、LM Studio、llama.cpp 三個主流推論伺服器的現況差異與安裝路徑、用 Continue.dev 把本地 LLM 接到 VS Code 的完整步驟、寫 code 場景下模型選型的優先順序、本地模型的期望管理、想進一步玩 coding agent、Web UI、產圖時的延伸方向。

模組二：LLM 的數學基礎

整理 LLM 推論背後的數學工具：線性代數（向量、矩陣、空間）、機率與資訊論（softmax、cross-entropy、KL、perplexity）、微積分與最佳化（gradient、SGD / Adam）、數值精度（fp32 / bf16 / Q4 / Q8 的取捨）。每章末尾接到公開課推薦。

模組三：LLM 的理論基礎

整理 LLM 內部運作機制、共 11 章：神經網路基礎、embedding 空間、attention 機制、Transformer 架構、訓練流程（pre-train → SFT → RLHF / DPO）、sampling 策略、tokenization 算法、跨語言場景原理、Reasoning models（o1 / R1 / QwQ 等 test-time compute paradigm）、Speculative decoding 內部（drafter / MTP / EAGLE）。每章末尾接到公開課推薦（Karpathy、Stanford CS224N / CS25 / CS336、DeepLearning.AI）。

模組四：LLM 應用層原理

整理 LLM 作為系統元件的設計原理、共 12 章：RAG、tool use、agent 架構、應用層協議、workflow 編排模式、Production resource planning、衍生產物管理、Long context engineering、Embedding model 內部、Benchmarking 方法論、Vision in coding workflow（本地 VLM 接 IDE）、靜態 / serverless RAG deployment（沒 backend 場景）。本模組刻意只寫跨工具世代不變的原理、避開 LangChain / LlamaIndex 等具體 framework 教學。

模組五：Windows / Linux + 獨立 GPU

整理消費級 PC（Windows / Linux + NVIDIA / AMD 獨立 GPU）跑本地 LLM 的硬體判讀模型與工程選項：VRAM + RAM 分層預算、MoE 模型的 CPU 卸載策略（--n-cpu-moe）、KV cache 量化（K=Q8 / V=Q4）跟 context 長度的權衡、llama.cpp 在 PC 上的調參空間。本模組跟模組一是平行的硬體路線、共用模組零的心智模型跟卡片。

模組六：本地 LLM 的安全與權限

整理個人 dev 在自己機器上跑本地 LLM 的安全議題：模型供應鏈與信任邊界、推論伺服器的綁定與暴露範圍、tool use 與 MCP server 的權限模型、IDE 場景的 prompt injection、跨雲端 / 本地的資料邊界、跨進 production 的 routing 中樞。framing 是個人 dev 視角、不是 enterprise 資安管理；production / 多租戶 LLM 服務的特殊資安議題見 Backend 模組七 資安與資料保護 的 LLM 相關章節。

模組之間怎麼配合

模組二跟模組三可並讀。閱讀模組三遇到陌生數學詞時跳回模組二補完、再回模組三繼續。模組四在前面模組之上、但讀者熟悉 LLM 應用詞彙也可直接從這裡讀起。模組一跟模組五依硬體選一條主路線、共用模組零的心智模型與 knowledge-cards。模組六在模組一 / 五跑穩後接、處理「跑起來後該注意什麼」。

適合的讀者

用語約定

本指南使用的關鍵術語在第一次出現時都附原文。為避免歧義，下列詞彙在本指南內固定指涉：

1. 本地 LLM：跑在使用者自己機器（Mac 或 PC）上的大型語言模型推論、prompt 留在本機。
2. 推論伺服器（inference server）：負責載入模型權重、處理 prompt、產生 token 的常駐程式、例如 Ollama、LM Studio 內建 server、llama.cpp server。
3. 介面層：使用者實際打字互動的工具、例如 VS Code + Continue.dev、CLI、Web UI。介面層透過 API 跟推論伺服器溝通。
4. 模型（model）：權重檔本身、例如 gemma4:31b、qwen3-coder:30b。模型可以在不同推論伺服器之間共用、前提是格式相容。
5. 量化（quantization）：把模型權重從高精度（如 bf16）壓成低精度（如 Q4）以減少記憶體佔用、代價是少許品質下降。

不在本指南內的主題

本指南不討論：

• Speech / audio LLM：跟核心文字 LLM 是不同方向、本指南不涵蓋。Vision（VLM）原本不放、但因 coding 工作流的 vision use case 進入主流、補上 4.15 Vision in coding workflow；video LLM 仍不放。
• 資料中心訓練的工程細節：data parallelism、ZeRO、tensor parallelism 等屬於專門課程的範圍。
• 向量資料庫的 vendor 比較（Pinecone vs Weaviate vs Chroma 等）：vendor 格局半年一變、不適合寫入教材。RAG 的 storage 工程原理（升級判讀、index 生命週期、dependency 約束）見 4.22 RAG storage 工程。
• Kubernetes / 資料中心級分散式推論：跟個人機器本地 LLM 方向不同、需另尋專門教材。
• 多卡 NVLink、tensor parallelism：消費級 PC 場景通常單卡、本指南不涵蓋多卡分散式推論。

若讀完本指南後想往這些方向走：

1. 想做 RAG 應用：先把 Ollama + Continue.dev 跑穩、再讀 模組四 4.1 RAG 原理 建立設計取捨判讀、或 模組三 3.8 推薦 的 DeepLearning.AI short courses。
2. 想跑 coding agent：先讀 4.4 Agent 架構原理 建立判讀、再看 1.6 延伸方向 了解 aider、Cline 等工具的定位差異。
3. 想跑產圖模型：Diffusion 跟 Transformer 是不同架構、請另尋 ComfyUI / Draw Things / Diffusers 教材。
4. 想自己訓練 / fine-tune：讀完模組三、進入 Karpathy zero-to-hero、Stanford CS336、Hugging Face NLP Course 等推薦資源。

文件版本：v0.7.0 最後更新：2026-05-12 系列狀態：七個模組 + 125 張知識卡片。模組零（9 章）/ 一（10 章 + hands-on、含 QLoRA + judge harness）/ 二（5 章）/ 三（12 章、含 reasoning / speculative / constrained decoding）/ 四（17 章、含 long context / embedding / benchmarking / VLM / 靜態 deployment / coding agent harness / prompt caching / agent memory / tracing / LLM-as-judge）/ 五（7 章）/ 六（7 章、含 OWASP 對照）。

這個差異一拆，後續所有取捨都會自然展開：隱私、成本、速度、能力四個維度在本地與雲端的權衡方向都不一樣。本章的責任是把這四個維度先攤開，後續章節再分別處理「速度為何慢」「記憶體為何決定能力」等具體問題。

本章目標

讀完本章後，你應該能回答：

1. 哪些情境下花時間在本地跑 LLM 比直接用雲端旗艦划算？
2. 本地 LLM 的「免費」實際成本怎麼算？
3. 本地 LLM 的速度跟雲端比、在不同任務上的差距如何？
4. 本地 LLM 在哪些任務上能跟 Claude / GPT-5 並肩、哪些任務改用雲端更划算？

四個維度的差異

這張表是後續所有章節的判讀基底。下面四個小節分別把每一格展開到「實際使用情境下會怎麼影響決策」。

隱私維度：prompt 出境邊界

本地 LLM 在隱私維度的核心承諾是 prompt 內容不離開本機。對寫 code 來說這影響的是兩件事：手上的 code 會不會進入訓練資料、客戶 NDA 或公司資安政策能否接受 code 出境。

接近真實的情境：

• 接受 NDA 的外包專案，客戶明示不得把 code 上傳第三方 AI 服務。
• 公司內部 monorepo 包含未公開的商業邏輯，資安政策禁止流向 OpenAI 或 Anthropic。
• 個人 side project 沒有合規壓力，但仍想避免將 prompt 變成廣告或推薦演算法的訓練資料。

陷阱是把「本地 = 絕對私密」當成自動成立的事實。本地 LLM 的隱私保證僅在於 prompt 不離開機器；若同時開啟雲端同步、把對話紀錄存到 Notion、或用 IDE 的雲端 plugin 同時送 prompt 給其他服務，隱私邊界仍會被穿透。隱私是一條鏈，本地推論伺服器只是其中一環。

雲端旗艦模型如 Claude 與 GPT 都提供 zero-retention 與不訓練選項（企業方案、API 預設等），合規上多數場景仍能滿足。隱私是訴求，不是非選本地不可的唯一理由。

成本維度：一次性投資 vs 按 token 計費

本地 LLM 的成本特性是「先付硬體錢，後續推論免費」。雲端 LLM 反過來：硬體完全不用管，但每個 prompt 都按 token 收費。

接近真實的情境：

• 一台 32GB Mac mini M4 約 NT$45,000，能持續跑 Gemma 4 31B 等中型模型。如果原本每月雲端 API 花費超過 NT$3,000，硬體成本約 15 個月攤平。
• 偶爾使用者（每月 API 花費 NT$200 以下）若為了「省錢」買新 Mac，是負投資；只有重度使用者才會真正攤平。
• 用 Claude Code 寫 code 的工程師，月費約 USD 200，一年 USD 2,400；硬體攤平的數學就要重算，特別是考慮到雲端能力斷崖式領先時，省下的時間成本通常超過 API 費用。

陷阱是把硬體成本當成沉沒成本、把雲端按月看成「持續流血」。實際上 Mac 本來就要買，邊際成本是「為了跑 LLM 多買 16GB 記憶體」這一段，這個邊際成本通常只有 NT$5,000 ~ 10,000，比看起來低很多。但這個邊際成本買到的是「不太強的模型」，能力差距見下一節。

電費跟風扇噪音是被忽略的隱性成本。32GB Mac 跑大型模型時持續滿載，風扇可能整天轉、機殼會熱；fanless 機種（Air）會降頻，速度進一步下降。

速度維度：首字延遲與生字速度

本地 LLM 的速度有兩個獨立指標：首字延遲（Time To First Token, TTFT，從送出 prompt 到第一個 token 出現）跟**生字速度**（tokens per second, tok/s，後續每秒能吐幾個字）。雲端跟本地在這兩個指標上的差距很不對稱。

接近真實的數字（2026 年 5 月、僅供量級參考、不是 benchmark）：

讀這張表時要注意三件事：

1. 雲端的 TTFT 是「請求送到資料中心 + 模型開始推論 + 第一個 token 回傳」的總和；網路 RTT 通常佔 100 ~ 300ms。本地 TTFT 是純推論成本。
2. 本地生字速度受 Apple Silicon 的記憶體頻寬限制、而不是算力。詳見 0.1 為什麼 LLM 生字慢。
3. 長 context 的首字延遲是本地 LLM 最大的痛點、瓶頸落在 prefill 階段把整個 prompt 灌進 KV cache。coding agent 場景塞了整個專案進 prompt 時、本地可能等 30 ~ 90 秒才開始吐字；這是為什麼後來出現 oMLX 這種特化伺服器 來解 KV cache 問題。

簡單的 chat 跟短 prompt 的 code completion，本地速度體感堪用。複雜的多檔案重構、塞大量 context 的 agent 場景，本地速度落差會被放大到難以忍受。

能力維度：本地模型能做到哪裡

能力是本地 LLM 最被誇大、也最容易讓人失望的維度。實話實說：2026 年 5 月在 Mac 上能跑的最強本地模型（如 Gemma 4 31B、Qwen3-Coder 30B、gpt-oss 20B），能力大約在 GPT-4 mini / Claude Haiku 4.5 這個層級。比雲端旗艦模型（Claude Sonnet 4.6、Opus 4.7、GPT-5）差一個明顯的品質差距。

接近真實的判讀：

• 簡單 function 寫作、單檔重構、加 type annotation、補 unit test、寫 docstring：本地堪用，速度差不多。
• 中等難度的 debug、解讀錯誤訊息、提建議：本地能給方向，但常需要追問才會收斂。
• 跨檔案重構、設計新架構、評估技術選型、寫長篇技術文件：雲端旗艦深度領先、改交給雲端更划算。
• 規劃 multi-step plan、把模糊需求拆成可執行步驟、做 deep debugging：規劃能力是雲端旗艦的明顯強項、現階段交給雲端是合理選擇。

陷阱是把網路上 cherry-picked 的成功案例當成普遍能力。「Gemma 4 31B 解出某個 leetcode 題」這類截圖無法代表它在你日常工作流的表現。判讀方法是直接用自己一週內實際處理過的 5 ~ 10 個任務當 benchmark、跑本地模型看通過率。

本地反而領先雲端的情境

雲端在「絕對能力」上領先、但本地在三類情境會反過來成為更好的選擇：

1. 離線或網路受限環境：出差、保密廠房、機上工作、行動網路不穩、雲端 API 連不上的場景。本地是唯一可用選項、能力差距不再是判讀重點。
2. 極低延遲容忍度的高頻互動：短 prompt 的 inline code completion、即時補 type annotation 等場景。本地省去 100 ~ 300ms 的網路 RTT、體感比雲端跳字流暢、適合「打字打到一半 IDE 自動補完」這類工作流。
3. 短 context 但隱私嚴格：金融、醫療、法務工作流的單檔處理。Prompt 短到不會放大本地速度劣勢、隱私要求又排除雲端、加上若是有 NDA 限制、本地的合規性優勢直接覆蓋能力差距。

這三類不是「本地通用領先」、而是「在這些限制下本地的劣勢被中和、優勢被放大」。除此之外的場景仍是雲端旗艦領先。

混用是現階段的正確心態

本地與雲端不是二選一。寫 code 場景下比較穩定的分工是：

1. 高頻、重複、隱私敏感、不需要極致品質的任務交給本地（補 type、寫測試、解釋 code、簡單重構）。
2. 低頻、複雜、需要深度思考的任務交給雲端旗艦（設計、規劃、深度 debug、跨檔案重構）。
3. 一台中型 Mac（24GB ~ 32GB 記憶體預算） + 雲端旗艦訂閱（Claude Code / GPT-5）的組合、現階段是大多數工程師的甜蜜點。

把本地 LLM 當成「免費的初階 pair programmer」而不是「Claude 替代品」，期望管理就會對齊現實。後續章節會回到這個心態，特別是 模型選型 與 期望管理。

下一章

下一章：0.1 為什麼 LLM 生字慢，解釋為什麼即使你的 Mac 看起來算力很強，生字速度仍受記憶體頻寬限制。

讀完本模組後，你應該能清楚回答：本地跟雲端跑 LLM 的差別在哪、為什麼 LLM 一個字一個字吐而不是整段吐、什麼是介面 / 伺服器 / 模型三層架構、為何 OpenAI 相容 API 是整個生態的基石、MLX 跟 MTP 跟 oMLX 各自是什麼東西、自己這台 Mac 的記憶體能跑多大的模型。

章節列表

為什麼先讀模組零

模組一的安裝步驟看起來只是 brew install 加一行 ollama run，但每個指令背後都隱含選擇：要選哪個推論伺服器、要拉哪個量化等級的模型、要不要打開 speculative decoding、API 接哪個 port。若沒有模組零的心智模型，這些選擇只能靠抄文章上的指令，遇到變化就無法判讀。

例如網路上常見的「裝完 Ollama 就能用 MLX 加速」這種說法，背後混淆了三件事：Ollama 是不是用 MLX 當 backend、MLX 跟 Metal 在 Apple Silicon 上的關係、加速來自 MLX 還是 MTP 還是量化。讀完 0.4 後你會自然知道這句話該怎麼追問才能得到正確答案。

模組零的閱讀策略

本模組八篇章節彼此獨立，但建議依下列順序讀：

1. 先讀 0.0 本地 vs 雲端 跟 0.1 為什麼 LLM 生字慢，建立「本地 LLM 解什麼問題、不解什麼問題」的判斷。
2. 接著讀 0.2 三層架構 跟 0.3 OpenAI 相容 API，建立「工具如何拼裝」的判斷。
3. 然後讀 0.4 MLX / MTP / oMLX，避開最常見的術語陷阱。
4. 接著讀 0.5 硬體記憶體 跟 0.6 判讀框架、把心智模型對到自己手上這台 Mac 的現實、並建立評估新資訊的反射。
5. 讀 0.7 隱私資料流原理、把 0.6 框架五展開成可操作的設計原則。
6. 最後讀 0.8 Deterministic vs Fuzzy Engineering、建立「LLM 軟體跟傳統軟體的設計典範差異」心智模型、為進入模組四 LLM 應用層 做準備。

讀完後可進 模組一：本地 LLM 服務的安裝與應用 看安裝步驟、或直接進 模組四 LLM 應用層 看典範怎麼落到 RAG / agent / workflow 設計。

不在本模組內的主題

本模組聚焦「操作層心智模型」、其他層次交給對應模組：

1. Transformer 架構數學細節（attention、positional encoding、residual stream 等）→ 模組三 LLM 理論基礎
2. 線性代數、機率、最佳化、數值精度等數學工具 → 模組二 數學基礎
3. 訓練、fine-tuning、RLHF、DPO → 模組三 3.4 訓練流程
4. 具體工具的安裝步驟 → 模組一 本地 LLM 服務
5. 雲端 GPU 部署 → 本指南範圍只在 Apple Silicon Mac、請另尋資料中心 inference 教材

本模組只提供「Mac 本地寫 code」這條最短路徑需要的概念基底；其他層次的學習路線見首頁的模組對照表。