モデル圧縮の全体像：量子化・枝刈り・蒸留の適用境界と組み合わせ

一、圧縮は何を節約しているのか：まず3つの勘定を分ける

圧縮を扱った記事のほぼすべては「パラメータ半減、VRAM 半減」から話が始まり、そのまま「速度2倍」という結論に着地します。この推論の連鎖のなかには2つの独立した飛躍が潜んでいます。圧縮がまず節約するのはストレージと転送であって、計算ではない。そして「転送を節約した」という事実が、モデルが VRAM 帯域律速の状態にあるときに限ってレイテンシの利益に変わる、ということです。この2つを分けて初めて、4bit 重みのモデルが単一リクエストの短いコンテキストでは BF16 より遅くなりうるのに、64 並列の長コンテキストサービスでははるかに速くなる、という現象を説明できます。

そこでまず概念の整理からいきます。Transformer の推論コストは、少なくとも次の4つの作用面に分解できます。

• 重みの VRAM：モデルパラメータ自体が占める DRAM。最も測りやすく、それだけで全部の話にすり替えられる、いちばん語られやすい部分です。
• KV Cache の VRAM：系列長に線形して増えていくあの部分。並列数やコンテキスト長、GQA の設定との結びつきは、重みよりもずっと強固です。
• VRAM 帯域幅：token を1つ生成するたびに DRAM から何バイト読み込む必要があるか。重みのメモリアクセスは固定ですが、KV のアクセスは系列長とともに増えていきます。
• 演算量（FLOPs）：実際に乗加算を行う回数。重み量子化ではほとんど変わらず、量子化の標的を activations にしたときだけ変わります。

この4つの作用面は、それぞれの手法に対してまったく違う反応を示します。これを1枚の表に並べてみると、表面上矛盾するように見えるコミュニティの結論も説明がつきます。

表から直接読み取れる結論が3つあります。第1に、重み量子化は KV Cache に触れません。128K の長コンテキストサービスで VRAM を使い切ってなお、重み量子化のビット幅を調整するのは、対象を間違えています。第2に、実際に FLOPs を減らせるのは activations 量子化と構造化枝刈りだけ、しかもこの2つは恰恰、精度に最も敏感な操作です。第3に、4つすべてに当てはまるのは蒸留だけ、しかし代償は一度の本格的な学習が必要になることで、これが他の手段と同じコストの次元に並ばない根本的な理由です。

1.1 推論のボトルネックが帯域か演算かを判定する

どの圧縮手法に手を伸ばす前に、まず測っておかなければならないことが1つあります。あなたのサービスは memory-bandwidth-bound なのか、それとも compute-bound なのか。大まかな判定基準は算術強度――token を1つ生成するために読む必要があるバイト数と、実際に完了した FLOPs の比です。稠密な自己回帰 Transformer では、重みは毎ステップ丸ごと1回読む必要があり、そのステップで行う乗加算は重みのパラメータ数回だけです。つまり重み部分の算術強度はおおむね1未満の定数で、batch が変わっても動きません。これが、反直感的で極めて重要な現象を直接生み出します。

• 単一リクエスト、小さな batch：GPU の演算能力が大量に遊休しており、ほとんど時間を DRAM へのデータ供給待ちに費やしています。このとき重みを圧縮するのが最もレバレッジが高い操作で、効果は TTFT と TPOT にほぼ線形に現れます。
• 大きな batch、長コンテキスト：batch が大きくなって行列積の FLOPs が帯域を埋めるようになると、モデルは演算律速に移ります。この段階で重みを圧縮しても効果は急速に減衰し、実際に時間を食うのは KV Cache の読み書きと attention 計算そのものになります。

だからこそ「同じモデルなのに、量子化すると単機で1.6倍速くなったのに、32並列だと1.1倍にしかならない」といった報告が至る所に溢れているのです。量子化手法に問題があるのではなく、圧縮手段が、すでに制限されていない次元に作用させたからです。エンジニアリング上もっとも実用的な手順は、まずリクエストログから平均入力長、平均出力長、並列数、生成長の分布を出し、各ステップの重み読み出し量と KV 読み出し量を計算してから、どちらに先に手を入れるかを決めることです。

圧縮の効果曲線は直線ではなく、「ボトルネックがどこか」を横軸とする区分け関数の曲線です。まずボトルネックを特定してから手法を選ぶ、その順番を逆にすると、実験予算まるごと1回分を無駄にします。

二、重み量子化：ビット幅・グループ・outlier は必ずセットで考える

重み量子化とは、各重みを16ビットの浮動小数点から低ビット整数と一組の量子化パラメータへ写すことです。形式としてはきわめて単純ですが、その「良さ」は3つの直交する選択に完全に支配されます。目標ビット幅、量子化パラメータをどの細かさで持つか、そしてoutlier をどう扱うか。多くの人は最初の1つだけを調整して、結果が不安定だと愚痴ります。

2.1 ビット幅の効果は亜線形で、メタデータは一部を食う

素朴な心算では、INT4 は INT8 の2倍、BF16 の4倍だと考えます。実際は違います。理由は2つあります。

第1に、低ビットのダイナミックレンジはすぐ潰れる。INT8 はおおむね7ビットの有効 mantissa を提供しますが、INT4 は3ビットしかありません。あるテンソルの重みの絶対値がごく狭い区間に集中していると、均一量子化のステップ幅が非常に粗くなり、ゼロに近い側の小さな重みがまとめて同じコードワードへ写されます。結果として情報が丸ごと失われます。これが、8bit から4bit へ落としたときの品質損失が通常 16bit から8bit への損失よりずっと大きくなる理由であり、損失曲線には3〜4bit 付近に明瞭な折れ曲がりがあります。

第2に、スケールパラメータ自体がバイトを食う。もっとも一般的な group-wise 対称 INT4 を例に取ると、group size を128とすると、各グループに FP16 の scale（16ビット）と4bit のゼロ点（パック後4ビット）を1つずつ持つので、追加オーバーヘッドは 20/128 ≒ 0.156 bit/weight です。つまり名目上4bit の方式でも、実際の保存量は1 weight あたり4.16 bit になります。同じ計算式で、7B モデルの BF16 の重みは約14 GB、純 INT4 の理論値は3.5 GB、グループメタデータを足しても約3.64 GB です。70B モデルなら BF16 で約140 GB、INT4 にメタデータを足して約36 GB になります。group size を128から64に下げると、メタデータのオーバーヘッドは約0.31 bit/weight に倍増し、圧縮比は3.85倍から3.72倍に落ちます。差としては小さいものの、量子化パラメータがテンソル内で再利用される回数は半分になるため、効果の改善は体感できる程度です。さらに group size を32まで下げると、オーバーヘッドは0.63 bit/weight に近づき、圧縮比は3.46倍まで落ち、効果は逓減し始めます。キャッシュ中の scale 配列が逆にメモリ帯域を圧迫してしまいます。

見落としやすい勘定がもう1つあります。メタデータと kernel の常駐領域です。実装がグループごとの逆量子化を行う場合、scale 配列、量子化パラメータのバッファ、fusion されていない演算子のワークスペースなどが、VRAM を圧迫します。4bit の方式では、これらの「重み以外のオーバーヘッド」が総 VRAM の5%から15%を占める可能性があり、計算しないと圧縮比を過大評価してしまう。

2.2 グループ分け：予算を最も必要な場所に使う

量子化の中心にある矛盾は「ステップ幅」と「解像度」のトレードオフです。1つの scale が覆う要素が多くなるほどパラメータは節約できますが、同じ scale の下にある重みの差は平坦に潰されます。粒度を粗い順に並べると次のとおりです。

• per-tensor：重みテンソル全体に1つの scale。メタデータはほぼゼロで、品質は最悪。重みの分布が非常に均等な層か、極めて保守的な場面でのみ使います。
• per-channel（per-output-channel）：出力フィルタごとに1つの scale。オーバーヘッドは 1/group 程度の端数で、ほぼ無料です。現代のすべての PTQ 方法のデフォルト出発点であり、重みが出力次元に持つ自然な構造に対応しているからです。
• per-group：1次元上で64または128のグループに切、それぞれに scale を持たせます。品質改善が最も顕著な段で、4bit 方式の事実上の標準です。
• per-group + ゼロ点（非対称）：各グループにゼロ点も持たせます。重みの分布が明らかに右に偏る（小さな正値が多い）とき効果が大きく、オーバーヘッドは約0.03〜0.06 bit/weight です。

実践上非常に有用な判断基準があります。group size は「メタデータのオーバーヘッド」と「量子化解像度」の間で唯一の調整可能なノブであり、ビット幅は「VRAM」と「品質」の間で唯一の調整可能なノブです。エンジニアリングでは、まずビット幅を必ず満たすべき VRAM のラインに固定し、そのラインの上で group size を128から64まで下げて品質が足りるかどうかを見るべきです。逆の順番で試すよりずっと速いのです。ビット幅を一度下げると、group size を小さくしても取り戻せないからです。

2.3 outlier：LLM の重みにおける「言うことを聞かないチャンネル」

Transformer の重みと activations の分布には、周知の病理的特徴があります。ほとんどの要素が0の近くに密集している一方、いくつかのチャンネルには、他のチャンネルとは桁違いに大きい振幅を持つ系統的な outlier チャンネル（outlier channel）が存在するからです。これはノイズではなく、学習が収束した結果です。

この特性は量子化にとって二重の打撃になります。重み側にすれば、1つの outlier がそのグループの scale を膨らませ、同じグループ内の正常な重みすべてが数個のコードワードの付近へ圧縮されます。これはそれらの重みがゼロにされたのと同じ効果です。activations側にすれば、outlier チャンネルが毎層のすべての層の scale を膨らませ、その層全体を低精度で表現させることになりますが、実際の情報量はそこまで大きくありません。

重み側への対処は、主流では2種類あります。第1はoutlier を切り詰める：量子化の前に、ある分位数を超えた重みを truncate し、わずかな要素を犠牲にしても全体の解像度を守ります。安価ですが粗雑です。第2はより巧妙で、outlier の情報を分離して別に保存するという方法です。主体は低ビットで量子化し、わずかな outlier はより高い精度で残すか、疎な例外テーブルとして直接保存し、逆量子化のときに加算して戻します。第3の、そして2025年以降で影響が最も大きい種類は、outlier を「回転」させて消すという考え方です。正交変換を使って重みと activations を同時により均等な座標系へ変換し、outlier チャンネルを数学的に消し、量子化のあとで回転を隣接する演算子に折り込みます。このアプローチの一般化形（ランダム直交変換、Householder 変換、オンライン Hadamard 変換をすべて同じ系統とみなすもの）は、すでに2025〜2026年の PTQ の標準的な前処理手順のひとつになりました。とくに W4A8 の場面ではほぼ必須です。主な戦場が activations 量子化だからです。

あなたのモデルが outlier に支配されているかどうかは、安価な実験で判定できます。純粋な per-tensor 量子化と per-channel 量子化をそれぞれ1回ずつ行い、両者の perplexity の差が直感よりずっと大きければ、その層には顕著な outlier チャンネルが存在します。ビット幅を下げることを続けるのではなく、まず回転系の前処理を検討すべきです。

2.4 浮動小数点のビット幅とブロックスケール：2025〜2026年に実際に動いている方向

整数低ビットのダイナミックレンジ問題は、本質的には「ブロックスケール（block scaling）」で解かれました。重みを非常に小さなブロックに切り、各ブロックで浮動小数点の scale を共有します。ブロックが小さく、scale が局所的な範囲に密着するほど有効精度は上がり、scale のオーバーヘッドもきわめて小さく希釈されます。MX 仕様はこの考え方を標準化したもので、32要素で E8M0 の2のべき乗 scale を共有します。NVIDIA の NVFP4 は別の方向を歩みました。16要素につき1つの FP8 E4M3 scale と、ブロック間のスケール差を表すグローバルな FP32 per-tensor scale を組み合わせています。

この2つのフォーマットが持つ意味は「フォーマット名がまた2つ増えた」ことではなく、4bit が、group-wise な整数のグループ単位の表現に依存せざるを得なかった段から、浮動小数点のセマンティクスの下でネイティブに扱える段へと変えたということです。代償はメタデータの増加です。NVFP4 は16要素につき1つの FP8 scale なので、オーバーヘッドは 8/16 = 0.5 bit/weight となり、名目4bitに対し実際は4.5 bit です。MXFP4 は32要素につき1つの8ビット scale なので、オーバーヘッドは0.25 bit/weight、実際は4.25 bit になります。7B モデルで言えば4.5 bit は3.64 GB ではなく約3.94 GB という意味です。増える300 MB と引き換えに、非対称ゼロ点が不要になり、分布シフトへの許容度も良くなります。划算が合うかどうかは、目標ハードウェアに低ビット浮動小数点テンソルコアがあるかどうかによります。

同じ時期の、もう1つの明確なトレンドは FP8 が推論側から完全に学習側へ入ってきたということです。FP8 を使った forward と backward の混合精度学習に、粒度の細かいブロック単位の累積を組み合わせれば、大規模 MoE モデルの学習を支えるのに十分であり、推論時の重み量子化の選択肢に留まらなくなりました。これがもたらす副作用はしばしば見落とされます。モデルは FP8 で学習されているので、その重み分布は本質的に FP8 推論に適していますというということです。FP8 への量子化ではほぼ無損失ですが、INT4 への量子化時の挙動が他のモデルより良くなるとは限りません。これは「圧縮方式の効き方」が一部では学習フォーマットによって決まるということで、モデルを替えるときに前社の量子化の経験をそのまま引き継いではいけません。

精度選択そのもののセマンティクスにも触れておきます。E4M3 は mantissa が多くダイナミックレンジが小さいため、数値に敏感な前方 activations に適します。E5M2 は mantissa が少なくダイナミックレンジが大きいため、通常は勾配や値域に敏感な量に使います。この分担は BF16/FP32 に対する直感と逆なので、設定時に間違いやすいところです。

2.5 キャリブレーションセット：無視されがちだが影響最大のハイパーパラメータ

PTQ には、各層の activations の統計を推定するための少量のデータが必要です（通常はチャンネルごとの絶対値の最大値や分位数）。このデータをキャリブレーションセットと呼びます。サンプル数は数十から数千程度で、重要そうに見ありませんが、最終的な品質への影響はビット幅の選択に匹敵します。注意点が3つあります。

• 分布を揃える。汎用コーパスで較正してから、コードや日本語のタスクにデプロイすると、activations の範囲がミスマッチします。ターゲットタスクのサンプル，哪怕数百件しかなくても、10万件の汎用コーパスより結果が良くなるのが一般的です。
• 長さの分布を覆う。長コンテキストタスクの activations 分布は位置によって変化します。短いテキストで較正して得た scale は、長めの位置では不適切なことがあります。
• 学習セットにある記憶サンプルを使わない。較正自体は重みを更新しませんが、そのデータで統計を取ると scale が過学習し、評価セット上の数値が実運用より良く見えてしまいます。

近年になって初めて体系的に扱われ始めた問題がもう1つあります。softmax のあとの出力です。これは本質的に長い裾を持つ分布をしており、そのまま token ごとの量子化を行うと、少数の大きな値に支配されます。ほとんどすべての問題は解決し、現代的な KV 量子化も activations の動的量子化も、デフォルトで token 単位になっています。

2.6 activations 量子化：本当に演算量を減らせる唯一の段

ここまでの節で扱ったのはすべて重み量子化です。重みは小さくなりますが、毎ステップの乗加算回数は1つも減りません。計算律速の領域からレイテンシを引き下げるのが目的なら、activations 量子化こそがその道です。行列積の入力と中間結果も低精度に圧縮することで、乗加算そのものを低ビットテンソルコア上で実行させるからです。

困難さは重み量子化より一段上で、次のような3つの理由があります。第1に outlier です。重みの分布は静的なので、量子化の前に何度も統計して調整できますが、activations は毎ステップ動的に生成され、コンテキストが変われば分布も変わるため、あらゆるグローバル統計がミスマッチします。第2に誤差の伝播です。重みの誤差は自層の出力にしか影響しませんが、activations の誤差は残差接続を通じて以降のすべての層へ浸透し、層が深いほど増幅されます。第3に kernel です。量子化パラメータをどれだけ正確に計算しても、対応する融合 kernel がなければ、あるいは kernel が scale をその場で計算して動的シェイプの調整 が必要なら、実際の速度は量子化しない BF16 パス还不如になることがあります。

したがって activations 量子化の現実的な道筋は、4bit に飛びつくのではなく 8bit から始めることです。W8A8 の考え方は、重みを8bit整数で、activations を8bitかつtoken ごとに動的に scale を取るように扱い、チャンネル平滑化や回転で outlier チャンネルを押さえ込むものと組み合わせるものです。この段は主要アクセラレータカードに成熟した kernel が揃っており、自信をもって使える本番向けの解法です。W4A8 は別の話で、重みを4bit に圧縮すればメモリアクセスはすでに十分減り、activations を8bit のままにするのは主に数値精度を保つためで、同時に行列積がなお低ビット命令セットに当たるようにするためです。——ここで得られる効果の大半は、実のところ重みのメモリアクセス削減に由来します。activations の 8bit は、その効果が精度損失によって消えてしまわないようにするためのものです。activations まで4bit に圧縮する（本当の W4A4）は、汎用タスクでは品質が明らかに崩壊するため、ごく狭い範囲ですでに十分に検証済みのシナリオでのみ検討に値します。

最後の列は、方式を選ぶときに見るべき最も重要な欄です。メモリ削減の効果と演算削減の効果は、分けて計算しなければなりません。W4A8 が単一リクエストで得られる加速のほとんどは、重みのメモリアクセスが2バイトから0.5バイトへ減ったことに由来します。大きな batch が機械を演算律速の領域へ押し込んだときに限って、activations 量子化の分の効果が現れ始めます。この2つを混ぜて語ると、W4A8 を入れたのに速くならなかった、という誤った結論になります。実際の原因は、サービスが本来就演算律速の領域に入っていないことに尽きます。

2.7 最小限の量子化セルフチェック手順

具体的な手法に入る前に、コードをほとんど書かずに済むセルフチェック手順があります。量子化を終えたのに効果が出ない原因の大半を、初期段階で手で潰せます。価値は各ステップが非常に安いながら、各ステップがそのままひとつの適用方向を否定できることにあります。

1. まず重みの分布が本当に均等かを確認する。ある層の重みを絶対値の順に並べ、最大の1%の要素が絶対値の総和に占める割合を測ります。この割合が高いなら強い outlier が存在するので、グループ粒度を調整する前に、まず回転か切り詰めを適用すべきです。この確認は数行のコードで済みますが、方式選択の方向そのものを直接変えてしまうことがよくあります。
2. 純粋な対称・純粋な per-tensor のブルートフォース量子化を1回行う。品質損失を記録しておきます。これはすべてのグループ方式とスケーリング方式の下限であり、参照価値が非常に高いです。ブルートフォースで既に大きく落ちているなら、問題は量子化器ではなく分布そのものにあり、ほぼ落ちないなら、それ以降のすべての利得は解像度から来るもので、投資する価値があります。
3. 変数は1つだけ変え、グループ粒度をひとしきり走査する。ビット幅を固定したまま小さい方から大きい方へ走査し、品質の曲線がどこで平坦になるかを見ます。その折れ曲がりを見つける方が、デフォルト値を引き継ぐよりずっと信頼できます。デフォルト値は他の人のモデルで測定されたもので、あなたの分布に合うとは限らないからです。
4. 最後にだけ誤差補正系のアルゴリズムを入れる。これは解像度が十分確保できた前提で、最後の損失を取り戻すものです。粗い解像度のまま誤差補正で帳尻を合わせようとすると、グループ粒度を小さくしてから進める場合に比べて効果がはるかに下回ります。

この手順に隠されている論理は、まず分布の問題を解き、次に解像度の問題を扱い、最後にアルゴリズムの技巧が働くという順序です。ほとんどの人は逆の順番をたどり、各種のアルゴリズムを先に試してから、本当のボトルネックが20行のコードで見つけられる outlier 問題だったことに気づきます。順番が正しければ、探索できるアルゴリズムの幅はずっと狭くなり、効果の確実さも増します。

三、GPTQ と AWQ：同じ問いへの、補完関係にある2つの視点

GPTQ と AWQ は「2つの4bit手法」として並べて二択に扱われがちですが、実際には別レベルの問いに答えています。かつ、しばしば重ねて使われます。この区別を理解することは、どちらがより正確かを覚えるよりも価値があります。

3.1 GPTQ：量子化誤差を、列をまたぐ伝播問題として見る

GPTQ の出発点となる、多くの人が見落としている事実があります。列ごとに量子化すると、前の列の丸め誤差が後の列の量子化結果を変えてしまいます。各列を独立に量子化すれば誤差は独立に累積しますが、重みの Hessian 行列の逆行列を利用して誤差を配分し直せば、最終的に再構築される重みの総誤差を理論的に小さくできます。

エンジニアリングに落とした実装は二次の近似に依存しています。量子化による増分を Hessian で重み付けした目的関数への1ステップの更新として扱い、各列の量子化が終わったあと Cholesky 分解を使って、すでに発生した誤差をまだ量子化していない列へ逆向きに配分します。GPTQ が列ごとに処理を必要とし、累積誤差ベクトルを維持しなければならないのはこのためで、朴素的 round-to-nearest より遅いのは、列間の数値補正を丸ごと1回余計に行っているからです。

GPTQ の実務上の要点は3つです。

• per-channel か per-group の上に適用されるのが前提で、グループ分けの代わりにはなりません。4bit の方式はほぼすべて group-wise（一般に128）を必要とし、GPTQ はその基盤の上で丸めを補正するもので、取って代わるものではありません。
• キャリブレーションセットの小さな batch は順序に敏感です。同じデータでも分け方が違えば結果がわずかに変わるため、評価時はシードを固定して記録してください。
• activations の分布には鈍感で、重みの Hessian だけを使うため weight-only の場面に非常に適しています。ただしactivations をモデル化していないぶん、W4A8 での効果は activations を考慮した方法にはおよびません。

3.2 AWQ：重要なチャンネルは activations が決めるが、守るには重みを使う

AWQ の観察は反対側からのものです。全体の約1%の重みだけがモデルの出力に最大の影響を与え、その重要な重みは重み自身の大きさではなく、入力 activations の振幅で決まります。直感ではここを逆だと考えますが、重みが大きいことは重要を意味しません。常に小さな activations と掛け合わされる大きな重みは、その寄与が小さくなります。

AWQ の手法は、チャンネルごとのスケーリング係数 s（入力次元に作用するもの）を見つけ、activations の重要なチャンネルを拡大し、重要でないチャンネルを縮小します。そうすることで重要な重みの群が数値的に大きなダイナミックレンジを占め、量子化のときに丸められにくくなります。このスケーリングは数学的に等価な変換であり、推論時には直前の層の重みに吸収できるため、推論側のオーバーヘッドは一切増えません。

GPTQ との補完関係はここから明快になります。

覚えておく価値のあるエンジニアリング上の結論があります。この2つは衝突せず、実装ではチャンネルスケーリングを先に行い、その後に GPTQ 式の丸めを行うことがよくあります。スケーリングが重みの分布条件を改善し、GPTQ がその改善された分布の上で誤差の配分を行います。エコシステムで一般的な「GPTQ + AWQ 風スケーリング」の組み合わせはまさにこの意味で、互いに排他的な2つのアルゴリズムではありません。

3.3 より完全なツールボックス：回転、平滑化、混合精度分解

2026年時点において、GPTQ と AWQ だけを語っても完成はしません。活発に開発されているいくつかの方向が、現代的な PTQ の補足レイヤーになっています。

• 回転 / 非干渉化（incoherence processing）（QuaRot、SpinQuant、QuIP# の一系）。直交変換によって重みと activations の outlier チャンネルを全チャンネルへ分散させ、per-tensor 量子化でも機能できるようにします。W4A8 ではほぼ必須で、activations 側の outlier 問題も同時に解決するからです。代償は、変換そのものにオフライン計算が1回必要になることと、オンラインの Hadamard 変換による追加 kernel です。
• activations 平滑化（SmoothQuant の一系）。考え方は AWQ に近いのですが目的が違います。重みは静的で量子化誤差を制御しやすいため、activations の outlier の困難さを重み側へ移行させます。スケーリング まざまに 前の層の重みに吸収できます。
• 混合精度分解（OmniQuant の一系）。各線形層を低ビットの主体と少数の高ビット／浮動小数点の残差に書き換え、層ごとに残差の最適ランクを探索します。本質的に量子化問題を低ランク分解の問題へ変換しており、2〜3bit の段では純粋な低ビットより有利です。
• 較正なし / 最適化ベースの方法（AutoRound の一系）。各層の重みを最適化可能な変数として扱い、学習ベースの最適化でより良い丸め点を探します。代償は GPTQ よりずっと重いオフライン処理で、通常は数十分から数時間かかります。

この層を整理すると、実用的な選択の論理が見えてきます。weight-only の4bit なら安定重視で GPTQ 一族に per-group 128 を足せば十分。W4A8 でスループットログを求めるなら、先に回転してから量子化する。3bit 以下で詰まっているなら、グループ分けを固守するよりも混合精度分解を試す価値が高い。

四、KV Cache 量子化と FP8：長コンテキストで本当に触れるべき場所

もし重みをすでに4bit まで圧縮しても VRAM が足りないという状況なら、問題の体はほぼ確実に重みにはありません。KV Cache は、長コンテキストと高並列のシーンにおいて、系列長に線形して増える一方で、その増加係数を自分が制御できない唯一のメモリブロックです。この種のデプロイの主要な矛盾はここにあります。

4.1 まず KV のサイズを計算する

KV Cache のバイト数には閉じた式があります。2 × 層数 × KV ヘッド数 × head_dim × 1要素あたりのバイト数 × token 数。ここでのヘッド数は KV ヘッド数であって attention ヘッド数ではない点に注意してください。GQA/MQA はこの部分を何倍も圧縮しており、現代的な長コンテキストモデルが動かせる理由のひとつです。圧縮方式は実際の KV ヘッド数に基づいて設計する必要があり、attention ヘッド数で見積もってはいけません。

純粋に算術だけの例を挙げます。80層、KV ヘッド8個、head_dim が128という構成なら、FP16 では1 token あたり 2 × 80 × 8 × 128 × 2 = 320 KiB です。128K のコンテキストを最大まで使うと、1本の系列の KV は40 GiB 程度になります。これに重み、activations のワークスペース、フレームワークのオーバーヘッドは含めていません。精度別に換算すると、FP8 で約20 GiB、INT8 で約20 GiB、INT4（group 64 にメタデータを加算）で約11 GiB です。この一連の数字は2つのことを示します。長コンテキストでは KV が重みよりひと桁大きくなることが多い。そしてKV 量化の効果は線形に積み上がるもので、精巧なアルゴリズムは要らず、FP16 から INT4 へは、文字どおり実際上の4倍になります。

4.2 なぜ KV 量化は重み量化より簡単なのか

直感的には KV のほうが圧縮が大変です。動的に生成され、分布が内容によって変わるからです。実際，效果がよいのは3つの理由があります。

• 誤差がステップをまたいで累積しない。重みの量子化誤差は各層の入力を通して以降のすべての層へ伝播し、層が深いほど増幅が明瞭になります。一方 KV の誤差はそのステップの attention 計算の中だけで働き、次のステップでは新しい KV が生成されます。系列長に沿って累積していく経路が存在しないのです。これが KV 量化で最も過小評価されている優位点です。
• softmax 自体に許容度がある。attention の重みは正規化後の相対量であり、attention スコアを同じ比率でスケールしても結果は変わりません。softmax の小領域における1次微分項はゼロに近いため、小さな摂動への余裕があります。これが量子化の余地を生み出します。
• token ごとに動的にスケールできる。各 token の K と V それぞれで scale を求めるだけで、token 間で共有する必要がまったくありません。粒度は本質的に細かくなります。

代償も確実に存在し、その集中的な場所は1か所です。attention スコアが量子化ノイズで乱されたとき、retrieval の並び替えが間違う。大量の状況から1本の情報を正確に掘り出す必要がある「藁の中の針」のようなタスクでは、この種の誤りが最初に表面化します。KV 量子化の評価は perplexity 全体だけを見ては不十分で、長文脈の retrieval と長文推論のサブセットを必ず含める必要があります。

4.3 粒度の選択：per-token、per-channel、per-head のどれか

KV 量化で最も重要な設計変数は scale の粒度です。主流の3つの選択肢のトレードオフは次のとおりです。

この表で最も直感に反し、同時に最も重要な行が per-channel です。直感では粒度が細かいほどよいはずですが、head_dim ごとの channel-wise スケーリングには副作用があります。異なるチャンネルのクエリとの内積に対する相対的な寄与を、如何に変えてしまうからです。そしてそのチャンネルこそ、モデルが「マッチング」に使うものです。スケーリングが K と Q で非対称なら、attention スコアのセマンティクスは破壊されます。したがって、細粒度が必ずよいわけではなく、per-token が绝大多数の場面での妥当な解です。per-channel は retrieval タスクでスコアが落ちないことを確認してから使ってください。

4.4 キー感知とクエリ感知：選択的量子化の思路

もうひとつの考え方は、次のような観察から来ます。位置もヘッドもチャンネルも、最終的な出力への貢献度がきわめて大きく異なるため、一括して同じ力度で圧縮する必要はない。

• キー感知：各 token または各ヘッドに重要度のスコアを1つずつ推定し、重要度の高い部分は高い精度を保ち、残りをより強く圧縮します。難しい点は重要度推定そのものの信頼性です。ヒューリスティックルールで計算したスコアは、長文の中で判断を誤ると、かえって均一量子化より悪い結果になります。
• クエリ感知：現在のデコードステップのクエリベクトル q は既知であることを利用し、K の値ごとに異なる量子化パラメータを使うことで、量子化誤差が現在のクエリに与える影響を最小にできます。この考えは数学的には自然ですが、q ごとに再計算するコストが工学的に必要で、KV がすでにキャッシュ済みである前提を活かせていません。実装の難度が高くなります。

この2つの思路の現在の共通の立ち位置はこうです。理論上の利得は明確ですが、実装上の利得は不安定で、エンジニアリングの複雑さは per-token の方式を上回ります。绝大多数の本番デプロイでは、まず per-token の INT8/FP8 を堅実に固めて、その利得が得られていることを確認してから、特定のタスクのために選択的な方式を導入すべきかを考えます。

4.5 FP8 の推論エンジンにおける本当の位置

FP8 は2025〜2026年に「新フォーマット」から推論エンジンのデフォルトの中間精度へ変わりましたが、その位置づけはしばしば間違って語られます。主に4つの場所に出現します。

• 重みの保存：8bit の代替として、同じサイズのままより良いダイナミックレンジを提供し、サービス側の「下限の精度」の段としてよく使われます。
• activations と中間結果：attention の P×V の中間状態、FFN の中間 activations、そして各種リダクションのアキュムレータ。利得が最大となる場所です。
• KV Cache：K と V を E4M3 で保存するのが現在の妥当な選択です。K は内積に関与し数値に敏感なので mantissa の多い E4M3 を、V は加重和に関与するので多少緩めてもかまいません。この組み合わせはすでに広く採用されたデフォルトの設定になりました。
• 学習側：前述のとおり、FP8 の混合精度学習によって、モデルは最初から FP8 推論に適合します。

必ず確認すべきディテールが1つあります。FP8 の累積精度と丸めモードは結果を大きく左右します。多くの実装では FP8 の乗加算の累積は FP16 か FP32 で行われますが、丸めが乗算の前か後か、split-k 累積を使うかどうか、attention の softmax 入力に特別な処理をしているかどうかによって、観測可能な差が生じます。フレームワークをまたいで FP8 の結果を比較するときは、まず累積のセマンティクスが一致していることを確認してください。そうでなければ差分は実装由来であり、モデル由来ではありません。

長文脈デプロイの圧縮順序はこうあるべきです。まず GQA/MQA の KV ヘッド数を確認し、次に KV の FP8/INT8 量子化を適用し、そのあとでようやく重み量子化を考えます。重みを8bit から4bit へ圧縮して得られる VRAM は、KV を FP16 から FP8 へ圧縮したときの半分にも満たないことがあります。

4.6 長文脈の別解：すべての問題を KV 量子化で解こうとする必要はない

KV 量子化が解くのは、同じ KV をより少ないバイトで保存するという問題です。しかしより上流の問題、つまりそもそもこれほど多くの KV が必要ないという問題は解いていません。長文脈の方向には補完関係にある2つの手段があり、量子化と同じ選択表に並べて比較する価値があります。

第1類はKV の選択的保持と打ち捨て（eviction）です。すでに計算された KV のうち、绝大多数は後続のデコードでほとんど参照されません。典型的なのが、長い文書の中で後続の質問が完全に無視する部分です。この観察に基づく手法は、軽量な判定基準で各位置に重要度スコアを付与し、高スコアの部分だけを残して、残りをキャッシュから直接削除することです。重要な違いは、その利得が系列長とともに増え続けるという点です。KV 量化の利得は一定の倍率にとどまります。数十万 token のシーンでは、eviction で節約できる空間はビット幅を圧縮するよりずっと大きくなります。リスクも同じくらい明確です。判定基準が本当に必要な位置まで捨ててしまうと、モデルは自信満々に誤答を返します。しかもこの種の誤りは通常の評価では発見しにくいです。総合スコアが明らかに下がる形には現れず、特定の難しい問題で不正解が出るだけだからです。eviction 系の方式には専用の長距離検索評価を別途用意する必要があります。

第2類はattention 自体の疎化です。密 attention の長系列での計算量は系列長の2乗に比例して増え、長文脈の中でもっとも高くつく部分です。疎 attention の考え方は、各 query が自分で関連すると判断した少数のブロックだけに attend させるというもので、重点はどの token を残すかではなく、十分な低コストで「関連しうるブロック」を先に見つける方法にあります。ここで使うブロック分割、インデックス、プレフィクス再利用の仕組みは、KV 量化の失效モードとは完全には異なります。量子化誤差は深さとともに累積しますが、疎 attention の誤りは主に「関連ブロックが検索できなかった」という1種類の失效に集中します。したがって両者の評価は分けて設計する必要があり、疎 attention は答えが長い文脈のどこかにあるタスクを専門的に測る必要があります。

この3つを並べて見ると、競争関係ではなく補完関係にあることが分かります。疎 attention は計算すべき KV の数を減らし、KV eviction は保存すべき数をさらに減らし、KV 量化は1つの KV の保存コストを下げます。現実の長文脈システムでは、このうち2つ、場合によっては3つすべてを同時に使う可能性が高いでしょう。ただし順序には意味があります。選択的な eviction で KV 予算の半分をすでに使ってしまっていたら、さらに INT4 へ圧縮しても追加の利得は限定的です。このとき投資すべきなのは eviction の判定基準の精度を上げることであり、さらにビット幅を詰めることではありません。ビット幅は際限なく圧縮できますが、判定基準を誤ったときの代償はそれに比例して小さくなることはありません。これが両者のもっとも重要な非対称性です。

五、枝刈り（pruning）：非構造化と構造化は2つの運命を背負う

量子化はモデルの「形」を変えずに、数字の保存方法だけを変えます。枝刈りが変えるのは、モデル内の非ゼロパラメータが実際にいくつ残るかです。性質のまったく異なる2つの操作であり、エンジニアリング上の結果もまったく正反対になります。

5.1 中心にある矛盾：疎密度とハードウェア利用効率

理想的な枝刈り方式が同時に満たしたいものは3つです。高い疎密度（VRAM の節約）、規則的な構造（ハードウェアで加速できる）、そしてほぼ無損失の品質。現実には、この3つは互いに矛盾します。構造が自由であるほどハードウェアでは利用しにくく、ハードウェアが利用できる構造は、まさに研究者がハードウェアの制約に合わせて設計した結果にすぎません。

理由は汎用 GPU の実行モデルにあります。行列積は固定形の tile に分解され、各 tile は1組のスレッドが連続メモリを読んで乗加算を行います。非ゼロ要素がメモリ中に散らばっていれば、スキップのコストが読み込みのコストとほぼ同じか、それ以上になります。乗加算は節約したものの、その分をメモリアクセスに費やしてしまうのです。これが、ランダムな非構造化枝刈りが論文では有効なのに本番では効かない根本理由です。その疎パターンは理論上の FLOPs を節約するために設計されたもので、実際のハードウェアのためのものではないからです。

5.2 2:4 半構造化疎性：ハードウェアに広く支援される唯一の形式

2:4 は現時点でエンジニアリング上もっとも成功している枝刈りフォーマットで、その制約はきわめて単純かつ巧妙です。連続する4個の重み要素のうち、ちょうど2個を残す。この制約の美しい点は、固定の疎計算パターンへコンパイルできることにあります。ハードウェアが2:4 のブロックで2つの非ゼロ値とそのインデックスを読み込み、枝刈られた重みは読み込み段階でまったく触れられないため、帯域を無駄使いすることがありません。

代償も明確です。

• 上限は50%の圧縮。モデルがどれだけ削るべきかにかかわらず、ハードウェアフォーマットの粒度が決めるので、2:4 は2:4 です。同じブロック形式のもとで理論的にさらに高い疎密度にしても、メモリアクセス上の利得は得られません。
• 実ハードウェアの対応が必要。対応する疎テンソル命令と2倍のスループットを約束するのは新しいアクセラレータカードだけです。非対応カードでは gather と密計算に退化し、枝刈らないより遅くなります。本番化の前に目標機種で実測する必要があり、スペック表を見てはいけません。
• インデックスも別に保存が必要。非ゼロ値に加えてインデックスのメタデータも容量を要するため、実効圧縮比は2:1からメタデータを差し引いた値になり、1.6〜1.8倍あたりとなり、名目値より下がります。
• 品質損失には復旧学習が必要。ハード枝刈りはモデルへ大きく偏った摂動を与えるものなので、復旧学習をしないとスコアが明確に落ちます。

実装上によく見落とされるディテールが1つあります。4要素ごとのグループ分けは、出力チャンネルではなく、重みを平坦化したあとの連続する次元に沿って切られます。つまり、4要素のグループは2つの異なる出力フィルタにまたがる可能性があり、枝刈りのセマンティクスは構造化の直感で想像するものとまったく違います。マスクを設計するときはこの平坦化の順序を尊重しなければなりません。そうでなければ、消えるのは同じフィルタの4つの重み、つまり1つの出力チャンネル全体を消すことになり、損傷は巨大になります。

5.3 構造化枝刈り：本当に FLOPs を減らせるやつ

構造化枝刈りが削るのは、チャンネル全体、attention ヘッド、FFN の中間次元、Transformer 層、あるいは MoE の丸ごとです。これが実行時の判定をまったく必要とせずに本物の FLOPs を節約できる唯一の枝刈り方式である理由は、削られた部分が計算グラフから完全に消えてしまうからです。

粒度の異なる構造化枝刈りでは、代償の差が非常に大きくなります。

構造化枝刈りの本当の難点は「どれだけ削るか」ではなく、「何を削るか」にあります。よく使われる判定基準は3種類で、まず重みの大きさに基づく判定基準（もっとも単純でもっとも当てにならず、重みの大きさと重要度は無関係だからです。この点は AWQ の節で述べました）、activations に基づくもの（較正データで各チャンネルの出力の大きさを測る）、そして ablations に基づくもの（1つずつ削って影響を測る。もっとも正確だがコストが受け入れるレベルではない）。実務では層ごとの感度で並べ替えることが一般的です。まず各層の再構築誤差を測定し、誤差が小さい順に削り、目標の率に届いたら止めます。

5.4 復旧学習：枝刈りの成否を分ける工程

ハード枝刈りの後には必ず復旧学習が必要で、例外はありません。しかしこの作業量を過小評価している人は多いです。復旧の効果を左右する要点は次のとおりです。

• 学習率は事前学習より1〜2桁低くする。復旧学習の目的は摂動された重みを補修することであり、表現を作り直すことではありません。学習率が高すぎると原有的能力が洗い流されます。
• データ分布をターゲットに合わせる。汎用コーパスで復旧して、特定のタスクへデプロイすると、復旧の効果は割り引かれます。
• パラメータの大半を凍結しない。よく使われる実践は、すべての層を解凍しつつ学習率を小さくするか、あるいは枝刈りされた層に隣接する層だけ解凍する方法です。すべてを凍結して少数の層だけ学習すると、高枝刈率では復旧が不足します。
• 疎フォーマットは学習時に固定する。2:4 の制約は、更新のたびに合法なマスクへ射影し戻すことを要求します。学習ループにこの工程がなければ、フォーマットを満たさないモデルが学習され、最終的にデプロイ時にハードウェアに静かに誤処理されます。

見落としやすい相互作用がもう1つあります。枝刈りの後に量子化する場合、量子化の対象は復旧学習後の重みです。先に枝刈りしてから量子化するつもりなら、復旧学習の段階で量子化感知学習（QAT）を使って、すでに削られた量子化誤差の目標を追い込むべきではありません。それは無駄です。逆に、先に量子化してから枝刈りするなら、削られるのはすでに低ビット化されたブロックの丸ごとであるべきで、粒度の整合が問題になります。

5.5 特殊だが非常に価値のある使い方：密重みを疎なエキスパート構造へ変換する

枝刈りと MoE はあたかも方向が正反対に見えますが、片方は引き算、もう片方は足し算です。ただしその間には非常に有用な変換経路が存在します。密モデルの中の FFN の重みを一部削り、残りを複数のエキスパートへ切り直すことで、能力をほとんど失わずに疎モデルを得るというものです。

この経路の価値は、枝刈りと疎 activations の両方の長所を同時に得られることにあります。モデル自体は実際に小さくなり（総パラメータ数が減る）、各 token は 依然としてパラメータの一部だけを活性化します（条件付き計算の演算上の優位性が保たれます）。ゼロから疎なアーキテクチャを事前学習するのに比べれば遥かに安く、単純に枝刈りするだけに比べれば、同じ総容量を異なる入力に対して異なる挙動を見せられる能力が保てます。

ただし変換はただでは済みません。必ず処理すべき点が3つあります。第1に、ルーティングネットワークは再学習が必要です。密な FFN は1つの固定マッピングしか持ませんが、複数のエキスパートへ分割すると、負荷分散を行う割り当ての仕組みが必要になります。初期の token 配分はほぼ確実に極端に偏っており（少数のエキスパートが大部分の token を吸収します）、学習でないと安定しません。第2に、エキスパート間の容量差です。均等に分割することは、元の FFN の異なるチャンネル区画が同じ重要度の機能を担っていると仮定することになり、この仮定は通常成り立ちません。重要性に応じて容量を不均等に割り振る必要があります。第3に、枝刈り率とエキスパート数は結び付いているというポイントです。総パラメータ数はエキスパート数×1エキスパートあたりのパラメータ数であり、両者を一緒に計画する必要があります。一方、1 token あたりの実際の計算量はエキスパート数だけで決まります。この2つの数字は設計時にしばしば混同され、モデルが想定より大きくなったのに速度がほとんど上がらない、という事態を起こします。

務実的な提案はこうです。この道筋は再利用として使うのが適しています。学習済みの密モデルを疎な形に変えたい場合や、同じアーキテクチャで異なる領域のモデルが複数あり、それらを条件付きモデル1つにまとめたい場合です。ゼロから巨大な能力のモデルを構築する道筋には向いていません。前者のコストは日単位、後者は月単位で、後者の効果はどの変換技法の成果よりもはっきり優れています。

六、蒸留（distillation）：コストをデータへ移す

これまでの5つの手段は、モデルのトポロジを変えずに既存の重みを別の表現で表し直すだけでした。蒸留は実際にモデルを入れ替える唯一の手段です。小さな学生モデルで教師の挙動を近似します。その上限は最も高く（4B の学生が70B の教師に追いつくことは十分あり得ます）、コストも最も高い（教師推論と全学習のプロセスが必要）。

6.1 蒸留は「小モデルが大モデルを学ぶ」ほど単純ではない

「蒸留」を単一の方法として扱うと、もっとも重要な情報を失います。少なくとも3つの段階があります。

• Logit 蒸留：学生に各 token で教師の出力分布（温度スケーリングしたソフトラベルに、正解ラベルを加えたもの）を合わせさせます。伝達される情報は one-hot ラベルよりはるかに多く、ソフトラベルの暗黙の知識には、教師が他の候補に対して抱く相対的な確信度が含まれている。 学生がそこから学ぶのがまさにこれです。
• シーケンス蒸留：教師の token 確率ではなく、教師が生成したテキストをそのまま使って学生を学習させます。形式は通常の SFT そのもので、データだけが教師由来です。実装は簡単ですが、分布の情報を失い、教師の出力の多様性に直面します。
• 推論チェーン蒸留：教師が完全な思考過程を含む答えを生成し、学生がそれを真似します。推論モデルではとくに重要で、推論能力の主要な担い手は途中経過そのものだからです。最終的な答えだけを学んでも推論は学びません。

2025〜2026年に、方法論の明確な転換を1つ触れておく価値があります。オフライン蒸留が on-policy 蒸留に置き換えられつつあるということです。中心的な観察は、オフライン蒸留で学習した学生は、自分の能力分布の外側でしか教師のテキストを模倣できないということです。学生が自分で間違える token の位置では、教師に一度も「引き戻された」ことがありません。学生はそこをサンプリングしていないからです。on-policy 蒸留では、学生自身がシーケンスを生成し、その学生が実際に訪れた状態で教師が監督信号を与え、学生の具体的な誤りを直接正します。仕組みとしては、学習の問題が「分布を模倣する」から「重要な状態で是正する」へ変わります。推論タスクにおけるこの差は、通常、両者の演算量の差よりはるかに大きくなります。

6.2 データ構築：蒸留品質の上限を決めるもの

蒸留の効果は学習レシピではなく、データ構築で上限が決まることが多いです。決定的な変数を挙げます。

このなかで最も強調すべき点が2つあります。第1に、検証は蒸留データパイプラインの必須の工程であり、選択肢ではありません。教師モデルの誤答率は難しいタスクでは必ずしも低くなく、学生の模倣能力は強く、誤りのパターンまでそのまま学びます。検証のない蒸留は、教師の弱点を拡大することになります。

第2に、難易度の分布はデータ量より重要です。ここを多くの人が理解していません。蒸留の学習信号は、主に学生が間違え教師が間違えない位置から来ます。データのほとんどが教師も学生も解ける簡単な問題であれば、その種 token では教師のソフトラベルが持つ情報量はきわめて低く、学習はほぼ勾配を生みません。本当に価値があるのは能力差の領域のデータです。実践上は、学生の現在の能力に合わせてサンプリングの難易度を動的に調整します。これは継続的に進化するデータ生産のプロセスであり、一度きりのデータ準備ではありません。

6.3 师生能力差：蒸留が機能しなくなる条件

蒸留には繰り返し観察される現象があります。教師と学生の能力差が大きすぎると、蒸留の効果は急激に下がり、教師の出力をそのまま SFT するより低くすらなります。原因は推測できるとおりです。学生には教師の高次の挙動を受け止めるのに十分な基礎表現がなく、学べるのは教師の表層の形式（文型、書式、用語）にすぎず、推論の構造ではない、さらに自分が消化できない大量の誤った推論手順に引きずられてしまいます。

実務上の判断根拠は2つあります。1つ目は教師の思考過程が学べ可能かを見ることです。教師の推論チェーンが長く、学生が正しい中間状態にすら到達できないなら、どのようにサンプリングしても勾配信号はノイズです。2つ目は難易度がマッチングした分布になっているかを見ることです。教師と学生をそれぞれ検証セット上で1回ずつ走らせ、学生が「できるが不確実」と「まったくできない」の比率を数えます。前者の比率が非常に低いなら、データがすべて能力差の領域の外にあるため、教師の規模を下げるか、まず1ラウンド SFT で土台を埋める必要があります。

ここから導かれる堅牢な戦略があります。階層型蒸留（layered distillation）です。まず最大の教師で（必要なら最も強く、ただし冗長な推論過程とともに）1ラウンド SFT を行い土台を敷く、その後、現在の学生能力とよりよく合った教師に切り替えて、複数のラウンドの on-policy 蒸留を行います。毎ラウンドごとに能力差を再評価し、それに応じて難易度の分布を調整します。これは本質的に課程学習の問題であり、一度きりのデータの運搬ではありません。

蒸留の利得は主として师生能力差の領域のデータから得られます。学生がすでに特定の軸で教師に追いついているなら、その軸で蒸留を続けても限界利得はゼロに近づくため、演算力はまだ差のある軸へ移すべきです。

6.4 蒸留の効果を単独で測定するには

蒸留モデルと量子化モデルには本質的な違いがあります。品質が数式から直接計算されるのではなく、学習によって作られるからです。这意味着蒸留モデルを評価するには、学生が本当に学んだのか、学生が教師の表層の形式を真似ているだけなのかを区別できなければなりません。総合スコアを1つだけ測っても、この区別はつきません。

分けて測る必要のある手がかりが3つあります。1つ目は能力差の曲線です。学生と教師の間で補間を行い、補間点ごとの性能を測ります。曲線が教師に近い側でもなお教師を明確に下回っているなら、学生は学び不足ではなく容量不足です。データを増やしても意味がなく、より大きな学生に変えるか、タスク分布を狭めるべきです。「データが足りない」のか「学生が小さい」のかを区別する、もっとも重要な線であり、これは補間の実験1回で得られます。

2つ目は教師の誤りが継承されていないかです。学生が確実に間違える問題について、学生と教師の答えの分布がどれだけ近いかを比較します。非常に近いなら、学生は教師の誤りを真似ているということです。この測定は教師の低確信領域でサンプリングして初めて可能で、学生が自信を持つサンプルで測っても意味がありません。これは蒸留データの検証工程が実際に効いているかを示すもっとも直接的な証拠でもあります。検証をしていない、または不足していた場合、この曲線は明確に高くなります。

3つ目はon-policy とオフラインの対照実験です。同じ教師、同じ規模の演算予算で、オフライン蒸留と on-policy 蒸留をそれぞれ1回ずつ行い結果を比較します。この対照実験は大きな規模でなくても方向は読み取れます。しかし、数据生産のプロセス全体を on-policy へ変更するかどうかを決める唯一の根拠になることがよくあります。プロセス変更のコストは小さくなく、着手するにはデータが要るからです。

この3つを合わせると、蒸留の評価の論理はこうなります。まず容量が足りているかを確認し、次に学び方が正しいかを確認し、最後に手法の選択が正しいかを確認します。1つ目を飛ばしてデータを最適化したり、3つ目を飛ばしてデータパイプライン全体を改造したりするのは、よくある時間の無駄です。

七、疎化：重み疎性と activation 疎性は別のもの

ここまで扱った 2:4 と構造化枝刈りは、いずれも重み疎性です。どの重みパラメータを恒久的に捨てるかを決めるものです。しかしまったく別の道筋があります。実行時に、どの計算をこのステップではしないかを決める。この系統の総称が activation 疎性（または動的疎性）です。

7.1 重み疎性：静的で予測可能、ハードウェアには不親切

重み疎性の判断は学習または枝刈りの段階で一度に決まり、推論時は固定のマスクになります。利点は予測可能さです。各層が各ステップにどれだけの計算をするかを計算でき、オフラインで配置まで前倒しできます。欠点はハードウェアに対してきわめて不親切なことです。マスクが存在すること自体は加速を保証せず、汎用 GPU が実際の利益を提供するのは 2:4 のような固定フォーマットの場合だけです。より根本的なのは、重みのゼロは計算のゼロを意味しないということです。枝刈られた重みに対応する activations がたまたまその時点で大きな値なら、損失は実在するもので、疎フォーマットがそのことを区別して扱うわけではありません。

7.2 activation 疎性：動的で、ハードウェア利得も大きく、精度損失も大きい

activation 疎性の論理はまったく違います。重みは密なままに保ち、乗加算のときに activations の大きさに応じて一部の乗算を飛ばす。activations は毎ステップ動的なので、飛ばす対象も動的になり、これは実行時疎性に自然に適合します。

その技術的な核心は予測にあります。本当に乗加算をする前に、どの activations が十分に小さいかを分かっている必要があり、それは予測でしかできません。低ランク近似で activations のノルムを予測するか、あるいは実際の activations のダウンサンプリング統計で近似するかのどちらかです。予測が外れると2つの結果になります。保持すべき大きな値を見落としたり（精度損失）、飛ばすべき小さな値を保持したり（疎密度が未達）します。

この種の方法は2023〜2024年に入念に研究されてきました。結論は、純粋な FLOPs の節約としては相当大きいですが、実際のエンドツーエンドの推論サービスでは果たしにくいということです。理由は第1節でも述べたとおりで、疎度を上げても理論上の算術強度が改善するだけで、サービスは依然としてメモリアクセス、kernel のスケジューリング、疎パターンが持ち込む gather のオーバーヘッドにも支配されています。加えて Transformer の FFN の中間次元は数千にしかならず、増幅後の activations 分布も相当に平坦です。安全に飛ばせる割合は理論値に届きません。

activation 疎性に近い位置にMoE 型の動的疎性もあります。MoE のルーティングによって各 token が少数のエキスパートだけを活性化する方式です。「動的疎性」という欄の中で、大規模な本番環境で検証されているのはこの形だけです。重要な違いは、MoE の疎性がパラメータ量の拡張（総パラメータは増え、1 token が活性化する量は減る）から生じるものであり、パラメータの削除から生じるものではないという点です。VRAM の勘定は逆で、MoE は VRAM の必要量を増やし、FLOPs を減らします。したがって MoE は圧縮手段ではなく、VRAM と演算の交換をするアーキテクチャの選択であり、ちょうど圧縮とは逆向きです。MoE を「圧縮」として宣伝するのは概念的な誤りです。

7.3 動的 token 枝刈りと早期終了：推論における疎化の新しい形

前の2つの節で扱ったのは重み側の静的疎性でしたが、推論段階にはさらに2つの形が重要になりつつあります。パラメータを減らすのではなく、このステップで何をしないかを決めるだけです。

1つ目はprefill 段階の token 枝刈りです。長文脈のコストは主に prefill 段階で発生し、この段階で処理される绝大多数の token は最終的な答えへの貢献がごく小さいものです。長い背景資料の中で、実際に関係するのは2〜3文だけという場合がよくあります。やり方は、まず安価な判定基準（通常は attention スコアの粗い推定、またはとても小さな補助スコアリングモデル）で貢献の低い token を識別し、本体の計算に入る前にそれらを捨てることです。KV eviction との違いはタイミングにあります。KV eviction は decode 期に起こるのに対し、prefill の枝刈りはattention マトリクスが完全に計算される前に行われるため、節約されるのは保存領域だけではなく、系列長に対して2乗で増える計算量です。リスクも KV eviction と同源で、判定基準が重要な token を落としてしまうと、モデルは不完全な情報に基づいて自信を持って答え，しかも何のエラーも出しません。

2つ目はtoken 単位の早期終了です。シンプルなリクエストの答えは、わずか数回のデコードステップのすでに、さらに数十 token を生成するのは、すでに安定した答えを書き続けるだけです。token 単位の早期終了の考え方は、デコード過程に軽量な判定基準を挿すことです（よく使われる方法としては隠れ状態の変化量を見る、あるいはごく小さな分類器で現在の答えが閉じたかを判定する）。収束したと判断したら早めに停止して終端記号を補います。これはカスケードルーティングと同じ直感を異なる粒度で実装したもので、すべての token が同じコストを払って生成されるに値するわけではないということです。この種の方法のリスクは、判定基準が「まだ考えていない」を「収束した」と誤判定することです。早期に切えると答えが不完全になり、しかも切られるのは多くの場合推論チェーンの最も重要な後半部分です。

この2つの形を並べて、統一された視点が現れます。圧縮の本質は、どの計算をせずに済むかの判断にある。重み量子化は数値的重要性で判断し（outlier や小さな重みが丸められます）、枝刈りはパラメータの重要性で判断し、KV eviction と token 枝刈りは内容の重要性で判断し、早期終了とカスケードは難易度で判断します。違いはその判断の信頼性がどこから来るかという点だけです。数値から来る判断はもっとも信頼できますがもっとも粗く、学習から来る判断はもっとも精細でももっとも脆いです。したがって本番システムで本当に堅実なやり方は、信頼できる荒い判断（量子化、低ビット幅の枝刈り）を土台に置き、脆い細かい判断（eviction、ルーティング）を利得が明確で評価でカバーできる範囲に限定することです。

八、3つの重ね合わせ：誤差は積み重なるが、利得は積み重ならない

ここまで来るともっとも難しい問題に着手できます。量子化、枝刈り、蒸留を同時に使えるのか。答えは可能ですが、重ね合わせの効果は線形でも加法的でもないので、1つずつ検証する必要があります。

8.1 最初に確立すべき直感：3種類の誤差は性質が異なる

3つの手段の誤差を同じ視点で見てみると、実際に作用する場所が異なっていることが分かります。

• 量子化誤差：重み側または activations 側の高周波の小さな摂動です。局所的で、密で、すべての層に存在し、すべての重み・activations に作用します。
• 枝刈りによる損失：構造的な、疎で、一回きりの容量の除去です。取り除かれるのは特定のパラメータ（構造化）または固定されたパターン（非構造化）です。
• 蒸留の誤差：全体で、目標志向のものです。蒸留の過程は学習によって圧縮による損失を積極的に補償します。これは有損圧縮のあとに行う1回の教師付き修復だからです。

この性質の差からすぐに重要な結論が導かれます。蒸留の誤差は学習によって作られ、量子化と枝刈り後のモデルの振る舞いを観察できるため、「圧縮してから蒸留する」は原理的に「蒸留してから圧縮する」よりも優れている。まず良い学生を蒸留してから、それに量子化と枝刈りを施すという構成は、圧縮のあとに何の補償メカニズムも無いことになります。圧縮してから蒸留すれば、蒸留の段階で圧縮による損失をフィットすべき目標として直せます。この順序は趣味の問題ではなく、仕組みの問題です。

8.2 具体的な干渉点

具体的に挙げると相互干渉を挙げておきます。

• 枝刈りと量子化の粒度衝突（もっとも深刻な問題）。2:4 の制約は平坦化後の連続4要素のグループに沿って定義され、group-wise 量子化のグループも連続次元に沿って切られます。group-wise 量子化を先に行って枝刈りすると、削った2つの非ゼロ値が量子化グループの scale 統計を壊す可能性があります。枝刈りを先に行ってから量子化すれば、削った値がそのグループの outlier であればグループの scale が再計算され、むしろ改善します。実務では枝刈りを先、量子化を後にするべきであり、量子化器に枝刈り後の最終的な分布を見せるのです。
• 量子化と復旧学習の循環依存。2:4 枝刈りに対して復旧学習を行い、同時に量子化意識訓練（QAT）も行うと、両者が同じ目標を奪い合います。復旧学習は枝刈りで失った容量を取り戻したいと思う一方、QAT は重みを量子化に強くしたいのです。実務では段階を分けた実践で、まず枝刈りして復旧学習を収束させ、次にマスクを凍結して QAT で最後の短い部分を微調整します。同時に最適化しようとしてはいけません。
• 蒸留データと圧縮後モデルのミスマッチ。教師が生成する推論チェーンは、圧縮前の能力水準を前提に作られています。圧縮済みの学生に対してオフライン蒸留をすると、学生が見る教師の軌跡は自分では到達できない状態です。先ほど述べた能力差の問題が拡大されます。on-policy 蒸留の価値はとくに大きく、学生が実際に踏む状態をそのまま対象にしてサンプリングするからです。
• outlier 処理の順序。回転系の前処理は量子化より前に置くべきですが、同時に構造化枝刈りを行うなら、回転の後に枝刈りすると、枝刈りの判定基準が見る分布はすでに元の分布ではありません。回転の逆変換は直交変換で値の大きさの関係を変えないので一般に安全ですが、振幅に基づく判定基準で枝刈るチャンネルを選ぶなら、順序は依然として重要です。

8.3 重ねる順序の推奨と実測

以上の分析を総合すると、一般的な重ね順は次のとおりです。

1. 構造化枝刈り（行う場合）― モデルの形を変えるので最初に行う必要があります。その後のすべての工程でパラメータ数を減らします。
2. 復旧学習― 枝刈りで失った容量を補います。この工程は低精度化の前に行う必要があり、高精度のまま復旧するのが最も結果は安定します。
3. 蒸留（行う場合）― 教師のデータでこの枝刈り済みのモデルを学習させ、教師に揃えます。この時点で枝刈りによる損失と初期の低精度化のの影響はまとめて補償されます。
4. 回転・チャンネルスケーリングなどの前処理― 最終的なモデルの実際の activations 分布に基づいて推定します。
5. 重み量子化― 最後の表現変換です。この段階の誤差は、もう何のメカニズムでも補償されません。
6. KV 量子化― 重みとは直交するので、並行して進められるため、単独で評価します。

ただしこの順序は出発点にすぎず、実測による検証が必須です。具体的な検証方法として増分アブレーションがあります。BF16 のベースラインから出発し、一度に1つの手段だけを加えながら品質の変化を記録します。次に2つ組み合わせ、3つ組み合わせと、段階的に積み上げます。ある組み合わせの損失が各々の単独損失の和を超えていたら（負の相互作用）、2つの手段が同じものを奪い合っていることを意味し、順序か、どちらかの強度を調整する必要があります。

最後に言っておくべき現実的な判断があります。重ね合わせの限界利得はきわめて速く減少します。単独では16bit から8bit への変更で品質はほとんど落ちず、8bit から4bit で少し落ち、4bit からさらに下げると難しくなります。同様に、20%の枝刈りの損失は小さいかもしれませんが、50%まで削るなら大量の復旧学習が必要です。3つの手段を同時に導入しようとするときは、誠実な期待はこうあるべきです。1つ目で大半の利得を得て、2つ目と3つ目はそれぞれ小さな部分を補い、作用域項がその一部を食べてしまう。時間が限られているなら、利得が最大のものだけを導入するのが通常は最適な判断です。

8.4 組み合わせとは別の第3の道：異なる圧縮率のモデルをカスケードにつなぐ

ここまで議論したすべての方法は、同じ1つのモデルに作用します。しかしエンジニアリングにはまったく別の、しかも多くの場合単一の圧縮方式よりも有効な方法があります。圧縮率の異なる複数のバージョンを用意し、ルーティングで各リクエストをどのバージョンに渡すかを決める。

もっともよく使われる形はカスケードです。小さく速いモデルで最初に処理し、不確かまたはリスクの高いリクエストに遭遇したら大きいモデルへ渡します。その価値は、よく見落とされる事実から来ます。リクエストの難易度の分布は極端に不均一です。大量の日常的なリクエストは書式の変換、常識的な質問、簡単な書き換えで、これらは最強のモデルでも有損圧縮したモデルでもほぼ同じ結果になります。一方、少量のリクエストは長い推論チェーンを必要とし、これらは圧縮モデルで処理すると明確にスコアが落ちます。リクエストごとに演算量を割り当てるのは、全リクエストを一様に圧縮するよりずっと割安です。

カスケードと圧縮の組み合わせ点は明確です。カスケードの上限は最も弱い段によって決まります。すべてのバージョンが BF16 なら、いちばん安い段でもなお高く、カスケードの節約効果は限定的です。まず最も弱い段を4bit か6bit まで圧縮して初めて、カスケード全体のコストが本当に下がります。逆に、圧縮が激しいほどルータの許容度は小さくなります。不確かさの推定が不正確なルータに、品質のより悪いモデルを組み合わせると、本来エスカレーションすべきリクエストが低い段に留まったままになり、平均品質が予想以上に落ちます。したがってルーティングの精度はカスケードシステムの中心指標であり、どの単一段の圧縮指標よりも重要です。評価時は誤エスカレーション率（エスカレーションしなくてよいのにしたケースで、コストを無駄にするもの）と見逃し率（すべきなのにしなかったケースで、品質を失うもの）を別々に測る必要があります。

より単純な形は、タスク種別による静的ルーティングです。確実に単純な業務トラフィックは小さいモデルに固定で通し、複雑なトラフィックは大きいモデルに固定で通します。実行時の判断がまったく不要になります。柔軟性の一部を捨てる代わりに、完全に予測可能なレイテンシとコストが得られるのです。リクエストの特徴が分類しやすい場面では、これは通常より良いエンジニアリング上の選択です。実行時の不確かさそのものが、一種類のコストだからです。

最後に、意思決定のレベルの事実を明示しておく必要があります。カスケードは圧縮の代替手段であり、補完ではありません。トラフィックの難易度分布が十分に偏っていれば、小さいモデル1つと大きいモデル1つの組み合わせのコストは、中くらいのモデルに全量を受け持たせるよりも安くなっている可能性があります。綿密な圧縮のチューニングに投資する前に、まずリクエストの難易度分布を測ってください。80% のリクエストが実は簡単なタスクなら、予算をカスケードのルーティングに使うリターンは、通常4bit を3.6bit まで最適化するものよりずっと大きくなります。

8.5 圧縮とファインチューニングの接続点：順序がコストを決める

圧縮は学習フローの終点ではなく、しばしば中点です。多くの場合、圧縮のあとにもう1ラウンドファインチューニングが必要になるため、このラウンドをどこに置くかでコストが数倍変わるからです。

もっとも重要な原則を先に言います。量子化感知ファインチューニングは、圧縮方針を確定したあとに行うべきもので、方針を選ぶために使うものではありません。多くの人はビット幅を選ぶときに先に1ラウンド量子化感知ファインチューニングをやり、品質が回復したのを見てそのビット幅は実行可能だと結論します。これは循環論法です。量子化感知ファインチューニングは実際にある程度攻めた設定を使える所にしますが、「その設定自体がどれだけ無理な設定だったか」という重要な情報を覆い隠してしまいます。正しいやり方は、学習に頼らない量子化で品質の下限を測定し、そのあとで1ラウンドのファインチューニングで取り戻す価値があるかを判断することです。

次に、具体的な順序のルールをいくつか。枝刈りの後には必ず復旧学習を行い、このラウンドでは同時に量子化感知学習をしてはいけません。枝刈りはすでに大きな構造的摂動なので、復旧学習の目的は容量を取り戻すことです。同時に量子化誤差を抑えると、互いに矛盾する2つの目的が干渉し、結果として両方とも半分しか達成されないことがよくあります。より安定した配置は、まず高精度で枝刈りの復旧を完了させ、次にマスクを凍結して量子化の設定に切り替え、短い区間のファインチューニングで重みを新しい表現に馴染ませることです。

蒸留とファインチューニングは1つのラウンドにまとめられます。最終的な構成に枝刈りと蒸留の両方が入るなら、復旧学習と蒸留を2回行う必要はありません。教師の出力をこの唯一の学習の目標とし、同時に枝刈りのマスクを固定したままにすれば、2つの目的が同じ最適化の中で処理されます。これは直列の2回の学習よりはるかに安く、通常は効果のほうが高くなります。復旧学習も蒸留も同じ重み群を変更するため、分けて行うと後の段階が前の段階の成果を一部洗い流してしまうからです。

低ランク適応と量子化は共存できますが、役割を分ける必要があります。低ランク適応はモデルにタスク関連の新しい能力を注入する役割を持ち、量子化はベースモデルを VRAM に収める役割を持ちます。両者は衝突しませんが、適応マトリクスが量子化の後も低精度を保つかどうかには注意が必要です。適応層が高精度でベースが4bitなら、推論時の精度差は適応層に集中して現れ、評価時に適応層の問題を量子化の問題と誤認しやすくなります。確実な方法は適応層の精度をベースと揃えること、少なくとも評価時に両者を別々に検証することです。

最後に圧縮の後のファインチューニングに使うデータ分布です。圧縮前のモデルで生成したデータで圧縮後のモデルをファインチューニングすると、隠れた分布のミスマッチが生じます。データのスタイルは、より強く、より高い精度のモデルに由来し、そのデータを受け取るモデルはすでに有損だからです。経験的には、圧縮後のモデルで適応データを生成し直したほうが，データ生成のコストは増えますが、効果のほうは高くなります。

この節を1文に圧縮すると、こうなります。圧縮方針が確定したあとにこそ、ファインチューニングが本当に始まります。ファインチューニングは、そもそも否定されるべき圧縮方針を救出するために使うものではなく、飾りを添えることに限られます。この判断によって、もっとも高額な種類の無駄を省けます。本来なら初日に却下すべき攻めた設定のために、1週間もファインチューニングに充当するという無駄です。

九、圧縮が本当に划算だったかをどう判断するか

圧縮プロジェクトでもっとも多い失敗様式は技術的に達成できないことではなく、できあがったものの利得を説明できないことです。以下にそのまま落地できる評価方法を示します。要点は品質、VRAM、速度、コストを1つのレポートにまとめ、1つの純収益指標で収束させることです。

9.1 名目圧縮比と実効圧縮比を先に分ける

ほとんどのレポートにある「4倍の圧縮」は名目圧縮比です。4bit を16bit で割ったものです。実効圧縮比は付随するオーバーヘッドをすべて含めて計算します。

有效权重压缩比 = (基线权重字节数) / (量化后权重字节数 + scale + zero_point + 未压缩的例外值 + 未融合算子工作区)

# 分组元数据开销的快速估算（对称 INT4，每组 128 元素）
overhead_bits_per_weight = (16 + 4) / 128          # FP16 scale + 4bit 零点
actual_bits_per_weight    = 4 + overhead_bits_per_weight   # ≈ 4.156

# 2:4 稀疏的实际情况（每 4 个元素存 2 个值 + 2 位索引）
sparse_effective_ratio    = 2 * 1.0 / (1.0 + 2/16)        # ≈ 1.78x，而非 2.0x

KV 側も同様です。INT4 の KV に group 64 と scale を加えると、実際の1要素あたりのビット数は約4 に20/64 を足した、つまり4.3 bit 程度で、4ではありません。レポートに「4倍」と書くか「3.7倍」と書くかは、厳密さの差ですが、下流で容量計画をする人は後者が必要のです。

9.2 品質評価：層別化が必須で、タスクレベルの最終指標も必要

perplexity はもっとも計算しやすい指標であり、同時に単独ではもっとも意思決定の根拠にならない指標です。実際のタスク性能との相関が弱く、特に枝刈りと蒸留を経ると、perplexity がまったく動かないのにタスク正解率が大きく変化することがあります。推奨する評価の階層は次のとおりです。

• 第0層：perplexity。高速な回帰チェックとしてだけ使い、破滅的な誤り（たとえばある層の量子化にバグがある）を検出するために使います。意思決定には使いません。
• 第1層：汎用能力のベースライン。広い範囲をカバーするベンチマークを固定し、相対変化率ではなくベースラインからの絶対スコアの変化を測ります。
• 第2層：ターゲット能力。実際のタスク群で、重み付けがもっとも高い層です。この層が落ちれば、前の層がどれほど良くても意味がありません。
• 第3層：圧縮に敏感なタスク。誤差に敏感であることが既知のサブセットを専門に選びます。長文脈の検索、多段推論、厳密なコード生成、数値検証が必要な問題です。KV 量子化は前者に、構造化枝刈りは後2者に先に崩れますが、通常のベンチマークではまったく検出できないことがあります。
• 第4層：振る舞いの退行チェック。スコアだけでなく出力の形も見ます。回答の長さが急増していないか、繰り返し始めているか、拒否率が高まっていないか、形式への準拠が崩れていないか。これらは圧縮モデルでもっとも多く、しかももっとも見落とされやすい退行様式です。

評価規律については少なくとも3つの硬い要求があります。サンプリングパラメータを完全に固定すること（貪欲デコード、温度0。サンプリングノイズを持ち込むと圧縮による差分が埋もれます）、複数のランダムシードを使うか、少なくとも評価設定の全部を記録すること、そしてベースラインと圧縮版を同一のハードウェア、同一の batch 設定、同一の並行度で測定することです。さもないと性能の数値は比較できません。

9.3 システム評価：実験室の形状ではなく、実際のトラフィックの形状で測る

性能評価のよくある誤りは、単一リクエストのレイテンシだけを測ることです。圧縮の利得は負荷の形状に強く依存するため、最低でも3つの点を測る必要があります。

同時にVRAM 使用量（予約量ではなくピークのアロケーション量で記録します。予約量はキャッシュプールの影響で実際より大きく出ます）と、モデルのロード時間とコールドスタートも記録してください。36 GB のモデルと140 GB のモデルは、必要に応じてスケールするアーキテクチャでは起動時間が実在するコストになります。

9.4 純収益：意思決定を1つの数値に収束させる

品質損失を許容できる閾値に換算することが、圧縮の意思決定を実装可能にする鍵です。純収益の指標を定義します。

# 净收益：节省的月成本 减去 质量退化带来的月损失
monthly_saving   = (baseline_gpu_count - compressed_gpu_count) * gpu_price_per_hour * hours_per_month
quality_loss_pct = max(0, (baseline_score - compressed_score) / baseline_score)

# 把质量损失换算成业务影响（需要按任务实际估算，这里是结构）
monthly_quality_cost = quality_loss_pct * affected_volume * value_per_request

net_benefit = monthly_saving - monthly_quality_cost

# 决策：净收益为正且质量损失低于业务容忍阈值才上线
# 注意：质量损失必须用绝对分数差判断，不能用相对百分比

この式の要点は数学ではなく、「品質が何ポイント落ちたか」に現実的な値段をつけることを強制することにあります。多くの圧縮プロジェクトは「VRAM を40%節約した」そこで止まってしまいます。「1.2ポイント落ちてもよいのか」と答える必要が出て初めて、1.2ポイントでも業務ごとに意味がまったく違うことに気づきます。内部の要約タスクではどうでもよく、契約レビューでは問題になります。圧縮方式の選択は要するに業務上の許容度の制約のもとでコストを最小化する問題であり、純粋な技術最適化の問題ではありません。

9.5 導入チェックリスト

ここまでの内容を、実行可能な順序に圧縮します。

1. まずボトルネックを測る：本番の長さと並行度の分布を使い、帯域律速か演算律速かを確認します。
2. まず無損失の段階を行う：GQA が既に低設定なら、まず KV ヘッド数と batch スケジューリングを見ます。ボトルネックが KV ではなく重みであることを確認します。
3. 重み側は8bit から始める：INT8 か FP8 の group-wise 量子化は通常安全で、大半の利得を得られます。まずこの段階の品質ベースラインが信頼できることを確認します。
4. そのあとで4bit を検討する：per-group 128 を用い、ターゲットタスクのデータで較正し、GPTQ 一族にチャンネルスケーリングを足します。
5. 長文脈は KV 量子化を別に走らせる：per-token の FP8 か INT8 を、単独で評価し、検索タスクを重点的に測ります。
6. 品質に明確な余裕があるときだけ枝刈りに手をつける：構造化から非構造化の順で、毎回復旧学習を伴わせます。
7. 蒸留は最後に補償の層として置く。順序は「圧縮してから蒸留」で、反対ではありません。
8. すべての操作を増分アブレーションの表に入れる：1つ追加するたびに品質とシステム評価の2つをやり直し、非線形な下落が1つでも現れたら止めて干渉を再分析します。
9. 設定の完全なスナップショットを記録する：量子化パラメータ、較正データのハッシュ、ランダムシード、kernel のバージョン、ドライバーのバージョン。圧縮モデルの再現性は通常のモデルより脆く、記録が1つでも欠けると数か月後にはほぼ再構築できません。

9.6 もっとも多い6つの翻車現場

最後に、実践でもっとも問題が起きやすい場所を一度に挙げます。ほぼすべて実際に起きているもので、しかも例外を投げずに、結論を静かに悪化させるだけです。

1. 推論フレームワークのデフォルト値をベースラインにする。ベースラインは、明示的に設定した BF16 の元の重み版でなければならず、フレームワークが自動で選んだ最適構成を使ってはいけません。そうしないと測った利得のなかにフレームワークの自動最適化が混ざり、圧縮自体の寄与に帰属できません。
2. 量子化版とベースラインで異なるサンプリングパラメータを使う。温度が0でない場合、サンプリングノイズは通常圧縮による差分より大きく、測定すると「差がない」ことになります。実際には差はありますがノイズに埋もれています。すべての比較評価は貪欲デコードで行うべきです。
3. perplexity だけを見て本番へ出す。perplexity は枝刈りにも量子化にも鈍感で、明らかに退行したモデルでも perplexity がほとんど変わりません。少なくともタスクレベルのスコアを1つ、ゲートとして置く必要があります。
4. 長文脈の評価を忘れる。KV 量子化、attention ヘッドの枝刈り、疎 attention の利得とリスクはすべて長系列に集中しています。短い文脈だけで評価するのはもっとも重要な部分を測定していないのと同じです。
5. 入力長分布の変化を無視する。モデルを4K の文脈で128K まで使い、量子化の較正は4K 以内のサンプルしか見ていない場合、較正時の統計的特性に依存する方式は範囲を超えた時点で機能しなくなります。
6. 圧縮を一度きりの設定として扱う。量子化パラメータ、枝刈りマスク、ルーティングの重み、蒸留データのレシピは互いに依存しています。あとでベースモデルを変えたり、推論フレームワークのバージョンを変えたり、較正データを変更したりしたら、以前の評価結論は適用できなくなります。古い結果を引用せず、やり直す必要があります。

この6つの共通点は、いずれも例外を投げず、結論を静かに歪めるだけだということです。つまり圧縮プロジェクトに最も必要な投資は、いっそう精緻な量子化アルゴリズムではなく、継続的に再現でき、変数を特定でき、長文脈の分岐を省略しない評価プロセスです。アルゴリズムの選定は試行錯誤できますが、評価が歪むと、すべての試しがすべて誤った方向を指してしまいます。

9.7 評価自体にもコストがかかることを忘れない

完全な圧縮評価は基準を1回走らせるだけでは終わりません。そのコストは過小評価されがちで、それが安全に測定できる案の数と結論の信頼性を直接に左右します。以下の勘定は事前に把握しておく必要があります。

• 時間コスト：完全な評価を1回回す絶対的な時間が、どれだけ多くの対照実験ができるかを決定します。1回の評価に丸1日かかるなら、3つのランダムシードで走らせるだけで3日かかり、案の反復速度は収束しないほど遅くなります。実務では小規模なサブセットによる高速な一次篩で絞り込み、入った案だけに完全な評価を走らせ、すべての案に同じ完全な手順を通す必要はありません。
• 階層コスト：第0層の perplexity は数分で計算できますが、第2層のターゲット能力評価には数時間かかることがあります。この2つを混ぜると反復が極めて高価になります。階層化の意義は評価論理が明快になることだけでなく、安い判定で枝刈りし、高価な判定で最終決定を下すことにあります。
• 再現性コスト：量子化案の評価はノイズに敏感で、その原因は較正データの分け方や推論時のサンプリングです。同じ案を2回走らせて違う結論が出ても、さらに1回走らせて良い方の結果を採用するという方法では解決しません。それは選択的報告をするということです。ランダム源を固定するか、十分な回数の反復で信頼区間を示してください。
• 保守コスト：量子化パラメータ、較正データのハッシュ、kernel のバージョン、フレームワークのバージョン、ドライバーのバージョンを完全に記録した評価結果だけが、数か月後に再現できます。圧縮スタックのいずれかの層のアップグレードでも結論は変わりうるので、評価環境のバージョンはモデルの設定と一緒にバージョン管理しなければなりません。そうしないと時間をまたぐ比較はすべて無効になります。

この勘定を計算し終えると得られるのは、現実的でありながらよく見落とされる帰結です。すべての組み合わせを1つずつ測定する必要はない。第10節で示す順序そのものが、先験的な利得順に並べた探索経路です。高い確率で効く組み合わせを先に走らせ、評価予算を本当に曖昧な分岐点に回してください。これは全数を1つずつ並べるより時間を節約でき、結論も信頼性よく収束します。逆に言えば、評価予算が3日しかないプロジェクトでは、案の数を減らすべきです。評価の厳密さを削るべきではありません。そこだけが削ってはいけない部分だからです。

9.8 圧縮モデルを本番に載せた後：保守とドリフト

圧縮の設定は一度きりの成果物ではなく、長期的に見守るべき設定です。本番に載せた後に実際に起きるのは、モデルが突然壊れることではなく、結論が少しずつ失効していくことに誰も気づかないことです。次の種類のドリフトはプロセスの中で明示的に監視する価値があります。

• 推論スタックのアップグレードによる数値ドリフト。kernel の実装、リダクションの順序、累積精度は、フレームワークやドライバーのバージョンとともに変わります。同じ重みを異なるバージョンで走らせると多少異なる結果が出るのは正常ですが、差分が時間とともに単調に増大するなら、何らかの工程の数値セマンティクスが変わった可能性があり、再評価が必要です。古い結論を引き続き使ってはいけません。
• 上流の重み更新による失效。ベースモデルが差し替えられたり学習が続けられた場合、圧縮設定内の量子化パラメータ、枝刈りマスク、蒸留データのレシピはすべて無効になります。いずれも特定の重みに合わせて適合させたものです。重みのバージョンごとに圧縮設定を個別に記録し検証しなければならず、前版の結論をそのまま継承することは当然ではありません。
• トラフィック分布のドリフトによる隠れた退行。圧縮方式は特定の入力分布で較正し、評価されています。本番トラフィックの長さ、言語、タスク種別の分布は変化し、activations の数値範囲もそれに伴って変わるため、量子化パラメータは当初の較正時の前提から外れます。この種の問題はオフライン評価には現れません（オフラインの分布そのものが変わっていないため）。オンラインのサンプリングによるバックテストでしか検出できません。
• 品質ドリフトの観測方法。圧縮モデルのオンライン品質の低下は漸進的で、出力が冗長になったり、繰り返しを始めたり、境界的な問題に書式を守らない答えを返すようになったりします。これらはラベル付きデータなしでも検出できます。定期的なサンプリングで人が確認し、出力長の分布、繰り返し率、拒否率を監視すれば、業務指標が落ちるのを待つより早く問題を検出できます。

対応する実践としての提案は3つです。圧縮設定と重みのバージョンを紐づけてバージョン管理する。どちらか一方でも変われば再評価を実行します。推論スタックのアップグレードのリリースプロセスに回帰評価を追加する。機能テストと同じゲートに置きます。そして定期的にオンラインの実際の分布でサンプリングバックテストを行う。オフラインの指標が動いていなくても、分布そのものが変わっているからです。

この3つの共通ロジックは、圧縮方式の有効性が3つの暗黙の前提に依存しているという点です。重みが変わらないこと、推論スタックが変わらないこと、入力分布が変わらないこと。どれか1つでも破れれば、以前の評価結論は自動的に成立しなくなります。この3つの前提を明示的にチェックリストに書き込むことは、あとから調査するよりずっと安価です。

十、まとめ：圧縮は一連の意思決定であり、一つの技術ではない

冒頭の判断に戻ります。圧縮がまず節約するのはストレージと転送であり、それだけが速度になるのはボトルネックが帯域にあるときだけです。重み量子化は KV Cache に触れず、activations 量子化だけが FLOPs に触れます。蒸留は全次元に効く唯一の手段であると同時に、コストももっとも高い。この判断は他のすべての選択を決めます。

手法まで具体的に降りると、量子化はもっとも普遍的な一段であり、そのノブはビット幅（どれだけ節約するか）とグループ粒度（節約する価値があるか）です。現代の PTQ の違いは、activations を考慮したチャンネルスケーリングと回転の前処理を行ったかどうかでほぼ決まります。GPTQ と AWQ は別レベルの問いに答えるもので、実践では二択ではなく重ねて使うことがほとんどです。枝刈りの成否はハードウェアの形式によって決まります。2:4 は現在唯一に広くハードウェアにサポートされている形で、構造化枝刈りは唯一本物の FLOPs を節約する形で、どちらも復旧学習が要ります。蒸留の上限はデータ構築で決まり、能力差の領域のデータだけが有効な学習信号で、on-policy の方法のほうが、オフラインの方法よりも当てはまりが良い

そして3つを重ねるときにもっとも重要な仕組み上の結論は1つだけです。蒸留は有損圧縮のあとの監督的な補償として行われるので、順序は「枝刈り → 復旧学習 → 蒸留 → 量子化」となり、量子化は最後に置くべき。量子化には補償の仕組みがないため、後で行うほど損失を挽回しにくくなるからです。枝刈りは量子化より前に行う必要があり、両者のグループ粒度が衝突するからです。

最後に、「本当に划算だったか」をどう判断するかについて、ひとつの答えしかありません。実際のトラフィックの形状、実際のタスク分布、実際の業務上の許容度を使って、その1つの純収益の数値を計算する。この数値に収束しない圧縮のレポートは、単なる技術デモにすぎません。本物のエンジニアリングの意思決定が問われるのは「圧縮できるか」ではなく「節約したこの演算量分の価値が、落としたこの品質に報われるか」です。