實驗跑了四個本地模型對比：

• gemma3:1b（815 MB、舊代 / 小）
• gemma3:4b（3.3 GB、舊代 / 中）
• qwen3:8b（5.2 GB、跨家族 / 大）
• gemma4:e4b（9.6 GB、新代 / 中、bf16）

對應 4.4 Agent 架構 「規劃能力是雲端旗艦的明顯強項、本地小模型的明顯弱項」這條觀察、用具體 structural metrics 驗證、並揭示**「最新世代 + 較大 size」未必比「跨家族 / 較強訓練」勝出**。

驗證日期：2026-05-12 環境：Ollama 0.23.2、Apple Silicon、MPS backend 任務：讀資料夾 A（風格參考、5 章已寫完）+ 資料夾 B（同類型、5 章已寫完、需寫 v06）→ 為 B 生成 v06 評估方式：純 structural metrics、不評論內容品質

任務設計

兩個資料夾結構：

1A/                          B/
2├── README.md               ├── README.md
3├── v01_XXX.md              ├── v01_XXX.md
4├── v02_XXX.md              ├── v02_XXX.md
5├── v03_XXX.md              ├── v03_XXX.md
6├── v04_XXX.md              ├── v04_XXX.md
7└── v05_XXX.md              └── v05_XXX.md
8                            └── v06_XXX.md  ← 要生成

兩個資料夾用不同 markdown 格式：

• A 風格：# 標題（H1）+ ## 場景設定 段 + 結尾 **【本章結束】**
• B 風格：## v0X｜<主題>（<角色1>×<角色2>）（H2）+ 直接敘事、無結尾 marker

LLM 看完 A + B 後、要寫 B 的 v06——必須 follow B 的格式、不是 A 的。是個 format discrimination 測試。

評估維度

純 structural、不涉內容：

不評估的：

• 內容品質、文筆好壞
• 敘事邏輯是否合理
• 角色塑造是否生動

純 structural 評估的好處是 reproducible、不需 reviewer 主觀判斷、可自動跑。

Baseline：B 既有 v01-v05 的 metrics

B 資料夾 5 個既有章節的平均：

這是 LLM 該模仿的目標。

四個模型的結果

四個 model 跑同樣 prompt、同樣輸入內容。

對比表

各模型觀察

gemma3:1b（815 MB）：

• 篇幅 4.6× 失控、段落數 4.5× 超標、用 H1 而不是 H2。
• 顯示 1B 模型對「2000-3000 字」這種 numeric instruction 沒有有效執行能力、會一直生成到 context 限制。
• 但 cross leak 0、結尾 marker 也沒誤加——「不要 X」這類 negative instruction follow 較成功。

gemma3:4b（3.3 GB）：

• 篇幅 / 段落 / heading 結構全 OK、明顯比 1B 大幅改善。
• dialogue lines = 0：完全沒寫對話、整篇純敘事。表示 4B 抓到字面 structural feature、但沒抓到「對話 driven 敘事」這個 stylistic feature。
• 主角名提及 24 次（baseline ~60）—內容偏短、提及次數偏低、但比例合理。

qwen3:8b（5.2 GB、跨家族）：

• 唯一 7/7 全 pass 的模型——篇幅完美匹配（951 vs ~933）、段落數合理（36 vs ~32）、heading 對、對話 7 行完全等於 baseline。
• 跨家族 + 大一級的組合表現質變，比同家族下一級的 4B 模型大幅提升。
• 代價：生成時間 97.5s、約是 4B 模型的 2.7×。

gemma4:e4b（9.6 GB、新代）：

• 驚人的 1/7、最差表現——比 1B 還少通過項目。
• 主角名提及 0：完全沒寫角色名、純抽象敘述「某一方」「另一方」。
• dialogue 0：沒對話。
• 生成內容是「劇情大綱建議」而非實際章節：含「劇情核心思路」「預計情緒強度」「寫作切入點建議」等 meta-text。
• 輸出末尾「（此為結構化建議、等待具體的指令後、將會生成與風格一致的劇情內容。）」——明示它把 prompt 理解成「給建議框架、等下一步」。

Strict prompt retest：揭示 internal alignment

懷疑 1/7 可能是「prompt 不夠強硬」、用 strict prompt 重跑 gemma4:e4b。Strict 加了八條規則、明示：

1- 直接從 `## v06｜...` 開頭、不寫前言
2- 絕對不可寫「劇情核心思路」「預計情緒強度」「寫作切入點」等 meta-text
3- 必須直接寫敘事內容、含對話、動作、感受描寫
4- 強制提到角色名多次、不要用「某一方」「另一人」抽象稱呼
5- ...

Strict prompt 結果：

從 1/7 → 4/7、prompt 強化明顯有用。但主角名提及兩次都 0、即使 strict prompt 明示「強制提到角色名」、模型仍用「兩人」「彼此」「對方」抽象稱呼。

這比「模型不會 follow」更精確、是兩個層次的 follow 差別：

• Surface level instruction（heading 格式、不要 meta-text、要對話）：model 願意 follow strict prompt。
• Semantic level instruction（在這個情境用具名角色）：model 有 internal alignment 抗拒、即使 prompt 明示也不 follow。

Gemma 4 e4b 是 device-deployable edge variant、RLHF 可能特別針對「敏感情境下的人物識別」做 alignment。這個 alignment 比 prompt-level instruction follow 更深、是 hard line、不能用 prompt engineering 繞過。

關鍵觀察

Model size 不是唯一因素、訓練 alignment 更重要

最反直覺的結果：

• gemma4:e4b（9.6 GB、最新世代）原 prompt 通過 1/7、strict prompt 通過 4/7。
• gemma3:4b（3.3 GB、舊一代）通過 6/7。
• qwen3:8b（5.2 GB、跨家族）通過 7/7。

「最大 + 最新」不等於「最好 follow instruction」。在這個任務上、ranking 是：

1qwen3:8b > gemma3:4b > gemma3:1b ≈ gemma4:e4b (strict) > gemma4:e4b (default)

可能因素：

1. 訓練資料分佈差異：Qwen 系列訓練資料含大量中文、對中文 instruction follow 更穩。
2. Edge variant 的 alignment 設計：gemma4:e4b 是 device-deployable edge variant、RLHF 可能特別在敏感情境用 conservative output。Strict prompt 能改善 surface-level（heading、meta-text、對話）、但 semantic-level（具名角色）有 hard line 不能繞過。
3. 跨家族效應 > 跨代效應：Qwen vs Gemma（不同家族）比 Gemma 3 vs Gemma 4（同家族跨代）影響更大。

兩層 instruction follow

gemma4:e4b 的 strict prompt retest 揭示一個重要區分：

• Surface-level instruction（heading 格式、不要 meta-text、要對話）：可以用 strict prompt 改善、prompt engineering 有效。
• Semantic-level alignment（特定情境的角色處理、敏感主題的表述方式）：是 RLHF 階段建立的 hard line、prompt engineering 繞不過。

設計應用時要意識：「LLM follow 不了 instruction」可能不是能力問題、是 alignment 問題。模型訓練時被刻意 align 不做某些事、即使 prompt 明示也不會做。發現這種情況、改換 model（或 less-aligned variant）會比繼續調 prompt 更省時間。

「最新世代」的標籤可能誤導

Gemma 4 是 2026/4/2 才發布的最新代、size 也夠大、但在這個 instruction following 任務上輸給 6 個月前發布的 Gemma 3 4b。

設計應用 / 選模型時、實測對自己 task 的表現比「最新 / 最大」標籤可靠。Benchmark ranking（如 LMSYS Chatbot Arena）反映平均表現、未必 reflect 你的 narrow 任務。本實驗示範了「自己跑一次」比「看 benchmark」更可靠的判讀方法。

Structural feature 跟 stylistic feature 兩層

跨四個模型一致觀察：

• Structural feature（heading level、結尾 marker、不要 cross leak）：所有模型多少都抓到。
• Stylistic feature（對話 driven 敘事、篇幅精準）：差異極大、Qwen3 8B 完美、其他三個都有明顯失分。

這對應 4.4 Agent 的「規劃 vs 字面 follow」差距——字面 instruction 容易、stylistic mimic 困難。寫應用時、預期 follow「形式約束」（output JSON、結尾 signature）跟 follow「風格約束」（用簡潔口吻、bullet 而非段落）兩種 instruction 的成功率不同。

Cross-pairing leak：全 0

四個模型 cross leak 都 0——表示「不要混角色」這個 instruction 兩個都 follow 成功。可能因素：

• 角色名是名詞、模型 generation 時容易 constrain。
• Prompt 已明示「為 B 寫」、模型沒被 A 角色名干擾。

如果改成模糊 instruction（「混合 A、B 風格」）、leak 可能會出現——本實驗沒涵蓋這個 case。

生成時間：size ≠ 時間

四個模型的生成時間：

意外發現：

1. 1B 比 4B 慢：因為 1B 生成 4324 字、4B 生成 1330 字、總 token 量決定總時間、不是 model size。
2. qwen3:8b 慢 2.7×：8B 的 forward pass 較慢、加上 generation 量級正常、總時間最長。
3. gemma4:e4b 跟 1B 相近：generation 短（679 字）、抵消 model 較大的開銷。

tokens per second 跟 total latency 是兩件事——decode 速度快但生成太多 token、未必更快完成任務。

對寫應用的啟示

1. 「最新最大」≠ 「最好 follow」：選模型實測自己 task、benchmark / size 只是輔助訊號。
2. 本地小模型（< 3B）做需要 follow 結構規則的任務、要嚴格驗證：用 structural metrics 自動 check、目視判斷模型「看起來有做到」的可靠度低。
3. Edge variant 可能有 special behavior：device-deployable variant 可能 RLHF 偏向 conservative、不一定適合所有任務。
4. 跨家族對比比同家族升 size 收益大：Qwen3 8B vs Gemma3 4B 比 Gemma3 4B vs Gemma3 1B 改善更明顯。
5. 「形式跟風格」分開驗證：應用層的 validation 分維度 score、比一次評全部更可解讀。

跑這個實驗的 framework

通用流程（不放具體 script、會綁定 corpus 內容）：

11. 準備兩個資料夾、A 是風格參考、B 是 work-in-progress
22. 寫 helper script 把兩個資料夾完整內容 + 任務說明做成 prompt
33. 跑多個 model 各一次（同 prompt、不同 model）
44. 對輸出計算 structural metrics（char count、paragraph、heading、dialogue lines）
55. 跟 B 既有章節的 baseline metrics 對比
66. 列通過 / 失敗矩陣

關鍵設計選擇：

• A 跟 B 風格故意不一樣：才能驗證 LLM 是否分辨「該 follow 哪個」。
• 不評估內容品質：純 structural 評估 reproducible、不需 reviewer 主觀判斷。
• baseline 用既有章節算：B 自己的 v01-v05 是「正確答案」的 reference。
• 跑多個跨家族 / 跨世代 / 跨 size 模型：避免「只測一個就下結論」的偏差。

何時這份對比會過時

• 具體模型 ranking：新模型發布後 ranking 會變、特別是新版 Gemma 4 / Qwen 4 / Llama 4 等推出時。
• 「Gemma 4 edge 表現差」這個觀察：可能隨後續 fine-tune 或新版改善。

不會過時的部分：

• Model size 不是 instruction following 的唯一因素——這個現象在所有 LLM 都存在。
• Structural vs stylistic 兩層 follow 難度不同。
• 跨家族對比比同家族升 size 收益大、這個現象可能持續。
• 純 metrics-based 評估比主觀判斷可重現。
• 「自己跑一次」比「看 benchmark」更可靠的判讀邏輯。

未來想擴展、可以加入更多維度（如反向 retrieval：把生成內容當 query、看能不能找回原資料夾；或 perplexity-based 評估）。

跟其他 hands-on 章節的關係：完整 hands-on 系列見 Hands-on 章節索引、選模型的優先序策略見 Model selection priority、模型 tag 命名規則見 Model tag、跑多模型的記憶體預算見 Resource management。

驗證日期：2026-05-11 Ollama 版本：0.23.2 示範模型：gemma3:1b（約 815 MB、選最小可運行的 Gemma 變體當驗證對象）

前置設定

表中 brew --version 這關若還沒過、代表 Homebrew 沒裝。新機從零的安裝順序（Homebrew、PATH、bash）見 macOS 新機基礎建設。

選 1B 模型只是為了驗證流程、能力很弱、實際寫 code 場景請用 14B / 31B 級。模型大小跟記憶體 / 磁碟對應關係見 0.5 Apple Silicon 記憶體預算。

安裝 Ollama

用 Homebrew 安裝、是 macOS 上最直接的路徑：

1brew install ollama

執行時間在 broadband 大約 30 秒到 2 分鐘、視 dependency cache 是否已有（Ollama 依賴 mlx-c 等 Apple Silicon 加速函式庫、首次裝較久）。

裝完看到的 caveat 訊息：

1To start ollama now and restart at login:
2  brew services start ollama
3Or, if you don't want/need a background service you can just run:
4  OLLAMA_FLASH_ATTENTION="1" OLLAMA_KV_CACHE_TYPE="q8_0" /opt/homebrew/opt/ollama/bin/ollama serve

兩種啟動模式：

• launchd service（推薦日常用）：開機自動啟動、跑在背景。
• 前景手動跑：terminal 開著、關掉就停。

驗證 binary 路徑：

1which ollama
2# 應該回 /opt/homebrew/bin/ollama

啟動 Ollama Service

選 launchd service 模式：

1brew services start ollama

預期輸出：

1==> Successfully started `ollama` (label: homebrew.mxcl.ollama)

這個動作做兩件事：

1. 註冊一個 launchd plist（macOS 開機自啟動 / 背景服務的設定檔、見 launchd-service 卡片）到 ~/Library/LaunchAgents/homebrew.mxcl.ollama.plist。
2. 立刻啟動 ollama serve、之後重開機自動啟動。

驗證 server 真的在跑：

1curl -s http://localhost:11434/api/version

預期回：

1{"version":"0.23.2"}

看到這個 JSON 就證明三件事：Ollama daemon 跑了、port 11434 通了、API 結構正確。

拉第一個模型

Ollama 用 ollama pull 從官方 registry 下載模型：

1ollama pull gemma3:1b

Gemma 3 1B 約 815 MB、broadband 約 1-2 分鐘下載。下載過程顯示多階段：

1pulling 7cd4618c1faf: 100% ▕██████████████████▏ 815 MB
2pulling e0a42594d802: 100% ▕██████████████████▏  358 B
3pulling dd084c7d92a3: 100% ▕██████████████████▏  8.4 KB
4pulling 3116c5225075: 100% ▕██████████████████▏   77 B
5pulling 120007c81bf8: 100% ▕██████████████████▏  492 B
6verifying sha256 digest
7writing manifest
8success

幾個 hash blob 分別是：模型權重（最大那個）、tokenizer、template、license metadata 等。Ollama 把這些統一管理、放在 ~/.ollama/models/。

驗證模型已下載：

1ollama list

預期：

1NAME         ID              SIZE      MODIFIED
2gemma3:1b    8648f39daa8f    815 MB    35 seconds ago

驗證 OpenAI 相容 API

OpenAI 相容 API 是下游所有工具（IDE plugin、RAG pipeline、MCP server、Continue.dev 等）依賴的介面 contract、驗證它能正常回應、整個 stack 才走得通：

1curl -s http://localhost:11434/v1/chat/completions \
2  -H "Content-Type: application/json" \
3  -d '{
4    "model": "gemma3:1b",
5    "messages": [{"role":"user","content":"Reply in one short sentence: what is 2+2?"}],
6    "stream": false
7  }'

預期回 JSON、choices[0].message.content 是模型回答（如 "2 + 2 = 4"）。看到合理回答就證明：

1. Ollama 跟模型權重對接好。
2. OpenAI 相容 API 格式正常（IDE plugin 可以接）。
3. 推論流程整條通。

常見的失敗回應跟下一步：

• {"error":"model 'gemma3:1b' not found, try pulling it first"}：先跑 ollama pull gemma3:1b、確認 ollama list 看到該 tag。
• curl: (7) Failed to connect to localhost port 11434: Connection refused：server 沒在跑、回 brew services list 看 status、若是 stopped 跑 brew services start ollama。
• {"error":"json: cannot unmarshal ..."}：請求格式錯（例如 messages 寫成 string 不是 array）、檢查 JSON body。
• 連得上但長時間沒回應：第一次載入大 model 需要 30 ~ 60 秒、看 ~/.ollama/logs/server.log 確認是否還在 loading。

用內建 CLI 互動模式也行：

1ollama run gemma3:1b

進入 REPL、可以打字對話。/bye 離開。

第一次跑 ollama run 會把模型載入記憶體（1B 模型大約 1-2 秒）、之後對話延遲低。如果幾分鐘沒用、模型會被 unload 釋放記憶體、下次 run 又要等載入。控制行為的環境變數是 OLLAMA_KEEP_ALIVE（預設 5 分鐘）。

常見前置設定問題

Port 11434 被佔用

1lsof -i :11434

若已有 process 占用、可能是先前手動跑過 ollama serve 沒關。kill 後再 start service：

1pkill -f "ollama serve"
2brew services restart ollama

ollama: command not found（裝完還是找不到）

Homebrew 在 Apple Silicon 預設裝到 /opt/homebrew/bin、shell PATH 應該已含。若沒含：

1echo $PATH | tr ':' '\n' | grep homebrew
2# 若沒看到 /opt/homebrew/bin、要加進 ~/.zshrc：
3echo 'export PATH="/opt/homebrew/bin:$PATH"' >> ~/.zshrc
4source ~/.zshrc

Server 啟動但 curl 失敗

1brew services list | grep ollama

若 status 不是 started、看 log：

1tail -50 /opt/homebrew/var/log/ollama.log

常見原因：port 衝突、權限問題、上次 crash 沒清乾淨。

完整排錯流程見 1.7 排錯方法論。

之後想做的事

• 接 VS Code：見 1.3 VS Code + Continue.dev 整合。設定 apiBase: http://localhost:11434 就能用。
• 跑更大模型：32GB+ Mac 推薦 gemma4:31b-coding-mtp-bf16（18 GB）。模型選擇見 1.4 模型選型優先順序。
• 加 embedding：codebase 索引要 embedding 模型：ollama pull nomic-embed-text（274 MB）、見 4.1 RAG 原理。

升級 / 移除

升級：

1brew upgrade ollama
2brew services restart ollama

完整移除：

1brew services stop ollama
2brew uninstall ollama
3rm -rf ~/.ollama  # 清模型 cache（可選）

何時這篇會過時

• brew install ollama 安裝方式跟 OpenAI 相容 API 形狀短期內不會變（生態都依賴）。
• gemma3:1b 這個具體 tag 預期會被新模型取代、但「拉一個小模型驗證流程」的方法不變。
• launchd service 機制是 macOS 系統 API、不會 deprecate。

讀的時候若 brew install 跑失敗、查 Ollama GitHub release notes；其餘驗證步驟結構通用。