標籤: llama.cpp

  • 讓電腦自己看螢幕幹活的小工具

    讓電腦自己看螢幕幹活的小工具

    📌 本文重點

    • 開源工具可把螢幕變成「可程式化」工作桌
    • 支援本機 LLM 與瀏覽器 LLM,兼顧隱私與便利
    • 透過 GUI 預設規則,非工程師也能自動化桌面任務
    • 可搭配 Webhook、雲端 LLM 打造微型 agent 工作流

    只要先把規則設好,這個開源小工具就能在背景「看著」你的螢幕,等畫面出現特定文字或按鈕,就自動幫你通知、截圖、點擊甚至重啟程式。

    工具原帖(作者自述):r/LocalLLaMA 原文連結


    核心功能:把螢幕變成一張「可程式化」的工作桌

    1. Observer MCP:一個控制台管理多個觀察任務

    這個工具的核心是一個叫 Observer MCP 的控制器,可以同時管理多個「觀察任務」(micro-agents)。

    你可以做的事:

    • 任務 A:監看模擬器視窗,畫面出現「Not Responding」就自動
    • 截圖
    • 關閉程式
    • 重新啟動模擬器
    • 任務 B:盯住下載器介面,偵測到「Download complete」就
    • 彈桌面通知
    • 或發一個 Webhook 給你自己的 Telegram/Slack bot
    • 任務 C:每天早上 9 點打開 BI 報表,如果畫面中出現「error」「failed」字樣
    • 立即截圖
    • 寄信給負責人

    操作邏輯很像「IFTTT 版的螢幕監控」:

    • IF 螢幕上出現某段文字 / 某個按鈕
    • THEN 執行通知、按鍵、滑鼠、呼叫 API、丟給其他 CLI 工具

    你可以在工具內的 GUI 列出多個任務,分別開關,不需要改程式碼,只要改設定。


    2. 本機 LLM + 瀏覽器 LLM:llama.cpp + transformers.js

    這個工具內建兩種推理引擎,讓你可以選擇 AI 要跑在哪裡。

    • llama.cpp 模式:
    • 在你的電腦本機跑 LLM
    • 適合已經有 GPU 或願意下載模型的人
    • 好處:完全離線、資料不出機器,適合隱私敏感場景

    💡 關鍵: 使用 llama.cpp 本機模式時,所有資料都留在自己的電腦裡,特別適合處理敏感畫面與內部數據。

    • transformers.js + WebGPU 模式(跑在瀏覽器):
    • 利用瀏覽器的 WebGPU,在前端執行模型
    • 不需要架後端,也不必裝一堆依賴
    • 搭配 Hugging Face 開源的高速 WebGPU kernels,可以在 Chrome/Edge 之類的瀏覽器上流暢運作

    你可以這樣配置:

    • 輕量任務(純文字判斷、簡單判讀畫面):用瀏覽器版 LLM,完全零部署
    • 重度任務(複雜畫面理解、長報表分析):切換成本機 llama.cpp 模式

    實際操作動作:

    1. 在設定頁選擇 Local LLM 或 Browser LLM
    2. 如果選 Local LLM,指定你的 GGUF 模型路徑(例如從 Hugging Face 下好的模型)
    3. 如果選 Browser LLM,只要開對應的 Web UI,直接在瀏覽器跑

    3. 預設規則 + 簡單 GUI:不會寫程式也能配置

    作者在 v3.0.0 的重點,就是讓「他媽媽也會用」。

    工具提供:

    • 預設規則模板(例如「偵測錯誤字樣」「下載完成通知」「程式崩潰自動重啟」)
    • 圖形介面 GUI:
    • 下拉選單選「要看哪個視窗」
    • 文本欄位填「要找的關鍵字」
    • 再選「觸發後要做什麼動作」

    你可以這樣設定第一個規則:

    1. 打開工具 > 新增任務
    2. 選擇「觀察區域」:整個螢幕,或某個應用程式視窗
    3. 在「條件」輸入關鍵字,例如 error 或 download complete
    4. 在「動作」選擇:彈出桌面通知 + 播放提示音
    5. 儲存後按「啟動」

    從這一刻開始,電腦就會在背景幫你盯畫面,只要滿足條件,就幫你處理重複的提醒工作。


    適合誰用:三種典型場景

    1. 辦公桌面自動化:BI 報表 / 下載器 / 排程任務

    如果你工作中常遇到:

    • 要盯 BI 報表更新,一有錯誤就要截圖回報
    • 等大型檔案下載完成才能進下一步
    • 排程報表生成,有時悄悄失敗沒人發現

    你可以這樣做:

    • 建一個任務專門看 BI 報表頁面
    • 條件:畫面包含 Error / Failed / Timeout
    • 動作:截圖 + 寄 Email 給團隊
    • 再建一個任務盯住下載器視窗
    • 條件:出現 100% 或 Download complete
    • 動作:桌面通知 + 呼叫你的 CLI 腳本開始後續處理

    💡 關鍵: 透過關鍵字條件搭配自動通知與截圖,可以避免「排程失敗卻沒人發現」的情況默默發生。

    2. 遊戲 / 模擬實驗監控

    對玩家或研究員:

    • 模擬器長時間跑實驗,一掛掉就浪費幾個小時
    • 練功、排隊、排程任務,需要特定事件時才回來動手

    可設定:

    • 任務:觀察模擬器畫面
    • 條件:出現 Not responding 或畫面變黑
    • 動作:
      • 截圖留證
      • 關閉程式
      • 再重新啟動模擬器
      • 發 Telegram / Slack 通知你

    3. 重視隱私,又不想把畫面丟雲端的人

    如果你在處理:

    • 內部財務報表
    • 客戶名單
    • 研究實驗數據

    又希望 AI 幫忙看畫面,但不想傳到雲端:

    • 開啟 Local LLM(llama.cpp) 模式
    • 所有畫面截圖、文字解析都在你的電腦裡完成
    • 即使你用 WebGUI 管理,也只是本機 Web 介面,資料不會被上傳

    怎麼開始:最快上手路線

    注意:原始專案為開源,實際專案名稱 / 下載方式請以作者 GitHub 為準。以下是一條通用、接地氣的上手流程。

    步驟 1:從 GitHub 下載與安裝

    1. 打開作者提供的 GitHub 連結(可從 Reddit 原文找到):
    2. r/LocalLLaMA 貼文
    3. 在 GitHub 右側 Release 區塊,下載
    4. Windows:*.exe 或 *.msi
    5. macOS:*.dmg
    6. 安裝後啟動程式

    首次啟動時通常會:

    • 要求螢幕錄影權限(macOS)或類似權限(Windows)
    • 這是為了截圖與讀取畫面內容

    步驟 2:只用瀏覽器版的「零部署」玩法

    如果你不想先搞本地模型,建議先用 瀏覽器版 LLM。

    1. 在工具設定裡選擇 Browser / Web LLM 模式
    2. 工具會指示你打開一個本機 Web UI(例如 http://localhost:xxxx)
    3. 確保你的瀏覽器支援 WebGPU(最新版 Chrome / Edge 通常可以)

    這種玩法的好處:

    • 不用裝 CUDA、不用拉模型
    • 先體驗「螢幕被 AI 盯著」的感覺
    • 確認需求後,再決定要不要搬到本地 LLM

    步驟 3:建立你的第一個觀察規則(關鍵字通知)

    目標:只要畫面出現某關鍵字,立刻彈出通知。

    操作示範:

    1. 在工具主畫面點 New Task 或「新增任務」
    2. 名稱:BI 報表錯誤偵測
    3. 觀察來源:選擇
    4. 目標應用程式視窗(例如 Chrome 中某個 tab)
    5. 或整個螢幕
    6. 條件設定:
    7. 模式:關鍵字比對
    8. 關鍵字:Error, Fail, Timeout(可多個)
    9. 動作設定:
    10. 桌面通知+提示音
    11. 按「儲存」並「啟動」任務

    接著打開你的 BI 報表頁,試著手動製造一個錯誤(或用假資料),確認工具會彈通知。


    步驟 4:接 Slack / Email Webhook,變成小工作流

    當你熟悉基本規則後,可以往「微型工作流」走。

    1. 在工具中新增一個動作類型:
    2. HTTP Webhook
    3. 填入你的 Slack Incoming Webhook URL 或自架的 Webhook endpoint
    4. 設定內容:
    5. 傳送 JSON 包含:任務名稱、觸發時間、螢幕截圖連結(如存到本機再由你自己的服務處理)

    範例工作流:

    • BI 報表錯誤 → 工具截圖 + 呼叫 Slack Webhook → 團隊頻道收到「報表錯誤 + 圖片」
    • 模擬器當機 → 工具重啟程式 + 呼叫 Email 發送服務 → 你手機立刻收通知

    如果你熟 CLI 工具,可以再加一層:

    • 工具觸發時執行某個 shell script
    • Script 裡再呼叫 curl、ffmpeg、python 等,組成一條完整 pipeline

    💡 關鍵: 透過 Webhook 或 shell script,這個螢幕監控工具可以無縫接到你原本的自動化腳本與團隊通知渠道。


    和雲端 LLM 混搭:把它當成練習用的「微型 agent」場

    雖然這個工具主打本地與瀏覽器 LLM,但你也可以:

    • 在設定裡新增 OpenAI / Claude API key
    • 把「畫面描述」或 OCR 結果,丟給雲端 LLM 做更複雜判斷

    例如:

    • 本地 LLM 負責:
    • 每幾秒截圖 + 基本文字偵測
    • 雲端 LLM 負責:
    • 分析整份畫面內容(例如圖表、表格)
    • 決定要不要通知你,或要不要執行下一步

    這樣的搭配好處:

    • 你可以在一個「單機環境」裡,練習設計 agent workflow
    • 之後要搬到更大規模的多 agent 系統(如企業自動化平台),概念是相通的

    建議學習路線:

    1. 先用預設 GUI + 本地 LLM 完成 2–3 個任務
    2. 再加上 Webhook,試一次和 Slack / Email 整合
    3. 最後才接 OpenAI / Claude,看整條流程能否穩定跑通

    這樣,你就多了一個很實際的「AI 工作桌」,幫你把螢幕上的重複瑣事自動化。


    🚀 你現在可以做的事

    • 前往 r/LocalLLaMA 原文 找到作者 GitHub 連結並下載專案
    • 安裝後建立一個簡單任務,例如監控 BI 報表錯誤並彈出桌面通知
    • 設定一個 HTTP Webhook,把觸發事件發到你的 Slack 或 Email,實際跑通一條小型工作流
  • 用本地開源 AI 控制你的 Mac

    用本地開源 AI 控制你的 Mac

    📌 本文重點

    • 本地視覺模型可當 macOS 半自動操作助理
    • 優先選支援 GGUF 的 4B–7B 模型在 Mac 上運行
    • 先讓模型說步驟,再逐步接上自動點擊工作流

    只要把「看得懂畫面」的開源 AI 模型裝在 Mac 上,你就能讓它幫你看截圖、找按鈕、決定滑鼠要點哪裡,變成半自動的 macOS 操作助理。


    核心功能:這類模型到底能做什麼?

    以下說的「模型」,指的是可以本地跑、支援視覺輸入的開源模型,本文主要參考 Towards AI 的實測:用 136 張真實 macOS 截圖,看每個模型會「點哪裡」。原文連結在此:https://pub.towardsai.net/5-best-local-open-source-models-that-can-control-your-mac-in-2026-61b4a1e4600c

    💡 關鍵: 用 136 張真實 macOS 截圖實測,代表這些模型真的能理解日常桌面操作場景

    這類模型的三個關鍵能力:

    1. 看截圖、理解介面元素
    2. 看一張 macOS 螢幕截圖,辨識「按鈕、選單、側邊欄、分頁」等。
    3. 實際用法:每次你截圖目前畫面,把圖丟給模型,問它「我要開 Wi-Fi 設定,下一步要點哪裡?」。

    4. 用文字描述操作步驟

    5. 模型會用文字回答:「先點右上角 Apple 圖示,再選『系統設定』,然後在側邊欄點『Wi-Fi』」。
    6. 你可以把這些回答,接到自動化工具(AppleScript、Keyboard Maestro、Shortcuts)變成真正的點擊。

    7. 預測滑鼠點擊位置

    8. 在 Towards AI 實測中,每個模型都要對截圖輸出一個「要點的座標」。
    9. 你可以用這個座標,讓腳本自動移動滑鼠並點擊,完成半自動操作。

    表現最好的 5 款本地開源模型

    以下是從原文與目前本地部署生態綜合整理出的 5 款代表模型,重點是:都能在 Mac 本地跑、支援視覺輸入,適合做「螢幕助手」。

    提醒:各模型的具體版本與分數以原文與官方 repo 為準,這裡重點放在「怎麼選」與「怎麼用」。

    名稱 核心功能 免費方案 適合誰
    LLaVA / LLaVA-NeXT 經典開源視覺語言模型,理解 UI 元素佳,社群資源多 完全開源,可下載 GGUF 量化版 想要穩定、教學資源多的入門使用者
    Qwen-VL (含量化版) 多語系、對中文 UI 說明友善,與 Hugging Face / llama.cpp 整合度高 開源,可用 GGUF 量化在 Mac 上跑 需要中文介面說明、希望在 M 系列 Mac 上效能更好的人
    InternVL / MiniCPM-V 更偏「感知」類任務,對複雜畫面理解細節不錯 開源,多種大小模型可選 做進階 UI 分析、需要在自家產品整合的人
    Phi-3-Vision 類小模型 參數較小、資源占用低,適合輕度自動化 開源,有多種量化方案 只有 8GB–16GB RAM 的 Mac,想跑得動就好
    Gemma Vision / 類似視覺版小模型 Google 系列、偏向乾淨 UI 理解與指令跟隨 開源,有社群提供 GGUF 想接未來更多 Google 生態,做客製化工作流的使用者

    💡 關鍵: 這 5 類模型的共通點是都能在 Mac 本地跑、支援視覺輸入,非常適合做桌面「螢幕助手」


    模型差異:隱私、本地運行、資源占用

    1. 隱私
    2. 上述模型若以 GGUF / llama.cpp 在本地跑,截圖不會上雲端,非常適合有敏感資料的公司與工作機。
    3. 行動:如果你在意隱私,優先選「完全在本地推理」的方案,不要接雲端 API。

    4. 本地運行便利度

    5. LLaVA、Qwen-VL 等都有 Hugging Face Hub 上的 GGUF 模型,可以搭配 transformers 或 llama.cpp。
    6. Hugging Face 官方已支援 GGUF 原生載入(參考:https://huggingface.co/blog/transformers-llama-cpp-quants、Reddit 討論:https://www.reddit.com/r/LocalLLaMA/comments/1wnxm0r/ggufs_in_transformers_natively/)。
    7. 行動:選一個有 GGUF 的模型,優先跟 Hugging Face / llama.cpp 生態走,安裝流程最簡單。

    8. 資源占用

    9. 4B–7B 參數的量化模型,一般 M1 / M2 MacBook(16GB RAM)就能跑。
    10. 超過 13B 會明顯變慢,占用也大,不建議拿來做即時操作助理。
    11. 行動:先從 4B–7B 規模的 Qwen-VL 或 LLaVA GGUF 開始測試,確認速度再升級。

    💡 關鍵: 4B–7B 量化模型是在一般 16GB Mac 上兼顧可用速度與效果的甜蜜點


    適合誰用:3 個具體場景

    1. 懶得自己點、但不想寫複雜腳本的人
    2. 需求:常整理檔案、開特定設定、做重複的 GUI 操作,但不熟 AppleScript。
    3. 做法:用模型看截圖,讓它用自然語言說「下一步要點哪裡」,再把這些指令手動轉成 Shortcuts 或 Keyboard Maestro 流程。

    4. 需要半自動「教學 + 操作」的 IT / 內部支援

    5. 需求:公司裡常有人問「怎麼開 VPN、怎麼設定印表機」,而且每台 Mac 介面略有不同。
    6. 做法:讓模型看使用者截圖,輸出文字步驟與點擊位置,再用腳本執行或回覆說明。

    7. 想做自己的「桌面代理人」的開發者 / Maker

    8. 需求:做一個類似「螢幕助手」的小工具,幫你點按、排程例行操作。
    9. 做法:把視覺模型接到一個簡單 Python / Swift 程式,讓它每 X 秒讀取截圖,決定下一個點擊座標,交給自動化腳本執行。

    怎麼開始:在普通 Mac 上裝一個模型 + 建第一個 workflow

    下面用 Qwen-VL GGUF + llama.cpp 當例子,示範最短上手路徑。你可以換成 LLaVA 或其他支援 GGUF 的視覺模型,流程類似。


    步驟 1:安裝基本環境

    1. 安裝 Homebrew(若已安裝可跳過)
      打開 Terminal:
      bash
      /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

    2. 安裝必備工具
      bash
      brew install cmake git python


    步驟 2:下載並編譯 llama.cpp

    1. 取得原始碼
      bash
      git clone https://github.com/ggerganov/llama.cpp.git
      cd llama.cpp

    2. 編譯(針對 Apple Silicon 優化)
      bash
      mkdir build && cd build
      cmake .. -DLLAMA_METAL=ON
      cmake --build . --config Release

    行動:這段只需要跑一次,之後都重用同一份 llama.cpp。


    步驟 3:從 Hugging Face 抓一個 GGUF 視覺模型

    1. 選模型
      打開 Hugging Face,搜尋類似:
    2. Qwen-VL-GGUF
    3. 或 llava-v1.5-7b-GGUF 等具備視覺能力、標明 GGUF 格式的模型。

    4. 使用 huggingface-cli 下載
      安裝與登入:
      bash
      pip install -U "huggingface_hub[cli]"
      huggingface-cli login

    下載模型檔(以示意 ID 代替,請換成實際模型):
    bash
    huggingface-cli download myorg/Qwen-VL-4B-GGUF \
    Qwen-VL-4B-Q4_K_M.gguf \
    --local-dir ./models/qwen-vl-4b

    行動:確保你選的是 Q4 / Q5 之類量化版本,體積較小,適合一般 Mac。


    步驟 4:寫一個最簡單的「看截圖 → 建議下一步」腳本

    下面用 Python 示意:

    import subprocess
    import os
    from datetime import datetime
    
    LLAMA_BIN = "./build/bin/llama-cli"  # 依照你編譯出的檔名調整
    MODEL_PATH = "./models/qwen-vl-4b/Qwen-VL-4B-Q4_K_M.gguf"
    
    SCREENSHOT_DIR = "./screenshots"
    os.makedirs(SCREENSHOT_DIR, exist_ok=True)
    
    # 1. 截圖目前螢幕
    filename = datetime.now().strftime("%Y%m%d-%H%M%S.png")
    filepath = os.path.join(SCREENSHOT_DIR, filename)
    subprocess.run(["screencapture", "-x", filepath])
    
    # 2. 準備提示詞(prompt)
    prompt = (
        "你現在看到的是一張 macOS 截圖。\n"
        "目標:幫我打開『系統設定』裡的『Wi-Fi』頁面。\n"
        "請回答:\n"
        "1)下一步滑鼠應該點哪個按鈕或選單?\n"
        "2)用簡短步驟列出接下來 3 步操作。\n"
    )
    
    # 3. 呼叫模型(llama.cpp 需支援 image + text 模式,參考各模型說明)
    result = subprocess.run([
        LLAMA_BIN,
        "-m", MODEL_PATH,
        "--image", filepath,
        "-p", prompt,
        "-n", "256"  # 最多生成 256 token
    ], capture_output=True, text=True)
    
    print("模型回答:")
    print(result.stdout)
    

    這個腳本會:

    • 自動抓一張當前螢幕截圖。
    • 把截圖 + 指令丟給模型,請它說明下一步要點哪裡。
    • 在 Terminal 印出回答,你可以照做,或下一步再把回答解析成座標、接上自動點擊腳本。

    行動:先讓模型說對步驟,確認理解 UI 沒問題,再往「自動點擊」邁進。


    步驟 5:接上「自動幫你點」的小 workflow

    等你確認模型給的步驟足夠穩定,可再疊以下工具:

    1. 用 AppleScript / Swift 控制滑鼠
    2. 例如用 Swift / Objective-C 的 CGEvent API,或第三方 CLI 工具移動滑鼠到指定座標並點擊。

    3. 用 Keyboard Maestro / Shortcuts 固定流程

    4. 把「截圖 → 丟給模型 → 執行步驟」包成一條快捷鍵,變成半自動助手。

    5. 安全性設定

    6. 建議只在自己的機器上跑,而且限制模型只能在特定 App(設定、Finder)執行點擊,避免誤操作重要軟體。

    最後整理:怎麼選、怎麼跑

    • 如果你完全新手:從 LLaVA 或 Qwen-VL 的 GGUF 小模型開始,照本文步驟裝 llama.cpp,先讓它「說步驟」。
    • 如果你是開發者:善用 Hugging Face 對 GGUF 的原生支援,在 transformers 中直接載入量化模型,接自己熟悉的 Python 工具鏈。
    • 如果你只有一般 MacBook:優先選 4B–7B 量化模型,避免模型過大導致卡頓;確認隱私需求後,再考慮是否要加上雲端模型輔助。

    只要先搭出第一個「幫我打開系統設定 → Wi-Fi」的小 workflow,你就有了自己的雛形桌面代理人,之後就能一步步擴充,讓 Mac 越來越懂得自己操作自己。

    🚀 你現在可以做的事

    • 到 Hugging Face 搜尋並下載一個 Qwen-VL 或 LLaVA 的 GGUF 量化模型
    • 依照文中步驟安裝 llama.cpp,跑通第一個「看截圖 → 說步驟」的 Python 腳本
    • 選擇 Keyboard Maestro 或 Shortcuts,把這個腳本包成快捷鍵,開始實驗你的第一個螢幕助手 workflow
  • 把家裡電腦變 AI 叢集:用 PAIR 就夠

    把家裡電腦變 AI 叢集:用 PAIR 就夠

    📌 本文重點

    • PAIR 把多台有 GPU 的電腦整合成一個本地 AI 叢集
    • 它負責自動分配推理任務、接管多代理與多模型流量
    • 不替代 LLM,只當「中間層」接上你現有的本地 AI workflow

    只要安裝一個軟體,Nvidia PAIR 就能把你家裡所有有 GPU 的電腦串成一個「個人 AI 叢集」,解決多機多 GPU 閒置、管理混亂的問題。

    工具官網與原始碼:
    官方介紹:https://www.nvidia.com/en-us/ai-on-rtx/personal-ai-router/
    GitHub:https://github.com/NVIDIA/Personal-AI-Router


    核心功能:PAIR 到底幫你做了什麼?

    1. 自動發現家裡可用設備

    PAIR 不是硬體路由器,而是一個在局域網裡跑的「AI 控制中心」。安裝後,它會自動掃描家裡網路裡支援的設備,像是:

    • 有 Nvidia RTX 20 系列以上 GPU 的 Windows / Linux 電腦
    • 新款 Mac(例如 M4 之後,依官方更新為準)
    • 之後可能會支援更多邊緣裝置(依官方版本)

    你可以立刻做的事:

    1. 列出你家裡有 GPU 的電腦,確認網路都在同一子網(同一 Wi-Fi / 有線路由器)。
    2. 在「主控機」(你平常用的桌機或筆電)裝 PAIR,讓它掃描網路上的其他設備。

    延伸閱讀:The Verge 對 PAIR 的介紹
    https://www.theverge.com/ai-artificial-intelligence/989435/nvidia-pair-personal-ai-router-home-local-llm-compute-tool-rtx-macbook

    💡 關鍵: 只要滿足「同一局域網 + 具備支援 GPU」,這些原本零散的設備就能被 PAIR 自動收編成一個共享算力池。

    2. 把推理任務分配到多台機器、多人多代理一起跑

    PAIR 的核心就是「分配推理任務」。當你用本地 LLM(例如 Ollama、LM Studio、vLLM)跑聊天或批量推理時:

    • 每個請求會先進到 PAIR
    • PAIR 會看哪台機器目前最空、哪張 GPU 最適合
    • 再把對話或任務分出去,並收回結果

    這在多代理(multi-agent)場景特別有用:

    • 例如一個「研究代理」去查資料、一個「寫作代理」整理、一個「翻譯代理」輸出
    • 過去全塞在一台機器,有 GPU 也常堵車
    • 現在可以由 PAIR 把三個代理丟到三台不同主機並行跑

    你可以立刻做的事:

    • 把你現在在用的本地 LLM 工具(如 Ollama)改成透過 PAIR 的端點呼叫,測一次同時間多對話的速度差異。

    3. 和本地 LLM 工具接起來:成為你家裡的「AI 交換器」

    PAIR 本身不提供模型,它是把現有的 LLM 推理服務串起來:

    常見搭配方式:

    • vLLM / TensorRT-LLM:在幾台有強 GPU 的主機上跑高速推理,再由 PAIR 統一入口
    • llama.cpp:在比較舊或低功耗的機器跑輕量模型,當作「輔助節點」
    • Ollama / LM Studio:做模型管理與介面,實際請求轉給 PAIR,再由 PAIR 分流到後端伺服器

    你可以立刻做的事:

    • 選一款你已經熟悉的本地 LLM 工具(例如 Ollama),把它當作「前端」,再把後端推理改由 PAIR 統一代理,看看多台機器一起工作時的體感差異。

    參考討論:Reddit r/LocalLLaMA 社群對 PAIR 的看法
    https://www.reddit.com/r/LocalLLaMA/comments/1w6chxw/nvidia_pair_seems_nice_for_people_with_multiple/


    適合誰用?三個具體場景

    1. 個人 / 小團隊自架本地聊天助手

    痛點: 你可能已經在家裡或工作室裡堆了好幾台主機、NAS、舊筆電,結果真正有在跑 LLM 的只有一台。

    用 PAIR 可以做到:

    • 把所有有 GPU 的機器都納入算力池
    • 用一個統一的 API / URL 提供聊天服務給團隊
    • 將不同模型部署在不同機器上(例如:一台跑推理、一台跑多模態),由 PAIR 統一入口

    行動建議:

    1. 列出團隊目前可用機器(GPU 型號、記憶體)。
    2. 在其中一台性能最好、網路穩定的機器當 PAIR 主控節點。
    3. 把其他機器都裝上 LLM 推理服務(如 vLLM + 某模型),讓 PAIR 掃描並註冊節點。
    4. 團隊只要記住一個「聊天 API」,背後由你用 PAIR 管理實際跑在哪一台機器。

    💡 關鍵: 對團隊來說只需要「一個 API 入口」,但背後可以是多台機器、多張 GPU 與多個模型動態協作。

    2. 批量推理與模型測試:一次跑多版本

    痛點: 你在做 prompt / 模型選型時,常需要:

    • 同一批輸入測試多個模型
    • 比較 latency 和輸出品質
    • 手動分配到不同機器很煩

    用 PAIR 可以做到:

    • 同一批測試資料一次丟給 PAIR
    • PAIR 自動分配到不同後端(不同模型 / 不同 GPU)並收集結果
    • 你只處理輸出比較,不管機器怎麼分配

    行動建議:

    1. 在不同機器分別部署你想測試的模型(例如 Llama 3.1 8B / 70B / 低參數版)。
    2. 在 PAIR 內設定這些節點標籤(如「高速但昂貴」「輕量但慢」)。
    3. 寫一個簡單的 script,呼叫 PAIR API 分發同一批測試輸入,最後把結果收回做比較。

    3. 家庭智慧設備上的低延遲 AI

    痛點: 智慧家居通常靠雲端:語音助理、家電控制、簡單自動化,但有隱私與延遲問題。

    用 PAIR 可以做到:

    • 讓家裡的主機當「AI 中樞」,其他設備(智慧音箱、樹莓派、自製家居控制)只送小請求
    • 語音指令、情境腳本等都在本地完成解析與推理
    • 不同類型任務(語音轉文字、指令理解、排程生成)分配到不同設備

    行動建議:

    1. 選一台永遠開機的電腦當 PAIR 主控節點(可放書房或機櫃)。
    2. 在家裡其他設備上跑輕量 client,將需要 AI 的部分全部指向 PAIR 的 API。
    3. 測試幾個情境:語音命令整理待辦、家庭排程生成、智慧燈光場景設計,看看本地推理的延遲是否能接受。

    怎麼開始:快速上手路徑

    硬體與環境要求

    先確認你是否具備基本條件:

    • GPU: 至少一台主機有 Nvidia RTX 20 系列以上(越新越好)。
    • 網路: 所有要加入叢集的機器在同一局域網(同一路由器),建議有線連接以降低延遲。
    • 作業系統: 依官方支援,優先選 Windows / Linux + Nvidia 驅動版本符合要求。
    • 本地 LLM: 至少有一套現成部署(如 vLLM、Ollama、llama.cpp),方便測試。

    💡 關鍵: 真正影響體驗的不是只有 GPU 規格,而是「同網段穩定網路 + 正確驅動」這整體環境是否到位。

    安裝與設定重點(含常見坑)

    1. 下載與安裝 PAIR
    2. 到官方頁面或 GitHub 取得最新版本:
      https://www.nvidia.com/en-us/ai-on-rtx/personal-ai-router/
    3. 在你要當「主控」的機器先安裝。

    4. 啟動 PAIR 服務

    5. 啟動後會開一個本地 Web UI / API 端點。
    6. 常見坑:

      • 防火牆阻擋局域網其他主機連入 → 記得開放該 port。
      • 舊版顯示卡驅動造成服務啟動失敗 → 更新 Nvidia 驅動到官方建議版本。
    7. 讓其他主機加入叢集

    8. 在其他有 GPU 的機器,安裝 PAIR client 或依官方指示跑對應 agent。
    9. 確保:

      • 可以 ping 到主控機 IP。
      • 系統時間大致同步(有些分散式系統需要,避免 log 混亂)。
    10. 對接現有 LLM 工具

    以常見工具為例:

    工具名稱 核心功能 免費方案 適合誰
    vLLM 高吞吐量 LLM 推理 開源免費 想在多 GPU 上跑大型模型的開發者
    llama.cpp CPU / 輕量 GPU 上跑量化模型 開源免費 只有中低階硬體、跑輕量助手的個人
    Ollama 簡單模型管理與本地聊天介面 免費 想快速上手多模型、搭配 GUI 的使用者
    LM Studio 桌面版模型管理與聊天 免費+付費版 想要圖形介面與多模型對話的小團隊

    對接方式概念:

    • 在每台主機先把上述工具跑起來(例如:vLLM 提供一個 HTTP 端點)。
    • 在 PAIR 中登記這些端點,標記它們的能力(模型名稱、輸入上限、速度)。
    • 把原本所有應用程式直接打 vLLM / Ollama 的地方,改成打 PAIR 的統一端點。

    • 驗證:用一個簡單請求實測

    • 開一個小 script 或用 Postman / curl:
      • 對 PAIR API 丟一個簡單聊天 prompt
      • 再開多個併發請求,看 log 中是否分配到不同主機
    • 若只看到一台主機在跑,檢查:
      • 其他主機是否成功註冊到 PAIR
      • 標籤或排程策略是否限制了分配

    和你現有的本地 workflow 接在一起

    要讓 PAIR 真正落地,不是重建一套新系統,而是把它當「中間層」:

    • 開發者: 既有的 API server 不用重寫,只要把 LLM 調用改指向 PAIR,把「跑在哪一台機器」交給它處理。
    • 創作者 / 個人使用者: 保留你熟悉的 UI(如 LM Studio / Ollama),在後端加一層 PAIR,享受多機並行的速度提升。
    • 團隊: 用 PAIR 做統一入口,並在內部維護一份「算力拓撲圖」,知道每台機器跑什麼模型、給誰用。

    只要你家裡有兩台以上有 GPU 的電腦,PAIR 值得你花一個晚上來試:先把它架起來,讓日常所有本地 AI 用量都走 PAIR,再看一週後你對「家用算力」的認知會怎麼改變。

    🚀 你現在可以做的事

    • 盤點家中或工作室所有具 GPU 的設備,確認是否在同一局域網並整理出一份清單
    • 在預計作為主控節點的機器上安裝 PAIR,並讓至少一個現有 LLM 服務(如 Ollama 或 vLLM)接到 PAIR 端點
    • 撰寫或修改一個現有小專案,將原本直連模型的呼叫改為經由 PAIR,實測多併發或多代理情境下的效能差異
  • 把舊遊戲卡變成本地 AI 程式助手

    把舊遊戲卡變成本地 AI 程式助手

    📌 本文重點

    • 16GB 顯卡即可本地跑 Qwen 3.8-27B 程式助手
    • llama.cpp + MTP 把長上下文推理速度壓到可用
    • 少數高階指令即可讓 Agent 自動讀 repo、寫 code、跑測試

    用一張 16GB 顯卡,把 Qwen 3.8-27B 跑在自己機器上,變成一個能讀 repo、寫 code、自己跑測試的本地程式助手。


    核心功能:這套組合能幫你做什麼?

    1. 在 16GB 顯卡上跑 27B 長上下文 Agent

    • Qwen 3.8-27B 是阿里開源的大模型,在 Reddit 實測 裡,表現接近商用雲端模型,特別擅長長上下文推理和實務知識。
    • 社群已針對 16GB VRAM 做過完整配置分享,可在 73k context 下跑 agentic coding,單專案可吃超過百萬 token 歷史。參考設定。
    • 透過 GGUF 量化 + cache 量化,搭配 CPU RAM,把 27B 模型擠進「遊戲卡 + 小主機」這種平價組合。

    💡 關鍵: 只要 16GB 顯卡就能在本地處理 73k 以上長上下文,支援單專案百萬 token 歷史。

    你可以做的:
    – 把原本只能打遊戲的 16GB 顯卡,變成一台完全離線的 AI 程式助手。
    – 不依賴雲端,內網就能讓 AI 幫你寫 CLI 工具、重構專案。


    2. llama.cpp v0.1.0 + FastMTP / adaptive MTP:把延遲壓到能用

    • llama.cpp v0.1.0 是穩定版,支援多平台(Windows / Linux / macOS / Apple Silicon),對 GGUF 模型友善。版本連結
    • HauhauCS 的 FastMTP(多 token 預測)在 Qwen 3.8-27B 上可達 3 倍輸出速度提升:模型頁面。
    • llama.cpp 的 adaptive MTP(PR#27210)會依情境自動調整 MTP 深度:簡單部分快出,多步推理時才放慢,代碼生成速度可提升 10–50%。

    💡 關鍵: 結合 FastMTP 與 adaptive MTP,可以把原本「一秒一 token」的體驗提升到實際可用的程式生成速度。

    你可以做的:
    – 在同一台機器上,從「一秒一 token」變成「可以實際用來寫 code」的速度。
    – 不用糾結 MTP 數字,用 adaptive 模式就能有不錯的平衡。


    3. 真正的「Agent」:少數幾個高階提示就能跑完整專案

    • Qwen 3.8-27B 在所謂 medium reasoning 模式下,對「代理式編碼」特別吃香:實測 benchmark 顯示,比 xhigh 模式更省 token、更少請求,完成度相近。
    • 你只要給它幾個高階指令(例如:讀 repo、規劃任務、按計畫實作),讓它自己呼叫 shell/測試,就能完成一個小專案。

    你可以做的:
    – 把它當成「本地版 Cursor Agent」:讓它自己看專案、拆任務、寫程式、跑測試。


    適合誰用?

    • 個人開發者 / 接案工程師:
    • 想用 Qwen 3.8-27B 協助寫後端 / CLI 工具,但又不想每月付雲端費用。
    • 例:在家用 3060 16GB + N100 補一台小主機,做本地私有助手。

    • 公司內部專案:

    • 需要把專案 code、內部文件給 LLM 看,但有資料不出防火牆的限制。
    • 例:在 CI/CD server 上掛一個 Qwen Agent,協助寫腳本、改 pipeline。

    • AI 工具愛好者 / 自架控:

    • 喜歡試不同量化、推理引擎,把效能擠到極限。
    • 例:對比 medium reasoning + adaptive MTP vs xhigh + 固定 MTP 的速度與品質差異。

    工具與環境:一次給你可複製的配置

    1. 必要硬體與系統建議

    最低建議(接近 Reddit 實測環境):

    • GPU:RTX 4060/5060 Ti 16GB,或同級 16GB 顯卡
    • CPU:Intel N100 以上(有 AVX2 更好)
    • RAM:32GB(推薦 48GB+,上下文拉長時更穩)
    • 系統:Ubuntu 22.04 / Windows 11(本文以 Linux 命令為例)

    行動:檢查自己機器:

    nvidia-smi  # 看 VRAM 容量
    free -h     # 看 RAM
    

    2. 模型與 llama.cpp 安裝

    Step 1:抓 llama.cpp v0.1.0

    git clone https://github.com/ggml-org/llama.cpp.git
    cd llama.cpp
    git checkout v0.1.0
    make -j$(nproc)
    

    Step 2:下載 Qwen 3.8-27B GGUF

    建議用 HauhauCS Aggressive + MTP 版本:

    下載範例(用 hf_hub_download 或直接瀏覽器下載):

    mkdir -p models/qwen-3.8-27b
    # 將下載好的 .gguf 放進這個資料夾
    mv ~/Downloads/Qwen3.8-27B-*-Q5_K_M.gguf models/qwen-3.8-27b/
    

    3. 實測好用的啟動指令(16GB VRAM)

    下面是一個可直接用來跑 Agent 的作者實測配置(參考自 1M+ token 實作):

    ./bin/llama-server \
      -m models/qwen-3.8-27b/Qwen3.8-27B-*-Q5_K_M.gguf \
      --ctx-size 73000 \
      --batch-size 512 \
      --n-gpu-layers 45 \
      --gpu-layers-split auto \
      --cache-type-k q8_0 \
      --cache-type-v q8_0 \
      --no-mmap \
      --temp 0.8 \
      --top_p 0.9 \
      --seed 42 \
      --mtl 4 \
      --mtp-adaptive
    

    關鍵說明:

    • --ctx-size 73000:長上下文,適合讀整個 repo。
    • --cache-type-k/v q8_0:cache 量化,換取更大上下文與速度。
    • --mtp-adaptive:啟用 adaptive MTP,自動調整多 token 推理深度。
    • --mtl 4:多執行緒,視 CPU 調整(8 核可用 6–8)。

    行動:啟動後,瀏覽器開 http://localhost:8080,確認模型可以互動,再往下走 Agent Workflow。


    Workflow 示範:讓本地 Qwen 自己寫一個 CLI 工具

    目標:寫一個「掃描專案中 TODO 註解並輸出報表」的 Python CLI 工具,讓 Agent 自己:

    1. 讀 repo
    2. 規劃任務
    3. 分步撰碼
    4. 呼叫 pytest 或自訂測試

    1. 準備一個 repo + agent shell

    假設你的專案在 ~/projects/todo-cli:

    cd ~/projects/todo-cli
    python -m venv .venv
    source .venv/bin/activate
    pip install pytest
    

    準備一個簡單的「Agent shell」腳本(例如 agent_shell.py),透過 HTTP 調用 llama.cpp,並允許它執行有限制的 shell 指令:

    import subprocess, json, requests, os
    
    API_URL = "http://localhost:8080/completion"
    
    ALLOWED_CMDS = ["pytest", "python", "ls", "cat"]
    
    def call_llm(prompt):
        payload = {
            "prompt": prompt,
            "max_tokens": 512,
            "temperature": 0.7
        }
        r = requests.post(API_URL, json=payload)
        return r.json()["content"]
    
    def run_cmd(cmd):
        if cmd.split()[0] not in ALLOWED_CMDS:
            return "[blocked command]"
        return subprocess.run(cmd, shell=True, capture_output=True, text=True).stdout
    
    if __name__ == "__main__":
        while True:
            user = input("You> ")
            if user.strip() == "exit":
                break
            resp = call_llm(user)
            print("Agent>", resp)
    

    行動:確保你能從命令列下指令,讓 Agent 先以「聊天模式」回答,再逐步加上工具使用(shell 執行)。


    2. 用高階提示引導 Qwen 變成程式助手

    示範系統提示(可貼進 Web UI 或 agent_shell 的第一個請求):

    你是一位本地程式助手,目標是在不依賴外網的情況下,完成整個專案開發流程。
    
    能力與規則:
    1. 你可以要求我執行指令,例如:`RUN: pytest`、`RUN: ls`、`RUN: cat filename`。
    2. 每次回答時,如果需要實際操作,請先說明要做什麼,再給出一行 `RUN:` 指令。
    3. 每個階段先列出簡短計畫,再實作。
    4. 對於程式碼修改,請輸出完整檔案內容,而不是差異片段。
    

    接著,使用者只需幾個高階指令:

    1. 讀 repo + 規劃任務

    text
    請先用 `RUN: ls` 和 `RUN: find . -maxdepth 3` 理解專案結構,之後提出一個開發計畫:
    目標是寫一個 `todo_report` CLI,掃描整個 repo 的 TODO 註解,輸出為 JSON 檔。

    1. 實作 CLI

    text
    依照你的計畫,先實作最小可用版本的 `todo_report`,用 Python 實作,並寫對應的 pytest 測試。

    1. 自動測試與修正

    text
    實作完成後,請要求我執行 `RUN: pytest`,你再根據測試結果修正程式。

    你會看到的典型互動流程:

    • 模型要求 RUN: ls、RUN: cat ... → 你在 shell 中照做,把結果貼回給它。
    • 它產生 todo_report.py 完整檔案內容 → 你存檔。
    • 它產生測試檔 → 你存檔,執行 pytest,貼回錯誤訊息。
    • 迭代 2–3 輪,CLI 工具就完成了。

    重點:整個過程你只下了 3–4 個高階指令,其餘由 Agent 自己規劃與修正。


    進階調校:reasoning 模式、量化與「記憶」

    1. medium vs xhigh reasoning:怎麼選?

    根據 agentic coding benchmark:

    • medium reasoning:
    • 得分較高、請求數幾乎減半,生成 token 也少三分之一。
    • 非常適合「多輪小步」的代理任務(寫 code、修測試)。

    • xhigh reasoning:

    • 單次 prompt 的嚴苛推理題可能略好,但耗時、耗 token。

    💡 關鍵: 實測顯示 medium reasoning 在代理式編碼中比 xhigh 更省時、省 token,完成度相近。

    建議:

    • 本地 Agent 預設用 medium。
    • 偶爾需要「一次回答寫完一篇長文或複雜設計」時,再開 xhigh。

    2. 量化與快取:怎麼不犧牲太多品質?

    實用組合(16GB 卡):

    • 權重:Q4_K_M 起跳,追求品質用 Q5_K_M。
    • KV cache:q8_0 或 q6_K,在長上下文時性價比佳。

    調整原則:

    • 若 VRAM 爆掉 → 降權重量化或減 --n-gpu-layers,讓更多層跑在 CPU。
    • 若輸出過慢 → 開 --mtp-adaptive 或固定 --mtp 3,配合 --batch-size 512 以上。

    3. 延伸玩法:簡單「長期記憶」

    你可以加一層「記憶層」,例如:

    • 使用簡單檔案索引:
    • 把重要檔案(設計文件、規格)摘要成短段落,存 JSON。
    • 開發時先用關鍵字搜尋相關摘要,附在 prompt 開頭,讓 Qwen 有「記憶」。

    • 像 ai-memory 那樣記錄對話:

    • 把每次對話中重要決策(例如:架構選擇、命名約定)存到 memory.md。
    • 每次新任務前,把 memory.md 摘要貼給模型。

    行動:先在專案根目錄加一個 ai_memory/,把設計決策和重要檔案摘要集中存放,讓下一次 Agent 啟動時也能延續上下文。


    怎麼開始:一鍵腳本 + 三個可套用 Prompt

    1. 安裝腳本(Linux 範例)

    # 安裝依賴\sudo apt update && sudo apt install -y build-essential git python3-venv
    
    # 取得 llama.cpp v0.1.0
    git clone https://github.com/ggml-org/llama.cpp.git
    cd llama.cpp
    git checkout v0.1.0
    make -j$(nproc)
    
    # 建立模型資料夾
    mkdir -p models/qwen-3.8-27b
    # 將從 Hugging Face 下載的 Qwen3.8-27B GGUF 放入上述資料夾
    
    echo "完成:請下載 GGUF 模型到 models/qwen-3.8-27b,然後執行啟動命令。"
    

    2. 一行啟動命令(可直接複製)

    ./bin/llama-server \
      -m models/qwen-3.8-27b/Qwen3.8-27B-*-Q5_K_M.gguf \
      --ctx-size 73000 --batch-size 512 --n-gpu-layers 45 \
      --cache-type-k q8_0 --cache-type-v q8_0 \
      --temp 0.8 --top_p 0.9 --mtl 4 --mtp-adaptive
    

    3. 三個可直接用的 Agent prompt 範本

    (1) Repo 讀取與理解

    你是一位本地程式助手,目標是理解這個 repo 的結構與目的。
    請:
    1. 用 `RUN:` 指令要求我列出檔案與重要檔案內容。
    2. 整理出專案用途、主要模組、依賴關係。
    3. 最後輸出一段 <SUMMARY> ... </SUMMARY> 作為後續任務的簡要說明。
    

    (2) 新功能開發(CLI 工具)

    根據目前 repo 的內容,規劃並實作一個新 CLI 工具:
    需求:{在此描述}
    步驟:
    1. 先列出開發計畫(檔案變更列表)。
    2. 依序產出完整檔案內容。
    3. 為新功能撰寫至少一個 pytest 測試。
    每個階段如果需要檔案內容或測試結果,請用 `RUN:` 指令要求我執行。
    

    (3) 重構與程式碼審查

    請針對這個模組進行重構,目標:
    - 提升可讀性
    - 避免重複邏輯
    - 保持對外 API 不變
    流程:
    1. 要求我貼上目前檔案內容。
    2. 提出重構建議清單。
    3. 輸出重構後的完整檔案。
    4. 建議或修改對應的測試。
    

    照著這套流程,你今天就能把舊遊戲卡升級成一個能讀 repo、寫 code、自己跑測試的本地 Qwen 3.8 程式助手。


    🚀 你現在可以做的事

    • 在自己的機器上執行 nvidia-smi 和 free -h,確認硬體是否符合 16GB VRAM + 32GB RAM 的建議配置
    • 按文中步驟安裝 llama.cpp v0.1.0,下載 Qwen 3.8-27B GGUF 到 models/qwen-3.8-27b 並用啟動指令跑起來
    • 在一個現有 repo 中建立 agent_shell.py,貼上提供的系統 prompt,實際讓本地 Qwen 幫你完成一個小型 CLI 工具或重構任務
  • 用 Unsloth 把筆電變成小型 AI 伺服器

    用 Unsloth 把筆電變成小型 AI 伺服器

    📌 本文重點

    • Unsloth Desktop 把筆電變成本地多模態 AI 伺服器
    • 支援多 GPU / CPU,並提供 OpenAI 兼容 API
    • 適合本地聊天助理、RAG、Agent 與多模態 Side Project
    • 幾乎不改程式即可把既有 OpenAI workflow 搬到本機

    用一句話定位:Unsloth Desktop 就是把你的筆電變成「小型 AI 伺服器 + 實驗室」的開源桌面工具,讓聊天、程式助理、RAG、影像與語音模型都能在本機跑起來。

    工具來源:
    – Reddit 介紹文:https://www.reddit.com/r/LocalLLaMA/comments/1vlj87v/introducing_unsloth_desktop_app/
    – Product Hunt:https://www.producthunt.com/products/unsloth


    核心功能:把「本地模型」變成可用的服務

    下面三個功能,是你真的會用到、立刻能起手的重點。

    1. 支援多種模型格式:MLX / diffusion / 語音 / GGUF

    Unsloth Desktop 的定位不是「只跑 LLM」,而是一個多模態模型的統一入口:

    • 語言模型:支援 GGUF(llama.cpp 系列)、MLX(Apple Silicon 上的高效框架)
    • 影像 / 視覺:支援 diffusion 影像 / 影片模型
    • 語音:支援音訊模型(語音辨識、TTS 等)

    你可以這樣開始行動:

    1. 安裝好 Unsloth 後,打開模型面板
    2. 選擇一個預設 GGUF LLM(例如 MiniMax-H3、Muse Glimmer)
    3. 選一個簡單的 diffusion 模型(如 Stable Diffusion 系列)
    4. 在同一個介面裡,分別測試文字聊天和影像生成

    這種「同一套操作邏輯管理多模態模型」的好處,是你不用在不同 CLI 工具之間切來切去,對 AI 新手非常友善。


    2. 多 GPU & CPU 加速,本地推理真的跑得動

    很多人「幻想」在筆電上跑模型,卡在效能與顯示記憶體。Unsloth Desktop 的重點是盡量把你手上的硬體吃乾抹淨:

    • 支援多種 GPU:NVIDIA、AMD、Intel、Mac(含 Apple Silicon)
    • 支援 CPU 推理:沒有獨顯也可以跑,只是速度會慢一些
    • 對訓練 / 微調:標榜約 2 倍訓練速度、70% VRAM 節省(來源:官方 Reddit 介紹)

    💡 關鍵: 大約 2 倍訓練速度與 70% VRAM 節省,代表同樣硬體上能跑更大模型或更多實驗。

    你可以立刻做的事:

    1. 在設定頁面確認硬體偵測到的 GPU / CPU
    2. 選一個中型模型(例如 7B gguf),先跑一次聊天測試
    3. 觀察系統資源使用(macOS 的活動監視器、Windows 的工作管理員),確認真的有用到 GPU

    如果你是 Mac 使用者,可以搭配像這篇關於 Apple Silicon + llama.cpp 的效能優化思路:https://github.com/trycua/cua/blob/main/blog/gpu-passthrough-macos-vms.md,來理解「為什麼在 M 系列晶片上跑本地 LLM 是可行的」。


    3. OpenAI 兼容 API + 自我修復工具呼叫

    Unsloth Desktop 最關鍵的功能,是把本地模型包成一個 OpenAI 兼容的 API:

    • 提供 OpenAI-compatible endpoint(Unsloth Native)
    • 可以同時串本地模型和雲端模型(例如 OpenAI、Anthropic 等),在同一個 API 層切換
    • 內建「自我修復」的工具呼叫與沙盒化代碼執行:模型在呼叫外部工具或執行程式碼出錯時,可以自動重試 / 修正,同時把程式碼限制在安全環境裡

    💡 關鍵: OpenAI 兼容 API 讓你幾乎不改程式碼,就能把原本的雲端 workflow 直接換成本地模型。

    這讓你可以做幾件事:

    1. 把本地 LLM 當成 ChatGPT-compatible 的後端,接在現成客戶端(如 Chatbox、Continue、Open WebUI 等)
    2. 在 VS Code 旁邊跑自己的模型,搭配 Claude Code / Codex 類工具一起用
    3. 建立簡單 Agent:模型收到任務 → 呼叫系統工具或小腳本 → 在沙盒裡執行 → 回傳結果

    適合誰用:三種典型場景

    1. 本地聊天與程式助理:在 VS Code 旁跑自己的模型

    如果你平常習慣用 Claude Code、Cursor 或 GitHub Copilot,想要多一個「完全不出機房」的備用助理,可以這樣玩:

    • 把 Unsloth Desktop 裝在開發機上,啟動一個 GGUF LLM
    • 用 VS Code 外掛或本地聊天客戶端,改成連至 Unsloth 的 OpenAI 兼容 API
    • 寫程式時,用雲端模型做主力、遇到敏感專案(公司內網、客戶程式碼)就切到本地模型

    具體行動建議:

    1. 選一套 ChatGPT-compatible 客戶端(例如 Continue 或 Chatbox)
    2. 在其設定裡,把 api_base 改成 Unsloth 提供的 endpoint(例如 http://localhost:port/v1)
    3. 選定模型名稱,例如 local-llm-7b,直接開始對話與程式補全

    2. 私有資料實驗與原型:本機 RAG / Agent,不經雲端

    很多團隊不敢把內部文件丟上雲端 RAG,Unsloth 提供了一條完全本地的實驗路線:

    • 把公司或個人 PDF / Markdown / internal wiki 先處理成向量資料庫(自行寫腳本或用現成 RAG 套件)
    • 模型端用 Unsloth 提供的本地 LLM API
    • 在本機 web app 或小工具裡,做檢索 + 回答組合

    可以這樣起手:

    1. 在你的後端(Node.js / Python)中,接 Unsloth 的 API 當成 chat/completions 或 responses 來源
    2. 用如 n8n / LangChain / LlamaIndex 這類工具,把「取文件片段 → 呼叫本地 LLM」串起來
    3. 先做一個只服務自己筆電的小型內部 FAQ Bot,再考慮用 Cloudflare Tunnels 把 Unsloth API 安全地開到公司內網(Unsloth 原文有提到 Cloudflare 保護連線)

    3. 多模態 Side Project:影像生成、語音模型、簡單 Agent 工作流

    如果你平常喜歡做 Side Project,Unsloth 可以當成你所有 AI 功能的統一後端:

    • 用 diffusion 模型接一個「本地 Stable Diffusion 影像生成頁面」
    • 用語音模型做「錄音 → 轉文字 → LLM 摘要 → TTS 回覆」的工作流
    • 用 Agent 功能做一個「會自己跑 bash / Python 腳本」的小助手,幫你整理檔案或抓網頁資料

    具體行動:

    1. 在 Unsloth Desktop 裡啟動影像 + 語言 + 語音模型
    2. 在本地 web app(React / Vue / Svelte 任意)裡,統一呼叫同一個 API endpoint
    3. 利用工具呼叫與沙盒功能,設計幾個具體指令,例如「幫我整理 Downloads 資料夾」或「抓這個網站最新 10 篇文章做摘要」

    怎麼開始:從安裝到接上現有 workflow

    1. 安裝:Mac / Windows / Linux 都有

    Unsloth Desktop 是開源工具,支援三大桌面平台:

    • Mac:適合 Apple Silicon,用 MLX 模型可以發揮硬體優勢
    • Windows:多數開發者主力,適合接 NVIDIA / AMD GPU
    • Linux:伺服器與進階用戶首選

    行動步驟:

    1. 前往官網或 GitHub 下載最新版(可從 Product Hunt 連過去:https://www.producthunt.com/products/unsloth)
    2. 安裝並啟動,確認介面可以看到模型列表
    3. 在設定裡檢查硬體偵測與 API 設定(本地端口、是否啟用 OpenAI 兼容模式)

    2. 跑起第一個 GGUF / MLX 模型

    上手建議流程:

    1. 在介面中選擇一個輕量模型(例如 3B–7B GGUF),避免一開始就把 VRAM 撐爆
    2. 點選「啟動 / RUN」讓模型載入;等待載入完成
    3. 使用內建聊天介面,輸入一段問題(例如「幫我寫一個 Python 把 CSV 轉成 JSON 的程式」)
    4. 確認回答品質與速度,調整溫度、max tokens 等基本參數

    若你是 Mac M 系列:

    • 優先選 MLX 模型,在偏好設定裡確認使用 Apple GPU
    • 對照前面的 Apple Silicon + llama.cpp 文章,思考是否要調整 batch size 等設定

    3. 啟用 OpenAI 兼容 API:用 curl 測試

    確認 API 真的跑起來,是往後串接 n8n / Zapier 的基礎。

    假設 Unsloth 在本機開一個 http://localhost:8000/v1 的 API,可以這樣測:

    curl http://localhost:8000/v1/chat/completions \
      -H "Content-Type: application/json" \
      -H "Authorization: Bearer YOUR_LOCAL_KEY" \
      -d '{
        "model": "local-llm-7b",
        "messages": [
          {"role": "user", "content": "幫我用 Python 寫一個排序函式"}
        ]
      }'
    

    你應該會拿到一個結構與 OpenAI 非常接近的 JSON 回應。確認:

    • model 名稱是否正確
    • 是否需要 API key(有些版本可設定為無認證,只限本機)

    💡 關鍵: 成功用 curl 打通 http://localhost:8000/v1/chat/completions,就代表之後的任何 OpenAI 客戶端幾乎都能直接改 endpoint 來使用本地模型。


    4. 在 n8n / Zapier / 本地 web app 裡改掉 endpoint

    最後一步,把你原本的 workflow 直接「搬家」到自己筆電上的 Unsloth。

    以 n8n 為例:

    1. 找到原本呼叫 OpenAI 的 HTTP Request 節點
    2. 把 URL 從 https://api.openai.com/v1/chat/completions 改成 http://localhost:8000/v1/chat/completions
    3. 把 Authorization header 改成對應的本地 key(或移除認證視你設定而定)
    4. 保留原本的 messages 結構,只把 model 改成 Unsloth 內的本地模型名稱

    Zapier 類似做法:

    • 若使用 Webhooks by Zapier,改成打本地 URL
    • 若原本用的是 OpenAI 官方 integration,則改為自訂 webhook

    對於自己寫的 web app:

    • 在環境變數裡新增 OPENAI_BASE_URL=http://localhost:8000/v1
    • 程式碼中使用 OPENAI_BASE_URL 來組合 API URL,而不是寫死 api.openai.com

    這樣,你所有原本設計給 OpenAI / Claude 的 workflow,可以在幾乎不改程式的情況下,直接切到自己機器上的 Unsloth。本地 + 雲端混用時,只要切換 base URL 或 model 名稱,就能控制資料是否出機房。


    簡短比較:Unsloth 與常見本地 LLM 工具差異

    若你已經在用 Ollama、llama.cpp,也可以把 Unsloth 當成「更偏向多模態與訓練、又有桌面介面」的補充工具。

    名稱 核心功能 免費方案 適合誰
    Unsloth Desktop 多模態模型管理 + 本地訓練 + OpenAI 兼容 API 開源免費 想在筆電做本地 Agent、多模態實驗的開發者
    Ollama 本地 LLM 管理與推理(重文字) 開源免費 想快速跑文字模型、不需要訓練與多模態的人
    llama.cpp 低階 C++ 推理引擎(GGUF、效能優化) 開源免費 有工程背景、願意自己包 API 的技術使用者

    如果你想要一個「按裝置效能極限推到滿、又不必寫太多底層程式」的本地 AI 實驗室,Unsloth Desktop 是一個很實用的選擇:先讓它跑起一個本地 LLM,接上 OpenAI 兼容 API,然後把你現有的工作流一個一個搬過來,你就真正擁有了屬於自己的多模態 Agent 伺服器。

    🚀 你現在可以做的事

    • 前往 Product Hunt 或 GitHub 下載並安裝 Unsloth Desktop,啟動一個 7B gguf 或 MLX 模型
    • 用 curl 或你常用的 ChatGPT-compatible 客戶端,將 api_base 改成 http://localhost:8000/v1 測試本地 API
    • 挑一個現有用 OpenAI 的 workflow(如 n8n 流程或小型 web app),只改 endpoint 與 model 名稱,把它搬到本機 Unsloth 上跑
  • 用手機跑 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)。
    • 先規劃步驟,再分批完成任務。
    • 適合的工具類型:
    • 檔案讀寫工具:讀取本地 txt、md、pdf(先轉文字)。
    • 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.6B 的 Q4_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:串接 curl、Python 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、CLI、API 操作時,轉給 BTL-3。
    • 其他任務仍用通用模型(如 Solar Open 2、Laguna 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 Studio → Add 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 Studio 或 llama.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 pull → cmake → 放入 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-smi 或 llama.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 + chromadb 或 llamaindex 搭一個最小可用的 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.rs 或 llama.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 做程式輔助