標籤: 手機跑 AI 模型

  • 用手機跑 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 空間準備導入模型
  • 在手機上跑本地滲透測試 AI:Nightcrawler 實戰

    在手機上跑本地滲透測試 AI:Nightcrawler 實戰

    📌 本文重點

    • Nightcrawler 讓手機成為行動滲透測試助手
    • 所有掃描與報告盡量在本地完成以保護隱私
    • 適合個人、小型內網與紅隊前期偵察使用
    • 只需簡單設定即可建立可重複安全檢查流程

    只用一支手機,在本地跑一個 AI pentesting agent,幫你自動掃描手機與周邊網路、找出潛在弱點並給出修補建議,這就是 Nightcrawler 要解決的問題。

    專案連結:https://github.com/garagehq/nightcrawler/


    核心功能:手機上的「行動滲透測試助手」

    1. 本地運行的 AI 滲透測試代理

    Nightcrawler 的定位很單純:在你的手機上扮演一個會自動行動的「滲透測試助手」,所有分析與推理盡量在本地完成。

    你可以直接讓它:

    • 在目前網路環境中自動偵測可掃描的目標(路由器、NAS、開發機等)
    • 針對指定 IP、子網做基本安全檢查
    • 把掃描結果整理成報告,並列出優先處理的問題

    可行動: 安裝完成後,從最簡單的指令開始:

    nightcrawler scan --target 192.168.0.0/24
    

    這會讓它在你家或辦公室內網跑一輪基本偵察,之後再看報告調整範圍。


    2. 自動掃描手機與周邊網路

    Nightcrawler 的重點不是只看「單一主機」,而是以你的手機作為入口,對周邊環境做偵察與掃描。

    實際能做到的事情包括:

    • 讀取手機目前連線的 Wi-Fi 網段,列出可到達的主機
    • 對這些主機做基本的 port scan / service 掃描
    • 將服務指紋交給 AI module,判斷可能存在的弱點類型(例如:舊版 HTTP 伺服器、未設密碼的管理介面)

    💡 關鍵: 透過手機作為入口,可以在不額外佈署設備的情況下掌握整個局部網路的暴露面。

    可行動: 在安全範圍內測試家中設備:

    nightcrawler scan --auto
    

    這會依照手機當前的網路環境自動偵測可掃描主機,適合初次使用快速看「家用設備有哪些服務暴露在網路上」。

    提醒:只在你有權限的網路與設備上使用,遵守當地法律與公司安全政策。


    3. 弱點說明 + 修補建議,一次給你

    掃描只是第一步,Nightcrawler 的價值在於「解讀」:它會用 AI 把技術細節翻譯成你可以直接採取行動的建議。

    一份典型報告會包含:

    • 找到的主機列表、服務與 port
    • 可能的風險標籤(例如:medium-risk: outdated SSH
    • 每條問題的:
    • 為什麼是風險
    • 可能被怎麼利用
    • 具體修補步驟(更新版本、關閉不必要服務、改密碼策略等)

    💡 關鍵: 把「資安專業術語」轉成具體修補步驟,是讓非專業使用者也能實際提升安全的關鍵差異。

    可行動: 每次跑完掃描後,把報告依「風險等級」分三類:

    • 先處理 High:例如公開管理介面、預設帳密
    • 再排 Medium:例如舊版服務、弱加密
    • Low 視情況保留或記錄

    4. 本地運行的隱私與延遲優勢

    與雲端安全掃描工具相比,Nightcrawler 強調「盡可能在本地推理」,好處是:

    • 不需把內網結構、設備 IP、服務資訊丟到第三方伺服器
    • 在弱網路或無網路環境仍可使用基本功能
    • 掃描結果只存放在你手機本地,方便做內網紅隊演練前期偵察

    💡 關鍵: 把掃描與分析留在本地,可以同時兼顧安全檢查與敏感環境下的隱私需求。

    可行動: 在報告設定中,將輸出目錄指定為手機加密儲存區或你信任的私有備份方案(如加密同步到自建 NAS),避免報告外流:

    nightcrawler scan --target 192.168.0.0/24 --output /secure/reports/
    

    適合誰用:三個具體場景

    1. 個人手機安全檢查

    如果你平常只靠 Android/iOS 內建的安全提示,其實只看到「App 權限」的一小部分。Nightcrawler 可以幫你補上:

    • 手機連線的 Wi-Fi 是否有可疑設備
    • 是否有開啟但你根本沒在用的服務(如某些測試用 web server)
    • 從外部角度看你的開發機、測試機有多「裸露」

    可行動: 每次連上公共 Wi-Fi(咖啡店、旅館)時,跑一次快速掃描:

    nightcrawler scan --auto --profile public_wifi
    

    把這當作「連上陌生網路前的健康檢查」。


    2. 小型內網的簡易滲透測試

    對中小企業、小型團隊來說,請專業資安顧問做完整滲透測試成本不低,但你可以先用 Nightcrawler 做一輪「預檢」。

    適合用在:

    • 新部署內網服務前,快速看是否有明顯暴露
    • 老舊系統尚未汰換前,先抓幾個最容易被打的點
    • 內部開發環境(CI server、test server)是否有開到外部網段

    可行動: 選擇一個子網作為範圍,定期(例如每月)跑一輪掃描,建立安全 baseline:

    nightcrawler scan --target 10.0.0.0/24 --output /secure/monthly/
    

    之後比對差異,看是否有新增高風險服務或設備。


    3. 紅隊演練的前期偵察

    對紅隊或安全研究者來說,Nightcrawler 可以當作「隨身偵察工具」。在合法授權範圍內:

    • 用手機在現場快速掃描演練環境
    • 取得初步服務列表後,再用更專業工具(如 nmapBurp)深挖
    • 用 AI 生成攻擊路徑假設,幫助制定演練腳本

    可行動: 把 Nightcrawler 報告當作演練前的「資產盤點」,再把標記為 High 的項目納入紅隊攻擊路徑設計。


    怎麼開始:從安裝到第一次掃描

    1. 下載與安裝

    目前 Nightcrawler 以開源專案形式提供,主入口在 GitHub:

    https://github.com/garagehq/nightcrawler/

    一般上手路線:

    1. 確認支援平台:以 Android(搭配 Termux)或 Linux 手機環境為主,iOS 需額外繞路(如越獄或遠端代理)。
    2. 安裝必要環境:在手機安裝 Termux 或類似終端環境;確保有 Python / Node.js(依專案需求)與必要套件。
    3. Clone 專案
      bash
      git clone https://github.com/garagehq/nightcrawler.git
      cd nightcrawler
    4. 依 README 安裝依賴:通常是 pip install -r requirements.txt 或專案提供的安裝腳本。

    可行動: 完成上述步驟後,在終端輸入:

    nightcrawler --help
    

    確認指令有正確註冊,確定環境準備完畢。


    2. 基本配置:先限制好掃描範圍

    為了避免不小心掃到不該掃的網段,建議一開始就設定清楚:

    • 指定允許掃描的子網(例如:家用路由器分配的網段)
    • 限制最大併發連線數,避免造成設備負擔
    • 啟用報告匿名化(隱藏部分 IP、主機名,方便分享給同事但不暴露太多細節)

    範例配置檔(假設為 config.yaml):

    network:
      allowed_ranges:
        - 192.168.0.0/24
      max_concurrent_scans: 32
    report:
      anonymize: true
      output_dir: /secure/reports/
    

    可行動: 按上述範例建立自己的 config.yaml,之後所有掃描都帶上:

    nightcrawler scan --config config.yaml --auto
    

    3. 第一次執行建議腳本與報告解讀方式

    第一次跑,建議用「保守但全面」的腳本:

    nightcrawler scan \
      --config config.yaml \
      --target 192.168.0.0/24 \
      --profile default \
      --output /secure/reports/first_scan.json
    

    跑完後,報告通常為 JSON 或簡易 HTML。解讀時可以照這個順序:

    1. 先看 Summary:總共有多少主機、幾個 High / Medium / Low issue。
    2. 鎖定 High:逐一查看是哪些設備(路由器?NAS?開發機?),問題是什麼類型(弱密碼、未授權存取、舊版服務)。
    3. 執行修補:根據建議更新 firmware、關掉不必要服務、改強密碼政策。
    4. 再跑一次掃描:確認問題是否消失或降級。

    可行動: 把第一份報告視為「現狀快照」,搭配你現有的備份/加固流程,一次整理。


    簡單 workflow 示範:Nightcrawler + 備份 / 加固工具

    為了讓你讀完就能馬上用,這裡給一個最簡單可落地的 workflow:

    1. 偵察與報告(Nightcrawler)
    2. 每月或每次環境變更後,跑一次:
      bash
      nightcrawler scan --config config.yaml --auto --output /secure/reports/scan_$(date +%F).json

    3. 備份重要設定與資料(例如:rsync / restic / 自建 NAS 工具)

    4. 對報告中標記為「關鍵設備」的主機,將設定檔與重要資料做加密備份。
    5. 可用簡單指令,例如:
      bash
      rsync -avz /etc /backup/router_config/

    6. 加固與追蹤

    7. 根據 Nightcrawler 報告中的修補建議,逐項調整設定。
    8. 建立一個簡單的變更紀錄(哪一天改了哪台設備、做了什麼修補)。
    9. 下次掃描時,比對報告、確認風險有下降。

    這樣,你就用一支手機,建立起一個「可重複、可追蹤」的個人或小型團隊安全檢查流程。


    小結

    Nightcrawler 把「手機上跑本地滲透測試 AI」這件事變成日常可以操作的工作:連上網路、跑掃描、看報告、依建議加固。只要你願意花一點時間設定範圍與流程,就能在不依賴雲端的大前提下,對自己的手機和內網做更有系統的安全檢查。

    🚀 你現在可以做的事

    • 到 GitHub 下載並安裝 Nightcrawler,完成環境與依賴設定
    • 建立自己的 config.yaml,限定掃描網段並設定輸出目錄後跑一次初始掃描
    • 依第一份報告中的 High / Medium 風險執行修補,並建立每月定期掃描與變更紀錄流程
  • 在手機跑 27B 模型:Bonsai 27B 實戰上手

    在手機跑 27B 模型:Bonsai 27B 實戰上手

    📌 本文重點

    • 27B 模型壓到 3.8GB
    • 本地跑在 iPhone 與瀏覽器
    • 數學與程式推理仍可用
    • 適合隱私優先的 AI 場景

    用一句話說完:Bonsai 27B 讓一個原本要 50GB 以上的大型推理模型,縮到不到 4GB,在你的 iPhone 或瀏覽器裡本地跑推理。

    原始資訊與 Demo:


    核心功能:為什麼 1-bit4GBWebGPU 很關鍵?

    1. 1-bit dense 量化:54GB 壓到 3.8GB,還保留 90% 能力

    Bonsai 27B 原始是 27B 參數的大模型,正常 fp16 大概要 50GB 以上。PrismML 用自家的 1-bit dense 量化,直接把模型縮到約 3.8GB-93%,官方與社群測試顯示:

    • 整體表現:約保留 90% 原始性能
    • 在數學與程式碼推理上的分數,幾乎不受影響

    💡 關鍵: 27B 級模型從 50GB+ 壓到 3.8GB,代表大型模型首次更接近一般裝置可本地部署的範圍。

    這對你代表什麼?

    • 一般高階筆電、桌機的 GPUWebGPU 就能跑 27B 級模型
    • iPhone 等手機只要有足夠 RAM,也能載得下整個模型
    • 做產品 PoC 時,不用再想「我要租幾張雲端 GPU」才能展示效果

    你可以立刻做的事:

    2. 本機 / 手機 / 瀏覽器推理:速度與隱私的平衡點

    Bonsai 27B 的壓縮搭配 WebGPU + 客製 Kernel,讓它可以在:

    • 桌機瀏覽器(ChromeEdgeArc 等支援 WebGPU 的版本)直接跑
    • iPhone 上透過支援 WebGPU 的瀏覽器或 App 跑本地推理

    實際體感: 依硬體而異,但大致區間如下:

    • 答案生成速度:中高階筆電可達 20~40 tokens/s,接近雲端中階模型
    • 手機上:會慢一些,但仍能用於聊天、寫作輔助、簡易程式碼推理

    💡 關鍵: 本地推理不只是能跑,速度已進到可互動使用的區間,隱私與延遲也因此開始有實際優勢。

    隱私優勢:

    • 所有輸入(聊天內容、筆記、程式碼)都留在裝置上,不經過雲端 API
    • 適合公司內部敏感資料、個人私密日記、會議記錄摘要等情境

    你可以立刻做的事:

    • 打開支援 WebGPU 的瀏覽器,跑官方 Demo:確認你的硬體大概能跑到什麼速度(Demo 入口通常在 PrismML 新聞頁或 Hugging Face Space)。

    3. 數學與程式碼推理表現:不只是「能跑」,而是「能用」

    依據 PrismML 自家基準測試(見 Reddit 討論:https://www.reddit.com/r/LocalLLaMA/comments/1uwm2hd/prismmls_bonsai27b_benchmarks/),Bonsai 27B 的量化版本:

    • 在數學、程式碼題目上的分數,與原始模型接近
    • 部分測試甚至優於廣為討論的 Qwen 3.7 27B 量化版本

    💡 關鍵: 有趣的是,這類極端壓縮不一定先犧牲數學與程式碼推理,實際上它在這兩類任務仍維持可用水準。

    實際體感上,它適合:

    • LeetCode 等級的題目、協助理解他人程式碼
    • 做數學證明草稿、檢查推理步驟是否有漏洞

    你可以立刻做的事:

    • 準備一段你自己寫的程式碼或演算法題目,在 Demo 裡測試它的 debug 能力,看它能不能說出具體修改建議。

    適合誰用?具體場景與做法

    1. 個人使用:離線寫作、私密筆記與聊天

    場景:

    • 不想把日記、心理對話丟到雲端模型
    • 在飛機、車上等無網路環境寫作

    可以怎麼用:

    • 在桌機瀏覽器開 Bonsai 27B WebGPU Demo,寫文章時讓它幫你改標題、想小節架構
    • 在支援的手機上安裝對應 App 或透過瀏覽器,做離線聊天與筆記整理

    2. 開發者:簡易 coding 助手與邊緣 AI PoC

    場景:

    • 做一個「本地程式碼助手」Side project
    • 想給客戶看「產品內嵌 on-device 聊天/推理」的原型

    可以怎麼用:

    • 使用 Bonsai 27Bgguf 版本,搭配像 llama.cpp 或其他本地推理框架,在筆電上跑一個命令列助手
    • Web 前端整合官方 WebGPU 推理程式碼,做一個「瀏覽器內跑的大模型聊天框」,無需後端 GPU

    3. 產品團隊:在 App 裡塞 on-device 聊天 / 推理

    場景:

    • 筆記 App 想加「在本機摘要筆記」功能
    • 知識庫產品想做「邊緣 FAQ 助手」,部署在客戶內網而不是雲端

    可以怎麼用:

    • WebGPUBonsai 27B 做前端推理引擎,後端只處理權限與資料存取
    • iOS App 裡預載或動態下載壓縮模型,讓使用者自主選擇是否開啟「完全本地 AI 模式」

    什麼時候考慮不用它?

    • 若你需要 GPT-4 級別的長上下文寫作、極高準確度的工具調用
    • 若手機使用者硬體普遍較舊,無法提供足夠 RAMWebGPU 支援

    怎麼開始:從 WebGPU DemoiPhone 實跑

    Step 1:在桌機用 WebGPU Demo 跑起來

    1. 確認瀏覽器支援 WebGPU
    2. Chrome / Edge:版本需在 113+,建議更新到最新穩定版
    3. chrome://flags 搜尋 WebGPU,確保已啟用(某些平台預設已開)

    4. 進入 Demo 網頁

    5. PrismML 新聞頁:https://prismml.com/news/bonsai-27b 找到 WebGPU Demo 連結
    6. 或在 Hugging Face 上搜尋 Bonsai 27B WebGPU 找到 Space

    7. 測試推理

    8. 選擇 Bonsai-27B 1-bit 模型版本
    9. 輸入一個你熟悉的程式題目或寫作題目,觀察回答速度與品質

    常見坑:若載入卡住或速度極慢,通常是 WebGPU 未啟用,或顯示卡太舊。換瀏覽器或更新驅動是第一步。

    Step 2:在 iPhone 嘗試跑 Bonsai 27B

    目前 iPhone 端的整合仍在快速變動階段,Apple 也被報導正在測試 PrismML 技術(參考:https://www.reddit.com/r/LocalLLaMA/comments/1ux4cn2/apple_in_talks_with_startup_prismml_that_shrinks/)。以下是一般建議路線:

    1. 確認機型與系統
    2. 建議使用 A17 / M 系列晶片的機型,RAM 越大越好(Pro 機型優先)
    3. iOS 更新到最新版本,以取得最佳 WebGPU / Metal 支援

    4. 嘗試透過瀏覽器 Demo

    5. 使用支援 WebGPUiOS 瀏覽器(未來 Safari 正式支援後會更穩定)
    6. 開啟 Bonsai 27B Web Demo,選最低階參數設定,測試生成速度

    7. 留意記憶體與耗電

    8. 模型雖然不到 4GB,但推理仍會吃 RAM;建議在單一 App 裡跑,不要開太多背景程式
    9. 長時間推理會發熱,適合短對話與輕量寫作,而非長時間批量任務

    常見坑:

    • 推理中 AppiOS 回收:代表 RAM 不足,只能調小 context 長度或改用桌機。
    • 首次載入模型時間偏長:正常現象,可考慮在 App 中做「背景預載」。

    Step 3:整合到你的應用(基本架構示意)

    Web 應用為例,一般做法是:

    使用者瀏覽器
     ├─ UI:聊天框 / 筆記編輯器
     ├─ WebGPU 推理:載入 Bonsai 27B 壓縮模型
     └─ 本地記憶體:暫存對話與提示
    
    後端伺服器
     ├─ 使用者認證 & 權限
     ├─ 資料索引(向量庫、文檔)
     └─ 僅在用戶同意時返回資料,讓前端本地推理
    

    你可以:

    • 直接參考 PrismML 提供的 WebGPU Kernel 實作,把它包成一個 JS/TS SDK
    • 將模型檔放在 CDN,首次使用時下載到瀏覽器 IndexedDBApp 沙盒中

    本地 Bonsai 27B vs 雲端 API:成本與隱私快速比較

    項目 Bonsai 27B 本地推理 雲端 API(如 GPT-4)
    成本 一次下載模型,之後幾乎零邊際成本,主要是硬體耗電 tokens 計費,流量大時費用顯著
    延遲 裝置好時可達 20–40 tokens/s,無網路也能用 需經網路與伺服器排隊,遇高峰時延遲高
    隱私 所有內容留在本機,適合敏感資料 對話上傳到雲端,需信任供應商
    維護 需自己管理模型更新與相容性 供應商幫你維持最新模型與基礎設施

    簡單判斷:

    • 若你重視隱私、成本可控、願意接受略低於頂級雲端模型的效果,Bonsai 27B 是合適的本地方案。
    • 若你的產品主打極高準確度、長上下文、工具調用整合,仍需要雲端 API 作為主力,Bonsai 27B 可做輔助或離線備份模式。

    小結:下一步你可以做什麼?

    1. 用桌機開 Bonsai 27B WebGPU Demo,測試寫作與程式碼題目,感受性能。
    2. 若你是開發者,下載 Hugging Face 量化模型,在本地框架中跑一個簡單聊天助手。
    3. 思考你的產品裡哪個功能最需要「本地推理+隱私」,從那一點開始嘗試嵌入 Bonsai 27B

    🚀 你現在可以做的事

    • 打開 PrismML 官方新聞頁,直接進 WebGPU Demo 測你的裝置速度
    • Hugging Face 搜尋 prism-ml/Bonsai-27B-gguf,下載量化模型做本地測試
    • 拿一段你自己的程式碼、筆記或寫作題目,驗證它是否符合你的實際場景
  • Needle:把工具調用 Agent 塞進手機

    Needle:把工具調用 Agent 塞進手機

    📌 本文重點

    • Needle 是專門負責工具選擇與參數填充的小型中控模型
    • 能在手機級硬體離線、高吞吐運行,降低雲端大模型成本
    • 最適合當工具路由器 / 前置規劃器,輸出穩定 JSON 給其他系統

    Needle 就是一顆專門幫大模型「只負責選工具、組參數、吐 JSON」的超小中控腦,讓工具調用 Agent 能在手機級硬體離線或低延遲運作。

    原始專案在 GitHub:https://github.com/cactus-compute/needle


    核心功能:專心當「工具路由中樞」的 26M 模型

    1. 26M 參數 + 純 Attention:為工具調用瘦身

    Needle 的設計很直接:

    • 只有約 2600 萬參數(26M),比動輒數十億參數的聊天模型小一到兩個數量級。
    • 結構是 Simple Attention Network:只有 attention + gating,沒有 MLP/FFN 層。
    • 目標任務只有一件事:
    • 讀取指令 + 工具列表描述
    • 選擇要用哪個工具(或多個)
    • 從指令中抽出參數
    • 輸出工具調用 JSON

    💡 關鍵: 只有約 2600 萬參數的 Needle,能在極小成本下專門負責工具路由與參數抽取,是取代通用大模型做 function calling 決策的關鍵。

    這代表你的行動步驟是:

    • 如果你現在是用 GPT / Gemini / Claude 來做工具決策(例如 function calling),可以把「決定用什麼工具」這一步改交給 Needle,減少大模型 token 消耗與延遲。

    2. 專門為工具調用預訓與微調

    Needle 的訓練重點不是聊天對話,而是「工具使用」:

    • 先在 200 億 token 上預訓練語言能力。
    • 再用約 20 億條合成函數調用資料微調,來源是模擬 Gemini style 工具(例如鬧鐘、導航、日曆、筆記等)。

    💡 關鍵: 針對 20 億條函數調用資料微調,讓 Needle 在工具選擇與參數解析上比同尺寸聊天模型穩定得多。

    實際上,它不負責長篇推理,而是非常擅長:

    • 從口語指令中抓出結構化欄位(時間、地點、標題…)。
    • 在多個工具之間做正確匹配。
    • 輸出符合 schema 的 JSON 給你直接丟進 API。

    行動建議:

    • 如果你已經有一組工具 schema(例如 OpenAPI、function calling 定義),可以直接拿來給 Needle,讓它幫你產生調用 payload,再由你自己的程式實際發 API。

    3. 手機級硬體也能跑的高吞吐

    作者實測在「消費級裝置」可達:

    • 6000 tok/s prefill
    • 1200 tok/s decode

    💡 關鍵: 在一般消費級裝置上就能達到 6000 tok/s prefill、1200 tok/s decode,讓 Needle 可以長駐於手機與邊緣設備當本地 Agent 大腦。

    翻成白話:

    • 放在中階手機、平板、開發板(如樹莓派級別 SoC)上,當離線工具路由器是可行的。
    • 可以把 Needle 當作 永遠常駐的本地 Agent 大腦,大模型只在真正需要複雜推理/生成時才被叫起。

    行動建議:

    • 如果你正在做行動 App 或智慧硬體(耳機、車機、家電),可以先用 Laptop 上測試 Needle 的工具選擇邏輯,再評估移植到裝置端做本地推理。

    適合誰用:三種典型場景

    1. 行動裝置上的離線 / 低延遲 Agent

    典型案例:

    • 「早上 7 點幫我叫醒,順便播固定歌單」→ Needle 決定:set_alarm + play_playlist
    • 「開車回家,避開高速公路」→ Needle 決定:navigate,並填好目的地與偏好
    • 「幫我記一條:明天 meeting 要問預算」→ Needle 決定:create_note,抽出時間與內容

    做法:

    • 語音 → 本地 ASR(或雲端 Transcription)
    • 文字指令 + 工具列表 → Needle → 工具 JSON
    • 裝置端程式依 JSON 實際調起鬧鐘、導航、筆記 App

    適合:行動 App 團隊、智慧手錶 / 車機 / AR 眼鏡、想要弱網路或離線也能用的指令助手

    2. 雲端大模型前面加一層「本地工具路由器」

    你可能遇過這種成本問題:

    • 每個使用者點一個按鈕,就丟完整上下文給 GPT 讓它幫你:
    • 看要不要查資料庫
    • 看要不要 call search API
    • 看要不要調 CRM
    • 結果大部分情況都只是在查一個欄位,卻要跑一整輪大模型推理。

    用 Needle 可以:

    • 由 Needle 先判斷:這次是否需要工具?用哪個?
    • 只有當需要長推理 / 文本生成時,才叫雲端 LLM

    這樣能直接對應到多代理系統常被提到的「orchestration tax」問題:減少不必要的 LLM orchestration 回合數。

    適合:SaaS 後端、API 產品、任何大量使用 function calling 的服務,希望降成本 + 降延遲

    3. MCP / Function Calling 之前的一層「前置規劃器」

    如果你已經在用:

    • OpenAI / Gemini / ClaudeTool Use / Function Calling
    • 或是某種 MCP(Multi-Channel Prompting 或 Model Context Protocol)架構

    Needle 可以扮演:

    • 用戶輸入 → Needle 選擇:
    • 要走哪一條 MCP channel
    • 要用哪個 Function / Tool
    • 再把整理好的工具調用意圖,交給聊天模型做:
    • 實際回應文案
    • 或進一步分解子任務

    差別在於:

    • 一般微型聊天模型:
    • 會嘗試「理解+回答+決定工具」,但在複雜工具 schema 上容易出錯或 hallucinate。
    • Needle:
    • 不負責聊天,只專注在「選工具+填參數+吐 JSON」。

    適合:已經有多工具、多 Agent 架構的團隊,需要一個可控、可本地跑的規劃器 / 路由器


    Needle vs 一般微型聊天模型

    名稱 核心功能 免費方案 適合誰
    Needle 工具選擇+參數抽取+輸出 JSON 完全開源,自架 行動 App、硬體端、本地 Agent
    微型聊天模型 閒聊、簡單問答 多數可免費測試 想要基本對話、不重工具調用的人

    關鍵差異:

    • Needle 的輸出預期是結構化工具調用,不是自然語言回答。
    • 在工具 schema 清楚的情況下,Needle 通常比同尺寸聊天模型更穩定地填參數、遵守格式。

    行動建議:

    • 若你只需要「會聊天」:選一般微型聊天模型。
    • 若你需要「穩定地依 schema 呼叫工具」:可以試 Needle 當前置規劃器,再用大模型生成回覆文案。

    怎麼開始:從 clone Repo 到跑出第一個工具調用

    1. 抓下專案與模型

    # 1. clone repo
    git clone https://github.com/cactus-compute/needle.git
    cd needle
    
    # 2. 建議先建立虛擬環境
    python -m venv .venv
    source .venv/bin/activate  # Windows 用 .venv\Scripts\activate
    
    # 3. 安裝依賴
    pip install -r requirements.txt
    

    模型本體會在首次推理時自動下載(或依 README 指示手動下載權重)。

    2. 用現成推理腳本跑官方 demo

    Repo 裡提供了簡單的推理範例(實際檔名可能隨版本變動,可在 examples/ 或 README 中找到):

    python examples/simple_tool_calling.py
    

    通常你需要提供:

    • 工具 schema(JSON / Python dict)
    • 使用者指令文字

    腳本會回傳一段包含工具名稱與參數的 JSON,確認能跑通是第一步。

    行動建議:

    • 先照官方 demo 跑一遍,不改任何 schema,只看 Needle 如何選工具。

    3. 定義自己的工具 schema

    假設你要做一個簡單的鬧鐘 + 記事 Agent,可以這樣定義工具(示意):

    tools = [
      {
        "name": "set_alarm",
        "description": "設定鬧鐘時間(24 小時制)",
        "parameters": {
          "type": "object",
          "properties": {
            "time": {"type": "string", "description": "例如 07:30"},
            "label": {"type": "string", "description": "鬧鐘備註"}
          },
          "required": ["time"]
        }
      },
      {
        "name": "create_note",
        "description": "建立一則文字筆記",
        "parameters": {
          "type": "object",
          "properties": {
            "title": {"type": "string"},
            "content": {"type": "string"}
          },
          "required": ["content"]
        }
      }
    ]
    

    接著丟給 Needle:

    from needle import NeedleModel
    
    model = NeedleModel.from_pretrained("cactus/needle-base")
    
    user_query = "明天早上七點叫我起床,順便幫我記:早會要問預算"
    
    result = model.route_tools(query=user_query, tools=tools)
    print(result)
    

    預期會拿到類似:

    [
      {
        "tool": "set_alarm",
        "arguments": {"time": "07:00", "label": "早會"}
      },
      {
        "tool": "create_note",
        "arguments": {"title": "早會", "content": "早會要問預算"}
      }
    ]
    

    接下來只要用你熟悉的語言(Swift / Kotlin / Node / Python),依這個 JSON 實際呼叫 OS API 或雲端 API 即可。

    4. 把 Needle 接在現有 LLM 後面,做一條簡單 workflow

    以下是一條最小可行的 workflow(伪碼):

    1. 語音 → 文字
    2. 行動裝置用本地或雲端 ASR:
    3. speech.wav -> transcript = "幫我找台北明天不下雨的戶外咖啡廳"

    4. Needle 選工具

    5. 工具例:search_weather, search_places 兩個 API。
    6. needle.route_tools(transcript, tools) → 回傳要先查天氣再查地點的參數 JSON。

    7. 實際 API 呼叫

    8. 你的後端或 App 依 Needle 給的 JSON,分別呼叫天氣 API、地點 API,整理出可用候選。

    9. 大模型生成回覆(可選)

    10. 把 API 結果 + 原始指令送給 GPT / Gemini / Claude,只讓它負責自然語言回覆:「幫你找到三間明天不預測下雨的咖啡廳…」。

    這種分工方式:

    • Needle:做工具決策+參數解析
    • LLM:只在真正需要「說人話」的最後一步出現

    能同時達到:成本可控、延遲更低、邊緣裝置也能預先處理大量決策。


    適合誰現在就試用 Needle?

    • 行動 App 開發者:想做語音指令、快捷操作、離線助手,又不想每次都打雲端 LLM。
    • 硬體產品團隊:智慧手錶、車機、家電、AR 眼鏡,需要一顆小而穩定的本地「工具路由中樞」。
    • 個人自架 Agent 系統玩家:已經有多工具、多 Agent,正在煩惱 orchestration 成本和延遲的人。

    只要你場景的核心在「選工具+填參數」,而不是長篇聊天,Needle 值得你花一個下午跑起 demo,直接把它塞到你的 workflow 裡測一次。更多細節與最新腳本可以在 GitHub 查看:https://github.com/cactus-compute/needle

    🚀 你現在可以做的事

    • 先 clone Needle 專案並跑一次官方 demo:git clone https://github.com/cactus-compute/needle.git
    • 把你現有的 function calling / OpenAPI schema 丟給 Needle,觀察它產生的工具 JSON
    • 在一個實際專案裡,嘗試用 Needle 接在 ASR 和雲端 LLM 之間,實測延遲與成本差異
  • 把 ChatGPT 搬進 iPhone:Gemma 4 實戰

    把 ChatGPT 搬進 iPhone:Gemma 4 實戰

    一句話定位:Gemma 4 讓你在 iPhone 上離線享受「接近 ChatGPT」的體驗,所有資料留在手機裡不出門。

    📌 本文重點

    • 在 iPhone 本地跑 Gemma 4,可離線又保護隱私
    • 用 Gemma 4 做聊天、翻譯、PDF/筆記問答與日記分析
    • 依照步驟完成「PDF/筆記 → 總結 + 問答」 workflow
    • 開發者可在手機上做無後端的 LLM 原型實驗

    下面的內容會帶你搞清楚:為什麼要在手機本地跑 Gemma 4、它能做什麼、適合哪些人用,以及最重要的——怎麼一步步在 iPhone 上跑起來,做到「把 PDF/筆記丟進去就能問答」

    參考:Gemma 4 本地推理在 iPhone 上的討論,可見 Gizmoweek 報導 與 Hacker News 熱門串。


    核心差異:為什麼要在 iPhone 本地跑 Gemma 4?

    先把雲端模型(ChatGPT、Gemini)和本地 Gemma 4 的差異講清楚:

    • 隱私
    • 雲端:你的對話、上傳檔案會經過伺服器。
    • 本地:模型在 iPhone 上推理,日記、醫療筆記、合同草案都不離開手機

    • 離線可用

    • 雲端:沒網路、飛機上、海外被限制時就完全失效。
    • 本地:Gemma 4 可以在飛機、公車、海外出差時照常回覆、翻譯、寫作。

    • 延遲穩定

    • 雲端:高峰期會卡、會 timeout,速度跟網路品質綁死。
    • 本地:只看你 iPhone 效能,體感像打字機,多數短文秒回

    💡 關鍵: 把 Gemma 4 放在 iPhone 本地跑,可以在無網路狀態下,用接近 ChatGPT 的體驗處理高度隱私與長文內容。

    如果你有「這些東西我不想丟到雲端」的內容,或常常沒網路,Gemma 4 在 iPhone 上會立刻變成高頻工具,而不是備胎。


    核心功能:你在 iPhone 上實際能做什麼?

    1. 對話與寫作助手(接近 ChatGPT 體驗)

    在支援本地 LLM 的 App 裡載好 Gemma 4 後,你就能:

    • 像聊天一樣問問題、整理想法
    • 寫 email 草稿、會議摘要、腳本、貼文
    • 讓它用你的語氣重寫文字(例如「幫我改成比較口語」)

    行動建議: 安裝一個本地 LLM App(下面「怎麼開始」會列),先用 Gemma 4 當純文字聊天助手,感受速度與溫度、耗電,再決定要不要開更大的模型。

    2. 本地長文與知識庫分析

    Gemma 4 支援長上下文版本(有社群實測用 26B + 256k context 分析十萬字日記,見 Reddit 分享),放在 iPhone 上就可以做:

    • 整本 PDF 報告丟進去請它重點整理
    • 長期筆記/子彈筆記匯總,問它「幫我找出過去一年我最常抱怨的三件事」
    • 針對整個專案文件問答(而不是只看一頁)

    💡 關鍵: 長上下文的 Gemma 4 能處理十萬字等級的內容,適合把整本報告或多年日記一次交給手機上的模型分析。

    行動建議: 準備 1–2 份你真正在看的 PDF(研究報告、投影片),等下在 workflow 範例中會用到。

    3. 手機端開發實驗(快捷指令 + 簡單 App)

    對開發者或自動化玩家,Gemma 4 在 iPhone 上的價值在於:

    • 不用伺服器,就能在手機上測試 LLM 原型
    • 用 iOS 快捷指令 + 本地 LLM App 做簡單 Agent:
    • 選取文字 → 呼叫 Gemma 4 重新整理/翻譯
    • Share Sheet 把檔案丟給 Gemma 4 總結
    • 若走原生路線,可用 Core ML / Metal 把轉好的 Gemma 4 模型 embed 到 Xcode 專案裡

    行動建議: 如果你是 iOS 開發者,先用現成 App 測試好 prompt 與模型尺寸,再考慮用 Core ML 導入;這樣可以避免一開始就卡在部署。相關量化思路可對照 Google 在 Apple Silicon 上的 TurboQuant 技術介紹(參考 Towards AI 文章)。


    適合誰用?三個典型場景

    1)個人知識庫與日記:所有東西都留在手機

    適合這些人:

    • 有多年日記、心理諮商紀錄、醫療紀錄
    • 研究生、創作者,有大量私人筆記
    • 對雲端隱私完全不放心

    可以做的事:

    • 把日記匯出成純文字 / Markdown,分段丟給 Gemma 4:
    • 「找出我反覆提到但沒有行動的目標」
    • 「整理這一年,我對工作的情緒變化」
    • 對敏感筆記做聚合搜尋與摘要,不經過任何第三方伺服器。

    立即行動: 先在 iPhone 裡整理一個「私人 LLM 資料夾」,放日記匯出檔、健康紀錄,後面 workflow 直接用這個資料夾測試。

    2)出差 / 通勤沒網路的翻譯與寫作

    適合這些人:

    • 常飛機、常坐高鐵/地鐵、跨國出差
    • 在國外有網路限制,雲端 AI 不穩

    可以做的事:

    • 把待回的英文信貼進去:「幫我寫一封比較禮貌但堅決的英文回覆」
    • 開會前在車上,用 Gemma 4 把簡報講稿縮短成 5 個 bullet
    • 旅行時拍照 + OCR 轉文字後,丟給 Gemma 4 做即時翻譯與說明

    立即行動: 下次搭車前,把常用的翻譯/寫作 prompt 存成備忘錄,沒網路時直接複製給 Gemma 4 用。

    3)開發者在手機上做原型與小工具實驗

    適合這些人:

    • iOS 工程師、快捷指令玩家
    • 想做「不需要後端」的 AI 小工具

    可以做的事:

    • 寫一個快捷指令:
    • 取得目前剪貼簿文字
    • 傳給本地 Gemma 4 App
    • 回傳整理後文字,直接覆蓋剪貼簿
    • 在 Xcode 專案中,用 Core ML 模型當 offline 助手(例如:程式碼註解生成、App 內 FAQ 問答)

    立即行動: 先在本地 LLM App 裡找到「URL Scheme / x-callback-url」或「Shortcut 支援」,確認能否被快捷指令呼叫,這會是你所有原型的入口。


    怎麼開始:在 iPhone 上跑 Gemma 4 的最短路徑

    先給一個工具選擇對照表(以 2026 年常見方案為例,實際名稱請依 App Store 為準):

    名稱(示例) 核心功能 免費方案 適合誰
    LM Studio Mobile 下載並在本地跑 LLM(含 Gemma 4)、聊天介面、檔案上傳 常見為免費 + 內購 想要「裝好就能用」的一般使用者
    MlcChat for iOS 基於 MLX / MLC 的高效本地推理,支援多模型 通常開源、免費 想試不同模型、在意性能的玩家
    自建 Core ML App 直接在 App 內嵌 Gemma 4 Core ML 模型 自行開發 iOS 開發者,要做產品原型

    實際請搜尋「local LLM」「offline AI」關鍵字,並確認是否支援 Gemma 4 款式或通用 GGUF / MLC 格式。

    步驟 1:選一個 App + 安裝

    1. 打開 App Store,搜尋:local LLMoffline AIMLC Chat 等關鍵字。
    2. 看描述裡有沒有提到 Gemma 4 或「自訂模型 / GGUF / MLC」支援。
    3. 安裝後確認:
    4. 是否有「下載模型」功能
    5. 是否支援「匯入檔案」或「knowledge base / documents」

    步驟 2:選擇合適尺寸的 Gemma 4 模型

    iPhone 上不要一開始就上最大顆,會太熱又太慢。可依照:

    • 中階機種(A15 / A16、基本容量)
    • 建議:Gemma 4 2B–4B 量化模型(例如 Q4 / Q5
    • 用途:聊天、筆記整理、短文翻譯

    • 高階 Pro / Max(A18 Pro 類級別,RAM 8GB+)

    • 建議:Gemma 4 9B 左右的量化模型,若 App 支援可試長上下文版本
    • 用途:較長文章摘要、本地知識庫問答

    行動建議: 先下載一個 2B–4B 模型,跑幾分鐘聊天測試溫度。如果手機發燙明顯,就把 thread 數調低或換更小模型。

    步驟 3:測試性能、溫度與耗電

    1. 開啟 App,載入 Gemma 4 模型。
    2. 問它一個中等長度 prompt,例如:

    「請用條列整理 Netflix 訂閱變貴時,使用者常見的三種反應,控制在 200 字內。」

    1. 觀察:
    2. 生成 200 字大約需要幾秒?
    3. 手機背面溫度明顯變熱嗎?
    4. 連續用 10 分鐘後,電量大約掉多少?

    5. 在 App 設定中調整:

    6. 推理 thread(有時稱為「CPU 核心數」「推理執行緒」)
    7. 最大輸出 token 數(不必要就別一次開超大)

    目標狀態

    • 你可以連續聊 10–15 分鐘,手機只是微熱,耗電還在可接受範圍。

    步驟 4:實戰 Workflow —— 把 PDF/筆記丟給 Gemma 4 做總結與問答

    示範一個你可以直接照做的流程:

    1. 準備檔案
    2. 在檔案 App 建一個資料夾:LLM-Inbox
    3. 把一份 PDF(例如 20–30 頁的報告)或匯出的日記 .txt 放進去。

    4. 在 App 裡建立「知識庫」或上傳文件

    5. 打開你的本地 LLM App,找到「Documents / Knowledge / Files」等選項。
    6. 選擇 LLM-Inbox 裡那個檔案上傳或索引。

    7. 設定一個專門對話空間

    8. 新建一個對話,命名成「某某報告 Q&A」。
    9. 在 system prompt(如果有)寫上:

      「你只能根據我上傳的文件回答問題,不要憑空猜測。回答用繁體中文。」

    10. 實際問問題

    11. 「請用 300 字總結這份報告的主要結論。」
    12. 「作者提出的三個建議是什麼?幫我用自己的話改寫。」
    13. 「如果我要做 5 分鐘簡報,應該只挑哪三個 key slide?」

    14. 優化體驗

    15. 如果覺得速度太慢:
      • 換更小的 Gemma 4 模型
      • 限制回答字數,例如「控制在 150 字內」
    16. 如果回答常飄走:
      • 再加一句規則:「如果文件沒有提到,就回答『文件未提及』。」

    完成這個 workflow 後,你就已經不是「玩玩看」而是把 Gemma 4 變成日常讀書 / 工作輔助工具。接下來才是微調 prompt、換更大模型或試試手機端原型開發。

    💡 關鍵: 只要先打通「PDF/筆記 → 總結 + 問答」,Gemma 4 就能穩定接手你日常的讀書、報告與資料整理工作。


    總結:先把一件小事做通,再考慮玩更大

    在 iPhone 本地跑 Gemma 4,不需要一次搞懂所有量化格式、Core ML 細節。建議你照這個順序:

    1. 找一個支援本地模型的 iOS App
    2. 下 1 個中等大小的 Gemma 4 模型
    3. 完成「PDF/筆記 → 總結 + 問答」這個 workflow
    4. 覺得穩定好用,再往日記分析、快捷指令、自建 App 擴展

    做到第 3 步,你就已經把「接近 ChatGPT 的體驗搬進 iPhone,而且可離線」真正落地了。

    🚀 你現在可以做的事

    • 打開 App Store 搜尋「local LLM / offline AI」,安裝一個支援 Gemma 4 或 GGUF 的 App
    • 準備一個 LLM-Inbox 資料夾,把一份 PDF 或日記 .txt 放進去,按文中步驟跑完一次總結 + 問答
    • 觀察 10–15 分鐘使用時的速度與溫度,調整模型大小與 thread 設定,找出最適合你 iPhone 的組合