GitHub Repo
Transformers、層ごとの量子化設定を提案 同一モデルでNVFP4とFP8の混在を検証
11月2日に提出されたTransformersの提案は、モデルの各層を個別の量子化器で読み込めるようにし、FP8とNVFP4を混在させた小規模モデルでテストしています。提案はまだマージされておらず、実モデルでの精度、メモリ使用量、推論性能は未検証です。

Hugging Face TransformersのコントリビューターであるArthurZuckerは11月2日、同じモデルチェックポイント内の異なるモジュールを、それぞれ対応する量子化器で読み込めるようにする、層ごとの量子化設定を提案しました。この変更は、複数の量子化形式を混在させたモデルの読み込みを可能にするものです。確認時点でPRはオープンのままで、ページにはレビューコメントが掲載されていません。提案の内容と状況
提案では quantization_config={glob: config} という形式で設定し、dtype planと同じ名前マッチング方式を使って、層ごとに異なる量子化器を適用します。量子化済みのNVFP4重みは deserialize 操作で読み込みます。作者によると、小規模なランダムMistral4モデルを使ってテストしており、attentionとexpertモジュールにはFP8、shared expertにはNVFP4を適用しています。これは混合形式の動作を確認するテストケースですが、実モデルの品質や速度を示す証拠ではありません。作者の説明
現行の公式ドキュメントによると、事前量子化済みチェックポイントでは config.json に量子化設定が保存され、from_pretrained が対応する量子化器を選択します。量子化方式によっては、別途ライブラリへの依存もあります。量子化にはメモリ使用量、速度、精度のトレードオフがあり、ビット数を下げても、すべてのハードウェアで同じ効果が得られるわけではありません。公式の量子化ドキュメント
エンジニアリングの観点からは、層ごとの設定が成熟すれば、開発者はモジュールごとの精度要件を表現しやすくなり、混合形式に対応する読み込み処理を個別に実装する負担を減らせると考えられます。ただし、読み込みに成功することは最初の段階にすぎません。モジュール名のマッチング、重みの形式、実行カーネルに齟齬がないかを確認し、対象のワークロードで効果を測定する必要があります。
現時点で、このPRのマージ先は別の開発ブランチです。また作者は、FP8のexpertには追加のカーネルサポートが必要だと記しています。今後は関連する依存関係が整うか、完全なモデルを使った精度、ピークメモリ、スループットの測定結果が公開されるかが注目点です。現在の公開情報だけでは、デプロイ時の性能改善を結論づけるには不十分です。依存関係と開発ブランチに関する情報