你让本地 AI 读一份长文件，最先遇到的可能不是回答慢，而是回答前那段等待：模型要先把全文读完，并建立内部状态。这个阶段叫 Prefill（预填充）。一名 Reddit 开发者尝试把闲置的 iPhone 变成 MacBook 的第二块推理设备，让两台机器同时干活，也让手机替电脑保存一部分长上下文。
这项实验值得看，因为跨设备推理并不是简单地把两颗芯片相加。手机算得再快，如果数据在设备之间搬运和同步耗时太久，协作反而可能更慢。以下性能数据均来自作者 StayLameBro 的自测，尚无论文、代码、可复现实验记录或第三方测试印证。
手机接过模型的后半程
作者使用一台 24 GB M4 Pro MacBook 和 iPhone 17 Pro Max，通过 10 Gb/s USB-C 连接，运行其所称的 Qwen 3.8 27B（IQ4_XS）。27B 表示模型约有 270 亿参数；IQ4_XS 是一种量化格式，即用较少位数保存模型权重，降低内存需求，但可能带来精度损失或硬件依赖。该模型名称和具体版本目前也没有独立来源确认。
在 Prefill 阶段，系统把输入切成每批 256 个 token。Token 是模型处理文字时使用的基本单位，可以粗略理解为拆分后的字词片段。Mac 计算第 1—40 层，再把中间结果传给手机；iPhone GPU 计算第 41—64 层。与此同时，Mac 已经开始处理下一批输入。
这像两个人接力装箱：前一个人不必等后一个人封完箱子，便能开始整理下一箱。关键不只是分工，而是让两边的工作重叠，尽量把 USB-C 传输的等待藏在计算之后。
作者还称，A19 Pro GPU 的 Metal 4 tensor ops（针对矩阵运算的硬件能力）让手机负责部分的速度达到未启用时的 2.4 倍。这个数字只适用于手机承担的计算，并不表示整套系统快了 2.4 倍。
29%—44%，到底快在哪里
作者用同一构建测试把一份 2,000-token 文件写入已有会话。按其正文给出的端到端 Prefill 速率，在 16k 上下文下，Mac 单独运行是 109 tok/s，接入 iPhone 后为 157 tok/s，提升 44%；在 32k 下从 101 升至 130 tok/s，提升 29%；在 48k 下从 87 升至 113 tok/s，提升 30%。这里的上下文窗口，是模型一次能够读取和保留的 token 范围；窗口越长，保存内部状态通常越占内存。
作者还报告了 8k 上下文下从 132 升至 177 tok/s、提升 35%的结果，但这项数据来自“两天前的同一 benchmark”，不确定是否与其余档位处于完全相同的测试条件，不宜直接横向比较。
原帖特别提醒，手机界面一度只显示手机所持模型层的速度，不能代表完整系统。因此这里采用的是作者正文声称的端到端数据，而不是截图读数。
另一个冷启动测试加载了全新的 27k-token agent 会话：原版 llama.cpp 用时 245 秒，作者修改版在 Mac 上单独运行用时 228 秒，接入 iPhone 后为 168 秒。不过这组比较同时改变了软件版本和是否连接手机，不能把 245 秒到 168 秒的全部差异都算成 iPhone 的贡献。
上下文太长后，手机换一份工作
超过 64k 上下文后，手机不再负责模型的后 24 层。系统把最旧的 KV pages 移到手机，Mac 则运行全部 64 层。KV Cache 可以理解为模型阅读长文时留下的计算草稿，避免生成每个新 token 时把旧内容全部重算；page 则是分块保存的草稿页。
此时，iPhone GPU 负责在旧的 keys 上计算 attention——也就是判断生成当前内容时，应当关注哪些旧信息——再由 Mac 合并结果。生成文字时，系统还会调用 iPhone Neural Engine：每个包含 16k keys 的旧上下文页，会被编译成一个以这些 keys 为权重的 Neural Engine 模型。
作者称，在 140k 上下文下，与只使用手机 GPU 处理这部分任务相比，引入 Neural Engine 后，生成延迟从每 token 279 毫秒降到 176 毫秒。这不是相对 Mac 单独运行的提升。服务器还会根据手机剩余内存分配 196k—229k 的 8-bit 上下文，最多约 5.7 GB KV Cache 放在手机上；但原始材料在此处截断，完整限定条件未知。
为什么值得关注
我们此前在 9 月 29 日的 A7677 中介绍过，用显存、系统内存和 SSD 分层运行超大模型。这次实验把同一种思路延伸到了 Mac 与 iPhone：电脑缺内存或算力时，不只向本机其他存储层借资源，也向桌边的另一台设备借。
已有尝试说明，这条路并不稳胜。据 GitHub 上 DIM 项目的技术报告，一名学生曾让 Mac 负责模型头尾、iPhone 处理中央若干层，却遇到 iOS 内存回收、GPU 工作集上限、SSD 溢出和 Core ML 调度开销；双机方案只在 Mac 内存紧张、可能掉到 SSD 的特定条件下快约 1.68 倍。另一名 Infer Ring 开发者也曾在 Reddit 报告，M1 Mac 接 iPhone 17 Pro 后，平均生成速度反而比全放在 Mac 上低约 25%。
所以，本次实验真正有意思的地方，不是“手机也能跑模型”，而是它试图用流水并行和任务切换，抵消跨设备通信成本：短一些的上下文让手机接手部分模型层，长到一定程度后则让它保存并计算旧上下文。
局限与未知
- 所有结果都来自同一位作者，未说明重复次数、误差范围、手机温度、功耗和散热状态；29%—44%目前只能视为自测结果。
- “一根 USB-C 线和一些软件就够了”带有明显宣传色彩。材料没有交代软件是否公开、安装条件、兼容设备范围及实际使用门槛。
- 这套方案是否划算，取决于手机算力、可用内存、传输速度和同步开销能否共同抵消通信等待。现有材料还不足以说明它在其他模型、设备和日常长时间运行中的边界。