AutoCompress、実ハードウェア制約に合わせてLLMを自動圧縮

大規模言語モデルの圧縮では、単にパラメータを何割削減するかを決めればよいわけではない。同じパラメータ数でも、層の構造、コンテキスト長、バッチサイズ、GPU、推論エンジンが変われば、遅延やスループット、メモリ使用量は大きく変わり得る。NVIDIAの研究チームが提案したAutoCompressは、こうした実運用条件を圧縮処理の中心に置く。

パラメータ数から実測コストへ

従来の枝刈りでは、まず小型モデルのサイズを決め、その後に目的の環境で制約を満たすか確認することが多い。しかし、パラメータ数は実際のサービス性能を示す間接的な指標にすぎない。AutoCompressは、対象環境に合わせて次の処理を行う。

• ハードウェア別のコストモデル：対象GPU上でモデルを効率的にプロファイリングし、構造ごとのコストを推定する。
• 微分可能なアーキテクチャ探索：全体の構造と層単位の構造を、制約の下で同時に最適化する。
• 異種アーキテクチャの生成：すべての層に同じ圧縮率を適用せず、層ごとに異なる規模を選択する。
• 枝刈りと蒸留：探索で決めた構造に実際の枝刈りを施し、蒸留によって品質低下を補う。

重要なのは、最小モデルを探すのではなく、特定のGPU、ワークロード、サービス条件を満たす構造を探す点だ。コストモデルは、エンドツーエンドの遅延、スループット、メモリ実測とも照合されるため、予測上は制約内でも実際のサービスで超過するリスクを抑えやすい。

三つの利用場面で評価

評価対象は、長文脈のローカルコーディング、データセンターでのバッチ推論、応答速度が重要なゲーム内インタラクションの三つだ。Minitron枝刈りフレームワークと比べ、8種類のベンチマークにおける平均精度は、RTX 5070で6.57ポイント、RTX 5080で2.35ポイント、H100で0.57ポイント向上した。資料では、アーキテクチャ探索に必要なトークン数も約2〜3.3倍削減されたとしている。

大規模な事例では、Nemotron 3.5 Superを120Bから74Bパラメータへ圧縮した。単一のB200上で、BF16、128Kコンテキストのサービスを想定し、平均ベンチマークスコアの約95％を維持したという。

意義と限界

AutoCompressは、モデル品質とデプロイ可能性を一つの最適化ループで扱う。長文脈アプリ、バッチ推論、インタラクティブな製品では、パラメータ数を手探りで選ぶのではなく、目標とするハードウェアやサービス条件を直接指定できる。

一方で、結果は特定のハードウェア、ワークロード、推論エンジンを前提として読む必要がある。環境依存性を明示的に扱う手法であるため、あるGPUで得られた改善がすべての環境で再現されるとは限らない。より大きな意味は、モデル圧縮を手作業による設計から、実測性能に基づく自動化された開発工程へ移行させる点にある。

出典：Hugging Face Daily Papers