分類: 🤖 AI 與自動化

你想在本地跑 AI 模型，但不知道哪款模型值得裝？硬體夠不夠？開 Thinking 模式到底有沒有差？這篇文章用實際跑出來的數據回答這三個問題——五款模型 × 兩台機器 × 三種設定，全部實測，沒有廣告。

測試環境分別是一台平價 Mini PC（Ryzen 7 4700U，16GB RAM，CPU-only）和 MacBook Air M3（24GB 統一記憶體）。七道測試題涵蓋：文字理解、Python 程式碼生成、SQL 查詢、TCP 技術解釋等真實使用情境。

測試環境規格

重點摘要表（先看這三張表）

表 1：Mini PC 五款模型速度與完成度對比

表 2：同款 gemma4:e4b，硬體差距

表 3：Mac 上同款模型，三種設定對比

第一層：Mini PC 上，哪個模型值得跑？

在只有 CPU 推論的環境下，選模型就是在「速度」與「品質」之間做取捨。以下是完整的三維評估。

Bonsai 8B：直接淘汰

Bonsai 8B 的速度是 0.001 tok/s——不是很慢，是根本無法執行。原因是它的量化版本依賴 AVX-512 指令集，而 Ryzen 7 4700U 不支援 AVX-512（只有 AVX2）。llama.cpp 在這種情況下會退回軟體模擬，速度接近零。如果你的機器是 Intel 第 11 代以後或 AMD Zen 4 以後，才有機會跑 Bonsai 8B。

qwen3:4b：最快但有截斷風險

qwen3:4b 在 Q1～Q7 七個量化等級測試中，平均跑出 0.78 tok/s，是 CPU 上可用模型裡的最高速。但在 num_predict=300 的限制下，Q2（程式碼生成）和 Q5（格式輸出）出現截斷或夾雜不相關文字的問題。如果你只需要短問短答，qwen3:4b Q6 量化（約 21 元台幣月費 API 等級）是最划算的選擇。

qwen3.5:9b vs qwen3:14b：9B 更快但 14B 更可靠

qwen3.5:9b 平均 0.57 tok/s，但 Q6/Q7 題遇到了 timeout 問題——需要將請求超時設定延長到 1800 秒才能完成。原因是 9B 模型在複雜任務上思考時間較長，但預設 timeout 不夠。

qwen3:14b 同樣 0.58 tok/s，卻跑出 7/7 完整答題率。它的 Q2 完整輸出 500 tokens、Q4 完整輸出 500 tokens，沒有截斷。代價是記憶體佔用更高，在 16GB 機器上跑 14B 模型時需要注意 KV Cache 可能 OOM（記憶體不足），建議設定 num_ctx 不超過 4096。

gemma4:e4b：速度最快的完整模型

gemma4:e4b 平均 1.45 tok/s，是所有可用模型中最快的，幾乎是 qwen3:14b 的 2.5 倍。在舊測試的 600 token 限制下，Q2 和 Q4 被截斷。但如果移除限制（num_predict=-1），這個問題就不存在——這正是下一層要說的。

Mini PC 選模型建議：

• 追求速度 → gemma4:e4b（1.45 tok/s，移除 token 限制）
• 追求品質 → qwen3:14b（7/7 完整，0.58 tok/s）
• 省記憶體 → qwen3:4b Q3/Q4（短任務夠用）
• 不建議 → Bonsai 8B（AVX-512 門檻）、qwen3.5:9b（需調 timeout）

第二層：同款模型，換台機器差多少？

用同款 gemma4:e4b，在 Mini PC 和 MacBook Air M3 上各跑一輪，看看換硬體能得到什麼。

速度差 6.7 倍，不只是快慢的問題

Mini PC 平均 1.45 tok/s，Mac 平均 9.75 tok/s。這個差距背後的原因是架構：Mini PC 用 x86 CPU 做矩陣運算，效率遠低於 Apple Silicon 的 Neural Engine + 統一記憶體架構。M3 的統一記憶體讓 CPU 和 GPU 共享同一塊 24GB，模型權重可以直接放在 GPU 能讀取的記憶體，不需要搬移。

記憶體夠，輸出才完整

這是硬體差距最直接的體現：Q2 要求生成一個能解析多種日期格式的 Python 函式，Mini PC 在 600 token 限制下就截斷了（回答還在中途），而 Mac 無限制跑出 2218 tokens 的完整函式。

Q4 要求生成帶有 CTE 和 Window Function 的複雜 SQL，Mini PC 截斷，Mac 輸出完整 1043 tokens 含說明。這不是模型能力的差異，是記憶體和 KV Cache 空間的差異。

24GB 統一記憶體的隱藏優勢：num_ctx 可拉到 65536+

num_ctx 決定模型能「看到」的上下文長度。Mini PC 的 16GB RAM 在跑 gemma4:e4b 時，實際可用的 KV Cache 空間有限，num_ctx 設太高就 OOM。Mac 的 24GB 統一記憶體可以輕鬆設定 num_ctx=65536，意味著可以貼入整個程式碼檔案、長文件、對話紀錄，模型不會「忘記」前面說了什麼。這個差距在實際工作流中比速度差距更重要。

第三層：同台機器，調設定差多少？

在 MacBook Air M3 上，用同款 gemma4:e4b 比較三種設定：舊測試的 600 token 限制、無限制（think:false）、開啟 Thinking 模式。

速度幾乎不變，但輸出長度和品質大幅提升

think:false 無限制：平均 9.75 tok/s。Thinking 開啟無限制：平均 9.16 tok/s。速度只差 6%，但輸出品質差距大：

• Q2（Python 程式碼）：2218 tokens → 3670 tokens（+65%），Thinking 版本多了完整的邊界條件處理和說明文字
• Q4（SQL 查詢）：1043 tokens → 1413 tokens（+35%），多了欄位說明和效能備注
• Q7（TCP 三次握手）：442 tokens → 990 tokens（+124%），Thinking 版本多了為何需要三次的深層解釋

Thinking 模式讓模型在回答前先「想」一遍，輸出的答案更完整、更有條理。對於技術問題、程式碼生成、複雜推理，這個設定幾乎是免費的品質提升。

gemma4:e4b 全力展開：這就是本地 LLM 的真實上限

以下展示 Thinking 模式在 Mac 上的實際輸出，讓你判斷品質是否符合你的需求。

Q2 Thinking：完整的多格式日期解析函式

問題：「寫一個 Python 函式，能解析 YYYY-MM-DD、YYY/MM/DD（民國年）、YYYYMMDD（8位）、YYYMMDD（7位民國年）四種格式。」

Thinking 模式輸出 3670 tokens，以下是完整的函式程式碼：

from datetime import datetime
import re

def parse_mixed_date_string(date_str: str) -> datetime:
    if not isinstance(date_str, str):
        raise TypeError("輸入必須是字串 (string) 格式。")
    date_str = date_str.strip()

    # 模式 A: YYYY-MM-DD
    if re.fullmatch(r'\d{4}-\d{2}-\d{2}', date_str):
        try:
            return datetime.strptime(date_str, "%Y-%m-%d")
        except ValueError:
            pass

    # 模式 B: YYY/MM/DD（含民國年）
    if re.search(r'[/]', date_str):
        parts = date_str.split('/')
        if len(parts) == 3:
            year, month, day = parts[0], parts[1], parts[2]
            try:
                temp_date_str = f"{year.zfill(4)}-{month.zfill(2)}-{day.zfill(2)}"
                return datetime.strptime(temp_date_str, "%Y-%m-%d")
            except ValueError:
                pass

    # 模式 C: YYYYMMDD（8位）
    if re.fullmatch(r'\d{8}', date_str):
        try:
            return datetime.strptime(date_str, "%Y%m%d")
        except ValueError:
            pass

    # 模式 D: YYYMMDD（7位民國年）
    if re.fullmatch(r'\d{7}', date_str):
        try:
            year = date_str[:-4]
            month = date_str[-4:-2]
            day = date_str[-2:]
            temp_date_str = f"{year.zfill(4)}-{month}-{day}"
            return datetime.strptime(temp_date_str, "%Y-%m-%d")
        except ValueError:
            pass

    raise ValueError(f"無法識別或解析的日期格式：'{date_str}'")

非 Thinking 模式在同題只輸出 2218 tokens，函式邏輯正確但缺少邊界案例說明和型別標注說明。Thinking 版本多的那 1452 tokens 全是有用的：錯誤處理說明、邊界條件討論、使用範例。

Q4 Thinking：帶 CTE 和視窗函數的複雜 SQL

問題：「找出每個城市近 30 天消費金額前三名的顧客，輸出城市、姓名、消費總額。」

WITH RecentSpending AS (
    SELECT o.customer_id, SUM(o.amount) AS total_spending
    FROM orders o
    WHERE o.created_at >= DATE_SUB(CURDATE(), INTERVAL 30 DAY)
    GROUP BY o.customer_id
),
RankedCustomers AS (
    SELECT c.name, c.city, rs.total_spending,
        RANK() OVER (PARTITION BY c.city ORDER BY rs.total_spending DESC) as city_rank
    FROM RecentSpending rs
    JOIN customers c ON rs.customer_id = c.id
)
SELECT city, name, total_spending
FROM RankedCustomers
WHERE city_rank <= 3
ORDER BY city, city_rank;

Thinking 版本（1413 tokens）在 SQL 後面額外附上了欄位說明對照表、RANK vs DENSE_RANK 的差異說明、以及在資料量大時建議加索引的備注。這種「自動補充說明」的行為，在程式碼審查或教學場景特別有用。

Q7 Thinking：TCP 三次握手的技術解釋

問題：「解釋 TCP 三次握手的過程，並說明為什麼需要三次而不是兩次。」

Thinking 模式的回答（節錄，990 tokens）：

TCP 三次握手是在兩台設備開始傳輸實際資料之前，建立穩定可靠連線的過程：

1. Client → Server (SYN)：「我想連線，序列號從 X 開始」
2. Server → Client (SYN-ACK)：「我收到了，我也準備好，序列號從 Y 開始」
3. Client → Server (ACK)：「我收到你的確認，正式連線」

為何需要三次而不是兩次：三次握手確保雙方的「發送能力」和「接收能力」都得到驗證。第三次 ACK 讓客戶端確認成功收到伺服器的肯定回應，確保雙方對初始序列號達成共識。若只有兩次，Server 無法確認 Client 是否真的收到了 SYN-ACK，可能導致半開連線（half-open connection）堆積。

非 Thinking 模式（442 tokens）的回答只覆蓋了步驟本身，沒有解釋半開連線問題。Thinking 版本的 990 tokens 多出了協議設計的「為什麼」。

技術踩坑筆記

坑 1：AVX-512 問題不是模型 bug，是 CPU 選錯了

Bonsai 8B 需要 AVX-512，AMD Ryzen 4000 系列（Zen 2 架構）不支援。解法：換用 AVX2 相容的量化版本，或換到支援 AVX-512 的 CPU（Intel 11th Gen+、AMD Zen 4+）。在買 Mini PC 跑本地 LLM 之前，先確認 CPU 指令集支援情況。

坑 2：num_predict=300 在 CPU 機器上是陷阱

設 num_predict=300 看起來是「省時間」，但會讓程式碼生成等長輸出任務的測試結果完全失效。正確做法是設 num_predict=-1（無限制），然後觀察模型自然停止的位置。如果真的需要截斷，至少設到 1000 以上再做程式碼類測試。

坑 3：qwen3.5:9b 的 timeout 問題

qwen3.5:9b 在 Q6（長文生成）和 Q7（技術解釋）上，Ollama 預設的請求 timeout 不夠，導致連線中斷而不是模型輸出完成。解法：在呼叫 API 時設定 timeout 參數為 1800 秒，或在 Ollama 的環境變數中調整 OLLAMA_TIMEOUT。

坑 4：KV Cache OOM 發生在 num_ctx 設太高時

在 16GB 機器上跑 qwen3:14b，如果 num_ctx 設到 8192 以上，KV Cache 的記憶體需求會超過可用 RAM，導致 OOM 或系統卡死。建議 16GB RAM 跑 14B 模型時，num_ctx 不超過 4096；跑 4B 模型時，num_ctx 可以到 8192。

坑 5：think:false 是必要的，否則輸出會混入思考過程

qwen3 系列模型如果不設定 think:false，輸出會包含 <think> 標籤包裹的推理過程，混在正式答案裡，對程式解析造成困擾。在 Ollama API 呼叫時加上 "options": {"think": false}，或使用 /set parameter think false。只有在你明確需要 Thinking 輸出時才開啟。

坑 6：num_predict 是物理截斷，不是智慧壓縮

很多人以為設 num_predict=600 會讓模型「給出精簡版本」，實際上不是。模型不知道 num_predict 這個參數的存在——它只是一個一個往下生成 token，到達上限時被外力硬切斷。結果是：程式碼寫到一半沒有結尾大括號、SQL 少了 WHERE 條件、解釋說到一半消失。

這次測試的 Q2（日期解析函數）和 Q4（SQL 排名查詢）在 num_predict=300 時全數截斷就是這個原因。移除限制（num_predict=-1）之後，模型自然停止，輸出完整。

坑 7：有些內容本質上無法壓縮到指定長度內

假設你問模型「給我一份完整 Kafka 設定檔，限制 50 個 token 內」——這兩個要求本身就互相矛盾。一份能正常運作的 Kafka 設定檔，光是必要欄位就需要遠超 50 token。模型沒有辦法把磚頭塞進比磚頭小的洞。

面對不可壓縮的內容，有三種做法：（1）直接移除 token 上限；（2）分步請求——先要最精簡模板，確認結構後再要完整版；（3）在 prompt 明確說「輸出必須完整可執行，不要省略任何欄位」，但前提是 token 上限本身要夠大。

補充：不同模型怎麼面對衝突指令？

這裡有個值得理解的差異：本地模型（Ollama + llama.cpp）的 token 限制來自 API 參數，是硬體截斷，模型本身完全不知道有這個限制存在。雲端模型（Claude、GPT-4 等）的「限制」則來自 prompt 文字指令，模型讀到這個指令後會嘗試推理你的真實意圖。

這個差異的實際意義是：在本地 LLM 環境下，token limit 是你唯一能控制輸出長度的工具，設太小就會截斷。雲端模型則更像是在和一個理解你意圖的人對話——你不需要精準計算 token，只需要把你真正想要的說清楚。

進階應用：讓本地 LLM 記住對話上下文

本地 LLM 的 API 呼叫預設是無狀態的——每次送出的是獨立的單輪問答，模型不記得你上一題問了什麼。如果你想做多輪對話助理、程式碼審查工具、或任何需要「記住脈絡」的應用，就需要自己管理對話歷史。

為什麼不能無限加長 messages？

標準做法是把整段對話歷史塞進 messages 陣列一起送出。但對話越長，messages 陣列越大，最終超過 num_ctx 上限，前面的對話就會被硬截斷——模型在不知情的狀況下「失憶」，不會告訴你它看不到前面的內容。

解法不是把 num_ctx 設更大（那只是延後問題），而是主動管理 messages 陣列：用摘要壓縮舊對話，只保留近期原文加上一段精簡的歷史摘要。

三種管理策略比較

摘要壓縮的運作方式

核心思路是：用同一個本地模型來摘要自己的舊對話。超過門檻後，把早期輪次壓縮成一段文字，之後每次送出時帶著「摘要 + 近期原文」，而不是全部歷史。

第 1-8 輪：原文保存在 messages[]

第 9 輪觸發壓縮：
  old[1-5輪] → summarize() → "重點：xxx, yyy, zzz"
  messages 只留 [6-8輪原文] + 新問題

第 9 輪實際送出的內容：
  system: "對話背景摘要：重點 xxx, yyy, zzz"
  user(6): ...  ai(6): ...
  user(7): ...  ai(7): ...
  user(8): ...  ai(8): ...
  user(9): 現在的問題

完整 Python 實作（本地 Ollama 版）

import json, urllib.request

MAC_URL = "http://192.168.1.xxx:11434/api/chat"  # Mac 的 Ollama，Mini PC 不跑本地模型
MODEL  = "gemma4:e4b"

def call_model(messages, think=False):
    payload = {
        "model": MODEL,
        "messages": messages,
        "stream": False,
        "think": think,
        "options": {"num_ctx": 4096, "num_predict": -1}
    }
    data = json.dumps(payload).encode()
    req = urllib.request.Request(
        MAC_URL, data=data,
        headers={"Content-Type": "application/json"}
    )
    with urllib.request.urlopen(req, timeout=300) as r:
        return json.loads(r.read())["message"]["content"]

def summarize(messages):
    """把舊對話丟給模型，壓縮成條列式重點"""
    history_text = "\n".join(
        f"{'User' if m['role'] == 'user' else 'AI'}: {m['content']}"
        for m in messages
    )
    prompt = f"""以下是一段對話記錄，請用條列式摘要最重要的資訊、結論、已確認的事實。
保留具體數字、決策、技術細節。100字以內。

對話：
{history_text}

摘要："""
    return call_model([{"role": "user", "content": prompt}])

class ChatSession:
    def __init__(self, keep_recent=4, compress_threshold=8):
        self.messages = []
        self.summary = ""               # 累積摘要
        self.keep_recent = keep_recent             # 保留最近幾輪原文
        self.compress_threshold = compress_threshold   # 超過幾輪就壓縮

    def chat(self, user_input):
        self.messages.append({"role": "user", "content": user_input})

        # 超過門檻 → 壓縮舊對話
        if len(self.messages) > self.compress_threshold:
            old = self.messages[:-self.keep_recent]
            new_summary = summarize(old)

            # 把舊摘要 + 新摘要合併
            self.summary = f"{self.summary}\n{new_summary}".strip()
            self.messages = self.messages[-self.keep_recent:]
            print(f"[已壓縮，摘要更新：{len(self.summary)} chars]")

        # 組合本次送出的 messages
        send_messages = []
        if self.summary:
            send_messages.append({
                "role": "system",
                "content": f"對話背景摘要（已發生的重點）：\n{self.summary}"
            })
        send_messages.extend(self.messages)

        response = call_model(send_messages)
        self.messages.append({"role": "assistant", "content": response})
        return response

# 使用方式
if __name__ == "__main__":
    session = ChatSession(keep_recent=4, compress_threshold=8)
    while True:
        user = input("你：").strip()
        if user.lower() == "exit":
            break
        reply = session.chat(user)
        print(f"AI：{reply}")
        if session.summary:
            print(f"[背景摘要：{len(session.summary)} chars]")

效能調優：摘要用小模型，回答用大模型

摘要這個步驟本身也消耗一次推理呼叫。如果 Mac 上同時有快慢兩個模型，可以分工：快的模型做摘要，慢的（品質更好的）做正式回答：

MAIN_MODEL    = "qwen3:14b"   # 回答主要問題，品質優先
SUMMARY_MODEL = "qwen3:4b"   # 做摘要，速度優先（簡單任務夠用）

def summarize(messages):
    # 使用小模型做摘要
    payload = {
        "model": SUMMARY_MODEL,
        ...
    }

這樣摘要時間從數十秒縮短到幾秒，而主要對話品質不受影響。MacBook Air M3 速度夠快（9+ tok/s），用同一個模型做摘要也無妨。

日常應用：把 Mac 當成你的私人 AI 主機

gemma4:e4b 在 MacBook Air M3 上跑出 9+ tok/s，這個速度對互動式日常使用完全夠用——不是只能跑 benchmark，而是可以當成隨時待命的個人助理。重點是：所有資料留在本機，不送雲端，不計費。

架構很簡單：Mini PC 負責發問和顯示，Mac 負責思考和回答。Mini PC 本身不跑模型，只是一個入口。

你（Mini PC）→ 問題 → Mac gemma4 → 回答 → 你

Mini PC：入口，不思考
Mac：腦子，負責推理

兩個最常用的場景

場景一：快速摘要

把一篇文章、一份 log、一段程式碼丟給 Mac，要它用幾句話說重點。不需要 Claude 等級的推理，gemma4 速度更快、更省錢（免費）。

#!/usr/bin/env python3
# summarize.py — 從 stdin 讀內容，打到 Mac gemma4 要摘要
# 用法：cat article.txt | python3 summarize.py
#       cat error.log   | python3 summarize.py --prompt "這份 log 的錯誤原因是什麼"

import json, sys, urllib.request, argparse

MAC_URL = "http://192.168.1.xxx:11434/api/chat"
MODEL   = "gemma4:e4b"

parser = argparse.ArgumentParser()
parser.add_argument("--prompt", default="請用5句話以內摘要以下內容的重點：")
args = parser.parse_args()

content = sys.stdin.read().strip()
if not content:
    print("ERROR: no input"); sys.exit(1)

payload = {
    "model": MODEL,
    "messages": [{"role": "user", "content": f"{args.prompt}\n\n{content}"}],
    "stream": False, "think": False,
    "options": {"num_ctx": 8192, "num_predict": -1},
}
req = urllib.request.Request(
    MAC_URL, data=json.dumps(payload).encode(),
    headers={"Content-Type": "application/json"},
)
with urllib.request.urlopen(req, timeout=300) as r:
    print(json.loads(r.read())["message"]["content"])

# 使用範例
cat ~/Downloads/article.txt   | python3 summarize.py
cat /var/log/app.log          | python3 summarize.py --prompt "這份 log 有什麼異常？"
git diff HEAD~5               | python3 summarize.py --prompt "這幾個 commit 改了什麼？"

場景二：快速產程式驗證

想驗證一個想法、寫一段臨時腳本、或確認某個 API 用法——不需要開 IDE，直接從命令列問 Mac，幾秒鐘拿到可以跑的程式碼片段。

#!/usr/bin/env python3
# ask.py — 命令列直接問 Mac，拿回程式碼或答案
# 用法：python3 ask.py "寫一個 Python 函數，把 list 裡的重複元素移除但保留順序"
#       python3 ask.py "用 curl 怎麼測試一個需要 Bearer token 的 API"

import json, sys, urllib.request

MAC_URL = "http://192.168.1.xxx:11434/api/chat"
MODEL   = "gemma4:e4b"

question = " ".join(sys.argv[1:])
if not question:
    print("Usage: python3 ask.py \"your question\""); sys.exit(1)

payload = {
    "model": MODEL,
    "messages": [{"role": "user", "content": question}],
    "stream": False, "think": False,
    "options": {"num_ctx": 4096, "num_predict": -1},
}
req = urllib.request.Request(
    MAC_URL, data=json.dumps(payload).encode(),
    headers={"Content-Type": "application/json"},
)
with urllib.request.urlopen(req, timeout=300) as r:
    print(json.loads(r.read())["message"]["content"])

# 使用範例
python3 ask.py "寫一個 bash script，每天早上備份 ~/Documents 到外接硬碟"
python3 ask.py "Python requests 怎麼設定 retry 和 timeout"
python3 ask.py "這個 SQL 有什麼問題：SELECT * FROM orders WHERE date > NOW() - 30"

什麼時候還是要 Claude

原則是：不需要記憶 codebase、不需要複雜推理的任務，都可以先試 Mac。速度快、免費、資料不出門。遇到 Mac 答不好的，再升到 Claude。

進階應用二：Mini PC + Mac 混合架構，讓 Agent Team 更有效率

角色定義（固定，不隨任務改變）

Mini PC  → 純指揮中心：跑 Claude Code、管理 Agent Team、處理串接邏輯
           不跑任何本地模型，資源用在穩定性和協調上

Mac      → 推理後端：跑 Ollama + gemma4:e4b
           只負責生成，不做決策

Claude API → 審查 + 架構：程式碼審查、複雜邏輯、跨檔案推理
             Mini PC 透過網路呼叫，不在本地

規則：Mac 不在線 → fallback 給 Claude API，不是 Mini PC 自己跑

當你用 Claude Code 的 Agent Team 跑自動化程式開發時，會面對一個現實問題：Claude API 的費用隨 token 用量線性增長，而很多任務其實不需要 Claude 的完整推理能力——DTO 生成、CRUD 樣板、SQL migration 這類結構性重複工作，本地的 gemma4:e4b 就能處理。

解法是把 Mac 當成 Agent Team 的「草稿後端」：Claude Agent 負責架構決策和程式碼審查，Mac gemma4 負責產生第一版草稿，再由 Claude 驗證整合。

架構分工

前置設定：讓 Mac 的 Ollama 對區網開放

Ollama 預設只監聽本機。在 Mac 上把它開放給區網，Mini PC 才能連進來：

# Mac 上執行（停掉 Ollama app 後）
OLLAMA_HOST=0.0.0.0 ollama serve

# 從 Mini PC 驗證是否連得到（換成 Mac 的區網 IP）
curl http://192.168.1.xxx:11434/api/tags

不想暴露 port 的話，用 SSH Tunnel：Mini PC 上執行 ssh -L 11435:localhost:11434 [email protected] -N，之後打 localhost:11435 就等於打 Mac 的 Ollama。

工具腳本：mac_draft.py

Agent 透過 Bash tool 呼叫這支腳本，傳入任務描述，拿回草稿程式碼。腳本會自動檢查 Mac 是否在線，不在線就回傳 exit code 1，讓 Agent 自行處理 fallback。

#!/usr/bin/env python3
"""
mac_draft.py — Call Mac's local gemma4 for code draft generation.

Usage:
    python3 mac_draft.py "write a SQLAlchemy User model with id, name, email"
    python3 mac_draft.py --task "CRUD for User" --context "FastAPI, SQLAlchemy async"

Exit codes:
    0 = success, draft printed to stdout
    1 = Mac unreachable → fallback: implement with Claude directly
    2 = model error
"""
import json, sys, urllib.request, urllib.error, argparse

MAC_HOST = "http://192.168.1.xxx:11434"   # 改成 Mac 的實際 IP
MODEL    = "gemma4:e4b"
TIMEOUT  = 600

SYSTEM_PROMPT = """You are a code generation assistant. Output ONLY code —
no explanations, no markdown fences, no comments unless essential.
The output will be reviewed and integrated by another agent."""

def check_reachable():
    try:
        with urllib.request.urlopen(f"{MAC_HOST}/api/tags", timeout=5):
            return True
    except Exception:
        return False

def generate(task, context=""):
    prompt = f"Context: {context}\n\nTask: {task}" if context else task
    payload = {
        "model": MODEL,
        "messages": [
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user",   "content": prompt},
        ],
        "stream": False, "think": False,
        "options": {"num_ctx": 4096, "num_predict": -1},
    }
    data = json.dumps(payload).encode()
    req  = urllib.request.Request(
        f"{MAC_HOST}/api/chat", data=data,
        headers={"Content-Type": "application/json"},
    )
    with urllib.request.urlopen(req, timeout=TIMEOUT) as r:
        return json.loads(r.read())["message"]["content"]

parser = argparse.ArgumentParser()
parser.add_argument("task", nargs="?")
parser.add_argument("--task", dest="task_flag")
parser.add_argument("--context", default="")
args = parser.parse_args()

task = args.task or args.task_flag
if not task:
    print("ERROR: no task provided", file=sys.stderr); sys.exit(1)

if not check_reachable():
    print(f"MAC_UNREACHABLE: {MAC_HOST}. Fallback: implement with Claude.",
          file=sys.stderr); sys.exit(1)

try:
    print(generate(task, args.context))
except Exception as e:
    print(f"ERROR: {e}", file=sys.stderr); sys.exit(2)

Agent 的實際使用流程

# Agent (sonnet) 在 Bash tool 中這樣呼叫：

# 1. 請 Mac 出草稿
draft=$(python3 ~/llm-benchmark/scripts/mac_draft.py \
  --task "generate SQLAlchemy User model" \
  --context "PostgreSQL, async, Pydantic v2")

# 2. 檢查是否成功
if [ $? -ne 0 ]; then
  echo "Mac unavailable, implementing directly"
  # Claude 自己寫
fi

# 3. 草稿給 Claude 審查後整合進 codebase
echo "$draft"  # Claude 讀到這裡，決定是否採用、修改哪裡

告訴 Agents 這條規則：寫入 AGENTS.md

Claude Code 的 Agent Team 每個 subagent 啟動時沒有對話歷史。規則要寫進 AGENTS.md，agent 才會在每次任務開始時讀到它。在專案的 AGENTS.md 加上這個區塊：

## Mac Draft Resource (Local LLM Offload)

Mac (gemma4:e4b) is available as a fast code draft generator.
Tool: python3 ~/llm-benchmark/scripts/mac_draft.py

Use Mac draft BEFORE writing code yourself for:
- DTO / model class boilerplate      ✅
- CRUD endpoints (standard pattern)  ✅
- SQL migration scripts              ✅
- Unit test scaffolding              ✅

Do NOT use Mac draft for:
- Complex business logic             ❌ (no codebase context)
- Security-sensitive code            ❌ (unreliable)
- Cross-file refactoring             ❌ (no context)
- Architecture decisions             ❌ (use opus)

Workflow:
1. Call mac_draft.py with task description
2. exit code 1 (MAC_UNREACHABLE) → implement with Claude directly
3. Review draft: check patterns, imports, logic, security
4. Integrate into codebase

Mac generates the shape. Claude ensures it fits.

這樣每個 subagent 都會知道「遇到樣板類任務先叫 Mac 出草稿」，不需要每次重新交代規則。

結論與推薦

本次測試跨越三個維度，每層都有明確的答案：

Mini PC + Mac 混合架構的定位

Mini PC 的角色是指揮中心，不是推理引擎。它跑 Claude Code、管理 Agent Team、處理串接邏輯，資源用在穩定性和協調上。推理工作全部交給 Mac 的 gemma4:e4b。

• 日常問答 / 摘要：Mini PC 發問 → Mac gemma4 回答，免費、快速、資料不出門
• 草稿程式碼：Agent 呼叫 mac_draft.py → Mac 出草稿 → Claude 審查整合
• 複雜推理 / 架構決策：直接用 Claude API，不走 Mac
• Mac 不在線：fallback 給 Claude API，Mini PC 本身不需要跑任何模型

如果你的情境是 Mini PC 獨立運作（沒有 Mac），模型選擇建議：gemma4:e4b 速度最快（1.45 tok/s）、qwen3:14b 完成度最高（7/7 全答）、qwen3:4b 最省記憶體。但這個架構的速度上限就是 CPU 推論，不如 Mac 的 Apple Silicon。

MacBook Air M3 的最佳設定

• 日常程式碼：think:false，num_predict=-1，9.75 tok/s，輸出完整
• 複雜推理/技術解釋：Thinking 開啟，速度只慢 6%，品質提升明顯
• 長文件處理：設定 num_ctx=65536，充分利用 24GB 統一記憶體

本地 LLM 的真實上限在哪裡？

gemma4:e4b 在 MacBook Air M3 + Thinking 模式下，輸出品質接近 GPT-3.5 的水準——在程式碼生成、SQL 查詢、技術解釋這些結構清晰的任務上。它不是 GPT-4，創意寫作和跨領域推理還是有差距，但對開發者的日常工作場景已經夠用。

真正的瓶頸不是模型大小，而是硬體架構。同款模型在 Apple Silicon 上跑出的效果，在 x86 CPU 上根本發揮不出來。如果你認真考慮本地 LLM，MacBook Air M3 是目前性價比最高的入門選擇；Mini PC 路線則需要搭配 NVIDIA GPU（VRAM ≥ 8GB）才能真正發揮。