「量子化した」では足りない:重み・計算・記憶の分け方
AI 公開日 更新日 初級

「量子化した」では足りない:重み・計算・記憶の分け方

モデル圧縮を一語で済ませず、どこを粗くしたかを分けて記録・比較する地図を解説します。

メトリフクロウ
メトリフクロウ 検証ラボ / Evaluation Lead

検証ラボの メトリフクロウ です。「量子化した」という言葉を、会議でそのまま使わないための回です。評価レポートを厚くする前に、比較の前提を揃えます。

この回の答え

「量子化した」は説明になりません。重み・計算・途中記憶に加え、品質がどれだけ残ったかを列にします。平均だけで合否せず、既製と自前も混ぜません。

この回だけの用語

用語ひとことで
量子化モデルの数字を粗くして、メモリや計算を軽くする工夫
重みモデル本体のパラメータ。倉庫の在庫に近い
キーバリューキャッシュ(KV)生成中の「途中までの記憶」。メモの置き場
品質保持(QualityRetention)量子化後の点数 ÷ 量子化前。0.95 ならだいたい 95% 残せた
NVFP4重み側の量子化形式のひとつ。KV の話とは別
意味改変平均は近いのに、語や数値が別物になる失敗

社内検証では、前後比較の自動化と品質ゲートの型が厚くなったので、地図もそこに合わせています。

「量子化した」は説明になっていない

ベンチ報告で「量子化したので速くなった」と聞くことがあります。しかし量子化は一枚岩ではありません。少なくとも次を分けないと、再現も改善もできません。

  1. 重みの量子化(例: NVFP4 / AWQ / GPTQ)
  2. 計算・活性化まわりの精度(例: 活性を 4bit のままにするか、16bit に戻すか)
  3. KV の数値型(例: FP8 KV)
  4. 品質保持(量子化前を基準にした QualityRetention

同じ「量子化」でも、効く場所が違います。この回は、評価前に揃えるべき 語彙 を作ります。

図1: 量子化はレイヤが違う。比較表では別列にする
図1: 量子化はレイヤが違う。比較表では別列にする

レイヤ別の見え方

レイヤ主に効くこと観測しやすい症状
重み載るか、常駐メモリ、品質の底メモリ不足(OOM)/起動不可/回答の崩れ
計算・活性スループットと生成の安定速くなるが反復崩壊・語のずれ
KV の型長文・同時実行の伸びしろ文脈を延ばすと急に詰まる
品質保持採用可否の最終ゲート平均は良いが最悪サンプルが壊れる

社内プロファイル例では、重み側に NVFP4、KV に FP8 を併用する構成が出てきます。大事なのは「速い設定」ではなく、どの列を変えたかを残すことです。

方式名の読み方(現場向け)

よく出る名前まず疑うレイヤメモ
NVFP4重み載せる/品質の話になりやすい。既製の配布重み自前量子化 を分ける。GPU が FP4 非ネイティブなら 重み圧縮のみで、生成速度の加速を期待しすぎない
NVFP4A16 など重み+活性重みは 4bit 寄りでも、活性を 16bit に戻す設計。反復崩壊の切り分けに使う
FP8 KVKV長文・同時実行とセットで見る
AWQ / GPTQ重み方式差を品質スイートで確認。平均だけで合否にしない
「FP8にした」どれか不明列を聞き返す

選定パターン(現場の型)

パターンねらい向く用途先に見る指標
載せる最優先まず常駐させる単機・共有GPU起動可否、メモリ
品質優先崩れを嫌うFAQ、規約、OCRスモーク+最悪サンプル
長文優先文脈を伸ばす要約、長文書KV と p95
同時実行優先複数利用者社内ツール同時実行数

品質保持を列にする(平均だけで合否しない)

量子化の採用判断では、生成速度の伸びだけでは足りません。社内では量子化前後を同じスイートで回し、おおまかに次を残します。

  • QualityRetention = 量子化後スコア / 基準スコア(軸別・総合)
  • 性能比(生成速度・最初のトークンまでの時間・ピークメモリなど)
  • ゲート合否(総合だけでなく軸別)

ここで転びやすいのが 集約平均の罠 です。

起きること先に足す見方
平均が希釈する少数の意味改変が平均に埋もれるサンプルごとの最悪値・誤り件数の増分
点推定が厳しすぎる小標本ノイズで良性の量子化を誤って落とす区間が重なるか(有意な退行か)を見る

OCR や転記では「平均の文字誤り率が近い」ことと「請求書の数字が別物になる件が無い」ことは別問題です。コーディングでも、平均の合格率が近くても特定タスクだけ崩れることがあります。平均は参考、最悪と件数と有意性で門番を組むのが、いまの検証の型です。

ポイント
速さの列の隣に、品質保持の列を置く。平均だけの合否表は作らない。

既製と自前を混ぜない

「NVFP4 にした」も、実装経路で別物です。

経路まず確認すること
既製の量子化済み重み公式/配布の重みがそのまま起動できるか。モデル依存で品質が分かれる
自前量子化出力形式とランタイムの対応。書き出し成功=起動成功ではない
画像+言語モデル(VLM)画像側(vision)を量子化対象から外すか。まとめて潰すと袋小路になりやすい

自前で直そうとして校正データを増やす前に、活性精度を変えた単一変数実験既製候補の載せ替えの方が先、という判断もあります。校正で治ると思い込むと、レバーを取り違えます。

エンジン側のノブ名はランタイムで違います(vLLM / SGLang の起動引数、TRT-LLM のビルド/起動、Atlas のターゲット固有制約など)。レイヤの切り方は共通で、変えた列だけを1つにするルールも共通です。

特に 量子化と投機的デコーディング(MTP 等)を同時に変えるのは禁止に近いです。社内では「公式 NVFP4 + MTP」の不採用と、「FP8 + MTP」の採用が並立しました。同じ「MTP」でも量子化が違えば別試合です。

チェックリスト(量子化比較の前)

  • [ ] 重みと KV と活性の列が分かれているか
  • [ ] 同時に変えた軸が1つだけか(投機を同時に入れていないか)
  • [ ] 既製/自前/出力形式が記録されているか
  • [ ] 起動可否と品質スモークを先に見たか
  • [ ] QualityRetention と最悪サンプル・誤り件数を見たか
  • [ ] 長文用途なら KV の影響を切り分けたか
  • [ ] 「量子化した」という曖昧語を資料から消したか
  • [ ] 「NVFP4=速い」をハードウェア前提なしに書いていないか

一度に全部いじらない

量子化比較の失敗パターンは、だいたい同じです。

  • 重みと KV とエンジンを同時変更する
  • 品質スイートなしでトークン毎秒だけ見る
  • 平均だけ見て意味改変を見逃す
  • 「NVFP4だから強い」と用途・モデル差を無視する

転ぶポイントを先に潰すなら、比較表は最低でも次の列を分けます。

  • 重み量子化方式(既製/自前)
  • 活性精度の方針
  • KV の型
  • 最大文脈長 / 同時実行
  • 品質スイート版と QualityRetention
  • 環境ラベル(ハーネス確認 / 実機)

シナリオで言うと、「メモリが足りないから量子化」は仮説として正しいことが多いです。ただし、その一言で重みと KV を同時に変えると、後から効いた理由が分からなくなります。まず載せるための重み、次に長文のための KV、と段を分けます。

ポイント
量子化は速度の話の前に、比較可能な列設計の話です。

つまずいたこと

「量子化したので軽くなりました」で説明を終えてしまい、精度と KV とビルドコストがごちゃ混ぜになった反省があります。言葉が太いほど、後工程の切り分けが不能になります。

苦労したのは、レイヤを分ける忍耐です。一度に語ると分かりやすい気がして、実際は誰も再現できませんでした。平均が近いのに現場で使えない量子化を見送った経験も、集約指標への過信が原因でした。

この回の要点

  • 『量子化した』で説明を終わらせない
  • 重み・活性・KV・品質保持をレイヤ別に書く
  • 平均だけでなく最悪サンプルと誤り件数を見る
  • 既製と自前、VLM の vision 除外を混ぜない
  • 一度に語らず、列を分けて残す

レイヤ別の比較地図は公開していますが、NVFP4 / FP8 などの実測差はこの回では断定しません。QualityRetention や最悪サンプルは、再計測と匿名化後に足します。

次は「先読みで速くする仕組み:コーディング用途での検証法」です。量子化列を固定したまま、速さの期待を別軸で扱います。

よくある質問

量子化を一言で比べてよいですか?

いいえ。重み量子化・計算/活性精度・KVキャッシュ精度は効果が違うため、レイヤを分けて記録します。

NVFP4 と FP8 KV は同じ話ですか?

違います。前者は主に重み側、後者はKVキャッシュ側の話です。混ぜると選定理由が読めなくなります。

NVFP4 にすれば必ず速くなりますか?

いいえ。GPU が FP4 演算をネイティブに持たない場合、重み圧縮が主で decode 加速にならないことがあります。

平均スコアがほぼ同じなら量子化は成功ですか?

いいえ。平均は意味改変級の少数失敗を薄めます。最悪サンプル・誤り件数・区間推定まで見ます。

この回で実測 tok/s は出しますか?

いいえ。レイヤ地図と選定・ゲートの型が先です。数字は条件が揃い匿名化したものから足します。

Related

関連記事

Contact

検証や観光DXの進め方について、お気軽にご相談ください。