【geek-terminalニュース】FP4互換問題でローカルLLM量子化がフォーマット戦争に突入

【事象の全貌と背景】

以前お伝えした量子化やローカル推論高速化の続報です。今回の主役は、単にFP4が速いか遅いかではありません。ローカルLLM界隈で火種になっているのは、FP4推論エンジン、モデル形式、GPU世代、ランタイム、配布チェックポイントが噛み合わないことで、ベンチマーク上の高速化がそのまま現場の快適さに変換されない問題です。つまり、量子化がついに「重みを4bitにしました、VRAMが浮きました」で終わらず、運用の泥臭い互換性問題として噴き出してきました。

公式に確認できる事実として、NVIDIAは複数のNVFP4チェックポイントをHugging Face上で公開しています。Llama 4 Scout 17B 16E Instruct NVFP4、DeepSeek-V3.1-NVFP4、Qwen3-8B-NVFP4などは、元モデルをTensorRT Model OptimizerなどでFP4化した派生モデルとして説明されています。これらは重みとアクティベーションをFP4へ量子化し、TensorRT-LLMなど特定の推論スタックで使えるようにしたものです。DeepSeek-V3.1-NVFP4ではテストハードウェアとしてB200が明記され、Llama 4 Scout系では16bitから4bitへ落とすことでディスクサイズとGPUメモリ要件が約3.3倍削減されるとされています。DeepSeek-V3.1-NVFP4では8bitから4bitへの圧縮で約1.6倍削減と説明されています。

ただし、この公式事実から言えるのは「NVIDIAがNVFP4モデルを出している」「FP4はメモリとディスクサイズを減らす」「想定ランタイムやハードウェア条件がある」というところまでです。コミュニティで語られている互換性地獄、特定GPUでの失速、MXFP4とNVFP4の優劣、loader patch、MTP層の欠落といった話は、現時点ではユーザー報告として扱うべきです。ここを混ぜると、FP4が万能なのか危険なのかという雑な話になってしまいます。

【技術的ディープダイブ】

今回の混乱の根には、コンテナ形式と量子化方式の混同があります。MarkTechPostの記事では、GGUF、safetensors、PyTorchの.bin/.ptなどはテンソルをディスク上に保存するコンテナ形式であり、GPTQやAWQは重みを低ビット化する量子化手法だと整理されています。GGUFはllama.cppやOllama系のローカル実行で広く使われる保存形式、GPTQやAWQはGPU推論向けのポストトレーニング量子化、EXL2/EXL3はExLlama系の形式として位置づけられています。ここを取り違えると、「GGUFだから速い」「FP4だから動く」「AWQだから互換」といった危ない短絡が起きます。

FP4も一枚岩ではありません。コミュニティでは、NVFP4、MXFP4、modelopt_fp4などの名前が飛び交っています。公式に確認できる範囲では、NVIDIAのGLM-5.1-NVFP4モデルカードにはSGLangで起動する場合に–quantization modelopt_fp4を指定する例があり、vLLM向けにはvllm/vllm-openai:v0.19.1のDockerイメージを使う例も示されています。つまりFP4モデルはTensorRT-LLMだけの話ではなく、SGLangやvLLMにも広がっています。ただし「広がっている」ことと「どこでも同じ性能で動く」ことは別です。

特に厄介なのは、速度がprefillとdecodeで違うこと、複数GPUが常に生成速度を上げるわけではないこと、GPU間通信やVRAMの一時領域が詰まりやすいことです。ユーザー報告では、gpu-memory-utilizationを最大VRAM使用量のつもりで上げると逆にOOMへ向かう、CUDA contextやruntime、graphsなどの一時メモリを残す必要がある、といった運用知が共有されています。これはいかにもローカルLLMらしい現実で、理論上の圧縮率より、起動コマンド、loader、カーネル、GPUトポロジー、P2P、NVLinkの有無が結果を支配します。

【コミュニティの生々しい熱量と議論】

Reddit / LocalLLaMA周辺での温度感はかなり生々しいです。あるユーザーは「今はIQ4_XS GGUFを走らせる」とし、Pro 6000上のNVFP4については、sm_120にtcgen05がなく、データセンターBlackwellの本来の高速経路に乗らないため「hit or miss」だと報告しています。さらに、2441 t/sのQwen系NVFP4報告のような派手な数字はあるものの、正確なbuildに強く依存し、GGUFの方が予測可能だという見方が出ています。ここは確度B、つまりユーザー報告として読むべきですが、現場の痛みとしては非常に説得力があります。

別の議論では、MXFP4 GGUFはMoEモデル向けで、dense modelには意味が薄いという指摘が出ています。さらに、MXFP4は32要素ブロックとE8M0スケール、NVFP4は16要素ブロックとFP8 E4M3スケールを使うため、dense modelではMXFP4がINT4より悪くなる場合がある、というかなり踏み込んだ主張もあります。これも公式裏付け済みの一般法則として断定はできませんが、「同じFP4でも中身が違う」という論点を読者に突きつけるには十分です。

ハックの濃さもLocalLLaMAらしいです。あるユーザーは、モデル作者がMTP layersを落としていたため、別のQwen3.8モデルからMTP層を移植したと報告しています。しかも、その作業をAI agentにやらせて「one shotted it」と語っています。別の投稿では、loader patchが必要だがアップロード可能、ただしadversarial needle in a haystack系の難しいテストではattention/recall問題が見える、としています。ここで面白いのは、量子化が「モデルサイズ削減」ではなく、欠落レイヤーの移植、loader patch、KV cache評価、公式ベンチ前の独自検証まで含む半分リバースエンジニアリングの遊びになっていることです。

さらに情報流通への不満もあります。「Discord, where information goes to die」「Friends don’t make friends use Discord, they post what they know on public boards.」という声は象徴的です。FP4互換性のような問題は、特定Discordの断片ログに閉じると再現性が死にます。どのcommit、どのCUDA、どのGPU、どのモデルカード、どのloader patchなのかが残らなければ、次の人は同じ沼に落ちます。

【今後の展望とエコシステムへの影響】

今回のパラダイムシフトは、量子化の勝者が「一番小さい形式」でも「一番速いベンチ」でもなく、「一番再現しやすく、ランタイムに優しく、配布者と利用者の間で壊れにくい形式」になる可能性です。NVFP4はNVIDIA公式モデルが増え、B200やTensorRT-LLMといった条件下では強い選択肢になり得ます。一方で、ローカルLLM勢にとってはGGUFの予測可能性、llama.cppの移植性、Ollama系の扱いやすさ、EXL2系のGPU特化運用も捨てられません。

オワコン化しそうなのは、「FP4対応」とだけ書いて細部を隠す雑なモデル配布です。これからは、量子化方式、コンテナ、対応ランタイム、検証GPU、prefillとdecodeの別スループット、VRAM実測、既知のloader patch、MoEかdenseか、欠落レイヤーの有無まで書かないモデルカードは信用されにくくなります。逆に伸びるのは、モデル配布をソフトウェアリリースのように扱う文化です。

ローカル推論はクラウドAPIの価格改定、スロットリング、モデル廃止へのヘッジでもあります。しかしヘッジとして成立するには、自宅や小規模チームのGPU環境で、昨日動いたモデルが明日も動く必要があります。FP4互換問題は、ローカルLLMが趣味の高速化競争から、小さなインフラ運用へ移行しているサインです。次の争点は「どの量子化が速いか」ではなく、「どの量子化なら、半年後の自分と他人が同じ結果を再現できるか」です。