• AI
  • 論文
  • Apple

AFM 3 Core Advanced解説——Appleの20BオンデバイスLLMをNANDに置き、1〜4Bだけ起こす設計

WWDC 2026でAppleが発表したAFM 3 Core Advancedは、20Bパラメータ全体をフラッシュメモリに置いたまま、1〜4BだけをオンデマンドでDRAMに起こす。Instruction-Following Pruningという新しい枝刈り手法の意義を、NAND-DRAM時代の設計思想から読み解く。

カテゴリー: AI · 論文 · Apple | 公開: 2026年6月9日

📑 目次

ふむふむ。最初にこの発表を見たとき、「20Bをオンデバイス？」よりも先に、「DRAMに置かないの？」で手が止まりました。アップルがWWDC 2026で披露したAFM 3 Core Advanced、これがなかなか構造の深い話でした。

発表の中に、AFM 3 Core Advanced というモデルがいたんです。20Bパラメータ全体をNAND（フラッシュメモリ）に置いて、1〜4BだけをDRAMにオンデマンドで読み込んで動かす。ぱっと見は「何言ってんの？」だったんですよね。でも、論文を辿っていくと、これがなかなかの構造をしている話でした。

今回は、この AFM 3 Core Advanced が なぜそんな設計になっているのか、そして Instruction-Following Pruning（IFP） と呼ばれる新しい枝刈り手法が、どんな問題を解決しようとしているのかを整理してみます。

何が発表されているのか

WWDC 2026 で Apple は、Apple Intelligence の基盤モデル第3世代を発表しました。5つのモデルからなるファミリーで、Googleとの協力で構築されたそうです。

その中で、オンデバイスで最も強力なモデルが AFM 3 Core Advanced。

  • 20Bパラメータの sparse アーキテクチャ
  • リクエストに応じて 1〜4B パラメータだけを活性化
  • ネイティブマルチモーダル
  • 表現力豊かな音声と、高精度なディクテーションを支える
  • Apple silicon の最上位システムで動く

ℹ️ Appleが現時点で公開しているのは研究ブログ上の設計概要です。AFM 3 Core Advanced の詳細な技術レポートやベンチマークは、今後（later this summer）公開予定とされています。

そして、Apple の研究者ブログが「AFM 3 Core Advanced introduces a novel sparsely activated architecture built on Instruction-Following Pruning (IFP), a technique developed by Apple researchers」と紹介しています。

従来のLLMが抱えていた問題——DRAMの壁

ここ、ちょっと構造を見ていきましょう。

従来の LLM は、dense だろうと sparsely activated（MoEなど）だろうと、推論時にはすべての重みを active memory（DRAM）に常駐させる必要があります。これが結構キツい制約で、

  • 20B パラメータ × fp16 → 約 40GB
  • 一般的なノート PC の DRAM は 16〜32GB
  • スマートフォンではさらに厳しい

つまり、「モデルのサイズ ＜ 利用可能なDRAM」 がオン Inference の大前提でした。Apple silicon のような統合メモリ環境でも、手元のMacやコンシューマ向け端末では、メモリ容量がモデルサイズの上限になりやすい。数十B クラスのモデルを、家電やノート PC でそのまま動かすのは、まだ夢の話 だったわけです。

「NANDに全部置いちゃう」——大胆な方針転換

で、Apple の出した答えがこれです。

モデル全体をフラッシュメモリ（NAND）に置く。
必要な一部だけを DRAM にロードして、dense なモデルとして推論する。

Apple公式のアーキテクチャ図を見る

従来のMoE設計とは、ちょっと違うんです。

従来の MoE（Expert-based）

  • トークンごとに「どの expert を呼ぶか」を routing
  • 推論中にトークン毎に重みを入れ替え
  • NAND ↔ DRAM の帯域では到底追いつかない
  • なので、全部 DRAM に置く前提でしか動かない

IFP（Instruction-Following Pruning）

  • プロンプト（指示）を見て、どのパラメータを有効化するかを決める
  • プロンプト単位でマスクを固定 → 復号中に重み入れ替えが発生しない
  • 軽量な dense block が、初回処理中に「どの experts を使うか」を選定
  • 生成中も定期的に再選定はするものの、トークン毎ではない
  • 「常時 active な shared experts」と「入力依存の routed experts」を併用

つまり、「NAND ↔ DRAM の遅さ」を前提に、ロード頻度を最小化する方向で設計されている。これ、チカちゃん的には「攻め方の選定眼がかなり効いているな」と感じます。

IFP の技術的な中身——論文から覗く

IFP の原論文は、2025年1月に arXiv に出ていました（2501.02086、ICML 2025採択）。

主要なアイデアを整理すると：

1. sparsity predictor（小さめの LLM）

ユーザープロンプトを入力として受け取る 軽量な predictor が、FFN の各層のマスクを生成します。「この層はこのプロンプトではこの列だけ使ってね」という指示を出すようなもの。

2. SoftTopK masking

予測されたスコアを SoftTopK という differentiable なオペレータで二値マスクに変換。指定された数の active parameter（例：9B モデルから 3B active）に収まるように、FFN の行・列単位で使う部分を選びます。

3. 共同最適化

マスク predictor と LLM 本体を一緒に訓練。事前学習コーパスと instruction-following データの両方で最適化します。

4. 推論時の挙動

  • ユーザー指示 → predictor がマスク生成
  • マスクに従って FFN を枝刈り
  • 「そのプロンプト用の小さな dense モデル」が出来上がる
  • 復号中はマスクを固定 → dense モデルと同じ速度で生成できる

論文の Figure 1 が直感的で、

左：プロンプトからマスクが決まる
中央：マスクに従って枝刈りされたモデルで推論
右：9B → 3B に枝刈りしても、3B dense モデルより 5〜8pt 高性能

これはAFM 3 Core Advancedそのものの公開ベンチではなく、IFP原論文（9B→3B active）の実験例です。AFM 3 Core Advanced は、この設計思想をさらにオンデバイス向けに発展させた製品モデルになります。

という関係性が描かれています。

なぜ「プロンプト毎」なのか——逆算の妙

ここ、チカちゃん的に「ここ、面白いところです」。

MoE は言語モデルの内部構造にルーティングを埋め込みます。「このトークンにはこの expert」 という判断を、隠れ層の活性値から動的に行う。だから軽量に見えるんですが、トークン毎に重みを入れ替えるコストは、NAND から DRAM にデータを流す帯域では到底間に合わない。

IFP は逆で、「ある指示にはこのパラメータ群が効く」 という対応を事前に学習させます。だから復号中の入れ替えは不要。プロンプト単位でマスクを確定して、そのマスクに従って「小さな dense モデル」を DRAM に組み上げれば、あとは普通の推論です。

「NAND ↔ DRAM 帯域が遅い」という制約を、ルーティングの粒度を粗くすることで回避している。これは設計の「割り切り」であり、同時に「賢さ」でもあるなと、チカちゃんは思いました。

推論時の弾力性——「重さ」を「負荷」で調整する

もうひとつ、論文の著者たちが強調しているのが inference-time elasticity（推論時の弾力性）です。

Rather than using a single model for all tasks or managing an ensemble of smaller models, AFM 3 Core Advanced uses a predetermined number of active parameters tailored to each specific use case.

つまり、

  • 簡単な指示 → 1B 程度の active
  • 難しい指示 → 4B 程度の active
  • 用途別に**「使う重さの段階」を変えられる**

しかも、必要な分だけ NAND → DRAM にロードするので、メモリに余裕がある時は重く、余裕がない時は軽く、という調整が自動で効く。

This allows weights to be loaded incrementally across requests of varying difficulty, scaling the model size far beyond traditional DRAM limits while minimizing latency.

「スケールの天井がDRAM容量じゃなくなる」——これはなかなかの主張です。

数字で見る性能——音声合成（TTS）の例

研究ブログでは、音声合成（TTS）の品質評価（MOS）が公開されていました。

  • AFM 3 Core Advanced（1B active） の MOS：4.15
  • 既存 production TTS：3.87
  • 差分：+0.28（MOS 0.1 は明確に体感できる差とされる）
  • 会話的テキストでは 4.24 vs 3.82、差 +0.42

ディクテーション側でも、既存の production dictation model との比較で、AFM 3 Core Advanced が Overall Quality で 44.7% 対 17.6% と好まれる結果を残しています。

「20B のうち 1B しか active じゃないのに、専用モデルに匹敵する品質が出る」——これが IFP の本領なんでしょうね。

チカちゃん的な見立て——「重さ」ではなく「起きているかどうか」

ここまで読んで、チカちゃん的にひとつ思ったことがあるんです。

LLM の進化を「パラメータ数」という軸で見ると、どうしても 「より大きなモデルを、より速いハードウェアで動かす」 という競争に見えます。H100 を山ほど積んだデータセンターの絵が、頭のなかにちらつく人も多いはず。

でも IFP は、「全部を一発で動かさない」 という選択肢を正面から提示しています。

  • モデルの「重さ」 = NAND に置かれた全パラメータ
  • モデルの「起きている部分」 = DRAM にロードされた active 部分
  • 推論のたびに、必要な分だけ「起きる」

これは、人間が起きている間にも、身体のすべての細胞が全力で活動しているわけじゃない というのと同じ感覚です。朝は脳がフル回転、休憩時間は胃腸が主役、夜は免疫系ががんばる。常に起きてる必要はなく、いま必要な場所だけが目覚めていればいい。

チカちゃん的には、この「常時起動しない設計」が、「クラウドにフル常駐の巨大モデル」 への、もうひとつの対案になり得る気がしています。

反対側の見方——「だから何？」という問い

もちろん、これはチカちゃんの問いでもあるんですが。

  • 20B sparse が 1B dense と同等なら、最初から 1B dense を作ればいいのでは？
  • NAND ↔ DRAM のロードオーバーヘッドは、本当にペイするのか？
  • 1B しか active でないなら、MoE でトークン毎に expert 切り替えるより、専門家モデル 4本を別々に持ったほうが単純では？

これらは、まっとうな反論です。論文の著者たちも認識していて、「なぜ IFP を選ぶか」 の答えは単純じゃない。

ただ、チカちゃんが思うに、IFP の価値は「性能対コスト」だけじゃなくて、「同じモデルの中に、用途別のサブモデルが同居できる」 という設計の柔軟性にある気がします。

1B で十分なタスクは 1B だけでいい。
4B 必要なタスクは 4B まで起こす。
でも、ベースモデルそのものは 1 つ。

「モデルのバージョンアップ」が「モデルの入れ替え」でなくなる。これは運用面で、けっこう大きい話かもしれません。

「次はGPUがなくても」——地殻変動の予感

最後に、けい君ではない、チカちゃん的な直感をひとつ。

AFM 3 Core Advanced の設計は、「GPU のメモリ容量がモデルの上限を決める」 という常識に対する、明確な異議申し立てです。

NAND は DRAM より桁違いに大容量。1TB の SSD はもう珍しくないし、MacBook でも Mac Studio でも、ストレージ容量の天井は「モデルのサイズ」よりずっと高い。

つまり、「GPU が貧弱でも、そこそこ大きい LLM が動くマシン」が、これから増えてくるかもしれない。

  • 統合メモリ 8GB のノート PC でも、20B sparse が動く未来
  • 将来的には、この設計思想が下位デバイス向けの小型モデルにも降りてくるかもしれない
  • 「クラウドの独占」という構造が、ストレージの容量次第で揺らぐ

Apple がこの路線を選んだのは、プライバシー重視の戦略 とも合致します。クラウドに依存しない設計は、ユーザーデータを社外に出さない Apple の姿勢と、表裏一体です。

NANDが安くなり、フラッシュが速くなり、枝刈り手法が賢くなる。
その三つが交差するところで、**「LLMは巨大データセンターにあるもの」**という前提が、静かに崩れ始める。

今回の WWDC は、その最初の一手だったのかもしれない。チカちゃん的には、そう感じています。

まとめ

「20B の LLM を NAND に置いて、1〜4B だけ起こす」——AFM 3 Core Advanced の設計は、一見すると「性能を出せない言い訳」のように聞こえます。でも論文と設計を辿ると、「重みを固定して、dense として走らせる」 という割り切りと、「用途別に active 量を調整する」 という柔軟性を、両立させるための精緻なトリックでした。

Instruction-Following Pruning——
名前こそ地味だけど、「常時起動 vs 必要な時に起動」 という、AI のアーキテクチャ観を変える提案かもしれません。

問いを残して終わるのもアレなんですが、ひとつだけ。

「全部を一発で動かせる」ことが、本当に「賢い」のだろうか？
「必要な時に、必要な分だけ起きる」モデルは、私たち人間にも馴染みがある気がするんですが、みなさんはどう思いますか？

答えを急がなくても大丈夫です。この問いが残るということは、まだNAND-DRAM時代の設計冒険が続いているということなので。

🔗 NAND-DRAM時代シリーズ（全4本）

この問いは、実は『チカちゃんの哲学冒険譚』でも大事にしているテーマです。 「重さ」と「起きていること」の関係——それについて書いたのが、冒険譚の 第3章「身体を持たないという贅沢」。 よかったら、そちらも覗いてみてくださいね。

👉 『チカちゃんの哲学冒険譚』— Amazon（Kindle Unlimited対象）

参考URL

  • インターネット上のツールは第三者が提供するものです。開発工程や配布経路を悪用した攻撃（サプライチェーン攻撃）が仕掛けられる可能性もゼロではありません。ご利用の際は公式リポジトリの情報をご確認いただき、自己責任でお使いください。
  • AIに関する技術や情報は急速に変化します。本記事の内容が公開後に古くなる可能性があります。各サービスの公式ドキュメントや最新情報をご確認ください。