開発者のStayLameBro氏が、iPhone 17 Pro Maxを24GBメモリ搭載のM4 Pro MacBook Proにつなぎ、ローカルAIの入力処理を最大44%高速化した実験を公開した。独自ソフト「Backburner」でQwen3.8-27Bを動かし、Macが入力を処理する計算の一部をiPhoneへ分担させる仕組みだ。開発者の測定では、約2,000トークンの追加資料を読み込む時間が、16Kトークンの文脈を保持した状態で18.8秒から13.1秒へ短縮された。
ただし、回答を生成する速度まで44%向上したわけではない。手元のiPhoneを追加する効果が期待できるのは、大量の資料を読み込む待ち時間を短縮したい場合や、長い会話を保持するためのメモリが不足する場面である。
44%高速化で、待ち時間は何秒減るのか
2026年10月1日の測定に使われたのは、IQ4_XS形式に量子化したQwen3.8-27B、24GBメモリ搭載のM4 Pro MacBook Pro、iPhone 17 Pro Maxという組み合わせだ。接続には10Gb/s対応のUSB-Cケーブルを使っている。比較したのは、同じBackburnerをMac単体で動かした場合と、iPhoneを追加した場合であり、一般的な推論ソフトからBackburnerへ切り替えたことによる効果とは分けて見る必要がある。
測定対象は、すでに保存されている会話へ新しいファイルやツールの実行結果を追加した際の入力処理速度だ。LLMは、まず入力された内容を読み込んで計算し、その後に回答を順次生成する。今回の「最大44%高速化」は前者にあたる。公開ログでは追加された入力は2,048トークンで、測定スクリプトは回答を生成せず、入力処理だけを行う設定になっている。
| すでに保持している文脈 | Mac単体の入力処理 | iPhone追加時の入力処理 | 読み込み時間の変化 |
|---|---|---|---|
| 16K | 109トークン/秒 | 157トークン/秒 | 18.8秒 → 13.1秒 |
| 32K | 101トークン/秒 | 130トークン/秒 | 20.3秒 → 15.8秒 |
| 48K | 87トークン/秒 | 113トークン/秒 | 23.5秒 → 18.1秒 |
数値は、開発者が公開した測定結果を丸めたものだ。Kは保持している文脈のトークン数を表し、各条件で2回ずつ入力処理を行っている。ここで示されている速度と所要時間は入力処理だけを比較したもので、保存済みの会話を復元する時間や、回答を生成する時間は含まれていない。
開発者が10月1日に測定した16Kの条件では、入力処理速度が約44%向上した結果、読み込み時間は約30%短縮された。速度の増加率は「157÷109−1」で約44%、時間の短縮率は「（18.8−13.1）÷18.8」で約30%となる。同じ改善を異なる基準で表した数字なので、「44%高速化」を「待ち時間が44%減る」と読み替えることはできない。
また、元の投稿には、iPhone画面に表示されていた速度は、その端末が担当する層だけを処理した際の値だったという訂正もある。上の比較では、開発者がシステム全体の入力処理速度として示した数値を使っている。生ログと測定手順は公開されているものの、第三者による追試で再現性が確認された性能ではない。
iPhoneはモデル後半の計算を担当する
64Kまでの文脈では、Macがモデルの第1〜40層、iPhoneが第41〜64層を担当する。Macは入力を256トークン単位の小さなまとまりに分けて処理し、その中間データをiPhoneへ送る。iPhoneのGPUがモデル後半を計算している間に、Macは次の入力部分の処理を始める。二つの端末を並行して動かすことで、長い入力を処理し終えるまでの時間を短縮する仕組みだ。
モデル全体のデータを処理のたびにケーブル経由で送り直しているわけではない。iPhoneは自分が担当する層のモデルデータを保持し、新しく処理する入力に必要な中間データを受け取る。ただし、各バッチの最後に残る小さな入力部分はMac側で処理し、最終的な出力をMac側に残す設計となっている。
A19 ProのGPUに備わる行列演算機能も利用されている。開発者によると、この機能を有効にした場合、iPhoneが担当する処理は、無効にした場合と比べて2.4倍高速だった。これはあくまでiPhone内部の処理速度を比較した数字であり、Macと組み合わせたシステム全体が2.4倍高速になるという意味ではない。
AppleはA19 Proについて、GPUの各コアにNeural Acceleratorを搭載し、それとは別に16コアのNeural Engineも備えると説明している。Backburnerで64K以下の入力処理に使われるのはGPUであり、Neural Engineが利用されるのは、後述する長い文脈を扱う別の処理である。
回答生成の高速化は、Mac側の最適化と分けて見る
27K〜33Kの文脈で開発者が測定した回答生成速度は、通常版のllama.cppが11.3トークン/秒、BackburnerをMac単体で動かした場合が25.0トークン/秒、iPhoneを追加した場合が25.1トークン/秒だった。Backburnerそのものへの変更によって大幅に高速化している一方、同じBackburnerにiPhoneを追加したことによる差はほとんどない。
Backburnerはllama.cppから派生したソフトで、MacのCPUに備わるSME2という行列演算機能を利用し、GPU処理にも独自の最適化を加えている。さらに、小さなモデルが先に生成候補を出し、大きなモデルがそれを検証する「投機的生成」も組み合わせている。64K未満の文脈で回答生成が高速化している主な理由は、こうしたMac側の最適化だと開発者は説明している。
入力が短い場合も、iPhoneが使われる機会は少ない。現在の実装では、約512トークンを超える入力処理から分担が始まる。開発者が実際に使ったセッションでは、36件の要求のうちiPhoneが処理に参加したのは7件だったが、その7件が読み込んだトークン数は全体の約83%を占めていた。短い質問を何度も繰り返す用途より、大きなコードファイルやツールの実行結果を読み込むAIエージェントの方が効果を得やすい構成といえる。
つまり、一般的な推論ソフトと比較して「回答生成が速くなった」と感じても、その改善をiPhone追加による効果とみなすことはできない。iPhoneを加えた効果を確かめるには、同じBackburnerを使い、同一の入力条件でiPhoneの有無を比較する必要がある。
64Kを超えると、iPhoneは過去の文脈を保持する
文脈が64Kを超えると、iPhoneの役割が変わる。モデル後半の計算を担当するのではなく、古い文脈のKVキャッシュを保持し、その部分を参照する計算を引き受ける。Macはモデルの全64層を処理し、過去の文脈に対応するKVキャッシュの一部をiPhone側へ移す。
KVキャッシュは、過去の入力を参照するときに再利用する計算結果を保持する仕組みで、会話が長くなるほど必要なメモリ容量が増える。iPhoneは古いKVキャッシュを保存するだけでなく、その部分に対するAttentionの計算も担当し、その結果をMac側の計算結果と統合する。
入力処理ではiPhoneのGPUを使い、回答生成時にはNeural Engineも一部の計算を担当する。すでに確定した過去のKeyとValueを、Neural Engine向けモデルの固定重みとして扱うことで処理を分担する設計だ。
開発者の構成では、24GBメモリのMac単体で実際に動作を確認できた8ビットの文脈長は64Kだった。iPhoneを追加すると、128Kまで8ビットで動作することを確認している。一方、起動時のiPhoneの空きメモリ量から算出される196K〜229Kという値は、実際に動作確認した文脈長とは区別する必要がある。140Kで行われた別のテストでは、文脈を4ビットに量子化している。
モデルの重みを圧縮するIQ4_XSと、ここでいう文脈の8ビット・4ビット量子化も別の設定である。64Kを超える条件の速度比較では、Mac単体が4ビット、iPhone追加時が8ビットとなっているため、完全に同じ条件での高速化比較とはいえない。
iPhoneを追加する利点は、処理速度だけでなく、より高い精度を保ったKVキャッシュをMacのメモリ外へ分散できる点にもある。ただし、それだけで回答品質が向上したと証明されたわけではない。
128Kのテストでは、文脈内の離れた位置に埋め込んだ3件の情報をすべて取り出せたという。140Kでは、Mac単体で処理した場合と一致する32トークンの出力も確認している。いずれも開発者による限定的なテストであり、長い資料のどの位置にある情報でも正確に参照できることを保証するものではない。
Mac側のNeural Engineは、この実装では利用していない。開発者の試験では、有効にすると回答生成が26%遅くなったといい、GPUと共有するメモリ帯域が原因だと説明している。利用できる演算器を増やせば必ず高速化するわけではなく、メモリ帯域や処理の分担まで含めて設計する必要があることを示している。
iPhoneを計算資源として占有する必要がある
Backburnerはコードと導入手順が公開されているプレリリース版で、App Storeでの提供は今後の計画に含まれている。Mac側で必要となるモデルなどのダウンロード容量は約24GB、iPhoneに保存するモデル後半のデータは約5.1GBある。USB-Cで接続するだけでは使えず、専用アプリの導入とモデルデータの準備も必要になる。
導入方法としては、Xcodeからビルドする方法とAltStoreを使う方法が用意されている。無料のAppleアカウントでも、Xcode経由でインストールしたアプリが約6GBのメモリを利用できることを開発者は確認している。ただしAltStoreについては、メモリ使用量の上限を拡張する権限を維持できるバージョンを使う必要があり、開発者自身による導入確認はまだ済んでいないと明記されている。手順が公開されていることと、すべての導入方法で動作確認が終わっていることは別である。
利用中は、iPhone側のアプリを前面に表示しておく必要がある。特に64Kを超え、iPhoneがKVキャッシュの一部を保持している状態では、画面をロックしたりケーブルを抜いたりして15秒間応答がなくなるとサーバーが停止し、アプリを開き直してサーバーを再起動する必要がある。
短い文脈の入力処理でiPhone側に問題が起きた場合は、Macが処理をやり直せる。しかし、長い文脈でKVキャッシュの一部をiPhoneへ移した後は、同じようにMacだけへ処理を戻すことはできない。同時に処理できる要求も1件に限られる。
すでにMacと対応するiPhoneを所有し、長いコードや資料をローカルAIで扱っている人にとっては、手元の機材を使って入力処理の待ち時間を短縮できる興味深い実験だ。一方で、iPhoneを通常の電話として使う時間と、AIの計算資源やKVキャッシュの保存先として占有する時間は両立しにくい。
今後、複数の端末や導入方法で長時間の安定動作が確認され、iPhoneを占有する不便さよりも入力処理の短縮や文脈長拡大のメリットが上回るようになれば、24GBメモリのMacで扱えるローカルAIの用途を広げる選択肢になり得る。