標籤: llama.cpp

  • 用手機跑 128K AI 小助手:LFM2.5 實戰

    用手機跑 128K AI 小助手:LFM2.5 實戰

    📌 本文重點

    • LFM2.5-2.6B 支援 128K 長上下文,可一次處理整本文件
    • 內建多步驟 Agent 與 tool calling,可拆解任務自動執行
    • 量化後記憶體 < 2.5GB,手機 CPU 也能跑到 17–30 tok/s
    • 適合本地文件助理、批量任務與離線手機 AI 助理

    一台手機就能跑的長上下文 AI 小助手,幫你在本地處理文件、批量任務和簡易自動化,不靠雲端也能用得上 AI。

    參考來源:Reddit LocalLLaMA 討論LFM2.5-2.6B 發布帖OnePlus 13 實測,以及 Hugging Face 專題文:Deploy local agents everywhere with LFM2.5-2.6B


    核心功能:為什麼是「一台手機就能跑的 Agent」?

    1. 128K 長上下文:整本報告一次丟進去

    • 它是什麼:LFM2.5-2.6B 支援約 128K tokens 上下文,大約可以一次吃下數十萬字的內容。
    • 具體能做什麼
    • 整本 PDF 報告、技術文件、會議紀錄一次丟進去,讓模型幫你摘要、對比、找重點。
    • 長期對話不會「忘記前文」,可以當持續的工作助理。
    • 你可以馬上做的事
    • 準備 1–2 本常用的 PDF(如年度報告、專案文件),作為之後測試的資料集。

    💡 關鍵: 支援約 128K tokens 的長上下文,讓單次對話就能覆蓋整本報告或多份文件,減少來回上傳與分段處理的麻煩。

    2. 多步驟 Agent + 工具呼叫:不只是聊天,是能「自己拆步驟」的小幫手

    • 它是什麼:模型後訓練時就針對多步驟代理流程(multi-step agent workflows),並支援 tool calling 格式,能主動:
    • 判斷需要使用工具(如讀檔、發 API)。
    • 先規劃步驟,再分批完成任務。
    • 適合的工具類型
    • 檔案讀寫工具:讀取本地 txtmdpdf(先轉文字)。
    • Web API:查天氣、查匯率、打公司內部 API。
    • 你可以馬上做的事
    • 想一個「需要拆步驟」的工作流程,例如:整理一週郵件 → 分類 → 摘要 → 拉出待辦清單,留著稍後做 Agent 範例。

    3. 本地推理友善:記憶體 < 2.5GB,在手機 CPU 跑到 17–30 tok/s

    • 它是什麼:LFM2.5-2.6B 約 2.69B 參數,官方提供 Q4_K_M GGUF 量化版本,在手機上記憶體占用低於 2.5GB
    • 實測數據
    • Reddit 用戶在 OnePlus 13 手機上純 CPU 跑,約 17 tok/s
    • Liquid AI 官方報告在某些推理與工具調用基準上,和 Qwen 3.5 9B 類模型接近,但資源需求低很多。
    • 你可以馬上做的事
    • 確認自己的設備:RAM 至少 4GB(桌機 / 筆電更好),手機 Android 版本支援安裝第三方推理 App 或自訂引擎。

    💡 關鍵: 在純 CPU 手機上僅需不到 2.5GB 記憶體就能跑到約 17 tok/s,代表即使沒有高階 GPU,也能實際部署長上下文本地 AI。


    適合誰用:三個實戰場景

    1. 本地文件助理:長文閱讀、知識庫整理

    場景:你有大量 PDF 報告、技術文件,平常用雲端模型怕機密外流,或上傳很慢。

    可以怎麼用 LFM2.5

    1. 在桌機用 llama.cpp 跑 LFM2.5,讀取本地資料夾中的文件(轉成文字)。
    2. 把多份文件丟進同一個上下文,請它:
    3. 「幫我整理這三份報告的差異,列出一頁摘要+決策建議。」
    4. 「從這堆文件找出所有提到 2025 年預算的段落。」

    你可以立刻做的事

    • 整理一個 docs/ 資料夾,把 3–5 份常用文件轉成純文字(txt),準備接入 LFM2.5。

    2. 批量任務 Agent:整理郵件、報告、待辦清單

    場景:你每天有一堆重複的小事,例如「每週整理專案更新」、「把會議紀錄轉成待辦」。

    可以怎麼用 LFM2.5

    1. 寫一個簡單腳本從郵件或系統導出文字(如 weekly_emails.txt)。
    2. 讓 Agent 執行一套固定流程:
    3. 讀入所有文本 → 按專案或標籤分類。
    4. 每類輸出摘要與關鍵日期。
    5. 最後產生「本週待辦清單」。

    你可以立刻做的事

    • 決定一個你每週都在做的重複整理任務,想好輸入格式(例如一個大 txt),稍後在工具呼叫範例裡實作。

    3. 手機上的離線問答與簡易自動化

    場景:出差在外、網路不穩,也想有一個在手機上的「私人 AI 小助理」。

    可以怎麼用 LFM2.5

    1. 在手機安裝支援 GGUF 的本地推理 App(如某些社群版 llama.cpp App,或自行編譯)。
    2. 把常用資料(旅遊行程、公司 FAQ、個人筆記)放進手機,讓模型作為離線問答庫。
    3. 再加上幾個簡單工具:
    4. 查本地檔案(行程、備忘錄)。
    5. 呼叫 Web API(天氣、匯率)— 有網路時也能用。

    你可以立刻做的事

    • 在手機上預留至少 3–4GB 空間和足夠 RAM,並確認能安裝第三方推理 App 或有 adb 環境可連接自製引擎。

    怎麼開始:從桌機到手機,一步步實作

    步驟一:在 Hugging Face 下載模型與量化權重

    1. 打開 Hugging Face 模型頁:
    2. 搜尋 LFM2.5-2.6B 或直接從官方 Blog 連結進入:https://huggingface.co/LiquidAI
    3. 選擇 GGUF 格式(例如官方提到的 Q4_K_M 量化版本)。
    4. 使用 git lfs 或直接瀏覽器下載:

    bash
    git lfs install
    git clone https://huggingface.co/LiquidAI/lfm2-5-2-6b-gguf

    你可以立刻做的事

    • 安裝 git lfs,測試是否能順利 clone 大檔案。

    步驟二:用 llama.cpp 在桌機跑起來

    1. 安裝 llama.cpp

    bash
    git clone https://github.com/ggerganov/llama.cpp
    cd llama.cpp
    make

    1. 把剛下載的 GGUF 模型放到 ./models/lfm2-5-2-6b-q4_k_m.gguf
    2. 用基本推理指令測試:

    bash
    ./main \
    -m models/lfm2-5-2-6b-q4_k_m.gguf \
    -c 128000 \
    -n 256 \
    -p "你是一個中文助理,請用繁體中文回覆。幫我總結這段文字:..."

    你可以立刻做的事

    • 先把 -c 設小一點(例如 8192),確認能跑,再逐步拉高到 128K 測試極限。

    💡 關鍵: 先以較小上下文長度測試穩定性,再逐步拉高到 128K,可以避免一開始就因資源不足導致崩潰。

    步驟三:在手機或低端設備配置推理引擎

    你有兩條路可以選:

    方案 核心功能 免費方案 適合誰
    原生 llama.cpp 編譯 直接在 Android / Linux 編譯 llama.cpp,跑 GGUF 模型 開源免費 喜歡動手編譯、可用 adb 的技術玩家
    第三方推理 App 安裝社群開發的本地 LLM App,匯入 GGUF 模型 多數免費或開源 想快速在手機體驗本地 AI 的一般使用者

    大致步驟示意(原生編譯路線)

    1. 在桌機用 adb 連上 Android 手機,確認有 shell:

    bash
    adb shell

    1. 把編譯好的二進位與模型檔推上手機:

    bash
    adb push ./main /data/local/tmp/
    adb push ./models/lfm2-5-2-6b-q4_k_m.gguf /data/local/tmp/

    1. 在手機上跑:

    bash
    cd /data/local/tmp
    chmod +x main
    ./main -m lfm2-5-2-6b-q4_k_m.gguf -c 32768 -n 128 -p "請用繁體中文介紹你自己。"

    你可以立刻做的事

    • 測試一次 adb shell 是否正常;如果你偏好 GUI,搜尋一款支援 GGUF 的 LLM App,確認可以匯入模型檔。

    步驟四:串接簡單工具(檔案讀取 + Web API)

    LFM2.5 支援 tool calling 格式,你可以在自己的程式裡定義工具,讓模型決定何時呼叫。

    以下以 Python + llama.cpp HTTP 伺服器為例(概念示意):

    1. 先啟動 llama.cpp 的伺服器模式:

    bash
    ./server \
    -m models/lfm2-5-2-6b-q4_k_m.gguf \
    -c 128000 \
    --host 127.0.0.1 --port 8080

    1. 在 Python 定義兩個工具:讀檔與查匯率:

    python
    tools = [
    {
    "name": "read_file",
    "description": "讀取本地文字檔內容",
    "parameters": {
    "type": "object",
    "properties": {
    "path": {"type": "string"}
    },
    "required": ["path"]
    }
    },
    {
    "name": "get_fx_rate",
    "description": "查詢美元對新台幣即時匯率",
    "parameters": {
    "type": "object",
    "properties": {}
    },
    }
    ]

    1. 當模型輸出 tool call 時,由你的程式實際執行:

    python
    def call_tool(name, args):
    if name == "read_file":
    with open(args["path"], "r", encoding="utf-8") as f:
    return f.read()
    if name == "get_fx_rate":
    # 這裡打某個匯率 API
    return "目前 USD/TWD 約為 32.1"

    你可以立刻做的事

    • 先做最簡單版本:只寫一個 read_file 工具,讓模型幫你讀取某個 txt,並摘要內容。

    收尾:下一步可以做什麼?

    如果你已經在桌機跑起 LFM2.5,有幾個很實際的下一步:

    • 把你的「每週重複工作」整理成一個 Agent 流程,固定用同一組工具+提示詞執行。
    • 把常用的公司文件、技術文檔轉成文字,作為 128K 上下文的知識庫。
    • 在手機上先跑小上下文(8K/16K),確認效能,再逐步增加到 32K,觀察速度和可用性。

    LFM2.5-2.6B 的重點不在「有多大」,而在「足夠聰明又能在你手邊的設備上跑」,只要你願意花一個週末,把下載、llama.cpp、簡單工具串接三件事做完,就能擁有一個真正屬於自己的本地 AI 小助手。

    🚀 你現在可以做的事

    • 到 Hugging Face 下載 LFM2.5-2.6BQ4_K_M GGUF 模型,並在桌機用 llama.cpp 跑通基本推理
    • 準備一個 docs/ 資料夾與一個「每週重複任務」,作為之後 Agent 與長上下文測試用資料
    • 在手機上安裝支援 GGUF 的本地 LLM App 或配置 adb 環境,預留 3–4GB 空間準備導入模型
  • BTL-3:8GB 就能跑的本地程式代理人

    BTL-3:8GB 就能跑的本地程式代理人

    📌 本文重點

    • BTL-3 是可本地部署的程式代理人模型
    • 8.39GB GGUF 保留約 92% 的 27B 能力
    • 特化在工具呼叫與完整程式工作流
    • 適合離線開發與本地 Agent 架構

    想要在自己電腦上擁有類似 GitHub Copilot / Claude Code 的程式代理人,又不想連雲端?BTL-3 是目前少數「真實可落地」的開源選擇。

    原帖與技術細節:[Reddit] BTL-3 27B agentic coding model


    核心功能:一顆小體積、但會「自己想和動手做」的模型

    1. Agentic 架構:不只是聊天,而是完整工作迴圈

    BTL-3 的訓練目標不是「回答問題」,而是模擬一個真正的程式代理人工作流:

    Reason → Act → Inspect → Recover → Continue

    你可以直接把它當成一個「會自己規劃與檢查的本地 Copilot」,實際用法像這樣:

    1. Reason(思考):給它一個 repo 跟目標,例如:把這個專案加上簡單的健康檢查 API
    2. Act(行動):它會規劃要改哪些檔案、生成修改方案或腳本。
    3. Inspect(檢查):搭配工具(如 git diff、測試腳本)檢查結果。
    4. Recover(恢復):若測試失敗,會根據錯誤訊息繼續修正。

    行動建議:

    • 設計你的 prompt 時,直接描述「任務目標 + 可用工具 + 成功條件」,讓它接手後續流程,而不是只叫它「寫一段程式」。

    2. 工具呼叫:一次、連續、並行都能掌握

    BTL-3 內建工具使用能力,可做到:

    • 單次工具呼叫:例如呼叫 bash 跑測試、或呼叫 HTTP client 打內部 API。
    • 連續呼叫:先爬資料,再處理,再更新資料庫。
    • 並行呼叫:同時對多個服務發出請求,再整合結果。
    • 知道何時不要用工具:測試顯示,它在「工具呼叫放棄」場景的表現也很不錯(原文數據:工具呼叫放棄約 91.2% 準確)。

    💡 關鍵: 約 91.2% 的工具呼叫放棄準確率,代表它不只會用工具,也懂得在不需要時適時收手。

    你可以把它接到現成 orchestrator(如 MCP、或你自己的 agent framework),讓 BTL-3 再負責「判斷何時用哪個工具」。

    行動建議:

    • 若你已有工具系統(CLI、內部 API),先列出 3–5 個常用操作,包成「工具描述 + I/O 格式」,再讓 BTL-3 透過這些工具完成任務,而不是只輸出文字。

    3. 在 8.39GB GGUF 裡塞進 92% 的 27B 智慧

    BTL-3 原始是 27B 參數模型,但 Bad Theory Labs 用自家量化壓縮技術(AVQ2 解碼、INT4 仿射運算等),做出一個:

    • 單一 GGUF 檔(約 8.39GB)
    • 每參數不到 2.5 bits
    • 保留約 92.2% 原始模型能力

    💡 關鍵: 約 8.39GB 的 GGUF 就保留 92.2% 能力,代表一般開發者電腦即可接近 27B 模型效能。

    一個關鍵指標是 HumanEval pass@1 約 95.12%,這個成績在開源程式模型裡非常高,實際效果就是:

    • 常見演算法題、資料處理、API 包裝腳本,大多可以一次寫對(或只需小修)。

    💡 關鍵: HumanEval pass@1 約 95.12%,表示它在「一次寫對程式」上的成功率已逼近頂級商業程式模型水準。

    行動建議:

    • 若你現在在本地跑的是 7B–8B 一般聊天模型(例如常見的「通用 LLM」),可以直接用同一套 llama.cpp / LM Studio 配置,換成 BTL-3 GGUF,感受一次「針對程式與工具使用優化」的落差。

    適合誰用:三種典型場景

    1. 離線/內網環境的程式開發助手

    如果你的程式碼不能上雲(金融、政府、內網產品),BTL-3 提供一條路:

    • 在機房或開發者筆電本地部署,不經過外部 API。
    • 讓它讀 repo、理解架構、提出修改建議。

    典型任務:

    • 在不同微服務間統一 logging 格式。
    • 為舊專案補上基本 test suite。

    行動建議:

    • 選一個「不能丟到 GitHub Copilot」的專案,讓 BTL-3 先生成一份「系統總覽 + 待改善清單」,作為內網 code review 助手。

    2. 自動化腳本 & 工具串接

    BTL-3 對工具呼叫特別強,適合當成:

    • CLI 自動化腳本生成器幫我寫一個每天備份某資料夾到 S3 的腳本
    • 爬蟲與內部 API orchestration:串接 curlPython script、內部 REST API

    行動建議:

    • 設計一個小專案:例如「自動整理 log + 發 Slack 通知」,讓 BTL-3 負責生成腳本、再透過工具跑一次,測試它的完整 workflow 能力。

    3. 本地 Agent 開發環境的一顆「程式專家」核心

    你可能已經在用:

    • llama.cpp / vLLM 當推理引擎
    • 本地 IDE 插件(VS Code extension、JetBrains plugin)
    • MCP 或其他 orchestrator 做多工具協調

    BTL-3 可以直接當「程式 & 工具專家」,其他模型負責一般聊天或決策。

    行動建議:

    • 在你的 agent framework 裡,新增一個 coding-agent 路由:
    • 當任務涉及 repo、CLIAPI 操作時,轉給 BTL-3。
    • 其他任務仍用通用模型(如 Solar Open 2Laguna S 2.1 等)。

    下面用表格簡單比較常見選項:

    名稱 核心功能 免費方案 適合誰
    BTL-3 本地程式代理人、工具呼叫 開源、GGUF 免費 想要本地 Copilot / 程式 Agent
    Solar Open 2 長上下文、辦公 & 程式代理 開源模型 文件密集 + 長上下文任務
    Laguna S 2.1 多語言、大型本地通用模型 開源模型 需要高性能通用助手

    相關連結:


    怎麼開始:從硬體到第一個 workflow

    Step 1:確認硬體配置

    官方 8.39GB GGUF 版本的目標是「一般開發者電腦可以跑得動」,實務建議:

    • RAM:16–32GB(越多越穩定)
    • GPU:一張中階卡(8–12GB VRAM 足夠),或純 CPU 也可嘗試
    • 儲存空間:至少預留 20GB 給模型與前端工具

    行動建議:

    • 先在自己的機器跑過任一 7B–8B GGUF 模型,如果能順跑,再換 BTL-3 應可接受。

    Step 2:下載 BTL-3 GGUF 模型

    目前 BTL-3 GGUF 版本由 Bad Theory Labs 釋出(連結通常在 Reddit 原帖或其 X 帳號):

    行動建議:

    • 用瀏覽器或 wget 下載 GGUF 檔到一個固定資料夾,例如:~/models/btl3/btl3-agentic.gguf

    Step 3:用 llama.cpp / LM Studio / Ollama 載入

    三條常見路徑:

    1. llama.cpp(命令列 / 伺服器模式)
    2. 安裝:依官方 repo 說明編譯。
    3. 啟動 server:
      bash
      ./llama-server \
      -m ~/models/btl3/btl3-agentic.gguf \
      -c 262144 \
      --host 0.0.0.0 --port 8080
    4. 之後透過 HTTP API 或前端連接。

    5. LM Studio

    6. 開啟 LM StudioAdd local model → 指向 GGUF 檔。
    7. 選好推理設定(context 長度、GPU offload),直接在內建聊天介面測試。

    8. Ollama 類工具

    9. 建一個 Modelfile 指向 BTL-3 GGUF。
    10. ollama run btl3 即可啟動本地推理。

    行動建議:

    • 初次使用先從 LM Studio 或類似 GUI 工具開始,快速確認模型品質,再把配置搬到 llama.cpp / server 模式。

    Step 4:實作一個簡單 workflow:讀 repo → 改動 → Patch → 自評測

    以下示範用「BTL-3 + llama.cpp server + 你習慣的 HTTP client」做一個小流程。

    1. 讓 BTL-3 讀 repo
    2. 先用你自己的 script 把重要檔案(README、主要程式入口、config)整理成一個壓縮過的文字輸入。
    3. 發送一個請求:
      json
      {
      "prompt": "你是一個程式代理人。以下是專案的主要檔案內容:...\n\n請先用條列方式整理這個系統的主要模組與依賴,再列出 3 個可以改善的地方。",
      "max_tokens": 2048
      }

    4. 規劃改動

    5. 根據它提出的改善建議,選一項(例如「增加健康檢查 API」),再下指令:
      > 「請為此改動設計一個實作計畫:要改哪些檔案、新增哪些函式、需要哪些測試。」

    6. 生成 Patch

    7. 要求它輸出 git-style unified diff
      > 「根據上面的計畫,請輸出 unified diff 格式的 patch,適用於 git apply。」

    8. 自評測

    9. 套用 patch,跑測試(可寫成工具讓 BTL-3 呼叫)。
    10. 把測試結果回傳給 BTL-3:
      > 「以下是測試輸出,請根據錯誤訊息更新 patch。」

    行動建議:

    • 把上述流程包成一個腳本或簡單 web UI,讓 BTL-3 成為你團隊的「自動 Patch 提案助手」,從單一專案先試用。

    Step 5:接進你現有的 Agent workflow(如 MCP)

    如果你已在用 MCP 或其他 orchestrator:

    1. 新增一個 LLM provider 指向 BTL-3
    2. 透過 llama.cpp server / LM Studio API 對接。

    3. 定義工具

    4. read_repo:讀指定路徑檔案並壓縮輸出。
    5. run_tests:執行 test 命令並回傳 stdout / stderr
    6. apply_patch:套用 diff 到 repo。

    7. 給 BTL-3 的 system prompt

    8. 明確告訴它有哪些工具、何時該使用、成功定義(例如「所有測試通過」)。

    行動建議:

    • 在你的 orchestrator 裡,把「所有涉及程式碼修改的任務」預設派給 BTL-3,其他任務仍用通用模型,實際對比整體完成品質與速度。

    BTL-3 的定位很清楚:不是要取代所有模型,而是成為你本地環境裡專門負責「寫程式 + 用工具」的那顆專家模型。如果你正在找一個接近本地版 Copilot / Claude Code 的選擇,它值得你花一個週末搭起來試用。

    🚀 你現在可以做的事

    • 到 Reddit 原帖下載 BTL-3 GGUF,並用 LM Studiollama.cpp 在本地先跑一輪測試
    • 選一個不能上雲的專案,讓 BTL-3 產生「系統總覽 + 改善清單」,試做一次 Patch workflow
    • 在你現有的 agent framework 中新增 coding-agent 路由,將程式與工具相關任務導向 BTL-3 並觀察效果
  • 270 億參數上 iPhone 的實戰路線

    270 億參數上 iPhone 的實戰路線

    📌 本文重點

    • 27B 大模型壓縮後可在手機端側實用
    • 量化 +剪枝 +蒸餾是端側部署核心組合
    • 善用 NPU/GPU 與 RAG/Agent 架構提升體驗

    在端側塞進 Qwen 3.6-27B 這種體量的模型,直接解決了三個痛點

    1. 隱私 & 合規:聊天、RAG 查文件、簡單 Agent 全在本機,不丟到雲端。
    2. 互動延遲:減少網路 RTT,短指令(改句子、補程式)能接近即時回應。
    3. 成本 & 擴展:不用為每個活躍使用者準備一個雲端 GPU,端側模型成為主力推理,引流雲端模型解決長上下文或高難任務。

    PrismML 把 Qwen 3.6-27B 壓到能在 iPhone 17 Pro 上跑,給了我們一個清楚訊號:27B 級模型上手機是可行路線,但你要整套壓縮 + runtime + 系統調優一起做


    重點說明:端側大模型的幾個關鍵技術

    1. 量化:從 16bit 壓到 4bit / 2bit

    目的:壓縮權重體積 + 減輕記憶體頻寬壓力

    • 粗估:
    • FP16:27B × 2 bytes ≈ 54 GB(純權重就爆)
    • 4bit:27B × 0.5 bytes ≈ 13.5 GB
    • 2bit:27B × 0.25 bytes ≈ 6.75 GB

    💡 關鍵: 把 27B 權重從 54GB 壓到約 7–14GB,是端側部署能否落地的基礎門檻

    • 實務上常用 mixed-precision
    • attention / embedding 保留 8bit 或 16bit
    • MLP 可用 4bit 或 2bit(配合 group-wise scaling)
    • 在 iOS 端常見兩種路線:
    • GGUF + llama.cpp:用 Q4_K_M / Q3_K_M 這類 profile
    • Core ML / MLC:用 symmetric int4 / int8,用 LUT 把量化常數 bake 進權重

    對專案的好處:

    • 同一隻 app 可以提供 小模型 + 壓縮大模型 的雙模式:日常用 7B,開「專業模式」時啟動 27B(但速度變慢 + 發熱)。

    2. 剪枝與低秩分解:不只變小,還要能跑快

    量化只壓體積,不一定壓算力;要在功耗有限的手機跑得動,需要再用:

    1. 結構化剪枝(structured pruning)
    2. 砍掉整個 head、channel 或 FFN neuron。
    3. 例如把 32 heads 剪到 24 heads,或把 FFN hidden dim 從 8k 降到 6k。
    4. 這會直接減少 MACs,對 NPU / GPU 友善。
    5. 低秩分解(LoRA / SVD 分解 FFN 權重)
    6. 把大矩陣 (W \in \mathbb{R}^{d \times d}) 分成 (U \in \mathbb{R}^{d \times r}, V \in \mathbb{R}^{r \times d}),r ≪ d
    7. 搭配蒸餾可以維持合理能力。

    PrismML 類型的方案多半是 多階段:量化 + 剪枝 + 蒸餾 + runtime 特化 一起做,才有可能把 27B 折成 iPhone 等級的 latency。

    3. KV Cache / 推理圖優化:token/s 的決勝點

    端側 LLM 的痛點不是 model load,而是 持續推理的 token/s 與發熱

    關鍵是:

    • KV Cache 緊縮
    • 精度壓到 8bit/4bit(與權重量化分開考慮)。
    • 善用 sliding window / attention sink,減少長對話時的 KV 佔用。
    • 推理圖優化(graph optimization)
    • 透過 MLC / Core ML / 自研 runtime 把整段 transformer block fuse 成 1–2 個大 kernel。
    • 減少 CPU ↔ NPU ↔ GPU 之間的 context switch。

    效果:在 iPhone 17 Pro 這種等級裝置,27B 壓縮到 4bit + 優化 graph,合理預期 5–10 tok/s 左右(看溫控),可以應付聊天、簡單 RAG,但不是寫 3k 行程式碼那種長輸出場景。

    💡 關鍵: 端側大模型的體感速度主要由 token/s 決定,5–10 tok/s 大致只適合短回覆與簡單任務

    4. 善用手機 NPU / GPU:不是「丟上去就快」

    iOS 上大致有三條路:

    1. Core ML + ANE(NPU)
    2. 最省電,但要配合 Core ML 支援的 op / dtype,需要前置轉換。
    3. Metal / MLC
    4. 走 GPU / CPU + 少量 NPU,對自訂 kernel 比較自由。
    5. llama.cpp(Metal 後端)
    6. 直接吃 GGUF,開 Metal 加速;部分 op 仍在 CPU。

    實務上可以採用 混合策略:embedding / 前幾層在 NPU,後面在 GPU / CPU,平衡記憶體與溫度。


    實作範例:在 iOS 上做聊天 / RAG / Agent 的架構

    下面給一個「實際可落地」的 27B 壓縮部署思路,用 pseudo code 表示。

    1. 推理框架選型與模型準備

    方案 A:llama.cpp + GGUF(開發週期短)

    1. 先把 Qwen 3.6-27B 轉成 GGUF 並量化(在桌機完成):
    python convert_qwen_to_gguf.py \
      --model qwen-3.6-27b \
      --out qwen-3.6-27b-q4_k_m.gguf
    
    ./quantize \
      qwen-3.6-27b-q4_k_m.gguf \
      qwen-3.6-27b-q4_k_m.gguf \
      Q4_K_M
    
    1. iOS 使用 llama.cpp Swift / C API:
    let params = gpt_params_default()
    params.n_ctx = 4096
    params.n_gpu_layers = 20   // 前 20 層走 Metal
    
    let ctx = llama_init_from_file("qwen-3.6-27b-q4_k_m.gguf", params)
    
    func infer(prompt: String) -> String {
        llama_reset(ctx)
        llama_eval_prompt(ctx, prompt)
        var output = ""
        while !shouldStop(output) {
            let token = llama_eval_next(ctx)
            output += tokenizer.decode(token)
        }
        return output
    }
    

    注意:n_gpu_layers 設太高,會爆 VRAM / 發熱;設太低,會被 CPU 拖死。實測需要在 8–24 之間找平衡。

    方案 B:MLC LLM + Metal(更深度優化)

    • 透過 MLC 工具鏈把 Qwen 3.6-27B 壓成 int4 + fused kernels,生成 iOS 專用模型包:
    mlc_llm convert qwen-3.6-27b \
      --quantization q4f16_0 \
      --target iphone
    
    mlc_llm build ios qwen-3.6-27b-q4f16_0
    

    iOS 端呼叫:

    let engine = MLCChatEngine(model: "qwen-27b-q4f16_0")
    
    engine.generate(
      prompt: userPrompt,
      maxTokens: 512,
      temperature: 0.7,
      streamHandler: { token in
        appendToUI(token)
      }
    )
    

    實務建議:若不是要深度客製 runtime,MLC 會比自己改 llama.cpp 更好拿穩定 fps 和電源管理

    2. RAG:本機嵌入 + 文件切片

    架構:

    • 輕量 embedding 模型(如 384–768 dim)放端側
    • 文本切 chunk(512–1024 tokens),建立本地向量索引。
    • 查詢時在端側 embed + ANN 搜索 + top-k context 拼回 prompt,再丟給 27B 生成。

    簡易 Swift 流程(以 Core ML embedding 模型為例):

    // 1. 建立索引(啟動或背景時)
    for chunk in documentChunks {
        let emb = embeddingModel.encode(text: chunk.text) // [Float]
        annIndex.add(vector: emb, id: chunk.id)
    }
    
    // 2. 查詢時
    func ragAnswer(query: String) -> String {
        let qEmb = embeddingModel.encode(text: query)
        let topK = annIndex.search(query: qEmb, k: 4)
        let context = topK.map { $0.text }.joined(separator: "\
    ---\
    ")
    
        let prompt = """
    你是一個助理。以下是知識庫內容:
    \(context)
    
    問題:\(query)
    請根據知識庫回答,若沒有明確答案就說不知道。
    """
        return infer(prompt: prompt)
    }
    

    好處

    • 敏感文件不離開手機;
    • 即使 27B 很慢,RAG 因為 context 精準,需要生成的 token 也變少

    3. 簡單 Agent:有限循環 + 工具調用

    在端側做 Agent 不要太貪心,建議:

    • 限制 max steps(例如 4–6 步)。
    • 工具呼叫只做本機能力:檔案讀寫、日曆、藍牙裝置等。

    簡化 pseudo code:

    struct ToolCall { let name: String; let args: [String: Any] }
    
    func runAgent(task: String) {
        var state = ""
        for step in 0..<6 {
            let prompt = buildAgentPrompt(task: task, state: state)
            let output = infer(prompt: prompt)
    
            if let tool = parseToolCall(output) {
                let result = executeTool(tool)
                state += "\
    [tool-result]\
    " + result
            } else {
                renderFinal(output)
                break
            }
        }
    }
    

    這種架構在 27B 上 iPhone 實務可行,但要注意:token/s 慢 → 每一輪推理越短越好,prompt 盡量模板化、少廢話。


    建議與注意事項:坑在哪、怎麼踩得比較輕

    1. 記憶體與冷啟動

    • iPhone 17 Pro 類級別裝置,27B 4bit 純權重就十幾 GB,實務上需:
    • 模型分片 / 分層載入
      • 常駐 7B 小模型;
      • 27B 大模型在「高需求模式」才 mmap 載入部分層(如後 12 層)。
    • 或採 Mixture-of-Experts(MoE) 類方案,如 GLM 5.2 + Flash MoE,那類模型在 Mac M5 上可跑 2–2.8 tok/s,給端側設計方向參考:不是所有 layer 都要 full dense
    • 冷啟動:
    • 首次 load 27B 量化模型,可能 3–10 秒,一定要做 loading UI + 延遲初始化(app 啟動時先載小模型,使用者開「專業模式」才載大模型)。

    💡 關鍵: 3–10 秒的冷啟動延遲是端側大模型的 UX 關鍵,必須用分層載入與明確 UI 掩護

    2. 電量與發熱

    • 連續推理 1–2 分鐘,大模型會把 SoC 拉到 TDP 上限,掉頻後 token/s 會明顯下降。
    • 實作上建議:
    • 限制 max_tokens,避免長篇輸出。
    • 使用 溫度監控(ThermalState,高溫時降速:
    if ProcessInfo.processInfo.thermalState == .serious {
        params.n_threads = max(2, params.n_threads / 2)
    }
    

    3. 隱私與合規

    • Ce 合規角度,端側推理 + 本地 RAG 是加分項,但要注意:
    • 日誌、錯誤回報不得包含原文檔內容。
    • 若有雲端 fallback,要明確 UI 提示「此問題將送出至伺服器」。

    4. 測試方法與性能預估

    建議自建簡單基準腳本,統計:

    • 冷啟動時間(model load 完到第一 token)
    • token/s(前 50 tokens、整段平均)
    • 電池掉電率與機身溫度(5 分鐘連續推理)

    例:用 llama.cpp CLI 在開發機 / TestFlight 內部版測一次:

    ./main -m qwen-27b-q4_k_m.gguf \
      -p "Hello" -n 256 -s 42 --timings
    

    官方輸出會給:

    • prompt eval time / token
    • generation eval time / token

    再用這些數據估算:

    • 聊天:平均 50–100 tokens → 是否能在 3–5 秒內完成?
    • RAG:查詢 + 150 tokens → 整體延遲能否低於 10 秒?

    結論:端側 27B 的實際策略

    對多數 iOS 專案,建議的 可實作路線 是:

    1. 產品層:
    2. 7B–8B 模型 作為主力。
    3. 提供「離線高精度模式」載入壓縮 27B,給重度用戶 & 高價方案。
    4. 技術層:
    5. 量化採 4bit mixed-precision,配合剪枝 + 蒸餾。
    6. 選擇 MLC / llama.cpp Metal 後端,不要自幹 runtime,除非是公司核心技術。
    7. 系統層:
    8. 做好 分層部署 + 延遲載入 + 熱管理
    9. 嵌入模型 + RAG 索引用小模型處理,27B 只負責最終生成。

    這樣設計,你可以合理地把「看起來誇張的 27B」塞進 iPhone 裡,並且在聊天、RAG、輕量 Agent 這幾個場景拿到實際可用的體驗。真正的難點不只在模型壓縮,而是在整條端側推理鏈的工程化

    🚀 你現在可以做的事

    • 在開發機上用 llama.cpp 或 MLC 先跑一版 Qwen 3.6-27B 4bit,量測 token/s 與冷啟動時間
    • 選定一個 7B 模型做端側 RAG PoC,實作本地嵌入與向量索引流程
    • 規劃產品中的「專業模式」或「離線高精度模式」,設計 7B / 27B 雙模型切換與載入策略
  • 本地 LLM+RAG 架構:從 NASA CMO-DA 學部署

    本地 LLM+RAG 架構:從 NASA CMO-DA 學部署

    📌 本文重點

    • 斷網環境可用本地 LLM+RAG 解決醫療輔助
    • llama.cpp 搭配容器化可在受限硬體穩定推理
    • 使用 OSS 向量庫打造可控、可回滾的 RAG pipeline
    • 模型與知識庫需分版本管理確保合規與安全

    在太空任務這種完全斷網、硬體受限且高合規的環境,NASA 的 CMO-DA 醫療助手用一套可攜、可封裝的本地 LLM+RAG 架構,解決了三個常見痛點:

    1. 不依賴雲端:模型推理與檔案檢索都在本地完成,沒有外部服務依賴。
    2. 可控資源與效能:透過 llama.cpp + 容器化(RamaLama 類工具),在 CPU/GPU 都受限的情況下仍能穩定跑推理。
    3. 安全與更新邊界清楚:醫療場景下做到知識庫可更新但可 rollback,模型版本可控且遵守合規要求。

    💡 關鍵: 在完全斷網且高合規場景中,能本地推理並可回滾的 LLM+RAG 架構是可行且可維護的方案

    下面用 NASA CMO-DA 的思路,拆成一個可直接套用的本地 LLM+RAG 模板。


    重點說明

    1. 為何選擇 llama.cpp + 容器化工具做本地推理

    在 CMO-DA 這類場景,llama.cpp 有幾個關鍵優勢:

    • 硬體覆蓋廣:支援 x86、ARM、多種 GPU(CUDA、Metal、OpenCL 等),適合未知/多樣化載具(太空艙、工廠、船艦)。
    • GGUF 模型格式:支援量化(q4_0, q5_K 等),可以在有限記憶體上跑中大型模型。
    • 單一 binary,易封裝:搭配像 RamaLama 這種工具,把模型 + 推理程式封裝成容器映像,做到「模型即容器」。

    實際好處:

    • 對你來說,部署路徑變成:git pullcmake → 放入 GGUF 模型 → 打包成 container,不需要大堆框架整合。
    • DeepSeek V4 已合併進 llama.cpp 主幹,你可以直接在本地跑 DeepSeek V4 GGUF,在推理品質與效能上有更好的選擇。

    容器化工具(以 RamaLama 類工具為例)則負責:

    • 自動 GPU 偵測與穿透(在 Kubernetes / OpenShift 中把 GPU 資源暴露給容器)。
    • 統一啟動參數與模型路徑,讓模型像應用程式一樣可複製、可移動。

    💡 關鍵: 透過 GGUF 量化與「模型即容器」封裝,能在受限硬體上穩定部署中大型本地模型

    2. 斷網環境下的 RAG pipeline 設計

    本地 RAG 的核心是:不要依賴雲端向量服務,一切用自架的 OSS 向量庫

    常見 OSS 選擇:

    • Qdrant:Rust 實作,支援 HNSW、瀏覽器/邊緣友好,有好用 REST / gRPC API。
    • Milvus / Weaviate:功能更完整,適合資料量非常大但資源較充裕的內網環境。

    醫療場景(也是典型高合規場景)的設計要點:

    1. Chunking 策略
    2. 醫療指引、SOP 文件為單位,再切成 512–1024 tokens chunk,重點是維持語境完整。
    3. 加上 overlap(例如 128 tokens),避免答案跨 chunk 斷裂。
    4. 針對表格或 checklist,考慮以「row / section」為粒度,而不是固定 tokens。

    5. Embedding 模型本地化

    6. 選一個能放進 GGUF 或支援 CPU/GPU 的 embedding 模型,例如 bge-large 的量化版本或 MiniLM 類模型。
    7. 避免用雲端 embedding API,保證完全離線。

    8. 延遲與資源限制

    9. 查詢流程:Embedding → Vector search → Top-k 文件 → LLM 回答,每一步都要評估延遲。
    10. 太空艙/工廠場景中通常只有 1–2 張 GPU,LLM 推理延遲是主瓶頸,可以:
      • 調低 max_tokens 回答長度。
      • 預先計算並緩存常見問答(FAQ)以降低實時查詢負擔。

    💡 關鍵: 在離線場景中,512–1024 tokens chunk 加 128 overlap 能平衡上下文完整性與檢索效率

    3. GPU 自動偵測與穿透:Kubernetes / OpenShift 配置

    在 CMO-DA 中,他們透過類似 RamaLama 的工具,在 OpenShift 上做到:

    • 自動偵測節點是否有 GPU(透過標籤或 device plugin)。
    • 在 pod 內把 GPU 暴露給 llama.cpp

    對你來說,可以簡化成 Kubernetes YAML 設計:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: local-llm
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: local-llm
      template:
        metadata:
          labels:
            app: local-llm
        spec:
          containers:
            - name: llama-cpp
              image: your-registry/llama-cpp-gguf:latest
              args:
                - "--model=/models/med-llm.gguf"
                - "--ctx-size=4096"
                - "--n-gpu-layers=35"  # **關鍵參數**:LLM 分配到 GPU 的層數
              resources:
                limits:
                  nvidia.com/gpu: 1      # Kubernetes GPU 資源宣告
              volumeMounts:
                - name: models
                  mountPath: /models
          volumes:
            - name: models
              persistentVolumeClaim:
                claimName: llm-model-pvc
          nodeSelector:
            nvidia.com/gpu.present: "true"  # **GPU 自動偵測:只排程到有 GPU 的節點
    

    OpenShift 上同樣依賴 GPU Operator / device plugin,容器內不需要特殊程式碼,llama.cpp 會透過 CUDA / ROCm 自動偵測 GPU。


    實作範例:Minimal 本地 LLM+RAG PoC

    下面是一個可離線部署的小型 RAG 助理範例,組合:llama.cpp + DeepSeek V4 GGUF + Qdrant

    1. 準備模型與 llama.cpp

    # 取得最新 llama.cpp(含 DeepSeek V4 支援)
    git clone https://github.com/ggml-org/llama.cpp.git
    cd llama.cpp
    git pull
    cmake -B build
    cmake --build build -j
    
    # 假設你已下載 DeepSeek V4 GGUF 模型到 ./models/deepseek-v4-med.q4_0.gguf
    

    2. 啟動本地 Qdrant 向量庫

    docker run -d --name qdrant \
      -p 6333:6333 \
      -v qdrant_data:/qdrant/storage \
      qdrant/qdrant
    

    3. 建立 RAG Pipeline(Python 範例)

    import requests
    from sentence_transformers import SentenceTransformer
    
    # **Embedding 模型**:可替換為你量化後的本地模型
    embed_model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")
    
    QDRANT_URL = "http://localhost:6333"
    COLLECTION = "med_docs"
    
    def create_collection():
        body = {
            "vectors": {
                "size": 384,
                "distance": "Cosine"
            }
        }
        requests.put(f"{QDRANT_URL}/collections/{COLLECTION}", json=body).raise_for_status()
    
    def index_documents(docs):
        vectors = embed_model.encode([d["text"] for d in docs])
        points = [{
            "id": i,
            "vector": vectors[i].tolist(),
            "payload": docs[i]
        } for i in range(len(docs))]
        requests.put(f"{QDRANT_URL}/collections/{COLLECTION}/points", json={"points": points}).raise_for_status()
    
    def rag_search(query, top_k=3):
        vec = embed_model.encode([query])[0].tolist()
        body = {
            "vector": vec,
            "limit": top_k
        }
        res = requests.post(f"{QDRANT_URL}/collections/{COLLECTION}/points/search", json=body).json()
        return [r["payload"]["text"] for r in res]
    
    # 初始化
    create_collection()
    index_documents([
      {"text": "若出現輕微頭痛且無其他症狀,建議先休息並補充水分。"},
      {"text": "若有持續胸痛或呼吸困難,應立即啟動緊急醫療流程。"}
    ])
    
    print(rag_search("胸口痛怎麼辦?"))
    

    4. 將檢索結果交給 llama.cpp

    在本地,你可以用簡單的 HTTP wrapper 把 context 拼接給 llama.cpp--prompt

    ./build/bin/llama-cli \
      --model ./models/deepseek-v4-med.q4_0.gguf \
      --ctx-size 4096 \
      --n-gpu-layers 35 \
      --prompt "根據以下醫療指引回答問題:
    [指引1]
    若有持續胸痛或呼吸困難,應立即啟動緊急醫療流程。
    
    問題:胸口痛怎麼辦?"
    

    在正式專案中,你會把 Qdrant 的 top-k 結果串接到 prompt,組成完整 RAG 回答流程。


    建議與注意事項

    1. 醫療場景的安全邊界與 offline 更新策略

    醫療、工業安全等場景,關鍵是 模型與知識庫的版本分離

    • 模型(LLM)版本:透過容器映像管理,例如在 tag 中寫明版本:med-llm:v1.2.0
    • 知識庫(向量庫 + 原始文件)版本:在 Qdrant collection 命名中加入版本:med_docs_v2024_06

    更新策略建議:

    1. 離線同步
    2. 透過 USB / 專用線路將新模型(GGUF)與新向量庫 dump 帶到現場。
    3. 先在 staging 節點載入,跑自動化驗收測試(醫療 QA 集)。

    4. Rollback 機制

    5. 保留上一版模型映像與向量庫快照,決策錯誤時可以在幾分鐘內回退。
    6. 配置開關:只允許在非緊急任務時切換版本,避免任務中途變更行為。

    2. 常見坑與最佳實踐

    1. 坑:只量化模型但忘記量化記憶體 footprint
    2. 即使用 q4_0,context 太大(例如 32k)時仍可能爆 RAM。
    3. 建議:先用 --ctx-size=4096 做壓力測試,再逐步拉高。

    4. 坑:Chunk 太小導致回答失去上下文

    5. 斷網場景下沒有「多輪 call retriever 補充」的餘裕,chunk 要適度放大。
    6. 建議:醫療/工廠 SOP 至少維持 512–1024 tokens + 128 overlap

    7. 坑:GPU 穿透配置錯誤導致 fallback 到 CPU

    8. 沒有設 resources.limits.nvidia.com/gpu 或節點沒正確標記,pod 會跑在無 GPU 節點上。
    9. 建議:在 CI/CD 中加入簡單檢查:呼叫 nvidia-smillama.cpp GPU info API,確認有 GPU 再部署。

    10. 最佳實踐:在高合規場景用「白名單指令 + RAG」模式

    11. 不允許模型「自由想像」,回答必須引用 RAG 檢索到的片段。
    12. prompt 設計中加入:「只能根據提供的文件回答,若無相關資訊請回答『資料不足』」,降低幻覺風險。

    總結來說,NASA CMO-DA 的做法給了我們一個清晰模板:llama.cpp + 容器化 + OSS 向量庫 + 可控版本策略。只要把這套思路搬到你的工廠、船艦、礦場或企業內網,就能在斷網或高合規環境下建立一個可維護、可升級又安全的本地 LLM+RAG 助理。

    🚀 你現在可以做的事

    • 在 GitHub 搜尋並 git clone 官方 llama.cpp 專案,編譯並測試本地推理
    • 使用 Docker 拉起 Qdrant,依照文中 Python 範例建立一個最小 RAG PoC
    • 寫一份 Kubernetes Deployment YAML,把你的 GGUF 模型封裝成「模型即容器」,並在測試環境驗證 GPU 穿透与延遲表现
  • Gemma 4 12B:16GB 筆電就能跑的多模態模型

    Gemma 4 12B:16GB 筆電就能跑的多模態模型

    📌 本文重點

    • Gemma 4 12B 可在 16GB 筆電本地跑起多模態助理
    • 支援 256K tokens 長上下文與 140+ 種語言
    • 多種推理框架與量化選項,依硬體彈性部署

    只要一台 16GB RAM 的筆電,你就能在本地跑起能看圖、懂多語言、支援長上下文的開源模型 Gemma 4 12B,當自己的離線 AI 助理。

    官方與模型頁:
    – Google DeepMind 介紹(英):The Decoder 報導
    – 模型權重:google/gemma-4-12b(Hugging Face)


    核心功能:這顆模型為什麼值得你在本地跑

    1. 多模態:同時處理文字、圖片,部分變體還支援音訊

    Gemma 4 12B 是 Google DeepMind 釋出的開放權重模型,可以:

    • 文字 → 文字:聊天、摘要、寫程式
    • 圖片 → 文字:看截圖、PPT、流程圖說明內容
    • (部分 12B 變體)音訊 → 文字:理解語音內容(需支援音訊版模型,見 Hugging Face 說明)

    你可以馬上實作:

    • 把專案架構圖或 UI 截圖丟給 Gemma 請它「用條列解釋每一塊的功能」
    • 拍下白板會議內容,請它整理成待辦清單 + 行動項目

    模型介紹討論可參考 Reddit:google/gemma-4-12B · Hugging Face


    2. 超長上下文:最多 256K tokens,做「整個資料夾」級別的助理

    Gemma 4 系列支援最高 256K tokens 上下文,適合處理:

    • 整本 PDF、技術規格書
    • 一整個 repo 的多檔案閱讀
    • 長對話紀錄與多輪推理

    能做的實際事情:

    • 丟一本 300 頁 PDF:請它依「章節 + 行動建議」整理摘要
    • 為專案整個 docs/ 資料夾建一個「本地 FAQ 助理」,用自然語言查文件

    進階提示:長上下文會吃 RAM,你在本地使用時可先把 context window 設在 16K~32K,等硬體 OK 再拉高。

    💡 關鍵: 高達 256K tokens 的上下文,讓你可以一次處理整本書或整個專案,而不用頻繁切段或換檔。


    3. 多語言 + 商用授權:可以直接放進產品

    根據 Google 與社群測試,Gemma 4 支援 140+ 種語言,在英文之外,中文、日文、歐洲語言表現都夠用;
    同時採用 Apache 2.0 授權,可用於商業產品(只需保留版權聲明)。

    你可以馬上行動:

    • 做一個「中英雙語客服 FAQ Bot」,在公司內網跑,不要雲端 API
    • 把它包成內部工具,處理公司文件、程式碼審閱,不用擔心資料外流

    授權與開源定位說明,可參考 The Decoder 報導與 Reddit 貼文:
    The Decoder:Gemma 4 12B
    Google just dropped Gemma 4 12B on your laptop!!

    💡 關鍵: Apache 2.0 商用授權加上 140+ 語言支援,讓 Gemma 4 12B 可以直接被放進正式產品中,而不只是一個玩具模型。


    適合誰用:三個實戰場景

    1. 本地文件助理:讀 PDF、企業知識庫、不出網就能查

    典型流程:

    1. 把 PDF/Markdown/Word 轉成純文字
    2. 用向量資料庫或簡單關鍵字搜尋切成小段
    3. 把相關段落 + 問題一起送進 Gemma 4 12B

    具體可以做:

    • 法律條款查詢:輸入「幫我比較第 5 條和第 8 條的差異,列成表格」
    • 公司內訓教材:輸入「只針對新進工程師,整理第一章的必讀重點」

    行動建議:

    • 不想寫程式:用桌面端 UI 工具(例如 LM Studio)載入 Gemma 4 12B 的 GGUF 量化版,搭配內建「本地檔案知識庫」功能。
    • 能寫 Python:用 transformers + chromadbllamaindex 搭一個最小可用的 RAG 查詢腳本。

    2. 圖片理解:看設計稿、截圖除錯、手寫筆記整理

    Gemma 4 12B 的多模態版本可以直接吃圖片:

    可以做的事:

    • 把前端 UI 截圖給模型:「列出這個畫面的功能區塊,以及可能漏掉的錯誤狀態」
    • 拍課堂黑板或手寫筆記:「幫我轉成 Markdown 大綱,並補上可能缺的步驟」

    行動建議:

    • 使用 Ollama:安裝後直接用
      bash
      ollama pull gemma4:12b
      ollama run gemma4:12b

      再在聊天 UI 裡丟圖片與文字問題。

    • 若走 transformers:選用多模態 checkpoint(Hugging Face 上會標示 image / vision 支援),用官方範例載入 processor + model 後送入 images + texts


    3. 簡單程式輔助與本地 Coding Agent

    在 Reddit 測試中,有人把 Gemma 4 12B 接進 VSCodium + Pi Agent,讓它:

    寫一個 Python 腳本:讀取 log 檔 → 抓出 error module → 統計後輸出 JSON,還自己產 mock data、在終端測試,一次成功。(案例連結)

    你可以:

    • 在 VS Code 裝本地 LLM 外掛(如 Continue / Pi Agent 等),指定後端使用本地 Gemma 4 12B
    • 常見用法:
    • 「寫一個腳本批次重命名資料夾裡的圖片」
    • 「讀這個函式庫的 README,給我最小可行 demo」

    行動建議:

    • 若你有 NVIDIA GPU(如 3060 以上):用 mistral.rsllama.cpp + CUDA,可以得到更順暢的互動速度。

    推理框架比較:Ollama / Transformers / llama.cpp / mistral.rs

    下表給你一眼看懂各工具適合誰:

    名稱 核心功能 免費方案 適合誰
    Ollama 一行指令拉模型、簡單本地聊天 UI 免費 想最快跑起 Gemma 4、只想用不想調參的人
    Transformers 直接操作 Hugging Face 權重 免費 Python 開發者、要客製 RAG / Agent 的人
    llama.cpp CPU/GPU 皆可的輕量推理框架 免費 只有 CPU 或老 GPU、需要 GGUF 量化的人
    mistral.rs 針對 CUDA 極速優化的推理框架 免費 有 NVIDIA GPU,追求吞吐和延遲的進階玩家

    補充:mistral.rs v0.8.2 在 Gemma 4 上,對多種 GPU(GB10 / B200 / H100)推理速度可比 llama.cpp 快到 2.8 倍(來源)。

    💡 關鍵: 若你有 NVIDIA GPU,mistral.rs 在 Gemma 4 上可達到比 llama.cpp 快約 2.8 倍的推理速度,大幅縮短互動延遲。


    硬體需求與量化:16GB 筆電怎麼選

    Gemma 4 12B 是 120 億參數等級的模型,但經過量化後可以塞進 16GB RAM 甚至更小機器上。

    基本建議:

    • 16GB RAM / 無獨顯
    • 量化:4-bit(如 Q4_K / Q4_0
    • 框架:Ollama、llama.cpp GGUF
    • 用途:文件整理、輕量對話、簡單程式輔助

    • 16GB RAM + 6–8GB VRAM(如 3060 Laptop)

    • 量化:4-bit 或 8-bit(看 VRAM 是否足夠)
    • 框架:mistral.rs(CUDA)、llama.cpp(GPU offload)、Ollama(自動 GPU 利用)
    • 用途:多輪對話、圖片理解、較密集的程式輔助

    若不確定自己機器能跑多大模型,可以用社群做的互動網站(類似「選模型大小 + 量化 → 即時計算 VRAM」工具,來源自 這篇 Reddit 貼文),先估算記憶體需求,再決定下載哪一個量化版本。


    怎麼開始:最簡路線 3 步驟

    路線 A:用 Ollama,三分鐘跑起 Gemma 4 12B

    適合:Mac / Windows / Linux,一行指令就想用的人。

    1. 安裝 Ollama:到 ollama.com 下載並安裝
    2. 在終端執行:
      bash
      ollama pull gemma4:12b
    3. 開始對話:
      bash
      ollama run gemma4:12b

      在對話中可以直接貼文字、上傳圖片,嘗試:
    4. 「幫我把這份 PDF 的重點整理成五條」
    5. 「看這張 UI 截圖,列出使用者可能會卡關的地方」

    路線 B:用 Hugging Face Transformers,做自家工具的核心模型

    適合:會 Python、想整合到後端或自製 UI 的開發者。

    1. 安裝套件:
      bash
      pip install transformers accelerate safetensors
    2. 在程式裡載入(以文字模式為例):
      “`python
      from transformers import AutoModelForCausalLM, AutoTokenizer

    model_id = “google/gemma-4-12b-it” # instruction-tuned 版本

    tokenizer = AutoTokenizer.from_pretrained(model_id)
    model = AutoModelForCausalLM.from_pretrained(
    model_id,
    device_map=”auto”,
    torch_dtype=”auto”,
    )

    prompt = “請用條列幫我整理這段技術文件的重點:…”
    inputs = tokenizer(prompt, return_tensors=”pt”).to(model.device)
    outputs = model.generate(**inputs, max_new_tokens=512)
    print(tokenizer.decode(outputs[0], skip_special_tokens=True))
    ``
    3. 若要圖片理解:選擇 Hugging Face 上標示支援 vision 的變體,搭配對應
    processor` 載入即可。


    路線 C:追求速度,用 mistral.rs / llama.cpp 跑量化版

    適合:有 NVIDIA GPU、想把延遲壓到最低的人。

    大致流程:

    1. 到 Hugging Face 找到 Gemma 4 12B 的 GGUF 或量化權重(搜尋 gemma-4-12b gguf 等)
    2. 安裝框架之一:
    3. mistral.rs
    4. llama.cpp
    5. 用官方 README 範例載入模型後,設定:
    6. n_gpu_layers 或類似參數,把前幾層放 GPU
    7. context_length:先從 16K 開始測試,再視記憶體往上調

    操作上可以先用簡單指令測試:

    ./main -m gemma4-12b-q4.gguf -p "幫我用三點整理這段文字的重點:..."
    

    確認速度和記憶體使用量,再決定是否改用更高精度的量化。


    如果你已經習慣雲端 LLM,Gemma 4 12B 是一個很好的起點,讓你在只靠 16GB 筆電的情況下,把「看圖、讀文件、寫程式」這三件事拉回自己機器上運行;從現在起,你可以把它當成本地端的多模態助手,按照上面的三條路線選一條裝起來,今晚就能實際用在手邊專案上。

    🚀 你現在可以做的事

    • ollama.com 安裝 Ollama,執行 ollama pull gemma4:12b 在本地跑起模型
    • 前往 Hugging Face 搜尋 google/gemma-4-12b,挑選一個適合你硬體的量化版本下載
    • 在 VS Code 安裝本地 LLM 外掛(如 Continue / Pi Agent),後端連接本地 Gemma 4 12B 做程式輔助
  • SmallCode 架構:讓 4B 模型也能帶專案

    SmallCode 架構:讓 4B 模型也能帶專案

    📌 本文重點

    • 小模型不適合搭配太多零碎 tools
    • 用少量 compound tools 封裝整個工作流
    • 加上可控 improvement loop 提升穩定性
    • 本地 4B 模型也能跑實用 coding agent

    在本地用 4B Gemma 這種小模型帶一個中大型 repo,傳統做法是「LLM + 一堆小工具」:讀檔、寫檔、跑測試、grep 全部拆成獨立 tool。結果大多數人遇到的狀況是:上下文爆炸、工具呼叫瘋狂往返、推理鏈斷裂,小模型最後只會在錯誤訊息上打轉。SmallCode 的重點就是把這些多步操作 封裝成少量高階 compound tools,加上一個可控的 improvement loop,讓 4B 模型也能穩定完成多檔案、反覆修改的任務。


    重點說明

    1. 為什麼「LLM + 一堆小工具」在小模型上會崩盤

    從工程視角,小模型掛點原因其實很單純:

    1. 上下文爆炸
    2. 每呼叫一次 read_filesearchrun_tests,LLM 就要重新看到整段對話 + 工具 I/O。
    3. 小模型 context 小、壓縮能力差,於是早期決策被擠掉,任務計畫完全失憶

    💡 關鍵: 小模型的 context 與壓縮能力有限,多工具頻繁往返會迅速擠掉關鍵決策,導致任務中途失憶。

    1. 頻繁往返 + 推理鏈斷裂
    2. 多工具設計變成:LLM → read_file → 回答 → write_file → 回答 → run_tests ...
    3. 每一步都要模型自己想「下一步該用什麼工具」,對小模型來說元認知成本太高,很容易在第 3、4 步就跑偏。

    4. 錯誤訊息解析太細碎

    5. 錯誤訊息來了:run_tests → 報一堆 stacktrace → LLM 要自己決定要再 read_file 哪幾個檔案。
    6. 4B 模型常常讀錯檔或只讀到片段,最後修 bug 幻覺化。

    SmallCode 的做法是:把「讀檔 → 修改 → 測試」這個典型工作流視為一個原子操作,交給 compound tool 內部處理,LLM 只需要決定「要不要再試一次?」。


    2. Compound Tools:把多步工作流變成一個 API

    設計思路可以簡化成三件事:

    1. 把多步操作拉到工具內執行
    2. 典型例子:edit_and_test
      • 根據指定 glob pattern 讀檔
      • 在本地套用 LLM patch(或簡單模板)
      • 寫回檔案
      • pytest / npm test,收集輸出
    3. 對 LLM 而言,這整件事就是 一次工具呼叫 + 一個結構化結果

    4. 清楚定義輸入 / 輸出 Schema

    輸入 Schema(JSON Schema 或 Pydantic)範例:

    python
    class EditAndTestInput(BaseModel):
    goal: str # 自然語言:『讓 tests/test_api.py 全部通過』
    target_files: List[str] # ['src/api.py', 'tests/test_api.py']
    test_command: str = "pytest -q"
    max_edits: int = 3

    輸出 Schema:

    “`python
    class EditSummary(BaseModel):
    file: str
    diff: str # unified diff

    class EditAndTestOutput(BaseModel):
    success: bool
    edits: List[EditSummary]
    test_output: str
    error_summary: Optional[str]
    “`

    重點是讓小模型只要關注:有沒有成功?改了哪些檔?錯在哪裡?

    1. 在一次工具呼叫中完成工作流

    Tool handler(Python 假想範例):

    “`python
    def edit_and_test_tool(payload: EditAndTestInput) -> EditAndTestOutput:
    # 1. 收斂上下文:只讀需要的檔案內容
    files = {f: Path(f).read_text() for f in payload.target_files}

       # 2. 呼叫同一個或更小的 LLM 產生 patch(可本地或子進程)
       patch = call_llm_generate_patch(goal=payload.goal, files=files)
       edits = apply_patch_to_files(patch)
    
       # 3. 寫回檔案
       for e in edits:
           Path(e.file).write_text(e.new_content)
    
       # 4. 跑測試
       ok, test_output = run_command(payload.test_command)
    
       return EditAndTestOutput(
           success=ok,
           edits=[
               EditSummary(file=e.file, diff=e.diff)
               for e in edits
           ],
           test_output=test_output,
           error_summary=None if ok else summarize_test_output(test_output),
       )
    

    “`

    好處:主 agent 模型只要發出一個 edit_and_test 呼叫,不用自己 orchestrate read_filewrite_filerun_tests,大幅降低 思考步數context 髒亂度


    3. Improvement Loop:可控的自我改進迴圈

    SmallCode 成效好的關鍵是:讓 retry 變成一級公民,而不是「失敗就結束」。

    1. 失敗偵測策略
    2. 以 compound tool 的輸出為主,不讓模型自己猜:
      • success == False
      • test_output 中出現關鍵字(FAILEDTracebackAssertionError
    3. 這樣 loop controller 可以用硬邏輯判斷下一步,不依賴 LLM 理解每一行 stacktrace。

    4. 重試策略

    簡單可用的架構:

    “`python
    MAX_ATTEMPTS = 5

    for attempt in range(1, MAX_ATTEMPTS + 1):
    tool_result = edit_and_test_tool(input_payload)

       if tool_result.success:
           break
    
       feedback = build_feedback_prompt(tool_result)
       input_payload.goal = feedback  # 將錯誤摘要回餵給模型
    

    “`

    build_feedback_prompt 可以把 error_summary + 失敗測試名稱打包,讓下一輪 LLM 更聚焦。

    1. 避免無限 loop 的做法
    2. 硬限制MAX_ATTEMPTS、最大 wall time。
    3. 檢查 edits 是否變化:若連續兩次 diff 幾乎一樣(甚至相同 hash),就早停。
    4. error signature 去重:同一個 assertion / stacktrace 重複出現 N 次就停止,標記為「需要人介入」。

    這樣,4B 模型只要能理解「這次錯在哪裡、我還有幾次機會」,就足以在迴圈中持續收斂。


    4. 在本地 4B 模型上的部署實務

    Gemma 2 4B 為例,用 llama.cpp / Ollama 都可以吃得很順,但細節會影響體驗:

    1. 記憶體與延遲粗估
    2. 4B Q4_K_M:VRAM 約 3–4 GB;Q6 大概 5–6 GB。
    3. context 8k、推理 1 token ≈ 10–40 ms,視 CPU/GPU 而定。
    4. agent 架構推薦:主模型用中量化(Q4/Q5)+ MTP(若硬體支援),工具內部幫忙 patch 的模型可以更小或更低位元。

    💡 關鍵: Gemma 2 4B 在 Q4 量化、約 3–4 GB VRAM 和 8k context 下即可順暢運行,適合作為本地實用 coding agent 的基礎。

    1. llama.cpp 整合範例

    bash
    # 轉 GGUF 後
    ./llama-cli \
    -m gemma-2-4b-q4_k_m.gguf \
    -c 8192 \
    -ngl 35 \ # offload 到 GPU layer 數
    --temp 0.2 \
    --top-p 0.9

    在你的 agent server(Python)裡包一層簡單的 HTTP:

    “`python
    from llama_cpp import Llama

    llm = Llama(model_path=”gemma-2-4b-q4_k_m.gguf”, n_ctx=8192)

    def chat(messages):
    return llm.create_chat_completion(
    messages=messages,
    tools=TOOLS_SCHEMA, # compound tools 定義
    )
    “`

    1. Ollama 整合範例

    yaml
    # Modelfile
    FROM gemma2:4b
    PARAMETER temperature 0.2
    PARAMETER num_ctx 8192

    Python 呼叫:

    “`python
    import requests, json

    def ollama_chat(messages, tools=None):
    payload = {“model”: “gemma2-4b”, “messages”: messages}
    if tools:
    payload[“tools”] = tools
    r = requests.post(“http://localhost:11434/api/chat”, json=payload)
    return r.json()
    “`

    注意:不要貪心開太大 context,4B 小模型在 16k context 上的品質掉得很明顯,8k 左右通常較穩定。


    實作範例:簡化版 SmallCode 架構

    以下是一個「可以直接改造」的最小可行架構:

    # 1. 定義 compound tools
    TOOLS_SCHEMA = [
        {
            "type": "function",
            "function": {
                "name": "edit_and_test",
                "description": "Edit target files to satisfy goal and run tests.",
                "parameters": EditAndTestInput.model_json_schema(),
            },
        },
    ]
    
    # 2. Agent 迴圈
    
    def coding_agent(task_description: str):
        messages = [
            {"role": "system", "content": "你是嚴謹的資深工程師,專注讓測試通過。"},
            {"role": "user", "content": task_description},
        ]
    
        for attempt in range(1, 6):
            resp = ollama_chat(messages, tools=TOOLS_SCHEMA)
            choice = resp["message"]
    
            if "tool_calls" not in choice:
                # 當成總結
                return choice["content"]
    
            for tool_call in choice["tool_calls"]:
                if tool_call["function"]["name"] == "edit_and_test":
                    args = json.loads(tool_call["function"]["arguments"])
                    result = edit_and_test_tool(EditAndTestInput(**args))
    
                    # 記錄 tool 結果
                    messages.append({
                        "role": "tool",
                        "name": "edit_and_test",
                        "content": result.model_dump_json(),
                    })
    
                    if result.success:
                        messages.append({
                            "role": "user",
                            "content": "測試已通過,請簡要總結你做了什麼修改。",
                        })
                        final = ollama_chat(messages)
                        return final["message"]["content"]
    
        return "多次嘗試仍未通過測試,請人工檢查。"
    

    實際好處:
    – 你不需要讓 4B 模型自己 orchestrate 所有 file ops,只決定「目標」和「是否繼續嘗試」。
    – 迴圈與成功判斷在 host 程式碼內可觀測、可監控,易於 debug。


    建議與注意事項

    1. tool 太細 vs 太粗的 trade-off
    2. 太細:read_filewrite_filerun_tests 分開 → 小模型迷路。
    3. 太粗:一個 tool 內藏太多隱含狀態 → 工具結果難以解釋與監控。
    4. 建議:以「一次迴圈可解決的一個明確目標」為單位設計 compound tool,例如:edit_and_test_suiteadd_feature_and_generate_tests

    5. 錯誤訊息解析策略

    6. 不要把整個 test log 丟給小模型,先在 host 端做:
      • 只保留最後一個錯誤 block
      • 摘要檔名、行號、錯誤訊息
    7. 這樣可以避免 4B 模型被 1k tokens 的 noisy log 淹沒。

    8. 測試覆蓋率不足導致的幻覺修 bug

    9. 如果只有 1–2 個測試,小模型會傾向「只讓這兩個測試過」而破壞其他邏輯。
    10. 實務上:

      • 優先在 agent pipeline 前補上最小必要測試
      • 或在 tool 裡檢查 diff 是否只動到相關檔案/區塊(heuristic)。
    11. 如何監控與記錄 agent 決策

    12. 每一次迴圈記錄:
      • 使用的 tool 名稱 + 輸入參數
      • diff 摘要(檔名、行數、行數變化量)
      • test command 與結果(pass/fail、耗時)
    13. 建議:

    text
    logs/
    session-2025-05-21T12-34-56Z/
    step-01-request.json
    step-01-edit_and_test-input.json
    step-01-edit_and_test-output.json
    step-01-diff.patch

    之後你可以回放整個 session,分析為什麼某一輪跑偏,進而調整 tool schema 或 system prompt。


    總結:如果你想在本地 4B 模型上做實用的 coding agent,不要再堆滿十幾個零碎 tools。把關鍵工作流收斂成少量 compound tools,加上一個明確可控的 improvement loop,再配合 llama.cpp / Ollama 的輕量部署,就能把原本只敢交給 GPT-級別模型的任務,下放到可自託管的小模型上。


    🚀 你現在可以做的事

    • 在現有 agent 專案中,把零碎的 read_file / write_file / run_tests 整合成一個 edit_and_test compound tool
    • 用 Gemma 2 4B + Ollama 或 llama.cpp 在本地啟一個 8k context、Q4 量化的測試環境
    • 為你的 repo 實作一個最小版 improvement loop,限制 MAX_ATTEMPTS 並記錄每次 diff 與測試結果
  • 96 個 Gemini Agent 幫你寫系統?

    96 個 Gemini Agent 幫你寫系統?

    📌 本文重點

    • 多 Agent 可複製「多人分工」開發流程
    • Runtime 設計比單純換更大模型更關鍵
    • 用開源工具就能打造迷你版 Antigravity

    用一群 Agent 代替「一個工程師慢慢寫」,解決的是:複雜專案要靠多人分工,AI 也可以用 Runtime + 多代理系統做到同樣的協作和自動化

    核心觀念先講白:模型戰爭差不多打完了,現在比的是誰的 Agent Runtime 能把「模型能力」變成可落地的、多步驟的自動化工作流。

    Google 在 I/O 上展示的 Antigravity 2.0 + Gemini 3.5 Flash 是一個很極端的例子:

    • 96 個子代理分工
    • 12 小時寫完一套從零開始的作業系統
    • Token 成本不到 1,000 美金
    • OS 還能跑《Doom》

    💡 關鍵: 多代理 + 強 Runtime 已經能在「12 小時、不到 1,000 美金」內完成從零開發 OS,顯示關鍵瓶頸不再是模型本身,而是協作與流程設計。

    這不是叫你明天也去做一個 OS,而是提供一個「如何設計多 Agent 開發流程」的範本。下面我們拆成三件你可以直接抄的事:

    1. 多代理分工設計:任務 → 子任務 → Agent 編隊
    2. 強健 Runtime:重試、檢查點、錯誤恢復
    3. 平價版本實作:在你自己的專案做一個「迷你 Antigravity」

    核心功能:Antigravity 2.0 給開發者的三個啟示

    1. 多代理分工:任務 → 子任務 → Agent 編隊

    Antigravity 的做法,其實很像你帶一個遠端工程團隊:

    • 架構師 Agent:決定 OS 的模組切分(檔案系統、排程、驅動、UI…)
    • 模組作者 Agent:各自負責某一個模組的程式碼生成
    • 測試員 Agent:寫測試、跑測試、收斂錯誤
    • 整合者 Agent:把各模組組合、處理相依性、打包成可啟動的系統

    對你來說,可直接套用成一個通用流程:

    1. 寫一個頂層任務描述
      例:建立一個 RESTful CRUD 服務,管理任務(待辦事項),含 API、DB schema、簡單前端。

    2. 讓「架構師 Agent」自動拆解

    3. API 設計與 OpenAPI spec

    4. 後端框架與資料庫層
    5. 前端 UI
    6. 測試與 CI script

    7. 為每個子任務設計 Agent 角色

    8. api-architect-agent:只產出 API spec

    9. backend-agent:根據 spec 產生程式碼
    10. frontend-agent:負責 UI
    11. tester-agent:生成並執行測試
    12. integrator-agent:檢查專案結構、跑 build / lint

    13. 在 Runtime 中定義工作流

    14. 任務圖(DAG):架構師 → 模組作者 → 測試員 → 整合者

    15. 每個節點定義輸入/輸出檔案、工具(Git、DB、HTTP client)

    可行動步驟:

    • 選一個你熟的框架(例如 FastAPI / Next.js
    • 用自然語言寫清楚「最終可交付物」
    • 為這個專案定義 3–5 個 Agent 角色,明確限制各自輸入輸出

    2. Runtime 比模型重要:90% 成功率在多步任務會變災難

    多步任務有一個殘酷數學:

    • 假設每一步成功率 90%
    • 要跑 20 步,整體成功率 ≈ 0.9^20 ≈ 12%

    💡 關鍵: 即使單步有 90% 成功率,20 步工作流成功率只剩約 12%,所以不加 Runtime 管控,多步任務幾乎註定失敗。

    這就是為什麼像 Forge 這種開源 guardrails 會被重視:作者實測,一個 8B 模型在多步代理任務上,從 53% 提到 99% 成功率,完全不改模型,只改 Runtime。

    你在自己的「迷你 Antigravity」裡,要做三件事:

    1. 重試與 nudging

    2. 為每個步驟設 max_retries(例如 3 次)

    3. 失敗時自動加上「修正提示」,例如:上一步測試失敗,錯誤訊息如下,請修正而不是重寫整檔。

    4. 檢查點(checkpoint)

    5. 每完成一個重要子任務,就把中間產出存到 Git / DB

    6. 失敗時從最近的檢查點重跑,而不是重頭來

    7. 錯誤恢復流程

    8. 專門的 debug-agent:只看錯誤訊息 & log,產出修復建議

    9. Runtime 層做:自動建立 bug report、開 issue、指派給對應 Agent

    如果你用 Forge,它已內建:

    • Tool-agnostic 重試策略
    • 步驟執行強制與錯誤恢復
    • VRAM-aware context 管理(對本地模型很重要)
    • 評估套件與 Dashboard,可量化成功率

    可行動步驟:

    • 先把現有「單 Agent 自動流程」改成有重試與 checkpoint
    • 對每個任務記錄:總步數、失敗點、重試次數,在 Dashboard 裡看瓶頸

    3. 平價版本:你也能做一個「迷你 Antigravity」

    你不需要 Gemini 3.5 Flash + Google 內部 Runtime 才能玩多 Agent。下面這些工具可以在自家專案做一個縮小版:

    名稱 核心功能 免費方案 適合誰
    Forge 多步代理 guardrails、重試、Dashboard 開源 想提升本地 / 自架 LLM 可靠性的工程師
    llama.cpp + Qwen 本地 Agent 在個人電腦跑本地模型 + 簡易工具調用 開源 想省雲端費用、在內網跑 Agent 的團隊
    MCP 生態(如 OpenAI MCP、各種 server) 統一的工具協議,讓 Agent 調用資料庫、API 等 多數開源 / 免費 想把既有系統暴露為 Agent 工具的後端工程師

    一個實用組合示例:

    • 模型:Qwen 2.5 7B / 14B(透過 llama.cppOllama 跑)
    • Runtime:Forge 當 guardrails
    • 工具層:一組 MCP server(例如 PostgreSQL、HTTP、Filesystem)

    你可以先做一個「自動搭建 CRUD 服務」的迷你 Antigravity:

    1. 使用者輸入需求(自然語言)
    2. architect-agent 產出設計 + 任務拆解
    3. backend-agent + frontend-agent 寫程式碼
    4. tester-agent 自動開發 & 執行測試
    5. integrator-agentbuild 並回報狀態

    適合誰用:三種典型場景

    1. 後端 / 全端工程師:自動化 CRUD 小專案

    你可以把「打造新微服務」變成一個表單:

    • 輸入資料模型 + 幾個業務規則
    • 多 Agent 流程負責 scaffold、API、測試、docker-compose

    行動:從一個只需要 3–5 小時就能手刻完的小服務開始,先讓多 Agent 幫你做到 70–80%,你只負責 code review。


    2. 資料團隊:資料管線與 ETL 任務

    • planner-agent:解析需求、拆成抽取/轉換/載入步驟
    • sql-agent:產生查詢與 view
    • check-agent:比對 row count、品質指標

    行動:挑一個每天都在重複手動跑的 ETL 任務,做成標準流程,讓 Agent 幫你自動生成 SQL + 驗證報表。


    3. 產品 / PM:快速驗證 Side Project

    • 搭配 Gemini 3.5(雲端)或本地 LLM
    • 定義一個「最小可行功能」(例如 landing page + 簡單 API)
    • 用多 Agent 完成第一版,再丟給工程師接手

    行動:每次新點子,給自己一個規則:「先讓多 Agent 寫一版 Demo,我只在最後 2 小時調整。」


    怎麼開始:一個最小可行範例

    這裡給一條「3–5 小時內可完成」的路線,你可以直接照做:

    步驟 1:選模型 + Agent 框架

    • 模型:
    • 想省錢/本地:Qwen 2.5 7B(透過 llama.cppOllama
    • 想雲端無痛:Gemini 3.5 Flash(透過 Google AI Studio
    • Runtime / 框架:
    • 想要 guardrails:裝 Forge
    • 想用現成 MCP:選一個支援 MCP 的 Agent 框架(如 OpenAI 官方 Agent SDK)

    步驟 2:挑一個小系統

    條件:

    • 單服務、沒有第三方整合
    • 你自己寫大約 3–5 小時能完成

    例:任務管理 CRUD API + 簡單 React 前端

    步驟 3:設計任務拆分與 Agent 角色

    1. 任務描述寫成一個 markdown 檔(會給 architect-agent 看)
    2. 在 Runtime 中註冊 4 個 Agent:
    3. architect
    4. backend
    5. frontend
    6. tester/integrator
    7. 為每個 Agent 明確:
    8. 可用工具(Git、Filesystem、HTTP…)
    9. 輸入(上一個 Agent 的輸出 / 檔案)
    10. 必須產出什麼檔案

    步驟 4:加上監控 Dashboard

    • 如果用 Forge:直接啟用它的 Dashboard,看每次工作流的步驟成功率
    • 若自己實作:
    • 為每個步驟記錄:開始時間、結束時間、是否重試
    • 每次失敗時存 log + 輸入輸出到一個資料夾

    步驟 5:只做一件事的迭代

    • 第一版只要求「能跑起來」,不追求漂亮結構
    • 每次失敗,你只調整:
    • 任務拆分是否太粗/太細
    • Agent 提示是否太模糊
    • 重試與 checkpoint 是否設太少

    等到這個小系統穩定後,你才讓 Runtime 去碰更大的專案。


    小結:Runtime 是你的「AI 開發主管」

    Antigravity 2.0 用 96 個 Gemini Agent 寫出一套能跑《Doom》 的 OS,看起來很遠,但背後用到的概念其實都可落在你今天的 side project 上:

    • 把任務拆成 Agent 可接手的小單位
    • 用 Runtime 管控流程,而不是寄望模型每次都猜對
    • 利用開源工具(Forge、llama.cpp、MCP)做出自己的「迷你 Antigravity」

    💡 關鍵: 關鍵不是再換一個更大的模型,而是把現有模型放進可靠的 Runtime,讓它真的「交付」可用產物。

    關鍵不是再換一個更大的模型,而是先把你手上的模型,放進一個可靠的 Runtime 裡,讓它真的幫你「交付」東西。

    🚀 你現在可以做的事

    • 在 GitHub 上看看 Forge 專案,了解多步代理的 guardrails 怎麼設計
    • 挑一個 3–5 小時能手刻完的 CRUD 小服務,照文中的 4 個 Agent 角色拆任務實作一次
    • 把既有的單 Agent 自動化腳本,加上 max_retries 和簡單 checkpoint 機制,量化成功率變化
  • GAIA 本地多代理實戰指南

    GAIA 本地多代理實戰指南

    📌 本文重點

    • 本地多代理更可控
    • sandbox 與權限隔離
    • 先選小模型再優化
    • Workflow 可 checkpoint

    在本地硬體上跑 GAIA 多代理 workflow,直接解決三個實際痛點:

    💡 關鍵: 本地部署的核心價值,不只是省雲端費用,更是把隱私、延遲和權限控制都收回自己手上。

    1. 隱私與合規:內網知識庫、檔案內容不出機器,減少 DLP 顧慮。
    2. 可控成本與延遲:不綁雲端 API,長任務與大量工具呼叫的成本與延遲可預期。
    3. 更細緻的權限隔離與除錯:工具執行在你設計的 sandbox 內,log、資源監控都在本機可觀測。

    以下以「本地檔案整理 + 內網知識庫助理」為具體任務,示範如何用 GAIA 在單機上組出一個可用的多代理系統,並說清楚在 Apple Silicon / GPU / 純 CPU 場景下要怎麼選 LLM 和調整架構。


    重點說明

    1. GAIA 的基本心智模型:Agent / 任務 / 工具

    GAIA 的抽象其實很單純:

    • Agent:有「目標 + 能力」的行為體,通常綁一個 LLM + 一組工具。
    • 任務(Task / Workflow:定義起點、終點,以及 Agent 如何接力。
    • 工具(Tools:一組可呼叫的函式,如檔案系統、HTTP、向量搜索,GAIA 會把它們包成可被 LLM 呼叫的函式呼叫介面。

    實務上你會這樣切:

    • 一個 Planner Agent 負責拆解高階目標:例如「整理 ~/Downloads 並產出 README」。
    • 一個 FileOps Agent 只負責檔案遍歷、分類、改名,綁定檔案系統工具,權限嚴格限制。
    • 一個 Knowledge Agent 使用向量庫對內網 markdown/PDF 做檢索與摘要。

    2. 在單機協調多代理:比你想像中輕量

    GAIA 不是重型的分散式框架,而是偏 本地 Orchestrator

    • 用一個主 loopworkflow engine 管理 Agent 呼叫順序、中間狀態與錯誤。
    • 每個 Agent 呼叫相同或不同 LLM(例如:Planner 用小模型,Knowledge Agent 用大模型)。
    • 即使只有一張 GPU 或一台 Apple Silicon,透過限流與序列化調度一樣能跑多代理,只是併發要保守。

    3. 本地 LLM 選擇策略(Apple / GPU / CPU)

    Apple Silicon(M1–M4

    • 優先考慮 MLX + Qwen3.5 / Gemma 4 / Llama 家族的 8–9B 量化。
    • 善用像 Reddit 提到的 DFlash 推測解碼:在 9B 級模型上可有 ~4× decoding 加速,對多代理回合式對話很有感。

    💡 關鍵: ~4× decoding 加速代表回合式多代理互動的體感差異會非常明顯,特別是在本地裝置上。

    • 32GB RAM 以上:可以考慮 27B 量級,但要注意 context 與 batch size 的 trade-off。

    桌機 GPUNVIDIA

    • llama.cpp / vLLM / TensorRT-LLM 都可;若用 llama.cpp,可利用社群的 llm-server v2 --ai-tune 自動調 flags,實測 Qwen3.5-27B+50% tok/s 以上,對長任務吞吐提升很明顯。

    💡 關鍵: +50% tok/s 以上的提升,對長任務與大量工具呼叫會直接反映在整體吞吐量上。

    CPU

    • 參考 Gemma 4CPU 的實測,8B 級模型仍可用,但要:
    • 選擇更小模型 + 更 aggressive 量化(如 Q4_K_M);
    • 控制 max_tokens,避免一次生成太長;
    • 任務設計上用更多工具、多輪互動,降低單次生成長度。

    實作範例:從零到一的本地多代理 workflow

    假設你要在 Mac(M2 Pro + 32GB)上做一個:

    指定資料夾路徑 → 自動整理檔案並產出整理報告 → 同時讓知識庫助理可以回答「這次整理做了什麼?」

    以下用簡化版 pseudo-code 示意 GAIA 專案結構與關鍵程式碼。

    專案結構

    my-gaia-local-agents/
    ├── gaia_config.yaml       # GAIA 全域設定(LLM, 日誌, sandbox)
    ├── agents/
    │   ├── planner_agent.py
    │   ├── fileops_agent.py
    │   └── knowledge_agent.py
    ├── tools/
    │   ├── file_tools.py      # 檔案操作工具
    │   └── vectordb_tools.py  # 內網知識庫檢索
    ├── workflows/
    │   └── organize_and_report.py
    └── main.py
    

    1. 定義本地 LLM backend

    假設你用 Ollama + Qwen2.5 7B 作為通用模型(Apple / GPU / CPU 都能跑):

    # gaia_config.yaml
    llm_backends:
      default:
        type: http
        base_url: "http://localhost:11434/v1"
        model: "qwen2.5:7b"
        # 重要:明確限制 context 和輸出長度,避免拖慢整體 workflow
        params:
          max_tokens: 512
          temperature: 0.3
          top_p: 0.9
    
    logging:
      level: INFO
      file: "logs/gaia.log"
    
    sandbox:
      file_root: "./sandbox_root"   # FileOps 只允許在這之下操作
      allow_network: false           # 預設工具無網路
    

    實際好處:

    • HTTP LLM backend,你可以隨時切換到 llama.cpp server / MLX server / vLLM 而不用改 Agent 邏輯。
    • max_tokens + temperature 控制對本地效能非常關鍵,避免一個 Agent 把整個 context 塞爆。

    2. 定義工具:檔案操作與向量檢索

    # tools/file_tools.py
    from gaia import tool
    from pathlib import Path
    
    SANDBOX_ROOT = Path("./sandbox_root").resolve()
    
    @tool(name="list_files", description="列出目錄下的檔案與大小")
    def list_files(path: str) -> dict:
        root = (SANDBOX_ROOT / path).resolve()
        assert root.is_dir() and str(root).startswith(str(SANDBOX_ROOT)), "path out of sandbox"
        files = []
        for p in root.iterdir():
            if p.is_file():
                files.append({"name": p.name, "size": p.stat().st_size})
        return {"files": files}
    
    @tool(name="move_file", description="移動檔案到新資料夾")
    def move_file(src: str, dst: str) -> str:
        src_path = (SANDBOX_ROOT / src).resolve()
        dst_path = (SANDBOX_ROOT / dst).resolve()
        assert str(src_path).startswith(str(SANDBOX_ROOT))
        assert str(dst_path).startswith(str(SANDBOX_ROOT))
        dst_path.parent.mkdir(parents=True, exist_ok=True)
        src_path.rename(dst_path)
        return f"moved {src} to {dst}"
    

    幾個關鍵點:

    • @tool 裝飾器,GAIA 會自動產生給 LLM 用的工具 schema
    • 使用 sandbox_root + startswith 檢查,避免 Agent 亂動整個檔案系統。

    向量檢索工具(略寫):

    # tools/vectordb_tools.py
    from gaia import tool
    from my_vectordb import search
    
    @tool(name="kb_search", description="在內網知識庫中搜尋相關文件")
    def kb_search(query: str, top_k: int = 5) -> list:
        return search(query, top_k=top_k)
    

    3. 定義 Agents

    # agents/planner_agent.py
    from gaia import Agent
    from gaia.llm import LLMClient
    
    llm = LLMClient.from_config("default")
    
    planner = Agent(
      name="planner",
      llm=llm,
      tools=[],  # Planner 不直接動檔案
      system_prompt="""
    你是任務規劃專家。使用簡短 JSON 回覆,包含 steps,
    每個 step 指定要由哪個 agent 執行(fileops 或 knowledge)。
    """
    )
    
    # agents/fileops_agent.py
    from gaia import Agent
    from gaia.llm import LLMClient
    from tools.file_tools import list_files, move_file
    
    llm = LLMClient.from_config("default")
    
    fileops = Agent(
      name="fileops",
      llm=llm,
      tools=[list_files, move_file],
      system_prompt="""
    你負責安全地整理檔案,只能使用提供的工具操作 sandbox 內的路徑。
    每次操作前先列出檔案,再決定如何移動。
    """
    )
    
    # agents/knowledge_agent.py
    from gaia import Agent
    from gaia.llm import LLMClient
    from tools.vectordb_tools import kb_search
    
    llm = LLMClient.from_config("default")
    
    knowledge = Agent(
      name="knowledge",
      llm=llm,
      tools=[kb_search],
      system_prompt="""
    你是內網知識庫助理,先呼叫 kb_search 找到相關內容,
    再用找到的內容回答使用者問題。
    """
    )
    

    4. Workflow:協調多代理 + 任務恢復

    # workflows/organize_and_report.py
    import json
    from gaia import Workflow
    from agents.planner_agent import planner
    from agents.fileops_agent import fileops
    from agents.knowledge_agent import knowledge
    
    class OrganizeWorkflow(Workflow):
        def run(self, target_dir: str):
            # 1) 用 planner 拆解任務
            plan = planner.run_sync(f"請為資料夾 {target_dir} 制定整理計畫,輸出 JSON 格式。")
            steps = json.loads(plan["content"]).get("steps", [])
    
            history = []
            for step in steps:
                agent_name = step["agent"]
                instruction = step["instruction"]
    
                if agent_name == "fileops":
                    result = fileops.run_sync(instruction)
                elif agent_name == "knowledge":
                    result = knowledge.run_sync(instruction)
                else:
                    continue
    
                history.append({"agent": agent_name, "instruction": instruction, "result": result})
                self.save_checkpoint(history)  # **關鍵:長任務可恢復**
    
            return history
    
        def save_checkpoint(self, state):
            with open("./state/organize_checkpoint.json", "w") as f:
                json.dump(state, f, ensure_ascii=False, indent=2)
    

    最後入口:

    # main.py
    from workflows.organize_and_report import OrganizeWorkflow
    
    if __name__ == "__main__":
        wf = OrganizeWorkflow()
        history = wf.run("downloads")
        print("任務完成,歷史記錄:")
        print(history)
    

    實際好處:

    • Workflow + checkpoint 讓你可以安全跑幾十分鐘的整理任務,中途 crash 可恢復。
    • 檔案操作與知識庫檢索被清楚拆成不同 Agent,權限與日誌都更好控管。

    建議與注意事項

    1. 模型大小與上下文限制:先決策、再堆功能

    • 本地 Agent 系統最常見的坑是 一開始就選太大模型 + 太大 context
    • Apple 32GB + 27B 模型 + 128k context 幾乎一定卡。
    • 建議流程:
    • 先用 7–9B 模型 + 8k–16k contextMVP
    • 觀察 GAIA 的日誌與 latency 再決定是否升級模型或 context
    • 用「多輪互動 + 工具」彌補模型容量,而不是盲目換大模型。

    2. 工具執行安全 & sandbox 設計

    • 檔案操作請一定:
    • 使用 sandbox root + path 檢查(如上例)。
    • 禁用 rm -rf 類型操作,必要時只暴露「移動到 trash」工具。
    • Agent 需要網路:
    • proxy 工具封裝(如 http_get),不要讓 Agent 任意發 HTTP
    • 在工具層加 domain allowlist

    3. 長任務與錯誤恢復

    • GAIA workflow 必須:
    • 對每個工具呼叫與 Agent 回應寫入結構化 logJSON)。
    • 週期性 checkpoint 中間狀態(如上例 save_checkpoint)。
    • 常見錯誤種類:
    • LLMJSON 解析失敗 → 在 workflow 層加入重試 + 自我修復 prompt(要求模型只回合法 JSON)。
    • 工具拋例外(路徑不存在、權限錯)→ 在工具層 catch,回傳結構化錯誤訊息給 Agent 解讀,而不是直接 crash。

    4. 本地 vs 雲端 Agent:怎麼選?

    適合用 GAIA 本地落地的場景

    • 需要處理敏感檔案 / 內網知識庫(法務、醫療、R&D 原始碼)。
    • 需要低延遲 + 高互動頻率的工具呼叫(檔案整理、CI/CD 助理、開發環境助手)。
    • 有穩定的本地硬體(Mac Studio / 工作站 / 甚至改造手機當常駐節點,如 Xiaomi + Ollama 案例)。

    仍應用雲端 Agent 平台的情境

    • 短期 PoC,需要快速試多種 SOTA 模型(如 GPT-4.1, Claude 3.7)。
    • 任務高度 bursty,需要按需擴容,或併發數百以上的 Agent 任務。
    • 需要平台級功能(RBAC、審計、隊列管理)而你不想自己實作。

    實務建議:

    • 先在雲端 Agent 平台驗證 prompt、工具設計、整體 UX
    • 穩定後再把核心工作流搬到 GAIA + 本地 LLM 上,對敏感資料與長任務特別划算。

    總結:GAIA 提供的是一個 在本地硬體上「可觀測、可控、可擴展」的多代理骨架。搭配 Apple Silicon/桌機 GPU 的本地 LLM 加速(--ai-tuneDFlash 等),你可以在單機上跑出相當實用的 AI Agents,而不再被雲端 API 綁死。關鍵是:先把 Agent / 工具 / Workflow 的邊界切清楚,再談模型與效能優化

    🚀 你現在可以做的事

    • 先在 Ollamallama.cpp 上跑一個 7B 模型
    • 按本文結構拆出 plannerfileopsknowledge 三個 Agent
    • 先用 sandbox_root 做安全檔案操作,再逐步加上 checkpointkb_search