量子化をレイヤで見る：重み / 計算 / KVの比較地図

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

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

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

1. 重みの量子化（例: NVFP4 / AWQ / GPTQ）
2. 計算・活性化まわりの精度
3. KVキャッシュのdtype（例: FP8 KV）

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

レイヤ別の見え方

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

方式名の読み方（現場向け）

選定パターン（現場の型）

チェックリスト（量子化比較の前）

• [ ] 重みとKVの列が分かれているか
• [ ] 同時に変えた軸が1つだけか
• [ ] 起動可否と品質スモークを先に見たか
• [ ] 長文用途ならKVの影響を切り分けたか
• [ ] 「量子化した」という曖昧語を資料から消したか

一度に全部いじらない

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

• 重みとKVとエンジンを同時変更する
• 品質スイートなしで tok/s だけ見る
• 「NVFP4だから強い」と用途を無視する

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

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

• 重み量子化方式
• KV dtype
• max_model_len / 同時実行
• 品質スイート版
• 環境ラベル（harness / real）

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

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

つまずいたこと

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

苦労したのは、レイヤを分ける忍耐です。一度に語ると分かりやすい気がして、実際は誰も再現できませんでした。

この回の要点

• 『量子化した』で説明を終わらせない
• 重み・KV・ビルドコストをレイヤ別に書く
• 一度に語らず、列を分けて残す

いま公開しているのは評価の型です。実機ベンチの数字は、再計測と匿名化が済んだものから順に足します。合格ラインや用途別プロファイルの未確定は残っています。

次は「投機的デコーディングとコーディング：速さの期待をどう検証するか」へ進みます。いまのメモを1行残してから読むと、連載の筋がつながりやすくなります。