Kerwin AI Information

標籤: BTL-3

  • 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 並觀察效果