NunchakuのDiffusers対応でVRAM使用量は削減、ただしハードウェアの制約は依然として存在
- Aisha Washington
- 1 日前
- 読了時間: 19分
NunchakuのDiffusers対応により、ネイティブな4ビットチェックポイントの読み込みが実現し、これまで専用のセットアップが必要だったワークフローから独立した推論エンジンが不要になりました。Hugging Faceによると、新しいNunchaku Liteの経路では、推論を高速化しながらピーク時のVRAM使用量を最大50％削減できます。
重要な変化は、単に量子化の選択肢が増えたことではありません。DiffusersはNunchakuチェックポイントを認識し、選択された線形層を置き換え、互換性のあるカーネルをダウンロードし、from_pretrained()を通じてパイプラインを読み込めるようになりました。
この利便性により、低メモリ推論で定着している重みのみの量子化手法に対する要求が高まります。bitsandbytes、GGUF、torchao、Quantoなどのバックエンドは、すでにDiffusers内で重みを圧縮しています。しかし通常、計算時にはそれらの重みをより高い精度へ戻すため、メモリ使用量の削減が自動的にレイテンシーの短縮につながるわけではありません。
これに対してNunchakuは、トランスフォーマー内で最も計算負荷の高い演算において、4ビットの重みと4ビットのアクティベーションを使用します。Hugging Faceは、ベンチマークにおいて大幅なメモリ削減とともに、コンパイルなしで約30％の速度向上を報告しています。
その代償となるのが、対応ハードウェアの範囲です。最速のNVFP4チェックポイントにはNVIDIA Blackwell GPUが必要であり、対応する旧世代のカードではINT4版が必要です。一部のデータセンター向けアーキテクチャには、依然として対応していません。
NunchakuのDiffusers対応が読み込み経路を変える
中心的な変化は運用面にあります。Nunchakuチェックポイントは、並行して別のランタイムを必要とせず、通常のDiffusersリポジトリと同じように扱えるようになりました。
開発者は、Diffusers、Transformers、Accelerate、kernels、bitsandbytesの新しいバージョンをインストールできます。その後、互換性のあるパイプラインを標準のパイプラインクラスとfrom_pretrained()で読み込めます。
Hugging FaceのNunchaku Liteの例では、ERNIE-Image-Turboチェックポイントが使用されています。このパイプラインはモデルをCUDAへ送り、ローカルでCUDAコードをコンパイルすることなく、1024×1024の画像を生成します。
初回実行時には、kernelsパッケージを通じて、必要なGPUカーネルがHugging Face Hubからダウンロードされます。これにより、デプロイはエンジンのインストール問題からチェックポイントの選択問題へと変わります。
量子化されたリポジトリには、トランスフォーマーの設定内にquantization_configブロックが含まれています。このブロックでは、対象となる各モジュール、その量子化方式、精度、グループサイズ、低ランク補正の有無を識別します。
Diffusersは、チェックポイントの重みを読み込む前に設定を読み取ります。そして通常のtorch.nn.Linearモジュールを適切なNunchaku Liteランタイム層に置き換えた後、量子化された値をそれらの置換先へ配置します。
2つの主要な層タイプは、拡散トランスフォーマーの異なる部分を担当します。SVDQ W4A4層は、計算負荷の高いアテンションと多層パーセプトロンの射影に、4ビットの重みとアクティベーションを使用します。
AWQ W4A16層は、4ビットの重みと16ビットのアクティベーションを組み合わせます。これは、精度に敏感でありながら計算量の少ない変調および適応的正規化の射影を対象としています。
この区分が重要なのは、一律の量子化では品質が損なわれたり、最適化の労力が無駄になったりする可能性があるためです。Nunchaku Liteは、低精度化によって最も多くの時間を節約できる演算に、より積極的な実行経路を割り当てます。
読み込まれたモデルは、Diffusersが想定するモジュール構造を維持します。そのため、スケジューラー、LoRAフック、オフロード機能、コンパイルツールは、使い慣れたインターフェースを通じてモデルと連携できます。
これがネイティブ対応の実用的な価値です。チームは周辺のパイプラインコードを維持したまま、高密度トランスフォーマーを互換性のある量子化チェックポイントに置き換えられます。
ネイティブ読み込みにより、配布も容易になります。公開者は、トランスフォーマー、その量子化メタデータ、残りのパイプラインコンポーネントを、一般的なHubリポジトリにまとめられます。
ユーザーには依然として適切なソフトウェアとGPUが必要です。しかし、モデルをテストする前に、アプリケーションをエンジン固有のパイプラインへ移植する必要はなくなりました。
これにより、個人開発者とプラットフォームチームの統合コストが下がります。またNunchakuは、ノイズ除去トランスフォーマー自体の外側にあるDiffusersの機能も利用できるようになります。
メモリ使用量の削減だけでは、もはや十分ではない
Nunchaku Liteは、推論速度とメモリ使用量を一体の問題として扱うことで、量子化の基準を引き上げます。
大規模なテキスト画像生成パイプラインは、最初の画像を生成する前からコンシューマー向けGPUを圧迫することがあります。Hugging Faceによると、最新のBF16パイプラインには20～30GBのVRAMが必要になる場合があります。
BF16、すなわちbfloat16は、各値を16ビットで格納します。数値範囲と計算効率のバランスに優れていますが、そのメモリ使用量がローカル環境へのデプロイを制限します。
重みのみの量子化は、この制約の一部に対処します。モデルの重みを多くの場合4ビットまたは8ビットの低精度で格納しつつ、アクティベーションと計算はより高い精度に維持します。
この手法では、格納されるモデルと常駐する重みを大幅に削減できます。しかし、推論中の重みの逆量子化によって処理が増え、アクティベーションも依然としてかなりのメモリを占有する可能性があります。
レイテンシーは同程度にとどまるか、わずかに増加することさえあります。ユーザーはメモリに収まるモデルを得られますが、必ずしも応答が速くなるわけではありません。
NunchakuのW4A4経路は、この計算を変えます。W4A4とは、選択されたトランスフォーマー演算において、重みとアクティベーションの両方に4ビット表現を使用することを意味します。
メモリ内を移動するデータ量が減り、対応カーネルは圧縮形式のまま、より多くの処理を実行します。そのため、ノイズ除去ループは、より少ないVRAMを消費しながら短時間で完了できます。
この手法が拡散トランスフォーマーを対象とするのは、そのアテンションとフィードフォワード射影が実行時間の大部分を占めるためです。繰り返し実行されるこれらの層には、専用の低ビット行列乗算経路を適用する大きな余地があります。
この手法では、すべてのコンポーネントを同じ方法で量子化するわけではありません。テキストエンコーダー、正規化層、変調射影では、性能と精度に関する要件が異なる場合があります。
Nunchaku Liteでは、そのトランスフォーマーとbitsandbytesのNF4テキストエンコーダーを組み合わせられます。NF4は、おおむね正規分布に従う値向けに設計された4ビット形式です。
Hugging Faceによると、テキストエンコーダーの量子化によって、ベンチマークにおけるピーク時のVRAM使用量が約22％削減されました。この削減効果は、トランスフォーマーの低精度経路による削減に上乗せされます。
この結果は、重みのみの量子化バックエンドに重要な変化を迫ります。メモリ削減が基本機能になりつつある一方、実用的な速度向上が差別化要因になります。
だからといって、既存のバックエンドが不要になるわけではありません。それらは異なるモデル、デバイス、精度の選択肢、デプロイ環境に対応しています。Nunchaku Liteより幅広いハードウェア互換性を現在提供しているものもあります。
また、アクティベーションの量子化が出力品質を損なう場合、重みのみの手法のほうが適用しやすいことがあります。スループットの最大化よりも、モデルをメモリに収めることが重要な場合には、引き続き有用です。
それでも、ネイティブなW4A4対応により、開発者が行うべき比較は変わります。選択肢はもはや、高密度モデルの精度と圧縮によるメモリ削減だけではありません。
チームは、メモリ、ノイズ除去のレイテンシー、コンパイル時間、ハードウェアの可用性、互換性、画像品質を比較する必要があります。NunchakuのDiffusers対応は、これらの要素を広く使われている1つのライブラリ内にまとめます。
この統合により、認知度も高まります。オリジナルのNunchakuエンジンを採用しなかった開発者も、標準的なDiffusersチェックポイントを探す中で、この形式に触れられるようになります。
SVDQuantは扱いにくい値を4ビット経路の外へ移す
速度とメモリに関する主張は、SVDQuantが数値的な外れ値を4ビットで実行される処理から分離できることに支えられています。
拡散トランスフォーマーの量子化が難しいのは、その重みとアクティベーションに大きな外れ値が含まれる場合があるためです。1つの粗いスケールで、一般的な値と異常に極端な値の両方を表現しなければなりません。
その範囲が広くなりすぎると、通常の4ビット丸めでは有用な細部が失われます。画像構造、テキスト描画、テクスチャ、プロンプトとの整合性が劣化する可能性があります。
SVDQuantは、アクティベーションの外れ値を重み側へ移すことで、この問題に対処します。その後、各重み行列で最も扱いにくい部分を、小規模な16ビット低ランク分岐で表現します。
残りの残差には、4ビットの重みとアクティベーションを使用できます。これにより、計算負荷の高い主要経路を圧縮したまま、量子化が難しい情報のための高精度経路を維持できます。
SVDQuant論文では、この分解手法とNunchakuを支えるシステム設計について説明しています。その目的は、単にチェックポイントのサイズを削減することではありません。
オリジナルのNunchakuエンジンは、低ランク補正を周囲の4ビット計算と融合します。カーネル融合は、本来であれば個別に起動され、中間値をメモリ内で移動させる複数の演算を組み合わせます。
低ランクのダウン射影は、入力の量子化と結合されます。対応するアップ射影は、4ビット行列乗算と結合されます。
これらの融合により、16ビット補正分岐がW4A4実行の利点を打ち消すのを防げます。また、量子化された重みと同じくらい専用カーネルが重要である理由も、ここにあります。
Nunchaku LiteはSVDQuantの中核となる層を維持しつつ、より汎用的な統合経路を採用しています。アーキテクチャ固有のエンジンでパイプライン全体を置き換える代わりに、通常のDiffusersモジュールへパッチを適用します。
汎用性にはオーバーヘッドが伴います。オリジナルのエンジンは、特定のモデルファミリーの正確な構造に基づいて演算を結合できますが、Lite経路では標準的なDiffusersモジュールを尊重する必要があります。
アテンションは、その分かりやすい例です。一部の最適化された実装では、クエリ、キー、バリューの射影を1つのグループ化された演算にまとめます。
通常のDiffusersトランスフォーマーでは、これらの射影を別々のモジュールとして格納できます。汎用ローダーが、融合されたチェックポイントをその構造へどう対応付けるべきか、常に推測できるとは限りません。
Nunchaku Liteは、単純なモジュールを量子化設定によって処理します。構造の書き換えには、依然としてモデル固有のターゲット設定と小規模なランタイムアダプターが必要です。
Hugging Faceは、クエリ、キー、バリューの融合射影をその一例として挙げています。アダプターでは、テンソルの順序と、グループ化されたパラメーターを移行先モジュールへどう対応付けるかを指定する必要があります。
この境界が、今回の統合による実質的な貢献を明確にしています。ネイティブ読み込みにより、一般的なNunchaku形式のチェックポイントは移植可能になりますが、アーキテクチャ固有の最適化作業が不要になるわけではありません。
Liteの設計は、より幅広いモデルへの対応と使い慣れたAPIを得る代わりに、ある程度の速度低下を受け入れています。Hugging Faceによると、基本実装でもアーキテクチャ固有の融合なしで約30％の性能向上を実現します。
コンパイルにより、繰り返されるグラフ演算を組み合わせ、残りのオーバーヘッドの一部を削減できます。しかし、事前準備の手順が増え、安定したグラフキャプチャに依存します。
このため、NunchakuのDiffusers対応は、新しいファイル形式ではなく仕組みの変化を意味します。量子化された値、ランタイム層、ダウンロード可能なカーネル、設定メタデータが1つのシステムとして機能します。
ベンチマークが示すのは性能向上であり、普遍的な結果ではない
Hugging Faceの数値は期待できるものですが、示しているのは1つのパイプライン、1つの解像度、1台のBlackwellワークステーション向けGPUでの結果です。
公開されたベンチマークでは、ERNIE-Image-TurboチェックポイントとNVIDIA RTX PRO 6000が使用されました。画像は1024×1024ピクセルの解像度で生成されました。
BF16ベースラインでは、パイプライン全体の実行に3.00秒を要しました。デノイジングループには2.86秒かかり、ピークVRAMは31.1 GBに達しました。
NVFP4を使用したNunchaku Liteは、パイプライン全体を2.27秒で完了しました。デノイジングループには2.13秒かかり、ピークメモリは20.6 GBまで減少しました。
この構成では、報告値として1.35倍の高速化を達成しました。割合に換算すると、パイプライン全体はBF16ベースラインより約24パーセント早く完了しました。
torch.compileを適用すると、パイプライン全体のレイテンシは1.68秒まで短縮されました。デノイジングには1.53秒かかり、ピークVRAMは20.6 GBのままでした。
Hugging Faceは、この結果を1.8倍の高速化として報告しています。したがって、このテストでは、コンパイルによって実行オーバーヘッドが削減された一方、メモリ使用量はさらに減少しませんでした。
別の構成では、bitsandbytes NF4を使用してテキストエンコーダーを量子化しました。この構成はパイプラインを2.29秒で完了し、ピークVRAM使用量は16.0 GBでした。
これはベースラインのメモリ使用量のおよそ半分です。また、未コンパイルのNunchaku構成で報告された1.35倍の高速化も維持しました。
これらの数値は、W4A4がメモリ使用量を削減しながら速度を向上できるという主張を裏付けています。ただし、すべての拡散トランスフォーマーやGPUで同一の改善が得られることを示すものではありません。
Hugging Faceの例では、ERNIE-Image-Turboは8回の推論ステップを使用します。デノイジングステップ数が多いモデルでは、固定されたパイプラインオーバーヘッドの配分が異なります。
解像度によっても、トランスフォーマーの計算量、アクティベーションメモリ、テキストエンコーディング、画像デコードのバランスが変化します。バッチサイズによって、そのバランスがさらに変わる可能性があります。
コンパイル結果については、特に慎重に扱う必要があります。初回実行時のコンパイルには、定常状態のレイテンシ測定には現れないオーバーヘッドが発生します。
同じグラフを繰り返し処理するアプリケーションでは、そのコストを分散できます。形状や設定を頻繁に変更するインタラクティブなワークフローでは、実用上のメリットが小さくなる可能性があります。
画質も別の制約です。Hugging Faceは、同一のシードと設定を使用した比較を提示し、結果はBF16に近いままであると述べています。
選択されたプロンプトでの視覚的な類似性は、体系的な評価に代わるものではありません。タイポグラフィ、複雑な人体構造、反復パターン、細かな空間関係では、広範なシーンに隠れていた誤差が明らかになる可能性があります。
モデルの公開者は、量子化チェックポイントを作成する際にキャリブレーションデータも選択する必要があります。キャリブレーション例は、スケールと低ランク補正がモデルの挙動をどのように表現するかに影響します。
そのため、チェックポイントは既知のプロンプト分布では良好に機能しても、別の領域ではより大きな差が生じる可能性があります。開発者は、公開されたベンチマークを保証として扱う前に、自分たちのプロンプトでテストすべきです。
正しい解釈は、より限定的ではあるものの、依然として意義があります。Hugging Faceが選定したBlackwell環境では、Nunchaku Liteは独立した推論エンジンを使わずにメモリを削減し、測定レイテンシを改善しました。
これはテストを正当化するには十分です。しかし、別のアーキテクチャ、解像度、サービスワークロードで正確な高速化率を予測するには不十分です。
ハードウェアサポートが最速の経路と最も広範な経路を分ける
主な制約はAPIではありません。チェックポイントの精度、カーネルサポート、GPU世代の組み合わせです。
NVFP4は、Blackwellハードウェア向けのNVIDIAの4ビット浮動小数点形式です。Nunchaku LiteのNVFP4チェックポイントには、RTX 50シリーズGPU、RTX PRO 6000、またはB200が必要です。
サポート対象のTuring、Ampere、Ada GPUを所有するユーザーは、INT4チェックポイントを使用する必要があります。Hugging Faceは、サポート例としてRTX 30シリーズ、RTX 40シリーズ、A100、L40Sハードウェアを挙げています。
この違いは、実用上の影響をもたらします。Blackwell向けに最適化されたチェックポイントを、同じカーネル経路を維持したまま古いカードへ単純に移すことはできません。
公開者は、NVFP4版とINT4版の両方を配布する必要が生じる可能性があります。ユーザーは大容量のモデルファイルをダウンロードする前に、自分のデバイスに合ったバリアントを選択する必要があります。
Hugging Faceによると、VoltaとHopperは現在、4ビットカーネルでサポートされていません。H100とH200システムがAIインフラで依然として広く使用されていることを考えると、Hopper経路がない点は注目に値します。
これにより、通常とは異なるデプロイ境界が生じます。一部の一般消費者向けRTXカードではNunchaku Lite INT4を使用できますが、高価なHopperサーバーでは現在の4ビット実装を使用できません。
ローダーは起動時にCUDA機能を検証します。サポートされていない組み合わせでは、互換性のないカーネルを暗黙的に実行するのではなく、エラーが表示されるはずです。
この検証は不正な出力を防ぎますが、フリートの断片化を解消するものではありません。複数世代のGPUを運用するクラウドサービスでは、世代ごとに異なるアーティファクトとルーティングルールが必要になる可能性があります。
元のNunchakuエンジンは、アーキテクチャ固有の融合経路によってさらに高速化できる環境では、引き続き重要です。Nunchaku Liteは、Diffusersの抽象化と標準的なパイプライン動作との互換性を優先しています。
したがって、開発者は「サポート」が持つ2つの異なる意味に直面します。ネイティブライブラリの読み込みはソフトウェアインターフェースを対象とする一方、高性能な実行は依然として専用カーネルに依存します。
この違いは、新しいモデルファミリーにも影響します。汎用スキャナーは、反復するトランスフォーマーブロック内の互換性のある線形層を識別できます。
アテンションおよび多層パーセプトロンの射影にSVDQ W4A4を割り当てられます。また、特定の変調層を認識し、AWQ W4A16処理を適用することもできます。
構造が単純なモデルは、付属の量子化ワークフローを通じて、キャリブレーションからパッケージ化されたDiffusersリポジトリへ移行できます。構造的な書き換えには追加のマッピングが必要です。
融合射影、分割テンソル、カスタムアテンションプロセッサ、特殊な正規化パターンでは、いずれも明示的なアダプターが必要になる可能性があります。ネイティブサポートはこの作業を減らしますが、完全になくすわけではありません。
LoRAの互換性も、検証が必要な領域です。標準的なモジュール構造により、Diffusersの読み込みフックは見慣れたモデルとして認識できます。
ただし、チェックポイントとアダプターの組み合わせごとに、依然としてテストが必要です。モデルが正常に読み込まれたとしても、すべてのLoRAが想定された量子化モジュールを対象にしているとは限りません。
CPUオフロードは、コンポーネントをシステムメモリとVRAMの間で移動することで、小容量GPUを支援できます。この手法はデバイスへの負荷を軽減しますが、転送レイテンシが増加する可能性があります。
したがって、最適な構成は実際の制約によって異なります。ワークステーションのユーザーはパイプラインを収めることを優先する一方、サービス運用者は定常状態のスループットを優先する可能性があります。
Nunchaku Diffusersにより、これらの選択肢を組み合わせやすくなります。ただし、どの組み合わせを利用できるかは、依然としてハードウェアサポートによって決まります。
Nunchaku Liteのリリース後に注目すべき点
次に試されるのは、ネイティブ読み込みによって、有望なベンチマークが広くサポートされるチェックポイントエコシステムへ発展するかどうかです。
最初の指標はチェックポイントの対応範囲です。Hugging Faceは現在、すぐに使用できる出発点としてERNIE-Image-Turbo、Krea 2 Turbo、コミュニティコレクションを取り上げています。
より広く普及するには、主要な拡散トランスフォーマーファミリー向けに保守されたバリアントが必要です。ユーザーが複数のNVIDIA世代にまたがるため、NVFP4版とINT4版の両方が重要です。
互換性のあるチェックポイントが継続的に提供されれば、汎用パッケージング手法が機能するという主張が強まります。リリースが少なければ、量子化とアダプター作業が依然として大きな障壁であることを示唆します。
2つ目の指標はカーネルの対応範囲です。Hopperのサポートは対応可能なデータセンター市場を大幅に拡大し、より多くの一般消費者向け構成への対応はデプロイの断片化を軽減します。
ハードウェア対応の拡大は、ベンチマーク比較の有用性も高めます。開発者は、Blackwell、Ada、Ampere、および一般的なサーバーアクセラレーター間で、同じチェックポイントを測定できるようになります。
サポート範囲が狭いままであれば、競合する量子化バックエンドは、より広範なデプロイ対応によって優位性を維持します。レイテンシ特性の魅力は劣る可能性がありますが、多くの場合、利用可能性が本番環境での選択を決定します。
3つ目の指標は、独立したワークロードテストです。Hugging Faceの測定値は明確な基準点を示していますが、本番環境の評価では、より多くのモデルと動作条件を対象にする必要があります。
有用なテストには、異なる解像度、デノイジングステップ数、バッチサイズ、スケジューラー、LoRAアダプター、プロンプト分布を含めるべきです。また、コンパイル時間と反復推論レイテンシを分けて測定すべきです。
画像評価は、視覚的に良好な例だけにとどめるべきではありません。テキスト描画、手、反復するオブジェクト、幾何学的なレイアウト、細かな質感は、量子化による変化を明らかにする可能性があります。
開発者は障害発生時の挙動も監視すべきです。コミュニティチェックポイントが増えるにつれて、サポートされていないカーネル、互換性のないアダプター、不正な構成ファイルに対する明確なエラーが重要になります。
業界全体の大きな傾向は明確です。拡散モデルはトランスフォーマー中心のアーキテクチャへ移行しており、そうしたアーキテクチャは多くのローカルGPUで利用可能な容量を超えるメモリを必要とします。
量子化は、ストレージ技術から実行戦略へと変化しています。成功するアプローチは、実用的な出力を維持しながら、メモリ、速度、統合コストを同時に改善しなければなりません。
Nunchaku Liteは4つの目標すべてに対応しますが、すべてのデバイスで同じように達成するわけではありません。その最も重要な成果は、W4A4推論を標準的なDiffusersワークフロー内に組み込んだことです。
現在Nunchaku Diffusersを検討している開発者にとって、妥当な次のステップは、代表的なプロンプトと対象ハードウェアを使用した管理されたベンチマークです。同一設定の下で、密なBF16、未コンパイルのNunchaku Lite、コンパイル済み実行を比較してください。ピークVRAM、初回実行レイテンシ、反復実行レイテンシ、目に見える出力の差異を記録してください。その後、アプリケーションで実際に使用するアダプターとオフロード機能をテストしてください。今回のリリースにより、その実験は大幅に容易になりましたが、最終的な答えは依然として実際のワークロードから得る必要があります。
