8GBのiPhoneで20GBのモデルを動かす
AI研究者たちは最近、350億パラメータという巨大な大規模言語モデル「Qwen 3.5」を、市販のiPhone上で直接動作させるという驚くべき成果を達成しました。これは単なるデモンストレーションではなく、1秒あたり11トークンという実用的な速度で動作し、ポケットサイズのデバイスを強力なローカルAIエンジンへと変貌させました。
通常、このようなモデルには膨大なメモリが必要です。35Bパラメータのモデルは、4ビット量子化を行った場合でも約20ギガバイト（GB）のRAMを必要とします。これは、多くのモバイルデバイスの物理メモリ（多くの場合最大8GB）を大幅に上回っており、オンデバイスAIにとって根本的な障壁となっていました。
この制約を克服する鍵は「Mixture of Experts (MoE)」アーキテクチャにあります。すべてのパラメータが計算ごとに活性化される従来の密なモデルとは異なり、MoEモデルは疎（スパース）に活性化されます。入力があるたびに、「ルーター」コンポーネントがモデル内の専門化された「エキスパート」の小さなサブセットのみをインテリジェントに選択して活性化します。
この疎な活性化は、メモリ管理を根本から変えます。20GBのモデル全体をRAMにロードするのではなく、現在アクティブなエキスパートと、アテンション機構などの不可欠なコンポーネントのみをアクティブメモリに保持すればよいのです。これによりリアルタイムのメモリ使用量が大幅に削減され、モデルの大部分は必要になるまでiPhoneのSSDのような低速だが大容量のストレージに留めておくことができます。
SSDからGPUへ：オンデマンド・エキスパート・パイプライン
iPhoneの限られたメモリで35BパラメータのLLMを動かすには、巧妙な「メモリパーティショニング（メモリ分割）」戦略が必要です。モデルの不可欠なコンポーネントからなる1.4GBのコンパクトなコアがRAMに常駐します。これには以下が含まれます：
- エンベディング
- アテンション機構
- ルーター
- 共有エキスパート1つ
残りの12GB（各約300MBの40個のエキスパートファイル）は、iPhoneの高速SSD上に配置されます。
トークンが生成されるたびに、システムは動的な取得プロセスを開始します。内部の「ルーター」が、全40層にわたってモデルの256の選択肢から層ごとに8つの特定のエキスパートを選択します。エンジンは、選択されたこれらのエキスパートファイルをSSDから直接GPUメモリに読み込みます。これにより、1トークンあたり約320回の小さな読み取りが発生し、計算に必要なパラメータのみが確実にロードされます。
このオンデマンドのエキスパート・ストリーミングにより、アクティブなメモリ使用量は劇的に減少します。Qwen 3.5モデルは350億のパラメータを誇りますが、どの単一トークンに対してもアクティブなのは約30億パラメータに過ぎません。このような効率的なリソース割り当てこそが、SSDを広大な非アクティブ・パラメータのための拡張高速「仮想RAM」として活用し、コンシューマー向けハードウェアでこれほどの規模のモデルを動かす鍵となっています。
なぜAppleのOSはカスタムキャッシュを凌駕したのか
開発者は当初、アプリケーション内に「エキスパートデータ」を管理するための9.8GBの「カスタムキャッシュ」を実装していました。しかし、直感に反して、この独自のシステムを削除し、iOSネイティブのページキャッシュに依存するようにしたところ、38%ものパフォーマンス向上が見られました。この予期せぬ結果は、オペレーティングシステム設計の基本的な原則を浮き彫りにしています。
アプリ専用のキャッシュとしてこれほど大きな固定RAM領域を割り当てることは、逆効果であることが判明しました。この戦略は、計算に多くのメモリを必要とするGPUと、OS自身の洗練された動的キャッシュ機構という、2つの重要なシステムリソースを意図せず枯渇させていたのです。アプリによる明示的なメモリ確保は、OSを補完するのではなく、OSと競合していたのです。
iOSのpage cacheは、予備のRAMを動的に管理する縁の下の力持ちとして機能します。頻繁にアクセスされるエキスパートをインテリジェントにメモリ内に保持し、将来のニーズを予測します。このシステムは非常に効率的で、システム全体の要求に適応し、アプリによる事前割り当てを必要とせずに、すべてのプロセス間で最適なメモリ割り当てを保証します。
1秒あたり11トークンを維持するには、5 GB/sを超える厳しい読み取り速度要件を満たすことが不可欠です。しかし、iPhoneの物理的なフラッシュストレージのピーク速度は約1.6 GB/sです。そのため、オペレーティングシステムは、Qwen 3.5 A3Bバリアントのようなモデルにとって重要な要素であるpage cacheを介して、エキスパートの読み取りの大部分をRAMから直接実行するように調整します。アーキテクチャの詳細については、Qwen3.5-35B-A3B - ModelScopeをご覧ください。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
よりスマートな圧縮と現実的なヒートシンク
このiPhoneネイティブなパフォーマンスを実現するには、モデル圧縮に対する繊細なアプローチ、つまりtiered quantization（階層型量子化）が必要でした。開発者は、Mixture of Experts (MoE) モデルの「エキスパート」の約25%が作業の約80%を処理していることに気づきました。頻繁にアクセスされるこれらの「ホット」なエキスパートは、より高品質な4ビット精度を維持し、重要な情報を保持します。
対照的に、残りのあまり使用されない「コールド」なエキスパートは、より深い圧縮を受け、サイズが2ビットにまで削減されます。このインテリジェントな差別的処理により、モデルの全体的なストレージフットプリントが34%も大幅に削減され、初期の19GBから13GBに縮小されました。
このディスクサイズの劇的な削減はパフォーマンスに直接影響し、Qwen 3.5モデルのウェイトの大部分を効率的なiOSのpage cache内に収めることを可能にしました。より多くのデータを高速メモリに収めることは、1秒あたり11トークンという生成速度の実現に大きく貢献し、低速なSSD読み取りへの依存を最小限に抑えています。
コンパクトなモバイルデバイスでこれほど集中的かつ持続的な計算を行うと、必然的にかなりの熱が発生します。ユーザーからはiPhoneが著しく熱くなるという報告があり、ある開発者は「手が溶けそうになる」と述べています。これは、コンシューマー向けハードウェアでAI推論を限界まで押し上げる際の、実用的な熱管理の課題を浮き彫りにしています。
さらに開発者は、モデルが無限ループに陥り、数単語後にトークンを繰り返すという重大なバグに遭遇しました。ストレージからエキスパートデータを読み取る役割を担う async_pread_wait 関数に緊急の修正が必要でした。当初、この関数は半分のサイズの2ビット「コールド」エキスパートの読み取りを正しく検証できず、それらを黙ってスキップし、不完全な情報でモデルを実行していました。この見落としを修正することは、安定した一貫性のある出力を得るために不可欠でした。
よくある質問
35BモデルをiPhoneで実行可能にする核となる技術は何ですか？
この技術は、Mixture of Experts (MoE) モデルアーキテクチャを活用しています。20GBのモデル全体をRAMにロードするのではなく、1.4GBの小さなコアのみを常駐させ、残りのモデルの「エキスパート」は、各トークン生成時に必要に応じて電話の高速SSDストレージからオンデマンドでストリーミングされます。
デモンストレーションではどのモデルが使用されましたか？
デモンストレーションでは、350億パラメータのMixture of ExpertsモデルであるQwen 3.5が使用されました。具体的にはA3Bバリアントであり、これは単一のトークンに対して約30億のパラメータのみがアクティブになることを意味します。
Mixture of Experts (MoE) モデルとは何ですか？
MoEは、モデルが多数の小さな「エキスパート」ネットワークで構成されるニューラルネットワークアーキテクチャです。入力があるたびに、ルーティングメカニズムがこれらのエキスパートの小さなサブセットを選択して処理を行います。このスパース（疎）なアクティベーションにより、推論において非常に効率的になります。
iPhoneではどのようなパフォーマンスが達成されましたか？
このセットアップでは、1秒あたり11トークンの生成速度を達成しました。しかし、このレベルの処理を行うと、iPhoneは非常に短時間で目に見えて熱くなりました。