Explainers

NVFP4がBlackwell GPUで拡散モデルを1.68倍高速化

BlackwellのNVFP4フォーマットが拡散モデルを1.68倍高速化、Flux.1-Devで驚異的なスピードアップを達成。これは量子化の銀の弾丸か、それともNVIDIAの最新の威光か?

{# Always render the hero — falls back to the theme OG image when article.image_url is empty (e.g. after the audit's repair_hero_images cleared a blocked Unsplash hot-link). Without this fallback, evergreens with cleared image_url render no hero at all → the JSON-LD ImageObject loses its visual counterpart and LCP attrs go missing. #}
BlackwellのNVFP4、拡散モデルを1.68倍高速化 [ベンチマーク] — Open Source Beat

Key Takeaways

  • NVFP4は、Diffusers/TorchAOを使用したFlux.1-Devで1.68倍の推論速度向上を実現。
  • MXFP8は1.26倍に達し、低バッチに最適。NVFP4は高バッチワークロードを制する。
  • Blackwell B200が必要。コードはGitHubリポジトリで完全に再現可能。

パイプラインをロード。プロンプトを投入:「こんにちは世界と書かれたサインを持つ猫」。出力は数分ではなく数秒で吐き出される。NVIDIAのBlackwellアーキテクチャ、特にB200が、NVFP4MXFP8量子化によってこれを実現し、Flux.1-Devのような拡散モデルを最大1.68倍高速化させている。

視野を広げよう。拡散モデルは画像・動画生成の王様であり、超リアルなビジュアルを大量に生み出している。問題は? 燃費危機のハマーのようにメモリと計算能力を貪り食うことだ。量子化がその解決策として登場し、BlackwellネイティブのNVIDIAのミクロスケーリングフォーマットは、品質低下なしでのスピードという聖杯を約束する。

MXFP8とNVFP4は具体的に何をしているのか?

OCP標準の8ビットチャンピオンであるMXFP8(E4M3/E5M2)は、テンソルを32要素ブロックにグループ化し、8ビットスケールを使用する。NVFP4は? NVIDIAの4ビットの雄(E2M1)で、ブロックサイズ16、FP8スケール、Tensor Coreが超強化されている。理論上はスループットが劇的に向上するはずだ。NVFP4はBF16と比較してメモリを3.5倍削減する。現実の結果は? Flux.1-Dev、QwenImage、LTX-2でのエンドツーエンドベンチマークは、MXFP8で1.26倍、NVFP4で1.68倍に達した。

ここで重要なのは、選択的量子化、CUDA Graphs、LPIPSメトリックだ。彼らはプロのようにイテレーションを繰り返し、パフォーマンスと忠実度のバランスを取った。ドライなユーモアに触れる:LPIPSは低く抑えられ、あなたの猫の画像が突然ピカソの駄作のように見えなくなることを意味する。

“NVIDIA B200上で、Diffusersとtorchaoを使用して、Flux.1-Dev、QwenImage、LTX-2モデルでMXFP8で最大1.26倍、NVFP4で最大1.68倍のエンドツーエンド推論速度向上を再現可能に実証しました。”

NVIDIAの投稿からのこの引用? 価値がある。再現可能。特定のモデル。空虚な約束ではない。

しかし待て。CUDA 10.0が最小要件。NVFP4にはB200が必要だ。もしA100をまだ使っているなら、残念だが—このパーティーの招待状は選ばれた者だけだ。

conda create -n nvfp4 python=3.11 -y
conda activate nvfp4
pip install --pre torch --index-url https://download.pytorch.org/whl/nightly/cu130
pip install --pre torchao --index-url https://download.pytorch.org/whl/nightly/cu130
pip install --pre mslk --index-url https://download.pytorch.org/whl/nightly/cu130
pip install diffusers transformers accelerate sentencepiece protobuf av imageio-ffmpeg

2026年3月のナイトリービルド—PyTorch 2.12.0.dev、TorchAO 0.17.0.dev。モデルにはHFログインが必要。いつもの手順だ。

拡散パイプラインを量子化する方法

TorchAOはDiffusersにシームレスに統合される。これを見てくれ:

from diffusers import DiffusionPipeline, TorchAoConfig, PipelineQuantizationConfig
import torch
from torchao.prototype.mx_formats.inference_workflow import (
    NVFP4DynamicActivationNVFP4WeightConfig,
)

config = NVFP4DynamicActivationNVFP4WeightConfig(
    use_dynamic_per_tensor_scale=True, use_triton_kernel=True,
)
pipe_quant_config = PipelineQuantizationConfig(
    quant_mapping={"transformer": TorchAoConfig(config)}
)
pipe = DiffusionPipeline.from_pretrained(
    "black-forest-labs/FLUX.1-dev",
    torch_dtype=torch.bfloat16,
    quantization_config=pipe_quant_config
).to("cuda")
pipe.transformer.compile_repeated_blocks(fullgraph=True)
pipe_call_kwargs = {
    "prompt": "A cat holding a sign that says hello world",
    "height": 1024,
    "width": 1024,
    "guidance_scale": 3.5,
    "num_inference_steps": 28,
    "max_sequence_length": 512,
    "num_images_per_prompt": 1,
    "generator": torch.manual_seed(0),
}
result = pipe(**pipe_call_kwargs)
image = result.images[0]
image.save("my_image.png")

全てのLinearレイヤーが量子化される。fullgraph=Trueでのリージョンコンパイル—コンパイル時間を短縮し、ほぼ完全なパフォーマンスを発揮する。MXFP8への切り替え? configサブクラスを調整するだけだ。Tritonカーネルが強力だ。

Flux.1-Devでのベンチマークは、まさにこれらのkwargsを使用:1024x1024、28ステップ、guidance 3.5。結果は? NVFP4は高バッチ実行を圧倒し、MXFP8は低バッチレイテンシを制する。

NVIDIAの戦略? 洗練されている。しかし、彼らがスキップしている辛辣な洞察がある:これは2017年のVoltaにおけるFP16 Tensor Coreのデビューを彷彿とさせる—ソフトウェアが追いつくまで、ハイプマシンは稼働し、採用は遅れた。大胆な予測:NVFP4はBlackwellを拡散モデルの支配に固定するだろうが、本格的な実用化までにはTorchAOの成長痛が6〜12ヶ月続くと予想される。

なぜこれが拡散モデル開発者にとって重要なのか?

速度向上は抽象的なものではない。1.68倍は、より多くのユーザーにサービスを提供し、コストを削減することを意味する—つまり、実際の金銭だ。QwenImage、LTX-2がFluxに加わり、クロスモデルでの勝利。選択的量子化は、デリケートなブロックでの精度低下を回避する。CUDA Graphsはオーバーヘッドを削減する。LPIPSは、ビジュアルゴミがないことを検証する。

懐疑論チェック:B200 DGXでのベンチマーク。あなたの結果は? バッチサイズ、モデル、プロンプト長によって変動する。高バッチNVFP4が輝き、小バッチではMXFP8が優位に立つ。企業のPRはそれを美化する—いつもそうだ。

ユニークな視点:AWQ/GPTQ量子化戦争を覚えているか? このミクロスケールへの飛躍はBlackwell上でそれらを凌駕するが、Hopper/Ampereへの移植性は低い。NVIDIAのエコシステムロックインは、11倍に調整されている。

MXFP8は業界標準になるか? OCPの支援は役立つが、NVFP4のBlackwell限定は、明確な堀を叫んでいる。開発者諸君:リポジトリをフォークし、数値を再現してみるがいい。テストされていないクールエイドは飲まないこと。

NVFP4は全てのワークロードでBF16に取って代わるか?

いや。計算負荷が高く、バッチサイズが大きいワークロード? はい。メモリが限られたビデオ生成? 間違いなく。しかし、ダイナミックレンジは様々だ—テンソルごとのスケールは緩和するが、奇跡ではない。LPIPSの低下は忠実度が維持されていることを証明するが、外れ値は潜んでいる。

TorchAOの統合? 今はスムーズだが、ナイトリービルドは無視できない。安定版リリースが間もなく登場するだろう、そう bet する。

Blackwellのオーナーはお祝いしよう。それ以外? 2027年のアップグレードまで待て。NVIDIAは、再び—ハードルを上げたのだ。

**


🧬 関連インサイト

よくある質問**

NVFP4量子化とは何ですか? NVIDIAの4ビット浮動小数点フォーマット(E2M1)で、16要素ブロックとFP8スケールを持ち、Blackwell Tensor Coreネイティブで最大スループットを実現します。

拡散モデルにおけるMXFP8の速度はどのくらい向上しますか? Diffusers/TorchAO経由のFlux.1-Devで最大1.26倍のエンドツーエンド性能。LPIPSによる品質損失はほぼゼロです。

これらの速度向上にはB200 GPUが必要ですか? NVFP4には必要です。CUDA 10.0が最小要件。ベンチマークはB200固有のものです。

Written by
Open Source Beat Editorial Team

Curated insights, explainers, and analysis from the editorial team.

Worth sharing?

Get the best Open Source stories of the week in your inbox — no noise, no spam.

Originally reported by PyTorch Blog