注記: 本記事の調査（M5 Pro / M5 Max の Fusion Architecture、パッケージング技術、実測メモリ帯域、および Qwen 系のローカル推論ベンチの突き合わせ）には、Claude と、そのリサーチ機能を利用しています。パッケージング周辺は Apple 非公開の部分が多い領域です。参考にされる場合は、必ず一次情報で確認してください。本記事は2026年7月時点の情報をもとにしています。
はじめに
いま Macbook pro M5 Max（128GB）を注文して、届くのを待っているところです(納期8月)。せっかくなので待っている間に M5 Max について調べていたのですが、そこで いまさらながら、M5 Pro / M5 Max が「2つのダイを1パッケージに結合した構成」になっていることを知りました。Apple はこれを Fusion Architecture と呼んでいます。
ここで少し引っかかったのが、ユニファイドメモリ（Unified Memory）を看板にしているのに、中身は2ダイ構成 という点です。半導体業界の片隅にいる人間として、次のような心配が頭をよぎりました。
ダイを2枚に分けたら、ダイをまたぐメモリアクセスで NUMA 的なペナルティが出るのではないか。単一プールに見えている Unified Memory は、本当に壊れていないのか。
ちょっと気になったので、公開資料・各社の解説・そして発売から数か月ぶんの実測ベンチをあたって処理モデルを分解してみた、というのが本記事です。なお、メモリコントローラやサブブロックのダイ間分割といった内部実装は Apple が完全公開しているわけではありません。ですので本記事は「内部を暴く」ものではなく、公開情報・分解記事・観測できる仕様から、メモリアクセス経路を推定して理解するものだとご理解ください。
何が変わったのか ─ Fusion Architecture
M5 世代は少し変則的なリリースになっています。ベースの M5 は2025年10月に登場し、これは従来と同じ 単一ダイ（モノリシック） のチップでした。一方の Pro / Max は2026年3月に別途発表され、ここで初めて Fusion Architecture という新しいパッケージング構成が導入されました。
Fusion Architecture の要点は、第3世代 3nm（N3P）のダイを2枚、高帯域・低レイテンシの相互接続で1つの SoC に統合する ことです。2枚のダイが合わせて CPU・GPU・Media Engine・Neural Engine・Unified Memory コントローラ・Thunderbolt 5 を構成します。
メモリ構成は以下のとおりです（いずれも理論最大帯域）。
| チップ | 構成 | 最大 Unified Memory | 理論最大帯域 |
|---|---|---|---|
| M5（base） | 単一ダイ | 32 GB | 153.6 GB/s |
| M5 Pro | 2ダイ | 64 GB | 307 GB/s |
| M5 Max | 2ダイ | 128 GB | 460 GB/s（32-core GPU）／ 614 GB/s（40-core GPU） |
UltraFusion とは何が違うのか
「2ダイ結合」と聞くと、M1/M2/M3 Ultra で使われた UltraFusion を思い出す方も多いはずです。しかし思想はかなり違います。
- UltraFusion（Ultra 系）: 完成された 同一の Max ダイを2枚、シリコンインターポーザ（約 2.5 TB/s の D2D）で貼り合わせ、2つの SoC を1つの大きな SoC に見せる方式です。いわば「対称なミラー結合」でした。
- Fusion（M5 Pro/Max）: CPU 主体タイル と GPU 主体タイル という、役割の異なる非対称なダイを組み合わせる方式です。
後者のポイントは SKU の作り分けにあります。CPU タイル（18コア = 6 super + 12 performance、Neural Engine、Media ブロック）を Pro / Max で共通化し、GPU ダイのサイズだけを変える（Max は Pro の約2倍）という設計です。同一ダイのミラー結合ではなく機能分割なので、歩留まりとバリデーションコストを同時に下げられます。これは AMD が Ryzen / EPYC でやってきたチップレット戦略と同じ物理ドリブンな発想で、Apple Silicon がついにその方向へ舵を切った、と読めます。
両者の結合思想の違いを図にすると、こうなります。
左は「完成した同一 SoC を2枚つなぐ」対称結合、右は「役割の違うタイルを組む」機能分割です。M5 は右側で、CPU タイルを共通化して GPU タイルだけ差し替えるのが SKU 戦略の肝になっています。
パッケージングの中身 ─ SoIC とハイブリッドボンディング
ここが今回いちばん腹落ちしたところです。心配の答えの半分は、実はパッケージング技術にあります。
Fusion Architecture のダイ間結合には、TSMC の先進パッケージングが使われています。アナリスト（Ming-Chi Kuo）の事前予測や複数の解説では SoIC-mH（molding horizontal、モールド水平型のハイブリッドボンディング）とされてきました。その後の TechInsights による実際の分解では、SoIC-X の F2F（face-to-face）チップオンウェハをシリコンインターポーザ上に載せる構成だと報じられており、正式な TSMC 呼称や細部は分解記事で詰められている段階です。呼称の揺れはあるものの、技術の核は共通しています。
その核とは、従来のはんだマイクロバンプではなく バンプレスのハイブリッドボンディング（Cu-Cu 直接接合）でダイ同士をつなぐ、という点です。これにより次のことが起こります。
- ダイ間の配線密度が桁違いに上がる。
- 相互接続の寄生（parasitics）が減り、チップレット化にありがちな「モノリシックより効率が落ちる」問題を大きく緩和できる。
- 結果として、D2D 相互接続がオンダイ配線に近い電気特性に近づく。
つまり「2ダイに割ったのに、ほぼ1枚のように振る舞える」のは、この接合技術があってこそ、というわけです。歩留まりの観点でも、CPU ダイと GPU ダイを別々に製造・テストして良品同士を組み合わせられるため、830 mm² のレチクル限界に近い巨大モノリシックを焼くより有利になります。
パッケージングを世代で並べると、位置づけが見えやすくなります。
| 世代 | 方式 | ダイ構成 | ダイ間接続 | D2D 帯域 |
|---|---|---|---|---|
| M1〜M4 Pro/Max | モノリシック | 単一ダイ | ─（1枚） | ─ |
| M1/M2/M3 Ultra | UltraFusion | 同一 Max ダイ ×2 | シリコンインターポーザ（マイクロバンプ） | 約 2.5 TB/s |
| M5 Pro/Max | Fusion | CPU タイル + GPU タイル | バンプレス Cu-Cu ハイブリッドボンディング（SoIC 系） | 非公開 |
| ベース M5 | モノリシック | 単一ダイ | ─（1枚） | ─ |
ただし、ここで正直に言っておくべき点があります。ダイ間相互接続（D2D）の帯域そのものの数値を、Apple は公開していません。UltraFusion では約 2.5 TB/s という数字が出ていましたが、M5 Fusion に関しては公称値がなく、分解記事でも接合ピッチ・密度の解析が進んでいる段階です。したがって「D2D がメモリ帯域より十分広い」というのは、設計として妥当だという推定であって、公称スペックで裏が取れているわけではありません。
素朴な疑問：2ダイでメモリアクセスは困らないのか
改めて本題です。ダイを2枚に割ると、当然こういう懸念が出てきます。
片方のダイのコアが、もう片方のダイに接続された DRAM を読みに行ったら、クロスダイの追加レイテンシと、ダイ間リンク（D2D）の帯域消費が発生するのではないか。
これは正しい直感で、チップレット／マルチダイ設計における最大のエンジニアリング課題そのものです。PC 側の一般的なマルチダイ（Intel の Foveros、AMD の chiplet）では、CPU と GPU を別エンティティとして扱い、それぞれ独立したメモリプールを持たせ、開発者が明示的にデータ配置と転送を管理する必要があります。まさに NUMA の世界で、AMD EPYC で NPS を設定したりスレッドをピン留めしたりする、あの世界です。
物理トポロジを模式化すると、次の構造になります。各サブブロックの正確な分割は Apple 非公開なので、あくまで妥当な推定モデルとしてご覧ください。
各ダイは物理的には 自分側のメモリコントローラと LPDDR を持ちます。したがって物理レイヤーには局所性が存在します。GPU 主体ダイのコアが CPU 主体ダイ側の DRAM を読みに行けば、そのトラフィックは D2D を経由します。ここが、クロスダイアクセスのコストが発生する場所です。
Apple はどう吸収しているのか
Apple が前面に出しているのは、Fusion Architecture が2ダイを単一 SoC に統合し、ソフトウェアからは従来どおり単一の Unified Memory として扱える、という点です。裏を返すと、クロスダイ時のレイテンシ、D2D 帯域、メモリ配置方式そのものは公開していません。したがって「単一プールに見える」までは公式に確認できますが、「クロスダイでもペナルティが一切ない」までを Apple の文言として断定するのは避けておきます。
一般論として、ディスクリート GPU 構成や一部のマルチダイ CPU では、物理的なメモリ局所性や転送コストがソフトウェア最適化の対象になりやすい、という違いがあります（ただし AMD EPYC の NUMA、Intel のタイル、dGPU の VRAM、APU の共有メモリはそれぞれ事情が異なるので、ひとくくりにはできません）。ざっくり整理すると次のようになります。
| 型 | メモリの見え方 | ソフト側の負担 | 代償 |
|---|---|---|---|
| 一般的な dGPU / 一部マルチダイ CPU | 局所性・転送コストが見える場合がある | データ配置やピン留めが最適化対象になりうる | ソフトの複雑さ |
| Apple Fusion 型 | ソフトからは単一プールに見える（HW が隠蔽） | 明示的配置は基本的に不要 | 相互接続の帯域・パッケージングコスト |
前章のハイブリッドボンディングによって D2D をオンダイ配線に近づけ、その上で単一アドレス空間を維持する。この二段構えで、非均一性を「実用上ほぼ見えない」ところまで抑え込んでいる、というのが妥当な読み筋です（ただし後述のとおり、どこまで抑えられているかの定量は非公開）。なお M5 Pro / Max では、常時オンのメモリ安全機構「Memory Integrity Enforcement（MIE、ARM EMTE ベース）」も新規に入っています。
GPU 側と CPU 側の DRAM は同時に読めるのか ─ 並列アクセスとクロスアクセス
ここは実機を注文してから特に気になった点です。DRAM が2つのダイに分かれて接続されているなら、GPU 側 DRAM と CPU 側 DRAM を同時に読めるのか、そしてクロス（片側ダイが反対側の DRAM を読む）も同時に成立するのか。順に整理します。
まず物理構成の確認です。614 GB/s は、パッケージ全体として見た Unified Memory 帯域の公称上限であり、Apple が公表しているのはこの合算値までです。物理的には複数のメモリチャネルが2ダイ側に分散している可能性が高いものの、どのチャネルがどちらのダイに属し、アドレスがどの粒度でインターリーブされるかは Apple 非公開です。機能分割については、Ars Technica の分析で ダイ1 ＝ CPU + Neural Engine + SSD/Thunderbolt、ダイ2 ＝ GPU とされ、Pro/Max はダイ1を共通化し GPU ダイのサイズだけ変えている、と報じられていますが、メモリコントローラを何本ずつどちらに置いたかまでは示されていません。
したがって以下の図と表は、実装そのものではなく「物理的な局所性を考えやすくするための推定モデル」だとご理解ください。その推定モデルの上で、アクセスパターンごとに帯域の上限を整理すると次のようになります。
| アクセスパターン | 経路 | 帯域の上限 | 位置づけ（推定） |
|---|---|---|---|
| 各ダイが自ダイ側 DRAM を同時アクセス（並列ローカル） | 各ダイのメモリチャネル | 合算で最大 ≈ 614 GB/s | 公称帯域を並列ローカルで説明した場合の理想ケース |
| 片側ダイ → 反対側ダイの DRAM（クロス片方向） | D2D 経由 | D2D 帯域が上限（非公開） | ローカルと同時併走は可 |
| 双方向クロス（両ダイが互いの DRAM を同時） | D2D（双方向） | D2D の双方向容量が上限（非公開） | 重いと D2D がボトルネックになりうる |
読み取れることは3つです（いずれも上記の推定モデルを前提とした解釈です）。
- GPU 側と CPU 側の DRAM の同時アクセスは、原理的にできます。マルチチャネルのメモリは各ダイのコントローラが自分側のチャネルを並列に叩いて合算帯域を出すのが一般的で、両ダイのチャネルが同時に動く状態が公称 614 GB/s を素直に説明します。ただし「その並列ローカルが D2D をまったく使わない」と言い切れるのは、局所性を優先した非インターリーブ配置だった場合に限られ、実際の配置は非公開です。
- クロスも同時にできます。ローカル（メモリチャネル）とクロス（D2D リンク）は経路が別なので併走し、双方向クロスも D2D が双方向なら成立します。
- ただし、クロストラフィックはすべて有限の D2D を共有します。したがって「同時クロスをどこまで出せるか」は D2D 帯域が上限で、その D2D 帯域を Apple は公開していません。D2D がメモリ帯域より狭ければ、重い同時クロスは D2D で頭打ちになります。
ここで一段深い論点があります。GPU 単体が 128GB 全域を 614 GB/s で読めるのか、という点です。もしアドレスがダイ境界をまたいでインターリーブ（全チャネルに均等ストライプ）されているなら、GPU が大きなバッファを読むだけで両ダイの DRAM を並列に引き、そのうち反対側ダイぶんは常に D2D を通ります。つまり「GPU は GPU 側 DRAM、CPU は CPU 側 DRAM」という素朴な棲み分けではなく、大きなアクセスは常に両ダイにまたがる、という描像になります。図にするとこうです。
この描像だと、D2D はメモリ帯域に匹敵するほど太くないと成立しません。逆にインターリーブせず局所性を優先する設計なら、単一エージェントはローカルの約半分（≈307 GB/s）しか引けないことになります。
（上図はいずれも、実装ではなく物理的局所性を説明するための推定モデルです。）
Apple はソフトウェアから単一 SoC／Unified Memory として扱えることを前面に出していますが、クロスダイ時のレイテンシ、D2D 帯域、メモリ配置方式は公開していません。識者からも「二枚のダイをまたいでメモリがどう動くのかの技術詳細は明かされていない」「クロスダイのレイテンシ主張は独立検証待ち」と指摘されています。
傍証としては、STREAM や LLM の実測が1タイル相当（≈307 GB/s、ちょうど M5 Pro の値）を超えている以上、単一エンジンが両ダイ側の帯域を使えている可能性が高い、とは言えます。ただしこれは「証明」ではなく「傍証」にとどめます。tok/s から実効メモリ帯域を逆算するのはかなり難しく、MoE では全パラメータではなく活性 expert が主に効くうえ、量子化形式・ランタイム・KV cache・Metal/MLX の実装・prefill/decode の分離で大きく変わるためです。
したがって現時点での正直な結論はこうです。並列ローカルもクロスも原理的には同時に成立しうる。公称 614 GB/s は並列ローカルで素直に説明でき、単一エンジンがそこに届く可能性は高いが、それがインターリーブ由来か（＝常時クロスが発生しているか）は公開情報からは断定できない。そして同時クロスの上限＝ D2D 帯域そのものは非公開のため、最悪ケースの数値は確定できません。ここは実機で切り分けて測るしかない領域です。
理論帯域と実測帯域 ─ 614 GB/s は本当に出るのか
心配のもう半分は「そもそも公称帯域どおり出るのか」でした。ここは実測を当たると、少し注意が必要なことがわかります。
独立系の STREAM ベンチ（CPU 側の持続帯域）では、M5 Max は概ね 350 GB/s 前後という報告があります（Mubashir Rahim の計測）。これは M4 Max より約13%高く、CPU 側では M3 Ultra すら上回る値ですが、理論最大の 614 GB/s と比べるとだいぶ低く見えます。
ここで誤読しないよう、はっきりさせておきます。STREAM が測っているのは CPU 側の持続帯域です。ローカル LLM 推論は基本的に GPU / Neural Accelerator 側で走り、そちらは 614 GB/s のプールをより大きく引き出せます。つまり「CPU STREAM で 350 GB/s しか出ない=LLM も 350 GB/s 相当」ではありません。LLM の実効帯域は、後述の tok/s 実測のほうが素直な指標になります。理論値はあくまでプール全体の上限であり、どのエンジンが・どんなアクセスパターンで叩くかで実効値は変わる、と捉えるのが正確です。
ローカル LLM の実効性能 ─ M5 Max の実測値で見る
いちばんの関心事はここです。トークン生成（decode）は バッチサイズ1では帯域律速 で、1トークンごとにモデル重みをメモリから読み出すため、tok/s はおおむねメモリ帯域に追従します。式で書くと、上限はこう表せます。
$$
\text{tok/s の上限} \approx \frac{\text{実効メモリ帯域}}{\text{1トークン生成で読む重みサイズ}}
$$
分母は、dense なら（ほぼ）全パラメータですが、MoE では活性した expert 分だけになります。
$$
\text{読む重みサイズ} \approx \text{活性パラメータ量} \times \text{量子化後の byte/parameter}
$$
つまり dense と MoE を同じ式で雑に比較してはいけない、というのがこの後の話の土台です。発売から数か月が経ち、M5 Max 実機での測定・報告がコミュニティに出そろってきたので、それらを（外挿ではなく）並べます。普段さわる Qwen 系を軸に、比較用として他アーキテクチャ（gpt-oss / Llama）も添えます。
まず MoE と dense の差を押さえます。MoE は総パラメータのうち一部の expert だけを毎トークン活性化するため、decode は 活性パラメータ数 に支配されます。一方でメモリ フットプリント は 総パラメータ数 で決まります。この「毎トークン、一部の expert だけが動く」様子を図にするとこうです。
太線の2つだけが毎トークン動き（＝活性パラメータ、decode 速度を決める）、点線の expert はメモリには載っているが今回は動きません（＝総パラメータ、フットプリントを決める）。つまり「活性は少ないが総量は大きい」大型 MoE ほど、速さ（活性が少ない）と容量要求（総量が大きい）が両立し、128GB がここで効いてきます。整理すると次のとおりです。
| 指標 | 何で決まるか | 効いてくるハード資源 |
|---|---|---|
| decode 速度（tok/s） | 活性パラメータ数 | メモリ帯域（614 GB/s） |
| メモリ フットプリント | 総パラメータ数 | メモリ容量（128GB） |
実際コミュニティでも「Apple Silicon では MoE を選べ」というのが定番の助言になっています。
M5 Max と M4 Max を同一条件で比べた例（集計サイト LLMCheck、64GB、Ollama 0.6 / MLX 0.24、Q4、いずれも生成 tok/s）。なお LLMCheck はコミュニティ提出をまとめたインデックスで、ページ上に推定値を含む旨が明記されている点は割り引いて見てください。
| モデル | 種別 | M5 Max | M4 Max | 差 |
|---|---|---|---|---|
| Llama 3 8B（Q4） | dense | 82 tok/s | 64 tok/s | +28% |
| Qwen3.5 30B-A3B（Q4） | MoE（活性3B） | 58 tok/s | 45 tok/s | +29% |
| Llama 4 Scout（Q4） | MoE | 32 tok/s | 25 tok/s | +28% |
| Llama 3 70B（Q4） | dense | 18 tok/s | 14 tok/s | +29% |
| Mistral 7B（Q8） | dense | 68 tok/s | 55 tok/s | +24% |
M5 Max 128GB 大型モデルの生成速度（decode）─ 実測・コミュニティ報告例。数値はランタイム・量子化・文脈長で大きく動くため、確定値ではなく「報告例」として扱ってください。
| モデル | 種別 | ランタイム / 量子化 | メモリ使用 | 生成 tok/s | ソース種別 |
|---|---|---|---|---|---|
| Qwen3.5-122B-A10B | MoE（活性10B） | mlx_lm / 4-bit | 約70 GB | 約41.5〜65.9 | 個人実測（Reddit）／紹介記事 |
| Qwen3-Coder-Next | MoE | mlx_lm / 8-bit | 約85〜90 GB | 約48〜79 | 個人実測（Reddit）／紹介記事 |
| gpt-oss-120B | MoE | mlx_lm / Q8・MXFP4 | 約64 GB | 約87.9 | 紹介記事（コミュニティ） |
| Qwen3.6-35B-A3B | MoE（活性3B） | MLX | ─ | 約55 | 集計サイト（コミュニティ MLX） |
| 7B 級 | dense | MLX / Q4 | ─ | 約95〜110 | 集計サイト |
| 70B 級 | dense | MLX / Q4 | ─ | 約25〜32 | 集計サイト |
同じ Qwen3.5-122B-A10B でも、紹介記事が引く Reddit 実測では 65.9 tok/s、別の Reddit 実測では TG128 で 41.5 tok/s と、報告によって1.5倍以上ばらつきます。これは量子化・文脈長・生成トークン数・ランタイム・KV cache 状態の違いによるもので、「M5 Max = 何 tok/s」と一意に言えるものではありません。上表はあくまで「この範囲で回っているという報告がある」という参照点です。
読み取れることを整理します。decode（生成速度）の M4 Max からの伸びは、報告により幅があります。Apple 公式の MLX 研究は +約20〜25%（帯域比 +約12% を上回るのは Neural Accelerator 等の寄与）、集計サイト LLMCheck は +28〜29%、別のコミュニティ計測では +10〜15% 程度と、おおむね +10〜29% のレンジに散らばります。いずれにせよ「劇的」ではなく「着実」というのが正直なところです。
推論には2つのフェーズがあり、律速要因が異なります。ここを分けて見ると M5 世代の変化点がはっきりします。
| フェーズ | 何をする | 律速要因 | M5 世代の効き方 |
|---|---|---|---|
| prefill（プロンプト処理） | 入力コンテキストを一括で読み込む | 演算（FLOPS） | Neural Accelerator 新設で大幅改善（Apple 主張で最大4倍） |
| decode（トークン生成） | 1トークンずつ重みを読み出す | メモリ帯域 | 帯域比（+約12%）に沿って着実（実測 +10〜29%） |
ここで用語を分けておきます。混同しやすいのですが、M5 世代には別物の2つがあります。
- Neural Accelerator: GPU コア1つ1つに内蔵された行列演算アクセラレータ（M5 Max なら40コア分）。M5 世代の prefill 高速化の主役はこちらです。
- Neural Engine: SoC 内の別ブロック（16コア）。Core ML や Apple 自身のアプリ推論では効きますが、MLX / llama.cpp の LLM 推論は基本的に GPU 上で走るため、これらのランタイムが Neural Engine を直接どこまで使うかはランタイム依存で、断定はできません。
M5 の本当の売りは prefill 側です。Apple 公式の MLX 研究でも、prefill（TTFT）の最大4倍は GPU コア内の Neural Accelerator によるもので、生成（decode）側は帯域律速のため +約20〜25% と、フェーズで効き方が分かれることが示されています（Qwen 系での測定、prompt 4096）。長文コンテキスト（大きなコードベースや論文の投入）で体感差が最も出るのはこの prefill です。
フレームワーク差も無視できません。MLX は Ollama / llama.cpp より 40〜80% 速いとされます。これは MLX が Metal 4 の Tensor 演算を介して GPU コア内の Neural Accelerator を活用でき、かつゼロコピーの unified memory を叩けるためで、Neural Engine を使うから速い、という話ではありません。いずれにせよ同じモデルでも計測値が大きく動くので、M5 Max で数字を出すなら MLX 前提で見るのが実態に合います。
用途面では、Qwen3-Coder-Next（コーディング MoE）が M5 Max で約80 tok/s 出るのは、エージェント的なコード生成に十分インタラクティブです。ただし速さと精度は別軸です。protocol の細かい正確さが要る用途（自分の場合は SV/UVM のコード生成）では、活性パラメータの少ない MoE より dense が有利、という感触を以前の検証でも持っています。128GB あれば大きめの dense もフットプリント的には載るので、「MoE で速く回す」と「dense で正確に書かせる」を用途で使い分けられる、というのが M5 Max 128GB を選ぶ実利だと考えています。
他プラットフォームとの比較 ─ fits と runs fast
最後に、ローカル LLM ハード選びで何度でも効いてくる 「載る（fits）」と「速く回る（runs fast）」は別問題 という観点で、主要プラットフォームを並べます。
| プラットフォーム | メモリ帯域 | 容量上限 | メモリ種別 | メモ |
|---|---|---|---|---|
| M5 Max（40-core） | 614 GB/s（理論）／STREAM実測 約350（CPU側） | 128 GB | LPDDR5X（unified） | ラップトップ。単ストリーム dense decode が得意 |
| M4 Max | 約546 GB/s | 128 GB | LPDDR5X（unified） | 前世代 |
| M3 Ultra | 約819 GB/s | 96 GB（2026・供給難で上限縮小／従来512GB） | LPDDR5X（unified） | デスクトップ。Apple 側では最速帯域 |
| DGX Spark / GB10 | 約273 GB/s | 128 GB | LPDDR5X | prefill・並列（concurrency）に強い。dense decode は約50 tok/s 級 |
| Ryzen AI Max+ 395（Strix Halo） | 約256〜273 GB/s | 128 GB | LPDDR5X | InFO-oS。帯域は控えめ |
| RTX 5090 | 約1,500 GB/s | 32 GB | GDDR7 | 速いが容量が小さい（fits に弱い） |
| RTX PRO 6000 | 約1,792 GB/s | 96 GB | GDDR7 | データセンタ級。高価 |
同じ内容を、容量（fits）と帯域（runs fast）の2軸マトリクスに置くと、各機の性格が一目で見えます。
| 容量 ＼ 帯域 | 低（≲300 GB/s） | 中（≈300〜700 GB/s） | 高（≳800 GB/s） |
|---|---|---|---|
| 大（128GB） | DGX Spark、Strix Halo | M5 Max、M4 Max | ─ |
| 中（96GB） | ─ | ─ | M3 Ultra、RTX PRO 6000 |
| 小（32GB） | ─ | ─ | RTX 5090 |
この表のいちばんのポイントは、右上の「大容量かつ高帯域」セルが（コンシューマでは）ほぼ空である、という点です。これがそのまま「fits と runs fast は両立しにくい」という構図です。大容量（128GB）を取ると帯域は中位までで、高帯域（≳800 GB/s）を取ると容量は 96GB 以下に落ちます。
その中で M5 Max は「大容量（128GB）× 中帯域（614 GB/s）」のセルにいて、M4 Max より右（帯域が高い）側です。128GB を保ったままラップトップで単ストリームの dense decode を速く回せる、というのが立ち位置になります。RTX 5090 は帯域は圧倒的ですが 32GB で大型モデルが載りません。DGX Spark は 128GB 載りますが 273 GB/s で decode が遅く、代わりに prefill と並列処理に強いという性格です。単ストリーム dense decode では、40-core M5 Max（614 GB/s）は DGX Spark（273 GB/s）に対して帯域比で約2.25倍の優位があります。ただし NVIDIA 側は Blackwell の NVFP4/MXFP4 でパラメータあたりのバイト数を半減でき、TensorRT-LLM / vLLM の成熟したサーバスタックと合わせると、この差は縮むか逆転しうる、という点も公平に添えておきます。右上（大容量かつ高帯域）に唯一近いのは RTX PRO 6000（96GB・1,792 GB/s）ですが、価格帯が別世界です。
補足として、2026年はメモリ供給難がハード選びの隠れた主役でもあります。この影響で Mac Studio M3 Ultra の 512GB / 256GB 構成は取り下げられ 96GB が上限になり、DGX Spark は約700ドル値上げ、といった動きが出ています。純粋なベンチ以前に、容量と価格の前提そのものが動いている点は頭に入れておくとよさそうです。
未確定事項と注意点
この記事は推定を多く含む領域なので、まず各主張を「どこまで確かか」で層別しておきます。
| 信頼度 | 内容 |
|---|---|
| 公式確認済み | Fusion Architecture、2ダイ構成、最大 614 GB/s、最大 128GB、各 GPU コア内の Neural Accelerator、prefill 最大4倍（Apple MLX 研究） |
| 分解・解析で確認 | SoIC-X F2F ハイブリッドボンディング、CPU/GPU チップレット構成（TechInsights） |
| 強い推定 | アドレスインターリーブの存在、D2D が実効帯域を支えていること |
| 未確定（非公開） | D2D 帯域、クロスダイ レイテンシ、メモリコントローラの分割、GPU 単体の全域帯域 |
そのうえで、はっきりさせておきたい点を挙げます。
- D2D 相互接続の帯域は Apple 非公開です。UltraFusion の 2.5 TB/s に相当する M5 Fusion の公称値はなく、「D2D はメモリ帯域より十分広いはず」は設計上の妥当な推定にとどまります。あわせて、メモリのインターリーブ方式（アドレスをダイ境界をまたいで均等分散しているか）も非公開のため、GPU 単体がフル帯域を引けるかや、同時クロスアクセスの上限は公開情報からは確定できません。
- どのサブブロックがどちらのダイに載っているか（メモリコントローラの正確な分割）も非公開で、本記事の内部配置図は推定モデルです。TSMC パッケージングの正式呼称（SoIC-mH か SoIC-X F2F か）も分解記事で詰められている段階です。
- STREAM の約350 GB/s は CPU 側の持続帯域であり、LLM が使う GPU 側の実効帯域とは別物です。理論値 614 GB/s と単純比較しないでください。
- LLM の tok/s は「実測確定値」ではなく「コミュニティ報告例」です。フレームワーク・量子化・文脈長で大きく動き（同じ 122B-A10B でも 41.5〜65.9 tok/s の幅）、Qwen3.6 系の M5 Max 実測もまだ 1〜2 件のコミュニティ報告にとどまります。実機の NUMA/クロスダイ特性を切り分けた測定も、これからです。
- 物理的には inter-die は on-die より必ず遅く、「無視できる」は「完全に同一」ではなく「実用上ほぼ気にならない水準に抑えた」の意です。
まとめ
- M5 Pro / Max は Apple Silicon 初の本格チップレットで、UltraFusion の「同一 SoC 結合」とは違い CPU タイル + GPU タイルの機能分割です。
- 「2ダイでメモリアクセスが困るのでは」への答えは、ソフトからは単一 Unified Memory として扱えること（公式確認済み）と、ハイブリッドボンディング（バンプレス Cu-Cu 接合）で D2D をオンダイ配線に近づけていること（分解で確認）の組み合わせです。ただし非均一性をどこまで抑えているか（D2D 帯域・レイテンシ）の定量は非公開です。
- 実測面では、CPU STREAM は約350 GB/s（CPU側）。LLM は M5 Max 実機のコミュニティ報告で、Qwen3.5-122B-A10B が約41.5〜66 tok/s、gpt-oss-120B が約88 tok/s と、128GB のラップトップで 120B 級がインタラクティブに回るという報告があります（数値は環境で大きく変動）。
- decode（生成）の M4 Max からの伸びは報告により +10〜29%（公式 MLX 研究では +20〜25%）で「着実」程度。M5 の本当の売りは prefill（プロンプト処理）で、Apple MLX 研究では各 GPU コア内の Neural Accelerator により最大4倍とされます。長文コンテキストで効きます。
- Qwen 系では MoE が decode で速く、大きな MoE のフットプリントを 128GB が受け止めます。速さ（MoE）と正確さ（dense）を用途で使い分けられるのが 128GB の実利です。
- 「fits vs runs fast」で見ると、M5 Max は 614 GB/s と 128GB の両立点。RTX 5090 は速いが容量小、DGX Spark は容量大だが decode 遅め（prefill/並列は強い）、という住み分けです。
- ただし D2D 帯域・ダイ分割・インターリーブ方式・正式なパッケージ呼称は非公開で、LLM 数値もコミュニティ報告例です。ここは実機が届いたら自分で測って更新します。
参考にしたリンク
- Apple Newsroom「Apple debuts M5 Pro and M5 Max」: https://www.apple.com/newsroom/2026/03/apple-debuts-m5-pro-and-m5-max-to-supercharge-the-most-demanding-pro-workflows/
- Apple M5 ─ Wikipedia: https://en.wikipedia.org/wiki/Apple_M5
- Apple Machine Learning Research「Exploring LLMs with MLX and the Neural Accelerators in the M5 GPU」（公式・prefill 最大4倍が GPU コア内 Neural Accelerator 由来、生成は帯域律速）: https://machinelearning.apple.com/research/exploring-llms-mlx-m5
- Om Malik「Apple Does Fusion.」（Ars Technica 分析経由・ダイ1=CPU/NE/IO とダイ2=GPU の機能分割、メモリ非公開の指摘）: https://om.co/2026/03/03/apple-does-fusion/
- Skorppio「Apple M5 Max vs NVIDIA DGX Spark」（単一プール・クロスダイ主張と独立検証待ちの明記）: https://skorppio.com/blog/apple-m5-max-vs-nvidia-ai-deep-dive
- TechInsights「Apple M5 Pro Package Analysis: TSMC SoIC-X F2F Hybrid Bonding」: https://www.techinsights.com/blog/apple-m5-pro-package-analysis-TSMC-hybrid-bonding
- TrendForce「Apple May Debut M5 Ultra ... N3P and SoIC-mH」: https://www.trendforce.com/news/2026/06/08/news-apple-may-debut-m5-ultra-powered-mac-studio-at-wwdc-boosting-demand-for-tsmc-n3p-and-soic-mh/
- Tom's Hardware「Apple ... TSMC's SoIC-mH (molding horizontal)」: https://www.tomshardware.com/pc-components/cpus/apple-rumored-to-kick-off-m5-chip-production-using-tsmc-performance-enhanced-3nm-node
- Notebookcheck「Apple M5 Max ─ Benchmarks and Specs」: https://www.notebookcheck.net/Apple-M5-Max-Processor-Benchmarks-and-Specs.1244918.0.html
- Mubashir Rahim「Apple's M5 Max Just Made My DGX Spark Benchmark Look Outdated」（STREAM 実測・tok/s）: https://medium.com/@mubashir_rahim/apples-m5-max-just-made-my-dgx-spark-benchmark-look-outdated-c860b920e9a1
- digitalapplied「DGX Spark vs M5 Max vs RTX 6000」（dense vs MoE / fits vs runs fast）: https://www.digitalapplied.com/blog/dgx-spark-vs-m5-max-vs-rtx-6000-blackwell-local-ai-2026
- Hardware Corner「Apple M5 Max for Local LLMs: First Benchmarks vs RTX Pro 6000 and RTX 5090」（M5 Max 実機・Qwen3.5-122B / Qwen3-Coder-Next / gpt-oss-120B, mlx_lm）: https://www.hardware-corner.net/m5-max-local-llm-benchmarks-20261233/
- The Byte Lab「M5 Max Local AI Benchmarks 2026: Real Qwen3.5 Numbers」（M5 Max 実機・Qwen3.5 / gpt-oss-120B, prefill 考察）: https://thebytelab.com/m5-max-local-ai-benchmark-qwen/
- LLMCheck「M5 Max for Local AI: Apple Silicon Benchmark Guide」（M5 Max vs M4 Max 同一条件, Qwen3.5-30B-A3B ほか）: https://llmcheck.net/blog/apple-silicon-m5-max-local-ai-guide/
- Presenc AI「Local LLM Tokens-per-Second Benchmarks 2026」（M5 Max 7B/70B tok/s・prefill vs decode）: https://presenc.ai/research/local-llm-tokens-per-second-benchmarks-2026
- LLMCheck「Apple Silicon LLM Benchmarks 2026」（コミュニティ集計インデックス）: https://llmcheck.net/benchmarks
- yage.ai「MLX vs llama.cpp on Apple Silicon」（MLX の MoE 有利・Ollama オーバーヘッド）: https://yage.ai/share/mlx-apple-silicon-en-20260331.html
- R. Eubanks「Which Local LLM Should You Actually Use?」（30B MoE vs dense 速度差）: https://robertheubanks.substack.com/p/which-local-llm-should-you-actually
- InsiderLLM「Best Apple M5 Pro and Max for Local AI」（Neural Accelerator と Neural Engine の区別、Qwen3.6-35B-A3B の M5 Max 報告例）: https://insiderllm.com/guides/apple-m5-pro-max-local-ai/
- r/LocalLLaMA「M5 Max 128G Performance tests（Round 2）」（Qwen3.5-122B-A10B の個人実測・TG128 で 41.5 tok/s）: https://www.reddit.com/r/LocalLLaMA/comments/1s0czc4/round_2_followup_m5_max_128g_performance_tests_i/
本記事のうち、メモリコントローラやサブブロックのダイ間分割、D2D 帯域、正式なパッケージ呼称など、Apple が完全公開していない部分については、公開情報・分解記事・各社の解説からの整理・推定です。実装の詳細および M5 Max 固有の実測は、今後の分解記事や実機測定で更新されうる点をお断りしておきます。