【2026 最新】Backburner 教學：iPhone 幫 Mac 跑本機 LLM，三組對照與長任務怎麼驗？

你讓 Mac 上的本機 AI 讀一份長文件，游標轉了很久；桌旁的 iPhone 卻閒著。Backburner 教學要回答的問題是：手機能分擔哪一段推論？接上線後變快，怎麼知道是手機幫忙，還是 Mac 軟體本來就改好了？

這篇專為第一次接觸本機模型、願意複製幾行終端機指令的讀者寫。先用白話看懂分工，再準備安裝與三組對照工作簿，最後驗收長任務、斷線和輸出。硬體不足也能先學會判讀方法；第一天的成果是一份說得清楚的紀錄。

以下依截至 2026 年 10 月 8 日的官方文件、安裝程式與公開原始測試紀錄整理。AlphaLab 本次環境為 16GB Mac，沒有指定模型，因此未執行跨裝置推論；文中效能數字均屬作者指定配置的觀察，下面的長跑與復原流程是待你執行的驗收方法。

先說結論：Backburner 教學先分清兩種加速

可歸因的手機增益＝同一個 fork，手機開啟相對手機關閉的差異。fork 是從原版程式分出去修改的版本。把它想成餐廳：換新廚房設備是一種改善，多一位助手是另一種；一起換，便很難知道誰省下等待。

• A 組：原版 llama.cpp，只有 Mac。作為你原來可用的基線。
• B 組：Backburner fork，只有 Mac。量到整套 fork 的改善與代價。
• C 組：同一 Backburner fork 加 iPhone。B、C 的差異才接近手機這一層的增益。

三組共同固定模型檔、權重量化、KV 精度、輸入與 Context 深度，另外保存各組軟體設定。fork 自帶的推測解碼等差異，是 A、B 比較的處理條件；不能把它們偷偷算成手機功勞。懂得這一點，再看跑分才有用途。

原理：手機接手的是讀題，還是寫答案？

LLM（大型語言模型）先讀你交給它的提示，再一小段一小段產生文字。prefill 是「讀題」；decode 是「寫答案」。token 是模型切分文字的單位，並不等於一個中文字。llama.cpp 則是讓模型在自己的電腦執行的推論引擎；可先讀推論引擎入門補上它與模型的關係。

在作者公布的預設配置、Context 不超過 64k 時，Mac 與手機像分段流水線：Mac 算前 40 層，iPhone 算第 41–64 層，分批交接並重疊工作。最後一小批留在 Mac。手機是否真的參與，要看 Mac 的啟動與 server log；手機畫面的一個速度值，未必就是整條流水線的完成速度。

長 Context 又換一種分工。KV cache 是讓模型不用每次重讀全部內容的「讀題筆記」；超過 Mac 的預設 64k cells 後，舊筆記的一部分放到手機，手機計算那部分 attention（把當前問題與既有內容對照的運算），Mac 合併結果。這不是兩台裝置變成一條任意共用的記憶體。

因此，64k 以下的打字速度不能直接歸給手機；超過這個分界又不能沿用短 Context 的分層解釋。官方分工與限制把兩者分開記錄。想理解卸載與記憶體成本，可接著讀本機 LLM 成本指南。

Backburner 教學上手：五步留下第一份安裝紀錄

①「先點名」：確認你的硬體走哪條路

看見 USB-C 就能照抄嗎？先記 Mac 型號、RAM、macOS、手機型號與線材速率。當前一般安裝程式檢查 Apple Silicon、macOS 14 以上與至少 24GB RAM；新安裝會下載及建立約 28GB 檔案，空間不足 30GB 時提出提醒。這是預設 27B 路線的門檻，不是所有小記憶體實驗的物理上限。

作者主要公布的配置是 M4 Pro 24GB 與 iPhone 17 Pro Max，另測過 16 Pro Max；安裝文件列 iPhone 15 Pro 以上與 M 系列 iPad。文件同時明說 iPad 尚未做效能測試。不要把可安裝範圍當成每台機器都能得到相同速度。

線材需要能傳資料的 10Gb/s USB-C 線。Apple 的 USB-C 說明也指出 Pro 裝置的高速傳輸要搭配適合的 USB 3 線，隨盒線只有 USB 2 速率。先確認線與連接埠，再排除軟體；插頭相同不代表頻寬相同。

②「先看工單」：下載並檢查安裝程式

把遠端 script 直接管進 shell，會跳過你閱讀它的機會。先依官方 install.sh下載成檔案：curl -fL https://raw.githubusercontent.com/StayLameBro/backburner/main/install.sh -o backburner-install.sh，再用 less backburner-install.sh閱讀；願意接受其中的下載、安裝目錄與設定後，執行 bash backburner-install.sh。這幾行是讀者操作，不是本站已執行的結果。

程式會準備 Mac 引擎、模型、手機尾段與專案內 Python 環境；缺少合適 Python 時還有取得 uv／Python 的分支。先有一份磁碟與工具變更清單，才知道日後要清哪些檔案。安裝完成記下 git -C ~/backburner rev-parse HEAD、git -C ~/backburner/llama.cpp rev-parse HEAD，並保存引擎的 --version 輸出與所用 release。使用預編譯引擎時，submodule commit 不能取代 binary 版本。

③「手機也要點名」：安裝 App 後核對記憶體預算

依Backburner 手機安裝文件，可以從 AltStore Classic 加官方 source 安裝 IPA，或由 Xcode 建置。AltStore 在 Mac 的入口是選單列 AltServer → Install AltStore → 你的手機；需要的信任與 Developer Mode 步驟可對照AltStore 官方 macOS 流程。帳號資訊只填在你自己選擇的官方工具。

關鍵不是「App 打開了」，而是 cd ~/backburner 後執行 scripts/phone-up.sh，看到 wired device 與 app budget。作者尚未完整驗證 AltStore 這條安裝路徑的記憶體 entitlement；文件要求 AltStore 2.2 以上並回報預算。若預算不夠裝下尾段，先排查簽章與裝置限制，不能靠多跑一次 benchmark 解決。

截至本次查核，最新公開 App release 是 v0.0.4。先更新再驗收：Security 文件記錄 v0.0.3 前的網路連線限制問題；當前 USB 路徑設有介面檢查，Wi-Fi 則是另一套配對、加密隧道。本文先採 USB 配置，不把網路埠暴露到外部。

④「先讀短紙條」：確認服務與手機分工

保持手機解鎖且 Backburner 在前景，執行 backburner phone複製手機尾段，再執行 backburner啟動服務。若 shell 找不到這個命令，先檢查安裝提示與 ~/.local/bin 是否在 PATH，不要重複下載整套模型。

若 server 要求提高 wired memory 上限，先記原值 sysctl -n iogpu.wired_limit_mb。官方為 24GB 測試配置使用 sudo sysctl iogpu.wired_limit_mb=20480；這會改系統 GPU 記憶體額度，只在已確認容量的同一路線使用。不要為了繞過 16GB 機器的安裝檢查照抄。這個設定重開機會重設，稍後也可用原值還原。

用 curl -f http://127.0.0.1:8080/health檢查服務，再從你選用的相容聊天工具把 base URL 設成 http://127.0.0.1:8080/v1，請它回一句短答案。Mac log 應能核對 split prefill on；更長 Context 才另驗 remote KV on。短題不一定觸發手機分層工作，連線成功與性能有效要分開驗。

⑤「再加厚紙本」：分離連線與效能驗收

預設工具圍繞 Qwen3.8-27B IQ4_XS 與指定 draft model，不把任意小模型當成可直接替換的教學捷徑。先用相同模型的短 prompt 確認服務，再加入一份你能核對內容的長文件。模型權重與 KV cache 是兩種不同量化；把兩者名稱分別記下，避免只寫「都是四位元」。

三組對照工作簿：每次只回答一個問題

先建立一份測試資料夾。每個跑次保存 UTC 時間、Mac／手機配置、線材、App／引擎版本、模型 SHA-256、輸入、生成上限、sampling、Context、KV 精度、cache 狀態、完整 log 與輸出。用 shasum -a 256 ~/Models/Qwen3.8-27B-IQ4_XS.gguf核對三組讀到同一個模型檔。

有原版 llama-server、指定模型與所需環境時，可從 session-bench.py 原始碼開始。它會在 bench/results/session.jsonl 寫入結果，原版 binary 預設路徑是 /opt/homebrew/bin/llama-server；先檢查路徑與 --version，不要把另一個 fork 命令冒充 stock。

在專案根目錄依次執行 python3 bench/session-bench.py --config stock、python3 bench/session-bench.py --config fork-mac、python3 bench/session-bench.py --config fork-phone。這三條是三次各自完整的 session，腳本會啟停自己的 server；先停掉占用測試埠的手動服務。每完成一組立即保存 JSONL 與 server log。

第一次依官方預設跑，先看程序能否結束。之後做數輪，交錯 A、B、C 順序並保留冷卻時間，避免每次最後一組都遇到熱機。這是本文建議的實驗設計，不是作者公布的樣本量。需要只比較加入長工具結果的讀題，可用 python3 bench/turn-bench.py --build建立狀態，再分別跑 python3 bench/turn-bench.py --config mac與 python3 bench/turn-bench.py --config phone。

工作簿有四本帳：prefill、decode、記憶體、總時間。前兩者看 prompt 與 generated tokens 的速率；首 token 等待還包括服務處理，不能直接叫純 prefill。記憶體分 Mac server RSS、系統 swap、手機 App footprint；RSS 是作業系統的一種記憶體計數，也不是 GPU 全部占用。總時間從同一個任務開始算到同一個驗收終點，另記答案長度與是否通過。

作者 session 腳本有每秒資源採樣；峰值是這個取樣間隔所看見的峰值，不保證捕捉每個瞬間尖峰。不要把手機與 Mac 的記憶體數值混成一個「顯存總數」，也不要把生成較短、甚至因 length 被截斷的回應算成省時成功。原版 llama-bench 文件可補上 prompt／generation 測項與輸出格式的讀法。

作者數字怎麼看：快了多少，證據就到哪裡

圖上保存的是作者 2026 年 10 月 1 日原始紀錄：stock build 10621／commit c1d0e7a00，fork 引擎 commit 879b48a68。兩個 fork run 的 integration commit 又不同，分別為 a6d00d7 與 6bf7fba。這組數字支持理解改進方向，不能取代在完全相同安裝快照下的 B、C 重跑。

在那組約 27k 初始輸入的紀錄裡，兩個 fork 的 decode 接近；改善不宜全部算給手機。首 token 等待也只是一次 session 的觀察，並非所有工作的平均提速。作者另有固定深度、每組兩次的讀題紀錄；你可以對照 公開原始 JSONL，先看 excluded、note 與版本，再看漂亮的數字。

長 Context 更要分精度：README 的部分 Mac-only 長文測試用四位元 KV，手機配置用八位元 KV；這是容量與精度一起改變的比較。啟動時依 free memory 算出的容量不是已驗品質；少數埋藏事實被找回，也不代表整份文件的推理都正確。先把自己的答案位置與合格條件寫好，再擴長。

長任務、斷線與回復：把「可用」寫成條件

建議先選一份沒有個資的長文件，埋三個可人工核對的資訊點，要求回傳答案與位置。這三題是你的驗收題，不是作者測試的翻版成績。先在 64k 以下做基線，再按實際工作需求加長；連跑幾次並保存開始／結束時間、手機 thermal 狀態、錯誤與輸出，不預先保證能跑多久。

手機必須保持 Backburner 在前景。Apple 的 Metal 背景說明明確限制背景 App 的 GPU 存取；可照手機安裝文件設定 Guided Access，降低誤鎖螢幕的機會。溫度欄是系統狀態，不等於你量到攝氏溫度；想量機身溫度要另外記量測方法。

斷線分兩張驗收卡。只有 split prefill 工作時，官方記錄失敗後暫停使用手機 60 秒、該 batch 在 Mac 重跑；你要確認 log、請求結束狀態與答案。手機已持有 remote KV 時，官方記錄 5 秒提出警告、15 秒不回應便停止 server；此時 Mac 已不持有那部分舊內容，不能期待無損續跑。重新開 App 與 server，並從你事前保存、實際驗過可載回的狀態開始。

先在可丟棄 session 拔線測試，別用唯一一份重要工作。v0.0.4 修正 remote-KV session 保存協定，但 README 說這條保存路徑驗於 loopback 模擬，尚未驗於真實手機。第一次長跑前，親自做「保存→停止→載回→核對答案」，通過才把它當復原能力。

輸出一致性也分兩層：greedy 模式可以核對 token 序列；有 sampling 的 session 要看任務與格式是否通過，不能要求每次逐字相同。作者的 token-identical 結果限特定深度與短輸出樣本；把它當 regression 線索，別當任意提示的品質保證。

要回到原版，先停止 Backburner 的 server 與 proxy，再啟動你保存版本的 stock llama-server，將用戶端端點改回該服務，跑同一題確認。若改過 wired limit，用記下的原值執行 sudo sysctl iogpu.wired_limit_mb=原值；這裡的「原值」要換成紀錄中的數字。App、模型與專案目錄先留到 stock 基線通過，之後再按自己的檔案清單整理。

常見問題：Backburner 教學的八個快答

1. 接上 iPhone，打字就會快一倍嗎？

不一定。64k 以下官方分工把 decode 留在 Mac；用 B、C 同設定對照，另看讀題的等待。

2. USB-C 充電線都能用嗎？

先查傳輸速率。這條流程指定 10Gb/s 資料線，隨盒 USB 2 線不是相同條件。

3. 16GB Mac 要強制跑這個安裝指令嗎？

先換路線。預設安裝檢查 24GB；作者另有 split-decode 實驗文件，配置與本篇基線不同，不用 FORCE 去冒充這組測試。

4. iPad 已經驗證有效嗎？

尚不能這樣說。文件列 M 系列可安裝，但明說效能與記憶體預算待回報。

5. 多支手機可以直接堆成兩倍速度嗎？

不能從目前證據推出。兩手機文件把 old-KV 分攤列為已建置、loopback 驗證；真實兩手機待測，三段 prefill 則列為未建置。

6. 螢幕鎖了，Mac 會自己接手全部內容嗎？

視分工而定。prefill 失敗與持有 remote KV 的失聯是不同復原情境；後者要按停止與重啟流程驗收。

7. 容量顯示很大，等於長文一定答對嗎？

不等於。容量、可執行與答題品質分開記；題目要有正確答案和文件位置。

8. 第一輪應該追最高 tok/s 嗎？

先追可核對。三組都能結束、版本與設定完整、答案通過，再比較耗時與記憶體分布。

給新手的三個重點

• 先分讀題和寫答案，再分短 Context 與 remote KV；同一支手機會做不同工作。
• 先保存 A、B、C 的版本與原始結果；手機功勞看 B、C，總任務還要看答案是否完成。
• 先驗前景、保存、拔線與回到 stock；能復原的流程，才值得交給更長的工作。