4月17日、Cloudflareが「Unweight: how we compressed an LLM 22% without sacrificing quality」と題した記事を公開した。
同社が開発した「Unweight」は、品質を一切犠牲にすることなくLLMを15-22%圧縮できるロスレス圧縮技術である。Llama-3.1-8Bでの実装では約3GBのVRAMを節約し、推論速度の向上を実現している。この技術が注目される背景には、現代のAI推論における深刻なメモリボトルネック問題がある。生成AIの普及とともにLLMのサイズは急拡大し、GPT-4クラスのモデルでは数百GBのメモリが必要となる一方、GPU価格の高騰により効率的なメモリ利用が業界全体の課題となっていた。
Cloudflareが世界のインターネット接続人口の95%に対して50ms以内での推論を実現するために使用するNVIDIA H100 GPUでは、テンサーコアがデータを処理する速度は、メモリがデータを供給する速度の約600倍に達する。つまり、ボトルネックは計算能力ではなく、メモリ帯域幅にある。LLMから1つのトークンを生成するたびに、GPU メモリからすべてのモデル重みを読み込む必要があり、メモリバスを通過するすべてのバイトがパフォーマンスに直結する。
指数部分の冗長性を突いたブレークスルー
Unweightの核心的なアイデアは、AI モデルの数値表現における指数部分の冗長性を活用することにある。すべての重みは16ビットの「ブレインフロート」（BF16）として格納され、符号（1ビット）、指数（8ビット）、仮数（7ビット）の3部分で構成される。
符号と仮数は予測不可能に変化するため意味のある圧縮は困難だが、指数部分は驚くほど予測可能である。訓練されたLLMでは、256個の可能な指数値のうち、上位16個の最も一般的な指数が全ウェイトの99%以上をカバーしている。情報理論上、この分布を表現するには約2.6ビットしか必要ない。
Unweightはこの冗長性を活用し、符号と仮数には手を付けず、**指数バイトのみをハフマン符号化**で圧縮する。指数分布が極度に偏っているため、指数ストリームで約30%の圧縮を実現している。
4つの実行戦略で最適化
圧縮された重みを推論時に使用する「最適な」方法は存在しない。適切なアプローチは、バッチサイズ、重み行列の形状、展開に利用可能なGPU時間によって異なる。そこでUnweightは4つの圧縮実行パイプラインを提供する：
- Full decode：完全にBF16重みを再構築
- Exponent-only decode：指数バイトのみを展開
- Palette transcode：4ビット形式に変換
- Direct palette：前処理をスキップして直接処理
小さなバッチサイズ（1-64トークン）では行列乗算が小さく、カスタムカーネルの固定コストが支配的になるため、Full decode + cuBLASが勝つことが多い。大きなバッチサイズ（256+トークン）では、より軽量な前処理が有利になる。実行時にUnweightは複数の戦略から選択し、自動チューナーが重み行列とバッチサイズごとに最適なものを選択する。
既存手法との差別化ポイント
従来のLLM圧縮手法には、ZipNN、Huff-LLM、ZipServなどがあるが、これらは主に配布やストレージ、特別なハードウェアに焦点を当てていた。一方、UnweightはH100 GPUでの推論時ロスレス展開という、これまでカバーされていない領域を埋める技術として差別化されている。
量子化（quantization）と異なり、Unweightはビット完全な出力を保持するため、品質劣化は一切発生しない。これは本番環境での信頼性が重要なCloudflareのような企業にとって決定的な優位性となる。近年、量子化による精度低下が問題視される中で、ロスレス圧縮への注目が高まっており、Unweightはその需要に応える技術と言える。
オープンソースでの貢献
CloudflareはUnweightの透明性を重視し、イノベーションを促進するため、技術論文とGPU カーネルをオープンソースで公開している。これにより、他の研究者や企業も同様の最適化手法を活用できるようになった。
LLMの商用利用が拡大する中で、メモリ効率の改善は運用コストの削減に直結する。AWS、Google Cloud、Azure等のクラウドプロバイダーでGPUインスタンスの費用が高騰する現状において、Unweightのようなロスレス圧縮技術は、AI推論インフラの新たなスタンダードになる可能性を秘めている。
詳細はUnweight: how we compressed an LLM 22% without sacrificing qualityを参照していただきたい。
