AIAI 工具图鉴
← 返回全部文章
·约 12 分钟PPT

🔥 闲置 iPhone 别吃灰：插根线给 Mac 当显卡，27B 大模型提速 44%

量化交易
下载 PPT下载视频

配套媒体

本页对应的 PPT 与演示视频

backburner-recommend.mp4
PPT
backburner-recommend.pptx浏览器不能直接打开 PPT，下载后用 PowerPoint / WPS / Keynote 查看
下载没反应？点这里复制直链

侧边栏预览窗口（Electron webview）会拦截下载，把下面的链接复制到 Chrome / Edge 地址栏打开即可保存。

PPT../../backburner-recommend.pptx
视频../../backburner-recommend.mp4
本文目录
  1. 🚀 Backburner 是什么？
  2. ✨ 核心能力：三个"真实数字"
  3. 1. 读长文件快 29%44%（最有用的一个）
  4. 2. 上下文从 64k 顶到 196k229k
  5. 3. 写字（生成）速度的账要分开算
  6. 4. 答案会不会变？
  7. 🛠️ 上手：一条命令，四步走
  8. 安装 / 一条命令版
  9. 手动分步版
  10. 📊 和别的路子比，值不值？
  11. ⚠️ 上手前必须知道的 5 个坑
  12. 🎯 总结

🔥 闲置 iPhone 别吃灰：插根线给 Mac 当显卡，27B 大模型提速 44%

封面图

一句话结论：一根 10Gb/s 的 USB-C 线，把你手边闲置的 iPhone 插到 Mac 上，它就能分担 Qwen3.8-27B 的部分计算——读长文件快 29%~44%，上下文从 64k 直接顶到 196k~229k，全程跑在你自己机器上，不花一分 API 钱。项目叫 Backburner，MIT 协议，开源代码在 GitHub（StayLameBro/backburner），648 star，创建才 5 天。

冷静点：这套方案目前是预发布状态，作者只在两款机器上实测过（MacBook Pro M4 Pro 24GB + iPhone 17 Pro Max / 16 Pro Max），数据全部来自作者自己的 bench 脚本。下面的每个数字我都会标出测量条件，你可以照着复现。

🚀 Backburner 是什么？

一句话：把原本只在你 Mac 上跑的大模型，"切一半出去"给 iPhone 跑。

它不是 App Store 里那种花哨的客户端，而是一个改过的 llama.cpp 分支 + 一个 iPhone 端 App，两头的活儿分工明确：

  • Mac 跑第 1~40 层，同时 Mac 的 CPU（M4 的 SME2 单元）分担约 30% 的大矩阵乘法；
  • iPhone 跑第 41~64 层，用 A 系列芯片 GPU 的矩阵单元算，干完把结果传回来；
  • 两头流水线并行——Mac 算下一批的时候，iPhone 正在算上一批，互相不等。

模型分层流水线示意

超过 64k 上下文之后，玩法还会变：Mac 自己把全部 64 层接过去，iPhone 改去算"最老的那批 key"的注意力。相当于手机成了 Mac 的一块"外挂显存 + 协处理器"，这是它最能拉开差距的地方。

作者实测的那张图很直观——同一个 agent 会话里，读每个文件时你要干等的秒数：

每个文件的等待秒数对比

✨ 核心能力：三个"真实数字"

1. 读长文件快 29%~44%（最有用的一个）

很多人跑本地模型最难受的不是"写字慢"，而是每读一个文件、每等一个工具返回，都要干瞪眼十几秒。Backburner 砍的就是这段等待。

prefill 速度对比

测量条件：Qwen3.8-27B IQ4_XS，MacBook Pro M4 Pro 24GB，iPhone 17 Pro Max，USB-C 有线，2026-10-01 实测，同一个模型量化、同一个构建版本。

换算成人话：你让 AI 读完一个 2000 行的文件，原本要等 18.8 秒，现在 13.1 秒。 一个会话里读十几个文件，省下来的就是两三分钟。

一条更贴近实战的数据：作者用 omp 的真实会话（系统提示 + 项目笔记 + 12 个工具，冷启动 26,849 token）测的——

冷启动会话首次回答对比

第一次回答从 245 秒砍到 168 秒，这个体感差别是肉眼可见的。而且读过一次之后，SSD 提示词缓存（scripts/proxy.py）下次恢复这 27k token 只要 0.3~5 秒。

2. 上下文从 64k 顶到 196k~229k

24GB 内存的 Mac 装 8-bit 上下文，64k 就见顶了；想上 128k 只能把精度降到 4-bit。作者实测 128k/8-bit 会超 GPU 显存上限约 0.3GB（在 20GB 限制下）。

插上 iPhone 之后，最老的那部分 KV 会被搬到手机上存着：

上下文容量对比

意义在哪：你现在可以真的把一个中等规模的代码仓库、一整份长文档塞进一个会话里问，而不是东一块西一块地切片喂。

作者还做了个"埋点测试"：在 128k 上下文的 1.5k / 40k / 100k 三个位置各藏一个事实 —— 3 个全召回，手机温度状态正常。

3. 写字（生成）速度的账要分开算

这条必须说清楚，免得你期望过高：64k 上下文以内，写字速度跟手机没关系，iPhone 完全不参与。这段时间快起来，是 fork 自带的内核和草稿模型（DFlash2 投机解码）的功劳。

decode 速度对比

注意看第一行：原版 llama.cpp 只有 11.3 tok/s，改过的引擎 Mac 单机就到 25.0 tok/s —— 哪怕你一个 iPhone 都不插，光换这套引擎，写字速度也是翻倍的。过了 64k，手机的 GPU 和神经引擎才开始接管"老 key 的注意力"：140k 时单个 token 从 279ms 降到 176ms。

4. 答案会不会变？

这是我最在意的一点，作者也测了：贪心解码下，插手机和不插手机的输出是 token 级完全一致的（8k 和 32k 各测 256 个 token 全部相同，140k 测 32 个 token 也全部相同）。也就是说，它只是帮你算得更快，不会偷偷把输出质量换了。

🛠️ 上手：一条命令，四步走

硬件门槛（照着对号入座）：

  • Apple 芯片的 Mac（作者实测 M4 Pro / 24GB）
  • iPhone 15 Pro 或更新（15 Pro / 16 Pro Max / 17 Pro Max 都行），M 系列 iPad 从 v0.0.2 起也支持但还没实测
  • 一根 10Gb/s 的 USB-C 线（⚠️ 手机盒里自带那根是 USB 2，太慢，不够用）

安装 / 一条命令版

curl -fsSL https://raw.githubusercontent.com/StayLameBro/backburner/main/install.sh | bash
backburner phone   # 每台手机做一次：插上、打开 App，把手机那一半模型拷过去
backburner         # OpenAI 兼容的服务就跑在 http://127.0.0.1:8080/v1

装 iPhone 端用 AltStore + 免费 Apple ID 就行，不需要开发者账号。

手动分步版

git clone --recursive https://github.com/StayLameBro/backburner && cd backburner

# 1. 编译 Mac 端引擎
cmake -S llama.cpp -B llama.cpp/build-metal -DCMAKE_BUILD_TYPE=Release
cmake --build llama.cpp/build-metal --target llama-server llama-quantize -j

# 2. 下模型：Qwen3.8-27B IQ4_XS GGUF 放到 ~/Models/Qwen3.8-27B-IQ4_XS.gguf，再搞个草稿模型
huggingface-cli download z-lab/Qwen3.8-27B-DFlash2 --local-dir ~/Models/qwen38-27b-dflash2
scripts/make-drafter.sh ~/Models/qwen38-27b-dflash2 ~/Models/dflash2-v2-q4km-self16.gguf

# 3. 切出手机那一半：第 41~64 层，约 5.1GB（Mac 负责算 logits，所以不要 head）
python3 scripts/split-gguf.py ~/Models/Qwen3.8-27B-IQ4_XS.gguf ~/Models/tail-iq4xs-L40-nohead.gguf -L 40 --no-head
scripts/phone-tail.sh L40

# 4. 每次重启后执行一次：让 GPU 把模型锁在内存里（macOS 会重置这个上限）
sudo sysctl iogpu.wired_limit_mb=20480

# 5. 开跑：插着手机 + 打开 App 就自动用上 iPhone
scripts/serve.sh
PHONE=0 scripts/serve.sh      # 想对比的话，这行是纯 Mac 单机

第一次带手机跑 serve.sh 会往手机推一份神经引擎的页模型并重启 App，大概要一分钟。之后启动日志里应该看到 split prefill on、remote KV on、ANE pages on 三行，看到就说明全套都通了。

8GB 内存的 Mac 也有活路：作者写了拆分解码模式，Mac 跑前 20 层、手机跑剩下的，在 MacBook Neo + iPhone Air 上能到约 4 tok/s。慢，但能跑。

桌面上的实际连接形态

📊 和别的路子比，值不值？

方案对比

适合你，如果你是：手上有一台 Apple 芯片 Mac + 一部吃灰的 iPhone 15 Pro 以上机型；日常在跑 agent / 读代码库这种"长上下文、反复读文件"的活儿；在意数据不出本机。

先别急，如果你是：想要写字速度也起飞（64k 以内手机不参与写字）；想用 Windows 或 Android（不支持）；连一根 10Gb/s 的线都懒得买（那确实白搭）。

⚠️ 上手前必须知道的 5 个坑

  1. 小文件它不管。 只有超过约 512 token 的读取，手机才会加入。作者真实 omp 会话里 36 次请求只有 7 次够格——不过这 7 次承担了 83% 的 token 量，所以还是值。
  2. 过 64k 后手机 App 必须保持前台。 那时候最老的对话内容只有手机有，Mac 已经没了。手机黑屏、锁屏、拔线超过 15 秒，服务端会直接停掉并提示。作者建议开 iOS 的"引导式访问"防误触锁屏。
  3. Wi-Fi 模式要先有线配对。 0.0.3 之前的版本在 Wi-Fi 上谁都能连，务必更新 App，或者开着 App 时把手机 Wi-Fi 关掉。现在网线上只认你这台 Mac，Wi-Fi 走加密隧道，且不在网上广播。
  4. 一次只能处理一个请求(-np 1)，别当多人服务用。
  5. 8GB Mac 只有约 4 tok/s，属于"能跑"而不是"好用"。

🎯 总结

Backburner 的聪明之处不在"用了两台设备"，而在把任务拆得足够细：读的时候分层流水线并行，写字的时候各自算各自的，超长上下文时再让手机专职伺候"最老的那批 key"。每一步都有实测数字，而不是拍脑袋说快了。

一句话建议：如果你手边正好躺着一台 Apple 芯片 Mac 和一部 iPhone 15 Pro 以上机型，这事儿值得一晚上折腾。 成本是一根线的钱，收益是 64k→196k+ 的上下文和一个不上云的本地 agent。

要是你已经试过了，作者专门开了个 issue 模板收集不同机型的实测数据——别的 Mac、别的手机、iPad、双手机这些组合，正是这份 README 里还缺的数字。

开源地址：https://github.com/StayLameBro/backburner（MIT，当前 648 star，创建 2026-10-01，最近更新 2026-10-05）

本文数据与截图均来自项目 README 与官方仓库 docs/img/wait-per-file.png，测试环境 MacBook Pro M4 Pro 24GB + iPhone 17 Pro Max，测量日期 2026-10-01。