本記事は2026年8月9日時点の公開情報を整理したものです。M7の内部仕様はAppleから発表されていません。本文では、確認済みの事実、報道、そこから導く仮説を分けて記述します。

はじめに

前回の記事では、M7世代について、巨大なオンデバイスAIを成立させるためのメモリ階層、フラッシュからの重み供給、Neural Engine強化の可能性を検討しました。

その見方は間違っていないと思います。ただし、購入した M5 Max 128GB macbook pro でオープンウェイトモデルを動かしたとき、もう一つの壁がはっきり見えました。

prefillの演算性能です。ちょっとがっかりするレベルで時間がかかります。

M5 Maxは最大128GBのユニファイドメモリと614GB/sの帯域を持ちます。4bit量子化された数十B級Denseモデルや、活性パラメータの少ない大型MoEを置く器としては、ノートPCとして例外的です。一方、長いプロンプトを読み込ませると、モデルは載るのに最初の1トークンがなかなか返ってこない、という状況が起きます。

これは矛盾ではありません。decodeとprefillでは、必要なハードウェアが違うからです。

本記事の仮説は次のとおりです。

M7世代のAI強化は、メモリ容量や帯域だけでなく、MXFP4のようなブロックスケーリング形式をそのまま積和演算できる低精度行列演算器が中心になる可能性が高い。特にMax系では、GPU各コアのNeural Acceleratorが「AI用の補助器」から「オープンウェイトLLMの主演算器」へ近づくのではないか。

先に断っておくと、これは公開情報から導くアーキテクチャ予測であり、M7の確定仕様ではありません。

1. M5 は M4より改善したが、まだ「prefillが十分速い」とは言えない

Appleが公表したM5 Maxの主なAI向け仕様は次のとおりです。

項目	M5 Max
ユニファイドメモリ	最大128GB
メモリ帯域	614GB/s
GPU	最大40コア
GPU内AI機構	各GPUコアにNeural Accelerator
Neural Engine	16コア
SSD	最大14.5GB/s

Appleは、M5 MaxのLLM prompt processingがM4 Max比で最大4倍になったと説明しています。M5でprefillが重視されたこと自体は明確です。ただし、これは特定条件での世代比較であり、NVIDIA GPUとの絶対性能比較ではありません。また、AppleはGPUのFP16、FP8、FP4行列演算性能をTFLOPSで公開していません。

ここに評価の難しさがあります。容量と帯域は公開されている一方、LLMのprefillを決める低精度GEMM性能は外から見えません。

2. decodeは帯域、prefillは演算を使う

LLMの推論は、大きく二つの段階に分かれます。

段階	処理	行列の形	支配的になりやすい資源
prefill	入力トークンをまとめて処理しKVキャッシュを作る	行列×行列	演算性能、Tensor Core相当の利用率
decode	1トークンずつ生成する	行列×ベクトルに近い	メモリ帯域、重み読み出し

decodeでは、1トークンを生成するたびに大量の重みを読みます。重み1バイトあたりに行う演算が少ないため、演算器より先にメモリ帯域を使い切りやすい。4bit化は重みの転送量を減らすため、そのまま速度向上へつながりやすくなります。

prefillでは、多数の入力トークンに同じ重みをまとめて適用できます。読み込んだ重みを何度も再利用できるため、算術強度が上がります。すると、614GB/sという帯域を持っていても、今度は行列積を処理する演算器が先に詰まります。

Rooflineモデルで書けば、到達性能の上限は次式です。

$$
P = \min(P_{\mathrm{compute}},\ B_{\mathrm{memory}} \times I)
$$

$P_{\mathrm{compute}}$は演算ピーク、$B_{\mathrm{memory}}$はメモリ帯域、$I$は算術強度です。decodeは$I$が小さく右項、prefillは$I$が大きく左項に当たりやすい。

したがって、M7 Maxでメモリ帯域だけを増やしても、decodeは速くなりますが、prefillが同じ比率で速くなるとは限りません。prefillを縮めるには$P_{\mathrm{compute}}$そのものを上げる必要があります。

3. NVIDIAが速い理由は「GPUだから」ではなく、低精度行列積が専用命令だから

NVIDIA BlackwellのTensor Coreは、FP4を含む低精度形式とmicroscaling形式をハードウェアで処理します。NVIDIAは、FP4によって対応可能なモデル容量と演算性能を従来形式に対して2倍にできると説明しています。

重要なのは、4bitで保存できることと、4bitのまま高速に積和演算できることは別だという点です。

実装	メモリ容量	重み転送量	prefillの行列積
4bit保存、演算前にFP16へ展開	減る	減る	展開後のFP16演算。変換コストも発生
4bitをネイティブ行列命令へ入力	減る	減る	低精度演算器の高いスループットを利用

前者でもdecodeには効きます。重みを読む量が減るからです。しかしprefillでは、展開した先のFP16/BF16演算性能が上限になりやすい。後者で初めて、4bit化が「保存形式」だけでなく「演算形式」になります。

AMDもCDNA 4世代のMI350でMXFP4を明示的にサポートしています。MI350Pの公称ピークはMXFP4で4.6PFLOPS、BF16行列演算で1.15PFLOPSです。理論値では同じ演算器面積から4倍のスループットを引き出す設計になっています。製品クラスも消費電力もMacBookとは異なりますが、「4bit対応が容量節約ではなく演算性能の機能である」ことを示す例としては分かりやすい数字です。

4. なぜMXFP4なのか

MXFP4については別記事で詳しく整理しました。

ここではM7の議論に必要な部分だけを抜き出します。

MXFP4は、32個のE2M1形式の4bit値に対して、1個のE8M0スケールを共有するOCPのmicroscaling形式です。

項目	MXFP4
要素形式	E2M1、4bit
ブロック長	32要素
共有スケール	E8M0、8bit
1ブロック	$32 \times 4 + 8 = 136$ bit
実効ビット数	4.25bit/要素

E8M0は2のべき乗のスケールです。そのため、スケール適用は仮数乗算ではなく指数の調整として実装できます。NVFP4より量子化精度では不利ですが、演算器は比較的単純にできます。

さらにMXFP4はNVIDIAだけの形式ではありません。OCP仕様の策定にはAMD、Arm、Intel、Meta、Microsoft、NVIDIA、Qualcommが参加し、NVIDIA BlackwellとAMD CDNA 4の双方が対応しました。オープンウェイトモデル側でも、gpt-ossに続き、DeepSeek-V4やKimi K3などでネイティブMXFP4の採用が広がっています。

モデルがハードウェアへ合わせる段階から、ハードウェアが配布チェックポイントへ合わせる段階へ移り始めています。

5. M5は「型を読める」。次に必要なのは「その型で掛けられる」こと

現行のApple環境には、MXFP4を扱うための足場があります。Metalの低精度テンソルAPIには4bit要素とUE8M0スケールを組み合わせる表現があり、MLXもMXFP4モデルを実行できます。

ただし、公開資料から確認できるのはAPIおよびランタイム上の対応です。M5のNeural AcceleratorがMXFP4ブロックを入力し、スケール処理と行列積を一命令系で実行している、というハードウェア仕様は公表されていません。

この区別は重要です。

現在地を安全に表現すると、次のようになります。

層	M5世代で確認できること	未確認のこと
チェックポイント	MXFP4モデルを格納・ロードできる	—
API・フレームワーク	Metal/MLXで形式を扱える	—
演算器	GPUで実行できる	MXFP4ネイティブ積和、ピーク性能、対応命令

M7の自然な進化は、この最後の空欄を埋めることです。

6. M7で入りそうなものを、強度別に分ける

M7の仕様は未発表なので、予測を三段階に分けます。

仮説	内容	確からしさ
A	GPUのNeural Acceleratorを増強し、LLMのprefillを高速化	高い
B	FP4またはブロックスケーリング行列積をネイティブ実装	中〜高
C	OCP MXFP4の配置・転置・grouped GEMMまで最適化	中

A. Neural Acceleratorの演算量を増やす

Apple自身がM5 Pro/MaxでLLM prompt processingを主要指標として掲げ、GPU各コアのNeural Acceleratorを前面に出しました。さらにM7ではNeural Engineの大幅強化を優先したとの報道があります。M7の中心がAI演算性能になる、という方向性は前回記事の時点より強くなっています。

ただし、オープンウェイトLLMの主経路は固定機能のNeural Engineだけではなく、Metal/MLXから使えるGPU側に置かれる可能性が高いと考えます。モデル構造、量子化形式、MoEのルーティングが速く変わるためです。

B. MXFP4を展開せず積和する

本命はここです。4bit値32個とE8M0スケールを一組として読み、スケールを適用しながら行列積へ流し込む。中間結果はFP16、BF16、FP32などで累積する。この経路があれば、MXFP4の容量削減がprefillの演算性能へつながります。

C. MoEと長文脈を含むデータ移動を最適化する

実際のモデルでは、単純な巨大GEMMだけでは足りません。DeepSeek-V4のようなモデルは多数の小さなexpertへトークンを振り分けます。必要なのはピークFLOPSだけでなく、grouped GEMM、スケールの並べ替え、活性値の量子化、疎なルーティングを低いオーバーヘッドで接続する仕組みです。

Appleが狙うなら、MXFP4命令を一つ追加して終わりではなく、MetalコンパイラとNeural Acceleratorを一体で設計するはずです。

7. M7 Maxに必要なのは「容量・帯域・演算」の三点セット

前回の記事では、メモリ階層を中心にM7を予測しました。今回の考察を加えると、必要条件は三つになります。

資源	解く問題	主に効く段階
大容量ユニファイドメモリ	モデルとKVキャッシュを置く	両方
高いメモリ帯域	重みを毎トークン供給する	decode
MXFP4行列演算性能	長い入力をまとめて処理する	prefill

容量だけ増やすと、大きいモデルは動きますが待ち時間が長い。帯域だけ増やすと、生成は速くなりますが最初の応答は十分縮まらない。演算だけ増やすと、モデルを置けません。

オンデバイスLLM機としてのM7 Maxを成立させるには、この三つを同時に伸ばす必要があります。

8. 反証可能な観察ポイント

この仮説が正しいかどうかは、製品発表の「AI性能が何倍」という表現だけでは判断できません。見るべき項目は次のとおりです。

観察項目	仮説を支持する発表
Metalの型	MXFP4、MXFP8を正式な行列演算入力として明記
命令・API	block-scaled matrix multiply、FP4 MMA相当
性能値	FP4/MXFP4のTFLOPSまたはTOPS
ベンチマーク	LLM prompt processing、TTFT、長いprefill
ソフトウェア	MLXのMXFP4 GEMM、grouped GEMMが専用経路を使用
電力	同じprefill性能で消費電力低下、または同じ電力で大幅向上

逆に、M7でメモリ帯域とNeural EngineのTOPSだけが増え、Metalから使えるMXFP4行列経路が示されなければ、本記事の強い仮説は外れです。その場合、AppleのAI強化はApple Intelligence用の固定されたモデルを中心にしており、汎用オープンウェイトLLMは副次的だったと判断できます。

まとめ

M5 Maxは、128GBの容量と614GB/sの帯域によって、大規模オープンウェイトモデルをノートPC上へ持ち込むところまで到達しました。次の壁は、モデルを載せられるかではなく、長い入力を何秒で処理できるかです。

decodeは主に帯域の問題ですが、prefillは行列演算の問題です。そこで4bit量子化を本当の速度へ変えるには、MXFP4を保存形式として読むだけでなく、ブロックスケールを保ったまま行列積へ投入するハードウェアが要ります。

NVIDIA BlackwellとAMD CDNA 4は、すでにその方向へ進んでいます。オープンウェイトモデル側でもMXFP4の採用が増えています。AppleにもMetal上の形式表現とGPU内Neural Acceleratorという部品は揃っています。

ブロックスケール MXFP4 演算で速く計算できるApple Siliconへ。

M7 Maxが埋めるべき穴は、そこにあります。

参考資料

Apple, “Apple introduces MacBook Pro with all-new M5 Pro and M5 Max”
https://www.apple.com/newsroom/2026/03/apple-introduces-macbook-pro-with-all-new-m5-pro-and-m5-max/
NVIDIA, “Blackwell Architecture”
https://www.nvidia.com/en-us/data-center/technologies/blackwell-architecture/
AMD, “Instinct MI350P PCIe Cards”
https://www.amd.com/en/products/accelerators/instinct/mi350/mi350p.html
OCP, “Microscaling Formats (MX) Specification Version 1.0”
https://www.opencompute.org/documents/ocp-microscaling-formats-mx-v1-0-spec-final-pdf
MLX
https://github.com/ml-explore/mlx
前回記事「アップルは M7 世代で何をしようとしているのか？」
https://qiita.com/sukimaengineer/items/e69524ec14e0907f48c7
関連記事「MXFP4」
https://qiita.com/sukimaengineer/items/373e39b42b394d88c890