MXFP4 と NVFP4 は何が違うのか調べてみた

---

はじめに

前回の記事で、中国ラボがどこから計算資源を調達しているのかを調べました。その第5章で、Kimi K3 が SFT 段階以降に MXFP4 の重みと MXFP8 の活性値で量子化認識学習を行っている、という話に触れています。

そこでは「MXFP4 は NVIDIA 独自の NVFP4 ではなくオープン標準である」という一点だけを取り上げて、NVIDIA 以外のアクセラレータへの移植性を確保する選択と読める、と推測して終えました。

実は、NVFP4 は聞いた事があったのですが、MXFP4 という形式は今回知りました。

そこで、仕様から入って、中国ラボがなぜこの形式を選ぶのかを調べ、最後に Apple Silicon での扱いも確認します。

本記事は2026年7月21日時点で公開されている情報を整理したものです。仕様の記述は OCP 仕様書および NVIDIA・Apple の公式文書、各社の技術報告に基づきます。ベンチマークは出典の性質（一次測定か第三者測定か推定値か）を本文中で区別します。内容は無保証です。

先に結論

論点	結論
要素の符号化	MXFP4 と NVFP4 は完全に同一。どちらも E2M1
違いの実体	ブロック長とスケールの型だけ。ただし別仕様でチェックポイント互換性はない
精度	NVFP4 が上。E8M0 が2のべき乗しか置けないことが効いている
ハード実装コスト	MXFP4 の方が安い。スケール適用が指数加算で済む
中国ラボの採用	gpt-oss が先例。DeepSeek-V4 が中国初で、Kimi K3 が3ヶ月遅れて続いた
DeepSeek-V4 の実装	1×32 の MXFP4 タイルを 128×128 の FP8 ブロックに入れ子にした
標準化のその後	MX は v1.0 のまま。NVFP4 は OCP に採択されず、IEEE P3109 と適合性検証が進む
Apple M5 の対応	Metal は MXFP4 の型を持つが加速は未確認。NVFP4 は型すらなくランタイムが自前処理
Mac での意味	効くのはデコード（帯域律速）と容量。プリフィルは演算律速なので、展開はむしろコスト側
MLX が自前でやる理由	ネイティブ型は macOS 27 から。MLX は 26.2 を切れず、affine も表現できない

1. E2M1 という共通土台

最初に押さえるべきは、MXFP4 と NVFP4 で要素の符号化が完全に同じだということです。どちらも E2M1、つまり符号1ビット・指数2ビット・仮数1ビットの4ビット浮動小数点を使います。

4ビットなので16通りしかありません。非負側の8個は 0, 0.5, 1.0, 1.5, 2.0, 3.0, 4.0, 6.0 で、負側はその鏡像です。±0 があるので、ビットパターンは16通り、相異なる値は15個になります。

ここで注目したいのは刻み幅です。1と2の間には 1.0 と 1.5 しかなく、2と4の間には 2.0 と 3.0 しかない。2のべき乗で区切られる区間ごとに2値ずつで、刻み幅は区間が上がるたびに倍になります。仮数1ビットなので当然といえば当然ですが、この粗さが後の議論すべての出発点になります。

もうひとつ、E2M1 は Inf も NaN も持ちません。16通り全部が有限値に割り当てられています。4ビットしかないところに特殊値を置く余裕がない、という設計判断です。

最大値が 6.0 であることも覚えておいてください。この 6.0 という数字は、以降の章で何度も出てきます。

2. MXFP4 はブロック32と E8M0

E2M1 は最大 6.0 までしか表現できないので、そのままでは実際の重みや活性値を格納できません。ブロック単位で共有するスケール係数を掛けて使います。これがマイクロスケーリング、いわゆるブロック浮動小数点の考え方です。

MXFP4 は OCP（Open Compute Project）の Microscaling Formats 仕様バージョン1.0 で定義されています。仕様書の日付は2023年9月、MX アライアンスと OCP による公開アナウンスは同年10月17日でした。

誰が決めたのか

策定に関わったのは7社です。

企業	立場
AMD	GPU・アクセラレータ。CDNA4 で MXFP4 と MXFP6 を実装
Arm	CPU と IP
Intel	CPU・アクセラレータ
Meta	ハイパースケーラ。使う側
Microsoft	ハイパースケーラ。技術的な基盤の出どころ
NVIDIA	GPU。Blackwell で MX 系と NVFP4 の両方を実装
Qualcomm	モバイルとエッジ推論

作る側が5社、使う側が2社。両方が入っています。

技術的な基盤は Microsoft Research の研究から出ていて、仕様の著者にも同社の研究者が並びます。Meta も低精度学習の実証研究を出しており、利用者の立場から仕様に意見を入れられる位置にいました。

NVIDIA が名を連ねている点は、この記事の文脈だと少し皮肉です。標準化には参加しながら、自社ハードウェアには独自の NVFP4 を別に用意しました。第8章で見るとおり、そちらはコンソーシアムに採択されていません。

むしろ入っていない顔ぶれ

情報量があるのは不在のほうです。Google、Amazon、そして RISC-V エコシステムが入っていません。

前の2社は TPU と Trainium という自社アクセラレータを持っていて、数値形式を自前で決められる立場にあります。他社と歩調を合わせる動機が薄い。標準化に参加するかどうかは、垂直統合の度合いと裏返しの関係にあります。

Apple も策定には入っていません。ただし本記事の第9章で見るとおり、Metal のスケール平面には UE8M0 を採用しています。決める側には回らず、実装だけ標準に寄せた形です。

そして中国のラボも当然入っていません。にもかかわらず DeepSeek-V4 と Kimi K3 は MXFP4 を採用しました。策定に関わっていない標準を、オープン仕様であるがゆえに使える。これが第5章で扱う話の前提になります。

MXFP4 の構成は次のとおりです。

項目	内容
要素形式	E2M1（4bit）
ブロック長	32要素
共有スケール	E8M0（8bit）
1ブロックの総ビット数	32 × 4 + 8 = 136 bit
実効ビット数	136 ÷ 32 = 4.25 bit / 要素

E8M0 は少し変わった型です。8ビットすべてが指数で、符号ビットも仮数ビットもありません。バイアスは127で、0から254が 2^-127 から 2^127 に対応します。255（0xFF）は NaN として予約されていて、Inf のエンコーディングはありません。スケールが NaN になると、そのブロックの32要素すべてが NaN になります。

つまり E8M0 で表現できるスケール係数は、2のべき乗だけです。

MX 仕様はファミリになっていて、要素形式を差し替えた兄弟が定義されています。ブロック長32と E8M0 スケールは共通です。

形式	要素	実効ビット / 要素
MXFP8	E4M3 または E5M2	8.25
MXFP6	E2M3 または E3M2	6.25
MXFP4	E2M1	4.25
MXINT8	INT8	8.25

Kimi K3 が使う「MXFP4 重みと MXFP8 活性値」という組み合わせは、この表の1行目と3行目を持ってきたものです。同じブロック長・同じスケール型で揃えられるので、実装上の相性が良い。

丸めについては、OCP 仕様が FP4 への変換に最近接偶数丸め（roundTiesToEven）を要求しています。一方でスケール係数の丸め方は仕様で一意に決まっておらず、切り上げ側に倒す推奨は NVIDIA の MXFP8 レシピ論文などベンダ側の資料に出てきます。ここは実装差が出る箇所です。

3. NVFP4 はブロック16と E4M3、そして二段目

NVFP4 は NVIDIA が2025年に公表した独自形式です。要素は E2M1 で MXFP4 と完全に同じ。変えたのはスケールの側だけです。

項目	内容
要素形式	E2M1（4bit）
ブロック長	16要素
ブロックスケール	符号なし E4M3、いわゆる UE4M3（FP8、最大448）
グローバルスケール	FP32（テンソル単位）
1ブロックの総ビット数	16 × 4 + 8 = 72 bit
実効ビット数	72 ÷ 16 = 4.5 bit / 要素

変更点は2つです。

ひとつはブロックを32から16へ短くしたこと。外れ値がひとつ混ざったとき、そのブロック全体のスケールが引っ張られます。ブロックが短いほど巻き込む範囲が狭くなります。

もうひとつはスケールを E8M0 から E4M3 に替えたこと。E4M3 は仮数を3ビット持つので、2のべき乗の間を8等分して刻めます。なお NVFP4 のブロックスケールは符号を持たない UE4M3 です。符号付きの E4M3 と取り違えると動的レンジが大きく狂うので、この一点は後の第7章で効いてきます。

ただし E4M3 は最大448までしか表現できません。E8M0 の 2^127 に比べると動的レンジが桁違いに狭い。そこでテンソル単位の FP32 グローバルスケールを二段目に置いて、レンジを一度寄せてからブロックスケールを適用します。NVIDIA の資料では、グローバルスケールをテンソル全体の最大絶対値を 6 × 448 で割った値として定義しています。6 は E2M1 の最大値、448 は E4M3 の最大値です。

同じ32要素を並べて比べると、違いが見やすくなります。MXFP4 はスケール1個、NVFP4 はスケール2個に加えてテンソル単位の FP32 が乗る。実効ビット数の差 4.25 対 4.5 は、ここから出ています。

NVIDIA は、NVFP4 が FP16 に対して約3.5倍、FP8 に対して約1.8倍メモリフットプリントを削減すると説明しています。

4. 同じ E2M1 でも、別仕様である

ここで一度整理します。

項目	MXFP4	NVFP4
策定	OCP（7社で標準化）	NVIDIA 独自
要素形式	E2M1	E2M1（同一）
ブロック長	32	16
ブロックスケール	E8M0（2のべき乗のみ）	E4M3（FP8）
グローバルスケール	なし	FP32（テンソル単位）
実効ビット / 要素	4.25	4.5
スケール適用	指数加算	FP8 乗算 + FP32 乗算
ネイティブ対応ハード	Blackwell、AMD CDNA4	Blackwell のみ

調べていて気になったのは、「NVFP4 は MXFP4 のハードウェア実装である」と書いている解説がそれなりに見つかることです。これは正確ではありません。ブロック長もスケール型も違う別仕様で、チェックポイントに互換性はありません。NVIDIA の CUTLASS も、OCP 準拠の32要素型と NVIDIA 独自の16要素型を別の型として提供しています。

「FP4」とだけ書かれた記事を読むときは、どちらの話なのか確認したほうがよさそうです。

精度の差はどこから出るか

E8M0 は2のべき乗しか置けません。ブロック内の最大値を E2M1 の表現域 0〜6 に合わせ込むとき、スケールの選び方が2倍の粒度でしか刻めない、ということです。

ここで注意が要るのは、スケールの選び方に流儀が2つあることです。

OCP 仕様が例として挙げるアルゴリズムは、ブロック最大絶対値の指数から要素形式の最大 binade を引く形、つまり floor(log2(amax)) − 2 を共有指数にします。この場合スケール後のブロック最大値は4以上8未満に着地し、6を超えた分はクリッピングされます。

もうひとつは、クリッピングを避ける側に1段大きくスケールを取る流儀です。この場合スケール後のブロック最大値は3から6の間のどこかに着地します。最悪ケースでは3の近くに落ちて、表現域の上半分がまるごと使われません。これが1ビット相当の損失です。

OCP 仕様は変換レシピを実装定義として許容しているので、どちらも仕様違反ではありません。本記事の図と以降の説明は、後者のクリッピングを避ける流儀を前提にしています。

NVIDIA の論文はこれをもう少し具体的に書いています。MXFP4 は全値を FP4 で格納するため、2のべき乗へのスケール丸めによって最大1ビナードぶんの動的レンジと、±4 と ±6 という4つのサンプルを失いうる。第1章で数えた15個の値のうち4個が使えなくなる、という言い方です。3より上にある表現点は 4 と 6 だけなので、上半分が使われないという先ほどの話と同じことを、失われる点の個数で言い直したものになります。

E4M3 なら仮数3ビットぶん刻めるので、着地点は6の近傍に収まります。ブロックが16要素と短いことと合わせて、この2点が精度差を生みます。

定量的なところを見ます。NVIDIA は120億パラメータの Mamba-Transformer ハイブリッドを10兆トークン学習させ、FP8 をベースラインとして比較した結果を公開しています。相対ロス誤差は一貫して1%未満で、学習率を減衰させる終盤でわずかに1.5%を超える程度。下流タスクでも MMLU-Pro が NVFP4 で62.58%、FP8 で62.62%とほぼ同等でした。公開されているものとしては最長の4ビット事前学習です。

ただし、この結果は素直に4ビットにしただけでは出ません。論文は収束に必要な4つの手法を挙げています。数値的に敏感な層（62ブロック中の最初2つと最後8つ、約16%）を BF16 のまま残すこと、重み勾配の入力に 16×16 のランダムアダマール変換をかけること、重みに二次元のブロックスケーリングを使うこと、勾配にのみ確率的丸めを使うこと。これらを外したデフォルト設定は、学習初期に発散します。

MXFP4 側の学習後量子化（PTQ）も見ておきます。素の MXFP4 と NVFP4 では、エンドツーエンドの精度差が約10%開くという報告があります。これに対してスケールの取り方と外れ値の扱いを改良すると、その差は平均1%未満まで縮まるとされています。

回転変換も効きます。ブロック単位のアダマール回転を GPTQ に組み込んだ MR-GPTQ は、B200 でレイヤ単位最大3.6倍・エンドツーエンド2.2倍、RTX 5090 でレイヤ単位6倍・エンドツーエンド4倍の高速化を報告しています。細粒度回転の DuQuant++ は LLaMA3-8B の WikiText2 パープレキシティを6.88（FP16 は6.14）まで戻しています。

まとめると、素の状態では NVFP4 が明確に上で、手当てをすれば MXFP4 も追いつける、という関係です。実効ビット数が 4.25 対 4.5 で等しくない点は割り引いて読む必要があります。

5. なぜ中国ラボは MXFP4 を選ぶのか

ここからが、前回の記事から持ち越した疑問です。

まず、Kimi K3 が最初ではありません。先例は gpt-oss です。OpenAI は2025年に、MoE のエキスパート重み（パラメータの90%超）を MXFP4 で量子化した状態でポストトレーニングしたオープンウェイトモデルを公開しました。これにより120Bモデルが単一の80GB GPU に載ります。

なお MXFP4 での量子化認識学習そのものは gpt-oss が世界初というわけではなく、ViT 向けなど先行研究があります。gpt-oss が画期的だったのは、主要なオープンウェイト LLM としてこの構成を実運用に持ち込んだ点です。

中国のモデルとしては、DeepSeek-V4 が先行しています。2026年4月24日公開のプレビュー版で、ポストトレーニング段階に FP4 量子化認識学習を組み込んでいます。Kimi K3 の7月16日より約3ヶ月早い。

そして Moonshot 自身にも前史があります。

モデル	時期	量子化方式
Kimi K2 Thinking	2025年11月	MoE に INT4 の重みのみ QAT（W4A16）
Kimi K2.6	2026年4月	上記を継承
Kimi K3	2026年7月16日	MXFP4 重み + MXFP8 活性値（W4A8）

Kimi K2 Thinking はポストトレーニング段階で QAT を採用し、MoE 部分に INT4 の重みのみ量子化を適用して、ネイティブ INT4 推論で約2倍の生成速度を実現していました。ベンチマークもすべて INT4 精度で報告しています。

つまり K3 は「Moonshot が QAT を始めた」のではありません。INT4 の W4A16 から MXFP4 の W4A8 へ、形式を乗り換えたという話です。前回の記事では K3 の MXFP4 だけを見て「オープン標準を選んだ」と書きましたが、より正確には「INT4 という独自寄りの構成から OCP 標準へ移った」ことになります。

Moonshot 自身は、この組み合わせを幅広いハードウェア互換性のために選んだと説明しています。Tom's Hardware も同じ説明を報じています。

ただし、移植性という読みには反証がある

前回の記事では、MXFP4 を選ぶのは国産チップへの移行を見据えた調達リスクへの備えではないか、と推測しました。そのうえで「これは設計意図の推測です」と留保を付けています。今回、その留保に具体的な反証が見つかりました。

NVIDIA の研究ブログは、DeepSeek-V4-Pro をエキスパート重みと疎アテンションインデクサに FP4 量子化認識学習を適用し、NVIDIA Blackwell を標的としたモデルとして記述しています。MXFP4 は Blackwell の Tensor Core もネイティブ対応しているので、OCP 標準を選ぶことと NVIDIA 向けに最適化することは矛盾しません。

移植性の確保という読み自体は成り立ちますが、それだけが理由だと断定はできない、というのが現時点の妥当な理解だと思います。

なお、他の中国製モデルが MXFP4 で先行していた形跡は見つかりませんでした。AMD の Quark リポジトリには、Qwen3-235B-A22B、MiniMax-M2.5、GLM-5 の MXFP4 量子化版が不足しているという Issue が立っています。これらは第三者による学習後量子化の話で、ネイティブ MXFP4 配布ではありません。

6. DeepSeek-V4 の入れ子構造

今回いちばん面白かったのがここです。DeepSeek-V4 の技術報告を読むと、MXFP4 のブロック長32という仕様が、そのまま実装上の設計制約として効いていることがわかります。

適用先は2ヶ所です。ひとつは MoE のエキスパート重み。GPU メモリを占める主因なので、ここを削るのが最も効きます。もうひとつは CSA（Compressed Sparse Attention）のインデクサにおける Query-Key 経路で、QK 活性値をキャッシュ・ロード・乗算まですべて FP4 で行い、長文脈でのアテンションスコア計算を加速しています。あわせてインデックススコアを FP32 から BF16 に落とし、top-k セレクタで2倍の高速化を得ながら、KV エントリの99.7%リコールを保っています。

学習時の流れはこうです。オプティマイザが保持する FP32 マスター重みをまず FP4 に量子化し、計算のために FP8 へ戻す。この FP4 から FP8 への逆量子化が可逆である、というのが肝です。

なぜ可逆になるのか。FP8 の E4M3 は FP4 の E2M1 より指数ビットを2つ多く持ち、より広い動的レンジを提供します。したがって、各 FP8 量子化ブロック（128×128 タイル）の中にある FP4 サブブロック（1×32 タイル）の最大スケール係数と最小スケール係数の比が一定の閾値を超えない限り、細粒度のスケール情報は FP8 の拡張された動的レンジに完全に吸収されます。DeepSeek は、実際の重みがこの条件を満たすことを経験的に確認したとしています。

ここで出てくる 1×32 が、第2章で見た MX 仕様のブロック長32そのものです。DeepSeek-V3 以来の FP8 は 128×128 のブロックスケーリングを使っていました。その 128×128 のマス目の中に、MXFP4 の32要素タイルがちょうど 4 × 128 = 512 個収まる。

この入れ子が成立するおかげで、QAT パイプライン全体が既存の FP8 学習フレームワークを一切変更せずに再利用できます。逆伝播では順伝播と同じ FP8 重みに対して勾配を計算し、FP32 マスター重みへ直接伝播させる。これは量子化操作に対する Straight-Through Estimator の適用と等価で、転置した重みを再量子化する必要もなくなります。推論と強化学習のロールアウトでは逆伝播がないので、シミュレートされた量子化ではなくネイティブの FP4 重みを直接使います。

配布されるチェックポイントもこの構成を反映しています。DeepSeek-V4-Flash の公式チェックポイントは、ルーテッドエキスパート（モデルの96%）をネイティブ MXFP4 で、それ以外を FP8 か BF16 で格納しています。モデルカードにも FP4 と FP8 の混合であることが明記されています。

配信側では、SGLang が FlashInfer の TRTLLM-Gen fused MoE バックエンドを統合し、MXFP8 の活性値と MXFP4 のエキスパート重みを組み合わせています。つまり実行時には V4 も実質的に W4A8 で動きます。「Kimi K3 の MXFP8 活性値が新しい」という整理をしがちですが、そこは差別化要素とは言い切れません。

検証の観点でひとこと付け加えると、この入れ子は状態空間を素直に増やします。FP8 ブロック内の E8M0 スケールのばらつきが閾値を超えたときにどう振る舞うか、という境界条件が仕様に組み込まれているからです。DeepSeek は経験的に条件を満たすと述べていますが、これは学習データと重み分布に依存する性質で、形式的に保証されているわけではありません。ここは検証項目として明示的に持っておきたいところです。

7. ハードウェアの対応状況

演算器の側を見ます。

ここで「対応」という言葉を2つに分けておきます。API やコンパイラが形式を型として扱えることと、演算器がその形式のまま積和を実行することは、別の話だからです。表の Apple の行だけ書き方が違うのはそのためです。

製品	MXFP4	NVFP4	備考
NVIDIA Blackwell（B200 など）	対応	対応	第5世代 Tensor Core
NVIDIA Blackwell Ultra（GB300）	対応	対応	NVFP4 で密 15 PFLOPS
AMD Instinct MI355X（CDNA4）	対応	非対応	scaled-MFMA 命令
Apple M5 シリーズ	Metal に型あり 加速は未確認	非対応	第9章と第10章で詳述

Apple の MXFP4 で判定を保留しているのには理由があります。Metal 4.1 は fp4 を持ち、テンソルに UE8M0 のスケール平面をブロック単位で付けられるので、API の上では MXFP4 を組み立てられます。ところがそれが Neural Accelerator の演算器で加速されるのかは、公開情報からは確認できません。仕様書は型がサポートされることは示しますが、それが加速されるかどうかを述べないからです。

一方 NVFP4 のほうは、そもそも型がありません。macOS と iOS 27 では MTLTensor が量子化データと並べてスケール平面を持てるようになりましたが、Apple がその平面のサポート形式として挙げているのは FP8 E8M0 です。E4M3 のスケール平面には言及がなく、ブロック長16もテンソル単位の FP32 グローバルスケールも出てきません。

これは示唆的です。Apple が実装したのは OCP 標準の側であって、NVIDIA 独自形式ではない。第8章で見るとおり NVFP4 はコンソーシアムに採択されておらず、Apple はその線引きに沿った、と読めます。

では NVFP4 のモデルが Mac で動かないのかというと、動きます。ランタイムが自前で処理しているからです。しかもそこに、仕様の空白が実装のバグを生む典型例が転がっています。ここは第9章でソースまで追って整理します。

B200 の Tensor Core 性能を密（非スパース）で揃えると、FP4 が 9 PFLOPS、FP8/INT8 が 4.5 PFLOPS、FP16/BF16 が 2.25 PFLOPS です。FP4 は FP16 のちょうど4倍。2:4 の構造化スパース性を使うとそれぞれ倍になります。

ここは資料によって数字がぶれる箇所なので注意が要ります。NVIDIA の資料に出てくる「FP4 20 PFLOPS / FP8 10 / FP16 5」という並びは、HGX B200 の8GPU合計を疎で数えた系統の値です。単体・密の数字と混ぜると4倍という比だけが残って絶対値が合わなくなります。比較表を作るときは、密同士か疎同士か、単体か筐体合計かを必ず揃えてください。

Blackwell Ultra（GB300）では NVFP4 が密で 15 PFLOPS に上がっています。

AMD の MI355X は MXFP4 と MXFP6 に対応しますが、NVFP4 には対応しません。OCP 標準だけを実装した形です。興味深いのは、MI355X では FP6 が FP4 と同じ回路を使うため同レートで動くのに対し、B200 では FP6 が FP8 側と同じ回路になっている点です。同じ仕様でも実装の割り付けが違います。

スケール適用のハードウェアコストも整理しておきます。E8M0 は2のべき乗なので、適用は指数フィールドへの加算だけで済みます。乗算器が要らず、丸め誤差もゼロ。一方 E4M3 は実際の FP8 乗算が必要で、NVFP4 ではさらにテンソル単位の FP32 乗算が乗ります。スケールの読み出し帯域も、ブロック長が半分なぶん NVFP4 のほうが倍かかります。

検証の観点では、NVFP4 のほうが確認項目が増えます。二段スケールの適用順序、E4M3 の符号の有無、丸めモードの切り替え。特に符号の有無は実際に問題になっています。第3章で触れたとおり NVFP4 のブロックスケールは符号なしの UE4M3 ですが、MLX の nvfp4 実装が符号付きの E4M3 を使っていて非互換になっている、という報告が上がっています。仕様書を読むだけでは拾いにくい種類の食い違いです。

8. その後の標準化はどこへ向かっているか

ここまで MXFP4 と NVFP4 を並べてきましたが、では標準化の側はその後どうなったのか。調べた範囲では、MX 仕様は v1.0 のままで後継版は確認できませんでした。動きは別の層に移っています。

MX は v1.0 のまま、NVFP4 は採択されなかった

OCP のリリース文は、MX v1.0 を今後の狭精度フォーマットの革新に向けた基盤を提供するものと位置づけていました。拡張は当初から想定されていたわけですが、後継版は出ていません。

むしろ注目すべきは、起きなかったことのほうです。OCP MX ファミリは複数ベンダによるコンソーシアム標準である一方、NVFP4 は Blackwell 向けの NVIDIA の選択であり、コンソーシアムは採用しなかったとされています。第4章で「別仕様である」と書きましたが、これは標準化プロセスの結果としてもそうなっている、ということです。

第2章で見たとおり、MX アライアンスには Google も Amazon も RISC-V エコシステムも入っていません。全員が乗った標準ではないところに、NVIDIA が自社形式を別に持ち込んだ。標準化の網の目は、思ったより粗いということです。

本命は IEEE P3109

いま実際に進んでいるのはこちらです。

項目	内容
名称	IEEE P3109 Standard for Arithmetic Formats for Machine Learning
PAR 承認	2023年2月15日、現在も Active PAR
担当	IEEE Computer Society、C/MSC マイクロプロセッサ標準委員会
位置づけ	IEEE 754-2019 と整合
進捗	中間報告が公開されている（v3.0 が2025年8月、v4.0 が2026年）

機械学習に最適化された領域向けの二進算術とデータ形式を定義し、この算術で生じる例外の既定の扱いも規定する、という射程です。幅・精度・符号の有無・無限大の有無でパラメータ化された二進浮動小数点形式の族を定義し、演算は値を閉拡張実数へデコードして定義されます。丸めと飽和のモードが広範に定義されていて、確率的丸めも含まれます。第4章で見た NVFP4 の事前学習が勾配に確率的丸めを使っていたことを思い出すと、標準の側もそこを織り込んでいるのが分かります。

MX との関係で重要なのは、P3109 が要素形式と演算の側を扱っていて、ブロックスケーリングそのものは対象外だという点です。競合ではなく補完関係にあります。MX が「ブロックをどう組むか」を決め、P3109 が「その要素で何をどう演算するか」を決める。

形式検証も進んでいて、SMT ソルバを使った形式化の論文が IEEE の会議に出ています。仕様書が形式検証にかけられる、というのは検証の側から見ると素直に良い流れです。

適合性検証という新しい層

今回いちばん面白かったのがここです。2026年6月に、FP8、BF16、MXFP4、そしてマイクロスケーリング形式のベンダ中立な参照として、84形式のカタログとビット厳密な適合性ベクタを提供する取り組みが公開されています。形式数は版によって変わりうるので、参照する際は最新版を確認してください。

現行スイート v0.1 は表現層、つまりエンコードとデコードのビット厳密性のみをカバーします。2026年第3四半期を目標とする Track 2 で演算層まで拡張され、少なくとも6形式すべてについて加算・乗算・FMA の最近接偶数丸めをカバーする予定とされています。

そして、名指しで挙げられている発散ケースが2つあります。ひとつは E4M3 のオーバーフローの扱いで、最大有限値である448を超えたとき、実装は最大有限値に飽和させることも NaN を返すこともできる、という余地が残っています。もうひとつが、MXFP4 と NVFP4 のブロック構造のギャップです。

前章で触れた MLX の符号付き E4M3 問題は、まさにこのカテゴリの事故でした。仕様に実装定義の余地があり、そこが相互運用性の穴になる。適合性ベクタが整備されれば、ああいう食い違いは早期に検出できます。リファレンスベクタを流し込んで差分を取るという、論理検証では当たり前の作業が、数値形式の世界でようやく整備されはじめた段階に見えます。

研究段階の次世代候補

標準化の手前では、MX の弱点を突く提案が出ています。

提案	発表	方向性
NxFP（ナノスケーリング）	2024年	要素ごとのスケーリングをさらに細分化する
MX+	MICRO 58（2025年10月）	ブロック最大要素の指数ビットを追加仮数として再利用する。4bit の MX 形式で最大 +42.15% の改善を報告
MX-SAFE	2026年5月	広仮数モードと subnormal モードを適応的に切り替え、学習と直接キャスト推論の両方に対応する

いずれも E8M0 の粗さをどう埋めるかという同じ問題に取り組んでいます。MX+ は第4章で触れた、ブロック最大要素の指数ビットを再利用する手法です。

これらが次の標準になるかは分かりません。ただ方向は一致していて、ブロックあたりスケール1個では足りない、という認識で揃っています。NVFP4 がブロックを16に縮めたのも、DeepSeek-V4 が 1×32 を 128×128 に入れ子にしたのも、同じ問題への別の答え方でした。

9. Mac 上の FP4 で実際に何が起きているのか

ここからが手元の話です。そして、この章はいちばん慎重に書く必要がありました。

先に立場を明確にしておきます。M5 の Neural Accelerator が MXFP4 を演算器レベルで加速するかどうかは、公開情報では確認できません。断定を避けて、何が分かっていて何が分かっていないかを分けて書きます。

まず、Metal は MXFP4 に対応している

これは事実です。macOS と iOS 27 では、ひとつの MTLTensor が量子化されたデータと並べてスケール平面を持てるようになりました。スケール平面の型は MTLTensorDataTypeMetalFloat8UE8M0、MSL では metal_fp8_ue8m0_format で、ブロック係数を 32×1 のように指定します。32要素ごとに1つのスケールを共有する、まさに MX 仕様の構造です。

要素側は fp4 が MSL の形式型として存在するので、これを組み合わせれば MXFP4 になります。ただし WWDC26 のセッション330で実際に示されているサンプルは、データ平面が metal_fp8_e4m3_format、つまり MXFP8 のほうでした。構造は共通なので MXFP4 も同じ書き方になりますが、公開例が MXFP8 である点は正確に書いておきます。

スケール型の名前に注目してください。UE8M0、符号なしです。型名に符号の有無が入っている。この点は後で効いてきます。

TensorOps は利用可能なハードウェア加速を世代を問わず自動的に使い、M5 の Neural Accelerator を活用する、とも説明されています。

つまり型の定義としては、MXFP4 は Metal に正式に組み込まれています。ここを「非対応」と書くのは誤りになります。

ただし対応しているのは MXFP4 であって、NVFP4 ではありません。macOS と iOS 27 で MTLTensor がスケール平面を持てるようになった際、Apple がサポート形式として挙げているのは FP8 E8M0 です。NVFP4 が要求する E4M3 のスケール平面も、ブロック長16も、テンソル単位の FP32 グローバルスケールも出てきません。Apple は OCP 標準の側だけを実装しています。

分かっていないのは、加速されるかどうか

問題は、仕様書が「サポートされる」とは書くが「加速される」とは書かないことです。Metal Shading Language 仕様は、データ型の行がサポート対象であることは示しますが、それがハードウェアで加速されるのか、演算がどこで実行されるのか、アキュムレータ幅がいくつかを一切述べません。cooperative_tensor のレイアウトも意図的に不透明とされています。

では実測はどうか。ここで引用できる測定が2つありますが、どちらも M5 の MXFP4 を測ったものではありません。

ひとつは A19 のマイクロベンチマークです。ハードウェアで加速される行列演算のデータ型は FP16（FP16 または FP32 アキュムレータ）と INT8（INT32 アキュムレータ）のみで、bfloat16 は含まれない。GPU コアあたり毎サイクル 1024 FLOPS が FP16 行列演算で、A19（5コア）での実測ピークが FP16 行列で 7.4 TFLOPS、INT8 行列で 13.4 TOPS。ここから外挿した M5 Max（40コア）は 70 TFLOPS 前後という推定値です。

ただしこの測定は2025年10月、Xcode 26.1 の時点のものです。fp4 や MXFP4 が Metal に露出する前で、そもそも測りようがありませんでした。「FP16 と INT8 のみ」は、その時点で API から到達できた形式の話と読むべきです。

もうひとつは Metal 4.1 のテンソル経路を解析した論文です。fp8 の matmul2d は fp16 の0.94倍のスループットしか出ず、オペランドのバイト数は半分なのに遅い。したがってこれは加速されておらずエミュレーションである、と結論しています。説得力のある論証です。

ただし測定対象は M4 Max です。論文自身が、M4 世代は Neural Accelerator 以前であり、すべての数値は M4 Max についてのものだと明記し、他の Apple GPU については何も主張しない、世代間の挙動は今後の課題である、と述べています。そのうえで結論部にはこう書かれています。M4 Max では fp8 の matmul2d はメモリフットプリントと動的レンジのための機能であってスループットのための機能ではない、高速化は M5 待ちだ、と。

つまりこの論文は、M5 で加速されないと言っているのではなく、むしろ加速を期待する立場です。

調べた範囲では、M5 上で fp4 や MXFP4 の matmul2d スループットを FP16 と比較した公開測定は見つかりませんでした。ここは空白です。

分かっているのは MLX の実装

ハードウェアの側は空白ですが、ソフトウェアの側は確認できます。MLX のソースを読みました。バージョンは 0.32.1 です。

MLX には Neural Accelerator 専用の実装系統があり、ファイル名に nax という接尾辞が付いています。この系統は Metal Performance Primitives のヘッダを直接インクルードしています。使われる条件は device.cpp の is_nax_available() で決まり、macOS 26.2 以降であることと GPU のアーキテクチャ世代が一定以上であることが要求されます。量子化行列積では、これに加えて転置であることと K が64の倍数であることが条件です。

肝心の処理はこうなっています。QuantizedBlockLoader がデバイスメモリから重みを uint8_t のまま、つまり4ビットにパックされた状態で読みます。スケールも uint8_t で読み、グループサイズが16なら fp8_e4m3、それ以外なら fp8_e8m0 として解釈する。NVFP4 と MXFP4 の分岐が、ここに条件分岐1つで入っています。

ここは MLX が自前でやっている処理です。Metal に NVFP4 のテンソル型がない以上、スケールの解釈はランタイム側が引き受けるしかありません。そして第7章で触れた符号の食い違いは、まさにこの1行で起きています。NVFP4 のブロックスケールは符号なしの UE4M3 であるべきところ、ここで使われている fp8_e4m3 は符号付きの実装です。仕様に定義がない場所を実装が埋めると、こういうずれが入る。

そのうえで dequantize が1バイトを2つの fp4_e2m1 に展開し、それぞれを型 T に変換してスケールを掛け、スレッドグループメモリに書き込みます。その後で mpp::tensor_ops::matmul2d を呼び、オペランドの型として T を渡す。

T が何かというと、カーネルのインスタンス化は float、bfloat16_t、float16_t の3つでした。

つまり MXFP4 の重みは、行列積器に届く前に FP32 か BF16 か FP16 に展開されています。Metal がネイティブに持つ MXFP4 のテンソル型は、少なくとも 0.32.1 の時点では使われていません。

ここで誤解しやすい点をひとつ。展開先はスレッドグループメモリ、つまりオンチップの共有メモリです。デバイスメモリから読むのは4ビットのままなので、DRAM 帯域の削減はそのまま効いています。「BF16 に展開してから演算する」という言い方は、メモリ上に BF16 のテンソルを作り直すように読めてしまいますが、そうではありません。読むのは4ビット、演算器に渡す直前でオンチップで広げる、という構造です。

そしてこれはハードウェアの性質ではなく、MLX の実装の性質です。MLX が Metal の MXFP4 テンソル型を使わない理由が、ハードウェアが加速しないからなのか、使っても速くならないからなのか、単に未対応なのかは、このコードからは判断できません。

なお NVFP4 のほうは、そもそも Metal に型がないので選択の余地がありません。MLX が自前で展開する以外の道がない。MXFP4 は「使えるのに使っていない」で、NVFP4 は「使えない」。同じ経路を通っていても、置かれている状況は違います。

プリフィルでは、展開が純粋なコストになる

ここまでを踏まえると、ひとつ気になることが出てきます。プリフィルで MXFP4 は得をしているのか、という点です。

ルーフラインで考えます。プリフィルの GEMM を [M, K] × [K, N] とすると、演算量は 2MKN、重みのバイト数は BF16 で 2KN。重みバイトあたりの演算強度は M になります。一方 M5 Max の演算対帯域の比は、70 TFLOPS を 614 GB/s で割って約114 FLOP/byte。つまり M が114を超えたあたりから演算律速に入ります。プリフィルは数千トークンをまとめて流すので、完全に演算律速の側です。

演算律速の領域では、帯域を減らしても速くなりません。そして前節で見たとおり、行列積器に渡る型は FP32 か BF16 か FP16 です。演算スループットの天井は BF16 のモデルと変わらない。

つまり4ビット化で得られるものが無いだけでなく、展開のための仕事が増えます。

これは実際に測られています。M4 Max で fp8 の matmul2d は fp16 の0.94倍でした。オペランドのバイト数は半分なのに遅い。低精度データパスが無いためアンパックのオーバーヘッドが丸ごと乗った、というのが論文の結論です。同じ論理が、MLX 経由の MXFP4 にもそのまま当てはまります。

ただし M5 では条件が変わっている

もっとも、M4 と M5 では前提が違います。

M4 では行列積そのものがシェーダの汎用 ALU 上で動いていました。展開処理と行列積が同じ演算資源を奪い合う。0.94倍という数字はそこから来ています。M5 では行列積が Neural Accelerator に移ったので、シェーダ ALU が空く。展開を裏で走らせる余地があります。

タイル1枚あたりで概算します。

項目	概算
展開の演算量	2KN（型変換とスケール乗算）
行列積の演算量	MKN の FMA
演算量の比	2/M
実行レートの差	Neural Accelerator が毎サイクル128 FMA、シェーダ ALU が32 FMA
サイクル数の比	8/M

MLX のタイルは 64×64×64 なので M は64、サイクル数の比はおよそ12%です。しかも展開はタイルの読み込みごとに一度で、そのタイルは M 方向で使い回されます。オーバーラップすれば隠れる範囲に収まります。

Apple の公表値もこれと矛盾しません。同じ Qwen3-8B で、bf16 の TTFT 向上が3.62倍、4ビット量子化版が3.97倍。4ビットのほうが伸びが大きい。M4 では展開が行列積と競合していたものが、M5 では隠れるようになった、と読めば説明が付きます。

ただしこれは M5 と M4 の比であって、M5 上での BF16 と MXFP4 の直接比較ではありません。傍証止まりです。

プリフィルで残るのは容量

整理します。プリフィルにおいて MXFP4 に演算上のメリットはありません。良くて中立、悪ければわずかなマイナス。M5 では隠れて中立に近いと推測できますが、確認された数字はありません。

残るメリットは容量です。gpt-oss-120b は 4.25 bit/パラメータなので約64GB に収まり、128GB の M5 Max に載ります。BF16 なら240GB 必要で、プリフィルが速いか遅いか以前に、そもそも走りません。速度の話ではなく、走るか走らないかの話です。

第4章で MXFP4 と NVFP4 の精度差を見たとき、実効ビット数の 4.25 対 4.5 という差を割り引いて読むべきだと書きました。Mac ではその 0.25 ビットが、速度ではなくロードできるモデルの上限として効いてきます。

10. ネイティブ型を使ったら何が変わるのか

第9章で「使えるのに使っていない」と書きました。では使ったら何が変わるのか、そしてなぜ使っていないのかまで踏み込みます。

逆量子化そのものは消えない

まず期待を先に潰しておきます。Apple のサンプルコードには、行列積を実行する行にこうコメントが付いています。逆量子化は TensorOps が自動的に処理する、と。章立ての説明でも、量子化された入力への対応は「カスタム逆量子化形式の扱い」として整理されています。

つまりネイティブ型を使っても逆量子化は起きます。演算器が4ビットのまま積を取るわけではない。この点は MLX の自前実装と変わりません。

変わるのは展開の場所

では何が違うのか。誰がいつどこで展開するか、です。

MLX はいま、展開した結果をスレッドグループメモリに置いています。ここが効きます。タイルは 64×64×64 なので、重みタイルは 64×64 で4096要素。

保持形式	スレッドグループメモリ上のサイズ
4ビットにパックしたまま	2 KB（＋スケール128バイト）
BF16 に展開したあと	8 KB

4倍です。ダブルバッファリングすれば差はさらに開きます。

TensorOps が展開を協調テンソル、つまりレジスタ側に寄せているなら、スレッドグループメモリには4ビットのまま置けます。同じ容量でタイルを大きく取れるか、オキュパンシーを上げられる。Apple がフラッシュアテンションの節で、協調テンソルを行列積の入力にそのまま渡してスレッドグループメモリの往復を排除する、という新 API を売りにしているのを見ると、この階層を気にしているのは間違いありません。

これは前節までのプリフィルの話に直結します。展開の演算コストがサイクルの12%程度という概算をしましたが、それとは別に、スレッドグループメモリを4倍使っている分がタイルサイズの上限を縛っています。演算律速の領域ではタイルが大きいほど演算強度が上がるので、ここは効く可能性があります。

世代をまたぐ移植性と、意味論の所在

もう2つあります。

ひとつは移植性です。TensorOps は利用可能なハードウェア加速を世代を問わず自動的に使うと説明されています。仮に M6 で FP4 のデータパスが入ったとき、ネイティブ型を使っていれば自動的に恩恵を受けます。自前カーネルは書き直しになります。

もうひとつは意味論の所在です。スケール平面の型は UE8M0 で、符号なしであることが型名に入っています。仕様が定義を持っているので、実装が解釈を埋める余地がない。MLX が NVFP4 で符号付きの E4M3 を使ってしまった種類の事故は、この経路では起きません。

第8章で、実装定義の余地が相互運用性の穴になると書きました。ネイティブ型を使うことは、その穴を仕様側に返すことでもあります。

三つのシナリオと、見分け方

整理します。ネイティブ型に切り替えたときに起こりうることは、3通りです。

シナリオ	起きること	見分け方
FP4 のデータパスがある	演算スループットが上がる	MXFP4 の matmul2d が FP16 より速い
展開が固定機能側にある	演算は同速だがスレッドグループメモリが空く	速度は同等だがタイルを大きく取れる
ライブラリ内のソフト展開	ほとんど変わらない	FP16 以下に留まる

Rigel が M4 Max で観測したのは3つめでした。fp8 が fp16 の0.94倍。M5 が1つめか2つめに移ったかは未測定です。

個人的には2つめが本命だと思っています。Apple は量子化を一貫してメモリ帯域と容量の文脈で説明していて、スループットの文脈では説明していない。逆量子化を自動処理すると明記していることも、演算器が4ビットを直接食うわけではないことを示しています。

ただしこれは推測です。確かめるには、同じタイル形状で FP16 版とネイティブ MXFP4 版の GEMM を組んでスループットを比べるしかありません。Rigel が M4 Max でやったことを、対象を M5 に変えてやるだけです。

なぜ MLX は使っていないのか

どちらも Apple なのだから揃えればいいのに、と思うところです。ただ MLX は ml-explore で公開されているオープンソースで、コミットは日次。Metal は OS に同梱されて年次で出ます。制約が違います。

ソースからいくつか具体的な理由が読めます。

いちばんはっきりしているのは対応 OS のずれです。MLX の is_nax_available() は macOS 26.2 以降を要求します。一方、MTLTensor がスケール平面を持てるようになったのは macOS と iOS 27 からです。つまり MLX が Neural Accelerator 対応を書いた時点で、ネイティブの量子化テンソル型はまだ存在しませんでした。いま切り替えると 26.x のユーザーが 4ビットを使えなくなるので、自前実装を残したまま 27 以降だけ別経路にするしかない。二重管理になります。

次にカバー範囲です。MLX がインスタンス化している量子化の組み合わせを数えると、こうなります。

モード	組み合わせ数
affine	グループ 32/64/128 × ビット 2/3/4/5/6/8 × 型3種 = 54
nvfp4 / mxfp8 / mxfp4	3モード × 型3種 = 9

計63です。このうち Metal のスケール平面に乗せられるのは、UE8M0 スケールを使う mxfp4 と mxfp8 の6通りだけ。残り57通りは自前実装が要ります。

しかも MLX の既定は affine 量子化で、スケールとバイアスを持つ非対称方式です。Metal のスケール平面はスケールのみで、バイアスに相当するものがありません。最も使われている経路が、そもそもネイティブ型では表現できない。

バックエンドの事情もあります。MLX には cpu、cuda、metal が並んでいて、CUDA 側にも同じ量子化仕様の実装があります。数値挙動を揃えたいなら、片方だけプラットフォーム固有の経路に寄せるのは扱いにくい。

加えて nax のカーネルは、転置の有無、K のアライメント、MoE ルーティング用の gather 版まで含めてインスタンス化の行数だけで75行あります。エキスパートごとに違う重みを引いてくる経路まで自前の loader に乗っている。ネイティブ型がこれらすべてと合成できるかは、外からは分かりません。

そして前節のとおり、速くなるとも限りません。

対応 OS のずれと affine の非対応は、仕様とソースから確定できる話です。残りは推測を含みます。MLX チームによる公式な説明は見つかりませんでした。

Ollama も Apple Silicon では MLX をバックエンドにしているので、同じことが言えます。いま手元で MXFP4 のモデルを動かして得られるのはメモリフットプリントの削減と帯域の削減であって、Blackwell のような演算スループットの向上ではない。ただしそれはランタイムの現状であって、シリコンの限界だと確認されたわけではありません。

この違いは、プリフィルとデコードで効き方が分かれる形で現れます。

Apple Machine Learning Research が公開した M5 と M4 の比較を見ると、傾向がはっきり出ています。

モデル	TTFT 速度向上	生成速度向上	メモリ (GB)
Qwen3-1.7B bf16	3.57×	1.27×	4.40
Qwen3-8B bf16	3.62×	1.24×	17.46
Qwen3-8B 4bit	3.97×	1.24×	5.61
Qwen3-14B 4bit	4.06×	1.19×	9.16
gpt-oss-20b MXFP4	3.33×	1.24×	12.08
Qwen3-30B-A3B 4bit	3.52×	1.25×	17.31

プリフィル（TTFT）は3.3倍から4.1倍まで伸びています。これは演算律速なので、Neural Accelerator の追加がそのまま効く。一方で生成速度は1.19倍から1.27倍に収まっていて、M5 のメモリ帯域が M4 比で約28%増（153 対 120 GB/s）であることとほぼ一致します。デコードは帯域律速なので、演算器を足しても伸びない。

言い換えると、Mac で4ビット化して速くなるのはデコード側だけで、それは帯域が減ったからです。プリフィルが速いのは Neural Accelerator の FP16 性能によるもので、4ビットであることとは関係がありません。

この表は、前節で空白だと書いた論点への間接的な手がかりにもなっています。MXFP4 でネイティブに配布されている gpt-oss-20b の TTFT 向上は3.33倍で、bf16 の Qwen3-8B の3.62倍を下回っています。MXFP4 に専用の演算経路があるなら、プリフィルでもっと差が付いてよいはずです。付いていない。

ただしこれは決定的な証拠ではありません。比較の分母である M4 には Neural Accelerator がそもそも無いので、この比はどの形式でも「Neural Accelerator が付いたこと」に支配されます。モデルもアーキテクチャも違うので、形式だけを切り出した比較になっていません。あくまで傍証です。

M5 Max なら614 GB/s（40コア版）あるので、デコード側の恩恵は相応に大きい。ただ、その恩恵は「4ビットにしたから」であって「MXFP4 だから」でも「NVFP4 だから」でもありません。

11. MLX、Ollama、llama.cpp での実際

MLX は量子化モードとして affine（デフォルト）、mxfp4、mxfp8、nvfp4 に対応しています。mx 系はグループサイズ32が必須、nvfp4 は16が必須で、これは仕様どおりです。

注意点がいくつかあります。

NVFP4 のグローバルスケールを扱う global_scale パラメータは、対応バックエンドが CPU と CUDA とされています。Metal 側での扱いは実際に使うバージョンで確認したほうがいいところです。

さらに前章で触れたとおり、MLX の nvfp4 実装は符号付き E4M3 をブロックスケールに使っていて、NVIDIA Blackwell が使う符号なし UE4M3 と非互換です。大きな重みや活性値でクリップする問題が報告されています。Mac 上の NVFP4 の数値挙動が NVIDIA のリファレンスと一致しない可能性がある、ということです。

MLX 標準の affine 量子化も押さえておく価値があります。これはスケールとバイアスを持つ非対称方式で、グループサイズ64なら 4 + 32/64 = 4.5 bit / 要素。NVFP4 と同じビット予算を、より表現力の高いスキームで使えます。Mac では演算経路が共通なので、MXFP4 や NVFP4 をわざわざ選ぶ理由は精度というより、チェックポイントの可搬性にあります。

# HuggingFace のモデルを MLX 形式に変換して量子化
mlx_lm.convert \
  --hf-path mistralai/Mistral-7B-Instruct-v0.3 \
  -q \
  --upload-repo mlx-community/Mistral-7B-Instruct-v0.3-4bit

なお、M5 の Neural Accelerator を使うには macOS 26.2 以降が必要です。Apple の記事にも明記されています。

Ollama は2026年3月末の 0.19 プレビューで Apple Silicon のバックエンドを MLX へ移行し、NVFP4 対応を追加しました。Linux と Windows は llama.cpp のままです。公式ブログの謝辞には NVIDIA の貢献者への言及があります。

公表されている測定値を引用します。M5 Max で Qwen3.5-35B-A3B を動かした2026年3月29日のテストで、NVFP4 がプリフィル 1810 t/s・デコード 112 t/s、比較対象の Q4_K_M（Ollama 0.18）がプリフィル 1154 t/s・デコード 58 t/s。ブログには int4 で 1851 t/s・134 t/s という数字も出てきますが、こちらは「will see」という将来値の書き方で、実測値ではありません。引用するときは区別が必要です。

llama.cpp 側では、gpt-oss がネイティブ MXFP4 形式のまま CUDA、Vulkan、Metal、CPU の全バックエンドで動きます。gpt-oss は 4.25 bit / パラメータで、FFN を MXFP4 のまま保つことが品質上必須とされています。NVFP4 は GGML_TYPE_NVFP4 として2026年3月末から4月末にかけて追加されました。

ランタイム	MXFP4	NVFP4	備考
MLX	対応	対応	Metal では逆量子化してから演算
Ollama（Apple Silicon）	対応	対応	0.19 以降は MLX バックエンド
llama.cpp	対応	対応	gpt-oss はネイティブ MXFP4
LM Studio	対応	—	MLX-MXFP4 形式を配布

12. 実測と選択指針

M5 Max（128GB）での第三者実測値を挙げます。個人による測定で、MLX のバージョンや構成によって変動する点は割り引いてください。

モデル / 量子化	コンテキスト	プリフィル (t/s)	デコード (t/s)
gpt-oss-120b MXFP4	4K	1,325	87.9
gpt-oss-120b MXFP4	16K	2,710	76.0
gpt-oss-120b MXFP4	32K	2,537	64.5
Qwen3.5-122B-A10B 4bit	4K	881	65.9
Qwen3.5-27B 6bit dense	4K	811	23.6

他機との比較も並べておきます。

機材	モデル	プリフィル (t/s)	デコード (t/s)
M5 Max 128GB	Qwen3.5-27B 6bit	811	23.6
RTX 5090 32GB	Qwen3.5-27B 6bit	2,884	49.1
M5 Max 128GB	gpt-oss-120b	1,325	87.9
RTX PRO 6000 96GB	gpt-oss-120b	6,512	221.3
DGX Spark 128GB	gpt-oss-120b	1,159	41

構図は素直です。演算器を持っている側がプリフィルで大きく勝ち、帯域を持っている側がデコードで健闘する。M5 Max の614 GB/s は DGX Spark の273 GB/s の約2.25倍で、デコードではその差がそのまま出ています。一方 RTX 5090 は32GBしかないので、長いコンテキストではそもそも載りません。

選択指針としてはこうなります。

状況	選ぶもの	理由
Blackwell で推論、精度優先	NVFP4	ネイティブ加速と精度を両取りできる
AMD Instinct で推論	MXFP4	NVFP4 は非対応
重みを配布する、複数ベンダで動かす	MXFP4	OCP 標準で可搬性が高い
Mac でローカル実行	MLX の affine 4bit	MLX 経由なら演算経路は共通なので素直な選択
Mac で gpt-oss を動かす	MXFP4 のまま	ネイティブ配布形式をそのまま使う
Mac で載るかどうかが問題	実効ビット数の小さい方	プリフィル速度より容量が効く場面がある
自前アクセラレータを設計する	MXFP4	スケール適用が指数加算で済む

おわりに

出発点は、前回の記事の第5章に書いた一行でした。Kimi K3 が MXFP4 を使っている、そしてそれは NVIDIA 独自の NVFP4 ではない、という話です。

調べてみると、その一行の裏にいくつかの層がありました。

MXFP4 と NVFP4 の違いは、要素の符号化ではなくスケールの粒度と型にあります。E8M0 が2のべき乗しか置けないという一点が、精度と実装コストの両方を規定している。NVFP4 は精度を取ってハードウェアを複雑にし、MXFP4 は実装の安さと標準化を取った。

中国ラボの採用については、Kimi K3 は最初ではありませんでした。主要なオープンウェイト LLM としては gpt-oss が先を行き、中国では DeepSeek-V4 が3ヶ月先行しています。Moonshot 自身も K2 Thinking で INT4 の QAT をやっていて、K3 はそこからの形式変更です。移植性の確保という読みは成り立ちますが、NVIDIA が DeepSeek-V4 を Blackwell 標的と説明していることを見ると、それだけが理由だと断定はできません。

そして、いちばん腑に落ちたのが DeepSeek-V4 の入れ子構造でした。MX 仕様が定めたブロック長32という数字が、DeepSeek-V3 以来の 128×128 FP8 ブロックにちょうど収まることで、既存の学習基盤を書き換えずに4ビット化できている。仕様書の一行が実装の設計余地を決めている、という半導体側の感覚に近い話で、ここが今回いちばん面白いところでした。

MLX がネイティブ型を使わない理由も、調べてみれば納得のいくものでした。スケール平面が使えるのは macOS 27 からで、MLX は 26.2 を切れない。しかも既定の affine 量子化はスケールとバイアスを持つ非対称方式で、スケールしか持てない Metal の平面では表現できません。手を抜いているのではなく、支えている裾野が広いということです。

標準化の側は、MX が v1.0 のまま止まっている一方で、IEEE P3109 が要素形式と演算のセマンティクスを、適合性ベクタが実装の一致を、それぞれ別の層で埋めにかかっています。NVFP4 がコンソーシアムに採択されなかったという事実は、当面この分裂が続くことを意味します。

最後に手元の話に戻ると、ここは書きながら一度立ち止まった箇所でした。Metal 4.1 は MXFP4 を型として持ち、Apple も WWDC でカーネルの書き方を示しています。にもかかわらず、M5 でそれが演算器レベルで加速されるかを示す公開測定は見当たりません。MLX v0.32.1 のソースを読むと、デバイスメモリからは4ビットのまま読み、スレッドグループメモリ上で展開してから行列積器に渡していました。したがって4ビット化で速くなるのはデコードだけで、それは帯域が減ったからです。プリフィルは演算律速なので、展開はむしろコスト側に回ります。前回の記事で見た「疎性のツケが推論に回る」という構図と、方向としては同じことを見ています。メモリと帯域が効く側に立っているかどうか。

7月27日に Kimi K3 のウェイトが公開されれば、どのレイヤーまで MXFP4 なのか、活性値の MXFP8 がどの演算範囲に適用されているのかが確認できるはずです。DeepSeek-V4 のようにルーテッドエキスパートだけなのか、より広い範囲なのか。そこが分かれば、第5章の推測はもう少し詰められると思います。

参考

仕様

• OCP Microscaling Formats (MX) Specification v1.0（仕様は2023年9月付、公開アナウンスは同年10月17日）
• Microscaling Data Formats for Deep Learning（arXiv:2310.10537）
• NVIDIA, Introducing NVFP4 for Efficient and Accurate Low-Precision Inference
• NVIDIA, NVFP4 Trains with Precision of 16-Bit and Speed and Efficiency of 4-Bit
• Pretraining Large Language Models with NVFP4（arXiv:2509.25149）

モデル

• DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence（arXiv:2606.19348）
• DeepSeek-V4-Pro モデルカード（FP4 と FP8 の混合構成）
• Kimi K3 技術ブログ（Moonshot AI、2026年7月16日）
• Kimi K2 Thinking モデルカード（INT4 QAT）
• DeepSeek-V3 Technical Report（arXiv:2412.19437、FP8 128×128 ブロック）

ハードウェアとランタイム

• NVIDIA Blackwell B200 データシート
• AMD Instinct MI355X 製品ページ
• Apple, Exploring LLMs with MLX and the Neural Accelerators in the M5 GPU
• Investigating the GPU Neural Accelerators on Apple A19/M5（tzakharko によるマイクロベンチマーク）
• Rigel: Reverse-Engineering the Metal 4.1 Tensor Compute Path on the Apple M4 Max GPU（arXiv:2606.12765）
• MLX ドキュメント（mlx.core.quantize / dequantize）
• MLX ソースコード v0.32.1（mlx/backend/metal/kernels/fp_quantized_nax.h、steel/gemm/nax.h、mlx/backend/metal/device.cpp）
• MLX Issue #2962（nvfp4 の符号付き E4M3 問題）
• Ollama Blog（MLX バックエンドと NVFP4 対応）
• llama.cpp Discussion #15095（gpt-oss のネイティブ MXFP4 対応）

標準化

• IEEE P3109 Standard for Arithmetic Formats for Machine Learning（Active PAR、2023年2月承認）
• Novel Aspects of IEEE SA P3109 Arithmetic Formats for Machine Learning（arXiv:2606.04028）
• An 84-Format Numeric Catalog with Bit-Exact Conformance Vectors（arXiv:2606.09686）
• Nanoscaling Floating-Point (NxFP)（arXiv:2412.19821）
• MX+: Pushing the Limits of Microscaling Formats for Efficient Large Language Model Serving（arXiv:2510.14557、MICRO 58、2025年10月）
• MX-SAFE（arXiv:2605.24391）

精度に関する研究

• Bridging the Gap Between Promise and Performance for Microscaling FP4 Quantization（arXiv:2509.23202、ICLR 2026。MR-GPTQ を提案）
• DuQuant++: Fine-grained Rotation Enhances Microscaling FP4 Quantization（arXiv:2604.17789）
• Unveiling the Potential of Quantization with MXFP4（arXiv:2603.08713）
• FP4 All the Way: Fully Quantized Training of LLMs（arXiv:2505.19115）

前回の記事

• 中国ラボはどこから計算資源を調達しているのか調べてみた

数字の扱いについて

• 仕様上の数値（ブロック長、ビット数、実効ビット数）は OCP 仕様書と NVIDIA 公式資料に基づく確定値です
• M5 Max の約70 TFLOPS FP16 は、A19 の実測値からの外挿による推定値です。Apple の公表値ではありません
• Apple Machine Learning Research のベンチマークは M5 の無印（24GB）と M4 の比較で、M5 Max の値ではありません
• M5 Max の実測値は個人による測定で、MLX のバージョンや構成により変動します
• Ollama ブログの int4 における 1851 t/s・134 t/s は将来値の記述であり、実測値として引用すべきではありません
• DeepSeek-V4 の「FP4 から FP8 への逆量子化が可逆」という性質は、重み分布が特定の条件を満たすことを前提としており、DeepSeek 自身も経験的な確認と述べています
• MX 仕様の変換アルゴリズムは実装定義の余地があり、スケール後のブロック最大値がどこに着地するかは選んだ流儀に依存します。本文では第4章でその前提を明示しています
• 第7章の B200 の数値は単体・密（非スパース）で統一しています。疎の値や筐体合計の値と混在させないでください
• 第11章と第12章のランタイム性能値およびベンチマーク値は、公式ブログまたは個人による測定に基づく二次情報です。一次測定として引用しないでください
• Apple の Neural Accelerator に関する毎サイクルあたりの演算数と実測ピークは、A19（iPhone 17、5コア）を対象とした第三者のマイクロベンチマークであり、M5 の実測ではありません。また測定は Xcode 26.1 時点のもので、Metal 4.1 が fp4 と MXFP4 を露出する前のものです
• 第9章のタイルあたりのサイクル数比は、演算量とレート差からの概算であり、実測ではありません。オーバーラップの効き方は実装とスケジューリングに依存します
• 第10章の「なぜ MLX は使っていないのか」のうち、対応 OS のずれと affine の非対応はソースと仕様から確定できます。それ以外は推測を含み、MLX チームによる公式な説明ではありません
• 第10章のスレッドグループメモリのサイズは、MLX のタイル形状 64×64×64 からの計算値です。TensorOps が内部でどこに展開しているかは非公開であり、ネイティブ型を使った場合の実際の消費量は確認していません
• MLX の逆量子化に関する記述は、v0.32.1 のソースコードを直接読んで確認したものです。将来のバージョンで Metal のネイティブ MXFP4 テンソル型に切り替わる可能性があります
• M5 上で fp4 または MXFP4 の行列積スループットを FP16 と比較した公開測定は、調べた範囲では見つかりませんでした。本記事は「加速されない」と断定していません
• Metal 4.1 のテンソル経路に関する解析論文の測定対象は M4 Max であり、論文自身が他の Apple GPU について主張しないと明記しています
• OCP MX 仕様の後継版が存在しないことは、公開情報を調べた範囲での結論です。策定作業が非公開で進んでいる可能性は排除できません
• Kimi K3 の詳細な技術報告は本記事執筆時点で未公開です。MXFP4 と MXFP8 の適用範囲は公式ブログの記述に基づく理解にとどまります