0.6 判讀本地 LLM 資訊的五個框架
本地 LLM 的核心特性之一是「資訊更新得很快」。新模型 2 ~ 3 個月一個世代、推論伺服器幾週一個版本、社群文章每天大量產出。同樣一件事在不同來源講法可能差很遠：有的精準、有的混淆層級、有的引用過時資訊、有的拿單一情境當普遍能力。學會用一致的框架評估每則資訊、是本地 LLM 使用者最值得培養的能力。
本章把前面五章的概念整理成五個判讀框架。每個框架對應一類常見資訊問題、給讀者一組可重複套用的提問清單。讀完後你會建立一個反射：看到 LLM 相關內容時、自動跑過這些框架、確認資訊夠不夠扎實再吸收。
本章目標
讀完本章後，你應該能：
- 看到「N 倍加速」「能跑 X 大小模型」這類量化宣稱時、知道要追問哪些變數。
- 看到「X 工具支援 Y 功能」時、知道怎麼確認時間點與版本。
- 把工具放回三層架構、辨識「framework vs 伺服器 vs 模型」的混淆。
- 區分「載得進記憶體」跟「實際好用」是兩件事。
- 把「隱私」從「位置」改成「資料流」來思考。
框架一：追溯版本與時間點
本地 LLM 工具的功能支援會隨版本變化。同一句「X 工具支援 Y 功能」可能 2025 年成立、2026 年版本改了、或反過來。判讀任一則「支援 / 整合 / 加入」的宣稱、第一步是確認版本與時間點。
這個框架解什麼問題
社群文章常省略版本資訊。「llama.cpp 加入 Gemma 4 MTP」這類句子若沒附上日期或版本號、就有三種可能：上游確實已合入、是某個 fork（從主 repo 分支出去的獨立版本）加的 patch（補丁修改）、或是社群討論的願景。三種狀態下「該怎麼用」的答案完全不同。
怎麼套用
看到「X 工具支援 / 整合 / 加入 Y」時、按順序問：
- 版本與日期：在哪個版本加入？發布日期是？
- 支援程度：是 GA（一般可用）、beta、實驗性、還是 fork 上的 patch？
- 官方確認：是否在 release notes / changelog / 官方文件提到？
確認來源的最快路徑：
| 工具 | 看哪裡確認版本支援狀態 |
|---|---|
| Ollama | github.com/ollama/ollama/releases |
| llama.cpp | github.com/ggerganov/llama.cpp/releases |
| LM Studio | 應用程式內 About 頁、官網 changelog |
| MLX | github.com/ml-explore/mlx/releases |
實際情境
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 倍」這個數字、放到自己的場景常常對不上。
怎麼套用
看到量化宣稱時、回到下面三個維度確認：
| 變數 | 該問什麼 |
|---|---|
| 任務類型 | coding？對話？數學？翻譯？不同任務的加速幅度差很多 |
| 比較基準 | 跟「沒開該功能」比、還是跟「另一個工具」比？ |
| 執行硬體 | M4 Max？M2 Pro？Mac Studio？硬體規格影響絕對數字 |
實際情境
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 是另一個推論伺服器。混淆層級的句子讀起來像在比較、實際上比較的對象不在同一層。
怎麼套用
看到工具被比較或描述時、按下表分類：
| 工具 | 屬於哪一層 | 比較對象應該是 |
|---|---|---|
| Continue.dev | 介面層 | Cursor、aider、Open WebUI |
| Ollama | 推論伺服器 | LM Studio、llama-server、oMLX |
| llama.cpp | library + 推論伺服器 | MLX、PyTorch（library 層）；llama-server 跟其他 server 比 |
| MLX | framework / library | PyTorch、JAX |
| Gemma 4 / Qwen3 | 模型 | 其他模型 |
| OpenAI 相容 API | 跨層標準介面 | （是介面、不是工具） |
實際情境
「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 模型」的報告時、按下表追問：
| 指標 | 體感分界 |
|---|---|
| 生字速度 | < 10 tok/s 卡頓、20 ~ 40 tok/s 流暢、> 40 即時 |
| TTFT（首字延遲） | > 10 秒打斷思路、< 3 秒接近順暢 |
| 整台 Mac 響應 | 切 tab / 開 app / 滑滑鼠是否順暢 |
| 記憶體 swap | Activity Monitor 看 Memory Pressure 是否變紅 |
| 風扇與降頻 | 長時間用是否風扇狂轉、體感變熱 |
實際情境
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每個節點問一次：
| 節點 | 該問什麼 |
|---|---|
| IDE 介面層 | 有沒有 telemetry？是否同時送雲端服務？ |
| 推論伺服器配置 | OLLAMA_HOST 是 127.0.0.1 還是 0.0.0.0？ |
| 對話紀錄保存 | 存到本機 SQLite？同步到 Notion / iCloud？ |
| 介面 plugin | 有沒有第三方 plugin 把 prompt 送到別處？ |
| 網路設定 | 是否有區網其他裝置能存取本地伺服器？ |
實際情境
寫 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 預設等），多數合規場景能滿足。本地的隱私優勢在「物理上資料留在機器」、雲端的隱私保證來自合約與技術控制；兩條路在隱私光譜上各占一段、按實際需求挑。
把五個框架當反射
下表把五個框架壓成一張快速查表、看新資訊時對照：
| 看到這類內容 | 先跑哪個框架 |
|---|---|
| 「N 倍加速」「快 X%」 | 框架二（任務、基準、硬體三變數） |
| 「達到 / 接近 GPT-X」 | 框架二 + 框架四（變數 + 真實體感） |
| 「X 工具支援 Y 功能」 | 框架一（版本與日期） |
| 「A 比 B 強」 | 框架三（兩者是不是同一層） |
| 「我跑得起 X 模型」 | 框架四（生字速度、TTFT、整機體感） |
| 「本地絕對私密」 | 框架五（資料流每個節點） |
| 「換 model 就能做 Y」 | 框架三（Y 是不是同一個架構家族？Transformer 還是 Diffusion） |
| 「量化越激進記憶體越省」 | 框架四（量化後品質還夠嗎） |
五個框架彼此互補、不互斥。一則複雜資訊常需要同時跑兩三個框架才能完整評估。例如「16GB Mac 跑 70B Q3 模型很順、達到 GPT-4 等級」這句話、要同時跑框架二（達到 GPT-4 是什麼任務上的測試？）、框架四（生字速度多少？整台 Mac 還能用嗎？）、框架三（70B Q3 跟 GPT-4 不在同一層、有點混）。三個框架都跑過、就能還原原始宣稱的真實價值。
框架的邊界：何時可以省略
五個框架是預設掃描清單、但不是每個情境都要五個一起跑。下表是「該框架不適用」的判讀：
| 框架 | 何時可以省略 |
|---|---|
| 一、追溯版本時間點 | 物理上限類數字（記憶體頻寬、bus 寬度）— 不隨版本變化 |
| 二、量化宣稱三變數 | 物理常數或寫死的硬體規格（如 M4 Max 頻寬 546 GB/s）— 是硬體事實、非宣稱 |
| 三、工具放回三層 | 純應用層討論（如 prompt engineering、agent 設計）— 跟分層架構正交 |
| 四、載得進 vs 好用 | 純概念說明 / 教學文（不涉及實際跑模型）— 沒有「好用」維度要評估 |
| 五、隱私資料流 | 完全離線的設備（air-gapped Mac）— 資料流退化為單一節點 |
判讀原則：框架不適用於「該維度根本不存在」的情境。寧可多跑一個框架、覆蓋率優先 — 跑了發現不適用比漏掉某維度風險小。
框架是工具、不是教條
跑這些框架的目的是「拿到能用在自己場景的判讀」、不是「找出每篇文章的錯」。多數作者寫東西時省略前提、是為了文章流暢、未必是有意誤導。把框架當成補完前提的工具：看到不完整的句子、自己補上「在什麼任務、什麼硬體、什麼版本」的脈絡、就能還原作者想表達的事。
對自己也用同一套標準。寫筆記、發推文、回答同事問題時、附上版本與硬體脈絡、能讓資訊更耐保存、半年後自己回看也仍能讀懂。
下一步
下一步：模組一 本地 LLM 服務的安裝與應用、把概念落地到實際安裝、整合 VS Code、選模型、做期望管理。