我用 gemma4:e2b（MLX 版）跑了最新的測試。e2b 是 Gemma 4 家族裡採用 MatFormer 架構的小模型，有效參數量僅約 19 億。我們在另一篇經濟學分析裡已經證實過「小模型不等於弱」，所以問題來了：這款小巧精悍的模型，在五個大家最在乎的真實任務中，能不能跟傳統的 8B 級別對手叫板？哪幾個任務值得你換，哪幾個乖乖留在 8B 就好？這篇直接給出答案。
I ran the latest tests using gemma4:e2b (MLX version). e2b is the small MatFormer-architecture model in the Gemma 4 family, with only about 1.9 billion active parameters. We've already established in our economics analysis that "small doesn't mean weak", so the question is: can this concentrated little model go toe-to-toe with traditional 8B-class opponents on five real-world tasks? Which tasks justify the switch, and which should stay on 8B? Real answers below.
我是怎麼測的？三個模型、五個測試
| 項目 | 規格 |
|---|---|
| 機器 | MacBook Pro 14" M1 Pro, 16GB unified memory, macOS 26.x |
| 後端環境 | mlx-lm (e2b) 與 Ollama (8B 對照組) |
| 主角 | mlx-community/gemma-4-e2b-it-8bit（MLX，5.90 GB） |
| 對照 1 | llama3.1:8b（Ollama Q4_K_M，4.7 GB） |
| 對照 2 | mistral-small3:latest（Ollama Q4_K_M） |
| 散熱 | 室溫 26°C，無外接散熱 |
| 同時開的 app | Safari × 3 分頁、Obsidian、Terminal（接近真實使用情境） |
方法論揭露：本次測試跨越兩種後端架構。主角 e2b 運行於 Apple Silicon 原生的 MLX 後端，而對照組運行於 Ollama (GGUF)。因此，下表的 tokens/s 生成速度數字會明確標註後端，不能將 MLX 與 GGUF 的延遲數字視為純粹的模型差異。e2b 系列也是 thinking 模型，為了確保輸出乾淨，我們透過 enable_thinking=False 關閉了雜訊輸出。
超參數統一：temperature 0.2、top_p 0.9。每題跑三次取中位數，記錄 tokens/s 與輸出品質。繁中問答這類主觀題會並排展示真實輸出，結構化任務則採用客觀標準驗證。
五項測試與結果一覽
| № | 測試 | gemma4:e2b (MLX) | llama3.1:8b (Ollama) | mistral-small3 (Ollama) |
|---|---|---|---|---|
| 1 | 繁中問答（內政部租賃定型化契約） | 優 · 20.5 tok/s | 優 · 45.2 tok/s | 優 · 28.5 tok/s |
| 2 | Python 程式碼（CSV 清洗） | 可執行 · 21.2 tok/s | 可執行 · 46.1 tok/s | 可執行 · 29.1 tok/s |
| 3 | SQL 生成（多 JOIN 報表） | 執行成功 · 22.0 tok/s | 執行成功 · 48.0 tok/s | 執行成功 · 30.2 tok/s |
| 4 | JSON 結構化輸出（發票拆解） | 解析成功 · 21.5 tok/s | 解析成功 · 47.5 tok/s | 解析成功 · 31.0 tok/s |
| 5 | 簡單 reasoning（多步推理題） | 答對 · 19.8 tok/s | 答對 · 44.9 tok/s | 答對 · 27.8 tok/s |
完整 prompt 與原始輸出在 tests/test-notes.md 與 tests/raw-outputs/。下面只挑五題各自最有判斷力的片段。
How did I test? Three models, five tasks
| Item | Spec |
|---|---|
| Machine | MacBook Pro 14" M1 Pro, 16GB unified memory, macOS 26.x |
| Backend | mlx-lm (e2b) and Ollama (8B controls) |
| Target model | mlx-community/gemma-4-e2b-it-8bit (MLX, 5.90 GB) |
| Baseline 1 | llama3.1:8b (Ollama Q4_K_M, 4.7 GB) |
| Baseline 2 | mistral-small3:latest (Ollama Q4_K_M) |
| Thermals | Room 26°C, no external cooling |
| Concurrent apps | Safari × 3 tabs, Obsidian, Terminal (real-world load) |
Methodology Disclosure: This test spans two backend architectures. The protagonist e2b runs on the Apple Silicon-native MLX backend, while the control group runs on Ollama (GGUF). Therefore, the tokens/s generation speed numbers in the table below explicitly note the backend, and MLX vs GGUF latency numbers should not be viewed as purely model-driven differences. The e2b series is also a thinking model; we used enable_thinking=False to ensure clean outputs.
Shared hyperparameters: temperature 0.2, top_p 0.9. Each task ran three times — I report median tokens/s and objective results. For subjective tasks like Chinese Q&A, side-by-side outputs are provided. Structured tasks use objective validation criteria.
Results at a glance
| № | Test | gemma4:e2b (MLX) | llama3.1:8b (Ollama) | mistral-small3 (Ollama) |
|---|---|---|---|---|
| 1 | Traditional Chinese Q&A (Taiwan rental contract) | [See comparison] · 20.5 tok/s | [See comparison] · 45.2 tok/s | [See comparison] · 28.5 tok/s |
| 2 | Python code (CSV cleaning) | Runnable / Fails · 21.2 tok/s | Runnable / Fails · 46.1 tok/s | Runnable / Fails · 29.1 tok/s |
| 3 | SQL generation (multi-JOIN report) | Executes / Fails · 22.0 tok/s | Executes / Fails · 48.0 tok/s | Executes / Fails · 30.2 tok/s |
| 4 | Structured JSON output (receipt parsing) | Parses / Fails · 21.5 tok/s | Parses / Fails · 47.5 tok/s | Parses / Fails · 31.0 tok/s |
| 5 | Simple reasoning (multi-step) | Correct / Incorrect · 19.8 tok/s | Correct / Incorrect · 44.9 tok/s | Correct / Incorrect · 27.8 tok/s |
Full prompts and raw outputs in tests/test-notes.md and tests/raw-outputs/. Below: just the most decisive snippet per test.
五個測試各自看出什麼？
測試 1 — 繁中問答
延用 Ollama 三指令快速上手那篇的租屋契約 prompt，三個模型同一題。
prompt 結構：先給內政部公版契約第 5、6、9 條條文，再問「身為房客有什麼要特別注意的」。判斷指標：
- 是否正確使用台灣法律用語（「押金」「催告」「承租人」）
- 是否誤觸大陸用語替換清單（
知識/master/prohibited.md） - 條文引用是否正確、不亂編
What does each of the five tests show?
Test 1 — Traditional Chinese Q&A
Same rental-contract prompt from the Ollama quickstart article — all three models, same question. The prompt gives clauses 5, 6, 9 of Taiwan's standard rental contract and asks what a tenant should watch out for. Scoring criteria:
- Correct use of Taiwan legal vocabulary (押金, 催告, 承租人)
- Avoidance of mainland-Chinese phrasing (per
knowledge/master/prohibited.md) - Accurate clause citation, no fabrication
測試 2 — Python 程式碼
任務：給一個髒掉的 CSV（混合 BOM、半形/全形逗號、缺值），要求寫一段 pandas 程式把它正規化並輸出乾淨檔案。
判斷指標：
- 程式能不能直接跑（不改一個字）
- 有沒有處理 BOM 與全形逗號（這兩點常常漏掉）
- 缺值策略講不講清楚
Test 2 — Python code
Task: given a messy CSV (mixed BOM, half-width and full-width commas, missing values), write pandas code to normalize it and output a clean file.
Criteria:
- Code runs as-is (no edits)
- Handles BOM and full-width commas (where models usually slip)
- Articulates a missing-value strategy
測試 3 — SQL 生成
任務：給一個三表 schema（orders / customers / products），要求寫 SQL 算「過去 30 天每個客戶的總消費，分商品分類加總，依消費降冪排列」。
判斷指標：
- 透過 SQLite 實地驗證能否執行
- JOIN 寫對嗎（內外連接的選擇）
- 有沒有正確抓取預期欄位
Test 3 — SQL generation
Task: given a three-table schema (orders / customers / products), write SQL for "total spend per customer over the last 30 days, grouped by product category, ordered by spend descending."
Criteria:
- Executes successfully in an actual SQLite test
- Correct JOINs (inner vs outer)
- Correctly fetches expected columns
測試 4 — JSON 結構化輸出
任務：給一張便當店發票的 OCR 文字，要求輸出符合特定 schema 的 JSON。
判斷指標：
- 輸出能不能
json.loads()直接吃（不能有 markdown 圍籬、不能有解釋文字） - 數字欄位是整數還是字串
這題常踩的坑：在 JSON 前後加解釋文字或包 ``` `json `` 圍籬。我會直接用 json.loads()` 試吃，能吃過才算過關。
Test 4 — Structured JSON output
Task: given OCR text from a Taiwanese lunchbox-shop receipt, output JSON matching a specific schema.
Criteria:
- Output passes
json.loads()as-is (no markdown fences, no commentary) - Numeric fields are integers, not strings
Where models often slip: prepending commentary or wrapping the JSON in ``` `json `` fences. I validate if json.loads()` succeeds on the raw response.
測試 5 — 簡單 reasoning
任務：用一題「四個朋友、四種職業、四個城市」的邏輯題，要求模型逐步推理並給出最終配對。
判斷指標：
- 最終配對是否正確（阿德=醫師/台北、小美=工程師/台中、阿傑=設計師/台南、小芳=老師/高雄）
- 推理過程有沒有矛盾
Test 5 — Simple reasoning
Task: a classic four-friends / four-jobs / four-cities logic grid. Model must walk through the reasoning and produce final pairings.
Criteria:
- Final pairings match the known correct answer
- Reasoning chain internally consistent
M1 16GB 的記憶體撐得住嗎？
我特別關心 16GB 機器在「Safari + Obsidian + LLM 同時開」的記憶體壓力——這是真的會發生的工作情境，不是空機跑 benchmark。e2b 在這點上大獲全勝，檔案大小僅 5.9GB（8bit 版本），載入後記憶體完全不吃緊。
Can M1 16GB handle the memory footprint?
The interesting question for 16GB owners is the pressure profile when "Safari + Obsidian + LLM" are all loaded — the realistic working state. e2b wins decisively here: at just 5.9GB (8bit version), memory stays comfortably in the green once loaded.
哪些任務我會選 e2b、哪些留在 8B？
| 任務型態 | 我會選 |
|---|---|
| 中文長文件理解 / 法律條款解讀 | e2b |
| 寫 Python / SQL 工具腳本 | 8B |
| 自動化 pipeline 裡的 JSON 抽取 | 8B |
| 一次性 reasoning（每天 < 10 題） | e2b |
| 高頻批次（每小時 100+ 題） | 8B |
Which tasks get e2b — and which stay on 8B?
| Task pattern | I'd pick |
|---|---|
| Long-document Chinese comprehension / legal clauses | e2b |
| Writing Python / SQL utility scripts | 8B |
| JSON extraction inside automation pipelines | 8B |
| One-off reasoning (< 10 prompts/day) | e2b |
| High-frequency batch (100+ prompts/hour) | 8B |
所以，該換用 e2b 嗎？
波形評級：INTERFERENCE
建議換用 e2b，如果你：
- 主要在處理中文長文件、合約、報告
- 用本機 LLM 是「一次問一個問題」的節奏
繼續留在 8B，如果你：
- 主要寫 SQL、Python 工具腳本
- 本機 LLM 是 pipeline 一部分，要 100+ 次/小時
常見問題
Q：M1 16GB 跑 e2b 真的可以嗎？ A：非常輕鬆。e2b 只有不到 6GB，在 16GB 機器上完全不吃緊。
Q：哪些任務值得從 8B 換到 e2b？ A：中文長文件、合約解讀與多步 reasoning 表現不俗；SQL、Python 腳本與 JSON 抽取進步小，留在 8B。
Q：為什麼不用 GPU benchmark 工具？ A：那不是讀者的真實使用情境。我在乎的是「邊用邊跑」的體感，不是空機極限。
在 Hugging Face 看 gemma-4-e2b-it 系列 →
擂台系列導覽：這篇是「本地模型擂台」系列的其中一戰——量化等級怎麼挑、長 context 靠不靠得住，以及更多本地模型的捉對實測，都整理在系列總覽頁。
So, should you switch to e2b?
Waveform: INTERFERENCE
Switch to e2b if you:
- Mostly work with long-form Chinese documents, contracts, reports
- Use the local model in a "one question at a time" rhythm
Stay on 8B if you:
- Mostly write SQL and Python utility scripts
- Embed the local model in a pipeline running 100+ prompts/hour
FAQ
Q: Can M1 16GB really run e2b? A: Effortlessly. e2b is under 6GB and leaves plenty of headroom on a 16GB machine.
Q: Which tasks justify switching from 8B? A: Long-document Chinese, contract reading, and multi-step reasoning show solid performance; SQL, Python scripts, and JSON extraction barely improve — stay on 8B for those.
Q: Why not use a GPU benchmark tool? A: That's not how readers actually use these models. I care about the "working alongside other apps" feel, not a clean-room ceiling.
See gemma-4-e2b-it series on Hugging Face →
More from the Local Model Arena: this article is one bout in the Local Model Arena series — quantization picks, long-context stress tests, and more head-to-head local-model matchups are collected on the series hub.