本週要驗證什麼假設
這週的規則改了：任何關於模型能力、量化影響、backend 差異的斷言，都要指向一份真實的技術報告或官方文件，沒有引用的說法一律不能寫進文章。
也就是說，這週的預測不是「Josh 覺得哪個會贏」，而是「這幾份技術報告分別主張什麼，實測會不會站得住腳」。
實驗設計
同一台 M1 Pro 16GB，一次只裝一支候選模型——pull → 跑完 5 題基準 → 記錄 → ollama rm → 換下一支。基準模型 gemma4:e2b 全程保留。
| 模型 | 開發者 | 參數 | Backend | 官方來源 |
|---|---|---|---|---|
| gemma4:e2b（基準） | Google DeepMind | 5.1B（PLE 架構，2B 記憶體足跡） | GGUF Q4_K_M | Gemma Team, "Gemma 4 Technical Report," arXiv:2607.02770, 2026-06 |
| gemma3:latest | Google DeepMind | 4.3B | GGUF | Gemma Team, "Gemma 3 Technical Report," arXiv:2503.19786, 2025-03 |
| llama3.1:8b | Meta AI | 8B | GGUF | Llama Team, "The Llama 3 Herd of Models," arXiv:2407.21783, 2024-07 |
| qwen3.5:9b-MLX | Alibaba | 9B | MLX | Qwen Team, "Qwen3 Technical Report," arXiv:2505.09388, 2025-05 |
（gemma4:e2b 容易被誤認是 Gemma 3 家族的變體——它其實屬於 2026-06 才發布的 Gemma 4 家族，E2B 是 effective-params 命名慣例，跟 Gemma 3n 的官方 model card 是兩份不同文件。）
三條測試路線：
- Route A：四支模型跑同一組 5 題基準（繁中改寫／Python／SQL／JSON／邏輯推理），同 prompt、temperature=0.0、num_predict=512
- Route B：Route A 贏家挑出來，比對不同量化版本的「品質 vs. 記憶體占用 vs. 延遲」
- Route C：找一支同時有 GGUF 和 MLX 版本的模型，同一份 prompt 測兩個 backend 的延遲差異——規矩很明確：MLX 的延遲不能跟 GGUF 直接列同一欄無註腳
我的預測與理由
文獻預測 gemma4:e2b 會贏。 Gemma 4 技術報告主打 PLE（Per-Layer Embedding）架構，讓 E2B 用 2B 記憶體足跡跑出 5.1B 總參數的效果，加上 256K context 與 thinking mode，理論上該是這四支裡「用最少資源換最多能力」的那個。
懸念一：Llama 3.1 8B 的參數優勢扛不扛得住 4-5B 級對手？ Llama 3 Herd 論文強調的是通用能力與工具使用，不是效率——8B 打 4-5B，理論上該贏，贏多少是個問號。
懸念二：MLX backend 的延遲代價有多大？ Qwen3 技術報告完全沒提到 backend，這是實測要補的空白——Apple 自家框架在 Apple Silicon 上該有主場優勢，但目前找不到任何官方文件量化這個優勢的大小。
明天先拆 LLM 評測方法論的三代演化，週三揭曉 Route A 的真實排名——以及哪個文獻預測站不住腳。