本章把前面五章的概念整理成五個判讀框架。每個框架對應一類常見資訊問題、給讀者一組可重複套用的提問清單。讀完後你會建立一個反射：看到 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、選模型、做期望管理。